Fix common misspellings
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
This commit is contained in:
Lucas De Marchi
parent
6aba74f279
commit
25985edced
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
|
||||
|
|
|
|||
|
|
@ -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 @@
|
|||
|
||||
<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 */
|
||||
.
|
||||
.
|
||||
|
|
|
|||
|
|
@ -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 @@ 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.
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ together.
|
|||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -223,7 +223,7 @@ we will get the following buffer structure:
|
|||
|
||||
A frame can be of any size with the only condition it can fit in a block. A block
|
||||
can only hold an integer number of frames, or in other words, a frame cannot
|
||||
be spawned accross two blocks, so there are some details you have to take into
|
||||
be spawned across two blocks, so there are some details you have to take into
|
||||
account when choosing the frame_size. See "Mapping and use of the circular
|
||||
buffer (ring)".
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ To associate an interface with a physical adapter use "ethtool -p <ethX>".
|
|||
The corresponding adapter's LED will blink multiple times.
|
||||
|
||||
3. Features supported:
|
||||
a. Jumbo frames. Xframe I/II supports MTU upto 9600 bytes,
|
||||
a. Jumbo frames. Xframe I/II supports MTU up to 9600 bytes,
|
||||
modifiable using ifconfig command.
|
||||
|
||||
b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit
|
||||
|
|
@ -49,7 +49,7 @@ significant performance improvement on certain platforms(SGI Altix,
|
|||
IBM xSeries).
|
||||
|
||||
d. MSI/MSI-X. Can be enabled on platforms which support this feature
|
||||
(IA64, Xeon) resulting in noticeable performance improvement(upto 7%
|
||||
(IA64, Xeon) resulting in noticeable performance improvement(up to 7%
|
||||
on certain platforms).
|
||||
|
||||
e. Statistics. Comprehensive MAC-level and software statistics displayed
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
The "enviromental" rules for authors of any new tc actions are:
|
||||
The "environmental" rules for authors of any new tc actions are:
|
||||
|
||||
1) If you stealeth or borroweth any packet thou shalt be branching
|
||||
from the righteous path and thou shalt cloneth.
|
||||
|
|
@ -20,7 +20,7 @@ this way any action downstream can stomp on the packet.
|
|||
3) Dropping packets you don't own is a no-no. You simply return
|
||||
TC_ACT_SHOT to the caller and they will drop it.
|
||||
|
||||
The "enviromental" rules for callers of actions (qdiscs etc) are:
|
||||
The "environmental" rules for callers of actions (qdiscs etc) are:
|
||||
|
||||
*) Thou art responsible for freeing anything returned as being
|
||||
TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
|
||||
|
|
|
|||
|
|
@ -367,7 +367,7 @@ Drivers need to be able to handle hardware which has been reset since the
|
|||
suspend methods were called, for example by complete reinitialization.
|
||||
This may be the hardest part, and the one most protected by NDA'd documents
|
||||
and chip errata. It's simplest if the hardware state hasn't changed since
|
||||
the suspend was carried out, but that can't be guaranteed (in fact, it ususally
|
||||
the suspend was carried out, but that can't be guaranteed (in fact, it usually
|
||||
is not the case).
|
||||
|
||||
Drivers must also be prepared to notice that the device has been removed
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will
|
|||
be frozen immediately.
|
||||
|
||||
PM_POST_HIBERNATION The system memory state has been restored from a
|
||||
hibernation image or an error occured during the
|
||||
hibernation image or an error occurred during the
|
||||
hibernation. Device drivers' .resume() callbacks have
|
||||
been executed and tasks have been thawed.
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ PM_POST_RESTORE An error occurred during the hibernation restore.
|
|||
|
||||
PM_SUSPEND_PREPARE The system is preparing for a suspend.
|
||||
|
||||
PM_POST_SUSPEND The system has just resumed or an error occured during
|
||||
PM_POST_SUSPEND The system has just resumed or an error occurred during
|
||||
the suspend. Device drivers' .resume() callbacks have
|
||||
been executed and tasks have been thawed.
|
||||
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ opp_find_freq_ceil - Search for an available OPP which is *at least* the
|
|||
if (!IS_ERR(opp))
|
||||
soc_switch_to_freq_voltage(freq);
|
||||
else
|
||||
/* do something when we cant satisfy the req */
|
||||
/* do something when we can't satisfy the req */
|
||||
/* do other stuff */
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ Q: There don't seem to be any generally useful behavioral
|
|||
distinctions between SUSPEND and FREEZE.
|
||||
|
||||
A: Doing SUSPEND when you are asked to do FREEZE is always correct,
|
||||
but it may be unneccessarily slow. If you want your driver to stay simple,
|
||||
but it may be unnecessarily slow. If you want your driver to stay simple,
|
||||
slowness may not matter to you. It can always be fixed later.
|
||||
|
||||
For devices like disk it does matter, you do not want to spindown for
|
||||
|
|
@ -237,7 +237,7 @@ disk. Whole sequence goes like
|
|||
|
||||
running system, user asks for suspend-to-disk
|
||||
|
||||
user processes are stopped (in common case there are none, but with resume-from-initrd, noone knows)
|
||||
user processes are stopped (in common case there are none, but with resume-from-initrd, no one knows)
|
||||
|
||||
read image from disk
|
||||
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
|
|||
The device's read() operation can be used to transfer the snapshot image from
|
||||
the kernel. It has the following limitations:
|
||||
- you cannot read() more than one virtual memory page at a time
|
||||
- read()s accross page boundaries are impossible (ie. if ypu read() 1/2 of
|
||||
- read()s across page boundaries are impossible (ie. if ypu read() 1/2 of
|
||||
a page in the previous call, you will only be able to read()
|
||||
_at_ _most_ 1/2 of the page in the next call)
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ mechanism and the userland utilities using the interface SHOULD use additional
|
|||
means, such as checksums, to ensure the integrity of the snapshot image.
|
||||
|
||||
The suspending and resuming utilities MUST lock themselves in memory,
|
||||
preferrably using mlockall(), before calling SNAPSHOT_FREEZE.
|
||||
preferably using mlockall(), before calling SNAPSHOT_FREEZE.
|
||||
|
||||
The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE
|
||||
in the memory location pointed to by the last argument of ioctl() and proceed
|
||||
|
|
@ -147,7 +147,7 @@ in accordance with it:
|
|||
(a) The suspending utility MUST NOT close the snapshot device
|
||||
_unless_ the whole suspend procedure is to be cancelled, in
|
||||
which case, if the snapshot image has already been saved, the
|
||||
suspending utility SHOULD destroy it, preferrably by zapping
|
||||
suspending utility SHOULD destroy it, preferably by zapping
|
||||
its header. If the suspend is not to be cancelled, the
|
||||
system MUST be powered off or rebooted after the snapshot
|
||||
image has been saved.
|
||||
|
|
|
|||
|
|
@ -528,7 +528,7 @@ this driver assignment of hotplug added vty-servers may be in a different
|
|||
order than how they would be exposed on module load. Rebooting or
|
||||
reloading the module after dynamic addition may result in the /dev/hvcs*
|
||||
and vty-server coupling changing if a vty-server adapter was added in a
|
||||
slot inbetween two other vty-server adapters. Refer to the section above
|
||||
slot between two other vty-server adapters. Refer to the section above
|
||||
on how to determine which vty-server goes with which /dev/hvcs* node.
|
||||
Hint; look at the sysfs "index" attribute for the vty-server.
|
||||
|
||||
|
|
|
|||
|
|
@ -352,7 +352,7 @@ Changes from 20041229 to 20050110
|
|||
lpfc_scsiport.c
|
||||
* In remote port changes: no longer nulling target->pnode when
|
||||
removing from mapped list. Pnode get nulled when the node is
|
||||
freed (after nodev tmo). This bug was causing i/o recieved in
|
||||
freed (after nodev tmo). This bug was causing i/o received in
|
||||
the small window while the device was blocked to be errored w/
|
||||
did_no_connect. With the fix, it returns host_busy
|
||||
(per the pre-remote port changes).
|
||||
|
|
@ -530,7 +530,7 @@ Changes from 20041018 to 20041123
|
|||
coherent mappings. Note: There are more consistent mappings
|
||||
that are using pci_dma_sync calls. Probably these should be
|
||||
removed as well.
|
||||
* Modified lpfc_free_scsi_buf to accomodate all three scsi_buf
|
||||
* Modified lpfc_free_scsi_buf to accommodate all three scsi_buf
|
||||
free types to alleviate miscellaneous panics with cable pull
|
||||
testing.
|
||||
* Set hotplug to default 0 and lpfc_target_remove to not remove
|
||||
|
|
@ -583,7 +583,7 @@ Changes from 20041018 to 20041123
|
|||
included more than once.
|
||||
* Replaced "set_current_state(TASK_UNINTERRUPTIBLE);
|
||||
schedule_timeout(timeout)" with "msleep(timeout)".
|
||||
* Fixnode was loosing starget when rediscovered. We saw messages
|
||||
* Fixnode was losing starget when rediscovered. We saw messages
|
||||
like: lpfc 0000:04:02.0: 0:0263 Cannot block scsi target as a
|
||||
result. Moved starget field into struct lpfc_target which is
|
||||
referenced from the node.
|
||||
|
|
@ -604,7 +604,7 @@ Changes from 20041018 to 20041123
|
|||
* Make 3 functions static: lpfc_get_hba_sym_node_name,
|
||||
lpfc_intr_prep and lpfc_setup_slim_access. Move lpfc_intr_prep
|
||||
and lpfc_setup_slim_access so they're defined before being used.
|
||||
* Remove an unecessary list_del() in lpfc_hbadisc.c.
|
||||
* Remove an unnecessary list_del() in lpfc_hbadisc.c.
|
||||
* Set nlp_state before calling lpfc_nlp_list() since this will
|
||||
potentially call fc_target_unblock which may cause a race in
|
||||
queuecommand by releasing host_lock.
|
||||
|
|
@ -753,7 +753,7 @@ Changes from 20040908 to 20040920
|
|||
* Changed version number to 8.0.12
|
||||
* Removed used #defines: DEFAULT_PCI_LATENCY_CLOCKS and
|
||||
PCI_LATENCY_VALUE from lpfc_hw.h.
|
||||
* Changes to accomodate rnid.
|
||||
* Changes to accommodate rnid.
|
||||
* Fix RSCN handling so RSCN NS queries only effect NPorts found in
|
||||
RSCN data.
|
||||
* If we rcv a plogi on a NPort queued up for discovery, clear the
|
||||
|
|
@ -813,7 +813,7 @@ Changes from 20040908 to 20040920
|
|||
counter instead, brd_no isn't reused anymore. Also some tiny
|
||||
whitespace cleanups in surrounding code.
|
||||
* Reorder functions in lpfc_els.c to remove need for prototypes.
|
||||
* Removed unsed prototypes from lpfc_crtn.h -
|
||||
* Removed unused prototypes from lpfc_crtn.h -
|
||||
lpfc_ip_timeout_handler, lpfc_read_pci and lpfc_revoke.
|
||||
* Removed some unused prototypes from lpfc_crtn.h -
|
||||
lpfc_scsi_hba_reset, lpfc_scsi_issue_inqsn,
|
||||
|
|
@ -863,7 +863,7 @@ Changes from 20040823 to 20040908
|
|||
* Minimal support for SCSI flat space addressing/volume set
|
||||
addressing. Use 16 bits of LUN address so that flat
|
||||
addressing/VSA will work.
|
||||
* Changed 2 occurences of if( 1 != f(x)) to if(f(x) != 1)
|
||||
* Changed 2 occurrences of if( 1 != f(x)) to if(f(x) != 1)
|
||||
* Drop include of lpfc_cfgparm.h.
|
||||
* Reduce stack usage of lpfc_fdmi_cmd in lpfc_ct.c.
|
||||
* Add minimum range checking property to /sys write/store
|
||||
|
|
@ -1449,7 +1449,7 @@ Changes from 20040402 to 20040409
|
|||
* Removed lpfc_els_chk_latt from the lpfc_config_post function.
|
||||
lpfc_els_chk_latt will enable the link event interrupts when
|
||||
flogi is pending which causes two discovery state machines
|
||||
running parallely.
|
||||
running parallelly.
|
||||
* Add pci_disable_device to unload path.
|
||||
* Move lpfc_sleep_event from lpfc_fcp.c to lpfc_util_ioctl.c
|
||||
* Call dma_map_single() & pci_map_single() directly instead of via
|
||||
|
|
@ -1590,7 +1590,7 @@ Changes from 20040326 to 20040402
|
|||
ELX_WRITE_HS ELX_WRITE_HA ELX_WRITE_CA ELX_READ_HC
|
||||
ELX_READ_HS ELX_READ_HA ELX_READ_CA ELX_READ_MB ELX_RESET
|
||||
ELX_READ_HBA ELX_INSTANCE ELX_LIP. Also introduced
|
||||
attribute "set" to be used in conjuction with the above
|
||||
attribute "set" to be used in conjunction with the above
|
||||
attributes.
|
||||
* Removed DLINK, enque and deque declarations now that clock
|
||||
doesn't use them anymore
|
||||
|
|
|
|||
|
|
@ -168,7 +168,7 @@ Older Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)
|
|||
|
||||
1. Sorted out PCI IDs to remove megaraid support overlaps.
|
||||
Based on the patch from Daniel, sorted out PCI IDs along with
|
||||
charactor node name change from 'megadev' to 'megadev_legacy' to avoid
|
||||
character node name change from 'megadev' to 'megadev_legacy' to avoid
|
||||
conflict.
|
||||
---
|
||||
Hopefully we'll be getting the build restriction zapped much sooner,
|
||||
|
|
|
|||
|
|
@ -200,7 +200,7 @@ Sun Feb 14:00 1999 Gerard Roudier (groudier@club-internet.fr)
|
|||
By default the driver uses both IRQF_SHARED and IRQF_DISABLED.
|
||||
Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by
|
||||
a 53C8XX adapter and a network board.
|
||||
- Tiny mispelling fixed (ABORT instead of ABRT). Was fortunately
|
||||
- Tiny misspelling fixed (ABORT instead of ABRT). Was fortunately
|
||||
harmless.
|
||||
- Negotiate SYNC data transfers with CCS devices.
|
||||
|
||||
|
|
|
|||
|
|
@ -457,7 +457,7 @@ Fri Jan 1 20:00 1999 Gerard Roudier (groudier@club-internet.fr)
|
|||
Sat Dec 19 21:00 1998 Gerard Roudier (groudier@club-internet.fr)
|
||||
* version sym53c8xx-1.0
|
||||
- Define some new IO registers for the 896 (istat1, mbox0, mbox1)
|
||||
- Revamp slighly the Symbios NVRAM lay-out based on the excerpt of
|
||||
- Revamp slightly the Symbios NVRAM lay-out based on the excerpt of
|
||||
the header file I received from Symbios.
|
||||
- Check the PCI bus number for the boot order (Using a fast
|
||||
PCI controller behing a PCI-PCI bridge seems sub-optimal).
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ in the partition table and therefore every operating system has to know
|
|||
the right geometry to be able to interpret it.
|
||||
|
||||
Moreover there are certain limitations to the C/H/S addressing scheme,
|
||||
namely the address space is limited to upto 255 heads, upto 63 sectors
|
||||
namely the address space is limited to up to 255 heads, up to 63 sectors
|
||||
and a maximum of 1023 cylinders.
|
||||
|
||||
The AHA-1522 BIOS calculates the geometry by fixing the number of heads
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue