Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts: drivers/net/smsc911x.c
This commit is contained in:
		
				commit
				
					
						1c01a80cfe
					
				
			
		
					 2765 changed files with 7223 additions and 8041 deletions
				
			
		
							
								
								
									
										6
									
								
								CREDITS
									
										
									
									
									
								
							
							
						
						
									
										6
									
								
								CREDITS
									
										
									
									
									
								
							|  | @ -1677,7 +1677,7 @@ W: http://www.codemonkey.org.uk | ||||||
| D: Assorted VIA x86 support. | D: Assorted VIA x86 support. | ||||||
| D: 2.5 AGPGART overhaul. | D: 2.5 AGPGART overhaul. | ||||||
| D: CPUFREQ maintenance. | D: CPUFREQ maintenance. | ||||||
| D: Fedora kernel maintainence. | D: Fedora kernel maintenance. | ||||||
| D: Misc/Other. | D: Misc/Other. | ||||||
| S: 314 Littleton Rd, Westford, MA 01886, USA | S: 314 Littleton Rd, Westford, MA 01886, USA | ||||||
| 
 | 
 | ||||||
|  | @ -3211,7 +3211,7 @@ N: James Simmons | ||||||
| E: jsimmons@infradead.org | E: jsimmons@infradead.org | ||||||
| E: jsimmons@users.sf.net  | E: jsimmons@users.sf.net  | ||||||
| D: Frame buffer device maintainer | D: Frame buffer device maintainer | ||||||
| D: input layer developement  | D: input layer development | ||||||
| D: tty/console layer | D: tty/console layer | ||||||
| D: various mipsel devices  | D: various mipsel devices  | ||||||
| S: 115 Carmel Avenue  | S: 115 Carmel Avenue  | ||||||
|  | @ -3290,7 +3290,7 @@ S: USA | ||||||
| N: Manfred Spraul | N: Manfred Spraul | ||||||
| E: manfred@colorfullife.com | E: manfred@colorfullife.com | ||||||
| W: http://www.colorfullife.com/~manfred | W: http://www.colorfullife.com/~manfred | ||||||
| D: Lots of tiny hacks. Larger improvments to SysV IPC msg, | D: Lots of tiny hacks. Larger improvements to SysV IPC msg, | ||||||
| D: slab, pipe, select. | D: slab, pipe, select. | ||||||
| S: 71701 Schwieberdingen | S: 71701 Schwieberdingen | ||||||
| S: Germany | S: Germany | ||||||
|  |  | ||||||
|  | @ -206,8 +206,8 @@ laptops/ | ||||||
| 	- directory with laptop related info and laptop driver documentation. | 	- directory with laptop related info and laptop driver documentation. | ||||||
| ldm.txt | ldm.txt | ||||||
| 	- a brief description of LDM (Windows Dynamic Disks). | 	- a brief description of LDM (Windows Dynamic Disks). | ||||||
| leds-class.txt | leds/ | ||||||
| 	- documents LED handling under Linux. | 	- directory with info about LED handling under Linux. | ||||||
| local_ops.txt | local_ops.txt | ||||||
| 	- semantics and behavior of local atomic operations. | 	- semantics and behavior of local atomic operations. | ||||||
| lockdep-design.txt | lockdep-design.txt | ||||||
|  |  | ||||||
|  | @ -29,7 +29,7 @@ Contact:	Cornelia Huck <cornelia.huck@de.ibm.com> | ||||||
| 		linux-s390@vger.kernel.org | 		linux-s390@vger.kernel.org | ||||||
| Description:	Contains the PIM/PAM/POM values, as reported by the | Description:	Contains the PIM/PAM/POM values, as reported by the | ||||||
| 		channel subsystem when last queried by the common I/O | 		channel subsystem when last queried by the common I/O | ||||||
| 		layer (this implies that this attribute is not neccessarily | 		layer (this implies that this attribute is not necessarily | ||||||
| 		in sync with the values current in the channel subsystem). | 		in sync with the values current in the channel subsystem). | ||||||
| 		Note: This is an I/O-subchannel specific attribute. | 		Note: This is an I/O-subchannel specific attribute. | ||||||
| Users:		s390-tools, HAL | Users:		s390-tools, HAL | ||||||
|  |  | ||||||
|  | @ -33,5 +33,5 @@ Contact:	Richard Purdie <rpurdie@rpsys.net> | ||||||
| Description: | Description: | ||||||
| 		Invert the LED on/off state. This parameter is specific to | 		Invert the LED on/off state. This parameter is specific to | ||||||
| 		gpio and backlight triggers. In case of the backlight trigger, | 		gpio and backlight triggers. In case of the backlight trigger, | ||||||
| 		it is usefull when driving a LED which is intended to indicate | 		it is useful when driving a LED which is intended to indicate | ||||||
| 		a device in a standby like state. | 		a device in a standby like state. | ||||||
|  |  | ||||||
|  | @ -40,7 +40,7 @@ What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid- | ||||||
| Date:		March 2010 | Date:		March 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
|                 press of a button. A profile holds informations like button |                 press of a button. A profile holds information like button | ||||||
|                 mappings, sensitivity, the colors of the 5 leds and light |                 mappings, sensitivity, the colors of the 5 leds and light | ||||||
|                 effects. |                 effects. | ||||||
|                 When read, these files return the respective profile. The |                 When read, these files return the respective profile. The | ||||||
|  |  | ||||||
|  | @ -33,7 +33,7 @@ Date:		August 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_buttons holds informations about button layout. | 		profile_buttons holds information about button layout. | ||||||
| 		When written, this file lets one write the respective profile | 		When written, this file lets one write the respective profile | ||||||
| 		buttons back to the mouse. The data has to be 77 bytes long. | 		buttons back to the mouse. The data has to be 77 bytes long. | ||||||
| 		The mouse will reject invalid data. | 		The mouse will reject invalid data. | ||||||
|  | @ -47,7 +47,7 @@ Date:		August 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_buttons holds informations about button layout. | 		profile_buttons holds information about button layout. | ||||||
| 		When read, these files return the respective profile buttons. | 		When read, these files return the respective profile buttons. | ||||||
| 		The returned data is 77 bytes in size. | 		The returned data is 77 bytes in size. | ||||||
| 		This file is readonly. | 		This file is readonly. | ||||||
|  | @ -58,7 +58,7 @@ Date:		October 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_settings holds informations like resolution, sensitivity | 		profile_settings holds information like resolution, sensitivity | ||||||
| 		and light effects. | 		and light effects. | ||||||
| 		When written, this file lets one write the respective profile | 		When written, this file lets one write the respective profile | ||||||
| 		settings back to the mouse. The data has to be 43 bytes long. | 		settings back to the mouse. The data has to be 43 bytes long. | ||||||
|  | @ -73,7 +73,7 @@ Date:		August 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_settings holds informations like resolution, sensitivity | 		profile_settings holds information like resolution, sensitivity | ||||||
| 		and light effects. | 		and light effects. | ||||||
| 		When read, these files return the respective profile settings. | 		When read, these files return the respective profile settings. | ||||||
| 		The returned data is 43 bytes in size. | 		The returned data is 43 bytes in size. | ||||||
|  |  | ||||||
|  | @ -52,7 +52,7 @@ Date:		January 2011 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_buttons holds informations about button layout. | 		profile_buttons holds information about button layout. | ||||||
| 		When written, this file lets one write the respective profile | 		When written, this file lets one write the respective profile | ||||||
| 		buttons back to the mouse. The data has to be 23 bytes long. | 		buttons back to the mouse. The data has to be 23 bytes long. | ||||||
| 		The mouse will reject invalid data. | 		The mouse will reject invalid data. | ||||||
|  | @ -66,7 +66,7 @@ Date:		January 2011 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_buttons holds informations about button layout. | 		profile_buttons holds information about button layout. | ||||||
| 		When read, these files return the respective profile buttons. | 		When read, these files return the respective profile buttons. | ||||||
| 		The returned data is 23 bytes in size. | 		The returned data is 23 bytes in size. | ||||||
| 		This file is readonly. | 		This file is readonly. | ||||||
|  | @ -77,7 +77,7 @@ Date:		January 2011 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_settings holds informations like resolution, sensitivity | 		profile_settings holds information like resolution, sensitivity | ||||||
| 		and light effects. | 		and light effects. | ||||||
| 		When written, this file lets one write the respective profile | 		When written, this file lets one write the respective profile | ||||||
| 		settings back to the mouse. The data has to be 16 bytes long. | 		settings back to the mouse. The data has to be 16 bytes long. | ||||||
|  | @ -92,7 +92,7 @@ Date:		January 2011 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_settings holds informations like resolution, sensitivity | 		profile_settings holds information like resolution, sensitivity | ||||||
| 		and light effects. | 		and light effects. | ||||||
| 		When read, these files return the respective profile settings. | 		When read, these files return the respective profile settings. | ||||||
| 		The returned data is 16 bytes in size. | 		The returned data is 16 bytes in size. | ||||||
|  |  | ||||||
|  | @ -39,7 +39,7 @@ Date:		August 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_settings holds informations like resolution, sensitivity | 		profile_settings holds information like resolution, sensitivity | ||||||
| 		and light effects. | 		and light effects. | ||||||
| 		When written, this file lets one write the respective profile | 		When written, this file lets one write the respective profile | ||||||
| 		settings back to the mouse. The data has to be 13 bytes long. | 		settings back to the mouse. The data has to be 13 bytes long. | ||||||
|  | @ -54,7 +54,7 @@ Date:		August 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_settings holds informations like resolution, sensitivity | 		profile_settings holds information like resolution, sensitivity | ||||||
| 		and light effects. | 		and light effects. | ||||||
| 		When read, these files return the respective profile settings. | 		When read, these files return the respective profile settings. | ||||||
| 		The returned data is 13 bytes in size. | 		The returned data is 13 bytes in size. | ||||||
|  | @ -66,7 +66,7 @@ Date:		August 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_buttons holds informations about button layout. | 		profile_buttons holds information about button layout. | ||||||
| 		When written, this file lets one write the respective profile | 		When written, this file lets one write the respective profile | ||||||
| 		buttons back to the mouse. The data has to be 19 bytes long. | 		buttons back to the mouse. The data has to be 19 bytes long. | ||||||
| 		The mouse will reject invalid data. | 		The mouse will reject invalid data. | ||||||
|  | @ -80,7 +80,7 @@ Date:		August 2010 | ||||||
| Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | Contact:	Stefan Achatz <erazor_de@users.sourceforge.net> | ||||||
| Description:	The mouse can store 5 profiles which can be switched by the | Description:	The mouse can store 5 profiles which can be switched by the | ||||||
| 		press of a button. A profile is split in settings and buttons. | 		press of a button. A profile is split in settings and buttons. | ||||||
| 		profile_buttons holds informations about button layout. | 		profile_buttons holds information about button layout. | ||||||
| 		When read, these files return the respective profile buttons. | 		When read, these files return the respective profile buttons. | ||||||
| 		The returned data is 19 bytes in size. | 		The returned data is 19 bytes in size. | ||||||
| 		This file is readonly. | 		This file is readonly. | ||||||
|  |  | ||||||
|  | @ -27,7 +27,7 @@ KernelVersion:	2.6.20 | ||||||
| Contact:	"Corentin Chary" <corentincj@iksaif.net> | Contact:	"Corentin Chary" <corentincj@iksaif.net> | ||||||
| Description: | Description: | ||||||
| 		Some models like the W1N have a LED display that can be | 		Some models like the W1N have a LED display that can be | ||||||
| 		used to display several informations. | 		used to display several items of information. | ||||||
| 		To control the LED display, use the following : | 		To control the LED display, use the following : | ||||||
| 		    echo 0x0T000DDD > /sys/devices/platform/asus_laptop/ | 		    echo 0x0T000DDD > /sys/devices/platform/asus_laptop/ | ||||||
| 		where T control the 3 letters display, and DDD the 3 digits display. | 		where T control the 3 letters display, and DDD the 3 digits display. | ||||||
|  |  | ||||||
|  | @ -40,7 +40,7 @@ | ||||||
| 
 | 
 | ||||||
| 			<para>Central frequency of the channel.</para> | 			<para>Central frequency of the channel.</para> | ||||||
| 
 | 
 | ||||||
| 			<para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a | 			<para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a | ||||||
| 				valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of | 				valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of | ||||||
| 				the channel which is 6MHz.</para> | 				the channel which is 6MHz.</para> | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -139,7 +139,7 @@ consistently to the DiSEqC commands as described in the DiSEqC spec.</para> | ||||||
| <section id="frontend_sec_tone"> | <section id="frontend_sec_tone"> | ||||||
| <title>SEC continuous tone</title> | <title>SEC continuous tone</title> | ||||||
| 
 | 
 | ||||||
