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