diff options
author | Russell King <rmk@dyn-67.arm.linux.org.uk> | 2008-08-07 04:55:03 -0400 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2008-08-07 04:55:03 -0400 |
commit | 4fb8af10d0fd09372d52966b76922b9e82bbc950 (patch) | |
tree | d240e4d40357583e3f3eb228dccf20122a5b31ed /Documentation | |
parent | f44f82e8a20b98558486eb14497b2f71c78fa325 (diff) | |
parent | 64a99d2a8c3ed5c4e39f3ae1cc682aa8fd3977fc (diff) |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes
Diffstat (limited to 'Documentation')
33 files changed, 2218 insertions, 513 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 6de71308a906..5b5aba404aac 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -89,8 +89,6 @@ cciss.txt | |||
89 | - info, major/minor #'s for Compaq's SMART Array Controllers. | 89 | - info, major/minor #'s for Compaq's SMART Array Controllers. |
90 | cdrom/ | 90 | cdrom/ |
91 | - directory with information on the CD-ROM drivers that Linux has. | 91 | - directory with information on the CD-ROM drivers that Linux has. |
92 | cli-sti-removal.txt | ||
93 | - cli()/sti() removal guide. | ||
94 | computone.txt | 92 | computone.txt |
95 | - info on Computone Intelliport II/Plus Multiport Serial Driver. | 93 | - info on Computone Intelliport II/Plus Multiport Serial Driver. |
96 | connector/ | 94 | connector/ |
diff --git a/Documentation/ABI/testing/sysfs-class-regulator b/Documentation/ABI/testing/sysfs-class-regulator new file mode 100644 index 000000000000..79a4a75b2d2c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-regulator | |||
@@ -0,0 +1,315 @@ | |||
1 | What: /sys/class/regulator/.../state | ||
2 | Date: April 2008 | ||
3 | KernelVersion: 2.6.26 | ||
4 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
5 | Description: | ||
6 | Each regulator directory will contain a field called | ||
7 | state. This holds the regulator output state. | ||
8 | |||
9 | This will be one of the following strings: | ||
10 | |||
11 | 'enabled' | ||
12 | 'disabled' | ||
13 | 'unknown' | ||
14 | |||
15 | 'enabled' means the regulator output is ON and is supplying | ||
16 | power to the system. | ||
17 | |||
18 | 'disabled' means the regulator output is OFF and is not | ||
19 | supplying power to the system.. | ||
20 | |||
21 | 'unknown' means software cannot determine the state. | ||
22 | |||
23 | NOTE: this field can be used in conjunction with microvolts | ||
24 | and microamps to determine regulator output levels. | ||
25 | |||
26 | |||
27 | What: /sys/class/regulator/.../type | ||
28 | Date: April 2008 | ||
29 | KernelVersion: 2.6.26 | ||
30 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
31 | Description: | ||
32 | Each regulator directory will contain a field called | ||
33 | type. This holds the regulator type. | ||
34 | |||
35 | This will be one of the following strings: | ||
36 | |||
37 | 'voltage' | ||
38 | 'current' | ||
39 | 'unknown' | ||
40 | |||
41 | 'voltage' means the regulator output voltage can be controlled | ||
42 | by software. | ||
43 | |||
44 | 'current' means the regulator output current limit can be | ||
45 | controlled by software. | ||
46 | |||
47 | 'unknown' means software cannot control either voltage or | ||
48 | current limit. | ||
49 | |||
50 | |||
51 | What: /sys/class/regulator/.../microvolts | ||
52 | Date: April 2008 | ||
53 | KernelVersion: 2.6.26 | ||
54 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
55 | Description: | ||
56 | Each regulator directory will contain a field called | ||
57 | microvolts. This holds the regulator output voltage setting | ||
58 | measured in microvolts (i.e. E-6 Volts). | ||
59 | |||
60 | NOTE: This value should not be used to determine the regulator | ||
61 | output voltage level as this value is the same regardless of | ||
62 | whether the regulator is enabled or disabled. | ||
63 | |||
64 | |||
65 | What: /sys/class/regulator/.../microamps | ||
66 | Date: April 2008 | ||
67 | KernelVersion: 2.6.26 | ||
68 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
69 | Description: | ||
70 | Each regulator directory will contain a field called | ||
71 | microamps. This holds the regulator output current limit | ||
72 | setting measured in microamps (i.e. E-6 Amps). | ||
73 | |||
74 | NOTE: This value should not be used to determine the regulator | ||
75 | output current level as this value is the same regardless of | ||
76 | whether the regulator is enabled or disabled. | ||
77 | |||
78 | |||
79 | What: /sys/class/regulator/.../opmode | ||
80 | Date: April 2008 | ||
81 | KernelVersion: 2.6.26 | ||
82 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
83 | Description: | ||
84 | Each regulator directory will contain a field called | ||
85 | opmode. This holds the regulator operating mode setting. | ||
86 | |||
87 | The opmode value can be one of the following strings: | ||
88 | |||
89 | 'fast' | ||
90 | 'normal' | ||
91 | 'idle' | ||
92 | 'standby' | ||
93 | 'unknown' | ||
94 | |||
95 | The modes are described in include/linux/regulator/regulator.h | ||
96 | |||
97 | NOTE: This value should not be used to determine the regulator | ||
98 | output operating mode as this value is the same regardless of | ||
99 | whether the regulator is enabled or disabled. | ||
100 | |||
101 | |||
102 | What: /sys/class/regulator/.../min_microvolts | ||
103 | Date: April 2008 | ||
104 | KernelVersion: 2.6.26 | ||
105 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
106 | Description: | ||
107 | Each regulator directory will contain a field called | ||
108 | min_microvolts. This holds the minimum safe working regulator | ||
109 | output voltage setting for this domain measured in microvolts. | ||
110 | |||
111 | NOTE: this will return the string 'constraint not defined' if | ||
112 | the power domain has no min microvolts constraint defined by | ||
113 | platform code. | ||
114 | |||
115 | |||
116 | What: /sys/class/regulator/.../max_microvolts | ||
117 | Date: April 2008 | ||
118 | KernelVersion: 2.6.26 | ||
119 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
120 | Description: | ||
121 | Each regulator directory will contain a field called | ||
122 | max_microvolts. This holds the maximum safe working regulator | ||
123 | output voltage setting for this domain measured in microvolts. | ||
124 | |||
125 | NOTE: this will return the string 'constraint not defined' if | ||
126 | the power domain has no max microvolts constraint defined by | ||
127 | platform code. | ||
128 | |||
129 | |||
130 | What: /sys/class/regulator/.../min_microamps | ||
131 | Date: April 2008 | ||
132 | KernelVersion: 2.6.26 | ||
133 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
134 | Description: | ||
135 | Each regulator directory will contain a field called | ||
136 | min_microamps. This holds the minimum safe working regulator | ||
137 | output current limit setting for this domain measured in | ||
138 | microamps. | ||
139 | |||
140 | NOTE: this will return the string 'constraint not defined' if | ||
141 | the power domain has no min microamps constraint defined by | ||
142 | platform code. | ||
143 | |||
144 | |||
145 | What: /sys/class/regulator/.../max_microamps | ||
146 | Date: April 2008 | ||
147 | KernelVersion: 2.6.26 | ||
148 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
149 | Description: | ||
150 | Each regulator directory will contain a field called | ||
151 | max_microamps. This holds the maximum safe working regulator | ||
152 | output current limit setting for this domain measured in | ||
153 | microamps. | ||
154 | |||
155 | NOTE: this will return the string 'constraint not defined' if | ||
156 | the power domain has no max microamps constraint defined by | ||
157 | platform code. | ||
158 | |||
159 | |||
160 | What: /sys/class/regulator/.../num_users | ||
161 | Date: April 2008 | ||
162 | KernelVersion: 2.6.26 | ||
163 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
164 | Description: | ||
165 | Each regulator directory will contain a field called | ||
166 | num_users. This holds the number of consumer devices that | ||
167 | have called regulator_enable() on this regulator. | ||
168 | |||
169 | |||
170 | What: /sys/class/regulator/.../requested_microamps | ||
171 | Date: April 2008 | ||
172 | KernelVersion: 2.6.26 | ||
173 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
174 | Description: | ||
175 | Each regulator directory will contain a field called | ||
176 | requested_microamps. This holds the total requested load | ||
177 | current in microamps for this regulator from all its consumer | ||
178 | devices. | ||
179 | |||
180 | |||
181 | What: /sys/class/regulator/.../parent | ||
182 | Date: April 2008 | ||
183 | KernelVersion: 2.6.26 | ||
184 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
185 | Description: | ||
186 | Some regulator directories will contain a link called parent. | ||
187 | This points to the parent or supply regulator if one exists. | ||
188 | |||
189 | What: /sys/class/regulator/.../suspend_mem_microvolts | ||
190 | Date: May 2008 | ||
191 | KernelVersion: 2.6.26 | ||
192 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
193 | Description: | ||
194 | Each regulator directory will contain a field called | ||
195 | suspend_mem_microvolts. This holds the regulator output | ||
196 | voltage setting for this domain measured in microvolts when | ||
197 | the system is suspended to memory. | ||
198 | |||
199 | NOTE: this will return the string 'not defined' if | ||
200 | the power domain has no suspend to memory voltage defined by | ||
201 | platform code. | ||
202 | |||
203 | What: /sys/class/regulator/.../suspend_disk_microvolts | ||
204 | Date: May 2008 | ||
205 | KernelVersion: 2.6.26 | ||
206 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
207 | Description: | ||
208 | Each regulator directory will contain a field called | ||
209 | suspend_disk_microvolts. This holds the regulator output | ||
210 | voltage setting for this domain measured in microvolts when | ||
211 | the system is suspended to disk. | ||
212 | |||
213 | NOTE: this will return the string 'not defined' if | ||
214 | the power domain has no suspend to disk voltage defined by | ||
215 | platform code. | ||
216 | |||
217 | What: /sys/class/regulator/.../suspend_standby_microvolts | ||
218 | Date: May 2008 | ||
219 | KernelVersion: 2.6.26 | ||
220 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
221 | Description: | ||
222 | Each regulator directory will contain a field called | ||
223 | suspend_standby_microvolts. This holds the regulator output | ||
224 | voltage setting for this domain measured in microvolts when | ||
225 | the system is suspended to standby. | ||
226 | |||
227 | NOTE: this will return the string 'not defined' if | ||
228 | the power domain has no suspend to standby voltage defined by | ||
229 | platform code. | ||
230 | |||
231 | What: /sys/class/regulator/.../suspend_mem_mode | ||
232 | Date: May 2008 | ||
233 | KernelVersion: 2.6.26 | ||
234 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
235 | Description: | ||
236 | Each regulator directory will contain a field called | ||
237 | suspend_mem_mode. This holds the regulator operating mode | ||
238 | setting for this domain when the system is suspended to | ||
239 | memory. | ||
240 | |||
241 | NOTE: this will return the string 'not defined' if | ||
242 | the power domain has no suspend to memory mode defined by | ||
243 | platform code. | ||
244 | |||
245 | What: /sys/class/regulator/.../suspend_disk_mode | ||
246 | Date: May 2008 | ||
247 | KernelVersion: 2.6.26 | ||
248 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
249 | Description: | ||
250 | Each regulator directory will contain a field called | ||
251 | suspend_disk_mode. This holds the regulator operating mode | ||
252 | setting for this domain when the system is suspended to disk. | ||
253 | |||
254 | NOTE: this will return the string 'not defined' if | ||
255 | the power domain has no suspend to disk mode defined by | ||
256 | platform code. | ||
257 | |||
258 | What: /sys/class/regulator/.../suspend_standby_mode | ||
259 | Date: May 2008 | ||
260 | KernelVersion: 2.6.26 | ||
261 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
262 | Description: | ||
263 | Each regulator directory will contain a field called | ||
264 | suspend_standby_mode. This holds the regulator operating mode | ||
265 | setting for this domain when the system is suspended to | ||
266 | standby. | ||
267 | |||
268 | NOTE: this will return the string 'not defined' if | ||
269 | the power domain has no suspend to standby mode defined by | ||
270 | platform code. | ||
271 | |||
272 | What: /sys/class/regulator/.../suspend_mem_state | ||
273 | Date: May 2008 | ||
274 | KernelVersion: 2.6.26 | ||
275 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
276 | Description: | ||
277 | Each regulator directory will contain a field called | ||
278 | suspend_mem_state. This holds the regulator operating state | ||
279 | when suspended to memory. | ||
280 | |||
281 | This will be one of the following strings: | ||
282 | |||
283 | 'enabled' | ||
284 | 'disabled' | ||
285 | 'not defined' | ||
286 | |||
287 | What: /sys/class/regulator/.../suspend_disk_state | ||
288 | Date: May 2008 | ||
289 | KernelVersion: 2.6.26 | ||
290 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
291 | Description: | ||
292 | Each regulator directory will contain a field called | ||
293 | suspend_disk_state. This holds the regulator operating state | ||
294 | when suspended to disk. | ||
295 | |||
296 | This will be one of the following strings: | ||
297 | |||
298 | 'enabled' | ||
299 | 'disabled' | ||
300 | 'not defined' | ||
301 | |||
302 | What: /sys/class/regulator/.../suspend_standby_state | ||
303 | Date: May 2008 | ||
304 | KernelVersion: 2.6.26 | ||
305 | Contact: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
306 | Description: | ||
307 | Each regulator directory will contain a field called | ||
308 | suspend_standby_state. This holds the regulator operating | ||
309 | state when suspended to standby. | ||
310 | |||
311 | This will be one of the following strings: | ||
312 | |||
313 | 'enabled' | ||
314 | 'disabled' | ||
315 | 'not defined' | ||
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 0eb0d027eb32..1d1b34500b69 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -12,7 +12,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ | |||
12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ | 12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ |
13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ | 13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ |
14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ | 14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ |
15 | mac80211.xml debugobjects.xml | 15 | mac80211.xml debugobjects.xml sh.xml |
16 | 16 | ||
17 | ### | 17 | ### |
18 | # The build process is as follows (targets): | 18 | # The build process is as follows (targets): |
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index e8acd1f03456..372dec20c8da 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl | |||
@@ -98,6 +98,24 @@ | |||
98 | "Kernel debugging" select "KGDB: kernel debugging with remote gdb". | 98 | "Kernel debugging" select "KGDB: kernel debugging with remote gdb". |
99 | </para> | 99 | </para> |
100 | <para> | 100 | <para> |
101 | It is advised, but not required that you turn on the | ||
102 | CONFIG_FRAME_POINTER kernel option. This option inserts code to | ||
103 | into the compiled executable which saves the frame information in | ||
104 | registers or on the stack at different points which will allow a | ||
105 | debugger such as gdb to more accurately construct stack back traces | ||
106 | while debugging the kernel. | ||
107 | </para> | ||
108 | <para> | ||
109 | If the architecture that you are using supports the kernel option | ||
110 | CONFIG_DEBUG_RODATA, you should consider turning it off. This | ||
111 | option will prevent the use of software breakpoints because it | ||
112 | marks certain regions of the kernel's memory space as read-only. | ||
113 | If kgdb supports it for the architecture you are using, you can | ||
114 | use hardware breakpoints if you desire to run with the | ||
115 | CONFIG_DEBUG_RODATA option turned on, else you need to turn off | ||
116 | this option. | ||
117 | </para> | ||
118 | <para> | ||
101 | Next you should choose one of more I/O drivers to interconnect debugging | 119 | Next you should choose one of more I/O drivers to interconnect debugging |
102 | host and debugged target. Early boot debugging requires a KGDB | 120 | host and debugged target. Early boot debugging requires a KGDB |
103 | I/O driver that supports early debugging and the driver must be | 121 | I/O driver that supports early debugging and the driver must be |
diff --git a/Documentation/DocBook/s390-drivers.tmpl b/Documentation/DocBook/s390-drivers.tmpl index 4acc73240a6d..95bfc12e5439 100644 --- a/Documentation/DocBook/s390-drivers.tmpl +++ b/Documentation/DocBook/s390-drivers.tmpl | |||
@@ -100,7 +100,7 @@ | |||
100 | the hardware structures represented here, please consult the Principles | 100 | the hardware structures represented here, please consult the Principles |
101 | of Operation. | 101 | of Operation. |
102 | </para> | 102 | </para> |
103 | !Iinclude/asm-s390/cio.h | 103 | !Iarch/s390/include/asm/cio.h |
104 | </sect1> | 104 | </sect1> |
105 | <sect1 id="ccwdev"> | 105 | <sect1 id="ccwdev"> |
106 | <title>ccw devices</title> | 106 | <title>ccw devices</title> |
@@ -114,7 +114,7 @@ | |||
114 | ccw device structure. Device drivers must not bypass those functions | 114 | ccw device structure. Device drivers must not bypass those functions |
115 | or strange side effects may happen. | 115 | or strange side effects may happen. |
116 | </para> | 116 | </para> |
117 | !Iinclude/asm-s390/ccwdev.h | 117 | !Iarch/s390/include/asm/ccwdev.h |
118 | !Edrivers/s390/cio/device.c | 118 | !Edrivers/s390/cio/device.c |
119 | !Edrivers/s390/cio/device_ops.c | 119 | !Edrivers/s390/cio/device_ops.c |
120 | </sect1> | 120 | </sect1> |
@@ -125,7 +125,7 @@ | |||
125 | measurement data which is made available by the channel subsystem | 125 | measurement data which is made available by the channel subsystem |
126 | for each channel attached device. | 126 | for each channel attached device. |
127 | </para> | 127 | </para> |
128 | !Iinclude/asm-s390/cmb.h | 128 | !Iarch/s390/include/asm/cmb.h |
129 | !Edrivers/s390/cio/cmf.c | 129 | !Edrivers/s390/cio/cmf.c |
130 | </sect1> | 130 | </sect1> |
131 | </chapter> | 131 | </chapter> |
@@ -142,7 +142,7 @@ | |||
142 | </para> | 142 | </para> |
143 | <sect1 id="ccwgroupdevices"> | 143 | <sect1 id="ccwgroupdevices"> |
144 | <title>ccw group devices</title> | 144 | <title>ccw group devices</title> |
145 | !Iinclude/asm-s390/ccwgroup.h | 145 | !Iarch/s390/include/asm/ccwgroup.h |
146 | !Edrivers/s390/cio/ccwgroup.c | 146 | !Edrivers/s390/cio/ccwgroup.c |
147 | </sect1> | 147 | </sect1> |
148 | </chapter> | 148 | </chapter> |
diff --git a/Documentation/DocBook/sh.tmpl b/Documentation/DocBook/sh.tmpl new file mode 100644 index 000000000000..0c3dc4c69dd1 --- /dev/null +++ b/Documentation/DocBook/sh.tmpl | |||
@@ -0,0 +1,105 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?> | ||
2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | ||
3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> | ||
4 | |||
5 | <book id="sh-drivers"> | ||
6 | <bookinfo> | ||
7 | <title>SuperH Interfaces Guide</title> | ||
8 | |||
9 | <authorgroup> | ||
10 | <author> | ||
11 | <firstname>Paul</firstname> | ||
12 | <surname>Mundt</surname> | ||
13 | <affiliation> | ||
14 | <address> | ||
15 | <email>lethal@linux-sh.org</email> | ||
16 | </address> | ||
17 | </affiliation> | ||
18 | </author> | ||
19 | </authorgroup> | ||
20 | |||
21 | <copyright> | ||
22 | <year>2008</year> | ||
23 | <holder>Paul Mundt</holder> | ||
24 | </copyright> | ||
25 | <copyright> | ||
26 | <year>2008</year> | ||
27 | <holder>Renesas Technology Corp.</holder> | ||
28 | </copyright> | ||
29 | |||
30 | <legalnotice> | ||
31 | <para> | ||
32 | This documentation is free software; you can redistribute | ||
33 | it and/or modify it under the terms of the GNU General Public | ||
34 | License version 2 as published by the Free Software Foundation. | ||
35 | </para> | ||
36 | |||
37 | <para> | ||
38 | This program is distributed in the hope that it will be | ||
39 | useful, but WITHOUT ANY WARRANTY; without even the implied | ||
40 | warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | ||
41 | See the GNU General Public License for more details. | ||
42 | </para> | ||
43 | |||
44 | <para> | ||
45 | You should have received a copy of the GNU General Public | ||
46 | License along with this program; if not, write to the Free | ||
47 | Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, | ||
48 | MA 02111-1307 USA | ||
49 | </para> | ||
50 | |||
51 | <para> | ||
52 | For more details see the file COPYING in the source | ||
53 | distribution of Linux. | ||
54 | </para> | ||
55 | </legalnotice> | ||
56 | </bookinfo> | ||
57 | |||
58 | <toc></toc> | ||
59 | |||
60 | <chapter id="mm"> | ||
61 | <title>Memory Management</title> | ||
62 | <sect1 id="sh4"> | ||
63 | <title>SH-4</title> | ||
64 | <sect2 id="sq"> | ||
65 | <title>Store Queue API</title> | ||
66 | !Earch/sh/kernel/cpu/sh4/sq.c | ||
67 | </sect2> | ||
68 | </sect1> | ||
69 | <sect1 id="sh5"> | ||
70 | <title>SH-5</title> | ||
71 | <sect2 id="tlb"> | ||
72 | <title>TLB Interfaces</title> | ||
73 | !Iarch/sh/mm/tlb-sh5.c | ||
74 | !Iarch/sh/include/asm/tlb_64.h | ||
75 | </sect2> | ||
76 | </sect1> | ||
77 | </chapter> | ||
78 | <chapter id="clk"> | ||
79 | <title>Clock Framework Extensions</title> | ||
80 | !Iarch/sh/include/asm/clock.h | ||
81 | </chapter> | ||
82 | <chapter id="mach"> | ||
83 | <title>Machine Specific Interfaces</title> | ||
84 | <sect1 id="dreamcast"> | ||
85 | <title>mach-dreamcast</title> | ||
86 | !Iarch/sh/boards/mach-dreamcast/rtc.c | ||
87 | </sect1> | ||
88 | <sect1 id="x3proto"> | ||
89 | <title>mach-x3proto</title> | ||
90 | !Earch/sh/boards/mach-x3proto/ilsel.c | ||
91 | </sect1> | ||
92 | </chapter> | ||
93 | <chapter id="busses"> | ||
94 | <title>Busses</title> | ||
95 | <sect1 id="superhyway"> | ||
96 | <title>SuperHyway</title> | ||
97 | !Edrivers/sh/superhyway/superhyway.c | ||
98 | </sect1> | ||
99 | |||
100 | <sect1 id="maple"> | ||
101 | <title>Maple</title> | ||
102 | !Edrivers/sh/maple/maple.c | ||
103 | </sect1> | ||
104 | </chapter> | ||
105 | </book> | ||
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 118ca6e9404f..f79ad9ff6031 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -528,7 +528,33 @@ See more details on the proper patch format in the following | |||
528 | references. | 528 | references. |
529 | 529 | ||
530 | 530 | ||
531 | 16) Sending "git pull" requests (from Linus emails) | ||
531 | 532 | ||
533 | Please write the git repo address and branch name alone on the same line | ||
534 | so that I can't even by mistake pull from the wrong branch, and so | ||
535 | that a triple-click just selects the whole thing. | ||
536 | |||
537 | So the proper format is something along the lines of: | ||
538 | |||
539 | "Please pull from | ||
540 | |||
541 | git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus | ||
542 | |||
543 | to get these changes:" | ||
544 | |||
545 | so that I don't have to hunt-and-peck for the address and inevitably | ||
546 | get it wrong (actually, I've only gotten it wrong a few times, and | ||
547 | checking against the diffstat tells me when I get it wrong, but I'm | ||
548 | just a lot more comfortable when I don't have to "look for" the right | ||
549 | thing to pull, and double-check that I have the right branch-name). | ||
550 | |||
551 | |||
552 | Please use "git diff -M --stat --summary" to generate the diffstat: | ||
553 | the -M enables rename detection, and the summary enables a summary of | ||
554 | new/deleted or renamed files. | ||
555 | |||
556 | With rename detection, the statistics are rather different [...] | ||
557 | because git will notice that a fair number of the changes are renames. | ||
532 | 558 | ||
533 | ----------------------------------- | 559 | ----------------------------------- |
534 | SECTION 2 - HINTS, TIPS, AND TRICKS | 560 | SECTION 2 - HINTS, TIPS, AND TRICKS |
diff --git a/Documentation/cli-sti-removal.txt b/Documentation/cli-sti-removal.txt deleted file mode 100644 index 60932b02fcb3..000000000000 --- a/Documentation/cli-sti-removal.txt +++ /dev/null | |||
@@ -1,133 +0,0 @@ | |||
1 | |||
2 | #### cli()/sti() removal guide, started by Ingo Molnar <mingo@redhat.com> | ||
3 | |||
4 | |||
5 | as of 2.5.28, five popular macros have been removed on SMP, and | ||
6 | are being phased out on UP: | ||
7 | |||
8 | cli(), sti(), save_flags(flags), save_flags_cli(flags), restore_flags(flags) | ||
9 | |||
10 | until now it was possible to protect driver code against interrupt | ||
11 | handlers via a cli(), but from now on other, more lightweight methods | ||
12 | have to be used for synchronization, such as spinlocks or semaphores. | ||
13 | |||
14 | for example, driver code that used to do something like: | ||
15 | |||
16 | struct driver_data; | ||
17 | |||
18 | irq_handler (...) | ||
19 | { | ||
20 | .... | ||
21 | driver_data.finish = 1; | ||
22 | driver_data.new_work = 0; | ||
23 | .... | ||
24 | } | ||
25 | |||
26 | ... | ||
27 | |||
28 | ioctl_func (...) | ||
29 | { | ||
30 | ... | ||
31 | cli(); | ||
32 | ... | ||
33 | driver_data.finish = 0; | ||
34 | driver_data.new_work = 2; | ||
35 | ... | ||
36 | sti(); | ||
37 | ... | ||
38 | } | ||
39 | |||
40 | was SMP-correct because the cli() function ensured that no | ||
41 | interrupt handler (amongst them the above irq_handler()) function | ||
42 | would execute while the cli()-ed section is executing. | ||
43 | |||
44 | but from now on a more direct method of locking has to be used: | ||
45 | |||
46 | DEFINE_SPINLOCK(driver_lock); | ||
47 | struct driver_data; | ||
48 | |||
49 | irq_handler (...) | ||
50 | { | ||
51 | unsigned long flags; | ||
52 | .... | ||
53 | spin_lock_irqsave(&driver_lock, flags); | ||
54 | .... | ||
55 | driver_data.finish = 1; | ||
56 | driver_data.new_work = 0; | ||
57 | .... | ||
58 | spin_unlock_irqrestore(&driver_lock, flags); | ||
59 | .... | ||
60 | } | ||
61 | |||
62 | ... | ||
63 | |||
64 | ioctl_func (...) | ||
65 | { | ||
66 | ... | ||
67 | spin_lock_irq(&driver_lock); | ||
68 | ... | ||
69 | driver_data.finish = 0; | ||
70 | driver_data.new_work = 2; | ||
71 | ... | ||
72 | spin_unlock_irq(&driver_lock); | ||
73 | ... | ||
74 | } | ||
75 | |||
76 | the above code has a number of advantages: | ||
77 | |||
78 | - the locking relation is easier to understand - actual lock usage | ||
79 | pinpoints the critical sections. cli() usage is too opaque. | ||
80 | Easier to understand means it's easier to debug. | ||
81 | |||
82 | - it's faster, because spinlocks are faster to acquire than the | ||
83 | potentially heavily-used IRQ lock. Furthermore, your driver does | ||
84 | not have to wait eg. for a big heavy SCSI interrupt to finish, | ||
85 | because the driver_lock spinlock is only used by your driver. | ||
86 | cli() on the other hand was used by many drivers, and extended | ||
87 | the critical section to the whole IRQ handler function - creating | ||
88 | serious lock contention. | ||
89 | |||
90 | |||
91 | to make the transition easier, we've still kept the cli(), sti(), | ||
92 | save_flags(), save_flags_cli() and restore_flags() macros defined | ||
93 | on UP systems - but their usage will be phased out until 2.6 is | ||
94 | released. | ||
95 | |||
96 | drivers that want to disable local interrupts (interrupts on the | ||
97 | current CPU), can use the following five macros: | ||
98 | |||
99 | local_irq_disable(), local_irq_enable(), local_save_flags(flags), | ||
100 | local_irq_save(flags), local_irq_restore(flags) | ||
101 | |||
102 | but beware, their meaning and semantics are much simpler, far from | ||
103 | that of the old cli(), sti(), save_flags(flags) and restore_flags(flags) | ||
104 | SMP meaning: | ||
105 | |||
106 | local_irq_disable() => turn local IRQs off | ||
107 | |||
108 | local_irq_enable() => turn local IRQs on | ||
109 | |||
110 | local_save_flags(flags) => save the current IRQ state into flags. The | ||
111 | state can be on or off. (on some | ||
112 | architectures there's even more bits in it.) | ||
113 | |||
114 | local_irq_save(flags) => save the current IRQ state into flags and | ||
115 | disable interrupts. | ||
116 | |||
117 | local_irq_restore(flags) => restore the IRQ state from flags. | ||
118 | |||
119 | (local_irq_save can save both irqs on and irqs off state, and | ||
120 | local_irq_restore can restore into both irqs on and irqs off state.) | ||
121 | |||
122 | another related change is that synchronize_irq() now takes a parameter: | ||
123 | synchronize_irq(irq). This change too has the purpose of making SMP | ||
124 | synchronization more lightweight - this way you can wait for your own | ||
125 | interrupt handler to finish, no need to wait for other IRQ sources. | ||
126 | |||
127 | |||
128 | why were these changes done? The main reason was the architectural burden | ||
129 | of maintaining the cli()/sti() interface - it became a real problem. The | ||
130 | new interrupt system is much more streamlined, easier to understand, debug, | ||
131 | and it's also a bit faster - the same happened to it that will happen to | ||
132 | cli()/sti() using drivers once they convert to spinlocks :-) | ||
133 | |||
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 721c71b86e06..c23955404bf5 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -47,6 +47,30 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org> | |||
47 | 47 | ||
48 | --------------------------- | 48 | --------------------------- |
49 | 49 | ||
50 | What: old tuner-3036 i2c driver | ||
51 | When: 2.6.28 | ||
52 | Why: This driver is for VERY old i2c-over-parallel port teletext receiver | ||
53 | boxes. Rather then spending effort on converting this driver to V4L2, | ||
54 | and since it is extremely unlikely that anyone still uses one of these | ||
55 | devices, it was decided to drop it. | ||
56 | Who: Hans Verkuil <hverkuil@xs4all.nl> | ||
57 | Mauro Carvalho Chehab <mchehab@infradead.org> | ||
58 | |||
59 | --------------------------- | ||
60 | |||
61 | What: V4L2 dpc7146 driver | ||
62 | When: 2.6.28 | ||
63 | Why: Old driver for the dpc7146 demonstration board that is no longer | ||
64 | relevant. The last time this was tested on actual hardware was | ||
65 | probably around 2002. Since this is a driver for a demonstration | ||
66 | board the decision was made to remove it rather than spending a | ||
67 | lot of effort continually updating this driver to stay in sync | ||
68 | with the latest internal V4L2 or I2C API. | ||
69 | Who: Hans Verkuil <hverkuil@xs4all.nl> | ||
70 | Mauro Carvalho Chehab <mchehab@infradead.org> | ||
71 | |||
72 | --------------------------- | ||
73 | |||
50 | What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) | 74 | What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) |
51 | When: November 2005 | 75 | When: November 2005 |
52 | Files: drivers/pcmcia/: pcmcia_ioctl.c | 76 | Files: drivers/pcmcia/: pcmcia_ioctl.c |
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt index 44c97e6accb2..fabcb0e00f25 100644 --- a/Documentation/filesystems/configfs/configfs.txt +++ b/Documentation/filesystems/configfs/configfs.txt | |||
@@ -311,9 +311,20 @@ the subsystem must be ready for it. | |||
311 | [An Example] | 311 | [An Example] |
312 | 312 | ||
313 | The best example of these basic concepts is the simple_children | 313 | The best example of these basic concepts is the simple_children |
314 | subsystem/group and the simple_child item in configfs_example.c It | 314 | subsystem/group and the simple_child item in configfs_example_explicit.c |
315 | shows a trivial object displaying and storing an attribute, and a simple | 315 | and configfs_example_macros.c. It shows a trivial object displaying and |
316 | group creating and destroying these children. | 316 | storing an attribute, and a simple group creating and destroying these |
317 | children. | ||
318 | |||
319 | The only difference between configfs_example_explicit.c and | ||
320 | configfs_example_macros.c is how the attributes of the childless item | ||
321 | are defined. The childless item has extended attributes, each with | ||
322 | their own show()/store() operation. This follows a convention commonly | ||
323 | used in sysfs. configfs_example_explicit.c creates these attributes | ||
324 | by explicitly defining the structures involved. Conversely | ||
325 | configfs_example_macros.c uses some convenience macros from configfs.h | ||
326 | to define the attributes. These macros are similar to their sysfs | ||
327 | counterparts. | ||
317 | 328 | ||
318 | [Hierarchy Navigation and the Subsystem Mutex] | 329 | [Hierarchy Navigation and the Subsystem Mutex] |
319 | 330 | ||
diff --git a/Documentation/filesystems/configfs/configfs_example.c b/Documentation/filesystems/configfs/configfs_example_explicit.c index 039648791701..d428cc9f07f3 100644 --- a/Documentation/filesystems/configfs/configfs_example.c +++ b/Documentation/filesystems/configfs/configfs_example_explicit.c | |||
@@ -1,8 +1,10 @@ | |||
1 | /* | 1 | /* |
2 | * vim: noexpandtab ts=8 sts=0 sw=8: | 2 | * vim: noexpandtab ts=8 sts=0 sw=8: |
3 | * | 3 | * |
4 | * configfs_example.c - This file is a demonstration module containing | 4 | * configfs_example_explicit.c - This file is a demonstration module |
5 | * a number of configfs subsystems. | 5 | * containing a number of configfs subsystems. It explicitly defines |
6 | * each structure without using the helper macros defined in | ||
7 | * configfs.h. | ||
6 | * | 8 | * |
7 | * This program is free software; you can redistribute it and/or | 9 | * This program is free software; you can redistribute it and/or |
8 | * modify it under the terms of the GNU General Public | 10 | * modify it under the terms of the GNU General Public |
@@ -281,7 +283,6 @@ static struct config_item *simple_children_make_item(struct config_group *group, | |||
281 | if (!simple_child) | 283 | if (!simple_child) |
282 | return ERR_PTR(-ENOMEM); | 284 | return ERR_PTR(-ENOMEM); |
283 | 285 | ||
284 | |||
285 | config_item_init_type_name(&simple_child->item, name, | 286 | config_item_init_type_name(&simple_child->item, name, |
286 | &simple_child_type); | 287 | &simple_child_type); |
287 | 288 | ||
@@ -302,8 +303,8 @@ static struct configfs_attribute *simple_children_attrs[] = { | |||
302 | }; | 303 | }; |
303 | 304 | ||
304 | static ssize_t simple_children_attr_show(struct config_item *item, | 305 | static ssize_t simple_children_attr_show(struct config_item *item, |
305 | struct configfs_attribute *attr, | 306 | struct configfs_attribute *attr, |
306 | char *page) | 307 | char *page) |
307 | { | 308 | { |
308 | return sprintf(page, | 309 | return sprintf(page, |
309 | "[02-simple-children]\n" | 310 | "[02-simple-children]\n" |
@@ -318,7 +319,7 @@ static void simple_children_release(struct config_item *item) | |||
318 | } | 319 | } |
319 | 320 | ||
320 | static struct configfs_item_operations simple_children_item_ops = { | 321 | static struct configfs_item_operations simple_children_item_ops = { |
321 | .release = simple_children_release, | 322 | .release = simple_children_release, |
322 | .show_attribute = simple_children_attr_show, | 323 | .show_attribute = simple_children_attr_show, |
323 | }; | 324 | }; |
324 | 325 | ||
@@ -368,7 +369,6 @@ static struct config_group *group_children_make_group(struct config_group *group | |||
368 | if (!simple_children) | 369 | if (!simple_children) |
369 | return ERR_PTR(-ENOMEM); | 370 | return ERR_PTR(-ENOMEM); |
370 | 371 | ||
371 | |||
372 | config_group_init_type_name(&simple_children->group, name, | 372 | config_group_init_type_name(&simple_children->group, name, |
373 | &simple_children_type); | 373 | &simple_children_type); |
374 | 374 | ||
@@ -387,8 +387,8 @@ static struct configfs_attribute *group_children_attrs[] = { | |||
387 | }; | 387 | }; |
388 | 388 | ||
389 | static ssize_t group_children_attr_show(struct config_item *item, | 389 | static ssize_t group_children_attr_show(struct config_item *item, |
390 | struct configfs_attribute *attr, | 390 | struct configfs_attribute *attr, |
391 | char *page) | 391 | char *page) |
392 | { | 392 | { |
393 | return sprintf(page, | 393 | return sprintf(page, |
394 | "[03-group-children]\n" | 394 | "[03-group-children]\n" |
diff --git a/Documentation/filesystems/configfs/configfs_example_macros.c b/Documentation/filesystems/configfs/configfs_example_macros.c new file mode 100644 index 000000000000..d8e30a0378aa --- /dev/null +++ b/Documentation/filesystems/configfs/configfs_example_macros.c | |||
@@ -0,0 +1,448 @@ | |||
1 | /* | ||
2 | * vim: noexpandtab ts=8 sts=0 sw=8: | ||
3 | * | ||
4 | * configfs_example_macros.c - This file is a demonstration module | ||
5 | * containing a number of configfs subsystems. It uses the helper | ||
6 | * macros defined by configfs.h | ||
7 | * | ||
8 | * This program is free software; you can redistribute it and/or | ||
9 | * modify it under the terms of the GNU General Public | ||
10 | * License as published by the Free Software Foundation; either | ||
11 | * version 2 of the License, or (at your option) any later version. | ||
12 | * | ||
13 | * This program is distributed in the hope that it will be useful, | ||
14 | * but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
15 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | ||
16 | * General Public License for more details. | ||
17 | * | ||
18 | * You should have received a copy of the GNU General Public | ||
19 | * License along with this program; if not, write to the | ||
20 | * Free Software Foundation, Inc., 59 Temple Place - Suite 330, | ||
21 | * Boston, MA 021110-1307, USA. | ||
22 | * | ||
23 | * Based on sysfs: | ||
24 | * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel | ||
25 | * | ||
26 | * configfs Copyright (C) 2005 Oracle. All rights reserved. | ||
27 | */ | ||
28 | |||
29 | #include <linux/init.h> | ||
30 | #include <linux/module.h> | ||
31 | #include <linux/slab.h> | ||
32 | |||
33 | #include <linux/configfs.h> | ||
34 | |||
35 | |||
36 | |||
37 | /* | ||
38 | * 01-childless | ||
39 | * | ||
40 | * This first example is a childless subsystem. It cannot create | ||
41 | * any config_items. It just has attributes. | ||
42 | * | ||
43 | * Note that we are enclosing the configfs_subsystem inside a container. | ||
44 | * This is not necessary if a subsystem has no attributes directly | ||
45 | * on the subsystem. See the next example, 02-simple-children, for | ||
46 | * such a subsystem. | ||
47 | */ | ||
48 | |||
49 | struct childless { | ||
50 | struct configfs_subsystem subsys; | ||
51 | int showme; | ||
52 | int storeme; | ||
53 | }; | ||
54 | |||
55 | static inline struct childless *to_childless(struct config_item *item) | ||
56 | { | ||
57 | return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL; | ||
58 | } | ||
59 | |||
60 | CONFIGFS_ATTR_STRUCT(childless); | ||
61 | #define CHILDLESS_ATTR(_name, _mode, _show, _store) \ | ||
62 | struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR(_name, _mode, _show, _store) | ||
63 | #define CHILDLESS_ATTR_RO(_name, _show) \ | ||
64 | struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR_RO(_name, _show); | ||
65 | |||
66 | static ssize_t childless_showme_read(struct childless *childless, | ||
67 | char *page) | ||
68 | { | ||
69 | ssize_t pos; | ||
70 | |||
71 | pos = sprintf(page, "%d\n", childless->showme); | ||
72 | childless->showme++; | ||
73 | |||
74 | return pos; | ||
75 | } | ||
76 | |||
77 | static ssize_t childless_storeme_read(struct childless *childless, | ||
78 | char *page) | ||
79 | { | ||
80 | return sprintf(page, "%d\n", childless->storeme); | ||
81 | } | ||
82 | |||
83 | static ssize_t childless_storeme_write(struct childless *childless, | ||
84 | const char *page, | ||
85 | size_t count) | ||
86 | { | ||
87 | unsigned long tmp; | ||
88 | char *p = (char *) page; | ||
89 | |||
90 | tmp = simple_strtoul(p, &p, 10); | ||
91 | if (!p || (*p && (*p != '\n'))) | ||
92 | return -EINVAL; | ||
93 | |||
94 | if (tmp > INT_MAX) | ||
95 | return -ERANGE; | ||
96 | |||
97 | childless->storeme = tmp; | ||
98 | |||
99 | return count; | ||
100 | } | ||
101 | |||
102 | static ssize_t childless_description_read(struct childless *childless, | ||
103 | char *page) | ||
104 | { | ||
105 | return sprintf(page, | ||
106 | "[01-childless]\n" | ||
107 | "\n" | ||
108 | "The childless subsystem is the simplest possible subsystem in\n" | ||
109 | "configfs. It does not support the creation of child config_items.\n" | ||
110 | "It only has a few attributes. In fact, it isn't much different\n" | ||
111 | "than a directory in /proc.\n"); | ||
112 | } | ||
113 | |||
114 | CHILDLESS_ATTR_RO(showme, childless_showme_read); | ||
115 | CHILDLESS_ATTR(storeme, S_IRUGO | S_IWUSR, childless_storeme_read, | ||
116 | childless_storeme_write); | ||
117 | CHILDLESS_ATTR_RO(description, childless_description_read); | ||
118 | |||
119 | static struct configfs_attribute *childless_attrs[] = { | ||
120 | &childless_attr_showme.attr, | ||
121 | &childless_attr_storeme.attr, | ||
122 | &childless_attr_description.attr, | ||
123 | NULL, | ||
124 | }; | ||
125 | |||
126 | CONFIGFS_ATTR_OPS(childless); | ||
127 | static struct configfs_item_operations childless_item_ops = { | ||
128 | .show_attribute = childless_attr_show, | ||
129 | .store_attribute = childless_attr_store, | ||
130 | }; | ||
131 | |||
132 | static struct config_item_type childless_type = { | ||
133 | .ct_item_ops = &childless_item_ops, | ||
134 | .ct_attrs = childless_attrs, | ||
135 | .ct_owner = THIS_MODULE, | ||
136 | }; | ||
137 | |||
138 | static struct childless childless_subsys = { | ||
139 | .subsys = { | ||
140 | .su_group = { | ||
141 | .cg_item = { | ||
142 | .ci_namebuf = "01-childless", | ||
143 | .ci_type = &childless_type, | ||
144 | }, | ||
145 | }, | ||
146 | }, | ||
147 | }; | ||
148 | |||
149 | |||
150 | /* ----------------------------------------------------------------- */ | ||
151 | |||
152 | /* | ||
153 | * 02-simple-children | ||
154 | * | ||
155 | * This example merely has a simple one-attribute child. Note that | ||
156 | * there is no extra attribute structure, as the child's attribute is | ||
157 | * known from the get-go. Also, there is no container for the | ||
158 | * subsystem, as it has no attributes of its own. | ||
159 | */ | ||
160 | |||
161 | struct simple_child { | ||
162 | struct config_item item; | ||
163 | int storeme; | ||
164 | }; | ||
165 | |||
166 | static inline struct simple_child *to_simple_child(struct config_item *item) | ||
167 | { | ||
168 | return item ? container_of(item, struct simple_child, item) : NULL; | ||
169 | } | ||
170 | |||
171 | static struct configfs_attribute simple_child_attr_storeme = { | ||
172 | .ca_owner = THIS_MODULE, | ||
173 | .ca_name = "storeme", | ||
174 | .ca_mode = S_IRUGO | S_IWUSR, | ||
175 | }; | ||
176 | |||
177 | static struct configfs_attribute *simple_child_attrs[] = { | ||
178 | &simple_child_attr_storeme, | ||
179 | NULL, | ||
180 | }; | ||
181 | |||
182 | static ssize_t simple_child_attr_show(struct config_item *item, | ||
183 | struct configfs_attribute *attr, | ||
184 | char *page) | ||
185 | { | ||
186 | ssize_t count; | ||
187 | struct simple_child *simple_child = to_simple_child(item); | ||
188 | |||
189 | count = sprintf(page, "%d\n", simple_child->storeme); | ||
190 | |||
191 | return count; | ||
192 | } | ||
193 | |||
194 | static ssize_t simple_child_attr_store(struct config_item *item, | ||
195 | struct configfs_attribute *attr, | ||
196 | const char *page, size_t count) | ||
197 | { | ||
198 | struct simple_child *simple_child = to_simple_child(item); | ||
199 | unsigned long tmp; | ||
200 | char *p = (char *) page; | ||
201 | |||
202 | tmp = simple_strtoul(p, &p, 10); | ||
203 | if (!p || (*p && (*p != '\n'))) | ||
204 | return -EINVAL; | ||
205 | |||
206 | if (tmp > INT_MAX) | ||
207 | return -ERANGE; | ||
208 | |||
209 | simple_child->storeme = tmp; | ||
210 | |||
211 | return count; | ||
212 | } | ||
213 | |||
214 | static void simple_child_release(struct config_item *item) | ||
215 | { | ||
216 | kfree(to_simple_child(item)); | ||
217 | } | ||
218 | |||
219 | static struct configfs_item_operations simple_child_item_ops = { | ||
220 | .release = simple_child_release, | ||
221 | .show_attribute = simple_child_attr_show, | ||
222 | .store_attribute = simple_child_attr_store, | ||
223 | }; | ||
224 | |||
225 | static struct config_item_type simple_child_type = { | ||
226 | .ct_item_ops = &simple_child_item_ops, | ||
227 | .ct_attrs = simple_child_attrs, | ||
228 | .ct_owner = THIS_MODULE, | ||
229 | }; | ||
230 | |||
231 | |||
232 | struct simple_children { | ||
233 | struct config_group group; | ||
234 | }; | ||
235 | |||
236 | static inline struct simple_children *to_simple_children(struct config_item *item) | ||
237 | { | ||
238 | return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; | ||
239 | } | ||
240 | |||
241 | static struct config_item *simple_children_make_item(struct config_group *group, const char *name) | ||
242 | { | ||
243 | struct simple_child *simple_child; | ||
244 | |||
245 | simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); | ||
246 | if (!simple_child) | ||
247 | return ERR_PTR(-ENOMEM); | ||
248 | |||
249 | config_item_init_type_name(&simple_child->item, name, | ||
250 | &simple_child_type); | ||
251 | |||
252 | simple_child->storeme = 0; | ||
253 | |||
254 | return &simple_child->item; | ||
255 | } | ||
256 | |||
257 | static struct configfs_attribute simple_children_attr_description = { | ||
258 | .ca_owner = THIS_MODULE, | ||
259 | .ca_name = "description", | ||
260 | .ca_mode = S_IRUGO, | ||
261 | }; | ||
262 | |||
263 | static struct configfs_attribute *simple_children_attrs[] = { | ||
264 | &simple_children_attr_description, | ||
265 | NULL, | ||
266 | }; | ||
267 | |||
268 | static ssize_t simple_children_attr_show(struct config_item *item, | ||
269 | struct configfs_attribute *attr, | ||
270 | char *page) | ||
271 | { | ||
272 | return sprintf(page, | ||
273 | "[02-simple-children]\n" | ||
274 | "\n" | ||
275 | "This subsystem allows the creation of child config_items. These\n" | ||
276 | "items have only one attribute that is readable and writeable.\n"); | ||
277 | } | ||
278 | |||
279 | static void simple_children_release(struct config_item *item) | ||
280 | { | ||
281 | kfree(to_simple_children(item)); | ||
282 | } | ||
283 | |||
284 | static struct configfs_item_operations simple_children_item_ops = { | ||
285 | .release = simple_children_release, | ||
286 | .show_attribute = simple_children_attr_show, | ||
287 | }; | ||
288 | |||
289 | /* | ||
290 | * Note that, since no extra work is required on ->drop_item(), | ||
291 | * no ->drop_item() is provided. | ||
292 | */ | ||
293 | static struct configfs_group_operations simple_children_group_ops = { | ||
294 | .make_item = simple_children_make_item, | ||
295 | }; | ||
296 | |||
297 | static struct config_item_type simple_children_type = { | ||
298 | .ct_item_ops = &simple_children_item_ops, | ||
299 | .ct_group_ops = &simple_children_group_ops, | ||
300 | .ct_attrs = simple_children_attrs, | ||
301 | .ct_owner = THIS_MODULE, | ||
302 | }; | ||
303 | |||
304 | static struct configfs_subsystem simple_children_subsys = { | ||
305 | .su_group = { | ||
306 | .cg_item = { | ||
307 | .ci_namebuf = "02-simple-children", | ||
308 | .ci_type = &simple_children_type, | ||
309 | }, | ||
310 | }, | ||
311 | }; | ||
312 | |||
313 | |||
314 | /* ----------------------------------------------------------------- */ | ||
315 | |||
316 | /* | ||
317 | * 03-group-children | ||
318 | * | ||
319 | * This example reuses the simple_children group from above. However, | ||
320 | * the simple_children group is not the subsystem itself, it is a | ||
321 | * child of the subsystem. Creation of a group in the subsystem creates | ||
322 | * a new simple_children group. That group can then have simple_child | ||
323 | * children of its own. | ||
324 | */ | ||
325 | |||
326 | static struct config_group *group_children_make_group(struct config_group *group, const char *name) | ||
327 | { | ||
328 | struct simple_children *simple_children; | ||
329 | |||
330 | simple_children = kzalloc(sizeof(struct simple_children), | ||
331 | GFP_KERNEL); | ||
332 | if (!simple_children) | ||
333 | return ERR_PTR(-ENOMEM); | ||
334 | |||
335 | config_group_init_type_name(&simple_children->group, name, | ||
336 | &simple_children_type); | ||
337 | |||
338 | return &simple_children->group; | ||
339 | } | ||
340 | |||
341 | static struct configfs_attribute group_children_attr_description = { | ||
342 | .ca_owner = THIS_MODULE, | ||
343 | .ca_name = "description", | ||
344 | .ca_mode = S_IRUGO, | ||
345 | }; | ||
346 | |||
347 | static struct configfs_attribute *group_children_attrs[] = { | ||
348 | &group_children_attr_description, | ||
349 | NULL, | ||
350 | }; | ||
351 | |||
352 | static ssize_t group_children_attr_show(struct config_item *item, | ||
353 | struct configfs_attribute *attr, | ||
354 | char *page) | ||
355 | { | ||
356 | return sprintf(page, | ||
357 | "[03-group-children]\n" | ||
358 | "\n" | ||
359 | "This subsystem allows the creation of child config_groups. These\n" | ||
360 | "groups are like the subsystem simple-children.\n"); | ||
361 | } | ||
362 | |||
363 | static struct configfs_item_operations group_children_item_ops = { | ||
364 | .show_attribute = group_children_attr_show, | ||
365 | }; | ||
366 | |||
367 | /* | ||
368 | * Note that, since no extra work is required on ->drop_item(), | ||
369 | * no ->drop_item() is provided. | ||
370 | */ | ||
371 | static struct configfs_group_operations group_children_group_ops = { | ||
372 | .make_group = group_children_make_group, | ||
373 | }; | ||
374 | |||
375 | static struct config_item_type group_children_type = { | ||
376 | .ct_item_ops = &group_children_item_ops, | ||
377 | .ct_group_ops = &group_children_group_ops, | ||
378 | .ct_attrs = group_children_attrs, | ||
379 | .ct_owner = THIS_MODULE, | ||
380 | }; | ||
381 | |||
382 | static struct configfs_subsystem group_children_subsys = { | ||
383 | .su_group = { | ||
384 | .cg_item = { | ||
385 | .ci_namebuf = "03-group-children", | ||
386 | .ci_type = &group_children_type, | ||
387 | }, | ||
388 | }, | ||
389 | }; | ||
390 | |||
391 | /* ----------------------------------------------------------------- */ | ||
392 | |||
393 | /* | ||
394 | * We're now done with our subsystem definitions. | ||
395 | * For convenience in this module, here's a list of them all. It | ||
396 | * allows the init function to easily register them. Most modules | ||
397 | * will only have one subsystem, and will only call register_subsystem | ||
398 | * on it directly. | ||
399 | */ | ||
400 | static struct configfs_subsystem *example_subsys[] = { | ||
401 | &childless_subsys.subsys, | ||
402 | &simple_children_subsys, | ||
403 | &group_children_subsys, | ||
404 | NULL, | ||
405 | }; | ||
406 | |||
407 | static int __init configfs_example_init(void) | ||
408 | { | ||
409 | int ret; | ||
410 | int i; | ||
411 | struct configfs_subsystem *subsys; | ||
412 | |||
413 | for (i = 0; example_subsys[i]; i++) { | ||
414 | subsys = example_subsys[i]; | ||
415 | |||
416 | config_group_init(&subsys->su_group); | ||
417 | mutex_init(&subsys->su_mutex); | ||
418 | ret = configfs_register_subsystem(subsys); | ||
419 | if (ret) { | ||
420 | printk(KERN_ERR "Error %d while registering subsystem %s\n", | ||
421 | ret, | ||
422 | subsys->su_group.cg_item.ci_namebuf); | ||
423 | goto out_unregister; | ||
424 | } | ||
425 | } | ||
426 | |||
427 | return 0; | ||
428 | |||
429 | out_unregister: | ||
430 | for (; i >= 0; i--) { | ||
431 | configfs_unregister_subsystem(example_subsys[i]); | ||
432 | } | ||
433 | |||
434 | return ret; | ||
435 | } | ||
436 | |||
437 | static void __exit configfs_example_exit(void) | ||
438 | { | ||
439 | int i; | ||
440 | |||
441 | for (i = 0; example_subsys[i]; i++) { | ||
442 | configfs_unregister_subsystem(example_subsys[i]); | ||
443 | } | ||
444 | } | ||
445 | |||
446 | module_init(configfs_example_init); | ||
447 | module_exit(configfs_example_exit); | ||
448 | MODULE_LICENSE("GPL"); | ||
diff --git a/Documentation/ftrace.txt b/Documentation/ftrace.txt index f218f616ff6b..d330fe3103da 100644 --- a/Documentation/ftrace.txt +++ b/Documentation/ftrace.txt | |||
@@ -4,6 +4,7 @@ | |||
4 | Copyright 2008 Red Hat Inc. | 4 | Copyright 2008 Red Hat Inc. |
5 | Author: Steven Rostedt <srostedt@redhat.com> | 5 | Author: Steven Rostedt <srostedt@redhat.com> |
6 | License: The GNU Free Documentation License, Version 1.2 | 6 | License: The GNU Free Documentation License, Version 1.2 |
7 | (dual licensed under the GPL v2) | ||
7 | Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton, | 8 | Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton, |
8 | John Kacur, and David Teigland. | 9 | John Kacur, and David Teigland. |
9 | 10 | ||
diff --git a/Documentation/hwmon/dme1737 b/Documentation/hwmon/dme1737 index 8f446070e64a..b1fe00999439 100644 --- a/Documentation/hwmon/dme1737 +++ b/Documentation/hwmon/dme1737 | |||
@@ -22,6 +22,10 @@ Module Parameters | |||
22 | and PWM output control functions. Using this parameter | 22 | and PWM output control functions. Using this parameter |
23 | shouldn't be required since the BIOS usually takes care | 23 | shouldn't be required since the BIOS usually takes care |
24 | of this. | 24 | of this. |
25 | * probe_all_addr: bool Include non-standard LPC addresses 0x162e and 0x164e | ||
26 | when probing for ISA devices. This is required for the | ||
27 | following boards: | ||
28 | - VIA EPIA SN18000 | ||
25 | 29 | ||
26 | Note that there is no need to use this parameter if the driver loads without | 30 | Note that there is no need to use this parameter if the driver loads without |
27 | complaining. The driver will say so if it is necessary. | 31 | complaining. The driver will say so if it is necessary. |
diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85 index 9549237530cf..6d41db7f17f8 100644 --- a/Documentation/hwmon/lm85 +++ b/Documentation/hwmon/lm85 | |||
@@ -96,11 +96,6 @@ initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has | |||
96 | confirmed this "bug". The ADT7463 is reported to work as described in the | 96 | confirmed this "bug". The ADT7463 is reported to work as described in the |
97 | documentation. The current lm85 driver does not show the offset register. | 97 | documentation. The current lm85 driver does not show the offset register. |
98 | 98 | ||
99 | The ADT7463 has a THERM asserted counter. This counter has a 22.76ms | ||
100 | resolution and a range of 5.8 seconds. The driver implements a 32-bit | ||
101 | accumulator of the counter value to extend the range to over a year. The | ||
102 | counter will stay at it's max value until read. | ||
103 | |||
104 | See the vendor datasheets for more information. There is application note | 99 | See the vendor datasheets for more information. There is application note |
105 | from National (AN-1260) with some additional information about the LM85. | 100 | from National (AN-1260) with some additional information about the LM85. |
106 | The Analog Devices datasheet is very detailed and describes a procedure for | 101 | The Analog Devices datasheet is very detailed and describes a procedure for |
@@ -206,13 +201,15 @@ Configuration choices: | |||
206 | 201 | ||
207 | The National LM85's have two vendor specific configuration | 202 | The National LM85's have two vendor specific configuration |
208 | features. Tach. mode and Spinup Control. For more details on these, | 203 | features. Tach. mode and Spinup Control. For more details on these, |
209 | see the LM85 datasheet or Application Note AN-1260. | 204 | see the LM85 datasheet or Application Note AN-1260. These features |
205 | are not currently supported by the lm85 driver. | ||
210 | 206 | ||
211 | The Analog Devices ADM1027 has several vendor specific enhancements. | 207 | The Analog Devices ADM1027 has several vendor specific enhancements. |
212 | The number of pulses-per-rev of the fans can be set, Tach monitoring | 208 | The number of pulses-per-rev of the fans can be set, Tach monitoring |
213 | can be optimized for PWM operation, and an offset can be applied to | 209 | can be optimized for PWM operation, and an offset can be applied to |
214 | the temperatures to compensate for systemic errors in the | 210 | the temperatures to compensate for systemic errors in the |
215 | measurements. | 211 | measurements. These features are not currently supported by the lm85 |
212 | driver. | ||
216 | 213 | ||
217 | In addition to the ADM1027 features, the ADT7463 also has Tmin control | 214 | In addition to the ADM1027 features, the ADT7463 also has Tmin control |
218 | and THERM asserted counts. Automatic Tmin control acts to adjust the | 215 | and THERM asserted counts. Automatic Tmin control acts to adjust the |
diff --git a/Documentation/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients new file mode 100644 index 000000000000..9a45f9bb6a25 --- /dev/null +++ b/Documentation/i2c/upgrading-clients | |||
@@ -0,0 +1,281 @@ | |||
1 | Upgrading I2C Drivers to the new 2.6 Driver Model | ||
2 | ================================================= | ||
3 | |||
4 | Ben Dooks <ben-linux@fluff.org> | ||
5 | |||
6 | Introduction | ||
7 | ------------ | ||
8 | |||
9 | This guide outlines how to alter existing Linux 2.6 client drivers from | ||
10 | the old to the new new binding methods. | ||
11 | |||
12 | |||
13 | Example old-style driver | ||
14 | ------------------------ | ||
15 | |||
16 | |||
17 | struct example_state { | ||
18 | struct i2c_client client; | ||
19 | .... | ||
20 | }; | ||
21 | |||
22 | static struct i2c_driver example_driver; | ||
23 | |||
24 | static unsigned short ignore[] = { I2C_CLIENT_END }; | ||
25 | static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END }; | ||
26 | |||
27 | I2C_CLIENT_INSMOD; | ||
28 | |||
29 | static int example_attach(struct i2c_adapter *adap, int addr, int kind) | ||
30 | { | ||
31 | struct example_state *state; | ||
32 | struct device *dev = &adap->dev; /* to use for dev_ reports */ | ||
33 | int ret; | ||
34 | |||
35 | state = kzalloc(sizeof(struct example_state), GFP_KERNEL); | ||
36 | if (state == NULL) { | ||
37 | dev_err(dev, "failed to create our state\n"); | ||
38 | return -ENOMEM; | ||
39 | } | ||
40 | |||
41 | example->client.addr = addr; | ||
42 | example->client.flags = 0; | ||
43 | example->client.adapter = adap; | ||
44 | |||
45 | i2c_set_clientdata(&state->i2c_client, state); | ||
46 | strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE); | ||
47 | |||
48 | ret = i2c_attach_client(&state->i2c_client); | ||
49 | if (ret < 0) { | ||
50 | dev_err(dev, "failed to attach client\n"); | ||
51 | kfree(state); | ||
52 | return ret; | ||
53 | } | ||
54 | |||
55 | dev = &state->i2c_client.dev; | ||
56 | |||
57 | /* rest of the initialisation goes here. */ | ||
58 | |||
59 | dev_info(dev, "example client created\n"); | ||
60 | |||
61 | return 0; | ||
62 | } | ||
63 | |||
64 | static int __devexit example_detach(struct i2c_client *client) | ||
65 | { | ||
66 | struct example_state *state = i2c_get_clientdata(client); | ||
67 | |||
68 | i2c_detach_client(client); | ||
69 | kfree(state); | ||
70 | return 0; | ||
71 | } | ||
72 | |||
73 | static int example_attach_adapter(struct i2c_adapter *adap) | ||
74 | { | ||
75 | return i2c_probe(adap, &addr_data, example_attach); | ||
76 | } | ||
77 | |||
78 | static struct i2c_driver example_driver = { | ||
79 | .driver = { | ||
80 | .owner = THIS_MODULE, | ||
81 | .name = "example", | ||
82 | }, | ||
83 | .attach_adapter = example_attach_adapter, | ||
84 | .detach_client = __devexit_p(example_detach), | ||
85 | .suspend = example_suspend, | ||
86 | .resume = example_resume, | ||
87 | }; | ||
88 | |||
89 | |||
90 | Updating the client | ||
91 | ------------------- | ||
92 | |||
93 | The new style binding model will check against a list of supported | ||
94 | devices and their associated address supplied by the code registering | ||
95 | the busses. This means that the driver .attach_adapter and | ||
96 | .detach_adapter methods can be removed, along with the addr_data, | ||
97 | as follows: | ||
98 | |||
99 | - static struct i2c_driver example_driver; | ||
100 | |||
101 | - static unsigned short ignore[] = { I2C_CLIENT_END }; | ||
102 | - static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END }; | ||
103 | |||
104 | - I2C_CLIENT_INSMOD; | ||
105 | |||
106 | - static int example_attach_adapter(struct i2c_adapter *adap) | ||
107 | - { | ||
108 | - return i2c_probe(adap, &addr_data, example_attach); | ||
109 | - } | ||
110 | |||
111 | static struct i2c_driver example_driver = { | ||
112 | - .attach_adapter = example_attach_adapter, | ||
113 | - .detach_client = __devexit_p(example_detach), | ||
114 | } | ||
115 | |||
116 | Add the probe and remove methods to the i2c_driver, as so: | ||
117 | |||
118 | static struct i2c_driver example_driver = { | ||
119 | + .probe = example_probe, | ||
120 | + .remove = __devexit_p(example_remove), | ||
121 | } | ||
122 | |||
123 | Change the example_attach method to accept the new parameters | ||
124 | which include the i2c_client that it will be working with: | ||
125 | |||
126 | - static int example_attach(struct i2c_adapter *adap, int addr, int kind) | ||
127 | + static int example_probe(struct i2c_client *client, | ||
128 | + const struct i2c_device_id *id) | ||
129 | |||
130 | Change the name of example_attach to example_probe to align it with the | ||
131 | i2c_driver entry names. The rest of the probe routine will now need to be | ||
132 | changed as the i2c_client has already been setup for use. | ||
133 | |||
134 | The necessary client fields have already been setup before | ||
135 | the probe function is called, so the following client setup | ||
136 | can be removed: | ||
137 | |||
138 | - example->client.addr = addr; | ||
139 | - example->client.flags = 0; | ||
140 | - example->client.adapter = adap; | ||
141 | - | ||
142 | - strlcpy(client->i2c_client.name, "example", I2C_NAME_SIZE); | ||
143 | |||
144 | The i2c_set_clientdata is now: | ||
145 | |||
146 | - i2c_set_clientdata(&state->client, state); | ||
147 | + i2c_set_clientdata(client, state); | ||
148 | |||
149 | The call to i2c_attach_client is no longer needed, if the probe | ||
150 | routine exits successfully, then the driver will be automatically | ||
151 | attached by the core. Change the probe routine as so: | ||
152 | |||
153 | - ret = i2c_attach_client(&state->i2c_client); | ||
154 | - if (ret < 0) { | ||
155 | - dev_err(dev, "failed to attach client\n"); | ||
156 | - kfree(state); | ||
157 | - return ret; | ||
158 | - } | ||
159 | |||
160 | |||
161 | Remove the storage of 'struct i2c_client' from the 'struct example_state' | ||
162 | as we are provided with the i2c_client in our example_probe. Instead we | ||
163 | store a pointer to it for when it is needed. | ||
164 | |||
165 | struct example_state { | ||
166 | - struct i2c_client client; | ||
167 | + struct i2c_client *client; | ||
168 | |||
169 | the new i2c client as so: | ||
170 | |||
171 | - struct device *dev = &adap->dev; /* to use for dev_ reports */ | ||
172 | + struct device *dev = &i2c_client->dev; /* to use for dev_ reports */ | ||
173 | |||
174 | And remove the change after our client is attached, as the driver no | ||
175 | longer needs to register a new client structure with the core: | ||
176 | |||
177 | - dev = &state->i2c_client.dev; | ||
178 | |||
179 | In the probe routine, ensure that the new state has the client stored | ||
180 | in it: | ||
181 | |||
182 | static int example_probe(struct i2c_client *i2c_client, | ||
183 | const struct i2c_device_id *id) | ||
184 | { | ||
185 | struct example_state *state; | ||
186 | struct device *dev = &i2c_client->dev; | ||
187 | int ret; | ||
188 | |||
189 | state = kzalloc(sizeof(struct example_state), GFP_KERNEL); | ||
190 | if (state == NULL) { | ||
191 | dev_err(dev, "failed to create our state\n"); | ||
192 | return -ENOMEM; | ||
193 | } | ||
194 | |||
195 | + state->client = i2c_client; | ||
196 | |||
197 | Update the detach method, by changing the name to _remove and | ||
198 | to delete the i2c_detach_client call. It is possible that you | ||
199 | can also remove the ret variable as it is not not needed for | ||
200 | any of the core functions. | ||
201 | |||
202 | - static int __devexit example_detach(struct i2c_client *client) | ||
203 | + static int __devexit example_remove(struct i2c_client *client) | ||
204 | { | ||
205 | struct example_state *state = i2c_get_clientdata(client); | ||
206 | |||
207 | - i2c_detach_client(client); | ||
208 | |||
209 | And finally ensure that we have the correct ID table for the i2c-core | ||
210 | and other utilities: | ||
211 | |||
212 | + struct i2c_device_id example_idtable[] = { | ||
213 | + { "example", 0 }, | ||
214 | + { } | ||
215 | +}; | ||
216 | + | ||
217 | +MODULE_DEVICE_TABLE(i2c, example_idtable); | ||
218 | |||
219 | static struct i2c_driver example_driver = { | ||
220 | .driver = { | ||
221 | .owner = THIS_MODULE, | ||
222 | .name = "example", | ||
223 | }, | ||
224 | + .id_table = example_ids, | ||
225 | |||
226 | |||
227 | Our driver should now look like this: | ||
228 | |||
229 | struct example_state { | ||
230 | struct i2c_client *client; | ||
231 | .... | ||
232 | }; | ||
233 | |||
234 | static int example_probe(struct i2c_client *client, | ||
235 | const struct i2c_device_id *id) | ||
236 | { | ||
237 | struct example_state *state; | ||
238 | struct device *dev = &client->dev; | ||
239 | |||
240 | state = kzalloc(sizeof(struct example_state), GFP_KERNEL); | ||
241 | if (state == NULL) { | ||
242 | dev_err(dev, "failed to create our state\n"); | ||
243 | return -ENOMEM; | ||
244 | } | ||
245 | |||
246 | state->client = client; | ||
247 | i2c_set_clientdata(client, state); | ||
248 | |||
249 | /* rest of the initialisation goes here. */ | ||
250 | |||
251 | dev_info(dev, "example client created\n"); | ||
252 | |||
253 | return 0; | ||
254 | } | ||
255 | |||
256 | static int __devexit example_remove(struct i2c_client *client) | ||
257 | { | ||
258 | struct example_state *state = i2c_get_clientdata(client); | ||
259 | |||
260 | kfree(state); | ||
261 | return 0; | ||
262 | } | ||
263 | |||
264 | static struct i2c_device_id example_idtable[] = { | ||
265 | { "example", 0 }, | ||
266 | { } | ||
267 | }; | ||
268 | |||
269 | MODULE_DEVICE_TABLE(i2c, example_idtable); | ||
270 | |||
271 | static struct i2c_driver example_driver = { | ||
272 | .driver = { | ||
273 | .owner = THIS_MODULE, | ||
274 | .name = "example", | ||
275 | }, | ||
276 | .id_table = example_idtable, | ||
277 | .probe = example_probe, | ||
278 | .remove = __devexit_p(example_remove), | ||
279 | .suspend = example_suspend, | ||
280 | .resume = example_resume, | ||
281 | }; | ||
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 9691c7f5166c..0705040531a5 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt | |||
@@ -65,26 +65,26 @@ Install kexec-tools | |||
65 | 65 | ||
66 | 2) Download the kexec-tools user-space package from the following URL: | 66 | 2) Download the kexec-tools user-space package from the following URL: |
67 | 67 | ||
68 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing.tar.gz | 68 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.gz |
69 | 69 | ||
70 | This is a symlink to the latest version, which at the time of writing is | 70 | This is a symlink to the latest version. |
71 | 20061214, the only release of kexec-tools-testing so far. As other versions | ||
72 | are released, the older ones will remain available at | ||
73 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/ | ||
74 | 71 | ||
75 | Note: Latest kexec-tools-testing git tree is available at | 72 | The latest kexec-tools git tree is available at: |
76 | 73 | ||
77 | git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git | 74 | git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git |
78 | or | 75 | or |
79 | http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary | 76 | http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools.git |
77 | |||
78 | More information about kexec-tools can be found at | ||
79 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/README.html | ||
80 | 80 | ||
81 | 3) Unpack the tarball with the tar command, as follows: | 81 | 3) Unpack the tarball with the tar command, as follows: |
82 | 82 | ||
83 | tar xvpzf kexec-tools-testing.tar.gz | 83 | tar xvpzf kexec-tools.tar.gz |
84 | 84 | ||
85 | 4) Change to the kexec-tools directory, as follows: | 85 | 4) Change to the kexec-tools directory, as follows: |
86 | 86 | ||
87 | cd kexec-tools-testing-VERSION | 87 | cd kexec-tools-VERSION |
88 | 88 | ||
89 | 5) Configure the package, as follows: | 89 | 5) Configure the package, as follows: |
90 | 90 | ||
diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index 82fafe0429fe..b88b0ea54e90 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c | |||
@@ -36,11 +36,13 @@ | |||
36 | #include <sched.h> | 36 | #include <sched.h> |
37 | #include <limits.h> | 37 | #include <limits.h> |
38 | #include <stddef.h> | 38 | #include <stddef.h> |
39 | #include <signal.h> | ||
39 | #include "linux/lguest_launcher.h" | 40 | #include "linux/lguest_launcher.h" |
40 | #include "linux/virtio_config.h" | 41 | #include "linux/virtio_config.h" |
41 | #include "linux/virtio_net.h" | 42 | #include "linux/virtio_net.h" |
42 | #include "linux/virtio_blk.h" | 43 | #include "linux/virtio_blk.h" |
43 | #include "linux/virtio_console.h" | 44 | #include "linux/virtio_console.h" |
45 | #include "linux/virtio_rng.h" | ||
44 | #include "linux/virtio_ring.h" | 46 | #include "linux/virtio_ring.h" |
45 | #include "asm-x86/bootparam.h" | 47 | #include "asm-x86/bootparam.h" |
46 | /*L:110 We can ignore the 39 include files we need for this program, but I do | 48 | /*L:110 We can ignore the 39 include files we need for this program, but I do |
@@ -64,8 +66,8 @@ typedef uint8_t u8; | |||
64 | #endif | 66 | #endif |
65 | /* We can have up to 256 pages for devices. */ | 67 | /* We can have up to 256 pages for devices. */ |
66 | #define DEVICE_PAGES 256 | 68 | #define DEVICE_PAGES 256 |
67 | /* This will occupy 2 pages: it must be a power of 2. */ | 69 | /* This will occupy 3 pages: it must be a power of 2. */ |
68 | #define VIRTQUEUE_NUM 128 | 70 | #define VIRTQUEUE_NUM 256 |
69 | 71 | ||
70 | /*L:120 verbose is both a global flag and a macro. The C preprocessor allows | 72 | /*L:120 verbose is both a global flag and a macro. The C preprocessor allows |
71 | * this, and although I wouldn't recommend it, it works quite nicely here. */ | 73 | * this, and although I wouldn't recommend it, it works quite nicely here. */ |
@@ -74,12 +76,19 @@ static bool verbose; | |||
74 | do { if (verbose) printf(args); } while(0) | 76 | do { if (verbose) printf(args); } while(0) |
75 | /*:*/ | 77 | /*:*/ |
76 | 78 | ||
77 | /* The pipe to send commands to the waker process */ | 79 | /* File descriptors for the Waker. */ |
78 | static int waker_fd; | 80 | struct { |
81 | int pipe[2]; | ||
82 | int lguest_fd; | ||
83 | } waker_fds; | ||
84 | |||
79 | /* The pointer to the start of guest memory. */ | 85 | /* The pointer to the start of guest memory. */ |
80 | static void *guest_base; | 86 | static void *guest_base; |
81 | /* The maximum guest physical address allowed, and maximum possible. */ | 87 | /* The maximum guest physical address allowed, and maximum possible. */ |
82 | static unsigned long guest_limit, guest_max; | 88 | static unsigned long guest_limit, guest_max; |
89 | /* The pipe for signal hander to write to. */ | ||
90 | static int timeoutpipe[2]; | ||
91 | static unsigned int timeout_usec = 500; | ||
83 | 92 | ||
84 | /* a per-cpu variable indicating whose vcpu is currently running */ | 93 | /* a per-cpu variable indicating whose vcpu is currently running */ |
85 | static unsigned int __thread cpu_id; | 94 | static unsigned int __thread cpu_id; |
@@ -155,11 +164,14 @@ struct virtqueue | |||
155 | /* Last available index we saw. */ | 164 | /* Last available index we saw. */ |
156 | u16 last_avail_idx; | 165 | u16 last_avail_idx; |
157 | 166 | ||
158 | /* The routine to call when the Guest pings us. */ | 167 | /* The routine to call when the Guest pings us, or timeout. */ |
159 | void (*handle_output)(int fd, struct virtqueue *me); | 168 | void (*handle_output)(int fd, struct virtqueue *me, bool timeout); |
160 | 169 | ||
161 | /* Outstanding buffers */ | 170 | /* Outstanding buffers */ |
162 | unsigned int inflight; | 171 | unsigned int inflight; |
172 | |||
173 | /* Is this blocked awaiting a timer? */ | ||
174 | bool blocked; | ||
163 | }; | 175 | }; |
164 | 176 | ||
165 | /* Remember the arguments to the program so we can "reboot" */ | 177 | /* Remember the arguments to the program so we can "reboot" */ |
@@ -190,6 +202,9 @@ static void *_convert(struct iovec *iov, size_t size, size_t align, | |||
190 | return iov->iov_base; | 202 | return iov->iov_base; |
191 | } | 203 | } |
192 | 204 | ||
205 | /* Wrapper for the last available index. Makes it easier to change. */ | ||
206 | #define lg_last_avail(vq) ((vq)->last_avail_idx) | ||
207 | |||
193 | /* The virtio configuration space is defined to be little-endian. x86 is | 208 | /* The virtio configuration space is defined to be little-endian. x86 is |
194 | * little-endian too, but it's nice to be explicit so we have these helpers. */ | 209 | * little-endian too, but it's nice to be explicit so we have these helpers. */ |
195 | #define cpu_to_le16(v16) (v16) | 210 | #define cpu_to_le16(v16) (v16) |
@@ -199,6 +214,33 @@ static void *_convert(struct iovec *iov, size_t size, size_t align, | |||
199 | #define le32_to_cpu(v32) (v32) | 214 | #define le32_to_cpu(v32) (v32) |
200 | #define le64_to_cpu(v64) (v64) | 215 | #define le64_to_cpu(v64) (v64) |
201 | 216 | ||
217 | /* Is this iovec empty? */ | ||
218 | static bool iov_empty(const struct iovec iov[], unsigned int num_iov) | ||
219 | { | ||
220 | unsigned int i; | ||
221 | |||
222 | for (i = 0; i < num_iov; i++) | ||
223 | if (iov[i].iov_len) | ||
224 | return false; | ||
225 | return true; | ||
226 | } | ||
227 | |||
228 | /* Take len bytes from the front of this iovec. */ | ||
229 | static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len) | ||
230 | { | ||
231 | unsigned int i; | ||
232 | |||
233 | for (i = 0; i < num_iov; i++) { | ||
234 | unsigned int used; | ||
235 | |||
236 | used = iov[i].iov_len < len ? iov[i].iov_len : len; | ||
237 | iov[i].iov_base += used; | ||
238 | iov[i].iov_len -= used; | ||
239 | len -= used; | ||
240 | } | ||
241 | assert(len == 0); | ||
242 | } | ||
243 | |||
202 | /* The device virtqueue descriptors are followed by feature bitmasks. */ | 244 | /* The device virtqueue descriptors are followed by feature bitmasks. */ |
203 | static u8 *get_feature_bits(struct device *dev) | 245 | static u8 *get_feature_bits(struct device *dev) |
204 | { | 246 | { |
@@ -254,6 +296,7 @@ static void *map_zeroed_pages(unsigned int num) | |||
254 | PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0); | 296 | PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0); |
255 | if (addr == MAP_FAILED) | 297 | if (addr == MAP_FAILED) |
256 | err(1, "Mmaping %u pages of /dev/zero", num); | 298 | err(1, "Mmaping %u pages of /dev/zero", num); |
299 | close(fd); | ||
257 | 300 | ||
258 | return addr; | 301 | return addr; |
259 | } | 302 | } |
@@ -540,69 +583,64 @@ static void add_device_fd(int fd) | |||
540 | * watch, but handing a file descriptor mask through to the kernel is fairly | 583 | * watch, but handing a file descriptor mask through to the kernel is fairly |
541 | * icky. | 584 | * icky. |
542 | * | 585 | * |
543 | * Instead, we fork off a process which watches the file descriptors and writes | 586 | * Instead, we clone off a thread which watches the file descriptors and writes |
544 | * the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host | 587 | * the LHREQ_BREAK command to the /dev/lguest file descriptor to tell the Host |
545 | * stop running the Guest. This causes the Launcher to return from the | 588 | * stop running the Guest. This causes the Launcher to return from the |
546 | * /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset | 589 | * /dev/lguest read with -EAGAIN, where it will write to /dev/lguest to reset |
547 | * the LHREQ_BREAK and wake us up again. | 590 | * the LHREQ_BREAK and wake us up again. |
548 | * | 591 | * |
549 | * This, of course, is merely a different *kind* of icky. | 592 | * This, of course, is merely a different *kind* of icky. |
593 | * | ||
594 | * Given my well-known antipathy to threads, I'd prefer to use processes. But | ||
595 | * it's easier to share Guest memory with threads, and trivial to share the | ||
596 | * devices.infds as the Launcher changes it. | ||
550 | */ | 597 | */ |
551 | static void wake_parent(int pipefd, int lguest_fd) | 598 | static int waker(void *unused) |
552 | { | 599 | { |
553 | /* Add the pipe from the Launcher to the fdset in the device_list, so | 600 | /* Close the write end of the pipe: only the Launcher has it open. */ |
554 | * we watch it, too. */ | 601 | close(waker_fds.pipe[1]); |
555 | add_device_fd(pipefd); | ||
556 | 602 | ||
557 | for (;;) { | 603 | for (;;) { |
558 | fd_set rfds = devices.infds; | 604 | fd_set rfds = devices.infds; |
559 | unsigned long args[] = { LHREQ_BREAK, 1 }; | 605 | unsigned long args[] = { LHREQ_BREAK, 1 }; |
606 | unsigned int maxfd = devices.max_infd; | ||
607 | |||
608 | /* We also listen to the pipe from the Launcher. */ | ||
609 | FD_SET(waker_fds.pipe[0], &rfds); | ||
610 | if (waker_fds.pipe[0] > maxfd) | ||
611 | maxfd = waker_fds.pipe[0]; | ||
560 | 612 | ||
561 | /* Wait until input is ready from one of the devices. */ | 613 | /* Wait until input is ready from one of the devices. */ |
562 | select(devices.max_infd+1, &rfds, NULL, NULL, NULL); | 614 | select(maxfd+1, &rfds, NULL, NULL, NULL); |
563 | /* Is it a message from the Launcher? */ | 615 | |
564 | if (FD_ISSET(pipefd, &rfds)) { | 616 | /* Message from Launcher? */ |
565 | int fd; | 617 | if (FD_ISSET(waker_fds.pipe[0], &rfds)) { |
566 | /* If read() returns 0, it means the Launcher has | 618 | char c; |
567 | * exited. We silently follow. */ | 619 | /* If this fails, then assume Launcher has exited. |
568 | if (read(pipefd, &fd, sizeof(fd)) == 0) | 620 | * Don't do anything on exit: we're just a thread! */ |
569 | exit(0); | 621 | if (read(waker_fds.pipe[0], &c, 1) != 1) |
570 | /* Otherwise it's telling us to change what file | 622 | _exit(0); |
571 | * descriptors we're to listen to. Positive means | 623 | continue; |
572 | * listen to a new one, negative means stop | 624 | } |
573 | * listening. */ | 625 | |
574 | if (fd >= 0) | 626 | /* Send LHREQ_BREAK command to snap the Launcher out of it. */ |
575 | FD_SET(fd, &devices.infds); | 627 | pwrite(waker_fds.lguest_fd, args, sizeof(args), cpu_id); |
576 | else | ||
577 | FD_CLR(-fd - 1, &devices.infds); | ||
578 | } else /* Send LHREQ_BREAK command. */ | ||
579 | pwrite(lguest_fd, args, sizeof(args), cpu_id); | ||
580 | } | 628 | } |
629 | return 0; | ||
581 | } | 630 | } |
582 | 631 | ||
583 | /* This routine just sets up a pipe to the Waker process. */ | 632 | /* This routine just sets up a pipe to the Waker process. */ |
584 | static int setup_waker(int lguest_fd) | 633 | static void setup_waker(int lguest_fd) |
585 | { | 634 | { |
586 | int pipefd[2], child; | 635 | /* This pipe is closed when Launcher dies, telling Waker. */ |
587 | 636 | if (pipe(waker_fds.pipe) != 0) | |
588 | /* We create a pipe to talk to the Waker, and also so it knows when the | 637 | err(1, "Creating pipe for Waker"); |
589 | * Launcher dies (and closes pipe). */ | ||
590 | pipe(pipefd); | ||
591 | child = fork(); | ||
592 | if (child == -1) | ||
593 | err(1, "forking"); | ||
594 | |||
595 | if (child == 0) { | ||
596 | /* We are the Waker: close the "writing" end of our copy of the | ||
597 | * pipe and start waiting for input. */ | ||
598 | close(pipefd[1]); | ||
599 | wake_parent(pipefd[0], lguest_fd); | ||
600 | } | ||
601 | /* Close the reading end of our copy of the pipe. */ | ||
602 | close(pipefd[0]); | ||
603 | 638 | ||
604 | /* Here is the fd used to talk to the waker. */ | 639 | /* Waker also needs to know the lguest fd */ |
605 | return pipefd[1]; | 640 | waker_fds.lguest_fd = lguest_fd; |
641 | |||
642 | if (clone(waker, malloc(4096) + 4096, CLONE_VM | SIGCHLD, NULL) == -1) | ||
643 | err(1, "Creating Waker"); | ||
606 | } | 644 | } |
607 | 645 | ||
608 | /* | 646 | /* |
@@ -661,19 +699,22 @@ static unsigned get_vq_desc(struct virtqueue *vq, | |||
661 | unsigned int *out_num, unsigned int *in_num) | 699 | unsigned int *out_num, unsigned int *in_num) |
662 | { | 700 | { |
663 | unsigned int i, head; | 701 | unsigned int i, head; |
702 | u16 last_avail; | ||
664 | 703 | ||
665 | /* Check it isn't doing very strange things with descriptor numbers. */ | 704 | /* Check it isn't doing very strange things with descriptor numbers. */ |
666 | if ((u16)(vq->vring.avail->idx - vq->last_avail_idx) > vq->vring.num) | 705 | last_avail = lg_last_avail(vq); |
706 | if ((u16)(vq->vring.avail->idx - last_avail) > vq->vring.num) | ||
667 | errx(1, "Guest moved used index from %u to %u", | 707 | errx(1, "Guest moved used index from %u to %u", |
668 | vq->last_avail_idx, vq->vring.avail->idx); | 708 | last_avail, vq->vring.avail->idx); |
669 | 709 | ||
670 | /* If there's nothing new since last we looked, return invalid. */ | 710 | /* If there's nothing new since last we looked, return invalid. */ |
671 | if (vq->vring.avail->idx == vq->last_avail_idx) | 711 | if (vq->vring.avail->idx == last_avail) |
672 | return vq->vring.num; | 712 | return vq->vring.num; |
673 | 713 | ||
674 | /* Grab the next descriptor number they're advertising, and increment | 714 | /* Grab the next descriptor number they're advertising, and increment |
675 | * the index we've seen. */ | 715 | * the index we've seen. */ |
676 | head = vq->vring.avail->ring[vq->last_avail_idx++ % vq->vring.num]; | 716 | head = vq->vring.avail->ring[last_avail % vq->vring.num]; |
717 | lg_last_avail(vq)++; | ||
677 | 718 | ||
678 | /* If their number is silly, that's a fatal mistake. */ | 719 | /* If their number is silly, that's a fatal mistake. */ |
679 | if (head >= vq->vring.num) | 720 | if (head >= vq->vring.num) |
@@ -821,8 +862,8 @@ static bool handle_console_input(int fd, struct device *dev) | |||
821 | unsigned long args[] = { LHREQ_BREAK, 0 }; | 862 | unsigned long args[] = { LHREQ_BREAK, 0 }; |
822 | /* Close the fd so Waker will know it has to | 863 | /* Close the fd so Waker will know it has to |
823 | * exit. */ | 864 | * exit. */ |
824 | close(waker_fd); | 865 | close(waker_fds.pipe[1]); |
825 | /* Just in case waker is blocked in BREAK, send | 866 | /* Just in case Waker is blocked in BREAK, send |
826 | * unbreak now. */ | 867 | * unbreak now. */ |
827 | write(fd, args, sizeof(args)); | 868 | write(fd, args, sizeof(args)); |
828 | exit(2); | 869 | exit(2); |
@@ -839,7 +880,7 @@ static bool handle_console_input(int fd, struct device *dev) | |||
839 | 880 | ||
840 | /* Handling output for console is simple: we just get all the output buffers | 881 | /* Handling output for console is simple: we just get all the output buffers |
841 | * and write them to stdout. */ | 882 | * and write them to stdout. */ |
842 | static void handle_console_output(int fd, struct virtqueue *vq) | 883 | static void handle_console_output(int fd, struct virtqueue *vq, bool timeout) |
843 | { | 884 | { |
844 | unsigned int head, out, in; | 885 | unsigned int head, out, in; |
845 | int len; | 886 | int len; |
@@ -854,6 +895,21 @@ static void handle_console_output(int fd, struct virtqueue *vq) | |||
854 | } | 895 | } |
855 | } | 896 | } |
856 | 897 | ||
898 | static void block_vq(struct virtqueue *vq) | ||
899 | { | ||
900 | struct itimerval itm; | ||
901 | |||
902 | vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY; | ||
903 | vq->blocked = true; | ||
904 | |||
905 | itm.it_interval.tv_sec = 0; | ||
906 | itm.it_interval.tv_usec = 0; | ||
907 | itm.it_value.tv_sec = 0; | ||
908 | itm.it_value.tv_usec = timeout_usec; | ||
909 | |||
910 | setitimer(ITIMER_REAL, &itm, NULL); | ||
911 | } | ||
912 | |||
857 | /* | 913 | /* |
858 | * The Network | 914 | * The Network |
859 | * | 915 | * |
@@ -861,22 +917,34 @@ static void handle_console_output(int fd, struct virtqueue *vq) | |||
861 | * and write them (ignoring the first element) to this device's file descriptor | 917 | * and write them (ignoring the first element) to this device's file descriptor |
862 | * (/dev/net/tun). | 918 | * (/dev/net/tun). |
863 | */ | 919 | */ |
864 | static void handle_net_output(int fd, struct virtqueue *vq) | 920 | static void handle_net_output(int fd, struct virtqueue *vq, bool timeout) |
865 | { | 921 | { |
866 | unsigned int head, out, in; | 922 | unsigned int head, out, in, num = 0; |
867 | int len; | 923 | int len; |
868 | struct iovec iov[vq->vring.num]; | 924 | struct iovec iov[vq->vring.num]; |
925 | static int last_timeout_num; | ||
869 | 926 | ||
870 | /* Keep getting output buffers from the Guest until we run out. */ | 927 | /* Keep getting output buffers from the Guest until we run out. */ |
871 | while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) { | 928 | while ((head = get_vq_desc(vq, iov, &out, &in)) != vq->vring.num) { |
872 | if (in) | 929 | if (in) |
873 | errx(1, "Input buffers in output queue?"); | 930 | errx(1, "Input buffers in output queue?"); |
874 | /* Check header, but otherwise ignore it (we told the Guest we | 931 | len = writev(vq->dev->fd, iov, out); |
875 | * supported no features, so it shouldn't have anything | 932 | if (len < 0) |
876 | * interesting). */ | 933 | err(1, "Writing network packet to tun"); |
877 | (void)convert(&iov[0], struct virtio_net_hdr); | ||
878 | len = writev(vq->dev->fd, iov+1, out-1); | ||
879 | add_used_and_trigger(fd, vq, head, len); | 934 | add_used_and_trigger(fd, vq, head, len); |
935 | num++; | ||
936 | } | ||
937 | |||
938 | /* Block further kicks and set up a timer if we saw anything. */ | ||
939 | if (!timeout && num) | ||
940 | block_vq(vq); | ||
941 | |||
942 | if (timeout) { | ||
943 | if (num < last_timeout_num) | ||
944 | timeout_usec += 10; | ||
945 | else if (timeout_usec > 1) | ||
946 | timeout_usec--; | ||
947 | last_timeout_num = num; | ||
880 | } | 948 | } |
881 | } | 949 | } |
882 | 950 | ||
@@ -887,7 +955,6 @@ static bool handle_tun_input(int fd, struct device *dev) | |||
887 | unsigned int head, in_num, out_num; | 955 | unsigned int head, in_num, out_num; |
888 | int len; | 956 | int len; |
889 | struct iovec iov[dev->vq->vring.num]; | 957 | struct iovec iov[dev->vq->vring.num]; |
890 | struct virtio_net_hdr *hdr; | ||
891 | 958 | ||
892 | /* First we need a network buffer from the Guests's recv virtqueue. */ | 959 | /* First we need a network buffer from the Guests's recv virtqueue. */ |
893 | head = get_vq_desc(dev->vq, iov, &out_num, &in_num); | 960 | head = get_vq_desc(dev->vq, iov, &out_num, &in_num); |
@@ -896,25 +963,23 @@ static bool handle_tun_input(int fd, struct device *dev) | |||
896 | * early, the Guest won't be ready yet. Wait until the device | 963 | * early, the Guest won't be ready yet. Wait until the device |
897 | * status says it's ready. */ | 964 | * status says it's ready. */ |
898 | /* FIXME: Actually want DRIVER_ACTIVE here. */ | 965 | /* FIXME: Actually want DRIVER_ACTIVE here. */ |
899 | if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK) | 966 | |
900 | warn("network: no dma buffer!"); | 967 | /* Now tell it we want to know if new things appear. */ |
968 | dev->vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY; | ||
969 | wmb(); | ||
970 | |||
901 | /* We'll turn this back on if input buffers are registered. */ | 971 | /* We'll turn this back on if input buffers are registered. */ |
902 | return false; | 972 | return false; |
903 | } else if (out_num) | 973 | } else if (out_num) |
904 | errx(1, "Output buffers in network recv queue?"); | 974 | errx(1, "Output buffers in network recv queue?"); |
905 | 975 | ||
906 | /* First element is the header: we set it to 0 (no features). */ | ||
907 | hdr = convert(&iov[0], struct virtio_net_hdr); | ||
908 | hdr->flags = 0; | ||
909 | hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE; | ||
910 | |||
911 | /* Read the packet from the device directly into the Guest's buffer. */ | 976 | /* Read the packet from the device directly into the Guest's buffer. */ |
912 | len = readv(dev->fd, iov+1, in_num-1); | 977 | len = readv(dev->fd, iov, in_num); |
913 | if (len <= 0) | 978 | if (len <= 0) |
914 | err(1, "reading network"); | 979 | err(1, "reading network"); |
915 | 980 | ||
916 | /* Tell the Guest about the new packet. */ | 981 | /* Tell the Guest about the new packet. */ |
917 | add_used_and_trigger(fd, dev->vq, head, sizeof(*hdr) + len); | 982 | add_used_and_trigger(fd, dev->vq, head, len); |
918 | 983 | ||
919 | verbose("tun input packet len %i [%02x %02x] (%s)\n", len, | 984 | verbose("tun input packet len %i [%02x %02x] (%s)\n", len, |
920 | ((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1], | 985 | ((u8 *)iov[1].iov_base)[0], ((u8 *)iov[1].iov_base)[1], |
@@ -927,11 +992,18 @@ static bool handle_tun_input(int fd, struct device *dev) | |||
927 | /*L:215 This is the callback attached to the network and console input | 992 | /*L:215 This is the callback attached to the network and console input |
928 | * virtqueues: it ensures we try again, in case we stopped console or net | 993 | * virtqueues: it ensures we try again, in case we stopped console or net |
929 | * delivery because Guest didn't have any buffers. */ | 994 | * delivery because Guest didn't have any buffers. */ |
930 | static void enable_fd(int fd, struct virtqueue *vq) | 995 | static void enable_fd(int fd, struct virtqueue *vq, bool timeout) |
931 | { | 996 | { |
932 | add_device_fd(vq->dev->fd); | 997 | add_device_fd(vq->dev->fd); |
933 | /* Tell waker to listen to it again */ | 998 | /* Snap the Waker out of its select loop. */ |
934 | write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd)); | 999 | write(waker_fds.pipe[1], "", 1); |
1000 | } | ||
1001 | |||
1002 | static void net_enable_fd(int fd, struct virtqueue *vq, bool timeout) | ||
1003 | { | ||
1004 | /* We don't need to know again when Guest refills receive buffer. */ | ||
1005 | vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY; | ||
1006 | enable_fd(fd, vq, timeout); | ||
935 | } | 1007 | } |
936 | 1008 | ||
937 | /* When the Guest tells us they updated the status field, we handle it. */ | 1009 | /* When the Guest tells us they updated the status field, we handle it. */ |
@@ -951,7 +1023,7 @@ static void update_device_status(struct device *dev) | |||
951 | for (vq = dev->vq; vq; vq = vq->next) { | 1023 | for (vq = dev->vq; vq; vq = vq->next) { |
952 | memset(vq->vring.desc, 0, | 1024 | memset(vq->vring.desc, 0, |
953 | vring_size(vq->config.num, getpagesize())); | 1025 | vring_size(vq->config.num, getpagesize())); |
954 | vq->last_avail_idx = 0; | 1026 | lg_last_avail(vq) = 0; |
955 | } | 1027 | } |
956 | } else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) { | 1028 | } else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) { |
957 | warnx("Device %s configuration FAILED", dev->name); | 1029 | warnx("Device %s configuration FAILED", dev->name); |
@@ -960,10 +1032,10 @@ static void update_device_status(struct device *dev) | |||
960 | 1032 | ||
961 | verbose("Device %s OK: offered", dev->name); | 1033 | verbose("Device %s OK: offered", dev->name); |
962 | for (i = 0; i < dev->desc->feature_len; i++) | 1034 | for (i = 0; i < dev->desc->feature_len; i++) |
963 | verbose(" %08x", get_feature_bits(dev)[i]); | 1035 | verbose(" %02x", get_feature_bits(dev)[i]); |
964 | verbose(", accepted"); | 1036 | verbose(", accepted"); |
965 | for (i = 0; i < dev->desc->feature_len; i++) | 1037 | for (i = 0; i < dev->desc->feature_len; i++) |
966 | verbose(" %08x", get_feature_bits(dev) | 1038 | verbose(" %02x", get_feature_bits(dev) |
967 | [dev->desc->feature_len+i]); | 1039 | [dev->desc->feature_len+i]); |
968 | 1040 | ||
969 | if (dev->ready) | 1041 | if (dev->ready) |
@@ -1000,7 +1072,7 @@ static void handle_output(int fd, unsigned long addr) | |||
1000 | if (strcmp(vq->dev->name, "console") != 0) | 1072 | if (strcmp(vq->dev->name, "console") != 0) |
1001 | verbose("Output to %s\n", vq->dev->name); | 1073 | verbose("Output to %s\n", vq->dev->name); |
1002 | if (vq->handle_output) | 1074 | if (vq->handle_output) |
1003 | vq->handle_output(fd, vq); | 1075 | vq->handle_output(fd, vq, false); |
1004 | return; | 1076 | return; |
1005 | } | 1077 | } |
1006 | } | 1078 | } |
@@ -1014,6 +1086,29 @@ static void handle_output(int fd, unsigned long addr) | |||
1014 | strnlen(from_guest_phys(addr), guest_limit - addr)); | 1086 | strnlen(from_guest_phys(addr), guest_limit - addr)); |
1015 | } | 1087 | } |
1016 | 1088 | ||
1089 | static void handle_timeout(int fd) | ||
1090 | { | ||
1091 | char buf[32]; | ||
1092 | struct device *i; | ||
1093 | struct virtqueue *vq; | ||
1094 | |||
1095 | /* Clear the pipe */ | ||
1096 | read(timeoutpipe[0], buf, sizeof(buf)); | ||
1097 | |||
1098 | /* Check each device and virtqueue: flush blocked ones. */ | ||
1099 | for (i = devices.dev; i; i = i->next) { | ||
1100 | for (vq = i->vq; vq; vq = vq->next) { | ||
1101 | if (!vq->blocked) | ||
1102 | continue; | ||
1103 | |||
1104 | vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY; | ||
1105 | vq->blocked = false; | ||
1106 | if (vq->handle_output) | ||
1107 | vq->handle_output(fd, vq, true); | ||
1108 | } | ||
1109 | } | ||
1110 | } | ||
1111 | |||
1017 | /* This is called when the Waker wakes us up: check for incoming file | 1112 | /* This is called when the Waker wakes us up: check for incoming file |
1018 | * descriptors. */ | 1113 | * descriptors. */ |
1019 | static void handle_input(int fd) | 1114 | static void handle_input(int fd) |
@@ -1024,16 +1119,20 @@ static void handle_input(int fd) | |||
1024 | for (;;) { | 1119 | for (;;) { |
1025 | struct device *i; | 1120 | struct device *i; |
1026 | fd_set fds = devices.infds; | 1121 | fd_set fds = devices.infds; |
1122 | int num; | ||
1027 | 1123 | ||
1124 | num = select(devices.max_infd+1, &fds, NULL, NULL, &poll); | ||
1125 | /* Could get interrupted */ | ||
1126 | if (num < 0) | ||
1127 | continue; | ||
1028 | /* If nothing is ready, we're done. */ | 1128 | /* If nothing is ready, we're done. */ |
1029 | if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0) | 1129 | if (num == 0) |
1030 | break; | 1130 | break; |
1031 | 1131 | ||
1032 | /* Otherwise, call the device(s) which have readable file | 1132 | /* Otherwise, call the device(s) which have readable file |
1033 | * descriptors and a method of handling them. */ | 1133 | * descriptors and a method of handling them. */ |
1034 | for (i = devices.dev; i; i = i->next) { | 1134 | for (i = devices.dev; i; i = i->next) { |
1035 | if (i->handle_input && FD_ISSET(i->fd, &fds)) { | 1135 | if (i->handle_input && FD_ISSET(i->fd, &fds)) { |
1036 | int dev_fd; | ||
1037 | if (i->handle_input(fd, i)) | 1136 | if (i->handle_input(fd, i)) |
1038 | continue; | 1137 | continue; |
1039 | 1138 | ||
@@ -1043,13 +1142,12 @@ static void handle_input(int fd) | |||
1043 | * buffers to deliver into. Console also uses | 1142 | * buffers to deliver into. Console also uses |
1044 | * it when it discovers that stdin is closed. */ | 1143 | * it when it discovers that stdin is closed. */ |
1045 | FD_CLR(i->fd, &devices.infds); | 1144 | FD_CLR(i->fd, &devices.infds); |
1046 | /* Tell waker to ignore it too, by sending a | ||
1047 | * negative fd number (-1, since 0 is a valid | ||
1048 | * FD number). */ | ||
1049 | dev_fd = -i->fd - 1; | ||
1050 | write(waker_fd, &dev_fd, sizeof(dev_fd)); | ||
1051 | } | 1145 | } |
1052 | } | 1146 | } |
1147 | |||
1148 | /* Is this the timeout fd? */ | ||
1149 | if (FD_ISSET(timeoutpipe[0], &fds)) | ||
1150 | handle_timeout(fd); | ||
1053 | } | 1151 | } |
1054 | } | 1152 | } |
1055 | 1153 | ||
@@ -1098,7 +1196,7 @@ static struct lguest_device_desc *new_dev_desc(u16 type) | |||
1098 | /* Each device descriptor is followed by the description of its virtqueues. We | 1196 | /* Each device descriptor is followed by the description of its virtqueues. We |
1099 | * specify how many descriptors the virtqueue is to have. */ | 1197 | * specify how many descriptors the virtqueue is to have. */ |
1100 | static void add_virtqueue(struct device *dev, unsigned int num_descs, | 1198 | static void add_virtqueue(struct device *dev, unsigned int num_descs, |
1101 | void (*handle_output)(int fd, struct virtqueue *me)) | 1199 | void (*handle_output)(int, struct virtqueue *, bool)) |
1102 | { | 1200 | { |
1103 | unsigned int pages; | 1201 | unsigned int pages; |
1104 | struct virtqueue **i, *vq = malloc(sizeof(*vq)); | 1202 | struct virtqueue **i, *vq = malloc(sizeof(*vq)); |
@@ -1114,6 +1212,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs, | |||
1114 | vq->last_avail_idx = 0; | 1212 | vq->last_avail_idx = 0; |
1115 | vq->dev = dev; | 1213 | vq->dev = dev; |
1116 | vq->inflight = 0; | 1214 | vq->inflight = 0; |
1215 | vq->blocked = false; | ||
1117 | 1216 | ||
1118 | /* Initialize the configuration. */ | 1217 | /* Initialize the configuration. */ |
1119 | vq->config.num = num_descs; | 1218 | vq->config.num = num_descs; |
@@ -1246,6 +1345,24 @@ static void setup_console(void) | |||
1246 | } | 1345 | } |
1247 | /*:*/ | 1346 | /*:*/ |
1248 | 1347 | ||
1348 | static void timeout_alarm(int sig) | ||
1349 | { | ||
1350 | write(timeoutpipe[1], "", 1); | ||
1351 | } | ||
1352 | |||
1353 | static void setup_timeout(void) | ||
1354 | { | ||
1355 | if (pipe(timeoutpipe) != 0) | ||
1356 | err(1, "Creating timeout pipe"); | ||
1357 | |||
1358 | if (fcntl(timeoutpipe[1], F_SETFL, | ||
1359 | fcntl(timeoutpipe[1], F_GETFL) | O_NONBLOCK) != 0) | ||
1360 | err(1, "Making timeout pipe nonblocking"); | ||
1361 | |||
1362 | add_device_fd(timeoutpipe[0]); | ||
1363 | signal(SIGALRM, timeout_alarm); | ||
1364 | } | ||
1365 | |||
1249 | /*M:010 Inter-guest networking is an interesting area. Simplest is to have a | 1366 | /*M:010 Inter-guest networking is an interesting area. Simplest is to have a |
1250 | * --sharenet=<name> option which opens or creates a named pipe. This can be | 1367 | * --sharenet=<name> option which opens or creates a named pipe. This can be |
1251 | * used to send packets to another guest in a 1:1 manner. | 1368 | * used to send packets to another guest in a 1:1 manner. |
@@ -1264,10 +1381,25 @@ static void setup_console(void) | |||
1264 | 1381 | ||
1265 | static u32 str2ip(const char *ipaddr) | 1382 | static u32 str2ip(const char *ipaddr) |
1266 | { | 1383 | { |
1267 | unsigned int byte[4]; | 1384 | unsigned int b[4]; |
1268 | 1385 | ||
1269 | sscanf(ipaddr, "%u.%u.%u.%u", &byte[0], &byte[1], &byte[2], &byte[3]); | 1386 | if (sscanf(ipaddr, "%u.%u.%u.%u", &b[0], &b[1], &b[2], &b[3]) != 4) |
1270 | return (byte[0] << 24) | (byte[1] << 16) | (byte[2] << 8) | byte[3]; | 1387 | errx(1, "Failed to parse IP address '%s'", ipaddr); |
1388 | return (b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3]; | ||
1389 | } | ||
1390 | |||
1391 | static void str2mac(const char *macaddr, unsigned char mac[6]) | ||
1392 | { | ||
1393 | unsigned int m[6]; | ||
1394 | if (sscanf(macaddr, "%02x:%02x:%02x:%02x:%02x:%02x", | ||
1395 | &m[0], &m[1], &m[2], &m[3], &m[4], &m[5]) != 6) | ||
1396 | errx(1, "Failed to parse mac address '%s'", macaddr); | ||
1397 | mac[0] = m[0]; | ||
1398 | mac[1] = m[1]; | ||
1399 | mac[2] = m[2]; | ||
1400 | mac[3] = m[3]; | ||
1401 | mac[4] = m[4]; | ||
1402 | mac[5] = m[5]; | ||
1271 | } | 1403 | } |
1272 | 1404 | ||
1273 | /* This code is "adapted" from libbridge: it attaches the Host end of the | 1405 | /* This code is "adapted" from libbridge: it attaches the Host end of the |
@@ -1288,6 +1420,7 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name) | |||
1288 | errx(1, "interface %s does not exist!", if_name); | 1420 | errx(1, "interface %s does not exist!", if_name); |
1289 | 1421 | ||
1290 | strncpy(ifr.ifr_name, br_name, IFNAMSIZ); | 1422 | strncpy(ifr.ifr_name, br_name, IFNAMSIZ); |
1423 | ifr.ifr_name[IFNAMSIZ-1] = '\0'; | ||
1291 | ifr.ifr_ifindex = ifidx; | 1424 | ifr.ifr_ifindex = ifidx; |
1292 | if (ioctl(fd, SIOCBRADDIF, &ifr) < 0) | 1425 | if (ioctl(fd, SIOCBRADDIF, &ifr) < 0) |
1293 | err(1, "can't add %s to bridge %s", if_name, br_name); | 1426 | err(1, "can't add %s to bridge %s", if_name, br_name); |
@@ -1296,64 +1429,90 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name) | |||
1296 | /* This sets up the Host end of the network device with an IP address, brings | 1429 | /* This sets up the Host end of the network device with an IP address, brings |
1297 | * it up so packets will flow, the copies the MAC address into the hwaddr | 1430 | * it up so packets will flow, the copies the MAC address into the hwaddr |
1298 | * pointer. */ | 1431 | * pointer. */ |
1299 | static void configure_device(int fd, const char *devname, u32 ipaddr, | 1432 | static void configure_device(int fd, const char *tapif, u32 ipaddr) |
1300 | unsigned char hwaddr[6]) | ||
1301 | { | 1433 | { |
1302 | struct ifreq ifr; | 1434 | struct ifreq ifr; |
1303 | struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; | 1435 | struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; |
1304 | 1436 | ||
1305 | /* Don't read these incantations. Just cut & paste them like I did! */ | ||
1306 | memset(&ifr, 0, sizeof(ifr)); | 1437 | memset(&ifr, 0, sizeof(ifr)); |
1307 | strcpy(ifr.ifr_name, devname); | 1438 | strcpy(ifr.ifr_name, tapif); |
1439 | |||
1440 | /* Don't read these incantations. Just cut & paste them like I did! */ | ||
1308 | sin->sin_family = AF_INET; | 1441 | sin->sin_family = AF_INET; |
1309 | sin->sin_addr.s_addr = htonl(ipaddr); | 1442 | sin->sin_addr.s_addr = htonl(ipaddr); |
1310 | if (ioctl(fd, SIOCSIFADDR, &ifr) != 0) | 1443 | if (ioctl(fd, SIOCSIFADDR, &ifr) != 0) |
1311 | err(1, "Setting %s interface address", devname); | 1444 | err(1, "Setting %s interface address", tapif); |
1312 | ifr.ifr_flags = IFF_UP; | 1445 | ifr.ifr_flags = IFF_UP; |
1313 | if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0) | 1446 | if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0) |
1314 | err(1, "Bringing interface %s up", devname); | 1447 | err(1, "Bringing interface %s up", tapif); |
1448 | } | ||
1449 | |||
1450 | static void get_mac(int fd, const char *tapif, unsigned char hwaddr[6]) | ||
1451 | { | ||
1452 | struct ifreq ifr; | ||
1453 | |||
1454 | memset(&ifr, 0, sizeof(ifr)); | ||
1455 | strcpy(ifr.ifr_name, tapif); | ||
1315 | 1456 | ||
1316 | /* SIOC stands for Socket I/O Control. G means Get (vs S for Set | 1457 | /* SIOC stands for Socket I/O Control. G means Get (vs S for Set |
1317 | * above). IF means Interface, and HWADDR is hardware address. | 1458 | * above). IF means Interface, and HWADDR is hardware address. |
1318 | * Simple! */ | 1459 | * Simple! */ |
1319 | if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0) | 1460 | if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0) |
1320 | err(1, "getting hw address for %s", devname); | 1461 | err(1, "getting hw address for %s", tapif); |
1321 | memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6); | 1462 | memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6); |
1322 | } | 1463 | } |
1323 | 1464 | ||
1324 | /*L:195 Our network is a Host<->Guest network. This can either use bridging or | 1465 | static int get_tun_device(char tapif[IFNAMSIZ]) |
1325 | * routing, but the principle is the same: it uses the "tun" device to inject | ||
1326 | * packets into the Host as if they came in from a normal network card. We | ||
1327 | * just shunt packets between the Guest and the tun device. */ | ||
1328 | static void setup_tun_net(const char *arg) | ||
1329 | { | 1466 | { |
1330 | struct device *dev; | ||
1331 | struct ifreq ifr; | 1467 | struct ifreq ifr; |
1332 | int netfd, ipfd; | 1468 | int netfd; |
1333 | u32 ip; | 1469 | |
1334 | const char *br_name = NULL; | 1470 | /* Start with this zeroed. Messy but sure. */ |
1335 | struct virtio_net_config conf; | 1471 | memset(&ifr, 0, sizeof(ifr)); |
1336 | 1472 | ||
1337 | /* We open the /dev/net/tun device and tell it we want a tap device. A | 1473 | /* We open the /dev/net/tun device and tell it we want a tap device. A |
1338 | * tap device is like a tun device, only somehow different. To tell | 1474 | * tap device is like a tun device, only somehow different. To tell |
1339 | * the truth, I completely blundered my way through this code, but it | 1475 | * the truth, I completely blundered my way through this code, but it |
1340 | * works now! */ | 1476 | * works now! */ |
1341 | netfd = open_or_die("/dev/net/tun", O_RDWR); | 1477 | netfd = open_or_die("/dev/net/tun", O_RDWR); |
1342 | memset(&ifr, 0, sizeof(ifr)); | 1478 | ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR; |
1343 | ifr.ifr_flags = IFF_TAP | IFF_NO_PI; | ||
1344 | strcpy(ifr.ifr_name, "tap%d"); | 1479 | strcpy(ifr.ifr_name, "tap%d"); |
1345 | if (ioctl(netfd, TUNSETIFF, &ifr) != 0) | 1480 | if (ioctl(netfd, TUNSETIFF, &ifr) != 0) |
1346 | err(1, "configuring /dev/net/tun"); | 1481 | err(1, "configuring /dev/net/tun"); |
1482 | |||
1483 | if (ioctl(netfd, TUNSETOFFLOAD, | ||
1484 | TUN_F_CSUM|TUN_F_TSO4|TUN_F_TSO6|TUN_F_TSO_ECN) != 0) | ||
1485 | err(1, "Could not set features for tun device"); | ||
1486 | |||
1347 | /* We don't need checksums calculated for packets coming in this | 1487 | /* We don't need checksums calculated for packets coming in this |
1348 | * device: trust us! */ | 1488 | * device: trust us! */ |
1349 | ioctl(netfd, TUNSETNOCSUM, 1); | 1489 | ioctl(netfd, TUNSETNOCSUM, 1); |
1350 | 1490 | ||
1491 | memcpy(tapif, ifr.ifr_name, IFNAMSIZ); | ||
1492 | return netfd; | ||
1493 | } | ||
1494 | |||
1495 | /*L:195 Our network is a Host<->Guest network. This can either use bridging or | ||
1496 | * routing, but the principle is the same: it uses the "tun" device to inject | ||
1497 | * packets into the Host as if they came in from a normal network card. We | ||
1498 | * just shunt packets between the Guest and the tun device. */ | ||
1499 | static void setup_tun_net(char *arg) | ||
1500 | { | ||
1501 | struct device *dev; | ||
1502 | int netfd, ipfd; | ||
1503 | u32 ip = INADDR_ANY; | ||
1504 | bool bridging = false; | ||
1505 | char tapif[IFNAMSIZ], *p; | ||
1506 | struct virtio_net_config conf; | ||
1507 | |||
1508 | netfd = get_tun_device(tapif); | ||
1509 | |||
1351 | /* First we create a new network device. */ | 1510 | /* First we create a new network device. */ |
1352 | dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input); | 1511 | dev = new_device("net", VIRTIO_ID_NET, netfd, handle_tun_input); |
1353 | 1512 | ||
1354 | /* Network devices need a receive and a send queue, just like | 1513 | /* Network devices need a receive and a send queue, just like |
1355 | * console. */ | 1514 | * console. */ |
1356 | add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd); | 1515 | add_virtqueue(dev, VIRTQUEUE_NUM, net_enable_fd); |
1357 | add_virtqueue(dev, VIRTQUEUE_NUM, handle_net_output); | 1516 | add_virtqueue(dev, VIRTQUEUE_NUM, handle_net_output); |
1358 | 1517 | ||
1359 | /* We need a socket to perform the magic network ioctls to bring up the | 1518 | /* We need a socket to perform the magic network ioctls to bring up the |
@@ -1364,28 +1523,56 @@ static void setup_tun_net(const char *arg) | |||
1364 | 1523 | ||
1365 | /* If the command line was --tunnet=bridge:<name> do bridging. */ | 1524 | /* If the command line was --tunnet=bridge:<name> do bridging. */ |
1366 | if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) { | 1525 | if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) { |
1367 | ip = INADDR_ANY; | 1526 | arg += strlen(BRIDGE_PFX); |
1368 | br_name = arg + strlen(BRIDGE_PFX); | 1527 | bridging = true; |
1369 | add_to_bridge(ipfd, ifr.ifr_name, br_name); | 1528 | } |
1370 | } else /* It is an IP address to set up the device with */ | 1529 | |
1530 | /* A mac address may follow the bridge name or IP address */ | ||
1531 | p = strchr(arg, ':'); | ||
1532 | if (p) { | ||
1533 | str2mac(p+1, conf.mac); | ||
1534 | *p = '\0'; | ||
1535 | } else { | ||
1536 | p = arg + strlen(arg); | ||
1537 | /* None supplied; query the randomly assigned mac. */ | ||
1538 | get_mac(ipfd, tapif, conf.mac); | ||
1539 | } | ||
1540 | |||
1541 | /* arg is now either an IP address or a bridge name */ | ||
1542 | if (bridging) | ||
1543 | add_to_bridge(ipfd, tapif, arg); | ||
1544 | else | ||
1371 | ip = str2ip(arg); | 1545 | ip = str2ip(arg); |
1372 | 1546 | ||
1373 | /* Set up the tun device, and get the mac address for the interface. */ | 1547 | /* Set up the tun device. */ |
1374 | configure_device(ipfd, ifr.ifr_name, ip, conf.mac); | 1548 | configure_device(ipfd, tapif, ip); |
1375 | 1549 | ||
1376 | /* Tell Guest what MAC address to use. */ | 1550 | /* Tell Guest what MAC address to use. */ |
1377 | add_feature(dev, VIRTIO_NET_F_MAC); | 1551 | add_feature(dev, VIRTIO_NET_F_MAC); |
1378 | add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); | 1552 | add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); |
1553 | /* Expect Guest to handle everything except UFO */ | ||
1554 | add_feature(dev, VIRTIO_NET_F_CSUM); | ||
1555 | add_feature(dev, VIRTIO_NET_F_GUEST_CSUM); | ||
1556 | add_feature(dev, VIRTIO_NET_F_MAC); | ||
1557 | add_feature(dev, VIRTIO_NET_F_GUEST_TSO4); | ||
1558 | add_feature(dev, VIRTIO_NET_F_GUEST_TSO6); | ||
1559 | add_feature(dev, VIRTIO_NET_F_GUEST_ECN); | ||
1560 | add_feature(dev, VIRTIO_NET_F_HOST_TSO4); | ||
1561 | add_feature(dev, VIRTIO_NET_F_HOST_TSO6); | ||
1562 | add_feature(dev, VIRTIO_NET_F_HOST_ECN); | ||
1379 | set_config(dev, sizeof(conf), &conf); | 1563 | set_config(dev, sizeof(conf), &conf); |
1380 | 1564 | ||
1381 | /* We don't need the socket any more; setup is done. */ | 1565 | /* We don't need the socket any more; setup is done. */ |
1382 | close(ipfd); | 1566 | close(ipfd); |
1383 | 1567 | ||
1384 | verbose("device %u: tun net %u.%u.%u.%u\n", | 1568 | devices.device_num++; |
1385 | devices.device_num++, | 1569 | |
1386 | (u8)(ip>>24),(u8)(ip>>16),(u8)(ip>>8),(u8)ip); | 1570 | if (bridging) |
1387 | if (br_name) | 1571 | verbose("device %u: tun %s attached to bridge: %s\n", |
1388 | verbose("attached to bridge: %s\n", br_name); | 1572 | devices.device_num, tapif, arg); |
1573 | else | ||
1574 | verbose("device %u: tun %s: %s\n", | ||
1575 | devices.device_num, tapif, arg); | ||
1389 | } | 1576 | } |
1390 | 1577 | ||
1391 | /* Our block (disk) device should be really simple: the Guest asks for a block | 1578 | /* Our block (disk) device should be really simple: the Guest asks for a block |
@@ -1550,7 +1737,7 @@ static bool handle_io_finish(int fd, struct device *dev) | |||
1550 | } | 1737 | } |
1551 | 1738 | ||
1552 | /* When the Guest submits some I/O, we just need to wake the I/O thread. */ | 1739 | /* When the Guest submits some I/O, we just need to wake the I/O thread. */ |
1553 | static void handle_virtblk_output(int fd, struct virtqueue *vq) | 1740 | static void handle_virtblk_output(int fd, struct virtqueue *vq, bool timeout) |
1554 | { | 1741 | { |
1555 | struct vblk_info *vblk = vq->dev->priv; | 1742 | struct vblk_info *vblk = vq->dev->priv; |
1556 | char c = 0; | 1743 | char c = 0; |
@@ -1621,6 +1808,64 @@ static void setup_block_file(const char *filename) | |||
1621 | verbose("device %u: virtblock %llu sectors\n", | 1808 | verbose("device %u: virtblock %llu sectors\n", |
1622 | devices.device_num, le64_to_cpu(conf.capacity)); | 1809 | devices.device_num, le64_to_cpu(conf.capacity)); |
1623 | } | 1810 | } |
1811 | |||
1812 | /* Our random number generator device reads from /dev/random into the Guest's | ||
1813 | * input buffers. The usual case is that the Guest doesn't want random numbers | ||
1814 | * and so has no buffers although /dev/random is still readable, whereas | ||
1815 | * console is the reverse. | ||
1816 | * | ||
1817 | * The same logic applies, however. */ | ||
1818 | static bool handle_rng_input(int fd, struct device *dev) | ||
1819 | { | ||
1820 | int len; | ||
1821 | unsigned int head, in_num, out_num, totlen = 0; | ||
1822 | struct iovec iov[dev->vq->vring.num]; | ||
1823 | |||
1824 | /* First we need a buffer from the Guests's virtqueue. */ | ||
1825 | head = get_vq_desc(dev->vq, iov, &out_num, &in_num); | ||
1826 | |||
1827 | /* If they're not ready for input, stop listening to this file | ||
1828 | * descriptor. We'll start again once they add an input buffer. */ | ||
1829 | if (head == dev->vq->vring.num) | ||
1830 | return false; | ||
1831 | |||
1832 | if (out_num) | ||
1833 | errx(1, "Output buffers in rng?"); | ||
1834 | |||
1835 | /* This is why we convert to iovecs: the readv() call uses them, and so | ||
1836 | * it reads straight into the Guest's buffer. We loop to make sure we | ||
1837 | * fill it. */ | ||
1838 | while (!iov_empty(iov, in_num)) { | ||
1839 | len = readv(dev->fd, iov, in_num); | ||
1840 | if (len <= 0) | ||
1841 | err(1, "Read from /dev/random gave %i", len); | ||
1842 | iov_consume(iov, in_num, len); | ||
1843 | totlen += len; | ||
1844 | } | ||
1845 | |||
1846 | /* Tell the Guest about the new input. */ | ||
1847 | add_used_and_trigger(fd, dev->vq, head, totlen); | ||
1848 | |||
1849 | /* Everything went OK! */ | ||
1850 | return true; | ||
1851 | } | ||
1852 | |||
1853 | /* And this creates a "hardware" random number device for the Guest. */ | ||
1854 | static void setup_rng(void) | ||
1855 | { | ||
1856 | struct device *dev; | ||
1857 | int fd; | ||
1858 | |||
1859 | fd = open_or_die("/dev/random", O_RDONLY); | ||
1860 | |||
1861 | /* The device responds to return from I/O thread. */ | ||
1862 | dev = new_device("rng", VIRTIO_ID_RNG, fd, handle_rng_input); | ||
1863 | |||
1864 | /* The device has one virtqueue, where the Guest places inbufs. */ | ||
1865 | add_virtqueue(dev, VIRTQUEUE_NUM, enable_fd); | ||
1866 | |||
1867 | verbose("device %u: rng\n", devices.device_num++); | ||
1868 | } | ||
1624 | /* That's the end of device setup. */ | 1869 | /* That's the end of device setup. */ |
1625 | 1870 | ||
1626 | /*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */ | 1871 | /*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */ |
@@ -1628,11 +1873,12 @@ static void __attribute__((noreturn)) restart_guest(void) | |||
1628 | { | 1873 | { |
1629 | unsigned int i; | 1874 | unsigned int i; |
1630 | 1875 | ||
1631 | /* Closing pipes causes the Waker thread and io_threads to die, and | 1876 | /* Since we don't track all open fds, we simply close everything beyond |
1632 | * closing /dev/lguest cleans up the Guest. Since we don't track all | 1877 | * stderr. */ |
1633 | * open fds, we simply close everything beyond stderr. */ | ||
1634 | for (i = 3; i < FD_SETSIZE; i++) | 1878 | for (i = 3; i < FD_SETSIZE; i++) |
1635 | close(i); | 1879 | close(i); |
1880 | |||
1881 | /* The exec automatically gets rid of the I/O and Waker threads. */ | ||
1636 | execv(main_args[0], main_args); | 1882 | execv(main_args[0], main_args); |
1637 | err(1, "Could not exec %s", main_args[0]); | 1883 | err(1, "Could not exec %s", main_args[0]); |
1638 | } | 1884 | } |
@@ -1663,7 +1909,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd) | |||
1663 | /* ERESTART means that we need to reboot the guest */ | 1909 | /* ERESTART means that we need to reboot the guest */ |
1664 | } else if (errno == ERESTART) { | 1910 | } else if (errno == ERESTART) { |
1665 | restart_guest(); | 1911 | restart_guest(); |
1666 | /* EAGAIN means the Waker wanted us to look at some input. | 1912 | /* EAGAIN means a signal (timeout). |
1667 | * Anything else means a bug or incompatible change. */ | 1913 | * Anything else means a bug or incompatible change. */ |
1668 | } else if (errno != EAGAIN) | 1914 | } else if (errno != EAGAIN) |
1669 | err(1, "Running guest failed"); | 1915 | err(1, "Running guest failed"); |
@@ -1691,13 +1937,14 @@ static struct option opts[] = { | |||
1691 | { "verbose", 0, NULL, 'v' }, | 1937 | { "verbose", 0, NULL, 'v' }, |
1692 | { "tunnet", 1, NULL, 't' }, | 1938 | { "tunnet", 1, NULL, 't' }, |
1693 | { "block", 1, NULL, 'b' }, | 1939 | { "block", 1, NULL, 'b' }, |
1940 | { "rng", 0, NULL, 'r' }, | ||
1694 | { "initrd", 1, NULL, 'i' }, | 1941 | { "initrd", 1, NULL, 'i' }, |
1695 | { NULL }, | 1942 | { NULL }, |
1696 | }; | 1943 | }; |
1697 | static void usage(void) | 1944 | static void usage(void) |
1698 | { | 1945 | { |
1699 | errx(1, "Usage: lguest [--verbose] " | 1946 | errx(1, "Usage: lguest [--verbose] " |
1700 | "[--tunnet=(<ipaddr>|bridge:<bridgename>)\n" | 1947 | "[--tunnet=(<ipaddr>:<macaddr>|bridge:<bridgename>:<macaddr>)\n" |
1701 | "|--block=<filename>|--initrd=<filename>]...\n" | 1948 | "|--block=<filename>|--initrd=<filename>]...\n" |
1702 | "<mem-in-mb> vmlinux [args...]"); | 1949 | "<mem-in-mb> vmlinux [args...]"); |
1703 | } | 1950 | } |
@@ -1765,6 +2012,9 @@ int main(int argc, char *argv[]) | |||
1765 | case 'b': | 2012 | case 'b': |
1766 | setup_block_file(optarg); | 2013 | setup_block_file(optarg); |
1767 | break; | 2014 | break; |
2015 | case 'r': | ||
2016 | setup_rng(); | ||
2017 | break; | ||
1768 | case 'i': | 2018 | case 'i': |
1769 | initrd_name = optarg; | 2019 | initrd_name = optarg; |
1770 | break; | 2020 | break; |
@@ -1783,6 +2033,9 @@ int main(int argc, char *argv[]) | |||
1783 | /* We always have a console device */ | 2033 | /* We always have a console device */ |
1784 | setup_console(); | 2034 | setup_console(); |
1785 | 2035 | ||
2036 | /* We can timeout waiting for Guest network transmit. */ | ||
2037 | setup_timeout(); | ||
2038 | |||
1786 | /* Now we load the kernel */ | 2039 | /* Now we load the kernel */ |
1787 | start = load_kernel(open_or_die(argv[optind+1], O_RDONLY)); | 2040 | start = load_kernel(open_or_die(argv[optind+1], O_RDONLY)); |
1788 | 2041 | ||
@@ -1826,10 +2079,10 @@ int main(int argc, char *argv[]) | |||
1826 | * /dev/lguest file descriptor. */ | 2079 | * /dev/lguest file descriptor. */ |
1827 | lguest_fd = tell_kernel(pgdir, start); | 2080 | lguest_fd = tell_kernel(pgdir, start); |
1828 | 2081 | ||
1829 | /* We fork off a child process, which wakes the Launcher whenever one | 2082 | /* We clone off a thread, which wakes the Launcher whenever one of the |
1830 | * of the input file descriptors needs attention. We call this the | 2083 | * input file descriptors needs attention. We call this the Waker, and |
1831 | * Waker, and we'll cover it in a moment. */ | 2084 | * we'll cover it in a moment. */ |
1832 | waker_fd = setup_waker(lguest_fd); | 2085 | setup_waker(lguest_fd); |
1833 | 2086 | ||
1834 | /* Finally, run the Guest. This doesn't return. */ | 2087 | /* Finally, run the Guest. This doesn't return. */ |
1835 | run_guest(lguest_fd); | 2088 | run_guest(lguest_fd); |
diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index 49adb1a33514..c40866e8b957 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt | |||
@@ -1,4 +1,4 @@ | |||
1 | PM quality of Service interface. | 1 | PM Quality Of Service Interface. |
2 | 2 | ||
3 | This interface provides a kernel and user mode interface for registering | 3 | This interface provides a kernel and user mode interface for registering |
4 | performance expectations by drivers, subsystems and user space applications on | 4 | performance expectations by drivers, subsystems and user space applications on |
@@ -7,6 +7,11 @@ one of the parameters. | |||
7 | Currently we have {cpu_dma_latency, network_latency, network_throughput} as the | 7 | Currently we have {cpu_dma_latency, network_latency, network_throughput} as the |
8 | initial set of pm_qos parameters. | 8 | initial set of pm_qos parameters. |
9 | 9 | ||
10 | Each parameters have defined units: | ||
11 | * latency: usec | ||
12 | * timeout: usec | ||
13 | * throughput: kbs (kilo bit / sec) | ||
14 | |||
10 | The infrastructure exposes multiple misc device nodes one per implemented | 15 | The infrastructure exposes multiple misc device nodes one per implemented |
11 | parameter. The set of parameters implement is defined by pm_qos_power_init() | 16 | parameter. The set of parameters implement is defined by pm_qos_power_init() |
12 | and pm_qos_params.h. This is done because having the available parameters | 17 | and pm_qos_params.h. This is done because having the available parameters |
diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index a8686e5a6857..c6cd4956047c 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt | |||
@@ -101,6 +101,10 @@ of charge when battery became full/empty". It also could mean "value of | |||
101 | charge when battery considered full/empty at given conditions (temperature, | 101 | charge when battery considered full/empty at given conditions (temperature, |
102 | age)". I.e. these attributes represents real thresholds, not design values. | 102 | age)". I.e. these attributes represents real thresholds, not design values. |
103 | 103 | ||
104 | CHARGE_COUNTER - the current charge counter (in µAh). This could easily | ||
105 | be negative; there is no empty or full value. It is only useful for | ||
106 | relative, time-based measurements. | ||
107 | |||
104 | ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. | 108 | ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. |
105 | 109 | ||
106 | CAPACITY - capacity in percents. | 110 | CAPACITY - capacity in percents. |
diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt new file mode 100644 index 000000000000..82b7a43aadba --- /dev/null +++ b/Documentation/power/regulator/consumer.txt | |||
@@ -0,0 +1,182 @@ | |||
1 | Regulator Consumer Driver Interface | ||
2 | =================================== | ||
3 | |||
4 | This text describes the regulator interface for consumer device drivers. | ||
5 | Please see overview.txt for a description of the terms used in this text. | ||
6 | |||
7 | |||
8 | 1. Consumer Regulator Access (static & dynamic drivers) | ||
9 | ======================================================= | ||
10 | |||
11 | A consumer driver can get access to it's supply regulator by calling :- | ||
12 | |||
13 | regulator = regulator_get(dev, "Vcc"); | ||
14 | |||
15 | The consumer passes in it's struct device pointer and power supply ID. The core | ||
16 | then finds the correct regulator by consulting a machine specific lookup table. | ||
17 | If the lookup is successful then this call will return a pointer to the struct | ||
18 | regulator that supplies this consumer. | ||
19 | |||
20 | To release the regulator the consumer driver should call :- | ||
21 | |||
22 | regulator_put(regulator); | ||
23 | |||
24 | Consumers can be supplied by more than one regulator e.g. codec consumer with | ||
25 | analog and digital supplies :- | ||
26 | |||
27 | digital = regulator_get(dev, "Vcc"); /* digital core */ | ||
28 | analog = regulator_get(dev, "Avdd"); /* analog */ | ||
29 | |||
30 | The regulator access functions regulator_get() and regulator_put() will | ||
31 | usually be called in your device drivers probe() and remove() respectively. | ||
32 | |||
33 | |||
34 | 2. Regulator Output Enable & Disable (static & dynamic drivers) | ||
35 | ==================================================================== | ||
36 | |||
37 | A consumer can enable it's power supply by calling:- | ||
38 | |||
39 | int regulator_enable(regulator); | ||
40 | |||
41 | NOTE: The supply may already be enabled before regulator_enabled() is called. | ||
42 | This may happen if the consumer shares the regulator or the regulator has been | ||
43 | previously enabled by bootloader or kernel board initialization code. | ||
44 | |||
45 | A consumer can determine if a regulator is enabled by calling :- | ||
46 | |||
47 | int regulator_is_enabled(regulator); | ||
48 | |||
49 | This will return > zero when the regulator is enabled. | ||
50 | |||
51 | |||
52 | A consumer can disable it's supply when no longer needed by calling :- | ||
53 | |||
54 | int regulator_disable(regulator); | ||
55 | |||
56 | NOTE: This may not disable the supply if it's shared with other consumers. The | ||
57 | regulator will only be disabled when the enabled reference count is zero. | ||
58 | |||
59 | Finally, a regulator can be forcefully disabled in the case of an emergency :- | ||
60 | |||
61 | int regulator_force_disable(regulator); | ||
62 | |||
63 | NOTE: this will immediately and forcefully shutdown the regulator output. All | ||
64 | consumers will be powered off. | ||
65 | |||
66 | |||
67 | 3. Regulator Voltage Control & Status (dynamic drivers) | ||
68 | ====================================================== | ||
69 | |||
70 | Some consumer drivers need to be able to dynamically change their supply | ||
71 | voltage to match system operating points. e.g. CPUfreq drivers can scale | ||
72 | voltage along with frequency to save power, SD drivers may need to select the | ||
73 | correct card voltage, etc. | ||
74 | |||
75 | Consumers can control their supply voltage by calling :- | ||
76 | |||
77 | int regulator_set_voltage(regulator, min_uV, max_uV); | ||
78 | |||
79 | Where min_uV and max_uV are the minimum and maximum acceptable voltages in | ||
80 | microvolts. | ||
81 | |||
82 | NOTE: this can be called when the regulator is enabled or disabled. If called | ||
83 | when enabled, then the voltage changes instantly, otherwise the voltage | ||
84 | configuration changes and the voltage is physically set when the regulator is | ||
85 | next enabled. | ||
86 | |||
87 | The regulators configured voltage output can be found by calling :- | ||
88 | |||
89 | int regulator_get_voltage(regulator); | ||
90 | |||
91 | NOTE: get_voltage() will return the configured output voltage whether the | ||
92 | regulator is enabled or disabled and should NOT be used to determine regulator | ||
93 | output state. However this can be used in conjunction with is_enabled() to | ||
94 | determine the regulator physical output voltage. | ||
95 | |||
96 | |||
97 | 4. Regulator Current Limit Control & Status (dynamic drivers) | ||
98 | =========================================================== | ||
99 | |||
100 | Some consumer drivers need to be able to dynamically change their supply | ||
101 | current limit to match system operating points. e.g. LCD backlight driver can | ||
102 | change the current limit to vary the backlight brightness, USB drivers may want | ||
103 | to set the limit to 500mA when supplying power. | ||
104 | |||
105 | Consumers can control their supply current limit by calling :- | ||
106 | |||
107 | int regulator_set_current_limit(regulator, min_uV, max_uV); | ||
108 | |||
109 | Where min_uA and max_uA are the minimum and maximum acceptable current limit in | ||
110 | microamps. | ||
111 | |||
112 | NOTE: this can be called when the regulator is enabled or disabled. If called | ||
113 | when enabled, then the current limit changes instantly, otherwise the current | ||
114 | limit configuration changes and the current limit is physically set when the | ||
115 | regulator is next enabled. | ||
116 | |||
117 | A regulators current limit can be found by calling :- | ||
118 | |||
119 | int regulator_get_current_limit(regulator); | ||
120 | |||
121 | NOTE: get_current_limit() will return the current limit whether the regulator | ||
122 | is enabled or disabled and should not be used to determine regulator current | ||
123 | load. | ||
124 | |||
125 | |||
126 | 5. Regulator Operating Mode Control & Status (dynamic drivers) | ||
127 | ============================================================= | ||
128 | |||
129 | Some consumers can further save system power by changing the operating mode of | ||
130 | their supply regulator to be more efficient when the consumers operating state | ||
131 | changes. e.g. consumer driver is idle and subsequently draws less current | ||
132 | |||
133 | Regulator operating mode can be changed indirectly or directly. | ||
134 | |||
135 | Indirect operating mode control. | ||
136 | -------------------------------- | ||
137 | Consumer drivers can request a change in their supply regulator operating mode | ||
138 | by calling :- | ||
139 | |||
140 | int regulator_set_optimum_mode(struct regulator *regulator, int load_uA); | ||
141 | |||
142 | This will cause the core to recalculate the total load on the regulator (based | ||
143 | on all it's consumers) and change operating mode (if necessary and permitted) | ||
144 | to best match the current operating load. | ||
145 | |||
146 | The load_uA value can be determined from the consumers datasheet. e.g.most | ||
147 | datasheets have tables showing the max current consumed in certain situations. | ||
148 | |||
149 | Most consumers will use indirect operating mode control since they have no | ||
150 | knowledge of the regulator or whether the regulator is shared with other | ||
151 | consumers. | ||
152 | |||
153 | Direct operating mode control. | ||
154 | ------------------------------ | ||
155 | Bespoke or tightly coupled drivers may want to directly control regulator | ||
156 | operating mode depending on their operating point. This can be achieved by | ||
157 | calling :- | ||
158 | |||
159 | int regulator_set_mode(struct regulator *regulator, unsigned int mode); | ||
160 | unsigned int regulator_get_mode(struct regulator *regulator); | ||
161 | |||
162 | Direct mode will only be used by consumers that *know* about the regulator and | ||
163 | are not sharing the regulator with other consumers. | ||
164 | |||
165 | |||
166 | 6. Regulator Events | ||
167 | =================== | ||
168 | Regulators can notify consumers of external events. Events could be received by | ||
169 | consumers under regulator stress or failure conditions. | ||
170 | |||
171 | Consumers can register interest in regulator events by calling :- | ||
172 | |||
173 | int regulator_register_notifier(struct regulator *regulator, | ||
174 | struct notifier_block *nb); | ||
175 | |||
176 | Consumers can uregister interest by calling :- | ||
177 | |||
178 | int regulator_unregister_notifier(struct regulator *regulator, | ||
179 | struct notifier_block *nb); | ||
180 | |||
181 | Regulators use the kernel notifier framework to send event to thier interested | ||
182 | consumers. | ||
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt new file mode 100644 index 000000000000..c9a35665cf70 --- /dev/null +++ b/Documentation/power/regulator/machine.txt | |||
@@ -0,0 +1,101 @@ | |||
1 | Regulator Machine Driver Interface | ||
2 | =================================== | ||
3 | |||
4 | The regulator machine driver interface is intended for board/machine specific | ||
5 | initialisation code to configure the regulator subsystem. Typical things that | ||
6 | machine drivers would do are :- | ||
7 | |||
8 | 1. Regulator -> Device mapping. | ||
9 | 2. Regulator supply configuration. | ||
10 | 3. Power Domain constraint setting. | ||
11 | |||
12 | |||
13 | |||
14 | 1. Regulator -> device mapping | ||
15 | ============================== | ||
16 | Consider the following machine :- | ||
17 | |||
18 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
19 | | | ||
20 | +-> [Consumer B @ 3.3V] | ||
21 | |||
22 | The drivers for consumers A & B must be mapped to the correct regulator in | ||
23 | order to control their power supply. This mapping can be achieved in machine | ||
24 | initialisation code by calling :- | ||
25 | |||
26 | int regulator_set_device_supply(const char *regulator, struct device *dev, | ||
27 | const char *supply); | ||
28 | |||
29 | and is shown with the following code :- | ||
30 | |||
31 | regulator_set_device_supply("Regulator-1", devB, "Vcc"); | ||
32 | regulator_set_device_supply("Regulator-2", devA, "Vcc"); | ||
33 | |||
34 | This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2 | ||
35 | to the 'Vcc' supply for Consumer A. | ||
36 | |||
37 | |||
38 | 2. Regulator supply configuration. | ||
39 | ================================== | ||
40 | Consider the following machine (again) :- | ||
41 | |||
42 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
43 | | | ||
44 | +-> [Consumer B @ 3.3V] | ||
45 | |||
46 | Regulator-1 supplies power to Regulator-2. This relationship must be registered | ||
47 | with the core so that Regulator-1 is also enabled when Consumer A enables it's | ||
48 | supply (Regulator-2). | ||
49 | |||
50 | This relationship can be register with the core via :- | ||
51 | |||
52 | int regulator_set_supply(const char *regulator, const char *regulator_supply); | ||
53 | |||
54 | In this example we would use the following code :- | ||
55 | |||
56 | regulator_set_supply("Regulator-2", "Regulator-1"); | ||
57 | |||
58 | Relationships can be queried by calling :- | ||
59 | |||
60 | const char *regulator_get_supply(const char *regulator); | ||
61 | |||
62 | |||
63 | 3. Power Domain constraint setting. | ||
64 | =================================== | ||
65 | Each power domain within a system has physical constraints on voltage and | ||
66 | current. This must be defined in software so that the power domain is always | ||
67 | operated within specifications. | ||
68 | |||
69 | Consider the following machine (again) :- | ||
70 | |||
71 | Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V] | ||
72 | | | ||
73 | +-> [Consumer B @ 3.3V] | ||
74 | |||
75 | This gives us two regulators and two power domains: | ||
76 | |||
77 | Domain 1: Regulator-2, Consumer B. | ||
78 | Domain 2: Consumer A. | ||
79 | |||
80 | Constraints can be registered by calling :- | ||
81 | |||
82 | int regulator_set_platform_constraints(const char *regulator, | ||
83 | struct regulation_constraints *constraints); | ||
84 | |||
85 | The example is defined as follows :- | ||
86 | |||
87 | struct regulation_constraints domain_1 = { | ||
88 | .min_uV = 3300000, | ||
89 | .max_uV = 3300000, | ||
90 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | ||
91 | }; | ||
92 | |||
93 | struct regulation_constraints domain_2 = { | ||
94 | .min_uV = 1800000, | ||
95 | .max_uV = 2000000, | ||
96 | .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE, | ||
97 | .valid_modes_mask = REGULATOR_MODE_NORMAL, | ||
98 | }; | ||
99 | |||
100 | regulator_set_platform_constraints("Regulator-1", &domain_1); | ||
101 | regulator_set_platform_constraints("Regulator-2", &domain_2); | ||
diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt new file mode 100644 index 000000000000..bdcb332bd7fb --- /dev/null +++ b/Documentation/power/regulator/overview.txt | |||
@@ -0,0 +1,171 @@ | |||
1 | Linux voltage and current regulator framework | ||
2 | ============================================= | ||
3 | |||
4 | About | ||
5 | ===== | ||
6 | |||
7 | This framework is designed to provide a standard kernel interface to control | ||
8 | voltage and current regulators. | ||
9 | |||
10 | The intention is to allow systems to dynamically control regulator power output | ||
11 | in order to save power and prolong battery life. This applies to both voltage | ||
12 | regulators (where voltage output is controllable) and current sinks (where | ||
13 | current limit is controllable). | ||
14 | |||
15 | (C) 2008 Wolfson Microelectronics PLC. | ||
16 | Author: Liam Girdwood <lg@opensource.wolfsonmicro.com> | ||
17 | |||
18 | |||
19 | Nomenclature | ||
20 | ============ | ||
21 | |||
22 | Some terms used in this document:- | ||
23 | |||
24 | o Regulator - Electronic device that supplies power to other devices. | ||
25 | Most regulators can enable and disable their output whilst | ||
26 | some can control their output voltage and or current. | ||
27 | |||
28 | Input Voltage -> Regulator -> Output Voltage | ||
29 | |||
30 | |||
31 | o PMIC - Power Management IC. An IC that contains numerous regulators | ||
32 | and often contains other susbsystems. | ||
33 | |||
34 | |||
35 | o Consumer - Electronic device that is supplied power by a regulator. | ||
36 | Consumers can be classified into two types:- | ||
37 | |||
38 | Static: consumer does not change it's supply voltage or | ||
39 | current limit. It only needs to enable or disable it's | ||
40 | power supply. It's supply voltage is set by the hardware, | ||
41 | bootloader, firmware or kernel board initialisation code. | ||
42 | |||
43 | Dynamic: consumer needs to change it's supply voltage or | ||
44 | current limit to meet operation demands. | ||
45 | |||
46 | |||
47 | o Power Domain - Electronic circuit that is supplied it's input power by the | ||
48 | output power of a regulator, switch or by another power | ||
49 | domain. | ||
50 | |||
51 | The supply regulator may be behind a switch(s). i.e. | ||
52 | |||
53 | Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A] | ||
54 | | | | ||
55 | | +-> [Consumer B], [Consumer C] | ||
56 | | | ||
57 | +-> [Consumer D], [Consumer E] | ||
58 | |||
59 | That is one regulator and three power domains: | ||
60 | |||
61 | Domain 1: Switch-1, Consumers D & E. | ||
62 | Domain 2: Switch-2, Consumers B & C. | ||
63 | Domain 3: Consumer A. | ||
64 | |||
65 | and this represents a "supplies" relationship: | ||
66 | |||
67 | Domain-1 --> Domain-2 --> Domain-3. | ||
68 | |||
69 | A power domain may have regulators that are supplied power | ||
70 | by other regulators. i.e. | ||
71 | |||
72 | Regulator-1 -+-> Regulator-2 -+-> [Consumer A] | ||
73 | | | ||
74 | +-> [Consumer B] | ||
75 | |||
76 | This gives us two regulators and two power domains: | ||
77 | |||
78 | Domain 1: Regulator-2, Consumer B. | ||
79 | Domain 2: Consumer A. | ||
80 | |||
81 | and a "supplies" relationship: | ||
82 | |||
83 | Domain-1 --> Domain-2 | ||
84 | |||
85 | |||
86 | o Constraints - Constraints are used to define power levels for performance | ||
87 | and hardware protection. Constraints exist at three levels: | ||
88 | |||
89 | Regulator Level: This is defined by the regulator hardware | ||
90 | operating parameters and is specified in the regulator | ||
91 | datasheet. i.e. | ||
92 | |||
93 | - voltage output is in the range 800mV -> 3500mV. | ||
94 | - regulator current output limit is 20mA @ 5V but is | ||
95 | 10mA @ 10V. | ||
96 | |||
97 | Power Domain Level: This is defined in software by kernel | ||
98 | level board initialisation code. It is used to constrain a | ||
99 | power domain to a particular power range. i.e. | ||
100 | |||
101 | - Domain-1 voltage is 3300mV | ||
102 | - Domain-2 voltage is 1400mV -> 1600mV | ||
103 | - Domain-3 current limit is 0mA -> 20mA. | ||
104 | |||
105 | Consumer Level: This is defined by consumer drivers | ||
106 | dynamically setting voltage or current limit levels. | ||
107 | |||
108 | e.g. a consumer backlight driver asks for a current increase | ||
109 | from 5mA to 10mA to increase LCD illumination. This passes | ||
110 | to through the levels as follows :- | ||
111 | |||
112 | Consumer: need to increase LCD brightness. Lookup and | ||
113 | request next current mA value in brightness table (the | ||
114 | consumer driver could be used on several different | ||
115 | personalities based upon the same reference device). | ||
116 | |||
117 | Power Domain: is the new current limit within the domain | ||
118 | operating limits for this domain and system state (e.g. | ||
119 | battery power, USB power) | ||
120 | |||
121 | Regulator Domains: is the new current limit within the | ||
122 | regulator operating parameters for input/ouput voltage. | ||
123 | |||
124 | If the regulator request passes all the constraint tests | ||
125 | then the new regulator value is applied. | ||
126 | |||
127 | |||
128 | Design | ||
129 | ====== | ||
130 | |||
131 | The framework is designed and targeted at SoC based devices but may also be | ||
132 | relevant to non SoC devices and is split into the following four interfaces:- | ||
133 | |||
134 | |||
135 | 1. Consumer driver interface. | ||
136 | |||
137 | This uses a similar API to the kernel clock interface in that consumer | ||
138 | drivers can get and put a regulator (like they can with clocks atm) and | ||
139 | get/set voltage, current limit, mode, enable and disable. This should | ||
140 | allow consumers complete control over their supply voltage and current | ||
141 | limit. This also compiles out if not in use so drivers can be reused in | ||
142 | systems with no regulator based power control. | ||
143 | |||
144 | See Documentation/power/regulator/consumer.txt | ||
145 | |||
146 | 2. Regulator driver interface. | ||
147 | |||
148 | This allows regulator drivers to register their regulators and provide | ||
149 | operations to the core. It also has a notifier call chain for propagating | ||
150 | regulator events to clients. | ||
151 | |||
152 | See Documentation/power/regulator/regulator.txt | ||
153 | |||
154 | 3. Machine interface. | ||
155 | |||
156 | This interface is for machine specific code and allows the creation of | ||
157 | voltage/current domains (with constraints) for each regulator. It can | ||
158 | provide regulator constraints that will prevent device damage through | ||
159 | overvoltage or over current caused by buggy client drivers. It also | ||
160 | allows the creation of a regulator tree whereby some regulators are | ||
161 | supplied by others (similar to a clock tree). | ||
162 | |||
163 | See Documentation/power/regulator/machine.txt | ||
164 | |||
165 | 4. Userspace ABI. | ||
166 | |||
167 | The framework also exports a lot of useful voltage/current/opmode data to | ||
168 | userspace via sysfs. This could be used to help monitor device power | ||
169 | consumption and status. | ||
170 | |||
171 | See Documentation/ABI/testing/regulator-sysfs.txt | ||
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt new file mode 100644 index 000000000000..a69050143592 --- /dev/null +++ b/Documentation/power/regulator/regulator.txt | |||
@@ -0,0 +1,30 @@ | |||
1 | Regulator Driver Interface | ||
2 | ========================== | ||
3 | |||
4 | The regulator driver interface is relatively simple and designed to allow | ||
5 | regulator drivers to register their services with the core framework. | ||
6 | |||
7 | |||
8 | Registration | ||
9 | ============ | ||
10 | |||
11 | Drivers can register a regulator by calling :- | ||
12 | |||
13 | struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, | ||
14 | void *reg_data); | ||
15 | |||
16 | This will register the regulators capabilities and operations the regulator | ||
17 | core. The core does not touch reg_data (private to regulator driver). | ||
18 | |||
19 | Regulators can be unregistered by calling :- | ||
20 | |||
21 | void regulator_unregister(struct regulator_dev *rdev); | ||
22 | |||
23 | |||
24 | Regulator Events | ||
25 | ================ | ||
26 | Regulators can send events (e.g. over temp, under voltage, etc) to consumer | ||
27 | drivers by calling :- | ||
28 | |||
29 | int regulator_notifier_call_chain(struct regulator_dev *rdev, | ||
30 | unsigned long event, void *data); | ||
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 3be84aa38dfe..29d839ce7327 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX | |||
@@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt | |||
20 | - MPC5200 Device Tree Bindings | 20 | - MPC5200 Device Tree Bindings |
21 | ppc_htab.txt | 21 | ppc_htab.txt |
22 | - info about the Linux/PPC /proc/ppc_htab entry | 22 | - info about the Linux/PPC /proc/ppc_htab entry |
23 | SBC8260_memory_mapping.txt | ||
24 | - EST SBC8260 board info | ||
25 | smp.txt | 23 | smp.txt |
26 | - use and state info about Linux/PPC on MP machines | 24 | - use and state info about Linux/PPC on MP machines |
27 | sound.txt | 25 | sound.txt |
diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt deleted file mode 100644 index e6e9ee0506c3..000000000000 --- a/Documentation/powerpc/SBC8260_memory_mapping.txt +++ /dev/null | |||
@@ -1,197 +0,0 @@ | |||
1 | Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com) | ||
2 | if you have questions, comments or corrections. | ||
3 | |||
4 | * EST SBC8260 Linux memory mapping rules | ||
5 | |||
6 | http://www.estc.com/ | ||
7 | http://www.estc.com/products/boards/SBC8260-8240_ds.html | ||
8 | |||
9 | Initial conditions: | ||
10 | ------------------- | ||
11 | |||
12 | Tasks that need to be perform by the boot ROM before control is | ||
13 | transferred to zImage (compressed Linux kernel): | ||
14 | |||
15 | - Define the IMMR to 0xf0000000 | ||
16 | |||
17 | - Initialize the memory controller so that RAM is available at | ||
18 | physical address 0x00000000. On the SBC8260 is this 16M (64M) | ||
19 | SDRAM. | ||
20 | |||
21 | - The boot ROM should only clear the RAM that it is using. | ||
22 | |||
23 | The reason for doing this is to enhances the chances of a | ||
24 | successful post mortem on a Linux panic. One of the first | ||
25 | items to examine is the 16k (LOG_BUF_LEN) circular console | ||
26 | buffer called log_buf which is defined in kernel/printk.c. | ||
27 | |||
28 | - To enhance boot ROM performance, the I-cache can be enabled. | ||
29 | |||
30 | Date: Mon, 22 May 2000 14:21:10 -0700 | ||
31 | From: Neil Russell <caret@c-side.com> | ||
32 | |||
33 | LiMon (LInux MONitor) runs with and starts Linux with MMU | ||
34 | off, I-cache enabled, D-cache disabled. The I-cache doesn't | ||
35 | need hints from the MMU to work correctly as the D-cache | ||
36 | does. No D-cache means no special code to handle devices in | ||
37 | the presence of cache (no snooping, etc). The use of the | ||
38 | I-cache means that the monitor can run acceptably fast | ||
39 | directly from ROM, rather than having to copy it to RAM. | ||
40 | |||
41 | - Build the board information structure (see | ||
42 | include/asm-ppc/est8260.h for its definition) | ||
43 | |||
44 | - The compressed Linux kernel (zImage) contains a bootstrap loader | ||
45 | that is position independent; you can load it into any RAM, | ||
46 | ROM or FLASH memory address >= 0x00500000 (above 5 MB), or | ||
47 | at its link address of 0x00400000 (4 MB). | ||
48 | |||
49 | Note: If zImage is loaded at its link address of 0x00400000 (4 MB), | ||
50 | then zImage will skip the step of moving itself to | ||
51 | its link address. | ||
52 | |||
53 | - Load R3 with the address of the board information structure | ||
54 | |||
55 | - Transfer control to zImage | ||
56 | |||
57 | - The Linux console port is SMC1, and the baud rate is controlled | ||
58 | from the bi_baudrate field of the board information structure. | ||
59 | On thing to keep in mind when picking the baud rate, is that | ||
60 | there is no flow control on the SMC ports. I would stick | ||
61 | with something safe and standard like 19200. | ||
62 | |||
63 | On the EST SBC8260, the SMC1 port is on the COM1 connector of | ||
64 | the board. | ||
65 | |||
66 | |||
67 | EST SBC8260 defaults: | ||
68 | --------------------- | ||
69 | |||
70 | Chip | ||
71 | Memory Sel Bus Use | ||
72 | --------------------- --- --- ---------------------------------- | ||
73 | 0x00000000-0x03FFFFFF CS2 60x (16M or 64M)/64M SDRAM | ||
74 | 0x04000000-0x04FFFFFF CS4 local 4M/16M SDRAM (soldered to the board) | ||
75 | 0x21000000-0x21000000 CS7 60x 1B/64K Flash present detect (from the flash SIMM) | ||
76 | 0x21000001-0x21000001 CS7 60x 1B/64K Switches (read) and LEDs (write) | ||
77 | 0x22000000-0x2200FFFF CS5 60x 8K/64K EEPROM | ||
78 | 0xFC000000-0xFCFFFFFF CS6 60x 2M/16M flash (8 bits wide, soldered to the board) | ||
79 | 0xFE000000-0xFFFFFFFF CS0 60x 4M/16M flash (SIMM) | ||
80 | |||
81 | Notes: | ||
82 | ------ | ||
83 | |||
84 | - The chip selects can map 32K blocks and up (powers of 2) | ||
85 | |||
86 | - The SDRAM machine can handled up to 128Mbytes per chip select | ||
87 | |||
88 | - Linux uses the 60x bus memory (the SDRAM DIMM) for the | ||
89 | communications buffers. | ||
90 | |||
91 | - BATs can map 128K-256Mbytes each. There are four data BATs and | ||
92 | four instruction BATs. Generally the data and instruction BATs | ||
93 | are mapped the same. | ||
94 | |||
95 | - The IMMR must be set above the kernel virtual memory addresses, | ||
96 | which start at 0xC0000000. Otherwise, the kernel may crash as | ||
97 | soon as you start any threads or processes due to VM collisions | ||
98 | in the kernel or user process space. | ||
99 | |||
100 | |||
101 | Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999: | ||
102 | |||
103 | The user application virtual space consumes the first 2 Gbytes | ||
104 | (0x00000000 to 0x7FFFFFFF). The kernel virtual text starts at | ||
105 | 0xC0000000, with data following. There is a "protection hole" | ||
106 | between the end of kernel data and the start of the kernel | ||
107 | dynamically allocated space, but this space is still within | ||
108 | 0xCxxxxxxx. | ||
109 | |||
110 | Obviously the kernel can't map any physical addresses 1:1 in | ||
111 | these ranges. | ||
112 | |||
113 | |||
114 | Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000: | ||
115 | |||
116 | During the early kernel initialization, the kernel virtual | ||
117 | memory allocator is not operational. Prior to this KVM | ||
118 | initialization, we choose to map virtual to physical addresses | ||
119 | 1:1. That is, the kernel virtual address exactly matches the | ||
120 | physical address on the bus. These mappings are typically done | ||
121 | in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c. Only | ||
122 | absolutely necessary mappings should be done at this time, for | ||
123 | example board control registers or a serial uart. Normal device | ||
124 | driver initialization should map resources later when necessary. | ||
125 | |||
126 | Although platform dependent, and certainly the case for embedded | ||
127 | 8xx, traditionally memory is mapped at physical address zero, | ||
128 | and I/O devices above physical address 0x80000000. The lowest | ||
129 | and highest (above 0xf0000000) I/O addresses are traditionally | ||
130 | used for devices or registers we need to map during kernel | ||
131 | initialization and prior to KVM operation. For this reason, | ||
132 | and since it followed prior PowerPC platform examples, I chose | ||
133 | to map the embedded 8xx kernel to the 0xc0000000 virtual address. | ||
134 | This way, we can enable the MMU to map the kernel for proper | ||
135 | operation, and still map a few windows before the KVM is operational. | ||
136 | |||
137 | On some systems, you could possibly run the kernel at the | ||
138 | 0x80000000 or any other virtual address. It just depends upon | ||
139 | mapping that must be done prior to KVM operational. You can never | ||
140 | map devices or kernel spaces that overlap with the user virtual | ||
141 | space. This is why default IMMR mapping used by most BDM tools | ||
142 | won't work. They put the IMMR at something like 0x10000000 or | ||
143 | 0x02000000 for example. You simply can't map these addresses early | ||
144 | in the kernel, and continue proper system operation. | ||
145 | |||
146 | The embedded 8xx/82xx kernel is mature enough that all you should | ||
147 | need to do is map the IMMR someplace at or above 0xf0000000 and it | ||
148 | should boot far enough to get serial console messages and KGDB | ||
149 | connected on any platform. There are lots of other subtle memory | ||
150 | management design features that you simply don't need to worry | ||
151 | about. If you are changing functions related to MMU initialization, | ||
152 | you are likely breaking things that are known to work and are | ||
153 | heading down a path of disaster and frustration. Your changes | ||
154 | should be to make the flexibility of the processor fit Linux, | ||
155 | not force arbitrary and non-workable memory mappings into Linux. | ||
156 | |||
157 | - You don't want to change KERNELLOAD or KERNELBASE, otherwise the | ||
158 | virtual memory and MMU code will get confused. | ||
159 | |||
160 | arch/ppc/Makefile:KERNELLOAD = 0xc0000000 | ||
161 | |||
162 | include/asm-ppc/page.h:#define PAGE_OFFSET 0xc0000000 | ||
163 | include/asm-ppc/page.h:#define KERNELBASE PAGE_OFFSET | ||
164 | |||
165 | - RAM is at physical address 0x00000000, and gets mapped to | ||
166 | virtual address 0xC0000000 for the kernel. | ||
167 | |||
168 | |||
169 | Physical addresses used by the Linux kernel: | ||
170 | -------------------------------------------- | ||
171 | |||
172 | 0x00000000-0x3FFFFFFF 1GB reserved for RAM | ||
173 | 0xF0000000-0xF001FFFF 128K IMMR 64K used for dual port memory, | ||
174 | 64K for 8260 registers | ||
175 | |||
176 | |||
177 | Logical addresses used by the Linux kernel: | ||
178 | ------------------------------------------- | ||
179 | |||
180 | 0xF0000000-0xFFFFFFFF 256M BAT0 (IMMR: dual port RAM, registers) | ||
181 | 0xE0000000-0xEFFFFFFF 256M BAT1 (I/O space for custom boards) | ||
182 | 0xC0000000-0xCFFFFFFF 256M BAT2 (RAM) | ||
183 | 0xD0000000-0xDFFFFFFF 256M BAT3 (if RAM > 256MByte) | ||
184 | |||
185 | |||
186 | EST SBC8260 Linux mapping: | ||
187 | -------------------------- | ||
188 | |||
189 | DBAT0, IBAT0, cache inhibited: | ||
190 | |||
191 | Chip | ||
192 | Memory Sel Use | ||
193 | --------------------- --- --------------------------------- | ||
194 | 0xF0000000-0xF001FFFF n/a IMMR: dual port RAM, registers | ||
195 | |||
196 | DBAT1, IBAT1, cache inhibited: | ||
197 | |||
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 928a79ceb7aa..de4063cb4fdc 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt | |||
@@ -278,7 +278,7 @@ it with special cases. | |||
278 | a 64-bit platform. | 278 | a 64-bit platform. |
279 | 279 | ||
280 | d) request and get assigned a platform number (see PLATFORM_* | 280 | d) request and get assigned a platform number (see PLATFORM_* |
281 | constants in include/asm-powerpc/processor.h | 281 | constants in arch/powerpc/include/asm/processor.h |
282 | 282 | ||
283 | 32-bit embedded kernels: | 283 | 32-bit embedded kernels: |
284 | 284 | ||
@@ -340,7 +340,7 @@ the block to RAM before passing it to the kernel. | |||
340 | --------- | 340 | --------- |
341 | 341 | ||
342 | The kernel is entered with r3 pointing to an area of memory that is | 342 | The kernel is entered with r3 pointing to an area of memory that is |
343 | roughly described in include/asm-powerpc/prom.h by the structure | 343 | roughly described in arch/powerpc/include/asm/prom.h by the structure |
344 | boot_param_header: | 344 | boot_param_header: |
345 | 345 | ||
346 | struct boot_param_header { | 346 | struct boot_param_header { |
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt index b35f3482e3e4..2ea76d9d137c 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt | |||
@@ -7,6 +7,15 @@ Currently defined compatibles: | |||
7 | - fsl,cpm2-scc-uart | 7 | - fsl,cpm2-scc-uart |
8 | - fsl,qe-uart | 8 | - fsl,qe-uart |
9 | 9 | ||
10 | Modem control lines connected to GPIO controllers are listed in the gpios | ||
11 | property as described in booting-without-of.txt, section IX.1 in the following | ||
12 | order: | ||
13 | |||
14 | CTS, RTS, DCD, DSR, DTR, and RI. | ||
15 | |||
16 | The gpios property is optional and can be left out when control lines are | ||
17 | not used. | ||
18 | |||
10 | Example: | 19 | Example: |
11 | 20 | ||
12 | serial@11a00 { | 21 | serial@11a00 { |
@@ -18,4 +27,6 @@ Example: | |||
18 | interrupt-parent = <&PIC>; | 27 | interrupt-parent = <&PIC>; |
19 | fsl,cpm-brg = <1>; | 28 | fsl,cpm-brg = <1>; |
20 | fsl,cpm-command = <00800000>; | 29 | fsl,cpm-command = <00800000>; |
30 | gpios = <&gpio_c 15 0 | ||
31 | &gpio_d 29 0>; | ||
21 | }; | 32 | }; |
diff --git a/Documentation/powerpc/eeh-pci-error-recovery.txt b/Documentation/powerpc/eeh-pci-error-recovery.txt index df7afe43d462..9d4e33df624c 100644 --- a/Documentation/powerpc/eeh-pci-error-recovery.txt +++ b/Documentation/powerpc/eeh-pci-error-recovery.txt | |||
@@ -133,7 +133,7 @@ error. Given an arbitrary address, the routine | |||
133 | pci_get_device_by_addr() will find the pci device associated | 133 | pci_get_device_by_addr() will find the pci device associated |
134 | with that address (if any). | 134 | with that address (if any). |
135 | 135 | ||
136 | The default include/asm-powerpc/io.h macros readb(), inb(), insb(), | 136 | The default arch/powerpc/include/asm/io.h macros readb(), inb(), insb(), |
137 | etc. include a check to see if the i/o read returned all-0xff's. | 137 | etc. include a check to see if the i/o read returned all-0xff's. |
138 | If so, these make a call to eeh_dn_check_failure(), which in turn | 138 | If so, these make a call to eeh_dn_check_failure(), which in turn |
139 | asks the firmware if the all-ff's value is the sign of a true EEH | 139 | asks the firmware if the all-ff's value is the sign of a true EEH |
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index 0843ed0163a5..28b6ec87c642 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt | |||
@@ -390,9 +390,10 @@ rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft | |||
390 | rfkill input line is active. Only if none of the rfkill input lines are | 390 | rfkill input line is active. Only if none of the rfkill input lines are |
391 | active, will it return RFKILL_STATE_UNBLOCKED. | 391 | active, will it return RFKILL_STATE_UNBLOCKED. |
392 | 392 | ||
393 | If it doesn't implement the get_state() hook, it must make sure that its calls | 393 | Since the device has a hardware rfkill line, it IS subject to state changes |
394 | to rfkill_force_state() are enough to keep the status always up-to-date, and it | 394 | external to rfkill. Therefore, the driver must make sure that it calls |
395 | must do a rfkill_force_state() on resume from sleep. | 395 | rfkill_force_state() to keep the status always up-to-date, and it must do a |
396 | rfkill_force_state() on resume from sleep. | ||
396 | 397 | ||
397 | Every time the driver gets a notification from the card that one of its rfkill | 398 | Every time the driver gets a notification from the card that one of its rfkill |
398 | lines changed state (polling might be needed on badly designed cards that don't | 399 | lines changed state (polling might be needed on badly designed cards that don't |
@@ -422,13 +423,24 @@ of the hardware is unknown), or read-write (where the hardware can be queried | |||
422 | about its current state). | 423 | about its current state). |
423 | 424 | ||
424 | The rfkill class will call the get_state hook of a device every time it needs | 425 | The rfkill class will call the get_state hook of a device every time it needs |
425 | to know the *real* current state of the hardware. This can happen often. | 426 | to know the *real* current state of the hardware. This can happen often, but |
427 | it does not do any polling, so it is not enough on hardware that is subject | ||
428 | to state changes outside of the rfkill subsystem. | ||
429 | |||
430 | Therefore, calling rfkill_force_state() when a state change happens is | ||
431 | mandatory when the device has a hardware rfkill line, or when something else | ||
432 | like the firmware could cause its state to be changed without going through the | ||
433 | rfkill class. | ||
426 | 434 | ||
427 | Some hardware provides events when its status changes. In these cases, it is | 435 | Some hardware provides events when its status changes. In these cases, it is |
428 | best for the driver to not provide a get_state hook, and instead register the | 436 | best for the driver to not provide a get_state hook, and instead register the |
429 | rfkill class *already* with the correct status, and keep it updated using | 437 | rfkill class *already* with the correct status, and keep it updated using |
430 | rfkill_force_state() when it gets an event from the hardware. | 438 | rfkill_force_state() when it gets an event from the hardware. |
431 | 439 | ||
440 | rfkill_force_state() must be used on the device resume handlers to update the | ||
441 | rfkill status, should there be any chance of the device status changing during | ||
442 | the sleep. | ||
443 | |||
432 | There is no provision for a statically-allocated rfkill struct. You must | 444 | There is no provision for a statically-allocated rfkill struct. You must |
433 | use rfkill_allocate() to allocate one. | 445 | use rfkill_allocate() to allocate one. |
434 | 446 | ||
diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 index 86d1c8e7b18f..eedc399e8deb 100644 --- a/Documentation/video4linux/CARDLIST.au0828 +++ b/Documentation/video4linux/CARDLIST.au0828 | |||
@@ -2,3 +2,4 @@ | |||
2 | 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008] | 2 | 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008] |
3 | 2 -> Hauppauge HVR850 (au0828) [2040:7240] | 3 | 2 -> Hauppauge HVR850 (au0828) [2040:7240] |
4 | 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] | 4 | 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] |
5 | 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281] | ||
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 10591467ef16..89c7f32abf9f 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx | |||
@@ -1,11 +1,11 @@ | |||
1 | 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] | 1 | 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] |
2 | 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2750,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] | 2 | 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] |
3 | 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] | 3 | 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] |
4 | 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] | 4 | 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] |
5 | 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] | 5 | 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] |
6 | 5 -> MSI VOX USB 2.0 (em2820/em2840) | 6 | 5 -> MSI VOX USB 2.0 (em2820/em2840) |
7 | 6 -> Terratec Cinergy 200 USB (em2800) | 7 | 6 -> Terratec Cinergy 200 USB (em2800) |
8 | 7 -> Leadtek Winfast USB II (em2800) | 8 | 7 -> Leadtek Winfast USB II (em2800) [0413:6023] |
9 | 8 -> Kworld USB2800 (em2800) | 9 | 8 -> Kworld USB2800 (em2800) |
10 | 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] | 10 | 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] |
11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] | 11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] |
@@ -14,7 +14,46 @@ | |||
14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] | 14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] |
15 | 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) | 15 | 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) |
16 | 15 -> V-Gear PocketTV (em2800) | 16 | 15 -> V-Gear PocketTV (em2800) |
17 | 16 -> Hauppauge WinTV HVR 950 (em2880) [2040:6513,2040:6517,2040:651b,2040:651f] | 17 | 16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b,2040:651f] |
18 | 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] | 18 | 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] |
19 | 18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502] | 19 | 18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502] |
20 | 19 -> PointNix Intra-Oral Camera (em2860) | 20 | 19 -> PointNix Intra-Oral Camera (em2860) |
21 | 20 -> AMD ATI TV Wonder HD 600 (em2880) [0438:b002] | ||
22 | 21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder (em2800) [eb1a:2801] | ||
23 | 22 -> Unknown EM2750/EM2751 webcam grabber (em2750) [eb1a:2750,eb1a:2751] | ||
24 | 23 -> Huaqi DLCW-130 (em2750) | ||
25 | 24 -> D-Link DUB-T210 TV Tuner (em2820/em2840) [2001:f112] | ||
26 | 25 -> Gadmei UTV310 (em2820/em2840) | ||
27 | 26 -> Hercules Smart TV USB 2.0 (em2820/em2840) | ||
28 | 27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) (em2820/em2840) | ||
29 | 28 -> Leadtek Winfast USB II Deluxe (em2820/em2840) | ||
30 | 29 -> Pinnacle Dazzle DVC 100 (em2820/em2840) | ||
31 | 30 -> Videology 20K14XUSB USB2.0 (em2820/em2840) | ||
32 | 31 -> Usbgear VD204v9 (em2821) | ||
33 | 32 -> Supercomp USB 2.0 TV (em2821) | ||
34 | 33 -> SIIG AVTuner-PVR/Prolink PlayTV USB 2.0 (em2821) | ||
35 | 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] | ||
36 | 35 -> Typhoon DVD Maker (em2860) | ||
37 | 36 -> NetGMBH Cam (em2860) | ||
38 | 37 -> Gadmei UTV330 (em2860) | ||
39 | 38 -> Yakumo MovieMixer (em2861) | ||
40 | 39 -> KWorld PVRTV 300U (em2861) [eb1a:e300] | ||
41 | 40 -> Plextor ConvertX PX-TV100U (em2861) [093b:a005] | ||
42 | 41 -> Kworld 350 U DVB-T (em2870) [eb1a:e350] | ||
43 | 42 -> Kworld 355 U DVB-T (em2870) [eb1a:e355,eb1a:e357] | ||
44 | 43 -> Terratec Cinergy T XS (em2870) [0ccd:0043] | ||
45 | 44 -> Terratec Cinergy T XS (MT2060) (em2870) | ||
46 | 45 -> Pinnacle PCTV DVB-T (em2870) | ||
47 | 46 -> Compro, VideoMate U3 (em2870) [185b:2870] | ||
48 | 47 -> KWorld DVB-T 305U (em2880) [eb1a:e305] | ||
49 | 48 -> KWorld DVB-T 310U (em2880) | ||
50 | 49 -> MSI DigiVox A/D (em2880) [eb1a:e310] | ||
51 | 50 -> MSI DigiVox A/D II (em2880) [eb1a:e320] | ||
52 | 51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c] | ||
53 | 52 -> DNT DA2 Hybrid (em2881) | ||
54 | 53 -> Pinnacle Hybrid Pro (em2881) | ||
55 | 54 -> Kworld VS-DVB-T 323UR (em2882) [eb1a:e323] | ||
56 | 55 -> Terratec Hybrid XS (em2882) (em2882) [0ccd:005e] | ||
57 | 56 -> Pinnacle Hybrid Pro (2) (em2882) [2304:0226] | ||
58 | 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] | ||
59 | 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] | ||
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 0c4880af57a3..bcaf4ab383be 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt | |||
@@ -1,4 +1,4 @@ | |||
1 | List of the webcams know by gspca. | 1 | List of the webcams known by gspca. |
2 | 2 | ||
3 | The modules are: | 3 | The modules are: |
4 | gspca_main main driver | 4 | gspca_main main driver |