| <para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the | <para>The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the | ||||||
| high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to | high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to | ||||||
| be switched consistently to the DiSEqC commands as described in the DiSEqC | be switched consistently to the DiSEqC commands as described in the DiSEqC | ||||||
| spec.</para> | spec.</para> | ||||||
|  |  | ||||||
|  | @ -1507,7 +1507,7 @@ and other resources, etc. | ||||||
| 
 | 
 | ||||||
| 	<listitem> | 	<listitem> | ||||||
| 	<para> | 	<para> | ||||||
| 	CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used) | 	CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used) | ||||||
| 	</para> | 	</para> | ||||||
| 	</listitem> | 	</listitem> | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -485,7 +485,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) | ||||||
| 				Reed-Solomon library. | 				Reed-Solomon library. | ||||||
| 			</para> | 			</para> | ||||||
| 			<para> | 			<para> | ||||||
| 				The ECC bytes must be placed immidiately after the data | 				The ECC bytes must be placed immediately after the data | ||||||
| 				bytes in order to make the syndrome generator work. This | 				bytes in order to make the syndrome generator work. This | ||||||
| 				is contrary to the usual layout used by software ECC. The | 				is contrary to the usual layout used by software ECC. The | ||||||
| 				separation of data and out of band area is not longer | 				separation of data and out of band area is not longer | ||||||
|  | @ -629,7 +629,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) | ||||||
| 				holds the bad block table. Store a pointer to the pattern   | 				holds the bad block table. Store a pointer to the pattern   | ||||||
| 				in the pattern field. Further the length of the pattern has to be  | 				in the pattern field. Further the length of the pattern has to be  | ||||||
| 				stored in len and the offset in the spare area must be given | 				stored in len and the offset in the spare area must be given | ||||||
| 				in the offs member of the nand_bbt_descr stucture. For mirrored | 				in the offs member of the nand_bbt_descr structure. For mirrored | ||||||
| 				bad block tables different patterns are mandatory.</para></listitem> | 				bad block tables different patterns are mandatory.</para></listitem> | ||||||
| 				<listitem><para>Table creation</para> | 				<listitem><para>Table creation</para> | ||||||
| 				<para>Set the option NAND_BBT_CREATE to enable the table creation | 				<para>Set the option NAND_BBT_CREATE to enable the table creation | ||||||
|  | @ -648,7 +648,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) | ||||||
| 				<listitem><para>Table version control</para> | 				<listitem><para>Table version control</para> | ||||||
| 				<para>Set the option NAND_BBT_VERSION to enable the table version control. | 				<para>Set the option NAND_BBT_VERSION to enable the table version control. | ||||||
| 				It's highly recommended to enable this for mirrored tables with write | 				It's highly recommended to enable this for mirrored tables with write | ||||||
| 				support. It makes sure that the risk of loosing the bad block | 				support. It makes sure that the risk of losing the bad block | ||||||
| 				table information is reduced to the loss of the information about the | 				table information is reduced to the loss of the information about the | ||||||
| 				one worn out block which should be marked bad. The version is stored in | 				one worn out block which should be marked bad. The version is stored in | ||||||
| 				4 consecutive bytes in the spare area of the device. The position of | 				4 consecutive bytes in the spare area of the device. The position of | ||||||
|  | @ -1060,19 +1060,19 @@ data in this page</entry> | ||||||
| <row> | <row> | ||||||
| <entry>0x3D</entry> | <entry>0x3D</entry> | ||||||
| <entry>ECC byte 21</entry> | <entry>ECC byte 21</entry> | ||||||
| <entry>Error correction code byte 0 of the eigth 256 Bytes of data | <entry>Error correction code byte 0 of the eighth 256 Bytes of data | ||||||
| in this page</entry> | in this page</entry> | ||||||
| </row> | </row> | ||||||
| <row> | <row> | ||||||
| <entry>0x3E</entry> | <entry>0x3E</entry> | ||||||
| <entry>ECC byte 22</entry> | <entry>ECC byte 22</entry> | ||||||
| <entry>Error correction code byte 1 of the eigth 256 Bytes of data | <entry>Error correction code byte 1 of the eighth 256 Bytes of data | ||||||
| in this page</entry> | in this page</entry> | ||||||
| </row> | </row> | ||||||
| <row> | <row> | ||||||
| <entry>0x3F</entry> | <entry>0x3F</entry> | ||||||
| <entry>ECC byte 23</entry> | <entry>ECC byte 23</entry> | ||||||
| <entry>Error correction code byte 2 of the eigth 256 Bytes of data | <entry>Error correction code byte 2 of the eighth 256 Bytes of data | ||||||
| in this page</entry> | in this page</entry> | ||||||
| </row> | </row> | ||||||
| </tbody></tgroup></informaltable> | </tbody></tgroup></informaltable> | ||||||
|  |  | ||||||
|  | @ -267,8 +267,8 @@ | ||||||
|      <sect1 id="machine-constraint"> |      <sect1 id="machine-constraint"> | ||||||
|        <title>Constraints</title> |        <title>Constraints</title> | ||||||
|        <para> |        <para> | ||||||
| 	 As well as definining the connections the machine interface | 	 As well as defining the connections the machine interface | ||||||
| 	 also provides constraints definining the operations that | 	 also provides constraints defining the operations that | ||||||
| 	 clients are allowed to perform and the parameters that may be | 	 clients are allowed to perform and the parameters that may be | ||||||
| 	 set.  This is required since generally regulator devices will | 	 set.  This is required since generally regulator devices will | ||||||
| 	 offer more flexibility than it is safe to use on a given | 	 offer more flexibility than it is safe to use on a given | ||||||
|  |  | ||||||
|  | @ -797,7 +797,7 @@ framework to set up sysfs files for this region. Simply leave it alone. | ||||||
| 	perform some initialization. After that, your hardware | 	perform some initialization. After that, your hardware | ||||||
| 	starts working and will generate an interrupt as soon | 	starts working and will generate an interrupt as soon | ||||||
| 	as it's finished, has some data available, or needs your | 	as it's finished, has some data available, or needs your | ||||||
| 	attention because an error occured. | 	attention because an error occurred. | ||||||
| 	</para> | 	</para> | ||||||
| 	<para> | 	<para> | ||||||
| 	<filename>/dev/uioX</filename> is a read-only file. A | 	<filename>/dev/uioX</filename> is a read-only file. A | ||||||
|  |  | ||||||
|  | @ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) | ||||||
| 		    </para><para> | 		    </para><para> | ||||||
| 		    This request lets kernel drivers talk to user mode code | 		    This request lets kernel drivers talk to user mode code | ||||||
| 		    through filesystem operations even when they don't create | 		    through filesystem operations even when they don't create | ||||||
| 		    a charactor or block special device. | 		    a character or block special device. | ||||||
| 		    It's also been used to do things like ask devices what | 		    It's also been used to do things like ask devices what | ||||||
| 		    device special file should be used. | 		    device special file should be used. | ||||||
| 		    Two pre-defined ioctls are used | 		    Two pre-defined ioctls are used | ||||||
|  |  | ||||||
|  | @ -100,7 +100,7 @@ linux-kernel@vger.kernel.org, 2002-11-20. --></para> | ||||||
| 
 | 
 | ||||||
|       <para>By convention system administrators create various |       <para>By convention system administrators create various | ||||||
| character device special files with these major and minor numbers in | character device special files with these major and minor numbers in | ||||||
| the <filename>/dev</filename> directory. The names recomended for the | the <filename>/dev</filename> directory. The names recommended for the | ||||||
| different V4L2 device types are listed in <xref linkend="devices" />. | different V4L2 device types are listed in <xref linkend="devices" />. | ||||||
| </para> | </para> | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -1243,7 +1243,7 @@ values are:</entry> | ||||||
| 	      </row><row><entry spanname="descr">Mutes the audio when | 	      </row><row><entry spanname="descr">Mutes the audio when | ||||||
| capturing. This is not done by muting audio hardware, which can still | capturing. This is not done by muting audio hardware, which can still | ||||||
| produce a slight hiss, but in the encoder itself, guaranteeing a fixed | produce a slight hiss, but in the encoder itself, guaranteeing a fixed | ||||||
| and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry> | and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry> | ||||||
| 	      </row> | 	      </row> | ||||||
| 	      <row><entry></entry></row> | 	      <row><entry></entry></row> | ||||||
| 	      <row id="v4l2-mpeg-video-encoding"> | 	      <row id="v4l2-mpeg-video-encoding"> | ||||||
|  |  | ||||||
|  | @ -90,7 +90,7 @@ | ||||||
|     processing hardware.</para> |     processing hardware.</para> | ||||||
| 
 | 
 | ||||||
|     <figure id="pipeline-scaling"> |     <figure id="pipeline-scaling"> | ||||||
|       <title>Image Format Negotation on Pipelines</title> |       <title>Image Format Negotiation on Pipelines</title> | ||||||
|       <mediaobject> |       <mediaobject> | ||||||
| 	<imageobject> | 	<imageobject> | ||||||
| 	  <imagedata fileref="pipeline.pdf" format="PS" /> | 	  <imagedata fileref="pipeline.pdf" format="PS" /> | ||||||
|  |  | ||||||
|  | @ -140,7 +140,7 @@ and is not locked sets the cid to the scaled value. | ||||||
| 			<para>int v4l2_get_control(int fd, int cid) - | 			<para>int v4l2_get_control(int fd, int cid) - | ||||||
| This function returns a value of 0 - 65535, scaled to from the actual range | This function returns a value of 0 - 65535, scaled to from the actual range | ||||||
| of the given v4l control id. when the cid does not exist, could not be | of the given v4l control id. when the cid does not exist, could not be | ||||||
| accessed for some reason, or some error occured 0 is returned. | accessed for some reason, or some error occurred 0 is returned. | ||||||
| </para></listitem> | </para></listitem> | ||||||
| </itemizedlist> | </itemizedlist> | ||||||
| 		</section> | 		</section> | ||||||
|  |  | ||||||
|  | @ -133,7 +133,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media | ||||||
| <row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row> | <row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row> | ||||||
| <row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row> | <row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row> | ||||||
| 
 | 
 | ||||||
| <row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row> | <row><entry><emphasis role="bold">Miscellaneous keys</emphasis></entry></row> | ||||||
| 
 | 
 | ||||||
| <row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row> | <row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row> | ||||||
| <row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row> | <row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row> | ||||||
|  |  | ||||||
|  | @ -4784,7 +4784,7 @@ struct _snd_pcm_runtime { | ||||||
|         FM registers can be directly accessed through the direct-FM API, |         FM registers can be directly accessed through the direct-FM API, | ||||||
|       defined in <filename><sound/asound_fm.h></filename>. In |       defined in <filename><sound/asound_fm.h></filename>. In | ||||||
|       ALSA native mode, FM registers are accessed through |       ALSA native mode, FM registers are accessed through | ||||||
|       the Hardware-Dependant Device direct-FM extension API, whereas in |       the Hardware-Dependent Device direct-FM extension API, whereas in | ||||||
|       OSS compatible mode, FM registers can be accessed with the OSS |       OSS compatible mode, FM registers can be accessed with the OSS | ||||||
|       direct-FM compatible API in <filename>/dev/dmfmX</filename> device.  |       direct-FM compatible API in <filename>/dev/dmfmX</filename> device.  | ||||||
|       </para> |       </para> | ||||||
|  |  | ||||||
|  | @ -253,8 +253,8 @@ In constrast, MSI is restricted to a maximum of 32 interrupts (and | ||||||
| must be a power of two).  In addition, the MSI interrupt vectors must | must be a power of two).  In addition, the MSI interrupt vectors must | ||||||
| be allocated consecutively, so the system may not be able to allocate | be allocated consecutively, so the system may not be able to allocate | ||||||
| as many vectors for MSI as it could for MSI-X.  On some platforms, MSI | as many vectors for MSI as it could for MSI-X.  On some platforms, MSI | ||||||
| interrupts must all be targetted at the same set of CPUs whereas MSI-X | interrupts must all be targeted at the same set of CPUs whereas MSI-X | ||||||
| interrupts can all be targetted at different CPUs. | interrupts can all be targeted at different CPUs. | ||||||
| 
 | 
 | ||||||
| 4.5.2 Spinlocks | 4.5.2 Spinlocks | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -28,7 +28,7 @@ expect these delays to be short, measurable in days, not weeks or months. | ||||||
| A disclosure date is negotiated by the security team working with the | A disclosure date is negotiated by the security team working with the | ||||||
| bug submitter as well as vendors.  However, the kernel security team | bug submitter as well as vendors.  However, the kernel security team | ||||||
| holds the final say when setting a disclosure date.  The timeframe for | holds the final say when setting a disclosure date.  The timeframe for | ||||||
| disclosure is from immediate (esp. if it's already publically known) | disclosure is from immediate (esp. if it's already publicly known) | ||||||
| to a few weeks.  As a basic default policy, we expect report date to | to a few weeks.  As a basic default policy, we expect report date to | ||||||
| disclosure date to be on the order of 7 days. | disclosure date to be on the order of 7 days. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -101,7 +101,7 @@ PM support:	Since Linux is used on many portable and desktop systems, your | ||||||
| 		complete overview of the power management issues related to | 		complete overview of the power management issues related to | ||||||
| 		drivers see Documentation/power/devices.txt . | 		drivers see Documentation/power/devices.txt . | ||||||
| 
 | 
 | ||||||
| Control:	In general if there is active maintainance of a driver by | Control:	In general if there is active maintenance of a driver by | ||||||
| 		the author then patches will be redirected to them unless | 		the author then patches will be redirected to them unless | ||||||
| 		they are totally obvious and without need of checking. | 		they are totally obvious and without need of checking. | ||||||
| 		If you want to be the contact and update point for the | 		If you want to be the contact and update point for the | ||||||
|  |  | ||||||
|  | @ -729,7 +729,7 @@ Linus Torvalds's mail on the canonical patch format: | ||||||
|   <http://lkml.org/lkml/2005/4/7/183> |   <http://lkml.org/lkml/2005/4/7/183> | ||||||
| 
 | 
 | ||||||
| Andi Kleen, "On submitting kernel patches" | Andi Kleen, "On submitting kernel patches" | ||||||
|   Some strategies to get difficult or controversal changes in. |   Some strategies to get difficult or controversial changes in. | ||||||
|   http://halobates.de/on-submitting-patches.pdf |   http://halobates.de/on-submitting-patches.pdf | ||||||
| 
 | 
 | ||||||
| -- | -- | ||||||
|  |  | ||||||
|  | @ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips: | ||||||
| - Timers (watchdog, OS) | - Timers (watchdog, OS) | ||||||
| 
 | 
 | ||||||
| The following components of the chips are not supported by Linux and | The following components of the chips are not supported by Linux and | ||||||
| require the use of Intel's propietary CSR softare: | require the use of Intel's proprietary CSR softare: | ||||||
| 
 | 
 | ||||||
| - USB device interface | - USB device interface | ||||||
| - Network interfaces (HSS, Utopia, NPEs, etc) | - Network interfaces (HSS, Utopia, NPEs, etc) | ||||||
|  | @ -47,7 +47,7 @@ software from: | ||||||
| 
 | 
 | ||||||
|    http://developer.intel.com/design/network/products/npfamily/ixp425.htm     |    http://developer.intel.com/design/network/products/npfamily/ixp425.htm     | ||||||
| 
 | 
 | ||||||
| DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY | DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY | ||||||
| SOFTWARE. | SOFTWARE. | ||||||
| 
 | 
 | ||||||
| There are several websites that provide directions/pointers on using | There are several websites that provide directions/pointers on using | ||||||
|  |  | ||||||
|  | @ -116,7 +116,7 @@ Configuration | ||||||
|     Allows the entire memory to be checksummed before and after the |     Allows the entire memory to be checksummed before and after the | ||||||
|     suspend to see if there has been any corruption of the contents. |     suspend to see if there has been any corruption of the contents. | ||||||
| 
 | 
 | ||||||
|     Note, the time to calculate the CRC is dependant on the CPU speed |     Note, the time to calculate the CRC is dependent on the CPU speed | ||||||
|     and the size of memory. For an 64Mbyte RAM area on an 200MHz |     and the size of memory. For an 64Mbyte RAM area on an 200MHz | ||||||
|     S3C2410, this can take approximately 4 seconds to complete. |     S3C2410, this can take approximately 4 seconds to complete. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -5,7 +5,7 @@ Introduction | ||||||
| ------------ | ------------ | ||||||
| 
 | 
 | ||||||
| This outlines the Samsung GPIO implementation and the architecture | This outlines the Samsung GPIO implementation and the architecture | ||||||
| specfic calls provided alongisde the drivers/gpio core. | specific calls provided alongisde the drivers/gpio core. | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| S3C24XX (Legacy) | S3C24XX (Legacy) | ||||||
|  |  | ||||||
|  | @ -110,22 +110,22 @@ university server with various users - students, professors, system | ||||||
| tasks etc. The resource planning for this server could be along the | tasks etc. The resource planning for this server could be along the | ||||||
| following lines: | following lines: | ||||||
| 
 | 
 | ||||||
|        CPU :           Top cpuset |        CPU :          "Top cpuset" | ||||||
|                        /       \ |                        /       \ | ||||||
|                CPUSet1         CPUSet2 |                CPUSet1         CPUSet2 | ||||||
|                   |               | |                   |               | | ||||||
|                (Profs)         (Students) |                (Professors)    (Students) | ||||||
| 
 | 
 | ||||||
|                In addition (system tasks) are attached to topcpuset (so |                In addition (system tasks) are attached to topcpuset (so | ||||||
|                that they can run anywhere) with a limit of 20% |                that they can run anywhere) with a limit of 20% | ||||||
| 
 | 
 | ||||||
|        Memory : Professors (50%), students (30%), system (20%) |        Memory : Professors (50%), Students (30%), system (20%) | ||||||
| 
 | 
 | ||||||
|        Disk : Prof (50%), students (30%), system (20%) |        Disk : Professors (50%), Students (30%), system (20%) | ||||||
| 
 | 
 | ||||||
|        Network : WWW browsing (20%), Network File System (60%), others (20%) |        Network : WWW browsing (20%), Network File System (60%), others (20%) | ||||||
|                                / \ |                                / \ | ||||||
|                        Prof (15%) students (5%) |                Professors (15%)  students (5%) | ||||||
| 
 | 
 | ||||||
| Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go | Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go | ||||||
| into NFS network class. | into NFS network class. | ||||||
|  |  | ||||||
|  | @ -196,7 +196,7 @@ the state as 0 when a cpu if offline and 1 when its online. | ||||||
| 	#To display the current cpu state. | 	#To display the current cpu state. | ||||||
| 	#cat /sys/devices/system/cpu/cpuX/online | 	#cat /sys/devices/system/cpu/cpuX/online | ||||||
| 
 | 
 | ||||||
| Q: Why cant i remove CPU0 on some systems? | Q: Why can't i remove CPU0 on some systems? | ||||||
| A: Some architectures may have some special dependency on a certain CPU. | A: Some architectures may have some special dependency on a certain CPU. | ||||||
| 
 | 
 | ||||||
| For e.g in IA64 platforms we have ability to sent platform interrupts to the | For e.g in IA64 platforms we have ability to sent platform interrupts to the | ||||||
|  |  | ||||||
|  | @ -62,7 +62,7 @@ image file and then arrange all these packets back to back in to one single | ||||||
| file. | file. | ||||||
| This file is then copied to /sys/class/firmware/dell_rbu/data. | This file is then copied to /sys/class/firmware/dell_rbu/data. | ||||||
| Once this file gets to the driver, the driver extracts packet_size data from | Once this file gets to the driver, the driver extracts packet_size data from | ||||||
| the file and spreads it accross the physical memory in contiguous packet_sized | the file and spreads it across the physical memory in contiguous packet_sized | ||||||
| space. | space. | ||||||
| This method makes sure that all the packets get to the driver in a single operation. | This method makes sure that all the packets get to the driver in a single operation. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -37,7 +37,7 @@ Algorithm | ||||||
| ========= | ========= | ||||||
| 
 | 
 | ||||||
| dm-service-time adds the I/O size to 'in-flight-size' when the I/O is | dm-service-time adds the I/O size to 'in-flight-size' when the I/O is | ||||||
| dispatched and substracts when completed. | dispatched and subtracts when completed. | ||||||
| Basically, dm-service-time selects a path having minimum service time | Basically, dm-service-time selects a path having minimum service time | ||||||
| which is calculated by: | which is calculated by: | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -18,9 +18,9 @@ Optional properties: | ||||||
| - edid : verbatim EDID data block describing attached display. | - edid : verbatim EDID data block describing attached display. | ||||||
|   Data from the detailed timing descriptor will be used to |   Data from the detailed timing descriptor will be used to | ||||||
|   program the display controller. |   program the display controller. | ||||||
| - little-endian: availiable on big endian systems, to | - little-endian: available on big endian systems, to | ||||||
|   set different foreign endian. |   set different foreign endian. | ||||||
| - big-endian: availiable on little endian systems, to | - big-endian: available on little endian systems, to | ||||||
|   set different foreign endian. |   set different foreign endian. | ||||||
| 
 | 
 | ||||||
