mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-09-04 20:19:47 +08:00
Merge branch 'master'; commit 'v2.6.38-rc7' into next
This commit is contained in:
commit
1cc26bada9
1
.gitignore
vendored
1
.gitignore
vendored
@ -28,6 +28,7 @@ modules.builtin
|
|||||||
*.gz
|
*.gz
|
||||||
*.bz2
|
*.bz2
|
||||||
*.lzma
|
*.lzma
|
||||||
|
*.xz
|
||||||
*.lzo
|
*.lzo
|
||||||
*.patch
|
*.patch
|
||||||
*.gcno
|
*.gcno
|
||||||
|
1
.mailmap
1
.mailmap
@ -23,6 +23,7 @@ Andy Adamson <andros@citi.umich.edu>
|
|||||||
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>
|
||||||
|
4
CREDITS
4
CREDITS
@ -2811,8 +2811,8 @@ D: CDROM driver "sonycd535" (Sony CDU-535/531)
|
|||||||
N: Stelian Pop
|
N: Stelian Pop
|
||||||
E: stelian@popies.net
|
E: stelian@popies.net
|
||||||
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
|
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
|
||||||
D: sonypi, meye drivers, mct_u232 usb serial hacks
|
D: random kernel hacks
|
||||||
S: Paris, France
|
S: Paimpont, France
|
||||||
|
|
||||||
N: Pete Popov
|
N: Pete Popov
|
||||||
E: pete_popov@yahoo.com
|
E: pete_popov@yahoo.com
|
||||||
|
4
Documentation/ABI/stable/thermal-notification
Normal file
4
Documentation/ABI/stable/thermal-notification
Normal file
@ -0,0 +1,4 @@
|
|||||||
|
What: A notification mechanism for thermal related events
|
||||||
|
Description:
|
||||||
|
This interface enables notification for thermal related events.
|
||||||
|
The notification is in the form of a netlink event.
|
@ -26,3 +26,12 @@ Description:
|
|||||||
scheduler is chosen. Trigger specific parameters can appear in
|
scheduler is chosen. Trigger specific parameters can appear in
|
||||||
/sys/class/leds/<led> once a given trigger is selected.
|
/sys/class/leds/<led> once a given trigger is selected.
|
||||||
|
|
||||||
|
What: /sys/class/leds/<led>/inverted
|
||||||
|
Date: January 2011
|
||||||
|
KernelVersion: 2.6.38
|
||||||
|
Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||||
|
Description:
|
||||||
|
Invert the LED on/off state. This parameter is specific to
|
||||||
|
gpio and backlight triggers. In case of the backlight trigger,
|
||||||
|
it is usefull when driving a LED which is intended to indicate
|
||||||
|
a device in a standby like state.
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_dpi
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/actual_dpi
|
||||||
Date: March 2010
|
Date: March 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: It is possible to switch the dpi setting of the mouse with the
|
Description: It is possible to switch the dpi setting of the mouse with the
|
||||||
@ -17,13 +17,13 @@ Description: It is possible to switch the dpi setting of the mouse with the
|
|||||||
|
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/actual_profile
|
||||||
Date: March 2010
|
Date: March 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: When read, this file returns the number of the actual profile.
|
Description: When read, this file returns the number of the actual profile.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/firmware_version
|
||||||
Date: March 2010
|
Date: March 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: When read, this file returns the raw integer version number of the
|
Description: When read, this file returns the raw integer version number of the
|
||||||
@ -33,7 +33,7 @@ Description: When read, this file returns the raw integer version number of the
|
|||||||
left. E.g. a returned value of 138 means 1.38
|
left. E.g. a returned value of 138 means 1.38
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/profile[1-5]
|
||||||
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
|
||||||
@ -48,7 +48,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
|||||||
stored in the profile doesn't need to fit the number of the
|
stored in the profile doesn't need to fit the number of the
|
||||||
store.
|
store.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/settings
|
||||||
Date: March 2010
|
Date: March 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: When read, this file returns the settings stored in the mouse.
|
Description: When read, this file returns the settings stored in the mouse.
|
||||||
@ -58,7 +58,7 @@ Description: When read, this file returns the settings stored in the mouse.
|
|||||||
The data has to be 36 bytes long. The mouse will reject invalid
|
The data has to be 36 bytes long. The mouse will reject invalid
|
||||||
data.
|
data.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/startup_profile
|
||||||
Date: March 2010
|
Date: March 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The integer value of this attribute ranges from 1 to 5.
|
Description: The integer value of this attribute ranges from 1 to 5.
|
||||||
@ -67,7 +67,7 @@ Description: The integer value of this attribute ranges from 1 to 5.
|
|||||||
When written, this file sets the number of the startup profile
|
When written, this file sets the number of the startup profile
|
||||||
and the mouse activates this profile immediately.
|
and the mouse activates this profile immediately.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/tcu
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/tcu
|
||||||
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 has a "Tracking Control Unit" which lets the user
|
Description: The mouse has a "Tracking Control Unit" which lets the user
|
||||||
@ -78,7 +78,7 @@ Description: The mouse has a "Tracking Control Unit" which lets the user
|
|||||||
Writing 1 in this file will start the calibration which takes
|
Writing 1 in this file will start the calibration which takes
|
||||||
around 6 seconds to complete and activates the TCU.
|
around 6 seconds to complete and activates the TCU.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/weight
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/weight
|
||||||
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 be equipped with one of four supplied weights
|
Description: The mouse can be equipped with one of four supplied weights
|
||||||
|
108
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
Normal file
108
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
Normal file
@ -0,0 +1,108 @@
|
|||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
Description: When read, this file returns the number of the actual profile in
|
||||||
|
range 0-4.
|
||||||
|
This file is readonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
Description: When read, this file returns the raw integer version number of the
|
||||||
|
firmware reported by the mouse. Using the integer value eases
|
||||||
|
further usage in other programs. To receive the real version
|
||||||
|
number the decimal point has to be shifted 2 positions to the
|
||||||
|
left. E.g. a returned value of 121 means 1.21
|
||||||
|
This file is readonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
Description: The mouse can store a macro with max 500 key/button strokes
|
||||||
|
internally.
|
||||||
|
When written, this file lets one set the sequence for a specific
|
||||||
|
button for a specific profile. Button and profile numbers are
|
||||||
|
included in written data. The data has to be 2082 bytes long.
|
||||||
|
This file is writeonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
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.
|
||||||
|
profile_buttons holds informations about button layout.
|
||||||
|
When written, this file lets one write the respective profile
|
||||||
|
buttons back to the mouse. The data has to be 77 bytes long.
|
||||||
|
The mouse will reject invalid data.
|
||||||
|
Which profile to write is determined by the profile number
|
||||||
|
contained in the data.
|
||||||
|
This file is writeonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
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.
|
||||||
|
profile_buttons holds informations about button layout.
|
||||||
|
When read, these files return the respective profile buttons.
|
||||||
|
The returned data is 77 bytes in size.
|
||||||
|
This file is readonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
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.
|
||||||
|
profile_settings holds informations like resolution, sensitivity
|
||||||
|
and light effects.
|
||||||
|
When written, this file lets one write the respective profile
|
||||||
|
settings back to the mouse. The data has to be 43 bytes long.
|
||||||
|
The mouse will reject invalid data.
|
||||||
|
Which profile to write is determined by the profile number
|
||||||
|
contained in the data.
|
||||||
|
This file is writeonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
|
||||||
|
Date: August 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
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.
|
||||||
|
profile_settings holds informations like resolution, sensitivity
|
||||||
|
and light effects.
|
||||||
|
When read, these files return the respective profile settings.
|
||||||
|
The returned data is 43 bytes in size.
|
||||||
|
This file is readonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
Description: The mouse has a tracking- and a distance-control-unit. These
|
||||||
|
can be activated/deactivated and the lift-off distance can be
|
||||||
|
set. The data has to be 6 bytes long.
|
||||||
|
This file is writeonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
Description: The integer value of this attribute ranges from 0-4.
|
||||||
|
When read, this attribute returns the number of the profile
|
||||||
|
that's active when the mouse is powered on.
|
||||||
|
When written, this file sets the number of the startup profile
|
||||||
|
and the mouse activates this profile immediately.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
Description: When written a calibration process for the tracking control unit
|
||||||
|
can be initiated/cancelled.
|
||||||
|
The data has to be 3 bytes long.
|
||||||
|
This file is writeonly.
|
||||||
|
|
||||||
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image
|
||||||
|
Date: October 2010
|
||||||
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
|
Description: When read the mouse returns a 30x30 pixel image of the
|
||||||
|
sampled underground. This works only in the course of a
|
||||||
|
calibration process initiated with tcu.
|
||||||
|
The returned data is 1028 bytes in size.
|
||||||
|
This file is readonly.
|
@ -1,4 +1,4 @@
|
|||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_cpi
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
|
||||||
Date: August 2010
|
Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: It is possible to switch the cpi setting of the mouse with the
|
Description: It is possible to switch the cpi setting of the mouse with the
|
||||||
@ -14,14 +14,14 @@ Description: It is possible to switch the cpi setting of the mouse with the
|
|||||||
|
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile
|
||||||
Date: August 2010
|
Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: When read, this file returns the number of the actual profile in
|
Description: When read, this file returns the number of the actual profile in
|
||||||
range 0-4.
|
range 0-4.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version
|
||||||
Date: August 2010
|
Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: When read, this file returns the raw integer version number of the
|
Description: When read, this file returns the raw integer version number of the
|
||||||
@ -31,7 +31,7 @@ Description: When read, this file returns the raw integer version number of the
|
|||||||
left. E.g. a returned value of 138 means 1.38
|
left. E.g. a returned value of 138 means 1.38
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_settings
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings
|
||||||
Date: August 2010
|
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
|
||||||
@ -45,7 +45,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
|||||||
contained in the data.
|
contained in the data.
|
||||||
This file is writeonly.
|
This file is writeonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_settings
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
|
||||||
Date: August 2010
|
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
|
||||||
@ -56,7 +56,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
|||||||
The returned data is 13 bytes in size.
|
The returned data is 13 bytes in size.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_buttons
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons
|
||||||
Date: August 2010
|
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
|
||||||
@ -69,7 +69,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
|||||||
contained in the data.
|
contained in the data.
|
||||||
This file is writeonly.
|
This file is writeonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_buttons
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
|
||||||
Date: August 2010
|
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
|
||||||
@ -79,7 +79,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
|||||||
The returned data is 19 bytes in size.
|
The returned data is 19 bytes in size.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
|
||||||
Date: August 2010
|
Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The integer value of this attribute ranges from 0-4.
|
Description: The integer value of this attribute ranges from 0-4.
|
||||||
@ -87,7 +87,7 @@ Description: The integer value of this attribute ranges from 0-4.
|
|||||||
that's active when the mouse is powered on.
|
that's active when the mouse is powered on.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
|
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings
|
||||||
Date: August 2010
|
Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: When read, this file returns the settings stored in the mouse.
|
Description: When read, this file returns the settings stored in the mouse.
|
||||||
|
25
Documentation/ABI/testing/sysfs-platform-at91
Normal file
25
Documentation/ABI/testing/sysfs-platform-at91
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
What: /sys/devices/platform/at91_can/net/<iface>/mb0_id
|
||||||
|
Date: January 2011
|
||||||
|
KernelVersion: 2.6.38
|
||||||
|
Contact: Marc Kleine-Budde <kernel@pengutronix.de>
|
||||||
|
Description:
|
||||||
|
Value representing the can_id of mailbox 0.
|
||||||
|
|
||||||
|
Default: 0x7ff (standard frame)
|
||||||
|
|
||||||
|
Due to a chip bug (errata 50.2.6.3 & 50.3.5.3 in
|
||||||
|
"AT91SAM9263 Preliminary 6249H-ATARM-27-Jul-09") the
|
||||||
|
contents of mailbox 0 may be send under certain
|
||||||
|
conditions (even if disabled or in rx mode).
|
||||||
|
|
||||||
|
The workaround in the errata suggests not to use the
|
||||||
|
mailbox and load it with an unused identifier.
|
||||||
|
|
||||||
|
In order to use an extended can_id add the
|
||||||
|
CAN_EFF_FLAG (0x80000000U) to the can_id. Example:
|
||||||
|
|
||||||
|
- standard id 0x7ff:
|
||||||
|
echo 0x7ff > /sys/class/net/can0/mb0_id
|
||||||
|
|
||||||
|
- extended id 0x1fffffff:
|
||||||
|
echo 0x9fffffff > /sys/class/net/can0/mb0_id
|
6
Documentation/ABI/testing/sysfs-platform-ideapad-laptop
Normal file
6
Documentation/ABI/testing/sysfs-platform-ideapad-laptop
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
What: /sys/devices/platform/ideapad/camera_power
|
||||||
|
Date: Dec 2010
|
||||||
|
KernelVersion: 2.6.37
|
||||||
|
Contact: "Ike Panhc <ike.pan@canonical.com>"
|
||||||
|
Description:
|
||||||
|
Control the power of camera module. 1 means on, 0 means off.
|
@ -268,10 +268,6 @@
|
|||||||
!Finclude/net/mac80211.h ieee80211_ops
|
!Finclude/net/mac80211.h ieee80211_ops
|
||||||
!Finclude/net/mac80211.h ieee80211_alloc_hw
|
!Finclude/net/mac80211.h ieee80211_alloc_hw
|
||||||
!Finclude/net/mac80211.h ieee80211_register_hw
|
!Finclude/net/mac80211.h ieee80211_register_hw
|
||||||
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
|
|
||||||
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
|
|
||||||
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
|
|
||||||
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
|
|
||||||
!Finclude/net/mac80211.h ieee80211_unregister_hw
|
!Finclude/net/mac80211.h ieee80211_unregister_hw
|
||||||
!Finclude/net/mac80211.h ieee80211_free_hw
|
!Finclude/net/mac80211.h ieee80211_free_hw
|
||||||
</chapter>
|
</chapter>
|
||||||
@ -382,6 +378,23 @@
|
|||||||
</para>
|
</para>
|
||||||
</partintro>
|
</partintro>
|
||||||
|
|
||||||
|
<chapter id="led-support">
|
||||||
|
<title>LED support</title>
|
||||||
|
<para>
|
||||||
|
Mac80211 supports various ways of blinking LEDs. Wherever possible,
|
||||||
|
device LEDs should be exposed as LED class devices and hooked up to
|
||||||
|
the appropriate trigger, which will then be triggered appropriately
|
||||||
|
by mac80211.
|
||||||
|
</para>
|
||||||
|
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
|
||||||
|
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
|
||||||
|
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
|
||||||
|
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
|
||||||
|
!Finclude/net/mac80211.h ieee80211_tpt_blink
|
||||||
|
!Finclude/net/mac80211.h ieee80211_tpt_led_trigger_flags
|
||||||
|
!Finclude/net/mac80211.h ieee80211_create_tpt_led_trigger
|
||||||
|
</chapter>
|
||||||
|
|
||||||
<chapter id="hardware-crypto-offload">
|
<chapter id="hardware-crypto-offload">
|
||||||
<title>Hardware crypto acceleration</title>
|
<title>Hardware crypto acceleration</title>
|
||||||
!Pinclude/net/mac80211.h Hardware crypto acceleration
|
!Pinclude/net/mac80211.h Hardware crypto acceleration
|
||||||
|
@ -217,8 +217,8 @@ X!Isound/sound_firmware.c
|
|||||||
<chapter id="uart16x50">
|
<chapter id="uart16x50">
|
||||||
<title>16x50 UART Driver</title>
|
<title>16x50 UART Driver</title>
|
||||||
!Iinclude/linux/serial_core.h
|
!Iinclude/linux/serial_core.h
|
||||||
!Edrivers/serial/serial_core.c
|
!Edrivers/tty/serial/serial_core.c
|
||||||
!Edrivers/serial/8250.c
|
!Edrivers/tty/serial/8250.c
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="fbdev">
|
<chapter id="fbdev">
|
||||||
|
@ -73,8 +73,8 @@
|
|||||||
services.
|
services.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The core of every DRM driver is struct drm_device. Drivers
|
The core of every DRM driver is struct drm_driver. Drivers
|
||||||
will typically statically initialize a drm_device structure,
|
will typically statically initialize a drm_driver structure,
|
||||||
then pass it to drm_init() at load time.
|
then pass it to drm_init() at load time.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -84,7 +84,7 @@
|
|||||||
<title>Driver initialization</title>
|
<title>Driver initialization</title>
|
||||||
<para>
|
<para>
|
||||||
Before calling the DRM initialization routines, the driver must
|
Before calling the DRM initialization routines, the driver must
|
||||||
first create and fill out a struct drm_device structure.
|
first create and fill out a struct drm_driver structure.
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
static struct drm_driver driver = {
|
static struct drm_driver driver = {
|
||||||
|
@ -28,7 +28,7 @@
|
|||||||
<holder>Convergence GmbH</holder>
|
<holder>Convergence GmbH</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
<copyright>
|
<copyright>
|
||||||
<year>2009-2010</year>
|
<year>2009-2011</year>
|
||||||
<holder>Mauro Carvalho Chehab</holder>
|
<holder>Mauro Carvalho Chehab</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
|
|
||||||
|
@ -82,6 +82,11 @@
|
|||||||
</sect1>
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="fs_events">
|
||||||
|
<title>Events based on file descriptors</title>
|
||||||
|
!Efs/eventfd.c
|
||||||
|
</chapter>
|
||||||
|
|
||||||
<chapter id="sysfs">
|
<chapter id="sysfs">
|
||||||
<title>The Filesystem for Exporting Kernel Objects</title>
|
<title>The Filesystem for Exporting Kernel Objects</title>
|
||||||
!Efs/sysfs/file.c
|
!Efs/sysfs/file.c
|
||||||
|
@ -28,7 +28,7 @@
|
|||||||
<title>LINUX MEDIA INFRASTRUCTURE API</title>
|
<title>LINUX MEDIA INFRASTRUCTURE API</title>
|
||||||
|
|
||||||
<copyright>
|
<copyright>
|
||||||
<year>2009-2010</year>
|
<year>2009-2011</year>
|
||||||
<holder>LinuxTV Developers</holder>
|
<holder>LinuxTV Developers</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
|
|
||||||
@ -86,7 +86,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
|||||||
</author>
|
</author>
|
||||||
</authorgroup>
|
</authorgroup>
|
||||||
<copyright>
|
<copyright>
|
||||||
<year>2009-2010</year>
|
<year>2009-2011</year>
|
||||||
<holder>Mauro Carvalho Chehab</holder>
|
<holder>Mauro Carvalho Chehab</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
|
|
||||||
|
@ -250,7 +250,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
|
|||||||
<title>Device ready function</title>
|
<title>Device ready function</title>
|
||||||
<para>
|
<para>
|
||||||
If the hardware interface has the ready busy pin of the NAND chip connected to a
|
If the hardware interface has the ready busy pin of the NAND chip connected to a
|
||||||
GPIO or other accesible I/O pin, this function is used to read back the state of the
|
GPIO or other accessible I/O pin, this function is used to read back the state of the
|
||||||
pin. The function has no arguments and should return 0, if the device is busy (R/B pin
|
pin. The function has no arguments and should return 0, if the device is busy (R/B pin
|
||||||
is low) and 1, if the device is ready (R/B pin is high).
|
is low) and 1, if the device is ready (R/B pin is high).
|
||||||
If the hardware interface does not give access to the ready busy pin, then
|
If the hardware interface does not give access to the ready busy pin, then
|
||||||
|
@ -75,6 +75,7 @@ as follows:</para>
|
|||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
|
<title>RDS datastructures</title>
|
||||||
<table frame="none" pgwide="1" id="v4l2-rds-data">
|
<table frame="none" pgwide="1" id="v4l2-rds-data">
|
||||||
<title>struct
|
<title>struct
|
||||||
<structname>v4l2_rds_data</structname></title>
|
<structname>v4l2_rds_data</structname></title>
|
||||||
@ -129,10 +130,11 @@ as follows:</para>
|
|||||||
|
|
||||||
<table frame="none" pgwide="1" id="v4l2-rds-block-codes">
|
<table frame="none" pgwide="1" id="v4l2-rds-block-codes">
|
||||||
<title>Block defines</title>
|
<title>Block defines</title>
|
||||||
<tgroup cols="3">
|
<tgroup cols="4">
|
||||||
<colspec colname="c1" colwidth="1*" />
|
<colspec colname="c1" colwidth="1*" />
|
||||||
<colspec colname="c2" colwidth="1*" />
|
<colspec colname="c2" colwidth="1*" />
|
||||||
<colspec colname="c3" colwidth="5*" />
|
<colspec colname="c3" colwidth="1*" />
|
||||||
|
<colspec colname="c4" colwidth="5*" />
|
||||||
<tbody valign="top">
|
<tbody valign="top">
|
||||||
<row>
|
<row>
|
||||||
<entry>V4L2_RDS_BLOCK_MSK</entry>
|
<entry>V4L2_RDS_BLOCK_MSK</entry>
|
||||||
|
@ -100,6 +100,7 @@ Remote Controller chapter.</contrib>
|
|||||||
<year>2008</year>
|
<year>2008</year>
|
||||||
<year>2009</year>
|
<year>2009</year>
|
||||||
<year>2010</year>
|
<year>2010</year>
|
||||||
|
<year>2011</year>
|
||||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
@ -381,7 +382,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||||||
</partinfo>
|
</partinfo>
|
||||||
|
|
||||||
<title>Video for Linux Two API Specification</title>
|
<title>Video for Linux Two API Specification</title>
|
||||||
<subtitle>Revision 2.6.33</subtitle>
|
<subtitle>Revision 2.6.38</subtitle>
|
||||||
|
|
||||||
<chapter id="common">
|
<chapter id="common">
|
||||||
&sub-common;
|
&sub-common;
|
||||||
|
@ -533,6 +533,33 @@ completion during sending a panic event.
|
|||||||
Other Pieces
|
Other Pieces
|
||||||
------------
|
------------
|
||||||
|
|
||||||
|
Get the detailed info related with the IPMI device
|
||||||
|
--------------------------------------------------
|
||||||
|
|
||||||
|
Some users need more detailed information about a device, like where
|
||||||
|
the address came from or the raw base device for the IPMI interface.
|
||||||
|
You can use the IPMI smi_watcher to catch the IPMI interfaces as they
|
||||||
|
come or go, and to grab the information, you can use the function
|
||||||
|
ipmi_get_smi_info(), which returns the following structure:
|
||||||
|
|
||||||
|
struct ipmi_smi_info {
|
||||||
|
enum ipmi_addr_src addr_src;
|
||||||
|
struct device *dev;
|
||||||
|
union {
|
||||||
|
struct {
|
||||||
|
void *acpi_handle;
|
||||||
|
} acpi_info;
|
||||||
|
} addr_info;
|
||||||
|
};
|
||||||
|
|
||||||
|
Currently special info for only for SI_ACPI address sources is
|
||||||
|
returned. Others may be added as necessary.
|
||||||
|
|
||||||
|
Note that the dev pointer is included in the above structure, and
|
||||||
|
assuming ipmi_smi_get_info returns success, you must call put_device
|
||||||
|
on the dev pointer.
|
||||||
|
|
||||||
|
|
||||||
Watchdog
|
Watchdog
|
||||||
--------
|
--------
|
||||||
|
|
||||||
|
122
Documentation/acpi/apei/output_format.txt
Normal file
122
Documentation/acpi/apei/output_format.txt
Normal file
@ -0,0 +1,122 @@
|
|||||||
|
APEI output format
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
APEI uses printk as hardware error reporting interface, the output
|
||||||
|
format is as follow.
|
||||||
|
|
||||||
|
<error record> :=
|
||||||
|
APEI generic hardware error status
|
||||||
|
severity: <integer>, <severity string>
|
||||||
|
section: <integer>, severity: <integer>, <severity string>
|
||||||
|
flags: <integer>
|
||||||
|
<section flags strings>
|
||||||
|
fru_id: <uuid string>
|
||||||
|
fru_text: <string>
|
||||||
|
section_type: <section type string>
|
||||||
|
<section data>
|
||||||
|
|
||||||
|
<severity string>* := recoverable | fatal | corrected | info
|
||||||
|
|
||||||
|
<section flags strings># :=
|
||||||
|
[primary][, containment warning][, reset][, threshold exceeded]\
|
||||||
|
[, resource not accessible][, latent error]
|
||||||
|
|
||||||
|
<section type string> := generic processor error | memory error | \
|
||||||
|
PCIe error | unknown, <uuid string>
|
||||||
|
|
||||||
|
<section data> :=
|
||||||
|
<generic processor section data> | <memory section data> | \
|
||||||
|
<pcie section data> | <null>
|
||||||
|
|
||||||
|
<generic processor section data> :=
|
||||||
|
[processor_type: <integer>, <proc type string>]
|
||||||
|
[processor_isa: <integer>, <proc isa string>]
|
||||||
|
[error_type: <integer>
|
||||||
|
<proc error type strings>]
|
||||||
|
[operation: <integer>, <proc operation string>]
|
||||||
|
[flags: <integer>
|
||||||
|
<proc flags strings>]
|
||||||
|
[level: <integer>]
|
||||||
|
[version_info: <integer>]
|
||||||
|
[processor_id: <integer>]
|
||||||
|
[target_address: <integer>]
|
||||||
|
[requestor_id: <integer>]
|
||||||
|
[responder_id: <integer>]
|
||||||
|
[IP: <integer>]
|
||||||
|
|
||||||
|
<proc type string>* := IA32/X64 | IA64
|
||||||
|
|
||||||
|
<proc isa string>* := IA32 | IA64 | X64
|
||||||
|
|
||||||
|
<processor error type strings># :=
|
||||||
|
[cache error][, TLB error][, bus error][, micro-architectural error]
|
||||||
|
|
||||||
|
<proc operation string>* := unknown or generic | data read | data write | \
|
||||||
|
instruction execution
|
||||||
|
|
||||||
|
<proc flags strings># :=
|
||||||
|
[restartable][, precise IP][, overflow][, corrected]
|
||||||
|
|
||||||
|
<memory section data> :=
|
||||||
|
[error_status: <integer>]
|
||||||
|
[physical_address: <integer>]
|
||||||
|
[physical_address_mask: <integer>]
|
||||||
|
[node: <integer>]
|
||||||
|
[card: <integer>]
|
||||||
|
[module: <integer>]
|
||||||
|
[bank: <integer>]
|
||||||
|
[device: <integer>]
|
||||||
|
[row: <integer>]
|
||||||
|
[column: <integer>]
|
||||||
|
[bit_position: <integer>]
|
||||||
|
[requestor_id: <integer>]
|
||||||
|
[responder_id: <integer>]
|
||||||
|
[target_id: <integer>]
|
||||||
|
[error_type: <integer>, <mem error type string>]
|
||||||
|
|
||||||
|
<mem error type string>* :=
|
||||||
|
unknown | no error | single-bit ECC | multi-bit ECC | \
|
||||||
|
single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \
|
||||||
|
target abort | parity error | watchdog timeout | invalid address | \
|
||||||
|
mirror Broken | memory sparing | scrub corrected error | \
|
||||||
|
scrub uncorrected error
|
||||||
|
|
||||||
|
<pcie section data> :=
|
||||||
|
[port_type: <integer>, <pcie port type string>]
|
||||||
|
[version: <integer>.<integer>]
|
||||||
|
[command: <integer>, status: <integer>]
|
||||||
|
[device_id: <integer>:<integer>:<integer>.<integer>
|
||||||
|
slot: <integer>
|
||||||
|
secondary_bus: <integer>
|
||||||
|
vendor_id: <integer>, device_id: <integer>
|
||||||
|
class_code: <integer>]
|
||||||
|
[serial number: <integer>, <integer>]
|
||||||
|
[bridge: secondary_status: <integer>, control: <integer>]
|
||||||
|
|
||||||
|
<pcie port type string>* := PCIe end point | legacy PCI end point | \
|
||||||
|
unknown | unknown | root port | upstream switch port | \
|
||||||
|
downstream switch port | PCIe to PCI/PCI-X bridge | \
|
||||||
|
PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \
|
||||||
|
root complex event collector
|
||||||
|
|
||||||
|
Where, [] designate corresponding content is optional
|
||||||
|
|
||||||
|
All <field string> description with * has the following format:
|
||||||
|
|
||||||
|
field: <integer>, <field string>
|
||||||
|
|
||||||
|
Where value of <integer> should be the position of "string" in <field
|
||||||
|
string> description. Otherwise, <field string> will be "unknown".
|
||||||
|
|
||||||
|
All <field strings> description with # has the following format:
|
||||||
|
|
||||||
|
field: <integer>
|
||||||
|
<field strings>
|
||||||
|
|
||||||
|
Where each string in <fields strings> corresponding to one set bit of
|
||||||
|
<integer>. The bit position is the position of "string" in <field
|
||||||
|
strings> description.
|
||||||
|
|
||||||
|
For more detailed explanation of every field, please refer to UEFI
|
||||||
|
specification version 2.3 or later, section Appendix N: Common
|
||||||
|
Platform Error Record.
|
@ -89,6 +89,33 @@ Throttling/Upper Limit policy
|
|||||||
|
|
||||||
Limits for writes can be put using blkio.write_bps_device file.
|
Limits for writes can be put using blkio.write_bps_device file.
|
||||||
|
|
||||||
|
Hierarchical Cgroups
|
||||||
|
====================
|
||||||
|
- Currently none of the IO control policy supports hierarhical groups. But
|
||||||
|
cgroup interface does allow creation of hierarhical cgroups and internally
|
||||||
|
IO policies treat them as flat hierarchy.
|
||||||
|
|
||||||
|
So this patch will allow creation of cgroup hierarhcy but at the backend
|
||||||
|
everything will be treated as flat. So if somebody created a hierarchy like
|
||||||
|
as follows.
|
||||||
|
|
||||||
|
root
|
||||||
|
/ \
|
||||||
|
test1 test2
|
||||||
|
|
|
||||||
|
test3
|
||||||
|
|
||||||
|
CFQ and throttling will practically treat all groups at same level.
|
||||||
|
|
||||||
|
pivot
|
||||||
|
/ | \ \
|
||||||
|
root test1 test2 test3
|
||||||
|
|
||||||
|
Down the line we can implement hierarchical accounting/control support
|
||||||
|
and also introduce a new cgroup file "use_hierarchy" which will control
|
||||||
|
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
|
||||||
|
This is how memory controller also has implemented the things.
|
||||||
|
|
||||||
Various user visible config options
|
Various user visible config options
|
||||||
===================================
|
===================================
|
||||||
CONFIG_BLK_CGROUP
|
CONFIG_BLK_CGROUP
|
||||||
|
@ -91,7 +91,7 @@ int main(int argc, char **argv)
|
|||||||
|
|
||||||
if (ret == -1) {
|
if (ret == -1) {
|
||||||
perror("cgroup.event_control "
|
perror("cgroup.event_control "
|
||||||
"is not accessable any more");
|
"is not accessible any more");
|
||||||
break;
|
break;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -355,13 +355,13 @@ subsystems, type:
|
|||||||
|
|
||||||
To change the set of subsystems bound to a mounted hierarchy, just
|
To change the set of subsystems bound to a mounted hierarchy, just
|
||||||
remount with different options:
|
remount with different options:
|
||||||
# mount -o remount,cpuset,ns hier1 /dev/cgroup
|
# mount -o remount,cpuset,blkio hier1 /dev/cgroup
|
||||||
|
|
||||||
Now memory is removed from the hierarchy and ns is added.
|
Now memory is removed from the hierarchy and blkio is added.
|
||||||
|
|
||||||
Note this will add ns to the hierarchy but won't remove memory or
|
Note this will add blkio to the hierarchy but won't remove memory or
|
||||||
cpuset, because the new options are appended to the old ones:
|
cpuset, because the new options are appended to the old ones:
|
||||||
# mount -o remount,ns /dev/cgroup
|
# mount -o remount,blkio /dev/cgroup
|
||||||
|
|
||||||
To Specify a hierarchy's release_agent:
|
To Specify a hierarchy's release_agent:
|
||||||
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
|
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
|
||||||
|
@ -398,7 +398,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
|||||||
written to move_charge_at_immigrate.
|
written to move_charge_at_immigrate.
|
||||||
|
|
||||||
9.10 Memory thresholds
|
9.10 Memory thresholds
|
||||||
Memory controler implements memory thresholds using cgroups notification
|
Memory controller implements memory thresholds using cgroups notification
|
||||||
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
|
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
|
||||||
it.
|
it.
|
||||||
|
|
||||||
|
@ -36,6 +36,10 @@ as a regular user, and install it with
|
|||||||
|
|
||||||
sudo make install
|
sudo make install
|
||||||
|
|
||||||
|
The semantic patches in the kernel will work best with Coccinelle version
|
||||||
|
0.2.4 or later. Using earlier versions may incur some parse errors in the
|
||||||
|
semantic patch code, but any results that are obtained should still be
|
||||||
|
correct.
|
||||||
|
|
||||||
Using Coccinelle on the Linux kernel
|
Using Coccinelle on the Linux kernel
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -8,7 +8,7 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>
|
|||||||
|
|
||||||
<cipher>
|
<cipher>
|
||||||
Encryption cipher and an optional IV generation mode.
|
Encryption cipher and an optional IV generation mode.
|
||||||
(In format cipher-chainmode-ivopts:ivmode).
|
(In format cipher[:keycount]-chainmode-ivopts:ivmode).
|
||||||
Examples:
|
Examples:
|
||||||
des
|
des
|
||||||
aes-cbc-essiv:sha256
|
aes-cbc-essiv:sha256
|
||||||
@ -20,6 +20,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>
|
|||||||
Key used for encryption. It is encoded as a hexadecimal number.
|
Key used for encryption. It is encoded as a hexadecimal number.
|
||||||
You can only use key sizes that are valid for the selected cipher.
|
You can only use key sizes that are valid for the selected cipher.
|
||||||
|
|
||||||
|
<keycount>
|
||||||
|
Multi-key compatibility mode. You can define <keycount> keys and
|
||||||
|
then sectors are encrypted according to their offsets (sector 0 uses key0;
|
||||||
|
sector 1 uses key1 etc.). <keycount> must be a power of two.
|
||||||
|
|
||||||
<iv_offset>
|
<iv_offset>
|
||||||
The IV offset is a sector count that is added to the sector number
|
The IV offset is a sector count that is added to the sector number
|
||||||
before creating the IV.
|
before creating the IV.
|
||||||
|
70
Documentation/device-mapper/dm-raid.txt
Normal file
70
Documentation/device-mapper/dm-raid.txt
Normal file
@ -0,0 +1,70 @@
|
|||||||
|
Device-mapper RAID (dm-raid) is a bridge from DM to MD. It
|
||||||
|
provides a way to use device-mapper interfaces to access the MD RAID
|
||||||
|
drivers.
|
||||||
|
|
||||||
|
As with all device-mapper targets, the nominal public interfaces are the
|
||||||
|
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
|
||||||
|
and STATUSTYPE_TABLE). The CTR table looks like the following:
|
||||||
|
|
||||||
|
1: <s> <l> raid \
|
||||||
|
2: <raid_type> <#raid_params> <raid_params> \
|
||||||
|
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
|
||||||
|
|
||||||
|
Line 1 contains the standard first three arguments to any device-mapper
|
||||||
|
target - the start, length, and target type fields. The target type in
|
||||||
|
this case is "raid".
|
||||||
|
|
||||||
|
Line 2 contains the arguments that define the particular raid
|
||||||
|
type/personality/level, the required arguments for that raid type, and
|
||||||
|
any optional arguments. Possible raid types include: raid4, raid5_la,
|
||||||
|
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (raid1 is
|
||||||
|
planned for the future.) The list of required and optional parameters
|
||||||
|
is the same for all the current raid types. The required parameters are
|
||||||
|
positional, while the optional parameters are given as key/value pairs.
|
||||||
|
The possible parameters are as follows:
|
||||||
|
<chunk_size> Chunk size in sectors.
|
||||||
|
[[no]sync] Force/Prevent RAID initialization
|
||||||
|
[rebuild <idx>] Rebuild the drive indicated by the index
|
||||||
|
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
|
||||||
|
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
|
||||||
|
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
|
||||||
|
[max_write_behind <sectors>] See '-write-behind=' (man mdadm)
|
||||||
|
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
|
||||||
|
|
||||||
|
Line 3 contains the list of devices that compose the array in
|
||||||
|
metadata/data device pairs. If the metadata is stored separately, a '-'
|
||||||
|
is given for the metadata device position. If a drive has failed or is
|
||||||
|
missing at creation time, a '-' can be given for both the metadata and
|
||||||
|
data drives for a given position.
|
||||||
|
|
||||||
|
NB. Currently all metadata devices must be specified as '-'.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
# RAID4 - 4 data drives, 1 parity
|
||||||
|
# No metadata devices specified to hold superblock/bitmap info
|
||||||
|
# Chunk size of 1MiB
|
||||||
|
# (Lines separated for easy reading)
|
||||||
|
0 1960893648 raid \
|
||||||
|
raid4 1 2048 \
|
||||||
|
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
|
||||||
|
|
||||||
|
# RAID4 - 4 data drives, 1 parity (no metadata devices)
|
||||||
|
# Chunk size of 1MiB, force RAID initialization,
|
||||||
|
# min recovery rate at 20 kiB/sec/disk
|
||||||
|
0 1960893648 raid \
|
||||||
|
raid4 4 2048 min_recovery_rate 20 sync\
|
||||||
|
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
|
||||||
|
|
||||||
|
Performing a 'dmsetup table' should display the CTR table used to
|
||||||
|
construct the mapping (with possible reordering of optional
|
||||||
|
parameters).
|
||||||
|
|
||||||
|
Performing a 'dmsetup status' will yield information on the state and
|
||||||
|
health of the array. The output is as follows:
|
||||||
|
1: <s> <l> raid \
|
||||||
|
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
|
||||||
|
|
||||||
|
Line 1 is standard DM output. Line 2 is best shown by example:
|
||||||
|
0 1960893648 raid raid4 5 AAAAA 2/490221568
|
||||||
|
Here we can see the RAID type is raid4, there are 5 devices - all of
|
||||||
|
which are 'A'live, and the array is 2/490221568 complete with recovery.
|
28
Documentation/devicetree/bindings/eeprom.txt
Normal file
28
Documentation/devicetree/bindings/eeprom.txt
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
EEPROMs (I2C)
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
|
||||||
|
- compatible : should be "<manufacturer>,<type>"
|
||||||
|
If there is no specific driver for <manufacturer>, a generic
|
||||||
|
driver based on <type> is selected. Possible types are:
|
||||||
|
24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64,
|
||||||
|
24c128, 24c256, 24c512, 24c1024, spd
|
||||||
|
|
||||||
|
- reg : the I2C address of the EEPROM
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
|
||||||
|
- pagesize : the length of the pagesize for writing. Please consult the
|
||||||
|
manual of your device, that value varies a lot. A wrong value
|
||||||
|
may result in data loss! If not specified, a safety value of
|
||||||
|
'1' is used which will be very slow.
|
||||||
|
|
||||||
|
- read-only: this parameterless property disables writes to the eeprom
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
eeprom@52 {
|
||||||
|
compatible = "atmel,24c32";
|
||||||
|
reg = <0x52>;
|
||||||
|
pagesize = <32>;
|
||||||
|
};
|
52
Documentation/devicetree/bindings/powerpc/4xx/cpm.txt
Normal file
52
Documentation/devicetree/bindings/powerpc/4xx/cpm.txt
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
PPC4xx Clock Power Management (CPM) node
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : compatible list, currently only "ibm,cpm"
|
||||||
|
- dcr-access-method : "native"
|
||||||
|
- dcr-reg : < DCR register range >
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- er-offset : All 4xx SoCs with a CPM controller have
|
||||||
|
one of two different order for the CPM
|
||||||
|
registers. Some have the CPM registers
|
||||||
|
in the following order (ER,FR,SR). The
|
||||||
|
others have them in the following order
|
||||||
|
(SR,ER,FR). For the second case set
|
||||||
|
er-offset = <1>.
|
||||||
|
- unused-units : specifier consist of one cell. For each
|
||||||
|
bit in the cell, the corresponding bit
|
||||||
|
in CPM will be set to turn off unused
|
||||||
|
devices.
|
||||||
|
- idle-doze : specifier consist of one cell. For each
|
||||||
|
bit in the cell, the corresponding bit
|
||||||
|
in CPM will be set to turn off unused
|
||||||
|
devices. This is usually just CPM[CPU].
|
||||||
|
- standby : specifier consist of one cell. For each
|
||||||
|
bit in the cell, the corresponding bit
|
||||||
|
in CPM will be set on standby and
|
||||||
|
restored on resume.
|
||||||
|
- suspend : specifier consist of one cell. For each
|
||||||
|
bit in the cell, the corresponding bit
|
||||||
|
in CPM will be set on suspend (mem) and
|
||||||
|
restored on resume. Note, for standby
|
||||||
|
and suspend the corresponding bits can
|
||||||
|
be different or the same. Usually for
|
||||||
|
standby only class 2 and 3 units are set.
|
||||||
|
However, the interface does not care.
|
||||||
|
If they are the same, the additional
|
||||||
|
power saving will be seeing if support
|
||||||
|
is available to put the DDR in self
|
||||||
|
refresh mode and any additional power
|
||||||
|
saving techniques for the specific SoC.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
CPM0: cpm {
|
||||||
|
compatible = "ibm,cpm";
|
||||||
|
dcr-access-method = "native";
|
||||||
|
dcr-reg = <0x160 0x003>;
|
||||||
|
er-offset = <0>;
|
||||||
|
unused-units = <0x00000100>;
|
||||||
|
idle-doze = <0x02000000>;
|
||||||
|
standby = <0xfeff0000>;
|
||||||
|
suspend = <0xfeff791d>;
|
||||||
|
};
|
@ -13,7 +13,6 @@ Table of Contents
|
|||||||
|
|
||||||
I - Introduction
|
I - Introduction
|
||||||
1) Entry point for arch/powerpc
|
1) Entry point for arch/powerpc
|
||||||
2) Board support
|
|
||||||
|
|
||||||
II - The DT block format
|
II - The DT block format
|
||||||
1) Header
|
1) Header
|
||||||
@ -41,13 +40,6 @@ Table of Contents
|
|||||||
VI - System-on-a-chip devices and nodes
|
VI - System-on-a-chip devices and nodes
|
||||||
1) Defining child nodes of an SOC
|
1) Defining child nodes of an SOC
|
||||||
2) Representing devices without a current OF specification
|
2) Representing devices without a current OF specification
|
||||||
a) PHY nodes
|
|
||||||
b) Interrupt controllers
|
|
||||||
c) 4xx/Axon EMAC ethernet nodes
|
|
||||||
d) Xilinx IP cores
|
|
||||||
e) USB EHCI controllers
|
|
||||||
f) MDIO on GPIOs
|
|
||||||
g) SPI busses
|
|
||||||
|
|
||||||
VII - Specifying interrupt information for devices
|
VII - Specifying interrupt information for devices
|
||||||
1) interrupts property
|
1) interrupts property
|
||||||
@ -123,7 +115,7 @@ Revision Information
|
|||||||
I - Introduction
|
I - Introduction
|
||||||
================
|
================
|
||||||
|
|
||||||
During the recent development of the Linux/ppc64 kernel, and more
|
During the development of the Linux/ppc64 kernel, and more
|
||||||
specifically, the addition of new platform types outside of the old
|
specifically, the addition of new platform types outside of the old
|
||||||
IBM pSeries/iSeries pair, it was decided to enforce some strict rules
|
IBM pSeries/iSeries pair, it was decided to enforce some strict rules
|
||||||
regarding the kernel entry and bootloader <-> kernel interfaces, in
|
regarding the kernel entry and bootloader <-> kernel interfaces, in
|
||||||
@ -131,7 +123,7 @@ order to avoid the degeneration that had become the ppc32 kernel entry
|
|||||||
point and the way a new platform should be added to the kernel. The
|
point and the way a new platform should be added to the kernel. The
|
||||||
legacy iSeries platform breaks those rules as it predates this scheme,
|
legacy iSeries platform breaks those rules as it predates this scheme,
|
||||||
but no new board support will be accepted in the main tree that
|
but no new board support will be accepted in the main tree that
|
||||||
doesn't follows them properly. In addition, since the advent of the
|
doesn't follow them properly. In addition, since the advent of the
|
||||||
arch/powerpc merged architecture for ppc32 and ppc64, new 32-bit
|
arch/powerpc merged architecture for ppc32 and ppc64, new 32-bit
|
||||||
platforms and 32-bit platforms which move into arch/powerpc will be
|
platforms and 32-bit platforms which move into arch/powerpc will be
|
||||||
required to use these rules as well.
|
required to use these rules as well.
|
||||||
@ -146,7 +138,7 @@ 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 informations and memory/IO ranges, among others. It is also
|
||||||
recommended to define nodes for on chip devices and other busses 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
|
||||||
drivers to device, without having to hard code all sorts of tables. It
|
drivers to device, without having to hard code all sorts of tables. It
|
||||||
@ -158,7 +150,7 @@ it with special cases.
|
|||||||
1) Entry point for arch/powerpc
|
1) Entry point for arch/powerpc
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
There is one and one single entry point to the kernel, at the start
|
There is one single entry point to the kernel, at the start
|
||||||
of the kernel image. That entry point supports two calling
|
of the kernel image. That entry point supports two calling
|
||||||
conventions:
|
conventions:
|
||||||
|
|
||||||
@ -210,12 +202,6 @@ it with special cases.
|
|||||||
with all CPUs. The way to do that with method b) will be
|
with all CPUs. The way to do that with method b) will be
|
||||||
described in a later revision of this document.
|
described in a later revision of this document.
|
||||||
|
|
||||||
|
|
||||||
2) Board support
|
|
||||||
----------------
|
|
||||||
|
|
||||||
64-bit kernels:
|
|
||||||
|
|
||||||
Board supports (platforms) are not exclusive config options. An
|
Board supports (platforms) are not exclusive config options. An
|
||||||
arbitrary set of board supports can be built in a single kernel
|
arbitrary set of board supports can be built in a single kernel
|
||||||
image. The kernel will "know" what set of functions to use for a
|
image. The kernel will "know" what set of functions to use for a
|
||||||
@ -234,48 +220,11 @@ it with special cases.
|
|||||||
containing the various callbacks that the generic code will
|
containing the various callbacks that the generic code will
|
||||||
use to get to your platform specific code
|
use to get to your platform specific code
|
||||||
|
|
||||||
c) Add a reference to your "ppc_md" structure in the
|
A kernel image may support multiple platforms, but only if the
|
||||||
"machines" table in arch/powerpc/kernel/setup_64.c if you are
|
|
||||||
a 64-bit platform.
|
|
||||||
|
|
||||||
d) request and get assigned a platform number (see PLATFORM_*
|
|
||||||
constants in arch/powerpc/include/asm/processor.h
|
|
||||||
|
|
||||||
32-bit embedded kernels:
|
|
||||||
|
|
||||||
Currently, board support is essentially an exclusive config option.
|
|
||||||
The kernel is configured for a single platform. Part of the reason
|
|
||||||
for this is to keep kernels on embedded systems small and efficient;
|
|
||||||
part of this is due to the fact the code is already that way. In the
|
|
||||||
future, a kernel may support multiple platforms, but only if the
|
|
||||||
platforms feature the same core architecture. A single kernel build
|
platforms feature the same core architecture. A single kernel build
|
||||||
cannot support both configurations with Book E and configurations
|
cannot support both configurations with Book E and configurations
|
||||||
with classic Powerpc architectures.
|
with classic Powerpc architectures.
|
||||||
|
|
||||||
32-bit embedded platforms that are moved into arch/powerpc using a
|
|
||||||
flattened device tree should adopt the merged tree practice of
|
|
||||||
setting ppc_md up dynamically, even though the kernel is currently
|
|
||||||
built with support for only a single platform at a time. This allows
|
|
||||||
unification of the setup code, and will make it easier to go to a
|
|
||||||
multiple-platform-support model in the future.
|
|
||||||
|
|
||||||
NOTE: I believe the above will be true once Ben's done with the merge
|
|
||||||
of the boot sequences.... someone speak up if this is wrong!
|
|
||||||
|
|
||||||
To add a 32-bit embedded platform support, follow the instructions
|
|
||||||
for 64-bit platforms above, with the exception that the Kconfig
|
|
||||||
option should be set up such that the kernel builds exclusively for
|
|
||||||
the platform selected. The processor type for the platform should
|
|
||||||
enable another config option to select the specific board
|
|
||||||
supported.
|
|
||||||
|
|
||||||
NOTE: If Ben doesn't merge the setup files, may need to change this to
|
|
||||||
point to setup_32.c
|
|
||||||
|
|
||||||
|
|
||||||
I will describe later the boot process and various callbacks that
|
|
||||||
your platform should implement.
|
|
||||||
|
|
||||||
|
|
||||||
II - The DT block format
|
II - The DT block format
|
||||||
========================
|
========================
|
||||||
@ -300,8 +249,8 @@ the block to RAM before passing it to the kernel.
|
|||||||
1) Header
|
1) Header
|
||||||
---------
|
---------
|
||||||
|
|
||||||
The kernel is entered with r3 pointing to an area of memory that is
|
The kernel is passed the physical address pointing to an area of memory
|
||||||
roughly described in arch/powerpc/include/asm/prom.h by the structure
|
that is roughly described in include/linux/of_fdt.h by the structure
|
||||||
boot_param_header:
|
boot_param_header:
|
||||||
|
|
||||||
struct boot_param_header {
|
struct boot_param_header {
|
||||||
@ -339,7 +288,7 @@ struct boot_param_header {
|
|||||||
All values in this header are in big endian format, the various
|
All values in this header are in big endian format, the various
|
||||||
fields in this header are defined more precisely below. All
|
fields in this header are defined more precisely below. All
|
||||||
"offset" values are in bytes from the start of the header; that is
|
"offset" values are in bytes from the start of the header; that is
|
||||||
from the value of r3.
|
from the physical base address of the device tree block.
|
||||||
|
|
||||||
- magic
|
- magic
|
||||||
|
|
||||||
@ -437,7 +386,7 @@ struct boot_param_header {
|
|||||||
|
|
||||||
|
|
||||||
------------------------------
|
------------------------------
|
||||||
r3 -> | struct boot_param_header |
|
base -> | struct boot_param_header |
|
||||||
------------------------------
|
------------------------------
|
||||||
| (alignment gap) (*) |
|
| (alignment gap) (*) |
|
||||||
------------------------------
|
------------------------------
|
||||||
@ -457,7 +406,7 @@ struct boot_param_header {
|
|||||||
-----> ------------------------------
|
-----> ------------------------------
|
||||||
|
|
|
|
||||||
|
|
|
|
||||||
--- (r3 + totalsize)
|
--- (base + totalsize)
|
||||||
|
|
||||||
(*) The alignment gaps are not necessarily present; their presence
|
(*) The alignment gaps are not necessarily present; their presence
|
||||||
and size are dependent on the various alignment requirements of
|
and size are dependent on the various alignment requirements of
|
||||||
@ -500,7 +449,7 @@ the device-tree structure. It is typically used to represent "path" in
|
|||||||
the device-tree. More details about the actual format of these will be
|
the device-tree. More details about the actual format of these will be
|
||||||
below.
|
below.
|
||||||
|
|
||||||
The kernel powerpc generic code does not make any formal use of the
|
The kernel generic code does not make any formal use of the
|
||||||
unit address (though some board support code may do) so the only real
|
unit address (though some board support code may do) so the only real
|
||||||
requirement here for the unit address is to ensure uniqueness of
|
requirement here for the unit address is to ensure uniqueness of
|
||||||
the node unit name at a given level of the tree. Nodes with no notion
|
the node unit name at a given level of the tree. Nodes with no notion
|
||||||
@ -518,20 +467,21 @@ path to the root node is "/".
|
|||||||
|
|
||||||
Every node which actually represents an actual device (that is, a node
|
Every node which actually represents an actual device (that is, a node
|
||||||
which isn't only a virtual "container" for more nodes, like "/cpus"
|
which isn't only a virtual "container" for more nodes, like "/cpus"
|
||||||
is) is also required to have a "device_type" property indicating the
|
is) is also required to have a "compatible" property indicating the
|
||||||
type of node .
|
specific hardware and an optional list of devices it is fully
|
||||||
|
backwards compatible with.
|
||||||
|
|
||||||
Finally, every node that can be referenced from a property in another
|
Finally, every node that can be referenced from a property in another
|
||||||
node is required to have a "linux,phandle" property. Real open
|
node is required to have either a "phandle" or a "linux,phandle"
|
||||||
firmware implementations provide a unique "phandle" value for every
|
property. Real Open Firmware implementations provide a unique
|
||||||
node that the "prom_init()" trampoline code turns into
|
"phandle" value for every node that the "prom_init()" trampoline code
|
||||||
"linux,phandle" properties. However, this is made optional if the
|
turns into "linux,phandle" properties. However, this is made optional
|
||||||
flattened device tree is used directly. An example of a node
|
if the flattened device tree is used directly. An example of a node
|
||||||
referencing another node via "phandle" is when laying out the
|
referencing another node via "phandle" is when laying out the
|
||||||
interrupt tree which will be described in a further version of this
|
interrupt tree which will be described in a further version of this
|
||||||
document.
|
document.
|
||||||
|
|
||||||
This "linux, phandle" property is a 32-bit value that uniquely
|
The "phandle" property is a 32-bit value that uniquely
|
||||||
identifies a node. You are free to use whatever values or system of
|
identifies a node. You are free to use whatever values or system of
|
||||||
values, internal pointers, or whatever to generate these, the only
|
values, internal pointers, or whatever to generate these, the only
|
||||||
requirement is that every node for which you provide that property has
|
requirement is that every node for which you provide that property has
|
||||||
@ -694,7 +644,7 @@ made of 3 cells, the bottom two containing the actual address itself
|
|||||||
while the top cell contains address space indication, flags, and pci
|
while the top cell contains address space indication, flags, and pci
|
||||||
bus & device numbers.
|
bus & device numbers.
|
||||||
|
|
||||||
For busses that support dynamic allocation, it's the accepted practice
|
For buses that support dynamic allocation, it's the accepted practice
|
||||||
to then not provide the address in "reg" (keep it 0) though while
|
to then not provide the address in "reg" (keep it 0) though while
|
||||||
providing a flag indicating the address is dynamically allocated, and
|
providing a flag indicating the address is dynamically allocated, and
|
||||||
then, to provide a separate "assigned-addresses" property that
|
then, to provide a separate "assigned-addresses" property that
|
||||||
@ -711,7 +661,7 @@ prom_parse.c file of the recent kernels for your bus type.
|
|||||||
The "reg" property only defines addresses and sizes (if #size-cells is
|
The "reg" property only defines addresses and sizes (if #size-cells is
|
||||||
non-0) within a given bus. In order to translate addresses upward
|
non-0) within a given bus. In order to translate addresses upward
|
||||||
(that is into parent bus addresses, and possibly into CPU physical
|
(that is into parent bus addresses, and possibly into CPU physical
|
||||||
addresses), all busses must contain a "ranges" property. If the
|
addresses), all buses must contain a "ranges" property. If the
|
||||||
"ranges" property is missing at a given level, it's assumed that
|
"ranges" property is missing at a given level, it's assumed that
|
||||||
translation isn't possible, i.e., the registers are not visible on the
|
translation isn't possible, i.e., the registers are not visible on the
|
||||||
parent bus. The format of the "ranges" property for a bus is a list
|
parent bus. The format of the "ranges" property for a bus is a list
|
||||||
@ -727,9 +677,9 @@ example, for a PCI host controller, that would be a CPU address. For a
|
|||||||
PCI<->ISA bridge, that would be a PCI address. It defines the base
|
PCI<->ISA bridge, that would be a PCI address. It defines the base
|
||||||
address in the parent bus where the beginning of that range is mapped.
|
address in the parent bus where the beginning of that range is mapped.
|
||||||
|
|
||||||
For a new 64-bit powerpc board, I recommend either the 2/2 format or
|
For new 64-bit board support, I recommend either the 2/2 format or
|
||||||
Apple's 2/1 format which is slightly more compact since sizes usually
|
Apple's 2/1 format which is slightly more compact since sizes usually
|
||||||
fit in a single 32-bit word. New 32-bit powerpc boards should use a
|
fit in a single 32-bit word. New 32-bit board support should use a
|
||||||
1/1 format, unless the processor supports physical addresses greater
|
1/1 format, unless the processor supports physical addresses greater
|
||||||
than 32-bits, in which case a 2/1 format is recommended.
|
than 32-bits, in which case a 2/1 format is recommended.
|
||||||
|
|
||||||
@ -754,7 +704,7 @@ of their actual names.
|
|||||||
While earlier users of Open Firmware like OldWorld macintoshes tended
|
While earlier users of Open Firmware like OldWorld macintoshes tended
|
||||||
to use the actual device name for the "name" property, it's nowadays
|
to use the actual device name for the "name" property, it's nowadays
|
||||||
considered a good practice to use a name that is closer to the device
|
considered a good practice to use a name that is closer to the device
|
||||||
class (often equal to device_type). For example, nowadays, ethernet
|
class (often equal to device_type). For example, nowadays, Ethernet
|
||||||
controllers are named "ethernet", an additional "model" property
|
controllers are named "ethernet", an additional "model" property
|
||||||
defining precisely the chip type/model, and "compatible" property
|
defining precisely the chip type/model, and "compatible" property
|
||||||
defining the family in case a single driver can driver more than one
|
defining the family in case a single driver can driver more than one
|
||||||
@ -772,7 +722,7 @@ is present).
|
|||||||
4) Note about node and property names and character set
|
4) Note about node and property names and character set
|
||||||
-------------------------------------------------------
|
-------------------------------------------------------
|
||||||
|
|
||||||
While open firmware provides more flexible usage of 8859-1, this
|
While Open Firmware provides more flexible usage of 8859-1, this
|
||||||
specification enforces more strict rules. Nodes and properties should
|
specification enforces more strict rules. Nodes and properties should
|
||||||
be comprised only of ASCII characters 'a' to 'z', '0' to
|
be comprised only of ASCII characters 'a' to 'z', '0' to
|
||||||
'9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally
|
'9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally
|
||||||
@ -792,7 +742,7 @@ address which can extend beyond that limit.
|
|||||||
--------------------------------
|
--------------------------------
|
||||||
These are all that are currently required. However, it is strongly
|
These are all that are currently required. However, it is strongly
|
||||||
recommended that you expose PCI host bridges as documented in the
|
recommended that you expose PCI host bridges as documented in the
|
||||||
PCI binding to open firmware, and your interrupt tree as documented
|
PCI binding to Open Firmware, and your interrupt tree as documented
|
||||||
in OF interrupt tree specification.
|
in OF interrupt tree specification.
|
||||||
|
|
||||||
a) The root node
|
a) The root node
|
||||||
@ -802,20 +752,12 @@ address which can extend beyond that limit.
|
|||||||
- model : this is your board name/model
|
- model : this is your board name/model
|
||||||
- #address-cells : address representation for "root" devices
|
- #address-cells : address representation for "root" devices
|
||||||
- #size-cells: the size representation for "root" devices
|
- #size-cells: the size representation for "root" devices
|
||||||
- device_type : This property shouldn't be necessary. However, if
|
|
||||||
you decide to create a device_type for your root node, make sure it
|
|
||||||
is _not_ "chrp" unless your platform is a pSeries or PAPR compliant
|
|
||||||
one for 64-bit, or a CHRP-type machine for 32-bit as this will
|
|
||||||
matched by the kernel this way.
|
|
||||||
|
|
||||||
Additionally, some recommended properties are:
|
|
||||||
|
|
||||||
- compatible : the board "family" generally finds its way here,
|
- compatible : the board "family" generally finds its way here,
|
||||||
for example, if you have 2 board models with a similar layout,
|
for example, if you have 2 board models with a similar layout,
|
||||||
that typically get driven by the same platform code in the
|
that typically get driven by the same platform code in the
|
||||||
kernel, you would use a different "model" property but put a
|
kernel, you would specify the exact board model in the
|
||||||
value in "compatible". The kernel doesn't directly use that
|
compatible property followed by an entry that represents the SoC
|
||||||
value but it is generally useful.
|
model.
|
||||||
|
|
||||||
The root node is also generally where you add additional properties
|
The root node is also generally where you add additional properties
|
||||||
specific to your board like the serial number if any, that sort of
|
specific to your board like the serial number if any, that sort of
|
||||||
@ -841,8 +783,11 @@ address which can extend beyond that limit.
|
|||||||
|
|
||||||
So under /cpus, you are supposed to create a node for every CPU on
|
So under /cpus, you are supposed to create a node for every CPU on
|
||||||
the machine. There is no specific restriction on the name of the
|
the machine. There is no specific restriction on the name of the
|
||||||
CPU, though It's common practice to call it PowerPC,<name>. For
|
CPU, though it's common to call it <architecture>,<core>. For
|
||||||
example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX.
|
example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX.
|
||||||
|
However, the Generic Names convention suggests that it would be
|
||||||
|
better to simply use 'cpu' for each cpu node and use the compatible
|
||||||
|
property to identify the specific cpu core.
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
|
|
||||||
@ -923,7 +868,7 @@ compatibility.
|
|||||||
|
|
||||||
e) The /chosen node
|
e) The /chosen node
|
||||||
|
|
||||||
This node is a bit "special". Normally, that's where open firmware
|
This node is a bit "special". Normally, that's where Open Firmware
|
||||||
puts some variable environment information, like the arguments, or
|
puts some variable environment information, like the arguments, or
|
||||||
the default input/output devices.
|
the default input/output devices.
|
||||||
|
|
||||||
@ -940,11 +885,7 @@ compatibility.
|
|||||||
console device if any. Typically, if you have serial devices on
|
console device if any. Typically, if you have serial devices on
|
||||||
your board, you may want to put the full path to the one set as
|
your board, you may want to put the full path to the one set as
|
||||||
the default console in the firmware here, for the kernel to pick
|
the default console in the firmware here, for the kernel to pick
|
||||||
it up as its own default console. If you look at the function
|
it up as its own default console.
|
||||||
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
|
|
||||||
that the kernel tries to find out the default console and has
|
|
||||||
knowledge of various types like 8250 serial ports. You may want
|
|
||||||
to extend this function to add your own.
|
|
||||||
|
|
||||||
Note that u-boot creates and fills in the chosen node for platforms
|
Note that u-boot creates and fills in the chosen node for platforms
|
||||||
that use it.
|
that use it.
|
||||||
@ -955,23 +896,23 @@ compatibility.
|
|||||||
|
|
||||||
f) the /soc<SOCname> node
|
f) the /soc<SOCname> node
|
||||||
|
|
||||||
This node is used to represent a system-on-a-chip (SOC) and must be
|
This node is used to represent a system-on-a-chip (SoC) and must be
|
||||||
present if the processor is a SOC. The top-level soc node contains
|
present if the processor is a SoC. The top-level soc node contains
|
||||||
information that is global to all devices on the SOC. The node name
|
information that is global to all devices on the SoC. The node name
|
||||||
should contain a unit address for the SOC, which is the base address
|
should contain a unit address for the SoC, which is the base address
|
||||||
of the memory-mapped register set for the SOC. The name of an soc
|
of the memory-mapped register set for the SoC. The name of an SoC
|
||||||
node should start with "soc", and the remainder of the name should
|
node should start with "soc", and the remainder of the name should
|
||||||
represent the part number for the soc. For example, the MPC8540's
|
represent the part number for the soc. For example, the MPC8540's
|
||||||
soc node would be called "soc8540".
|
soc node would be called "soc8540".
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
|
|
||||||
- device_type : Should be "soc"
|
|
||||||
- ranges : Should be defined as specified in 1) to describe the
|
- ranges : Should be defined as specified in 1) to describe the
|
||||||
translation of SOC addresses for memory mapped SOC registers.
|
translation of SoC addresses for memory mapped SoC registers.
|
||||||
- bus-frequency: Contains the bus frequency for the SOC node.
|
- bus-frequency: Contains the bus frequency for the SoC node.
|
||||||
Typically, the value of this field is filled in by the boot
|
Typically, the value of this field is filled in by the boot
|
||||||
loader.
|
loader.
|
||||||
|
- compatible : Exact model of the SoC
|
||||||
|
|
||||||
|
|
||||||
Recommended properties:
|
Recommended properties:
|
||||||
@ -1025,7 +966,7 @@ dtc source code can be found at
|
|||||||
|
|
||||||
WARNING: This version is still in early development stage; the
|
WARNING: This version is still in early development stage; the
|
||||||
resulting device-tree "blobs" have not yet been validated with the
|
resulting device-tree "blobs" have not yet been validated with the
|
||||||
kernel. The current generated bloc lacks a useful reserve map (it will
|
kernel. The current generated block lacks a useful reserve map (it will
|
||||||
be fixed to generate an empty one, it's up to the bootloader to fill
|
be fixed to generate an empty one, it's up to the bootloader to fill
|
||||||
it up) among others. The error handling needs work, bugs are lurking,
|
it up) among others. The error handling needs work, bugs are lurking,
|
||||||
etc...
|
etc...
|
||||||
@ -1098,7 +1039,7 @@ supported currently at the toplevel.
|
|||||||
* an arbitrary array of bytes
|
* an arbitrary array of bytes
|
||||||
*/
|
*/
|
||||||
|
|
||||||
childnode@addresss { /* define a child node named "childnode"
|
childnode@address { /* define a child node named "childnode"
|
||||||
* whose unit name is "childnode at
|
* whose unit name is "childnode at
|
||||||
* address"
|
* address"
|
||||||
*/
|
*/
|
||||||
@ -1155,12 +1096,13 @@ while all this has been defined and implemented.
|
|||||||
|
|
||||||
- An example of code for iterating nodes & retrieving properties
|
- An example of code for iterating nodes & retrieving properties
|
||||||
directly from the flattened tree format can be found in the kernel
|
directly from the flattened tree format can be found in the kernel
|
||||||
file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function,
|
file drivers/of/fdt.c. Look at the of_scan_flat_dt() function,
|
||||||
its usage in early_init_devtree(), and the corresponding various
|
its usage in early_init_devtree(), and the corresponding various
|
||||||
early_init_dt_scan_*() callbacks. That code can be re-used in a
|
early_init_dt_scan_*() callbacks. That code can be re-used in a
|
||||||
GPL bootloader, and as the author of that code, I would be happy
|
GPL bootloader, and as the author of that code, I would be happy
|
||||||
to discuss possible free licensing to any vendor who wishes to
|
to discuss possible free licensing to any vendor who wishes to
|
||||||
integrate all or part of this code into a non-GPL bootloader.
|
integrate all or part of this code into a non-GPL bootloader.
|
||||||
|
(reference needed; who is 'I' here? ---gcl Jan 31, 2011)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -1203,18 +1145,19 @@ MPC8540.
|
|||||||
2) Representing devices without a current OF specification
|
2) Representing devices without a current OF specification
|
||||||
----------------------------------------------------------
|
----------------------------------------------------------
|
||||||
|
|
||||||
Currently, there are many devices on SOCs that do not have a standard
|
Currently, there are many devices on SoCs that do not have a standard
|
||||||
representation pre-defined as part of the open firmware
|
representation defined as part of the Open Firmware specifications,
|
||||||
specifications, mainly because the boards that contain these SOCs are
|
mainly because the boards that contain these SoCs are not currently
|
||||||
not currently booted using open firmware. This section contains
|
booted using Open Firmware. Binding documentation for new devices
|
||||||
descriptions for the SOC devices for which new nodes have been
|
should be added to the Documentation/devicetree/bindings directory.
|
||||||
defined; this list will expand as more and more SOC-containing
|
That directory will expand as device tree support is added to more and
|
||||||
platforms are moved over to use the flattened-device-tree model.
|
more SoCs.
|
||||||
|
|
||||||
|
|
||||||
VII - Specifying interrupt information for devices
|
VII - Specifying interrupt information for devices
|
||||||
===================================================
|
===================================================
|
||||||
|
|
||||||
The device tree represents the busses and devices of a hardware
|
The device tree represents the buses and devices of a hardware
|
||||||
system in a form similar to the physical bus topology of the
|
system in a form similar to the physical bus topology of the
|
||||||
hardware.
|
hardware.
|
||||||
|
|
@ -104,6 +104,13 @@ Then from the "Message" menu item, select insert file and choose your patch.
|
|||||||
As an added bonus you can customise the message creation toolbar menu
|
As an added bonus you can customise the message creation toolbar menu
|
||||||
and put the "insert file" icon there.
|
and put the "insert file" icon there.
|
||||||
|
|
||||||
|
Make the the composer window wide enough so that no lines wrap. As of
|
||||||
|
KMail 1.13.5 (KDE 4.5.4), KMail will apply word wrapping when sending
|
||||||
|
the email if the lines wrap in the composer window. Having word wrapping
|
||||||
|
disabled in the Options menu isn't enough. Thus, if your patch has very
|
||||||
|
long lines, you must make the composer window very wide before sending
|
||||||
|
the email. See: https://bugs.kde.org/show_bug.cgi?id=174034
|
||||||
|
|
||||||
You can safely GPG sign attachments, but inlined text is preferred for
|
You can safely GPG sign attachments, but inlined text is preferred for
|
||||||
patches so do not GPG sign them. Signing patches that have been inserted
|
patches so do not GPG sign them. Signing patches that have been inserted
|
||||||
as inlined text will make them tricky to extract from their 7-bit encoding.
|
as inlined text will make them tricky to extract from their 7-bit encoding.
|
||||||
@ -179,26 +186,8 @@ Sylpheed (GUI)
|
|||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
Thunderbird (GUI)
|
Thunderbird (GUI)
|
||||||
|
|
||||||
By default, thunderbird likes to mangle text, but there are ways to
|
Thunderbird is an Outlook clone that likes to mangle text, but there are ways
|
||||||
coerce it into being nice.
|
to coerce it into behaving.
|
||||||
|
|
||||||
- Under account settings, composition and addressing, uncheck "Compose
|
|
||||||
messages in HTML format".
|
|
||||||
|
|
||||||
- Edit your Thunderbird config settings to tell it not to wrap lines:
|
|
||||||
user_pref("mailnews.wraplength", 0);
|
|
||||||
|
|
||||||
- Edit your Thunderbird config settings so that it won't use format=flowed:
|
|
||||||
user_pref("mailnews.send_plaintext_flowed", false);
|
|
||||||
|
|
||||||
- You need to get Thunderbird into preformat mode:
|
|
||||||
. If you compose HTML messages by default, it's not too hard. Just select
|
|
||||||
"Preformat" from the drop-down box just under the subject line.
|
|
||||||
. If you compose in text by default, you have to tell it to compose a new
|
|
||||||
message in HTML (just as a one-off), and then force it from there back to
|
|
||||||
text, else it will wrap lines. To do this, use shift-click on the Write
|
|
||||||
icon to compose to get HTML compose mode, then select "Preformat" from
|
|
||||||
the drop-down box just under the subject line.
|
|
||||||
|
|
||||||
- Allows use of an external editor:
|
- Allows use of an external editor:
|
||||||
The easiest thing to do with Thunderbird and patches is to use an
|
The easiest thing to do with Thunderbird and patches is to use an
|
||||||
@ -208,6 +197,27 @@ coerce it into being nice.
|
|||||||
View->Toolbars->Customize... and finally just click on it when in the
|
View->Toolbars->Customize... and finally just click on it when in the
|
||||||
Compose dialog.
|
Compose dialog.
|
||||||
|
|
||||||
|
To beat some sense out of the internal editor, do this:
|
||||||
|
|
||||||
|
- Under account settings, composition and addressing, uncheck "Compose
|
||||||
|
messages in HTML format".
|
||||||
|
|
||||||
|
- Edit your Thunderbird config settings so that it won't use format=flowed.
|
||||||
|
Go to "edit->preferences->advanced->config editor" to bring up the
|
||||||
|
thunderbird's registry editor, and set "mailnews.send_plaintext_flowed" to
|
||||||
|
"false".
|
||||||
|
|
||||||
|
- Enable "preformat" mode: Shft-click on the Write icon to bring up the HTML
|
||||||
|
composer, select "Preformat" from the drop-down box just under the subject
|
||||||
|
line, then close the message without saving. (This setting also applies to
|
||||||
|
the text composer, but the only control for it is in the HTML composer.)
|
||||||
|
|
||||||
|
- Install the "toggle wordwrap" extension. Download the file from:
|
||||||
|
https://addons.mozilla.org/thunderbird/addon/2351/
|
||||||
|
Then go to "tools->add ons", select "install" at the bottom of the screen,
|
||||||
|
and browse to where you saved the .xul file. This adds an "Enable
|
||||||
|
Wordwrap" entry under the Options menu of the message composer.
|
||||||
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
TkRat (GUI)
|
TkRat (GUI)
|
||||||
|
|
||||||
|
@ -193,6 +193,20 @@ Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
|||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
What: CS5535/CS5536 obsolete GPIO driver
|
||||||
|
When: June 2011
|
||||||
|
Files: drivers/staging/cs5535_gpio/*
|
||||||
|
Check: drivers/staging/cs5535_gpio/cs5535_gpio.c
|
||||||
|
Why: A newer driver replaces this; it is drivers/gpio/cs5535-gpio.c, and
|
||||||
|
integrates with the Linux GPIO subsystem. The old driver has been
|
||||||
|
moved to staging, and will be removed altogether around 2.6.40.
|
||||||
|
Please test the new driver, and ensure that the functionality you
|
||||||
|
need and any bugfixes from the old driver are available in the new
|
||||||
|
one.
|
||||||
|
Who: Andres Salomon <dilinger@queued.net>
|
||||||
|
|
||||||
|
--------------------------
|
||||||
|
|
||||||
What: remove EXPORT_SYMBOL(kernel_thread)
|
What: remove EXPORT_SYMBOL(kernel_thread)
|
||||||
When: August 2006
|
When: August 2006
|
||||||
Files: arch/*/kernel/*_ksyms.c
|
Files: arch/*/kernel/*_ksyms.c
|
||||||
@ -234,6 +248,17 @@ Who: Zhang Rui <rui.zhang@intel.com>
|
|||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
What: CONFIG_ACPI_PROCFS_POWER
|
||||||
|
When: 2.6.39
|
||||||
|
Why: sysfs I/F for ACPI power devices, including AC and Battery,
|
||||||
|
has been working in upstream kenrel since 2.6.24, Sep 2007.
|
||||||
|
In 2.6.37, we make the sysfs I/F always built in and this option
|
||||||
|
disabled by default.
|
||||||
|
Remove this option and the ACPI power procfs interface in 2.6.39.
|
||||||
|
Who: Zhang Rui <rui.zhang@intel.com>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
What: /proc/acpi/button
|
What: /proc/acpi/button
|
||||||
When: August 2007
|
When: August 2007
|
||||||
Why: /proc/acpi/button has been replaced by events to the input layer
|
Why: /proc/acpi/button has been replaced by events to the input layer
|
||||||
@ -332,14 +357,6 @@ Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
|
|||||||
|
|
||||||
-----------------------------
|
-----------------------------
|
||||||
|
|
||||||
What: __do_IRQ all in one fits nothing interrupt handler
|
|
||||||
When: 2.6.32
|
|
||||||
Why: __do_IRQ was kept for easy migration to the type flow handlers.
|
|
||||||
More than two years of migration time is enough.
|
|
||||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
|
||||||
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
What: fakephp and associated sysfs files in /sys/bus/pci/slots/
|
What: fakephp and associated sysfs files in /sys/bus/pci/slots/
|
||||||
When: 2011
|
When: 2011
|
||||||
Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
|
Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
|
||||||
@ -576,3 +593,29 @@ Why: The functions have been superceded by cancel_delayed_work_sync()
|
|||||||
Who: Tejun Heo <tj@kernel.org>
|
Who: Tejun Heo <tj@kernel.org>
|
||||||
|
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
|
What: Legacy, non-standard chassis intrusion detection interface.
|
||||||
|
When: June 2011
|
||||||
|
Why: The adm9240, w83792d and w83793 hardware monitoring drivers have
|
||||||
|
legacy interfaces for chassis intrusion detection. A standard
|
||||||
|
interface has been added to each driver, so the legacy interface
|
||||||
|
can be removed.
|
||||||
|
Who: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
What: noswapaccount kernel command line parameter
|
||||||
|
When: 2.6.40
|
||||||
|
Why: The original implementation of memsw feature enabled by
|
||||||
|
CONFIG_CGROUP_MEM_RES_CTLR_SWAP could be disabled by the noswapaccount
|
||||||
|
kernel parameter (introduced in 2.6.29-rc1). Later on, this decision
|
||||||
|
turned out to be not ideal because we cannot have the feature compiled
|
||||||
|
in and disabled by default and let only interested to enable it
|
||||||
|
(e.g. general distribution kernels might need it). Therefore we have
|
||||||
|
added swapaccount[=0|1] parameter (introduced in 2.6.37) which provides
|
||||||
|
the both possibilities. If we remove noswapaccount we will have
|
||||||
|
less command line parameters with the same functionality and we
|
||||||
|
can also cleanup the parameter handling a bit ().
|
||||||
|
Who: Michal Hocko <mhocko@suse.cz>
|
||||||
|
|
||||||
|
----------------------------
|
||||||
|
@ -19,6 +19,8 @@ prototypes:
|
|||||||
void (*d_release)(struct dentry *);
|
void (*d_release)(struct dentry *);
|
||||||
void (*d_iput)(struct dentry *, struct inode *);
|
void (*d_iput)(struct dentry *, struct inode *);
|
||||||
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
|
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
|
||||||
|
struct vfsmount *(*d_automount)(struct path *path);
|
||||||
|
int (*d_manage)(struct dentry *, bool);
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
rename_lock ->d_lock may block rcu-walk
|
rename_lock ->d_lock may block rcu-walk
|
||||||
@ -29,6 +31,8 @@ d_delete: no yes no no
|
|||||||
d_release: no no yes no
|
d_release: no no yes no
|
||||||
d_iput: no no yes no
|
d_iput: no no yes no
|
||||||
d_dname: no no no no
|
d_dname: no no no no
|
||||||
|
d_automount: no no yes no
|
||||||
|
d_manage: no no yes (ref-walk) maybe
|
||||||
|
|
||||||
--------------------------- inode_operations ---------------------------
|
--------------------------- inode_operations ---------------------------
|
||||||
prototypes:
|
prototypes:
|
||||||
@ -56,7 +60,6 @@ ata *);
|
|||||||
ssize_t (*listxattr) (struct dentry *, char *, size_t);
|
ssize_t (*listxattr) (struct dentry *, char *, size_t);
|
||||||
int (*removexattr) (struct dentry *, const char *);
|
int (*removexattr) (struct dentry *, const char *);
|
||||||
void (*truncate_range)(struct inode *, loff_t, loff_t);
|
void (*truncate_range)(struct inode *, loff_t, loff_t);
|
||||||
long (*fallocate)(struct inode *inode, int mode, loff_t offset, loff_t len);
|
|
||||||
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
|
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
@ -84,7 +87,6 @@ getxattr: no
|
|||||||
listxattr: no
|
listxattr: no
|
||||||
removexattr: yes
|
removexattr: yes
|
||||||
truncate_range: yes
|
truncate_range: yes
|
||||||
fallocate: no
|
|
||||||
fiemap: no
|
fiemap: no
|
||||||
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
|
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
|
||||||
victim.
|
victim.
|
||||||
@ -343,7 +345,6 @@ prototypes:
|
|||||||
int (*fl_grant)(struct file_lock *, struct file_lock *, int);
|
int (*fl_grant)(struct file_lock *, struct file_lock *, int);
|
||||||
void (*fl_release_private)(struct file_lock *);
|
void (*fl_release_private)(struct file_lock *);
|
||||||
void (*fl_break)(struct file_lock *); /* break_lease callback */
|
void (*fl_break)(struct file_lock *); /* break_lease callback */
|
||||||
int (*fl_mylease)(struct file_lock *, struct file_lock *);
|
|
||||||
int (*fl_change)(struct file_lock **, int);
|
int (*fl_change)(struct file_lock **, int);
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
@ -353,7 +354,6 @@ fl_notify: yes no
|
|||||||
fl_grant: no no
|
fl_grant: no no
|
||||||
fl_release_private: maybe no
|
fl_release_private: maybe no
|
||||||
fl_break: yes no
|
fl_break: yes no
|
||||||
fl_mylease: yes no
|
|
||||||
fl_change yes no
|
fl_change yes no
|
||||||
|
|
||||||
--------------------------- buffer_head -----------------------------------
|
--------------------------- buffer_head -----------------------------------
|
||||||
@ -435,6 +435,7 @@ prototypes:
|
|||||||
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *,
|
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *,
|
||||||
size_t, unsigned int);
|
size_t, unsigned int);
|
||||||
int (*setlease)(struct file *, long, struct file_lock **);
|
int (*setlease)(struct file *, long, struct file_lock **);
|
||||||
|
long (*fallocate)(struct file *, int, loff_t, loff_t);
|
||||||
};
|
};
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
|
@ -457,6 +457,11 @@ ChangeLog
|
|||||||
|
|
||||||
Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
|
Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
|
||||||
|
|
||||||
|
2.1.30:
|
||||||
|
- Fix writev() (it kept writing the first segment over and over again
|
||||||
|
instead of moving onto subsequent segments).
|
||||||
|
- Fix crash in ntfs_mft_record_alloc() when mapping the new extent mft
|
||||||
|
record failed.
|
||||||
2.1.29:
|
2.1.29:
|
||||||
- Fix a deadlock when mounting read-write.
|
- Fix a deadlock when mounting read-write.
|
||||||
2.1.28:
|
2.1.28:
|
||||||
|
@ -365,8 +365,8 @@ must be done in the RCU callback.
|
|||||||
[recommended]
|
[recommended]
|
||||||
vfs now tries to do path walking in "rcu-walk mode", which avoids
|
vfs now tries to do path walking in "rcu-walk mode", which avoids
|
||||||
atomic operations and scalability hazards on dentries and inodes (see
|
atomic operations and scalability hazards on dentries and inodes (see
|
||||||
Documentation/filesystems/path-walk.txt). d_hash and d_compare changes (above)
|
Documentation/filesystems/path-lookup.txt). d_hash and d_compare changes
|
||||||
are examples of the changes required to support this. For more complex
|
(above) are examples of the changes required to support this. For more complex
|
||||||
filesystem callbacks, the vfs drops out of rcu-walk mode before the fs call, so
|
filesystem callbacks, the vfs drops out of rcu-walk mode before the fs call, so
|
||||||
no changes are required to the filesystem. However, this is costly and loses
|
no changes are required to the filesystem. However, this is costly and loses
|
||||||
the benefits of rcu-walk mode. We will begin to add filesystem callbacks that
|
the benefits of rcu-walk mode. We will begin to add filesystem callbacks that
|
||||||
@ -383,5 +383,14 @@ Documentation/filesystems/vfs.txt for more details.
|
|||||||
|
|
||||||
permission and check_acl are inode permission checks that are called
|
permission and check_acl are inode permission checks that are called
|
||||||
on many or all directory inodes on the way down a path walk (to check for
|
on many or all directory inodes on the way down a path walk (to check for
|
||||||
exec permission). These must now be rcu-walk aware (flags & IPERM_RCU). See
|
exec permission). These must now be rcu-walk aware (flags & IPERM_FLAG_RCU).
|
||||||
Documentation/filesystems/vfs.txt for more details.
|
See Documentation/filesystems/vfs.txt for more details.
|
||||||
|
|
||||||
|
--
|
||||||
|
[mandatory]
|
||||||
|
In ->fallocate() you must check the mode option passed in. If your
|
||||||
|
filesystem does not support hole punching (deallocating space in the middle of a
|
||||||
|
file) you must return -EOPNOTSUPP if FALLOC_FL_PUNCH_HOLE is set in mode.
|
||||||
|
Currently you can only have FALLOC_FL_PUNCH_HOLE with FALLOC_FL_KEEP_SIZE set,
|
||||||
|
so the i_size should not change when hole punching, even when puching the end of
|
||||||
|
a file off.
|
||||||
|
@ -375,6 +375,7 @@ Anonymous: 0 kB
|
|||||||
Swap: 0 kB
|
Swap: 0 kB
|
||||||
KernelPageSize: 4 kB
|
KernelPageSize: 4 kB
|
||||||
MMUPageSize: 4 kB
|
MMUPageSize: 4 kB
|
||||||
|
Locked: 374 kB
|
||||||
|
|
||||||
The first of these lines shows the same information as is displayed for the
|
The first of these lines shows the same information as is displayed for the
|
||||||
mapping in /proc/PID/maps. The remaining lines show the size of the mapping
|
mapping in /proc/PID/maps. The remaining lines show the size of the mapping
|
||||||
@ -670,6 +671,8 @@ varies by architecture and compile options. The following is from a
|
|||||||
|
|
||||||
> cat /proc/meminfo
|
> cat /proc/meminfo
|
||||||
|
|
||||||
|
The "Locked" indicates whether the mapping is locked in memory or not.
|
||||||
|
|
||||||
|
|
||||||
MemTotal: 16344972 kB
|
MemTotal: 16344972 kB
|
||||||
MemFree: 13634064 kB
|
MemFree: 13634064 kB
|
||||||
@ -1320,6 +1323,10 @@ scaled linearly with /proc/<pid>/oom_score_adj.
|
|||||||
Writing to /proc/<pid>/oom_score_adj or /proc/<pid>/oom_adj will change the
|
Writing to /proc/<pid>/oom_score_adj or /proc/<pid>/oom_adj will change the
|
||||||
other with its scaled value.
|
other with its scaled value.
|
||||||
|
|
||||||
|
The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last
|
||||||
|
value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
|
||||||
|
requires CAP_SYS_RESOURCE.
|
||||||
|
|
||||||
NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
|
NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
|
||||||
Documentation/feature-removal-schedule.txt.
|
Documentation/feature-removal-schedule.txt.
|
||||||
|
|
||||||
|
@ -415,7 +415,7 @@ otherwise noted.
|
|||||||
permission: called by the VFS to check for access rights on a POSIX-like
|
permission: called by the VFS to check for access rights on a POSIX-like
|
||||||
filesystem.
|
filesystem.
|
||||||
|
|
||||||
May be called in rcu-walk mode (flags & IPERM_RCU). If in rcu-walk
|
May be called in rcu-walk mode (flags & IPERM_FLAG_RCU). If in rcu-walk
|
||||||
mode, the filesystem must check the permission without blocking or
|
mode, the filesystem must check the permission without blocking or
|
||||||
storing to the inode.
|
storing to the inode.
|
||||||
|
|
||||||
@ -864,6 +864,8 @@ struct dentry_operations {
|
|||||||
void (*d_release)(struct dentry *);
|
void (*d_release)(struct dentry *);
|
||||||
void (*d_iput)(struct dentry *, struct inode *);
|
void (*d_iput)(struct dentry *, struct inode *);
|
||||||
char *(*d_dname)(struct dentry *, char *, int);
|
char *(*d_dname)(struct dentry *, char *, int);
|
||||||
|
struct vfsmount *(*d_automount)(struct path *);
|
||||||
|
int (*d_manage)(struct dentry *, bool, bool);
|
||||||
};
|
};
|
||||||
|
|
||||||
d_revalidate: called when the VFS needs to revalidate a dentry. This
|
d_revalidate: called when the VFS needs to revalidate a dentry. This
|
||||||
@ -930,6 +932,47 @@ struct dentry_operations {
|
|||||||
at the end of the buffer, and returns a pointer to the first char.
|
at the end of the buffer, and returns a pointer to the first char.
|
||||||
dynamic_dname() helper function is provided to take care of this.
|
dynamic_dname() helper function is provided to take care of this.
|
||||||
|
|
||||||
|
d_automount: called when an automount dentry is to be traversed (optional).
|
||||||
|
This should create a new VFS mount record and return the record to the
|
||||||
|
caller. The caller is supplied with a path parameter giving the
|
||||||
|
automount directory to describe the automount target and the parent
|
||||||
|
VFS mount record to provide inheritable mount parameters. NULL should
|
||||||
|
be returned if someone else managed to make the automount first. If
|
||||||
|
the vfsmount creation failed, then an error code should be returned.
|
||||||
|
If -EISDIR is returned, then the directory will be treated as an
|
||||||
|
ordinary directory and returned to pathwalk to continue walking.
|
||||||
|
|
||||||
|
If a vfsmount is returned, the caller will attempt to mount it on the
|
||||||
|
mountpoint and will remove the vfsmount from its expiration list in
|
||||||
|
the case of failure. The vfsmount should be returned with 2 refs on
|
||||||
|
it to prevent automatic expiration - the caller will clean up the
|
||||||
|
additional ref.
|
||||||
|
|
||||||
|
This function is only used if DCACHE_NEED_AUTOMOUNT is set on the
|
||||||
|
dentry. This is set by __d_instantiate() if S_AUTOMOUNT is set on the
|
||||||
|
inode being added.
|
||||||
|
|
||||||
|
d_manage: called to allow the filesystem to manage the transition from a
|
||||||
|
dentry (optional). This allows autofs, for example, to hold up clients
|
||||||
|
waiting to explore behind a 'mountpoint' whilst letting the daemon go
|
||||||
|
past and construct the subtree there. 0 should be returned to let the
|
||||||
|
calling process continue. -EISDIR can be returned to tell pathwalk to
|
||||||
|
use this directory as an ordinary directory and to ignore anything
|
||||||
|
mounted on it and not to check the automount flag. Any other error
|
||||||
|
code will abort pathwalk completely.
|
||||||
|
|
||||||
|
If the 'mounting_here' parameter is true, then namespace_sem is being
|
||||||
|
held by the caller and the function should not initiate any mounts or
|
||||||
|
unmounts that it will then wait for.
|
||||||
|
|
||||||
|
If the 'rcu_walk' parameter is true, then the caller is doing a
|
||||||
|
pathwalk in RCU-walk mode. Sleeping is not permitted in this mode,
|
||||||
|
and the caller can be asked to leave it and call again by returing
|
||||||
|
-ECHILD.
|
||||||
|
|
||||||
|
This function is only used if DCACHE_MANAGE_TRANSIT is set on the
|
||||||
|
dentry being transited from.
|
||||||
|
|
||||||
Example :
|
Example :
|
||||||
|
|
||||||
static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
|
static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
|
||||||
|
@ -155,7 +155,7 @@ connected to a normally open switch.
|
|||||||
The ADM9240 provides an internal open drain on this line, and may output
|
The ADM9240 provides an internal open drain on this line, and may output
|
||||||
a 20 ms active low pulse to reset an external Chassis Intrusion latch.
|
a 20 ms active low pulse to reset an external Chassis Intrusion latch.
|
||||||
|
|
||||||
Clear the CI latch by writing value 1 to the sysfs chassis_clear file.
|
Clear the CI latch by writing value 0 to the sysfs intrusion0_alarm file.
|
||||||
|
|
||||||
Alarm flags reported as 16-bit word
|
Alarm flags reported as 16-bit word
|
||||||
|
|
||||||
|
@ -9,7 +9,7 @@ Supported chips:
|
|||||||
http://focus.ti.com/lit/ds/symlink/ads7828.pdf
|
http://focus.ti.com/lit/ds/symlink/ads7828.pdf
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Steve Hardy <steve@linuxrealtime.co.uk>
|
Steve Hardy <shardy@redhat.com>
|
||||||
|
|
||||||
Module Parameters
|
Module Parameters
|
||||||
-----------------
|
-----------------
|
||||||
|
@ -42,7 +42,7 @@ Description
|
|||||||
This driver implements support for the hardware monitoring capabilities of the
|
This driver implements support for the hardware monitoring capabilities of the
|
||||||
SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, SCH311x,
|
SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, SCH311x,
|
||||||
and SCH5127 Super-I/O chips. These chips feature monitoring of 3 temp sensors
|
and SCH5127 Super-I/O chips. These chips feature monitoring of 3 temp sensors
|
||||||
temp[1-3] (2 remote diodes and 1 internal), 7 voltages in[0-6] (6 external and
|
temp[1-3] (2 remote diodes and 1 internal), 8 voltages in[0-7] (7 external and
|
||||||
1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
|
1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
|
||||||
up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
||||||
automatically.
|
automatically.
|
||||||
@ -105,6 +105,7 @@ SCH5127:
|
|||||||
in4: V1_IN 0V - 1.5V
|
in4: V1_IN 0V - 1.5V
|
||||||
in5: VTR (+3.3V standby) 0V - 4.38V
|
in5: VTR (+3.3V standby) 0V - 4.38V
|
||||||
in6: Vbat (+3.0V) 0V - 4.38V
|
in6: Vbat (+3.0V) 0V - 4.38V
|
||||||
|
in7: Vtrip (+1.5V) 0V - 1.99V
|
||||||
|
|
||||||
Each voltage input has associated min and max limits which trigger an alarm
|
Each voltage input has associated min and max limits which trigger an alarm
|
||||||
when crossed.
|
when crossed.
|
||||||
@ -217,10 +218,10 @@ cpu0_vid RO CPU core reference voltage in
|
|||||||
vrm RW Voltage regulator module version
|
vrm RW Voltage regulator module version
|
||||||
number.
|
number.
|
||||||
|
|
||||||
in[0-6]_input RO Measured voltage in millivolts.
|
in[0-7]_input RO Measured voltage in millivolts.
|
||||||
in[0-6]_min RW Low limit for voltage input.
|
in[0-7]_min RW Low limit for voltage input.
|
||||||
in[0-6]_max RW High limit for voltage input.
|
in[0-7]_max RW High limit for voltage input.
|
||||||
in[0-6]_alarm RO Voltage input alarm. Returns 1 if
|
in[0-7]_alarm RO Voltage input alarm. Returns 1 if
|
||||||
voltage input is or went outside the
|
voltage input is or went outside the
|
||||||
associated min-max range, 0 otherwise.
|
associated min-max range, 0 otherwise.
|
||||||
|
|
||||||
@ -324,3 +325,4 @@ fan5 opt opt
|
|||||||
pwm5 opt opt
|
pwm5 opt opt
|
||||||
fan6 opt opt
|
fan6 opt opt
|
||||||
pwm6 opt opt
|
pwm6 opt opt
|
||||||
|
in7 yes
|
||||||
|
34
Documentation/hwmon/ds620
Normal file
34
Documentation/hwmon/ds620
Normal file
@ -0,0 +1,34 @@
|
|||||||
|
Kernel driver ds620
|
||||||
|
===================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* Dallas Semiconductor DS620
|
||||||
|
Prefix: 'ds620'
|
||||||
|
Datasheet: Publicly available at the Dallas Semiconductor website
|
||||||
|
http://www.dalsemi.com/
|
||||||
|
|
||||||
|
Authors:
|
||||||
|
Roland Stigge <stigge@antcom.de>
|
||||||
|
based on ds1621.c by
|
||||||
|
Christian W. Zuckschwerdt <zany@triq.net>
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
The DS620 is a (one instance) digital thermometer and thermostat. It has both
|
||||||
|
high and low temperature limits which can be user defined (i.e. programmed
|
||||||
|
into non-volatile on-chip registers). Temperature range is -55 degree Celsius
|
||||||
|
to +125. Between 0 and 70 degree Celsius, accuracy is 0.5 Kelvin. The value
|
||||||
|
returned via sysfs displays post decimal positions.
|
||||||
|
|
||||||
|
The thermostat function works as follows: When configured via platform_data
|
||||||
|
(struct ds620_platform_data) .pomode == 0 (default), the thermostat output pin
|
||||||
|
PO is always low. If .pomode == 1, the thermostat is in PO_LOW mode. I.e., the
|
||||||
|
output pin PO becomes active when the temperature falls below temp1_min and
|
||||||
|
stays active until the temperature goes above temp1_max.
|
||||||
|
|
||||||
|
Likewise, with .pomode == 2, the thermostat is in PO_HIGH mode. I.e., the PO
|
||||||
|
output pin becomes active when the temperature goes above temp1_max and stays
|
||||||
|
active until the temperature falls below temp1_min.
|
||||||
|
|
||||||
|
The PO output pin of the DS620 operates active-low.
|
@ -51,7 +51,8 @@ Supported chips:
|
|||||||
* JEDEC JC 42.4 compliant temperature sensor chips
|
* JEDEC JC 42.4 compliant temperature sensor chips
|
||||||
Prefix: 'jc42'
|
Prefix: 'jc42'
|
||||||
Addresses scanned: I2C 0x18 - 0x1f
|
Addresses scanned: I2C 0x18 - 0x1f
|
||||||
Datasheet: -
|
Datasheet:
|
||||||
|
http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
|
||||||
|
|
||||||
Author:
|
Author:
|
||||||
Guenter Roeck <guenter.roeck@ericsson.com>
|
Guenter Roeck <guenter.roeck@ericsson.com>
|
||||||
@ -60,7 +61,11 @@ Author:
|
|||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver implements support for JEDEC JC 42.4 compliant temperature sensors.
|
This driver implements support for JEDEC JC 42.4 compliant temperature sensors,
|
||||||
|
which are used on many DDR3 memory modules for mobile devices and servers. Some
|
||||||
|
systems use the sensor to prevent memory overheating by automatically throttling
|
||||||
|
the memory controller.
|
||||||
|
|
||||||
The driver auto-detects the chips listed above, but can be manually instantiated
|
The driver auto-detects the chips listed above, but can be manually instantiated
|
||||||
to support other JC 42.4 compliant chips.
|
to support other JC 42.4 compliant chips.
|
||||||
|
|
||||||
@ -81,15 +86,19 @@ limits. The chip supports only a single register to configure the hysteresis,
|
|||||||
which applies to all limits. This register can be written by writing into
|
which applies to all limits. This register can be written by writing into
|
||||||
temp1_crit_hyst. Other hysteresis attributes are read-only.
|
temp1_crit_hyst. Other hysteresis attributes are read-only.
|
||||||
|
|
||||||
|
If the BIOS has configured the sensor for automatic temperature management, it
|
||||||
|
is likely that it has locked the registers, i.e., that the temperature limits
|
||||||
|
cannot be changed.
|
||||||
|
|
||||||
Sysfs entries
|
Sysfs entries
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
temp1_input Temperature (RO)
|
temp1_input Temperature (RO)
|
||||||
temp1_min Minimum temperature (RW)
|
temp1_min Minimum temperature (RO or RW)
|
||||||
temp1_max Maximum temperature (RW)
|
temp1_max Maximum temperature (RO or RW)
|
||||||
temp1_crit Critical high temperature (RW)
|
temp1_crit Critical high temperature (RO or RW)
|
||||||
|
|
||||||
temp1_crit_hyst Critical hysteresis temperature (RW)
|
temp1_crit_hyst Critical hysteresis temperature (RO or RW)
|
||||||
temp1_max_hyst Maximum hysteresis temperature (RO)
|
temp1_max_hyst Maximum hysteresis temperature (RO)
|
||||||
|
|
||||||
temp1_min_alarm Temperature low alarm
|
temp1_min_alarm Temperature low alarm
|
||||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user