Loading .gitignore +1 −0 Original line number Original line Diff line number Diff line Loading @@ -28,6 +28,7 @@ modules.builtin *.gz *.gz *.bz2 *.bz2 *.lzma *.lzma *.xz *.lzo *.lzo *.patch *.patch *.gcno *.gcno Loading .mailmap +5 −0 Original line number Original line Diff line number Diff line Loading @@ -20,9 +20,11 @@ Andreas Herrmann <aherrman@de.ibm.com> Andrew Morton <akpm@osdl.org> Andrew Morton <akpm@osdl.org> Andrew Vasquez <andrew.vasquez@qlogic.com> Andrew Vasquez <andrew.vasquez@qlogic.com> Andy Adamson <andros@citi.umich.edu> Andy Adamson <andros@citi.umich.edu> Archit Taneja <archit@ti.com> Arnaud Patard <arnaud.patard@rtp-net.org> Arnaud Patard <arnaud.patard@rtp-net.org> Arnd Bergmann <arnd@arndb.de> Arnd Bergmann <arnd@arndb.de> Axel Dyks <xl@xlsigned.net> Axel Dyks <xl@xlsigned.net> Axel Lin <axel.lin@gmail.com> Ben Gardner <bgardner@wabtec.com> Ben Gardner <bgardner@wabtec.com> Ben M Cahill <ben.m.cahill@intel.com> Ben M Cahill <ben.m.cahill@intel.com> Björn Steinbrink <B.Steinbrink@gmx.de> Björn Steinbrink <B.Steinbrink@gmx.de> Loading Loading @@ -69,6 +71,7 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com> Linas Vepstas <linas@austin.ibm.com> Linas Vepstas <linas@austin.ibm.com> Mark Brown <broonie@sirena.org.uk> Mark Brown <broonie@sirena.org.uk> Matthieu CASTET <castet.matthieu@free.fr> Matthieu CASTET <castet.matthieu@free.fr> Mayuresh Janorkar <mayur@ti.com> Michael Buesch <mb@bu3sch.de> Michael Buesch <mb@bu3sch.de> Michael Buesch <mbuesch@freenet.de> Michael Buesch <mbuesch@freenet.de> Michel Dänzer <michel@tungstengraphics.com> Michel Dänzer <michel@tungstengraphics.com> Loading @@ -77,6 +80,7 @@ Morten Welinder <terra@gnome.org> Morten Welinder <welinder@anemone.rentec.com> Morten Welinder <welinder@anemone.rentec.com> Morten Welinder <welinder@darter.rentec.com> Morten Welinder <welinder@darter.rentec.com> Morten Welinder <welinder@troll.com> Morten Welinder <welinder@troll.com> Mythri P K <mythripk@ti.com> Nguyen Anh Quynh <aquynh@gmail.com> Nguyen Anh Quynh <aquynh@gmail.com> Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Patrick Mochel <mochel@digitalimplant.org> Patrick Mochel <mochel@digitalimplant.org> Loading @@ -97,6 +101,7 @@ S.Çağlar Onur <caglar@pardus.org.tr> Simon Kelley <simon@thekelleys.org.uk> Simon Kelley <simon@thekelleys.org.uk> Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr> Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr> Stephen Hemminger <shemminger@osdl.org> Stephen Hemminger <shemminger@osdl.org> Sumit Semwal <sumit.semwal@ti.com> Tejun Heo <htejun@gmail.com> Tejun Heo <htejun@gmail.com> Thomas Graf <tgraf@suug.ch> Thomas Graf <tgraf@suug.ch> Tony Luck <tony.luck@intel.com> Tony Luck <tony.luck@intel.com> Loading Documentation/00-INDEX +0 −4 Original line number Original line Diff line number Diff line Loading @@ -328,8 +328,6 @@ sysrq.txt - info on the magic SysRq key. - info on the magic SysRq key. telephony/ telephony/ - directory with info on telephony (e.g. voice over IP) support. - directory with info on telephony (e.g. voice over IP) support. time_interpolators.txt - info on time interpolators. uml/ uml/ - directory with information about User Mode Linux. - directory with information about User Mode Linux. unicode.txt unicode.txt Loading @@ -346,8 +344,6 @@ vm/ - directory with info on the Linux vm code. - directory with info on the Linux vm code. volatile-considered-harmful.txt volatile-considered-harmful.txt - Why the "volatile" type class should not be used - Why the "volatile" type class should not be used voyager.txt - guide to running Linux on the Voyager architecture. w1/ w1/ - directory with documents regarding the 1-wire (w1) subsystem. - directory with documents regarding the 1-wire (w1) subsystem. watchdog/ watchdog/ Loading Documentation/ABI/stable/sysfs-class-backlight +20 −0 Original line number Original line Diff line number Diff line Loading @@ -34,3 +34,23 @@ Contact: Richard Purdie <rpurdie@rpsys.net> Description: Description: Maximum brightness for <backlight>. Maximum brightness for <backlight>. Users: HAL Users: HAL What: /sys/class/backlight/<backlight>/type Date: September 2010 KernelVersion: 2.6.37 Contact: Matthew Garrett <mjg@redhat.com> Description: The type of interface controlled by <backlight>. "firmware": The driver uses a standard firmware interface "platform": The driver uses a platform-specific interface "raw": The driver controls hardware registers directly In the general case, when multiple backlight interfaces are available for a single device, firmware control should be preferred to platform control should be preferred to raw control. Using a firmware interface reduces the probability of confusion with the hardware and the OS independently updating the backlight state. Platform interfaces are mostly a holdover from pre-standardisation of firmware interfaces. Documentation/ABI/stable/sysfs-firmware-efi-vars 0 → 100644 +75 −0 Original line number Original line Diff line number Diff line What: /sys/firmware/efi/vars Date: April 2004 Contact: Matt Domsch <Matt_Domsch@dell.com> Description: This directory exposes interfaces for interactive with EFI variables. For more information on EFI variables, see 'Variable Services' in the UEFI specification (section 7.2 in specification version 2.3 Errata D). In summary, EFI variables are named, and are classified into separate namespaces through the use of a vendor GUID. They also have an arbitrary binary value associated with them. The efivars module enumerates these variables and creates a separate directory for each one found. Each directory has a name of the form "<key>-<vendor guid>" and contains the following files: attributes: A read-only text file enumerating the EFI variable flags. Potential values include: EFI_VARIABLE_NON_VOLATILE EFI_VARIABLE_BOOTSERVICE_ACCESS EFI_VARIABLE_RUNTIME_ACCESS EFI_VARIABLE_HARDWARE_ERROR_RECORD EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS See the EFI documentation for an explanation of each of these variables. data: A read-only binary file that can be read to attain the value of the EFI variable guid: The vendor GUID of the variable. This should always match the GUID in the variable's name. raw_var: A binary file that can be read to obtain a structure that contains everything there is to know about the variable. For structure definition see "struct efi_variable" in the kernel sources. This file can also be written to in order to update the value of a variable. For this to work however, all fields of the "struct efi_variable" passed must match byte for byte with the structure read out of the file, save for the value portion. **Note** the efi_variable structure read/written with this file contains a 'long' type that may change widths depending on your underlying architecture. size: As ASCII representation of the size of the variable's value. In addition, two other magic binary files are provided in the top-level directory and are used for adding and removing variables: new_var: Takes a "struct efi_variable" and instructs the EFI firmware to create a new variable. del_var: Takes a "struct efi_variable" and instructs the EFI firmware to remove any variable that has a matching vendor GUID and variable key name. Loading
.gitignore +1 −0 Original line number Original line Diff line number Diff line Loading @@ -28,6 +28,7 @@ modules.builtin *.gz *.gz *.bz2 *.bz2 *.lzma *.lzma *.xz *.lzo *.lzo *.patch *.patch *.gcno *.gcno Loading
.mailmap +5 −0 Original line number Original line Diff line number Diff line Loading @@ -20,9 +20,11 @@ Andreas Herrmann <aherrman@de.ibm.com> Andrew Morton <akpm@osdl.org> Andrew Morton <akpm@osdl.org> Andrew Vasquez <andrew.vasquez@qlogic.com> Andrew Vasquez <andrew.vasquez@qlogic.com> Andy Adamson <andros@citi.umich.edu> Andy Adamson <andros@citi.umich.edu> Archit Taneja <archit@ti.com> Arnaud Patard <arnaud.patard@rtp-net.org> Arnaud Patard <arnaud.patard@rtp-net.org> Arnd Bergmann <arnd@arndb.de> Arnd Bergmann <arnd@arndb.de> Axel Dyks <xl@xlsigned.net> Axel Dyks <xl@xlsigned.net> Axel Lin <axel.lin@gmail.com> Ben Gardner <bgardner@wabtec.com> Ben Gardner <bgardner@wabtec.com> Ben M Cahill <ben.m.cahill@intel.com> Ben M Cahill <ben.m.cahill@intel.com> Björn Steinbrink <B.Steinbrink@gmx.de> Björn Steinbrink <B.Steinbrink@gmx.de> Loading Loading @@ -69,6 +71,7 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com> Linas Vepstas <linas@austin.ibm.com> Linas Vepstas <linas@austin.ibm.com> Mark Brown <broonie@sirena.org.uk> Mark Brown <broonie@sirena.org.uk> Matthieu CASTET <castet.matthieu@free.fr> Matthieu CASTET <castet.matthieu@free.fr> Mayuresh Janorkar <mayur@ti.com> Michael Buesch <mb@bu3sch.de> Michael Buesch <mb@bu3sch.de> Michael Buesch <mbuesch@freenet.de> Michael Buesch <mbuesch@freenet.de> Michel Dänzer <michel@tungstengraphics.com> Michel Dänzer <michel@tungstengraphics.com> Loading @@ -77,6 +80,7 @@ Morten Welinder <terra@gnome.org> Morten Welinder <welinder@anemone.rentec.com> Morten Welinder <welinder@anemone.rentec.com> Morten Welinder <welinder@darter.rentec.com> Morten Welinder <welinder@darter.rentec.com> Morten Welinder <welinder@troll.com> Morten Welinder <welinder@troll.com> Mythri P K <mythripk@ti.com> Nguyen Anh Quynh <aquynh@gmail.com> Nguyen Anh Quynh <aquynh@gmail.com> Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Patrick Mochel <mochel@digitalimplant.org> Patrick Mochel <mochel@digitalimplant.org> Loading @@ -97,6 +101,7 @@ S.Çağlar Onur <caglar@pardus.org.tr> Simon Kelley <simon@thekelleys.org.uk> Simon Kelley <simon@thekelleys.org.uk> Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr> Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr> Stephen Hemminger <shemminger@osdl.org> Stephen Hemminger <shemminger@osdl.org> Sumit Semwal <sumit.semwal@ti.com> Tejun Heo <htejun@gmail.com> Tejun Heo <htejun@gmail.com> Thomas Graf <tgraf@suug.ch> Thomas Graf <tgraf@suug.ch> Tony Luck <tony.luck@intel.com> Tony Luck <tony.luck@intel.com> Loading
Documentation/00-INDEX +0 −4 Original line number Original line Diff line number Diff line Loading @@ -328,8 +328,6 @@ sysrq.txt - info on the magic SysRq key. - info on the magic SysRq key. telephony/ telephony/ - directory with info on telephony (e.g. voice over IP) support. - directory with info on telephony (e.g. voice over IP) support. time_interpolators.txt - info on time interpolators. uml/ uml/ - directory with information about User Mode Linux. - directory with information about User Mode Linux. unicode.txt unicode.txt Loading @@ -346,8 +344,6 @@ vm/ - directory with info on the Linux vm code. - directory with info on the Linux vm code. volatile-considered-harmful.txt volatile-considered-harmful.txt - Why the "volatile" type class should not be used - Why the "volatile" type class should not be used voyager.txt - guide to running Linux on the Voyager architecture. w1/ w1/ - directory with documents regarding the 1-wire (w1) subsystem. - directory with documents regarding the 1-wire (w1) subsystem. watchdog/ watchdog/ Loading
Documentation/ABI/stable/sysfs-class-backlight +20 −0 Original line number Original line Diff line number Diff line Loading @@ -34,3 +34,23 @@ Contact: Richard Purdie <rpurdie@rpsys.net> Description: Description: Maximum brightness for <backlight>. Maximum brightness for <backlight>. Users: HAL Users: HAL What: /sys/class/backlight/<backlight>/type Date: September 2010 KernelVersion: 2.6.37 Contact: Matthew Garrett <mjg@redhat.com> Description: The type of interface controlled by <backlight>. "firmware": The driver uses a standard firmware interface "platform": The driver uses a platform-specific interface "raw": The driver controls hardware registers directly In the general case, when multiple backlight interfaces are available for a single device, firmware control should be preferred to platform control should be preferred to raw control. Using a firmware interface reduces the probability of confusion with the hardware and the OS independently updating the backlight state. Platform interfaces are mostly a holdover from pre-standardisation of firmware interfaces.
Documentation/ABI/stable/sysfs-firmware-efi-vars 0 → 100644 +75 −0 Original line number Original line Diff line number Diff line What: /sys/firmware/efi/vars Date: April 2004 Contact: Matt Domsch <Matt_Domsch@dell.com> Description: This directory exposes interfaces for interactive with EFI variables. For more information on EFI variables, see 'Variable Services' in the UEFI specification (section 7.2 in specification version 2.3 Errata D). In summary, EFI variables are named, and are classified into separate namespaces through the use of a vendor GUID. They also have an arbitrary binary value associated with them. The efivars module enumerates these variables and creates a separate directory for each one found. Each directory has a name of the form "<key>-<vendor guid>" and contains the following files: attributes: A read-only text file enumerating the EFI variable flags. Potential values include: EFI_VARIABLE_NON_VOLATILE EFI_VARIABLE_BOOTSERVICE_ACCESS EFI_VARIABLE_RUNTIME_ACCESS EFI_VARIABLE_HARDWARE_ERROR_RECORD EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS See the EFI documentation for an explanation of each of these variables. data: A read-only binary file that can be read to attain the value of the EFI variable guid: The vendor GUID of the variable. This should always match the GUID in the variable's name. raw_var: A binary file that can be read to obtain a structure that contains everything there is to know about the variable. For structure definition see "struct efi_variable" in the kernel sources. This file can also be written to in order to update the value of a variable. For this to work however, all fields of the "struct efi_variable" passed must match byte for byte with the structure read out of the file, save for the value portion. **Note** the efi_variable structure read/written with this file contains a 'long' type that may change widths depending on your underlying architecture. size: As ASCII representation of the size of the variable's value. In addition, two other magic binary files are provided in the top-level directory and are used for adding and removing variables: new_var: Takes a "struct efi_variable" and instructs the EFI firmware to create a new variable. del_var: Takes a "struct efi_variable" and instructs the EFI firmware to remove any variable that has a matching vendor GUID and variable key name.