| Example for MPC5200: | Example for MPC5200: | ||||||
|  |  | ||||||
|  | @ -15,7 +15,7 @@ Optional properties: | ||||||
| - gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins | - gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins | ||||||
| 	(R/B#). For multi-chip devices, "n" GPIO definitions are required | 	(R/B#). For multi-chip devices, "n" GPIO definitions are required | ||||||
| 	according to the number of chips. | 	according to the number of chips. | ||||||
| - chip-delay : chip dependent delay for transfering data from array to | - chip-delay : chip dependent delay for transferring data from array to | ||||||
| 	read registers (tR). Required if property "gpios" is not used | 	read registers (tR). Required if property "gpios" is not used | ||||||
| 	(R/B# pins not connected). | 	(R/B# pins not connected). | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -39,7 +39,7 @@ Optional properties: | ||||||
| 
 | 
 | ||||||
| - nxp,no-comparator-bypass : Allows to disable the CAN input comperator. | - nxp,no-comparator-bypass : Allows to disable the CAN input comperator. | ||||||
| 
 | 
 | ||||||
| For futher information, please have a look to the SJA1000 data sheet. | For further information, please have a look to the SJA1000 data sheet. | ||||||
| 
 | 
 | ||||||
| Examples: | Examples: | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -199,7 +199,7 @@ EXAMPLE 4 | ||||||
| 
 | 
 | ||||||
| EXAMPLE 5 | EXAMPLE 5 | ||||||
| 	/* | 	/* | ||||||
| 	 * Definition of an error interrupt (interupt type 1). | 	 * Definition of an error interrupt (interrupt type 1). | ||||||
| 	 * SoC interrupt number is 16 and the specific error | 	 * SoC interrupt number is 16 and the specific error | ||||||
|          * interrupt bit in the error interrupt summary register |          * interrupt bit in the error interrupt summary register | ||||||
| 	 * is 23. | 	 * is 23. | ||||||
|  |  | ||||||
|  | @ -138,7 +138,7 @@ and properties to be present. This will be described in detail in | ||||||
| section III, but, for example, the kernel does not require you to | section III, but, for example, the kernel does not require you to | ||||||
| create a node for every PCI device in the system. It is a requirement | create a node for every PCI device in the system. It is a requirement | ||||||
| to have a node for PCI host bridges in order to provide interrupt | to have a node for PCI host bridges in order to provide interrupt | ||||||
| routing informations and memory/IO ranges, among others. It is also | routing information and memory/IO ranges, among others. It is also | ||||||
| recommended to define nodes for on chip devices and other buses that | recommended to define nodes for on chip devices and other buses that | ||||||
| don't specifically fit in an existing OF specification. This creates a | don't specifically fit in an existing OF specification. This creates a | ||||||
| great flexibility in the way the kernel can then probe those and match | great flexibility in the way the kernel can then probe those and match | ||||||
|  | @ -385,7 +385,7 @@ struct boot_param_header { | ||||||
|      among others, by kexec. If you are on an SMP system, this value |      among others, by kexec. If you are on an SMP system, this value | ||||||
|      should match the content of the "reg" property of the CPU node in |      should match the content of the "reg" property of the CPU node in | ||||||
|      the device-tree corresponding to the CPU calling the kernel entry |      the device-tree corresponding to the CPU calling the kernel entry | ||||||
|      point (see further chapters for more informations on the required |      point (see further chapters for more information on the required | ||||||
|      device-tree contents) |      device-tree contents) | ||||||
| 
 | 
 | ||||||
|    - size_dt_strings |    - size_dt_strings | ||||||
|  | @ -553,7 +553,7 @@ looks like in practice. | ||||||
| 
 | 
 | ||||||
| This tree is almost a minimal tree. It pretty much contains the | This tree is almost a minimal tree. It pretty much contains the | ||||||
| minimal set of required nodes and properties to boot a linux kernel; | minimal set of required nodes and properties to boot a linux kernel; | ||||||
| that is, some basic model informations at the root, the CPUs, and the | that is, some basic model information at the root, the CPUs, and the | ||||||
| physical memory layout.  It also includes misc information passed | physical memory layout.  It also includes misc information passed | ||||||
| through /chosen, like in this example, the platform type (mandatory) | through /chosen, like in this example, the platform type (mandatory) | ||||||
| and the kernel command line arguments (optional). | and the kernel command line arguments (optional). | ||||||
|  |  | ||||||
|  | @ -138,7 +138,7 @@ Hotplug is able to load the driver, when it is needed (because you plugged | ||||||
| in the device). | in the device). | ||||||
| 
 | 
 | ||||||
| If you want to enable debug output, you have to load the driver manually and | If you want to enable debug output, you have to load the driver manually and | ||||||
| from withing the dvb-kernel cvs repository. | from within the dvb-kernel cvs repository. | ||||||
| 
 | 
 | ||||||
| first have a look, which debug level are available: | first have a look, which debug level are available: | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -47,7 +47,7 @@ so on. | ||||||
| 
 | 
 | ||||||
| * CI modules that are supported | * CI modules that are supported | ||||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||||
| The CI module support is largely dependant upon the firmware on the cards | The CI module support is largely dependent upon the firmware on the cards | ||||||
| Some cards do support almost all of the available CI modules. There is | Some cards do support almost all of the available CI modules. There is | ||||||
| nothing much that can be done in order to make additional CI modules | nothing much that can be done in order to make additional CI modules | ||||||
| working with these cards. | working with these cards. | ||||||
|  |  | ||||||
|  | @ -106,7 +106,7 @@ Some very frequently asked questions about linuxtv-dvb | ||||||
| 5. The dvb_net device doesn't give me any packets at all | 5. The dvb_net device doesn't give me any packets at all | ||||||
| 
 | 
 | ||||||
| 	Run tcpdump on the dvb0_0 interface. This sets the interface | 	Run tcpdump on the dvb0_0 interface. This sets the interface | ||||||
| 	into promiscous mode so it accepts any packets from the PID | 	into promiscuous mode so it accepts any packets from the PID | ||||||
| 	you have configured with the dvbnet utility. Check if there | 	you have configured with the dvbnet utility. Check if there | ||||||
| 	are any packets with the IP addr and MAC addr you have | 	are any packets with the IP addr and MAC addr you have | ||||||
| 	configured with ifconfig. | 	configured with ifconfig. | ||||||
|  |  | ||||||
|  | @ -1,7 +1,7 @@ | ||||||
| The DVB subsystem currently registers to the sysfs subsystem using the | The DVB subsystem currently registers to the sysfs subsystem using the | ||||||
| "class_simple" interface. | "class_simple" interface. | ||||||
| 
 | 
 | ||||||
| This means that only the basic informations like module loading parameters | This means that only the basic information like module loading parameters | ||||||
| are presented through sysfs. Other things that might be interesting are | are presented through sysfs. Other things that might be interesting are | ||||||
| currently *not* available. | currently *not* available. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -311,7 +311,7 @@ Total Correctable Errors count attribute file: | ||||||
| 	'ce_noinfo_count' | 	'ce_noinfo_count' | ||||||
| 
 | 
 | ||||||
| 	This attribute file displays the number of CEs that | 	This attribute file displays the number of CEs that | ||||||
| 	have occurred wherewith no informations as to which DIMM slot | 	have occurred wherewith no information as to which DIMM slot | ||||||
| 	is having errors. Memory is handicapped, but operational, | 	is having errors. Memory is handicapped, but operational, | ||||||
| 	yet no information is available to indicate which slot | 	yet no information is available to indicate which slot | ||||||
| 	the failing memory is in. This count field should be also | 	the failing memory is in. This count field should be also | ||||||
|  | @ -741,7 +741,7 @@ were done at i7core_edac driver. This chapter will cover those differences | ||||||
|    As EDAC API maps the minimum unity is csrows, the driver sequencially |    As EDAC API maps the minimum unity is csrows, the driver sequencially | ||||||
|    maps channel/dimm into different csrows. |    maps channel/dimm into different csrows. | ||||||
| 
 | 
 | ||||||
|    For example, suposing the following layout: |    For example, supposing the following layout: | ||||||
| 	Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs | 	Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs | ||||||
| 	  dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400 | 	  dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400 | ||||||
| 	  dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400 | 	  dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400 | ||||||
|  |  | ||||||
|  | @ -84,7 +84,7 @@ struct eisa_driver { | ||||||
| 
 | 
 | ||||||
| id_table	: an array of NULL terminated EISA id strings, | id_table	: an array of NULL terminated EISA id strings, | ||||||
| 		  followed by an empty string. Each string can | 		  followed by an empty string. Each string can | ||||||
| 		  optionally be paired with a driver-dependant value | 		  optionally be paired with a driver-dependent value | ||||||
| 		  (driver_data). | 		  (driver_data). | ||||||
| 
 | 
 | ||||||
| driver		: a generic driver, such as described in | driver		: a generic driver, such as described in | ||||||
|  |  | ||||||
|  | @ -204,7 +204,7 @@ Notes: | ||||||
| 
 | 
 | ||||||
|     supported_output_devices |     supported_output_devices | ||||||
| 
 | 
 | ||||||
|         This read-only file contains a full ',' seperated list containing all |         This read-only file contains a full ',' separated list containing all | ||||||
|         output devices that could be available on your platform. It is likely |         output devices that could be available on your platform. It is likely | ||||||
|         that not all of those have a connector on your hardware but it should |         that not all of those have a connector on your hardware but it should | ||||||
|         provide a good starting point to figure out which of those names match |         provide a good starting point to figure out which of those names match | ||||||
|  | @ -225,7 +225,7 @@ Notes: | ||||||
|         This can happen for example if only one (the other) iga is used. |         This can happen for example if only one (the other) iga is used. | ||||||
|         Writing to these files allows adjusting the output devices during |         Writing to these files allows adjusting the output devices during | ||||||
|         runtime. One can add new devices, remove existing ones or switch |         runtime. One can add new devices, remove existing ones or switch | ||||||
|         between igas. Essentially you can write a ',' seperated list of device |         between igas. Essentially you can write a ',' separated list of device | ||||||
|         names (or a single one) in the same format as the output to those |         names (or a single one) in the same format as the output to those | ||||||
|         files. You can add a '+' or '-' as a prefix allowing simple addition |         files. You can add a '+' or '-' as a prefix allowing simple addition | ||||||
|         and removal of devices. So a prefix '+' adds the devices from your list |         and removal of devices. So a prefix '+' adds the devices from your list | ||||||
|  |  | ||||||
|  | @ -309,7 +309,7 @@ ioctlfd field set to the descriptor obtained from the open call. | ||||||
| AUTOFS_DEV_IOCTL_TIMEOUT_CMD | AUTOFS_DEV_IOCTL_TIMEOUT_CMD | ||||||
| ---------------------------- | ---------------------------- | ||||||
| 
 | 
 | ||||||
| Set the expire timeout for mounts withing an autofs mount point. | Set the expire timeout for mounts within an autofs mount point. | ||||||
| 
 | 
 | ||||||
| The call requires an initialized struct autofs_dev_ioctl with the | The call requires an initialized struct autofs_dev_ioctl with the | ||||||
| ioctlfd field set to the descriptor obtained from the open call. | ioctlfd field set to the descriptor obtained from the open call. | ||||||
|  |  | ||||||
|  | @ -95,7 +95,7 @@ restraints as possible on how an index is structured and where it is placed in | ||||||
| the tree.  The netfs can even mix indices and data files at the same level, but | the tree.  The netfs can even mix indices and data files at the same level, but | ||||||
| it's not recommended. | it's not recommended. | ||||||
| 
 | 
 | ||||||
| Each index entry consists of a key of indeterminate length plus some auxilliary | Each index entry consists of a key of indeterminate length plus some auxiliary | ||||||
| data, also of indeterminate length. | data, also of indeterminate length. | ||||||
| 
 | 
 | ||||||
| There are some limits on indices: | There are some limits on indices: | ||||||
|  | @ -203,23 +203,23 @@ This has the following fields: | ||||||
| 
 | 
 | ||||||
|      If the function is absent, a file size of 0 is assumed. |      If the function is absent, a file size of 0 is assumed. | ||||||
| 
 | 
 | ||||||
|  (6) A function to retrieve auxilliary data from the netfs [optional]. |  (6) A function to retrieve auxiliary data from the netfs [optional]. | ||||||
| 
 | 
 | ||||||
|      This function will be called with the netfs data that was passed to the |      This function will be called with the netfs data that was passed to the | ||||||
|      cookie acquisition function and the maximum length of auxilliary data that |      cookie acquisition function and the maximum length of auxiliary data that | ||||||
|      it may provide.  It should write the auxilliary data into the given buffer |      it may provide.  It should write the auxiliary data into the given buffer | ||||||
|      and return the quantity it wrote. |      and return the quantity it wrote. | ||||||
| 
 | 
 | ||||||
|      If this function is absent, the auxilliary data length will be set to 0. |      If this function is absent, the auxiliary data length will be set to 0. | ||||||
| 
 | 
 | ||||||
|      The length of the auxilliary data buffer may be dependent on the key |      The length of the auxiliary data buffer may be dependent on the key | ||||||
|      length.  A netfs mustn't rely on being able to provide more than 400 bytes |      length.  A netfs mustn't rely on being able to provide more than 400 bytes | ||||||
|      for both. |      for both. | ||||||
| 
 | 
 | ||||||
|  (7) A function to check the auxilliary data [optional]. |  (7) A function to check the auxiliary data [optional]. | ||||||
| 
 | 
 | ||||||
|      This function will be called to check that a match found in the cache for |      This function will be called to check that a match found in the cache for | ||||||
|      this object is valid.  For instance with AFS it could check the auxilliary |      this object is valid.  For instance with AFS it could check the auxiliary | ||||||
|      data against the data version number returned by the server to determine |      data against the data version number returned by the server to determine | ||||||
|      whether the index entry in a cache is still valid. |      whether the index entry in a cache is still valid. | ||||||
| 
 | 
 | ||||||
|  | @ -232,7 +232,7 @@ This has the following fields: | ||||||
| 	(*) FSCACHE_CHECKAUX_NEEDS_UPDATE	- the entry requires update | 	(*) FSCACHE_CHECKAUX_NEEDS_UPDATE	- the entry requires update | ||||||
| 	(*) FSCACHE_CHECKAUX_OBSOLETE		- the entry should be deleted | 	(*) FSCACHE_CHECKAUX_OBSOLETE		- the entry should be deleted | ||||||
| 
 | 
 | ||||||
|      This function can also be used to extract data from the auxilliary data in |      This function can also be used to extract data from the auxiliary data in | ||||||
|      the cache and copy it into the netfs's structures. |      the cache and copy it into the netfs's structures. | ||||||
| 
 | 
 | ||||||
|  (8) A pair of functions to manage contexts for the completion callback |  (8) A pair of functions to manage contexts for the completion callback | ||||||
|  |  | ||||||
|  | @ -409,7 +409,7 @@ As a consequence of this, default_groups cannot be removed directly via | ||||||
| rmdir(2).  They also are not considered when rmdir(2) on the parent | rmdir(2).  They also are not considered when rmdir(2) on the parent | ||||||
| group is checking for children. | group is checking for children. | ||||||
| 
 | 
 | ||||||
| [Dependant Subsystems] | [Dependent Subsystems] | ||||||
| 
 | 
 | ||||||
| Sometimes other drivers depend on particular configfs items.  For | Sometimes other drivers depend on particular configfs items.  For | ||||||
| example, ocfs2 mounts depend on a heartbeat region item.  If that | example, ocfs2 mounts depend on a heartbeat region item.  If that | ||||||
|  |  | ||||||
|  | @ -97,7 +97,7 @@ Note: More extensive information for getting started with ext4 can be | ||||||
| * Inode allocation using large virtual block groups via flex_bg | * Inode allocation using large virtual block groups via flex_bg | ||||||
| * delayed allocation | * delayed allocation | ||||||
| * large block (up to pagesize) support | * large block (up to pagesize) support | ||||||
| * efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force | * efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force | ||||||
|   the ordering) |   the ordering) | ||||||
| 
 | 
 | ||||||
| [1] Filesystems with a block size of 1k may see a limit imposed by the | [1] Filesystems with a block size of 1k may see a limit imposed by the | ||||||
|  | @ -106,7 +106,7 @@ directory hash tree having a maximum depth of two. | ||||||
| 2.2 Candidate features for future inclusion | 2.2 Candidate features for future inclusion | ||||||
| 
 | 
 | ||||||
| * Online defrag (patches available but not well tested) | * Online defrag (patches available but not well tested) | ||||||
| * reduced mke2fs time via lazy itable initialization in conjuction with | * reduced mke2fs time via lazy itable initialization in conjunction with | ||||||
|   the uninit_bg feature (capability to do this is available in e2fsprogs |   the uninit_bg feature (capability to do this is available in e2fsprogs | ||||||
|   but a kernel thread to do lazy zeroing of unused inode table blocks |   but a kernel thread to do lazy zeroing of unused inode table blocks | ||||||
|   after filesystem is first mounted is required for safety) |   after filesystem is first mounted is required for safety) | ||||||
|  |  | ||||||
|  | @ -62,7 +62,7 @@ be fixed. | ||||||
| 
 | 
 | ||||||
| The REMOVE uevent is generated at the end of an unsuccessful mount | The REMOVE uevent is generated at the end of an unsuccessful mount | ||||||
| or at the end of a umount of the filesystem. All REMOVE uevents will | or at the end of a umount of the filesystem. All REMOVE uevents will | ||||||
| have been preceeded by at least an ADD uevent for the same fileystem, | have been preceded by at least an ADD uevent for the same fileystem, | ||||||
| and unlike the other uevents is generated automatically by the kernel's | and unlike the other uevents is generated automatically by the kernel's | ||||||
| kobject subsystem. | kobject subsystem. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -11,7 +11,7 @@ their I/O so file system consistency is maintained.  One of the nifty | ||||||
| features of GFS is perfect consistency -- changes made to the file system | features of GFS is perfect consistency -- changes made to the file system | ||||||
| on one machine show up immediately on all other machines in the cluster. | on one machine show up immediately on all other machines in the cluster. | ||||||
| 
 | 
 | ||||||
| GFS uses interchangable inter-node locking mechanisms, the currently | GFS uses interchangeable inter-node locking mechanisms, the currently | ||||||
| supported mechanisms are: | supported mechanisms are: | ||||||
| 
 | 
 | ||||||
|   lock_nolock -- allows gfs to be used as a local file system |   lock_nolock -- allows gfs to be used as a local file system | ||||||
|  |  | ||||||
|  | @ -350,7 +350,7 @@ Note the "Should sync?" parameter "nosync" means that the two mirrors are | ||||||
| already in sync which will be the case on a clean shutdown of Windows.  If the | already in sync which will be the case on a clean shutdown of Windows.  If the | ||||||
| mirrors are not clean, you can specify the "sync" option instead of "nosync" | mirrors are not clean, you can specify the "sync" option instead of "nosync" | ||||||
| and the Device-Mapper driver will then copy the entirety of the "Source Device" | and the Device-Mapper driver will then copy the entirety of the "Source Device" | ||||||
| to the "Target Device" or if you specified multipled target devices to all of | to the "Target Device" or if you specified multiple target devices to all of | ||||||
| them. | them. | ||||||
| 
 | 
 | ||||||
| Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1), | Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1), | ||||||
|  |  | ||||||
|  | @ -80,7 +80,7 @@ user_xattr	(*)	Enables Extended User Attributes. | ||||||
| nouser_xattr		Disables Extended User Attributes. | nouser_xattr		Disables Extended User Attributes. | ||||||
| acl			Enables POSIX Access Control Lists support. | acl			Enables POSIX Access Control Lists support. | ||||||
| noacl		(*)	Disables POSIX Access Control Lists support. | noacl		(*)	Disables POSIX Access Control Lists support. | ||||||
| resv_level=2	(*)	Set how agressive allocation reservations will be. | resv_level=2	(*)	Set how aggressive allocation reservations will be. | ||||||
| 			Valid values are between 0 (reservations off) to 8 | 			Valid values are between 0 (reservations off) to 8 | ||||||
| 			(maximum space for reservations). | 			(maximum space for reservations). | ||||||
| dir_resv_level=	(*)	By default, directory reservations will scale with file | dir_resv_level=	(*)	By default, directory reservations will scale with file | ||||||
|  |  | ||||||
|  | @ -42,7 +42,7 @@ Path walking overview | ||||||
| A name string specifies a start (root directory, cwd, fd-relative) and a | A name string specifies a start (root directory, cwd, fd-relative) and a | ||||||
| sequence of elements (directory entry names), which together refer to a path in | sequence of elements (directory entry names), which together refer to a path in | ||||||
| the namespace. A path is represented as a (dentry, vfsmount) tuple. The name | the namespace. A path is represented as a (dentry, vfsmount) tuple. The name | ||||||
| elements are sub-strings, seperated by '/'. | elements are sub-strings, separated by '/'. | ||||||
| 
 | 
 | ||||||
| Name lookups will want to find a particular path that a name string refers to | Name lookups will want to find a particular path that a name string refers to | ||||||
| (usually the final element, or parent of final element). This is done by taking | (usually the final element, or parent of final element). This is done by taking | ||||||
|  | @ -354,7 +354,7 @@ vfstest 24185492        4945    708725(2.9%) 1076136(4.4%)     0        2651 | ||||||
| 
 | 
 | ||||||
| What this shows is that failed rcu-walk lookups, ie. ones that are restarted | What this shows is that failed rcu-walk lookups, ie. ones that are restarted | ||||||
| entirely with ref-walk, are quite rare. Even the "vfstest" case which | entirely with ref-walk, are quite rare. Even the "vfstest" case which | ||||||
| specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to excercise | specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to exercise | ||||||
| such races is not showing a huge amount of restarts. | such races is not showing a huge amount of restarts. | ||||||
| 
 | 
 | ||||||
| Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where | Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where | ||||||
|  |  | ||||||
|  | @ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command | ||||||
| so one can extend protocol as needed without breaking backward compatibility as long | so one can extend protocol as needed without breaking backward compatibility as long | ||||||
| as old commands are supported. All string lengths include tail 0 byte. | as old commands are supported. All string lengths include tail 0 byte. | ||||||
| 
 | 
 | ||||||
| All commans are transfered over the network in big-endian. CPU endianess is used at the end peers. | All commands are transferred over the network in big-endian. CPU endianess is used at the end peers. | ||||||
| 
 | 
 | ||||||
| @cmd - command number, which specifies command to be processed. Following | @cmd - command number, which specifies command to be processed. Following | ||||||
| 	commands are used currently: | 	commands are used currently: | ||||||
|  |  | ||||||
|  | @ -543,7 +543,7 @@ just those considered 'most important'.  The new vectors are: | ||||||
|   their statistics are used by kernel developers and interested users to |   their statistics are used by kernel developers and interested users to | ||||||
|   determine the occurrence of interrupts of the given type. |   determine the occurrence of interrupts of the given type. | ||||||
| 
 | 
 | ||||||
| The above IRQ vectors are displayed only when relevent.  For example, | The above IRQ vectors are displayed only when relevant.  For example, | ||||||
| the threshold vector does not exist on x86_64 platforms.  Others are | the threshold vector does not exist on x86_64 platforms.  Others are | ||||||
| suppressed when the system is a uniprocessor.  As of this writing, only | suppressed when the system is a uniprocessor.  As of this writing, only | ||||||
| i386 and x86_64 platforms support the new IRQ vector displays. | i386 and x86_64 platforms support the new IRQ vector displays. | ||||||
|  | @ -1202,7 +1202,7 @@ The columns are: | ||||||
|                        W = can do write operations |                        W = can do write operations | ||||||
|                        U = can do unblank |                        U = can do unblank | ||||||
|   flags                E = it is enabled |   flags                E = it is enabled | ||||||
|                        C = it is prefered console |                        C = it is preferred console | ||||||
|                        B = it is primary boot console |                        B = it is primary boot console | ||||||
|                        p = it is used for printk buffer |                        p = it is used for printk buffer | ||||||
|                        b = it is not a TTY but a Braille device |                        b = it is not a TTY but a Braille device | ||||||
|  | @ -1331,7 +1331,7 @@ NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see | ||||||
| Documentation/feature-removal-schedule.txt. | Documentation/feature-removal-schedule.txt. | ||||||
| 
 | 
 | ||||||
| Caveat: when a parent task is selected, the oom killer will sacrifice any first | Caveat: when a parent task is selected, the oom killer will sacrifice any first | ||||||
| generation children with seperate address spaces instead, if possible.  This | generation children with separate address spaces instead, if possible.  This | ||||||
| avoids servers and important system daemons from being killed and loses the | avoids servers and important system daemons from being killed and loses the | ||||||
| minimal amount of work. | minimal amount of work. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -219,7 +219,7 @@ or if it is stored out of line (in which case the value field stores a | ||||||
| reference to where the actual value is stored).  This allows large values | reference to where the actual value is stored).  This allows large values | ||||||
| to be stored out of line improving scanning and lookup performance and it | to be stored out of line improving scanning and lookup performance and it | ||||||
| also allows values to be de-duplicated, the value being stored once, and | also allows values to be de-duplicated, the value being stored once, and | ||||||
| all other occurences holding an out of line reference to that value. | all other occurrences holding an out of line reference to that value. | ||||||
| 
 | 
 | ||||||
| The xattr lists are packed into compressed 8K metadata blocks. | The xattr lists are packed into compressed 8K metadata blocks. | ||||||
| To reduce overhead in inodes, rather than storing the on-disk | To reduce overhead in inodes, rather than storing the on-disk | ||||||
|  |  | ||||||
|  | @ -62,7 +62,7 @@ values of the same type. | ||||||
| 
 | 
 | ||||||
| Mixing types, expressing multiple lines of data, and doing fancy | Mixing types, expressing multiple lines of data, and doing fancy | ||||||
| formatting of data is heavily frowned upon. Doing these things may get | formatting of data is heavily frowned upon. Doing these things may get | ||||||
| you publically humiliated and your code rewritten without notice.  | you publicly humiliated and your code rewritten without notice.  | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| An attribute definition is simply: | An attribute definition is simply: | ||||||
|  |  | ||||||
|  | @ -97,7 +97,7 @@ functions: | ||||||
| The passed struct file_system_type describes your filesystem. When a | The passed struct file_system_type describes your filesystem. When a | ||||||
| request is made to mount a filesystem onto a directory in your namespace, | request is made to mount a filesystem onto a directory in your namespace, | ||||||
| the VFS will call the appropriate mount() method for the specific | the VFS will call the appropriate mount() method for the specific | ||||||
| filesystem.  New vfsmount refering to the tree returned by ->mount() | filesystem.  New vfsmount referring to the tree returned by ->mount() | ||||||
| will be attached to the mountpoint, so that when pathname resolution | will be attached to the mountpoint, so that when pathname resolution | ||||||
| reaches the mountpoint it will jump into the root of that vfsmount. | reaches the mountpoint it will jump into the root of that vfsmount. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -42,7 +42,7 @@ the aggregation of all the previous changes currently held only in the log. | ||||||
| This relogging technique also allows objects to be moved forward in the log so | This relogging technique also allows objects to be moved forward in the log so | ||||||
| that an object being relogged does not prevent the tail of the log from ever | that an object being relogged does not prevent the tail of the log from ever | ||||||
| moving forward.  This can be seen in the table above by the changing | moving forward.  This can be seen in the table above by the changing | ||||||
| (increasing) LSN of each subsquent transaction - the LSN is effectively a | (increasing) LSN of each subsequent transaction - the LSN is effectively a | ||||||
| direct encoding of the location in the log of the transaction. | direct encoding of the location in the log of the transaction. | ||||||
| 
 | 
 | ||||||
| This relogging is also used to implement long-running, multiple-commit | This relogging is also used to implement long-running, multiple-commit | ||||||
|  | @ -338,7 +338,7 @@ the same time another transaction modifies the item and inserts the log item | ||||||
| into the new CIL, then checkpoint transaction commit code cannot use log items | into the new CIL, then checkpoint transaction commit code cannot use log items | ||||||
| to store the list of log vectors that need to be written into the transaction. | to store the list of log vectors that need to be written into the transaction. | ||||||
| Hence log vectors need to be able to be chained together to allow them to be | Hence log vectors need to be able to be chained together to allow them to be | ||||||
| detatched from the log items. That is, when the CIL is flushed the memory | detached from the log items. That is, when the CIL is flushed the memory | ||||||
| buffer and log vector attached to each log item needs to be attached to the | buffer and log vector attached to each log item needs to be attached to the | ||||||
| checkpoint context so that the log item can be released. In diagrammatic form, | checkpoint context so that the log item can be released. In diagrammatic form, | ||||||
| the CIL would look like this before the flush: | the CIL would look like this before the flush: | ||||||
|  | @ -577,7 +577,7 @@ only becomes unpinned when all the transactions complete and there are no | ||||||
| pending transactions. Thus the pinning and unpinning of a log item is symmetric | pending transactions. Thus the pinning and unpinning of a log item is symmetric | ||||||
| as there is a 1:1 relationship with transaction commit and log item completion. | as there is a 1:1 relationship with transaction commit and log item completion. | ||||||
| 
 | 
 | ||||||
| For delayed logging, however, we have an assymetric transaction commit to | For delayed logging, however, we have an asymmetric transaction commit to | ||||||
| completion relationship. Every time an object is relogged in the CIL it goes | completion relationship. Every time an object is relogged in the CIL it goes | ||||||
| through the commit process without a corresponding completion being registered. | through the commit process without a corresponding completion being registered. | ||||||
| That is, we now have a many-to-one relationship between transaction commit and | That is, we now have a many-to-one relationship between transaction commit and | ||||||
|  | @ -780,7 +780,7 @@ With delayed logging, there are new steps inserted into the life cycle: | ||||||
| From this, it can be seen that the only life cycle differences between the two | From this, it can be seen that the only life cycle differences between the two | ||||||
| logging methods are in the middle of the life cycle - they still have the same | logging methods are in the middle of the life cycle - they still have the same | ||||||
| beginning and end and execution constraints. The only differences are in the | beginning and end and execution constraints. The only differences are in the | ||||||
| commiting of the log items to the log itself and the completion processing. | committing of the log items to the log itself and the completion processing. | ||||||
| Hence delayed logging should not introduce any constraints on log item | Hence delayed logging should not introduce any constraints on log item | ||||||
| behaviour, allocation or freeing that don't already exist. | behaviour, allocation or freeing that don't already exist. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -78,7 +78,7 @@ motherboards (most modern Abit motherboards). | ||||||
| 
 | 
 | ||||||
| The first and second revision of the uGuru chip in reality is a Winbond | The first and second revision of the uGuru chip in reality is a Winbond | ||||||
| W83L950D in disguise (despite Abit claiming it is "a new microprocessor | W83L950D in disguise (despite Abit claiming it is "a new microprocessor | ||||||
| designed by the ABIT Engineers"). Unfortunatly this doesn't help since the | designed by the ABIT Engineers"). Unfortunately this doesn't help since the | ||||||
| W83L950D is a generic microcontroller with a custom Abit application running | W83L950D is a generic microcontroller with a custom Abit application running | ||||||
| on it. | on it. | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -5,9 +5,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or | ||||||
| datasheet from Abit. The data I have got on uGuru have I assembled through | datasheet from Abit. The data I have got on uGuru have I assembled through | ||||||
| my weak knowledge in "backwards engineering". | my weak knowledge in "backwards engineering". | ||||||
| And just for the record, you may have noticed uGuru isn't a chip developed by | And just for the record, you may have noticed uGuru isn't a chip developed by | ||||||
| Abit, as they claim it to be. It's realy just an microprocessor (uC) created by | Abit, as they claim it to be. It's really just an microprocessor (uC) created by | ||||||
| Winbond (W83L950D). And no, reading the manual for this specific uC or | Winbond (W83L950D). And no, reading the manual for this specific uC or | ||||||
| mailing  Windbond for help won't give any usefull data about uGuru, as it is | mailing  Windbond for help won't give any useful data about uGuru, as it is | ||||||
| the program inside the uC that is responding to calls. | the program inside the uC that is responding to calls. | ||||||
| 
 | 
 | ||||||
| Olle Sandberg <ollebull@gmail.com>, 2005-05-25 | Olle Sandberg <ollebull@gmail.com>, 2005-05-25 | ||||||
|  | @ -41,7 +41,7 @@ later on attached again data-port will hold 0x08, more about this later. | ||||||
| 
 | 
 | ||||||
| After wider testing of the Linux kernel driver some variants of the uGuru have | After wider testing of the Linux kernel driver some variants of the uGuru have | ||||||
| turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also | turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also | ||||||
| have to test CMD for two different values. On these uGuru's DATA will initally | have to test CMD for two different values. On these uGuru's DATA will initially | ||||||
| hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read | hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read | ||||||
| first! | first! | ||||||
| 
 | 
 | ||||||
|  | @ -308,5 +308,5 @@ the voltage / clock programming out, I tried reading and only reading banks | ||||||
| resulted in a _permanent_ reprogramming of the voltages, luckily I had the | resulted in a _permanent_ reprogramming of the voltages, luckily I had the | ||||||
| sensors part configured so that it would shutdown my system on any out of spec | sensors part configured so that it would shutdown my system on any out of spec | ||||||
| voltages which proprably safed my computer (after a reboot I managed to | voltages which proprably safed my computer (after a reboot I managed to | ||||||
| immediatly enter the bios and reload the defaults). This probably means that | immediately enter the bios and reload the defaults). This probably means that | ||||||
| the read/write cycle for the non sensor part is different from the sensor part. | the read/write cycle for the non sensor part is different from the sensor part. | ||||||
|  |  | ||||||
|  | @ -47,7 +47,7 @@ This driver supports the hardware monitoring features of the third revision of | ||||||
| the Abit uGuru chip, found on recent Abit uGuru featuring motherboards. | the Abit uGuru chip, found on recent Abit uGuru featuring motherboards. | ||||||
| 
 | 
 | ||||||
| The 3rd revision of the uGuru chip in reality is a Winbond W83L951G. | The 3rd revision of the uGuru chip in reality is a Winbond W83L951G. | ||||||
| Unfortunatly this doesn't help since the W83L951G is a generic microcontroller | Unfortunately this doesn't help since the W83L951G is a generic microcontroller | ||||||
| with a custom Abit application running on it. | with a custom Abit application running on it. | ||||||
| 
 | 
 | ||||||
| Despite Abit not releasing any information regarding the uGuru revision 3, | Despite Abit not releasing any information regarding the uGuru revision 3, | ||||||
|  |  | ||||||
|  | @ -150,11 +150,11 @@ The following attributes are supported. Limits are read-write; all other | ||||||
| attributes are read-only. | attributes are read-only. | ||||||
| 
 | 
 | ||||||
| inX_input		Measured voltage. From READ_VIN or READ_VOUT register. | inX_input		Measured voltage. From READ_VIN or READ_VOUT register. | ||||||
| inX_min			Minumum Voltage. | inX_min			Minimum Voltage. | ||||||
| 			From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register. | 			From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register. | ||||||
| inX_max			Maximum voltage. | inX_max			Maximum voltage. | ||||||
| 			From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register. | 			From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register. | ||||||
| inX_lcrit		Critical minumum Voltage. | inX_lcrit		Critical minimum Voltage. | ||||||
| 			From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register. | 			From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register. | ||||||
| inX_crit		Critical maximum voltage. | inX_crit		Critical maximum voltage. | ||||||
| 			From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register. | 			From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register. | ||||||
|  | @ -169,7 +169,7 @@ inX_label		"vin", "vcap", or "voutY" | ||||||
| currX_input		Measured current. From READ_IIN or READ_IOUT register. | currX_input		Measured current. From READ_IIN or READ_IOUT register. | ||||||
| currX_max		Maximum current. | currX_max		Maximum current. | ||||||
| 			From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register. | 			From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register. | ||||||
| currX_lcrit		Critical minumum output current. | currX_lcrit		Critical minimum output current. | ||||||
| 			From IOUT_UC_FAULT_LIMIT register. | 			From IOUT_UC_FAULT_LIMIT register. | ||||||
| currX_crit		Critical maximum current. | currX_crit		Critical maximum current. | ||||||
| 			From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register. | 			From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register. | ||||||
|  |  | ||||||
|  | @ -579,7 +579,7 @@ channel should not be trusted. | ||||||
| fan[1-*]_fault | fan[1-*]_fault | ||||||
| temp[1-*]_fault | temp[1-*]_fault | ||||||
| 		Input fault condition | 		Input fault condition | ||||||
| 		0: no fault occured | 		0: no fault occurred | ||||||
| 		1: fault condition | 		1: fault condition | ||||||
| 		RO | 		RO | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -403,7 +403,7 @@ found out the following values do work as a form of coarse pwm: | ||||||
| 
 | 
 | ||||||
| 0x80 - seems to turn fans off after some time(1-2 minutes)... might be | 0x80 - seems to turn fans off after some time(1-2 minutes)... might be | ||||||
| some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an | some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an | ||||||
| old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan | old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan | ||||||
| that was dropped at the BIOS) | that was dropped at the BIOS) | ||||||
| 0x81 - off | 0x81 - off | ||||||
| 0x82 - slightly "on-ner" than off, but my fans do not get to move. I can | 0x82 - slightly "on-ner" than off, but my fans do not get to move. I can | ||||||
|  |  | ||||||
|  | @ -93,7 +93,7 @@ The sysfs interface to the beep bitmask has migrated from the original legacy | ||||||
| method of a single sysfs beep_mask file to a newer method using multiple | method of a single sysfs beep_mask file to a newer method using multiple | ||||||
| *_beep files as described in .../Documentation/hwmon/sysfs-interface. | *_beep files as described in .../Documentation/hwmon/sysfs-interface. | ||||||
| 
 | 
 | ||||||
| A similar change has occured for the bitmap corresponding to the alarms. The | A similar change has occurred for the bitmap corresponding to the alarms. The | ||||||
| original legacy method used a single sysfs alarms file containing a bitmap | original legacy method used a single sysfs alarms file containing a bitmap | ||||||
| of triggered alarms. The newer method uses multiple sysfs *_alarm files | of triggered alarms. The newer method uses multiple sysfs *_alarm files | ||||||
| (again following the pattern described in sysfs-interface). | (again following the pattern described in sysfs-interface). | ||||||
|  |  | ||||||
|  | @ -4,7 +4,7 @@ Author: Jean Delvare <khali@linux-fr.org> | ||||||
| 
 | 
 | ||||||
| This driver is a light version of i2c-parport. It doesn't depend         | This driver is a light version of i2c-parport. It doesn't depend         | ||||||
| on the parport driver, and uses direct I/O access instead. This might be | on the parport driver, and uses direct I/O access instead. This might be | ||||||
| prefered on embedded systems where wasting memory for the clean but heavy | preferred on embedded systems where wasting memory for the clean but heavy | ||||||
| parport handling is not an option. The drawback is a reduced portability | parport handling is not an option. The drawback is a reduced portability | ||||||
| and the impossibility to daisy-chain other parallel port devices.                  | and the impossibility to daisy-chain other parallel port devices.                  | ||||||
|    |    | ||||||
|  |  | ||||||
|  | @ -35,7 +35,7 @@ or perhaps this... | ||||||
| 
 | 
 | ||||||
| (kernel versions later than 2.4.18 may fill in the "Unknown"s) | (kernel versions later than 2.4.18 may fill in the "Unknown"s) | ||||||
| 
 | 
 | ||||||
| If you cant see it please look on quirk_sis_96x_smbus | If you can't see it please look on quirk_sis_96x_smbus | ||||||
| (drivers/pci/quirks.c) (also if southbridge detection fails) | (drivers/pci/quirks.c) (also if southbridge detection fails) | ||||||
| 
 | 
 | ||||||
| I suspect that this driver could be made to work for the following SiS | I suspect that this driver could be made to work for the following SiS | ||||||
|  |  | ||||||
|  | @ -13,7 +13,7 @@ Currently supported devices are: | ||||||
| 
 | 
 | ||||||
| * TAOS TSL2550 EVM | * TAOS TSL2550 EVM | ||||||
| 
 | 
 | ||||||
| For addtional information on TAOS products, please see | For additional information on TAOS products, please see | ||||||
|   http://www.taosinc.com/ |   http://www.taosinc.com/ | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -53,7 +53,7 @@ Symbios Logic (Now LSI) | ||||||
| BoxHill Corporation | BoxHill Corporation | ||||||
| 	Loan of initial FibreChannel disk array used for development work. | 	Loan of initial FibreChannel disk array used for development work. | ||||||
| 
 | 
 | ||||||
| European Comission | European Commission | ||||||
| 	Funding the work done by the University of Helsinki | 	Funding the work done by the University of Helsinki | ||||||
| 
 | 
 | ||||||
| SysKonnect | SysKonnect | ||||||
|  |  | ||||||
|  | @ -177,7 +177,7 @@ static int scan_rom(char *path, char *file) | ||||||
| 
 | 
 | ||||||
| 			/*
 | 			/*
 | ||||||
| 			 * It's OK if the ROM is unreadable.  Maybe there | 			 * It's OK if the ROM is unreadable.  Maybe there | ||||||
| 			 * is no ROM, or some other error ocurred.  The | 			 * is no ROM, or some other error occurred.  The | ||||||
| 			 * important thing is that no MCA happened. | 			 * important thing is that no MCA happened. | ||||||
| 			 */ | 			 */ | ||||||
| 			if (rc > 0) | 			if (rc > 0) | ||||||
|  |  | ||||||
|  | @ -272,7 +272,7 @@ if you want to use gamecon.c. | ||||||
| 
 | 
 | ||||||
|   Also, the connection is a bit more complex. You'll need a bunch of diodes, |   Also, the connection is a bit more complex. You'll need a bunch of diodes, | ||||||
| and one pullup resistor. First, you connect the Directions and the button | and one pullup resistor. First, you connect the Directions and the button | ||||||
| the same as for db9, however with the diodes inbetween. | the same as for db9, however with the diodes between. | ||||||
| 
 | 
 | ||||||
| 	    Diodes | 	    Diodes | ||||||
| (pin 2) -----|<|----> Up | (pin 2) -----|<|----> Up | ||||||
|  |  | ||||||
|  | @ -46,7 +46,7 @@ c) Falling edge on channel A, channel B in high state | ||||||
| 
 | 
 | ||||||
| d) Falling edge on channel B, channel A in low state | d) Falling edge on channel B, channel A in low state | ||||||
| 	Parking position. If the encoder enters this state, a full transition | 	Parking position. If the encoder enters this state, a full transition | ||||||
| 	should have happend, unless it flipped back on half the way. The | 	should have happened, unless it flipped back on half the way. The | ||||||
| 	'armed' state tells us about that. | 	'armed' state tells us about that. | ||||||
| 
 | 
 | ||||||
