You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
Pull trivial updates from Jiri Kosina: "As usual, it's mostly typo fixes, redundant code elimination and some documentation updates." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (57 commits) edac, mips: don't change code that has been removed in edac/mips tree xtensa: Change mail addresses of Hannes Weiner and Oskar Schirmer lib: Change mail address of Oskar Schirmer net: Change mail address of Oskar Schirmer arm/m68k: Change mail address of Sebastian Hess i2c: Change mail address of Oskar Schirmer net: Fix tcp_build_and_update_options comment in struct tcp_sock atomic64_32.h: fix parameter naming mismatch Kconfig: replace "--- help ---" with "---help---" c2port: fix bogus Kconfig "default no" edac: Fix spelling errors. qla1280: Remove redundant NULL check before release_firmware() call remoteproc: remove redundant NULL check before release_firmware() qla2xxx: Remove redundant NULL check before release_firmware() call. aic94xx: Get rid of redundant NULL check before release_firmware() call tehuti: delete redundant NULL check before release_firmware() qlogic: get rid of a redundant test for NULL before call to release_firmware() bna: remove redundant NULL test before release_firmware() tg3: remove redundant NULL test before release_firmware() call typhoon: get rid of redundant conditional before all to release_firmware() ...
This commit is contained in:
@@ -3814,8 +3814,8 @@ D: INFO-SHEET, former maintainer
|
||||
D: Author of the longest-living linux bug
|
||||
|
||||
N: Jonathan Woithe
|
||||
E: jwoithe@physics.adelaide.edu.au
|
||||
W: http://www.physics.adelaide.edu.au/~jwoithe
|
||||
E: jwoithe@just42.net
|
||||
W: http:/www.just42.net/jwoithe
|
||||
D: ALS-007 sound card extensions to Sound Blaster driver
|
||||
S: 20 Jordan St
|
||||
S: Valley View, SA 5093
|
||||
|
||||
@@ -204,7 +204,7 @@ Contact: Matthew Garrett <mjg@redhat.com>
|
||||
Description:
|
||||
Some information about whether a given USB device is
|
||||
physically fixed to the platform can be inferred from a
|
||||
combination of hub decriptor bits and platform-specific data
|
||||
combination of hub descriptor bits and platform-specific data
|
||||
such as ACPI. This file will read either "removable" or
|
||||
"fixed" if the information is available, and "unknown"
|
||||
otherwise.
|
||||
@@ -1289,7 +1289,7 @@ static struct block_device_operations opt_fops = {
|
||||
* Sparc assembly will do this to ya.
|
||||
*/
|
||||
C_LABEL(cputypvar):
|
||||
.asciz "compatability"
|
||||
.asciz "compatibility"
|
||||
|
||||
/* Tested on SS-5, SS-10. Probably someone at Sun applied a spell-checker. */
|
||||
.align 4
|
||||
|
||||
@@ -918,7 +918,7 @@ and other resources, etc.
|
||||
<title>HSM violation</title>
|
||||
<para>
|
||||
This error is indicated when STATUS value doesn't match HSM
|
||||
requirement during issuing or excution any ATA/ATAPI command.
|
||||
requirement during issuing or execution any ATA/ATAPI command.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
@@ -2023,7 +2023,7 @@ Possible values are:</entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Cyclic intra macroblock refresh. This is the number of continuous macroblocks
|
||||
refreshed every frame. Each frame a succesive set of macroblocks is refreshed until the cycle completes and starts from the
|
||||
refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from the
|
||||
top of the frame. Applicable to H264, H263 and MPEG4 encoder.</entry>
|
||||
</row>
|
||||
|
||||
@@ -2183,7 +2183,7 @@ Applicable to the MPEG4 and H264 encoders.</entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">The Video Buffer Verifier size in kilobytes, it is used as a limitation of frame skip.
|
||||
The VBV is defined in the standard as a mean to verify that the produced stream will be succesfully decoded.
|
||||
The VBV is defined in the standard as a mean to verify that the produced stream will be successfully decoded.
|
||||
The standard describes it as "Part of a hypothetical decoder that is conceptually connected to the
|
||||
output of the encoder. Its purpose is to provide a constraint on the variability of the data rate that an
|
||||
encoder or editing process may produce.".
|
||||
@@ -2196,7 +2196,7 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
|
||||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">The Coded Picture Buffer size in kilobytes, it is used as a limitation of frame skip.
|
||||
The CPB is defined in the H264 standard as a mean to verify that the produced stream will be succesfully decoded.
|
||||
The CPB is defined in the H264 standard as a mean to verify that the produced stream will be successfully decoded.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
|
||||
@@ -53,7 +53,7 @@
|
||||
|
||||
3. But there are some exceptions
|
||||
- Kernel permit the identical GPIO be requested both as GPIO and GPIO
|
||||
interrut.
|
||||
interrupt.
|
||||
Some drivers, like gpio-keys, need this behavior. Kernel only print out
|
||||
warning messages like,
|
||||
bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
|
||||
Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
|
||||
|
||||
Required properties:
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ from the windriver disk into this directory.
|
||||
|
||||
Then run
|
||||
|
||||
./get_dvb_firware opera1
|
||||
./get_dvb_firmware opera1
|
||||
|
||||
and after that you have 2 files:
|
||||
|
||||
|
||||
@@ -734,7 +734,7 @@ were done at i7core_edac driver. This chapter will cover those differences
|
||||
associated with a physical CPU socket.
|
||||
|
||||
Each MC have 3 physical read channels, 3 physical write channels and
|
||||
3 logic channels. The driver currenty sees it as just 3 channels.
|
||||
3 logic channels. The driver currently sees it as just 3 channels.
|
||||
Each channel can have up to 3 DIMMs.
|
||||
|
||||
The minimum known unity is DIMMs. There are no information about csrows.
|
||||
|
||||
@@ -93,7 +93,7 @@ The API to the login script is as follows:
|
||||
(allways exists)
|
||||
(More protocols can be defined in the future.
|
||||
The client does not interpret this string it is
|
||||
passed unchanged as recieved from the Server)
|
||||
passed unchanged as received from the Server)
|
||||
-o osdname of the requested target OSD
|
||||
(Might be empty)
|
||||
(A string which denotes the OSD name, there is a
|
||||
|
||||
@@ -17,7 +17,7 @@ concepts of blocks, inodes and directories.
|
||||
On QNX it is possible to create little endian and big endian qnx6 filesystems.
|
||||
This feature makes it possible to create and use a different endianness fs
|
||||
for the target (QNX is used on quite a range of embedded systems) plattform
|
||||
running on a different endianess.
|
||||
running on a different endianness.
|
||||
The Linux driver handles endianness transparently. (LE and BE)
|
||||
|
||||
Blocks
|
||||
@@ -26,7 +26,7 @@ Blocks
|
||||
The space in the device or file is split up into blocks. These are a fixed
|
||||
size of 512, 1024, 2048 or 4096, which is decided when the filesystem is
|
||||
created.
|
||||
Blockpointers are 32bit, so the maximum space that can be adressed is
|
||||
Blockpointers are 32bit, so the maximum space that can be addressed is
|
||||
2^32 * 4096 bytes or 16TB
|
||||
|
||||
The superblocks
|
||||
@@ -47,16 +47,16 @@ inactive superblock.
|
||||
Each superblock holds a set of root inodes for the different filesystem
|
||||
parts. (Inode, Bitmap and Longfilenames)
|
||||
Each of these root nodes holds information like total size of the stored
|
||||
data and the adressing levels in that specific tree.
|
||||
If the level value is 0, up to 16 direct blocks can be adressed by each
|
||||
data and the addressing levels in that specific tree.
|
||||
If the level value is 0, up to 16 direct blocks can be addressed by each
|
||||
node.
|
||||
Level 1 adds an additional indirect adressing level where each indirect
|
||||
adressing block holds up to blocksize / 4 bytes pointers to data blocks.
|
||||
Level 2 adds an additional indirect adressig block level (so, already up
|
||||
to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a
|
||||
Level 1 adds an additional indirect addressing level where each indirect
|
||||
addressing block holds up to blocksize / 4 bytes pointers to data blocks.
|
||||
Level 2 adds an additional indirect addressing block level (so, already up
|
||||
to 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree).
|
||||
|
||||
Unused block pointers are always set to ~0 - regardless of root node,
|
||||
indirect adressing blocks or inodes.
|
||||
indirect addressing blocks or inodes.
|
||||
Data leaves are always on the lowest level. So no data is stored on upper
|
||||
tree levels.
|
||||
|
||||
@@ -64,7 +64,7 @@ The first Superblock is located at 0x2000. (0x2000 is the bootblock size)
|
||||
The Audi MMI 3G first superblock directly starts at byte 0.
|
||||
Second superblock position can either be calculated from the superblock
|
||||
information (total number of filesystem blocks) or by taking the highest
|
||||
device address, zeroing the last 3 bytes and then substracting 0x1000 from
|
||||
device address, zeroing the last 3 bytes and then subtracting 0x1000 from
|
||||
that address.
|
||||
|
||||
0x1000 is the size reserved for each superblock - regardless of the
|
||||
@@ -83,8 +83,8 @@ size, number of blocks used, access time, change time and modification time.
|
||||
Object mode field is POSIX format. (which makes things easier)
|
||||
|
||||
There are also pointers to the first 16 blocks, if the object data can be
|
||||
adressed with 16 direct blocks.
|
||||
For more than 16 blocks an indirect adressing in form of another tree is
|
||||
addressed with 16 direct blocks.
|
||||
For more than 16 blocks an indirect addressing in form of another tree is
|
||||
used. (scheme is the same as the one used for the superblock root nodes)
|
||||
|
||||
The filesize is stored 64bit. Inode counting starts with 1. (whilst long
|
||||
@@ -118,13 +118,13 @@ no block pointers and the directory file record pointing to the target file
|
||||
inode.
|
||||
|
||||
Character and block special devices do not exist in QNX as those files
|
||||
are handled by the QNX kernel/drivers and created in /dev independant of the
|
||||
are handled by the QNX kernel/drivers and created in /dev independent of the
|
||||
underlaying filesystem.
|
||||
|
||||
Long filenames
|
||||
--------------
|
||||
|
||||
Long filenames are stored in a seperate adressing tree. The staring point
|
||||
Long filenames are stored in a separate addressing tree. The staring point
|
||||
is the longfilename root node in the active superblock.
|
||||
Each data block (tree leaves) holds one long filename. That filename is
|
||||
limited to 510 bytes. The first two starting bytes are used as length field
|
||||
|
||||
@@ -63,7 +63,7 @@ Module Parameters
|
||||
Hardware Interfaces
|
||||
-------------------
|
||||
|
||||
All the chips suported by this driver are LPC Super-I/O chips, accessed
|
||||
All the chips supported by this driver are LPC Super-I/O chips, accessed
|
||||
through the LPC bus (ISA-like I/O ports). The IT8712F additionally has an
|
||||
SMBus interface to the hardware monitoring functions. This driver no
|
||||
longer supports this interface though, as it is slower and less reliable
|
||||
|
||||
@@ -22,7 +22,7 @@ reporting of all the input values but does not provide any alarms.
|
||||
Voltage Monitoring
|
||||
------------------
|
||||
|
||||
Voltages are sampled by a 12 bit ADC. Voltages in milivolts are 1.465
|
||||
Voltages are sampled by a 12 bit ADC. Voltages in millivolts are 1.465
|
||||
times the ADC value.
|
||||
|
||||
Temperature Monitoring
|
||||
|
||||
@@ -341,7 +341,7 @@ Need more implementation yet....
|
||||
--------------------------------
|
||||
8. Memory hotplug event notifier
|
||||
--------------------------------
|
||||
Memory hotplug has event notifer. There are 6 types of notification.
|
||||
Memory hotplug has event notifier. There are 6 types of notification.
|
||||
|
||||
MEMORY_GOING_ONLINE
|
||||
Generated before new memory becomes available in order to be able to
|
||||
|
||||
@@ -649,7 +649,7 @@ solution for a couple of reasons:
|
||||
The CAN device must be configured via netlink interface. The supported
|
||||
netlink message types are defined and briefly described in
|
||||
"include/linux/can/netlink.h". CAN link support for the program "ip"
|
||||
of the IPROUTE2 utility suite is avaiable and it can be used as shown
|
||||
of the IPROUTE2 utility suite is available and it can be used as shown
|
||||
below:
|
||||
|
||||
- Setting CAN device properties:
|
||||
|
||||
@@ -34,6 +34,6 @@ registers interruption handlers read to find out where the machine
|
||||
was interrupted - so if you get an interruption between the instruction
|
||||
that clears the Q bit and the RFI that sets it again you don't know
|
||||
where exactly it happened. If you're lucky the IAOQ will point to the
|
||||
instrucion that cleared the Q bit, if you're not it points anywhere
|
||||
instruction that cleared the Q bit, if you're not it points anywhere
|
||||
at all. Usually Q bit problems will show themselves in unexplainable
|
||||
system hangs or running off the end of physical memory.
|
||||
|
||||
@@ -18,7 +18,7 @@ processing. Support for such hardware has not been very good in Linux,
|
||||
mostly because of a lack of a generic API available in the mainline
|
||||
kernel.
|
||||
|
||||
Rather than requiring a compability break with an API change of the
|
||||
Rather than requiring a compatibility break with an API change of the
|
||||
ALSA PCM interface, a new 'Compressed Data' API is introduced to
|
||||
provide a control and data-streaming interface for audio DSPs.
|
||||
|
||||
|
||||
@@ -57,10 +57,10 @@ The resulting sound driver will provide the following capabilities:
|
||||
DSP/PCM/audio out (L&R), FM (L&R) and Mic in (mono).
|
||||
|
||||
Jonathan Woithe
|
||||
jwoithe@physics.adelaide.edu.au
|
||||
jwoithe@just42.net
|
||||
30 March 1998
|
||||
|
||||
Modified 2000-02-26 by Dave Forrest, drf5n@virginia.edu to add ALS100/ALS200
|
||||
Modified 2000-04-10 by Paul Laufer, pelaufer@csupomona.edu to add ISAPnP info.
|
||||
Modified 2000-11-19 by Jonathan Woithe, jwoithe@physics.adelaide.edu.au
|
||||
Modified 2000-11-19 by Jonathan Woithe, jwoithe@just42.net
|
||||
- updated information for kernel 2.4.x.
|
||||
|
||||
@@ -235,7 +235,7 @@ label case adds:
|
||||
6 (mov) + 2 (test) + 2 (jne) = 10 - 5 (5 byte jump 0) = 5 addition bytes.
|
||||
|
||||
If we then include the padding bytes, the jump label code saves, 16 total bytes
|
||||
of instruction memory for this small fucntion. In this case the non-jump label
|
||||
of instruction memory for this small function. In this case the non-jump label
|
||||
function is 80 bytes long. Thus, we have have saved 20% of the instruction
|
||||
footprint. We can in fact improve this even further, since the 5-byte no-op
|
||||
really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp.
|
||||
|
||||
@@ -28,7 +28,7 @@ Please pick something while reading :)
|
||||
none
|
||||
|
||||
- primary handler of the EP-interrupt
|
||||
reads the event and tries to process it. Everything that requries
|
||||
reads the event and tries to process it. Everything that requires
|
||||
sleeping is handed over to the Thread. The event is saved in an
|
||||
per-endpoint data-structure.
|
||||
We probably have to pay attention not to process events once we
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user