aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/arm/Samsung-S3C24XX/Suspend.txt8
-rw-r--r--Documentation/arm/memory.txt9
-rw-r--r--Documentation/cputopology.txt6
-rw-r--r--Documentation/devices.txt6
-rw-r--r--Documentation/feature-removal-schedule.txt3
-rw-r--r--Documentation/i2c/busses/i2c-nforce212
-rw-r--r--Documentation/i2c/busses/i2c-piix42
-rw-r--r--Documentation/i2c/instantiating-devices167
-rw-r--r--Documentation/i2c/writing-clients19
-rw-r--r--Documentation/kernel-parameters.txt13
-rw-r--r--Documentation/scsi/osd.txt198
-rw-r--r--Documentation/x86/boot.txt18
12 files changed, 435 insertions, 26 deletions
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
index 0dab6e32c130..a30fe510572b 100644
--- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt
+++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
@@ -40,13 +40,13 @@ Resuming
40Machine Support 40Machine Support
41--------------- 41---------------
42 42
43 The machine specific functions must call the s3c2410_pm_init() function 43 The machine specific functions must call the s3c_pm_init() function
44 to say that its bootloader is capable of resuming. This can be as 44 to say that its bootloader is capable of resuming. This can be as
45 simple as adding the following to the machine's definition: 45 simple as adding the following to the machine's definition:
46 46
47 INITMACHINE(s3c2410_pm_init) 47 INITMACHINE(s3c_pm_init)
48 48
49 A board can do its own setup before calling s3c2410_pm_init, if it 49 A board can do its own setup before calling s3c_pm_init, if it
50 needs to setup anything else for power management support. 50 needs to setup anything else for power management support.
51 51
52 There is currently no support for over-riding the default method of 52 There is currently no support for over-riding the default method of
@@ -74,7 +74,7 @@ statuc void __init machine_init(void)
74 74
75 enable_irq_wake(IRQ_EINT0); 75 enable_irq_wake(IRQ_EINT0);
76 76
77 s3c2410_pm_init(); 77 s3c_pm_init();
78} 78}
79 79
80 80
diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
index dc6045577a8b..43cb1004d35f 100644
--- a/Documentation/arm/memory.txt
+++ b/Documentation/arm/memory.txt
@@ -29,7 +29,14 @@ ffff0000 ffff0fff CPU vector page.
29 CPU supports vector relocation (control 29 CPU supports vector relocation (control
30 register V bit.) 30 register V bit.)
31 31
32ffc00000 fffeffff DMA memory mapping region. Memory returned 32fffe0000 fffeffff XScale cache flush area. This is used
33 in proc-xscale.S to flush the whole data
34 cache. Free for other usage on non-XScale.
35
36fff00000 fffdffff Fixmap mapping region. Addresses provided
37 by fix_to_virt() will be located here.
38
39ffc00000 ffefffff DMA memory mapping region. Memory returned
33 by the dma_alloc_xxx functions will be 40 by the dma_alloc_xxx functions will be
34 dynamically mapped here. 41 dynamically mapped here.
35 42
diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt
index 45932ec21cee..b41f3e58aefa 100644
--- a/Documentation/cputopology.txt
+++ b/Documentation/cputopology.txt
@@ -18,11 +18,11 @@ For an architecture to support this feature, it must define some of
18these macros in include/asm-XXX/topology.h: 18these macros in include/asm-XXX/topology.h:
19#define topology_physical_package_id(cpu) 19#define topology_physical_package_id(cpu)
20#define topology_core_id(cpu) 20#define topology_core_id(cpu)
21#define topology_thread_siblings(cpu) 21#define topology_thread_cpumask(cpu)
22#define topology_core_siblings(cpu) 22#define topology_core_cpumask(cpu)
23 23
24The type of **_id is int. 24The type of **_id is int.
25The type of siblings is cpumask_t. 25The type of siblings is (const) struct cpumask *.
26 26
27To be consistent on all architectures, include/linux/topology.h 27To be consistent on all architectures, include/linux/topology.h
28provides default definitions for any of the above macros that are 28provides default definitions for any of the above macros that are
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 2be08240ee80..62254d4510c6 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -3145,6 +3145,12 @@ Your cooperation is appreciated.
3145 1 = /dev/blockrom1 Second ROM card's translation layer interface 3145 1 = /dev/blockrom1 Second ROM card's translation layer interface
3146 ... 3146 ...
3147 3147
3148260 char OSD (Object-based-device) SCSI Device
3149 0 = /dev/osd0 First OSD Device
3150 1 = /dev/osd1 Second OSD Device
3151 ...
3152 255 = /dev/osd255 256th OSD Device
3153
3148 **** ADDITIONAL /dev DIRECTORY ENTRIES 3154 **** ADDITIONAL /dev DIRECTORY ENTRIES
3149 3155
3150This section details additional entries that should or may exist in 3156This section details additional entries that should or may exist in
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 049a96247f58..1135996bec8b 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -340,7 +340,8 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl>
340--------------------------- 340---------------------------
341 341
342What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client() 342What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
343When: 2.6.29 (ideally) or 2.6.30 (more likely) 343When: 2.6.30
344Check: i2c_attach_client i2c_detach_client
344Why: Deprecated by the new (standard) device driver binding model. Use 345Why: Deprecated by the new (standard) device driver binding model. Use
345 i2c_driver->probe() and ->remove() instead. 346 i2c_driver->probe() and ->remove() instead.
346Who: Jean Delvare <khali@linux-fr.org> 347Who: Jean Delvare <khali@linux-fr.org>
diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2
index fae3495bcbaf..9698c396b830 100644
--- a/Documentation/i2c/busses/i2c-nforce2
+++ b/Documentation/i2c/busses/i2c-nforce2
@@ -7,10 +7,14 @@ Supported adapters:
7 * nForce3 250Gb MCP 10de:00E4 7 * nForce3 250Gb MCP 10de:00E4
8 * nForce4 MCP 10de:0052 8 * nForce4 MCP 10de:0052
9 * nForce4 MCP-04 10de:0034 9 * nForce4 MCP-04 10de:0034
10 * nForce4 MCP51 10de:0264 10 * nForce MCP51 10de:0264
11 * nForce4 MCP55 10de:0368 11 * nForce MCP55 10de:0368
12 * nForce4 MCP61 10de:03EB 12 * nForce MCP61 10de:03EB
13 * nForce4 MCP65 10de:0446 13 * nForce MCP65 10de:0446
14 * nForce MCP67 10de:0542
15 * nForce MCP73 10de:07D8
16 * nForce MCP78S 10de:0752
17 * nForce MCP79 10de:0AA2
14 18
15Datasheet: not publicly available, but seems to be similar to the 19Datasheet: not publicly available, but seems to be similar to the
16 AMD-8111 SMBus 2.0 adapter. 20 AMD-8111 SMBus 2.0 adapter.
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4
index ef1efa79b1df..f889481762b5 100644
--- a/Documentation/i2c/busses/i2c-piix4
+++ b/Documentation/i2c/busses/i2c-piix4
@@ -4,7 +4,7 @@ Supported adapters:
4 * Intel 82371AB PIIX4 and PIIX4E 4 * Intel 82371AB PIIX4 and PIIX4E
5 * Intel 82443MX (440MX) 5 * Intel 82443MX (440MX)
6 Datasheet: Publicly available at the Intel website 6 Datasheet: Publicly available at the Intel website
7 * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges 7 * ServerWorks OSB4, CSB5, CSB6, HT-1000 and HT-1100 southbridges
8 Datasheet: Only available via NDA from ServerWorks 8 Datasheet: Only available via NDA from ServerWorks
9 * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges 9 * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
10 Datasheet: Not publicly available 10 Datasheet: Not publicly available
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
new file mode 100644
index 000000000000..b55ce57a84db
--- /dev/null
+++ b/Documentation/i2c/instantiating-devices
@@ -0,0 +1,167 @@
1How to instantiate I2C devices
2==============================
3
4Unlike PCI or USB devices, I2C devices are not enumerated at the hardware
5level. Instead, the software must know which devices are connected on each
6I2C bus segment, and what address these devices are using. For this
7reason, the kernel code must instantiate I2C devices explicitly. There are
8several ways to achieve this, depending on the context and requirements.
9
10
11Method 1: Declare the I2C devices by bus number
12-----------------------------------------------
13
14This method is appropriate when the I2C bus is a system bus as is the case
15for many embedded systems. On such systems, each I2C bus has a number
16which is known in advance. It is thus possible to pre-declare the I2C
17devices which live on this bus. This is done with an array of struct
18i2c_board_info which is registered by calling i2c_register_board_info().
19
20Example (from omap2 h4):
21
22static struct i2c_board_info __initdata h4_i2c_board_info[] = {
23 {
24 I2C_BOARD_INFO("isp1301_omap", 0x2d),
25 .irq = OMAP_GPIO_IRQ(125),
26 },
27 { /* EEPROM on mainboard */
28 I2C_BOARD_INFO("24c01", 0x52),
29 .platform_data = &m24c01,
30 },
31 { /* EEPROM on cpu card */
32 I2C_BOARD_INFO("24c01", 0x57),
33 .platform_data = &m24c01,
34 },
35};
36
37static void __init omap_h4_init(void)
38{
39 (...)
40 i2c_register_board_info(1, h4_i2c_board_info,
41 ARRAY_SIZE(h4_i2c_board_info));
42 (...)
43}
44
45The above code declares 3 devices on I2C bus 1, including their respective
46addresses and custom data needed by their drivers. When the I2C bus in
47question is registered, the I2C devices will be instantiated automatically
48by i2c-core.
49
50The devices will be automatically unbound and destroyed when the I2C bus
51they sit on goes away (if ever.)
52
53
54Method 2: Instantiate the devices explicitly
55--------------------------------------------
56
57This method is appropriate when a larger device uses an I2C bus for
58internal communication. A typical case is TV adapters. These can have a
59tuner, a video decoder, an audio decoder, etc. usually connected to the
60main chip by the means of an I2C bus. You won't know the number of the I2C
61bus in advance, so the method 1 described above can't be used. Instead,
62you can instantiate your I2C devices explicitly. This is done by filling
63a struct i2c_board_info and calling i2c_new_device().
64
65Example (from the sfe4001 network driver):
66
67static struct i2c_board_info sfe4001_hwmon_info = {
68 I2C_BOARD_INFO("max6647", 0x4e),
69};
70
71int sfe4001_init(struct efx_nic *efx)
72{
73 (...)
74 efx->board_info.hwmon_client =
75 i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info);
76
77 (...)
78}
79
80The above code instantiates 1 I2C device on the I2C bus which is on the
81network adapter in question.
82
83A variant of this is when you don't know for sure if an I2C device is
84present or not (for example for an optional feature which is not present
85on cheap variants of a board but you have no way to tell them apart), or
86it may have different addresses from one board to the next (manufacturer
87changing its design without notice). In this case, you can call
88i2c_new_probed_device() instead of i2c_new_device().
89
90Example (from the pnx4008 OHCI driver):
91
92static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
93
94static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
95{
96 (...)
97 struct i2c_adapter *i2c_adap;
98 struct i2c_board_info i2c_info;
99
100 (...)
101 i2c_adap = i2c_get_adapter(2);
102 memset(&i2c_info, 0, sizeof(struct i2c_board_info));
103 strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE);
104 isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
105 normal_i2c);
106 i2c_put_adapter(i2c_adap);
107 (...)
108}
109
110The above code instantiates up to 1 I2C device on the I2C bus which is on
111the OHCI adapter in question. It first tries at address 0x2c, if nothing
112is found there it tries address 0x2d, and if still nothing is found, it
113simply gives up.
114
115The driver which instantiated the I2C device is responsible for destroying
116it on cleanup. This is done by calling i2c_unregister_device() on the
117pointer that was earlier returned by i2c_new_device() or
118i2c_new_probed_device().
119
120
121Method 3: Probe an I2C bus for certain devices
122----------------------------------------------
123
124Sometimes you do not have enough information about an I2C device, not even
125to call i2c_new_probed_device(). The typical case is hardware monitoring
126chips on PC mainboards. There are several dozen models, which can live
127at 25 different addresses. Given the huge number of mainboards out there,
128it is next to impossible to build an exhaustive list of the hardware
129monitoring chips being used. Fortunately, most of these chips have
130manufacturer and device ID registers, so they can be identified by
131probing.
132
133In that case, I2C devices are neither declared nor instantiated
134explicitly. Instead, i2c-core will probe for such devices as soon as their
135drivers are loaded, and if any is found, an I2C device will be
136instantiated automatically. In order to prevent any misbehavior of this
137mechanism, the following restrictions apply:
138* The I2C device driver must implement the detect() method, which
139 identifies a supported device by reading from arbitrary registers.
140* Only buses which are likely to have a supported device and agree to be
141 probed, will be probed. For example this avoids probing for hardware
142 monitoring chips on a TV adapter.
143
144Example:
145See lm90_driver and lm90_detect() in drivers/hwmon/lm90.c
146
147I2C devices instantiated as a result of such a successful probe will be
148destroyed automatically when the driver which detected them is removed,
149or when the underlying I2C bus is itself destroyed, whichever happens
150first.
151
152Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6
153kernels will find out that this method 3 is essentially similar to what
154was done there. Two significant differences are:
155* Probing is only one way to instantiate I2C devices now, while it was the
156 only way back then. Where possible, methods 1 and 2 should be preferred.
157 Method 3 should only be used when there is no other way, as it can have
158 undesirable side effects.
159* I2C buses must now explicitly say which I2C driver classes can probe
160 them (by the means of the class bitfield), while all I2C buses were
161 probed by default back then. The default is an empty class which means
162 that no probing happens. The purpose of the class bitfield is to limit
163 the aforementioned undesirable side effects.
164
165Once again, method 3 should be avoided wherever possible. Explicit device
166instantiation (methods 1 and 2) is much preferred for it is safer and
167faster.
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index 6b9af7d479c2..c1a06f989cf7 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -207,15 +207,26 @@ You simply have to define a detect callback which will attempt to
207identify supported devices (returning 0 for supported ones and -ENODEV 207identify supported devices (returning 0 for supported ones and -ENODEV
208for unsupported ones), a list of addresses to probe, and a device type 208for unsupported ones), a list of addresses to probe, and a device type
209(or class) so that only I2C buses which may have that type of device 209(or class) so that only I2C buses which may have that type of device
210connected (and not otherwise enumerated) will be probed. The i2c 210connected (and not otherwise enumerated) will be probed. For example,
211core will then call you back as needed and will instantiate a device 211a driver for a hardware monitoring chip for which auto-detection is
212for you for every successful detection. 212needed would set its class to I2C_CLASS_HWMON, and only I2C adapters
213with a class including I2C_CLASS_HWMON would be probed by this driver.
214Note that the absence of matching classes does not prevent the use of
215a device of that type on the given I2C adapter. All it prevents is
216auto-detection; explicit instantiation of devices is still possible.
213 217
214Note that this mechanism is purely optional and not suitable for all 218Note that this mechanism is purely optional and not suitable for all
215devices. You need some reliable way to identify the supported devices 219devices. You need some reliable way to identify the supported devices
216(typically using device-specific, dedicated identification registers), 220(typically using device-specific, dedicated identification registers),
217otherwise misdetections are likely to occur and things can get wrong 221otherwise misdetections are likely to occur and things can get wrong
218quickly. 222quickly. Keep in mind that the I2C protocol doesn't include any
223standard way to detect the presence of a chip at a given address, let
224alone a standard way to identify devices. Even worse is the lack of
225semantics associated to bus transfers, which means that the same
226transfer can be seen as a read operation by a chip and as a write
227operation by another chip. For these reasons, explicit device
228instantiation should always be preferred to auto-detection where
229possible.
219 230
220 231
221Device Deletion 232Device Deletion
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index d1b082772e39..be3bde51b564 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -836,6 +836,12 @@ and is between 256 and 4096 characters. It is defined in the file
836 If specified, z/VM IUCV HVC accepts connections 836 If specified, z/VM IUCV HVC accepts connections
837 from listed z/VM user IDs only. 837 from listed z/VM user IDs only.
838 838
839 i2c_bus= [HW] Override the default board specific I2C bus speed
840 or register an additional I2C bus that is not
841 registered from board initialization code.
842 Format:
843 <bus_id>,<clkrate>
844
839 i8042.debug [HW] Toggle i8042 debug mode 845 i8042.debug [HW] Toggle i8042 debug mode
840 i8042.direct [HW] Put keyboard port into non-translated mode 846 i8042.direct [HW] Put keyboard port into non-translated mode
841 i8042.dumbkbd [HW] Pretend that controller can only read data from 847 i8042.dumbkbd [HW] Pretend that controller can only read data from
@@ -1325,8 +1331,13 @@ and is between 256 and 4096 characters. It is defined in the file
1325 1331
1326 memtest= [KNL,X86] Enable memtest 1332 memtest= [KNL,X86] Enable memtest
1327 Format: <integer> 1333 Format: <integer>
1328 range: 0,4 : pattern number
1329 default : 0 <disable> 1334 default : 0 <disable>
1335 Specifies the number of memtest passes to be
1336 performed. Each pass selects another test
1337 pattern from a given set of patterns. Memtest
1338 fills the memory with this pattern, validates
1339 memory contents and reserves bad memory
1340 regions that are detected.
1330 1341
1331 meye.*= [HW] Set MotionEye Camera parameters 1342 meye.*= [HW] Set MotionEye Camera parameters
1332 See Documentation/video4linux/meye.txt. 1343 See Documentation/video4linux/meye.txt.
diff --git a/Documentation/scsi/osd.txt b/Documentation/scsi/osd.txt
new file mode 100644
index 000000000000..da162f7fd5f5
--- /dev/null
+++ b/Documentation/scsi/osd.txt
@@ -0,0 +1,198 @@
1The OSD Standard
2================
3OSD (Object-Based Storage Device) is a T10 SCSI command set that is designed
4to provide efficient operation of input/output logical units that manage the
5allocation, placement, and accessing of variable-size data-storage containers,
6called objects. Objects are intended to contain operating system and application
7constructs. Each object has associated attributes attached to it, which are
8integral part of the object and provide metadata about the object. The standard
9defines some common obligatory attributes, but user attributes can be added as
10needed.
11
12See: http://www.t10.org/ftp/t10/drafts/osd2/ for the latest draft for OSD 2
13or search the web for "OSD SCSI"
14
15OSD in the Linux Kernel
16=======================
17osd-initiator:
18 The main component of OSD in Kernel is the osd-initiator library. Its main
19user is intended to be the pNFS-over-objects layout driver, which uses objects
20as its back-end data storage. Other clients are the other osd parts listed below.
21
22osd-uld:
23 This is a SCSI ULD that registers for OSD type devices and provides a testing
24platform, both for the in-kernel initiator as well as connected targets. It
25currently has no useful user-mode API, though it could have if need be.
26
27exofs:
28 Is an OSD based Linux file system. It uses the osd-initiator and osd-uld,
29to export a usable file system for users.
30See Documentation/filesystems/exofs.txt for more details
31
32osd target:
33 There are no current plans for an OSD target implementation in kernel. For all
34needs, a user-mode target that is based on the scsi tgt target framework is
35available from Ohio Supercomputer Center (OSC) at:
36http://www.open-osd.org/bin/view/Main/OscOsdProject
37There are several other target implementations. See http://open-osd.org for more
38links.
39
40Files and Folders
41=================
42This is the complete list of files included in this work:
43include/scsi/
44 osd_initiator.h Main API for the initiator library
45 osd_types.h Common OSD types
46 osd_sec.h Security Manager API
47 osd_protocol.h Wire definitions of the OSD standard protocol
48 osd_attributes.h Wire definitions of OSD attributes
49
50drivers/scsi/osd/
51 osd_initiator.c OSD-Initiator library implementation
52 osd_uld.c The OSD scsi ULD
53 osd_ktest.{h,c} In-kernel test suite (called by osd_uld)
54 osd_debug.h Some printk macros
55 Makefile For both in-tree and out-of-tree compilation
56 Kconfig Enables inclusion of the different pieces
57 osd_test.c User-mode application to call the kernel tests
58
59The OSD-Initiator Library
60=========================
61osd_initiator is a low level implementation of an osd initiator encoder.
62But even though, it should be intuitive and easy to use. Perhaps over time an
63higher lever will form that automates some of the more common recipes.
64
65init/fini:
66- osd_dev_init() associates a scsi_device with an osd_dev structure
67 and initializes some global pools. This should be done once per scsi_device
68 (OSD LUN). The osd_dev structure is needed for calling osd_start_request().
69
70- osd_dev_fini() cleans up before a osd_dev/scsi_device destruction.
71
72OSD commands encoding, execution, and decoding of results:
73
74struct osd_request's is used to iteratively encode an OSD command and carry
75its state throughout execution. Each request goes through these stages:
76
77a. osd_start_request() allocates the request.
78
79b. Any of the osd_req_* methods is used to encode a request of the specified
80 type.
81
82c. osd_req_add_{get,set}_attr_* may be called to add get/set attributes to the
83 CDB. "List" or "Page" mode can be used exclusively. The attribute-list API
84 can be called multiple times on the same request. However, only one
85 attribute-page can be read, as mandated by the OSD standard.
86
87d. osd_finalize_request() computes offsets into the data-in and data-out buffers
88 and signs the request using the provided capability key and integrity-
89 check parameters.
90
91e. osd_execute_request() may be called to execute the request via the block
92 layer and wait for its completion. The request can be executed
93 asynchronously by calling the block layer API directly.
94
95f. After execution, osd_req_decode_sense() can be called to decode the request's
96 sense information.
97
98g. osd_req_decode_get_attr() may be called to retrieve osd_add_get_attr_list()
99 values.
100
101h. osd_end_request() must be called to deallocate the request and any resource
102 associated with it. Note that osd_end_request cleans up the request at any
103 stage and it must always be called after a successful osd_start_request().
104
105osd_request's structure:
106
107The OSD standard defines a complex structure of IO segments pointed to by
108members in the CDB. Up to 3 segments can be deployed in the IN-Buffer and up to
1094 in the OUT-Buffer. The ASCII illustration below depicts a secure-read with
110associated get+set of attributes-lists. Other combinations very on the same
111basic theme. From no-segments-used up to all-segments-used.
112
113|________OSD-CDB__________|
114| |
115|read_len (offset=0) -|---------\
116| | |
117|get_attrs_list_length | |
118|get_attrs_list_offset -|----\ |
119| | | |
120|retrieved_attrs_alloc_len| | |
121|retrieved_attrs_offset -|----|----|-\
122| | | | |
123|set_attrs_list_length | | | |
124|set_attrs_list_offset -|-\ | | |
125| | | | | |
126|in_data_integ_offset -|-|--|----|-|-\
127|out_data_integ_offset -|-|--|--\ | | |
128\_________________________/ | | | | | |
129 | | | | | |
130|_______OUT-BUFFER________| | | | | | |
131| Set attr list |</ | | | | |
132| | | | | | |
133|-------------------------| | | | | |
134| Get attr descriptors |<---/ | | | |
135| | | | | |
136|-------------------------| | | | |
137| Out-data integrity |<------/ | | |
138| | | | |
139\_________________________/ | | |
140 | | |
141|________IN-BUFFER________| | | |
142| In-Data read |<--------/ | |
143| | | |
144|-------------------------| | |
145| Get attr list |<----------/ |
146| | |
147|-------------------------| |
148| In-data integrity |<------------/
149| |
150\_________________________/
151
152A block device request can carry bidirectional payload by means of associating
153a bidi_read request with a main write-request. Each in/out request is described
154by a chain of BIOs associated with each request.
155The CDB is of a SCSI VARLEN CDB format, as described by OSD standard.
156The OSD standard also mandates alignment restrictions at start of each segment.
157
158In the code, in struct osd_request, there are two _osd_io_info structures to
159describe the IN/OUT buffers above, two BIOs for the data payload and up to five
160_osd_req_data_segment structures to hold the different segments allocation and
161information.
162
163Important: We have chosen to disregard the assumption that a BIO-chain (and
164the resulting sg-list) describes a linear memory buffer. Meaning only first and
165last scatter chain can be incomplete and all the middle chains are of PAGE_SIZE.
166For us, a scatter-gather-list, as its name implies and as used by the Networking
167layer, is to describe a vector of buffers that will be transferred to/from the
168wire. It works very well with current iSCSI transport. iSCSI is currently the
169only deployed OSD transport. In the future we anticipate SAS and FC attached OSD
170devices as well.
171
172The OSD Testing ULD
173===================
174TODO: More user-mode control on tests.
175
176Authors, Mailing list
177=====================
178Please communicate with us on any deployment of osd, whether using this code
179or not.
180
181Any problems, questions, bug reports, lonely OSD nights, please email:
182 OSD Dev List <osd-dev@open-osd.org>
183
184More up-to-date information can be found on:
185http://open-osd.org
186
187Boaz Harrosh <bharrosh@panasas.com>
188Benny Halevy <bhalevy@panasas.com>
189
190References
191==========
192Weber, R., "SCSI Object-Based Storage Device Commands",
193T10/1355-D ANSI/INCITS 400-2004,
194http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf
195
196Weber, R., "SCSI Object-Based Storage Device Commands -2 (OSD-2)"
197T10/1729-D, Working Draft, rev. 3
198http://www.t10.org/ftp/t10/drafts/osd2/osd2r03.pdf
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 7b4596ac4120..e0203662f9e9 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -158,7 +158,7 @@ Offset Proto Name Meaning
1580202/4 2.00+ header Magic signature "HdrS" 1580202/4 2.00+ header Magic signature "HdrS"
1590206/2 2.00+ version Boot protocol version supported 1590206/2 2.00+ version Boot protocol version supported
1600208/4 2.00+ realmode_swtch Boot loader hook (see below) 1600208/4 2.00+ realmode_swtch Boot loader hook (see below)
161020C/2 2.00+ start_sys The load-low segment (0x1000) (obsolete) 161020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete)
162020E/2 2.00+ kernel_version Pointer to kernel version string 162020E/2 2.00+ kernel_version Pointer to kernel version string
1630210/1 2.00+ type_of_loader Boot loader identifier 1630210/1 2.00+ type_of_loader Boot loader identifier
1640211/1 2.00+ loadflags Boot protocol option flags 1640211/1 2.00+ loadflags Boot protocol option flags
@@ -170,10 +170,11 @@ Offset Proto Name Meaning
1700224/2 2.01+ heap_end_ptr Free memory after setup end 1700224/2 2.01+ heap_end_ptr Free memory after setup end
1710226/2 N/A pad1 Unused 1710226/2 N/A pad1 Unused
1720228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line 1720228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line
173022C/4 2.03+ initrd_addr_max Highest legal initrd address 173022C/4 2.03+ ramdisk_max Highest legal initrd address
1740230/4 2.05+ kernel_alignment Physical addr alignment required for kernel 1740230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
1750234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not 1750234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
1760235/3 N/A pad2 Unused 1760235/1 N/A pad2 Unused
1770236/2 N/A pad3 Unused
1770238/4 2.06+ cmdline_size Maximum size of the kernel command line 1780238/4 2.06+ cmdline_size Maximum size of the kernel command line
178023C/4 2.07+ hardware_subarch Hardware subarchitecture 179023C/4 2.07+ hardware_subarch Hardware subarchitecture
1790240/8 2.07+ hardware_subarch_data Subarchitecture-specific data 1800240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
@@ -299,14 +300,14 @@ Protocol: 2.00+
299 e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version 300 e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version
300 10.17. 301 10.17.
301 302
302Field name: readmode_swtch 303Field name: realmode_swtch
303Type: modify (optional) 304Type: modify (optional)
304Offset/size: 0x208/4 305Offset/size: 0x208/4
305Protocol: 2.00+ 306Protocol: 2.00+
306 307
307 Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) 308 Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
308 309
309Field name: start_sys 310Field name: start_sys_seg
310Type: read 311Type: read
311Offset/size: 0x20c/2 312Offset/size: 0x20c/2
312Protocol: 2.00+ 313Protocol: 2.00+
@@ -468,7 +469,7 @@ Protocol: 2.02+
468 zero, the kernel will assume that your boot loader does not support 469 zero, the kernel will assume that your boot loader does not support
469 the 2.02+ protocol. 470 the 2.02+ protocol.
470 471
471Field name: initrd_addr_max 472Field name: ramdisk_max
472Type: read 473Type: read
473Offset/size: 0x22c/4 474Offset/size: 0x22c/4
474Protocol: 2.03+ 475Protocol: 2.03+
@@ -542,7 +543,10 @@ Protocol: 2.08+
542 543
543 The payload may be compressed. The format of both the compressed and 544 The payload may be compressed. The format of both the compressed and
544 uncompressed data should be determined using the standard magic 545 uncompressed data should be determined using the standard magic
545 numbers. Currently only gzip compressed ELF is used. 546 numbers. The currently supported compression formats are gzip
547 (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A) and LZMA
548 (magic number 5D 00). The uncompressed payload is currently always ELF
549 (magic number 7F 45 4C 46).
546 550
547Field name: payload_length 551Field name: payload_length
548Type: read 552Type: read