| 2. Platform requirements | 2. Platform requirements | ||||||
|  |  | ||||||
|  | @ -77,7 +77,7 @@ pulse length: | ||||||
| 
 | 
 | ||||||
| 24 bin+oct values + 1 bin value = 24*4+1 bits  = 97 bits | 24 bin+oct values + 1 bin value = 24*4+1 bits  = 97 bits | ||||||
| 
 | 
 | ||||||
| (Warning, pulses on ACK ar inverted by transistor, irq is rised up on sync | (Warning, pulses on ACK are inverted by transistor, irq is raised up on sync | ||||||
| to bin change or octal value to bin change). | to bin change or octal value to bin change). | ||||||
| 
 | 
 | ||||||
| Binary data representations: | Binary data representations: | ||||||
|  |  | ||||||
|  | @ -53,5 +53,5 @@ implementation in an architecture: lockdep will detect that and will | ||||||
| turn itself off. I.e. the lock validator will still be reliable. There | turn itself off. I.e. the lock validator will still be reliable. There | ||||||
| should be no crashes due to irq-tracing bugs. (except if the assembly | should be no crashes due to irq-tracing bugs. (except if the assembly | ||||||
| changes break other code by modifying conditions or registers that | changes break other code by modifying conditions or registers that | ||||||
| shouldnt be) | shouldn't be) | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -240,7 +240,7 @@ Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert | ||||||
| messages between their transport encoding described in the CAPI 2.0 standard | messages between their transport encoding described in the CAPI 2.0 standard | ||||||
| and their _cmsg structure representation. Note that capi_cmsg2message() does | and their _cmsg structure representation. Note that capi_cmsg2message() does | ||||||
| not know or check the size of its destination buffer. The caller must make | not know or check the size of its destination buffer. The caller must make | ||||||
| sure it is big enough to accomodate the resulting CAPI message. | sure it is big enough to accommodate the resulting CAPI message. | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| 5. Lower Layer Interface Functions | 5. Lower Layer Interface Functions | ||||||
|  |  | ||||||
|  | @ -26,11 +26,11 @@ Additional options to the assembler (for built-in and modules). | ||||||
| 
 | 
 | ||||||
| AFLAGS_MODULE | AFLAGS_MODULE | ||||||
| -------------------------------------------------- | -------------------------------------------------- | ||||||
| Addtional module specific options to use for $(AS). | Additional module specific options to use for $(AS). | ||||||
| 
 | 
 | ||||||
| AFLAGS_KERNEL | AFLAGS_KERNEL | ||||||
| -------------------------------------------------- | -------------------------------------------------- | ||||||
| Addtional options for $(AS) when used for assembler | Additional options for $(AS) when used for assembler | ||||||
| code for code that is compiled as built-in. | code for code that is compiled as built-in. | ||||||
| 
 | 
 | ||||||
| KCFLAGS | KCFLAGS | ||||||
|  | @ -39,12 +39,12 @@ Additional options to the C compiler (for built-in and modules). | ||||||
| 
 | 
 | ||||||
| CFLAGS_KERNEL | CFLAGS_KERNEL | ||||||
| -------------------------------------------------- | -------------------------------------------------- | ||||||
| Addtional options for $(CC) when used to compile | Additional options for $(CC) when used to compile | ||||||
| code that is compiled as built-in. | code that is compiled as built-in. | ||||||
| 
 | 
 | ||||||
| CFLAGS_MODULE | CFLAGS_MODULE | ||||||
| -------------------------------------------------- | -------------------------------------------------- | ||||||
| Addtional module specific options to use for $(CC). | Additional module specific options to use for $(CC). | ||||||
| 
 | 
 | ||||||
| LDFLAGS_MODULE | LDFLAGS_MODULE | ||||||
| -------------------------------------------------- | -------------------------------------------------- | ||||||
|  |  | ||||||
|  | @ -699,7 +699,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | ||||||
| 	ekgdboc=	[X86,KGDB] Allow early kernel console debugging | 	ekgdboc=	[X86,KGDB] Allow early kernel console debugging | ||||||
| 			ekgdboc=kbd | 			ekgdboc=kbd | ||||||
| 
 | 
 | ||||||
| 			This is desgined to be used in conjunction with | 			This is designed to be used in conjunction with | ||||||
| 			the boot argument: earlyprintk=vga | 			the boot argument: earlyprintk=vga | ||||||
| 
 | 
 | ||||||
| 	edd=		[EDD] | 	edd=		[EDD] | ||||||
|  | @ -1832,15 +1832,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | ||||||
| 				perfmon on Intel CPUs instead of the | 				perfmon on Intel CPUs instead of the | ||||||
| 				CPU specific event set. | 				CPU specific event set. | ||||||
| 
 | 
 | ||||||
| 	oops=panic	Always panic on oopses. Default is to just kill the process, | 	oops=panic	Always panic on oopses. Default is to just kill the | ||||||
| 			but there is a small probability of deadlocking the machine. | 			process, but there is a small probability of | ||||||
|  | 			deadlocking the machine. | ||||||
| 			This will also cause panics on machine check exceptions. | 			This will also cause panics on machine check exceptions. | ||||||
| 			Useful together with panic=30 to trigger a reboot. | 			Useful together with panic=30 to trigger a reboot. | ||||||
| 
 | 
 | ||||||
| 	OSS		[HW,OSS] | 	OSS		[HW,OSS] | ||||||
| 			See Documentation/sound/oss/oss-parameters.txt | 			See Documentation/sound/oss/oss-parameters.txt | ||||||
| 
 | 
 | ||||||
| 	panic=		[KNL] Kernel behaviour on panic | 	panic=		[KNL] Kernel behaviour on panic: delay <timeout> | ||||||
|  | 			seconds before rebooting | ||||||
| 			Format: <timeout> | 			Format: <timeout> | ||||||
| 
 | 
 | ||||||
| 	parkbd.port=	[HW] Parallel port number the keyboard adapter is | 	parkbd.port=	[HW] Parallel port number the keyboard adapter is | ||||||
|  | @ -2343,6 +2345,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | ||||||
| 
 | 
 | ||||||
| 	softlockup_panic= | 	softlockup_panic= | ||||||
| 			[KNL] Should the soft-lockup detector generate panics. | 			[KNL] Should the soft-lockup detector generate panics. | ||||||
|  | 			Format: <integer> | ||||||
| 
 | 
 | ||||||
| 	sonypi.*=	[HW] Sony Programmable I/O Control Device driver | 	sonypi.*=	[HW] Sony Programmable I/O Control Device driver | ||||||
| 			See Documentation/sonypi.txt | 			See Documentation/sonypi.txt | ||||||
|  | @ -2475,8 +2478,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | ||||||
| 	topology=	[S390] | 	topology=	[S390] | ||||||
| 			Format: {off | on} | 			Format: {off | on} | ||||||
| 			Specify if the kernel should make use of the cpu | 			Specify if the kernel should make use of the cpu | ||||||
| 			topology informations if the hardware supports these. | 			topology information if the hardware supports this. | ||||||
| 			The scheduler will make use of these informations and | 			The scheduler will make use of this information and | ||||||
| 			e.g. base its process migration decisions on it. | 			e.g. base its process migration decisions on it. | ||||||
| 			Default is on. | 			Default is on. | ||||||
| 
 | 
 | ||||||
|  | @ -2529,8 +2532,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | ||||||
| 			reported either. | 			reported either. | ||||||
| 
 | 
 | ||||||
| 	unknown_nmi_panic | 	unknown_nmi_panic | ||||||
| 			[X86] | 			[X86] Cause panic on unknown NMI. | ||||||
| 			Set unknown_nmi_panic=1 early on boot. |  | ||||||
| 
 | 
 | ||||||
| 	usbcore.autosuspend= | 	usbcore.autosuspend= | ||||||
| 			[USB] The autosuspend time delay (in seconds) used | 			[USB] The autosuspend time delay (in seconds) used | ||||||
|  |  | ||||||
|  | @ -11,6 +11,7 @@ with the difference that the orphan objects are not freed but only | ||||||
| reported via /sys/kernel/debug/kmemleak. A similar method is used by the | reported via /sys/kernel/debug/kmemleak. A similar method is used by the | ||||||
| Valgrind tool (memcheck --leak-check) to detect the memory leaks in | Valgrind tool (memcheck --leak-check) to detect the memory leaks in | ||||||
| user-space applications. | user-space applications. | ||||||
|  | Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. | ||||||
| 
 | 
 | ||||||
| Usage | Usage | ||||||
| ----- | ----- | ||||||
|  | @ -178,5 +179,4 @@ block doesn't need to be freed (some cases in the init_call functions), | ||||||
| the pointer is calculated by other methods than the usual container_of | the pointer is calculated by other methods than the usual container_of | ||||||
| macro or the pointer is stored in a location not scanned by kmemleak. | macro or the pointer is stored in a location not scanned by kmemleak. | ||||||
| 
 | 
 | ||||||
| Page allocations and ioremap are not tracked. Only the ARM and x86 | Page allocations and ioremap are not tracked. | ||||||
| architectures are currently supported. |  | ||||||
|  |  | ||||||
|  | @ -23,7 +23,7 @@ The mmu code attempts to satisfy the following requirements: | ||||||
|                and framebuffer-based displays |                and framebuffer-based displays | ||||||
| - footprint:   keep the amount of pinned kernel memory low (most memory | - footprint:   keep the amount of pinned kernel memory low (most memory | ||||||
|                should be shrinkable) |                should be shrinkable) | ||||||
| - reliablity:  avoid multipage or GFP_ATOMIC allocations | - reliability:  avoid multipage or GFP_ATOMIC allocations | ||||||
| 
 | 
 | ||||||
| Acronyms | Acronyms | ||||||
| ======== | ======== | ||||||
|  |  | ||||||
|  | @ -136,7 +136,7 @@ Patched instructions | ||||||
| ==================== | ==================== | ||||||
| 
 | 
 | ||||||
| The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions | The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions | ||||||
| respectively on 32 bit systems with an added offset of 4 to accomodate for big | respectively on 32 bit systems with an added offset of 4 to accommodate for big | ||||||
| endianness. | endianness. | ||||||
| 
 | 
 | ||||||
| The following is a list of mapping the Linux kernel performs when running as | The following is a list of mapping the Linux kernel performs when running as | ||||||
|  |  | ||||||
|  | @ -81,7 +81,7 @@ Mode 0: Single Timeout.   This is a one-shot software timeout that counts down | ||||||
|  when the gate is high (always true for timers 0 and 1).  When the count |  when the gate is high (always true for timers 0 and 1).  When the count | ||||||
|  reaches zero, the output goes high. |  reaches zero, the output goes high. | ||||||
| 
 | 
 | ||||||
| Mode 1: Triggered One-shot.  The output is intially set high.  When the gate | Mode 1: Triggered One-shot.  The output is initially set high.  When the gate | ||||||
|  line is set high, a countdown is initiated (which does not stop if the gate is |  line is set high, a countdown is initiated (which does not stop if the gate is | ||||||
|  lowered), during which the output is set low.  When the count reaches zero, |  lowered), during which the output is set low.  When the count reaches zero, | ||||||
|  the output goes high. |  the output goes high. | ||||||
|  |  | ||||||
|  | @ -61,7 +61,7 @@ Usage | ||||||
|   Hotkeys are also reported as input keys (like keyboards) you can check |   Hotkeys are also reported as input keys (like keyboards) you can check | ||||||
|   which key are supported using "xev" under X11. |   which key are supported using "xev" under X11. | ||||||
| 
 | 
 | ||||||
|   You can get informations on the version of your DSDT table by reading the |   You can get information on the version of your DSDT table by reading the | ||||||
|   /sys/devices/platform/asus-laptop/infos entry. If you have a question or a |   /sys/devices/platform/asus-laptop/infos entry. If you have a question or a | ||||||
|   bug report to do, please include the output of this entry. |   bug report to do, please include the output of this entry. | ||||||
| 
 | 
 | ||||||
|  | @ -178,7 +178,7 @@ LED display | ||||||
| ----------- | ----------- | ||||||
| 
 | 
 | ||||||
|   Some models like the W1N have a LED display that can be used to display |   Some models like the W1N have a LED display that can be used to display | ||||||
|   several informations. |   several items of information. | ||||||
| 
 | 
 | ||||||
|   LED display works for the following models: |   LED display works for the following models: | ||||||
|     W1000N |     W1000N | ||||||
|  |  | ||||||
							
								
								
									
										8
									
								
								Documentation/leds/00-INDEX
									
										
									
									
									
										Normal file
									
								
							
							
						
						
									
										8
									
								
								Documentation/leds/00-INDEX
									
										
									
									
									
										Normal file
									
								
							|  | @ -0,0 +1,8 @@ | ||||||
|  | leds-class.txt | ||||||
|  | 	- documents LED handling under Linux. | ||||||
|  | leds-lp3944.txt | ||||||
|  | 	- notes on how to use the leds-lp3944 driver. | ||||||
|  | leds-lp5521.txt | ||||||
|  | 	- notes on how to use the leds-lp5521 driver. | ||||||
|  | leds-lp5523.txt | ||||||
|  | 	- notes on how to use the leds-lp5523 driver. | ||||||
|  | @ -95,4 +95,3 @@ There are a number of cases where a trigger might only be mappable to a | ||||||
| particular LED (ACPI?). The addition of triggers provided by the LED driver | particular LED (ACPI?). The addition of triggers provided by the LED driver | ||||||
| should cover this option and be possible to add without breaking the | should cover this option and be possible to add without breaking the | ||||||
| current interface. | current interface. | ||||||
| 
 |  | ||||||
|  | @ -194,7 +194,7 @@ each pad. | ||||||
| 
 | 
 | ||||||
| Links are represented by a struct media_link instance, defined in | Links are represented by a struct media_link instance, defined in | ||||||
| include/media/media-entity.h. Each entity stores all links originating at or | include/media/media-entity.h. Each entity stores all links originating at or | ||||||
| targetting any of its pads in a links array. A given link is thus stored | targeting any of its pads in a links array. A given link is thus stored | ||||||
| twice, once in the source entity and once in the target entity. The array is | twice, once in the source entity and once in the target entity. The array is | ||||||
| pre-allocated and grows dynamically as needed. | pre-allocated and grows dynamically as needed. | ||||||
| 
 | 
 | ||||||
|  | @ -348,6 +348,6 @@ a streaming entity. Links that can be modified while streaming must be marked | ||||||
| with the MEDIA_LNK_FL_DYNAMIC flag. | with the MEDIA_LNK_FL_DYNAMIC flag. | ||||||
| 
 | 
 | ||||||
| If other operations need to be disallowed on streaming entities (such as | If other operations need to be disallowed on streaming entities (such as | ||||||
| changing entities configuration parameters) drivers can explictly check the | changing entities configuration parameters) drivers can explicitly check the | ||||||
| media_entity stream_count field to find out if an entity is streaming. This | media_entity stream_count field to find out if an entity is streaming. This | ||||||
| operation must be done with the media_device graph_mutex held. | operation must be done with the media_device graph_mutex held. | ||||||
|  |  | ||||||
|  | @ -39,13 +39,13 @@ Note: for more information, please refer "AMD Alchemy Au1200/Au1550 IDE | ||||||
|       Interface and Linux Device Driver" Application Note. |       Interface and Linux Device Driver" Application Note. | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| FILES, CONFIGS AND COMPATABILITY | FILES, CONFIGS AND COMPATIBILITY | ||||||
| -------------------------------- | -------------------------------- | ||||||
| 
 | 
 | ||||||
| Two files are introduced: | Two files are introduced: | ||||||
| 
 | 
 | ||||||
|   a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h' |   a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h' | ||||||
|      containes : struct _auide_hwif |      contains : struct _auide_hwif | ||||||
|                  timing parameters for PIO mode 0/1/2/3/4 |                  timing parameters for PIO mode 0/1/2/3/4 | ||||||
|                  timing parameters for MWDMA 0/1/2 |                  timing parameters for MWDMA 0/1/2 | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -5,7 +5,7 @@ Supported chips: | ||||||
|   * IDT ICS932S401 |   * IDT ICS932S401 | ||||||
|     Prefix: 'ics932s401' |     Prefix: 'ics932s401' | ||||||
|     Addresses scanned: I2C 0x69 |     Addresses scanned: I2C 0x69 | ||||||
|     Datasheet: Publically available at the IDT website |     Datasheet: Publicly available at the IDT website | ||||||
| 
 | 
 | ||||||
| Author: Darrick J. Wong | Author: Darrick J. Wong | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -256,7 +256,7 @@ You can set the debug level via: | ||||||
| 
 | 
 | ||||||
| Where $VALUE would be a number in the case of this sysfs entry.  The  | Where $VALUE would be a number in the case of this sysfs entry.  The  | ||||||
| input to sysfs files does not have to be a number.  For example, the  | input to sysfs files does not have to be a number.  For example, the  | ||||||
| firmware loader used by hotplug utilizes sysfs entries for transfering  | firmware loader used by hotplug utilizes sysfs entries for transferring  | ||||||
| the firmware image from user space into the driver. | the firmware image from user space into the driver. | ||||||
| 
 | 
 | ||||||
| The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries  | The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries  | ||||||
|  |  | ||||||
|  | @ -72,7 +72,7 @@ folder: | ||||||
| #  fragmentation    gw_sel_class  vis_mode | #  fragmentation    gw_sel_class  vis_mode | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| There is a special folder for debugging informations: | There is a special folder for debugging information: | ||||||
| 
 | 
 | ||||||
| #  ls /sys/kernel/debug/batman_adv/bat0/ | #  ls /sys/kernel/debug/batman_adv/bat0/ | ||||||
| #  gateways     socket        transtable_global  vis_data | #  gateways     socket        transtable_global  vis_data | ||||||
|  |  | ||||||
|  | @ -368,7 +368,7 @@ fail_over_mac | ||||||
| 		gratuitous ARP is lost, communication may be | 		gratuitous ARP is lost, communication may be | ||||||
| 		disrupted. | 		disrupted. | ||||||
| 
 | 
 | ||||||
| 		When this policy is used in conjuction with the mii | 		When this policy is used in conjunction with the mii | ||||||
| 		monitor, devices which assert link up prior to being | 		monitor, devices which assert link up prior to being | ||||||
| 		able to actually transmit and receive are particularly | 		able to actually transmit and receive are particularly | ||||||
| 		susceptible to loss of the gratuitous ARP, and an | 		susceptible to loss of the gratuitous ARP, and an | ||||||
|  |  | ||||||
|  | @ -136,7 +136,7 @@ The CAIF Protocol implementation contains: | ||||||
|       - CFMUX CAIF Mux layer. Handles multiplexing between multiple |       - CFMUX CAIF Mux layer. Handles multiplexing between multiple | ||||||
| 	physical bearers and multiple channels such as VEI, Datagram, etc. | 	physical bearers and multiple channels such as VEI, Datagram, etc. | ||||||
| 	The MUX keeps track of the existing CAIF Channels and | 	The MUX keeps track of the existing CAIF Channels and | ||||||
| 	Physical Instances and selects the apropriate instance based | 	Physical Instances and selects the appropriate instance based | ||||||
| 	on Channel-Id and Physical-ID. | 	on Channel-Id and Physical-ID. | ||||||
| 
 | 
 | ||||||
|       - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length |       - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length | ||||||
|  |  | ||||||
|  | @ -150,7 +150,7 @@ static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev) | ||||||
| void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev) | void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev) | ||||||
| { | { | ||||||
| 	/* If xfer is true then you should assert the SPI_INT to indicate to | 	/* If xfer is true then you should assert the SPI_INT to indicate to | ||||||
| 	 * the master that you are ready to recieve the data from the master | 	 * the master that you are ready to receive the data from the master | ||||||
| 	 * SPI. If xfer is false then you should de-assert SPI_INT to indicate | 	 * SPI. If xfer is false then you should de-assert SPI_INT to indicate | ||||||
| 	 * that the transfer is done. | 	 * that the transfer is done. | ||||||
| 	 */ | 	 */ | ||||||
|  |  | ||||||
|  | @ -240,7 +240,7 @@ solution for a couple of reasons: | ||||||
|   the user application using the common CAN filter mechanisms. Inside |   the user application using the common CAN filter mechanisms. Inside | ||||||
|   this filter definition the (interested) type of errors may be |   this filter definition the (interested) type of errors may be | ||||||
|   selected. The reception of error frames is disabled by default. |   selected. The reception of error frames is disabled by default. | ||||||
|   The format of the CAN error frame is briefly decribed in the Linux |   The format of the CAN error frame is briefly described in the Linux | ||||||
|   header file "include/linux/can/error.h". |   header file "include/linux/can/error.h". | ||||||
| 
 | 
 | ||||||
| 4. How to use Socket CAN | 4. How to use Socket CAN | ||||||
|  |  | ||||||
|  | @ -9,7 +9,7 @@ The Linux-ZigBee project goal is to provide complete implementation | ||||||
| of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack | of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack | ||||||
| of protocols for organizing Low-Rate Wireless Personal Area Networks. | of protocols for organizing Low-Rate Wireless Personal Area Networks. | ||||||
| 
 | 
 | ||||||
| Currently only IEEE 802.15.4 layer is implemented. We have choosen | Currently only IEEE 802.15.4 layer is implemented. We have chosen | ||||||
| to use plain Berkeley socket API, the generic Linux networking stack | to use plain Berkeley socket API, the generic Linux networking stack | ||||||
| to transfer IEEE 802.15.4 messages and a special protocol over genetlink | to transfer IEEE 802.15.4 messages and a special protocol over genetlink | ||||||
| for configuration/management | for configuration/management | ||||||
|  |  | ||||||
|  | @ -223,7 +223,7 @@ we will get the following buffer structure: | ||||||
| 
 | 
 | ||||||
| A frame can be of any size with the only condition it can fit in a block. A block | A frame can be of any size with the only condition it can fit in a block. A block | ||||||
| can only hold an integer number of frames, or in other words, a frame cannot  | can only hold an integer number of frames, or in other words, a frame cannot  | ||||||
| be spawned accross two blocks, so there are some details you have to take into  | be spawned across two blocks, so there are some details you have to take into  | ||||||
| account when choosing the frame_size. See "Mapping and use of the circular  | account when choosing the frame_size. See "Mapping and use of the circular  | ||||||
| buffer (ring)". | buffer (ring)". | ||||||
| 
 | 
 | ||||||
|  |  | ||||||
|  | @ -1,5 +1,5 @@ | ||||||
| 
 | 
 | ||||||
| The "enviromental" rules for authors of any new tc actions are: | The "environmental" rules for authors of any new tc actions are: | ||||||
| 
 | 
 | ||||||
| 1) If you stealeth or borroweth any packet thou shalt be branching | 1) If you stealeth or borroweth any packet thou shalt be branching | ||||||
| from the righteous path and thou shalt cloneth. | from the righteous path and thou shalt cloneth. | ||||||
|  | @ -20,7 +20,7 @@ this way any action downstream can stomp on the packet. | ||||||
| 3) Dropping packets you don't own is a no-no. You simply return | 3) Dropping packets you don't own is a no-no. You simply return | ||||||
| TC_ACT_SHOT to the caller and they will drop it. | TC_ACT_SHOT to the caller and they will drop it. | ||||||
| 
 | 
 | ||||||
| The "enviromental" rules for callers of actions (qdiscs etc) are: | The "environmental" rules for callers of actions (qdiscs etc) are: | ||||||
| 
 | 
 | ||||||
| *) Thou art responsible for freeing anything returned as being | *) Thou art responsible for freeing anything returned as being | ||||||
| TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is | TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is | ||||||
|  |  | ||||||
|  | @ -367,7 +367,7 @@ Drivers need to be able to handle hardware which has been reset since the | ||||||
| suspend methods were called, for example by complete reinitialization. | suspend methods were called, for example by complete reinitialization. | ||||||
| This may be the hardest part, and the one most protected by NDA'd documents | This may be the hardest part, and the one most protected by NDA'd documents | ||||||
| and chip errata.  It's simplest if the hardware state hasn't changed since | and chip errata.  It's simplest if the hardware state hasn't changed since | ||||||
| the suspend was carried out, but that can't be guaranteed (in fact, it ususally | the suspend was carried out, but that can't be guaranteed (in fact, it usually | ||||||
| is not the case). | is not the case). | ||||||
| 
 | 
 | ||||||
| Drivers must also be prepared to notice that the device has been removed | Drivers must also be prepared to notice that the device has been removed | ||||||
|  |  | ||||||
Some files were not shown because too many files have changed in this diff Show more
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue
	
	 David S. Miller
				David S. Miller