* pm-cpufreq-fixes: cpufreq: intel_pstate: Always set max P-state in performance mode cpufreq: intel_pstate: Set P-state upfront in performance mode * pm-sleep-fixes: PM / suspend: Fix missing KERN_CONT for suspend message
Unified · Split
| @@ -0,0 +1,2 @@ | ||
| 1 | +*.c diff=cpp | |
| 2 | +*.h diff=cpp | |
| @@ -69,11 +69,14 @@ James Bottomley <jejb@mulgrave.(none)> · 68 unmodified lines | ||
| 69 | 69 | James Bottomley <jejb@titanic.il.steeleye.com> |
| 70 | 70 | James E Wilson <wilson@specifix.com> |
| 71 | 71 | James Ketrenos <jketreno@io.(none)> |
| 72 | +Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com> | |
| 72 | 73 | <javier@osg.samsung.com> <javier.martinez@collabora.co.uk> |
| 73 | 74 | Jean Tourrilhes <jt@hpl.hp.com> |
| 74 | 75 | Jeff Garzik <jgarzik@pretzel.yyz.us> |
| 75 | 76 | Jens Axboe <axboe@suse.de> |
| 76 | 77 | Jens Osterkamp <Jens.Osterkamp@de.ibm.com> |
| 78 | +Johan Hovold <johan@kernel.org> <jhovold@gmail.com> | |
| 79 | +Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com> | |
| 77 | 80 | John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> |
| 78 | 81 | John Stultz <johnstul@us.ibm.com> |
| 79 | 82 | <josh@joshtriplett.org> <josh@freedesktop.org> |
| @@ -88,6 +91,7 @@ Kay Sievers <kay.sievers@vrfy.org> · 8 unmodified lines | ||
| 88 | 91 | Kenneth W Chen <kenneth.w.chen@intel.com> |
| 89 | 92 | Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com> |
| 90 | 93 | Koushik <raghavendra.koushik@neterion.com> |
| 94 | +Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com> | |
| 91 | 95 | Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com> |
| 92 | 96 | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> |
| 93 | 97 | Leonid I Ananiev <leonid.i.ananiev@intel.com> |
| @@ -123,6 +127,7 @@ Peter Oruba <peter@oruba.de> · 29 unmodified lines | ||
| 123 | 127 | Peter Oruba <peter.oruba@amd.com> |
| 124 | 128 | Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com> |
| 125 | 129 | Praveen BP <praveenbp@ti.com> |
| 130 | +Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com> | |
| 126 | 131 | Rajesh Shah <rajesh.shah@intel.com> |
| 127 | 132 | Ralf Baechle <ralf@linux-mips.org> |
| 128 | 133 | Ralf Wildenhues <Ralf.Wildenhues@gmx.de> |
| @@ -158,6 +163,7 @@ Valdis Kletnieks <Valdis.Kletnieks@vt.edu> · 29 unmodified lines | ||
| 158 | 163 | Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com> |
| 159 | 164 | Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com> |
| 160 | 165 | Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com> |
| 166 | +Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com> | |
| 161 | 167 | Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com> |
| 162 | 168 | Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com> |
| 163 | 169 | Takashi YOSHII <takashi.yoshii.zj@renesas.com> |
| @@ -1090,6 +1090,10 @@ S: 6350 Stoneridge Mall Road · 1089 unmodified lines | ||
| 1090 | 1090 | S: Pleasanton, CA 94588 |
| 1091 | 1091 | S: USA |
| 1092 | 1092 | |
| 1093 | +N: Dmitry Eremin-Solenikov | |
| 1094 | +E: dbaryshkov@gmail.com | |
| 1095 | +D: Power Supply Maintainer from v3.14 - v3.15 | |
| 1096 | + | |
| 1093 | 1097 | N: Doug Evans |
| 1094 | 1098 | E: dje@cygnus.com |
| 1095 | 1099 | D: Wrote Xenix FS (part of standard kernel since 0.99.15) |
| @@ -1944,6 +1948,11 @@ E: kraxel@bytesex.org · 848 unmodified lines | ||
| 1944 | 1948 | E: kraxel@suse.de |
| 1945 | 1949 | D: video4linux, bttv, vesafb, some scsi, misc fixes |
| 1946 | 1950 | |
| 1951 | +N: Hans J. Koch | |
| 1952 | +D: USERSPACE I/O, MAX6650 | |
| 1953 | +D: Hans passed away in June 2016, and will be greatly missed. | |
| 1954 | +W: https://lwn.net/Articles/691000/ | |
| 1955 | + | |
| 1947 | 1956 | N: Harald Koenig |
| 1948 | 1957 | E: koenig@tat.physik.uni-tuebingen.de |
| 1949 | 1958 | D: XFree86 (S3), DCF77, some kernel hacks and fixes |
| @@ -2287,11 +2296,11 @@ D: Initial implementation of VC's, pty's and select() · 337 unmodified lines | ||
| 2287 | 2296 | |
| 2288 | 2297 | N: Pavel Machek |
| 2289 | 2298 | E: pavel@ucw.cz |
| 2290 | −D: Softcursor for vga, hypertech cdrom support, vcsa bugfix, nbd | |
| 2299 | +P: 4096R/92DFCE96 4FA7 9EEF FCD4 C44F C585 B8C7 C060 2241 92DF CE96 | |
| 2300 | +D: Softcursor for vga, hypertech cdrom support, vcsa bugfix, nbd, | |
| 2291 | 2301 | D: sun4/330 port, capabilities for elf, speedup for rm on ext2, USB, |
| 2292 | −D: work on suspend-to-ram/disk, killing duplicates from ioctl32 | |
| 2293 | −S: Volkova 1131 | |
| 2294 | −S: 198 00 Praha 9 | |
| 2302 | +D: work on suspend-to-ram/disk, killing duplicates from ioctl32, | |
| 2303 | +D: Altera SoCFPGA and Nokia N900 support. | |
| 2295 | 2304 | S: Czech Republic |
| 2296 | 2305 | |
| 2297 | 2306 | N: Paul Mackerras |
| @@ -3518,6 +3527,10 @@ S: 145 Howard St. · 1220 unmodified lines | ||
| 3518 | 3527 | S: Northborough, MA 01532 |
| 3519 | 3528 | S: USA |
| 3520 | 3529 | |
| 3530 | +N: Doug Thompson | |
| 3531 | +E: dougthompson@xmission.com | |
| 3532 | +D: EDAC | |
| 3533 | + | |
| 3521 | 3534 | N: Tommy Thorn |
| 3522 | 3535 | E: Tommy.Thorn@irisa.fr |
| 3523 | 3536 | W: http://www.irisa.fr/prive/thorn/index.html |
| @@ -3654,6 +3667,10 @@ S: Obere Heerbergstrasse 17 · 130 unmodified lines | ||
| 3654 | 3667 | S: 97078 Wuerzburg |
| 3655 | 3668 | S: Germany |
| 3656 | 3669 | |
| 3670 | +N: Jason Uhlenkott | |
| 3671 | +E: juhlenko@akamai.com | |
| 3672 | +D: I3000 EDAC driver | |
| 3673 | + | |
| 3657 | 3674 | N: Greg Ungerer |
| 3658 | 3675 | E: gerg@snapgear.com |
| 3659 | 3676 | D: uClinux kernel hacker |
| @@ -3691,7 +3708,7 @@ S: Germany · 31 unmodified lines | ||
| 3691 | 3708 | N: Geert Uytterhoeven |
| 3692 | 3709 | E: geert@linux-m68k.org |
| 3693 | 3710 | W: http://users.telenet.be/geertu/ |
| 3694 | −P: 1024/862678A6 C51D 361C 0BD1 4C90 B275 C553 6EEA 11BA 8626 78A6 | |
| 3711 | +P: 4096R/4804B4BC3F55EEFB 750D 82B0 A781 5431 5E25 925B 4804 B4BC 3F55 EEFB | |
| 3695 | 3712 | D: m68k/Amiga and PPC/CHRP Longtrail coordinator |
| 3696 | 3713 | D: Frame buffer device and XF68_FBDev maintainer |
| 3697 | 3714 | D: m68k IDE maintainer |
| @@ -46,7 +46,8 @@ IRQ.txt · 45 unmodified lines | ||
| 46 | 46 | Intel-IOMMU.txt |
| 47 | 47 | - basic info on the Intel IOMMU virtualization support. |
| 48 | 48 | Makefile |
| 49 | − - some files in Documentation dir are actually sample code to build | |
| 49 | + - This file does nothing. Removing it breaks make htmldocs and | |
| 50 | + make distclean. | |
| 50 | 51 | ManagementStyle |
| 51 | 52 | - how to (attempt to) manage kernel hackers. |
| 52 | 53 | RCU/ |
| @@ -0,0 +1,345 @@ | ||
| 1 | +================== | |
| 2 | +cfg80211 subsystem | |
| 3 | +================== | |
| 4 | + | |
| 5 | +Device registration | |
| 6 | +=================== | |
| 7 | + | |
| 8 | +.. kernel-doc:: include/net/cfg80211.h | |
| 9 | + :doc: Device registration | |
| 10 | + | |
| 11 | +.. kernel-doc:: include/net/cfg80211.h | |
| 12 | + :functions: ieee80211_channel_flags | |
| 13 | + | |
| 14 | +.. kernel-doc:: include/net/cfg80211.h | |
| 15 | + :functions: ieee80211_channel | |
| 16 | + | |
| 17 | +.. kernel-doc:: include/net/cfg80211.h | |
| 18 | + :functions: ieee80211_rate_flags | |
| 19 | + | |
| 20 | +.. kernel-doc:: include/net/cfg80211.h | |
| 21 | + :functions: ieee80211_rate | |
| 22 | + | |
| 23 | +.. kernel-doc:: include/net/cfg80211.h | |
| 24 | + :functions: ieee80211_sta_ht_cap | |
| 25 | + | |
| 26 | +.. kernel-doc:: include/net/cfg80211.h | |
| 27 | + :functions: ieee80211_supported_band | |
| 28 | + | |
| 29 | +.. kernel-doc:: include/net/cfg80211.h | |
| 30 | + :functions: cfg80211_signal_type | |
| 31 | + | |
| 32 | +.. kernel-doc:: include/net/cfg80211.h | |
| 33 | + :functions: wiphy_params_flags | |
| 34 | + | |
| 35 | +.. kernel-doc:: include/net/cfg80211.h | |
| 36 | + :functions: wiphy_flags | |
| 37 | + | |
| 38 | +.. kernel-doc:: include/net/cfg80211.h | |
| 39 | + :functions: wiphy | |
| 40 | + | |
| 41 | +.. kernel-doc:: include/net/cfg80211.h | |
| 42 | + :functions: wireless_dev | |
| 43 | + | |
| 44 | +.. kernel-doc:: include/net/cfg80211.h | |
| 45 | + :functions: wiphy_new | |
| 46 | + | |
| 47 | +.. kernel-doc:: include/net/cfg80211.h | |
| 48 | + :functions: wiphy_register | |
| 49 | + | |
| 50 | +.. kernel-doc:: include/net/cfg80211.h | |
| 51 | + :functions: wiphy_unregister | |
| 52 | + | |
| 53 | +.. kernel-doc:: include/net/cfg80211.h | |
| 54 | + :functions: wiphy_free | |
| 55 | + | |
| 56 | +.. kernel-doc:: include/net/cfg80211.h | |
| 57 | + :functions: wiphy_name | |
| 58 | + | |
| 59 | +.. kernel-doc:: include/net/cfg80211.h | |
| 60 | + :functions: wiphy_dev | |
| 61 | + | |
| 62 | +.. kernel-doc:: include/net/cfg80211.h | |
| 63 | + :functions: wiphy_priv | |
| 64 | + | |
| 65 | +.. kernel-doc:: include/net/cfg80211.h | |
| 66 | + :functions: priv_to_wiphy | |
| 67 | + | |
| 68 | +.. kernel-doc:: include/net/cfg80211.h | |
| 69 | + :functions: set_wiphy_dev | |
| 70 | + | |
| 71 | +.. kernel-doc:: include/net/cfg80211.h | |
| 72 | + :functions: wdev_priv | |
| 73 | + | |
| 74 | +.. kernel-doc:: include/net/cfg80211.h | |
| 75 | + :functions: ieee80211_iface_limit | |
| 76 | + | |
| 77 | +.. kernel-doc:: include/net/cfg80211.h | |
| 78 | + :functions: ieee80211_iface_combination | |
| 79 | + | |
| 80 | +.. kernel-doc:: include/net/cfg80211.h | |
| 81 | + :functions: cfg80211_check_combinations | |
| 82 | + | |
| 83 | +Actions and configuration | |
| 84 | +========================= | |
| 85 | + | |
| 86 | +.. kernel-doc:: include/net/cfg80211.h | |
| 87 | + :doc: Actions and configuration | |
| 88 | + | |
| 89 | +.. kernel-doc:: include/net/cfg80211.h | |
| 90 | + :functions: cfg80211_ops | |
| 91 | + | |
| 92 | +.. kernel-doc:: include/net/cfg80211.h | |
| 93 | + :functions: vif_params | |
| 94 | + | |
| 95 | +.. kernel-doc:: include/net/cfg80211.h | |
| 96 | + :functions: key_params | |
| 97 | + | |
| 98 | +.. kernel-doc:: include/net/cfg80211.h | |
| 99 | + :functions: survey_info_flags | |
| 100 | + | |
| 101 | +.. kernel-doc:: include/net/cfg80211.h | |
| 102 | + :functions: survey_info | |
| 103 | + | |
| 104 | +.. kernel-doc:: include/net/cfg80211.h | |
| 105 | + :functions: cfg80211_beacon_data | |
| 106 | + | |
| 107 | +.. kernel-doc:: include/net/cfg80211.h | |
| 108 | + :functions: cfg80211_ap_settings | |
| 109 | + | |
| 110 | +.. kernel-doc:: include/net/cfg80211.h | |
| 111 | + :functions: station_parameters | |
| 112 | + | |
| 113 | +.. kernel-doc:: include/net/cfg80211.h | |
| 114 | + :functions: rate_info_flags | |
| 115 | + | |
| 116 | +.. kernel-doc:: include/net/cfg80211.h | |
| 117 | + :functions: rate_info | |
| 118 | + | |
| 119 | +.. kernel-doc:: include/net/cfg80211.h | |
| 120 | + :functions: station_info | |
| 121 | + | |
| 122 | +.. kernel-doc:: include/net/cfg80211.h | |
| 123 | + :functions: monitor_flags | |
| 124 | + | |
| 125 | +.. kernel-doc:: include/net/cfg80211.h | |
| 126 | + :functions: mpath_info_flags | |
| 127 | + | |
| 128 | +.. kernel-doc:: include/net/cfg80211.h | |
| 129 | + :functions: mpath_info | |
| 130 | + | |
| 131 | +.. kernel-doc:: include/net/cfg80211.h | |
| 132 | + :functions: bss_parameters | |
| 133 | + | |
| 134 | +.. kernel-doc:: include/net/cfg80211.h | |
| 135 | + :functions: ieee80211_txq_params | |
| 136 | + | |
| 137 | +.. kernel-doc:: include/net/cfg80211.h | |
| 138 | + :functions: cfg80211_crypto_settings | |
| 139 | + | |
| 140 | +.. kernel-doc:: include/net/cfg80211.h | |
| 141 | + :functions: cfg80211_auth_request | |
| 142 | + | |
| 143 | +.. kernel-doc:: include/net/cfg80211.h | |
| 144 | + :functions: cfg80211_assoc_request | |
| 145 | + | |
| 146 | +.. kernel-doc:: include/net/cfg80211.h | |
| 147 | + :functions: cfg80211_deauth_request | |
| 148 | + | |
| 149 | +.. kernel-doc:: include/net/cfg80211.h | |
| 150 | + :functions: cfg80211_disassoc_request | |
| 151 | + | |
| 152 | +.. kernel-doc:: include/net/cfg80211.h | |
| 153 | + :functions: cfg80211_ibss_params | |
| 154 | + | |
| 155 | +.. kernel-doc:: include/net/cfg80211.h | |
| 156 | + :functions: cfg80211_connect_params | |
| 157 | + | |
| 158 | +.. kernel-doc:: include/net/cfg80211.h | |
| 159 | + :functions: cfg80211_pmksa | |
| 160 | + | |
| 161 | +.. kernel-doc:: include/net/cfg80211.h | |
| 162 | + :functions: cfg80211_rx_mlme_mgmt | |
| 163 | + | |
| 164 | +.. kernel-doc:: include/net/cfg80211.h | |
| 165 | + :functions: cfg80211_auth_timeout | |
| 166 | + | |
| 167 | +.. kernel-doc:: include/net/cfg80211.h | |
| 168 | + :functions: cfg80211_rx_assoc_resp | |
| 169 | + | |
| 170 | +.. kernel-doc:: include/net/cfg80211.h | |
| 171 | + :functions: cfg80211_assoc_timeout | |
| 172 | + | |
| 173 | +.. kernel-doc:: include/net/cfg80211.h | |
| 174 | + :functions: cfg80211_tx_mlme_mgmt | |
| 175 | + | |
| 176 | +.. kernel-doc:: include/net/cfg80211.h | |
| 177 | + :functions: cfg80211_ibss_joined | |
| 178 | + | |
| 179 | +.. kernel-doc:: include/net/cfg80211.h | |
| 180 | + :functions: cfg80211_connect_result | |
| 181 | + | |
| 182 | +.. kernel-doc:: include/net/cfg80211.h | |
| 183 | + :functions: cfg80211_connect_bss | |
| 184 | + | |
| 185 | +.. kernel-doc:: include/net/cfg80211.h | |
| 186 | + :functions: cfg80211_connect_timeout | |
| 187 | + | |
| 188 | +.. kernel-doc:: include/net/cfg80211.h | |
| 189 | + :functions: cfg80211_roamed | |
| 190 | + | |
| 191 | +.. kernel-doc:: include/net/cfg80211.h | |
| 192 | + :functions: cfg80211_disconnected | |
| 193 | + | |
| 194 | +.. kernel-doc:: include/net/cfg80211.h | |
| 195 | + :functions: cfg80211_ready_on_channel | |
| 196 | + | |
| 197 | +.. kernel-doc:: include/net/cfg80211.h | |
| 198 | + :functions: cfg80211_remain_on_channel_expired | |
| 199 | + | |
| 200 | +.. kernel-doc:: include/net/cfg80211.h | |
| 201 | + :functions: cfg80211_new_sta | |
| 202 | + | |
| 203 | +.. kernel-doc:: include/net/cfg80211.h | |
| 204 | + :functions: cfg80211_rx_mgmt | |
| 205 | + | |
| 206 | +.. kernel-doc:: include/net/cfg80211.h | |
| 207 | + :functions: cfg80211_mgmt_tx_status | |
| 208 | + | |
| 209 | +.. kernel-doc:: include/net/cfg80211.h | |
| 210 | + :functions: cfg80211_cqm_rssi_notify | |
| 211 | + | |
| 212 | +.. kernel-doc:: include/net/cfg80211.h | |
| 213 | + :functions: cfg80211_cqm_pktloss_notify | |
| 214 | + | |
| 215 | +.. kernel-doc:: include/net/cfg80211.h | |
| 216 | + :functions: cfg80211_michael_mic_failure | |
| 217 | + | |
| 218 | +Scanning and BSS list handling | |
| 219 | +============================== | |
| 220 | + | |
| 221 | +.. kernel-doc:: include/net/cfg80211.h | |
| 222 | + :doc: Scanning and BSS list handling | |
| 223 | + | |
| 224 | +.. kernel-doc:: include/net/cfg80211.h | |
| 225 | + :functions: cfg80211_ssid | |
| 226 | + | |
| 227 | +.. kernel-doc:: include/net/cfg80211.h | |
| 228 | + :functions: cfg80211_scan_request | |
| 229 | + | |
| 230 | +.. kernel-doc:: include/net/cfg80211.h | |
| 231 | + :functions: cfg80211_scan_done | |
| 232 | + | |
| 233 | +.. kernel-doc:: include/net/cfg80211.h | |
| 234 | + :functions: cfg80211_bss | |
| 235 | + | |
| 236 | +.. kernel-doc:: include/net/cfg80211.h | |
| 237 | + :functions: cfg80211_inform_bss | |
| 238 | + | |
| 239 | +.. kernel-doc:: include/net/cfg80211.h | |
| 240 | + :functions: cfg80211_inform_bss_frame_data | |
| 241 | + | |
| 242 | +.. kernel-doc:: include/net/cfg80211.h | |
| 243 | + :functions: cfg80211_inform_bss_data | |
| 244 | + | |
| 245 | +.. kernel-doc:: include/net/cfg80211.h | |
| 246 | + :functions: cfg80211_unlink_bss | |
| 247 | + | |
| 248 | +.. kernel-doc:: include/net/cfg80211.h | |
| 249 | + :functions: cfg80211_find_ie | |
| 250 | + | |
| 251 | +.. kernel-doc:: include/net/cfg80211.h | |
| 252 | + :functions: ieee80211_bss_get_ie | |
| 253 | + | |
| 254 | +Utility functions | |
| 255 | +================= | |
| 256 | + | |
| 257 | +.. kernel-doc:: include/net/cfg80211.h | |
| 258 | + :doc: Utility functions | |
| 259 | + | |
| 260 | +.. kernel-doc:: include/net/cfg80211.h | |
| 261 | + :functions: ieee80211_channel_to_frequency | |
| 262 | + | |
| 263 | +.. kernel-doc:: include/net/cfg80211.h | |
| 264 | + :functions: ieee80211_frequency_to_channel | |
| 265 | + | |
| 266 | +.. kernel-doc:: include/net/cfg80211.h | |
| 267 | + :functions: ieee80211_get_channel | |
| 268 | + | |
| 269 | +.. kernel-doc:: include/net/cfg80211.h | |
| 270 | + :functions: ieee80211_get_response_rate | |
| 271 | + | |
| 272 | +.. kernel-doc:: include/net/cfg80211.h | |
| 273 | + :functions: ieee80211_hdrlen | |
| 274 | + | |
| 275 | +.. kernel-doc:: include/net/cfg80211.h | |
| 276 | + :functions: ieee80211_get_hdrlen_from_skb | |
| 277 | + | |
| 278 | +.. kernel-doc:: include/net/cfg80211.h | |
| 279 | + :functions: ieee80211_radiotap_iterator | |
| 280 | + | |
| 281 | +Data path helpers | |
| 282 | +================= | |
| 283 | + | |
| 284 | +.. kernel-doc:: include/net/cfg80211.h | |
| 285 | + :doc: Data path helpers | |
| 286 | + | |
| 287 | +.. kernel-doc:: include/net/cfg80211.h | |
| 288 | + :functions: ieee80211_data_to_8023 | |
| 289 | + | |
| 290 | +.. kernel-doc:: include/net/cfg80211.h | |
| 291 | + :functions: ieee80211_data_from_8023 | |
| 292 | + | |
| 293 | +.. kernel-doc:: include/net/cfg80211.h | |
| 294 | + :functions: ieee80211_amsdu_to_8023s | |
| 295 | + | |
| 296 | +.. kernel-doc:: include/net/cfg80211.h | |
| 297 | + :functions: cfg80211_classify8021d | |
| 298 | + | |
| 299 | +Regulatory enforcement infrastructure | |
| 300 | +===================================== | |
| 301 | + | |
| 302 | +.. kernel-doc:: include/net/cfg80211.h | |
| 303 | + :doc: Regulatory enforcement infrastructure | |
| 304 | + | |
| 305 | +.. kernel-doc:: include/net/cfg80211.h | |
| 306 | + :functions: regulatory_hint | |
| 307 | + | |
| 308 | +.. kernel-doc:: include/net/cfg80211.h | |
| 309 | + :functions: wiphy_apply_custom_regulatory | |
| 310 | + | |
| 311 | +.. kernel-doc:: include/net/cfg80211.h | |
| 312 | + :functions: freq_reg_info | |
| 313 | + | |
| 314 | +RFkill integration | |
| 315 | +================== | |
| 316 | + | |
| 317 | +.. kernel-doc:: include/net/cfg80211.h | |
| 318 | + :doc: RFkill integration | |
| 319 | + | |
| 320 | +.. kernel-doc:: include/net/cfg80211.h | |
| 321 | + :functions: wiphy_rfkill_set_hw_state | |
| 322 | + | |
| 323 | +.. kernel-doc:: include/net/cfg80211.h | |
| 324 | + :functions: wiphy_rfkill_start_polling | |
| 325 | + | |
| 326 | +.. kernel-doc:: include/net/cfg80211.h | |
| 327 | + :functions: wiphy_rfkill_stop_polling | |
| 328 | + | |
| 329 | +Test mode | |
| 330 | +========= | |
| 331 | + | |
| 332 | +.. kernel-doc:: include/net/cfg80211.h | |
| 333 | + :doc: Test mode | |
| 334 | + | |
| 335 | +.. kernel-doc:: include/net/cfg80211.h | |
| 336 | + :functions: cfg80211_testmode_alloc_reply_skb | |
| 337 | + | |
| 338 | +.. kernel-doc:: include/net/cfg80211.h | |
| 339 | + :functions: cfg80211_testmode_reply | |
| 340 | + | |
| 341 | +.. kernel-doc:: include/net/cfg80211.h | |
| 342 | + :functions: cfg80211_testmode_alloc_event_skb | |
| 343 | + | |
| 344 | +.. kernel-doc:: include/net/cfg80211.h | |
| 345 | + :functions: cfg80211_testmode_event | |
| @@ -0,0 +1,5 @@ | ||
| 1 | +# -*- coding: utf-8; mode: python -*- | |
| 2 | + | |
| 3 | +project = "Linux 802.11 Driver Developer's Guide" | |
| 4 | + | |
| 5 | +tags.add("subproject") | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +===================================== | |
| 2 | +Linux 802.11 Driver Developer's Guide | |
| 3 | +===================================== | |
| 4 | + | |
| 5 | +.. toctree:: | |
| 6 | + | |
| 7 | + introduction | |
| 8 | + cfg80211 | |
| 9 | + mac80211 | |
| 10 | + mac80211-advanced | |
| 11 | + | |
| 12 | +.. only:: subproject | |
| 13 | + | |
| 14 | + Indices | |
| 15 | + ======= | |
| 16 | + | |
| 17 | + * :ref:`genindex` | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +============ | |
| 2 | +Introduction | |
| 3 | +============ | |
| 4 | + | |
| 5 | +Explaining wireless 802.11 networking in the Linux kernel | |
| 6 | + | |
| 7 | +Copyright 2007-2009 Johannes Berg | |
| 8 | + | |
| 9 | +These books attempt to give a description of the various subsystems | |
| 10 | +that play a role in 802.11 wireless networking in Linux. Since these | |
| 11 | +books are for kernel developers they attempts to document the | |
| 12 | +structures and functions used in the kernel as well as giving a | |
| 13 | +higher-level overview. | |
| 14 | + | |
| 15 | +The reader is expected to be familiar with the 802.11 standard as | |
| 16 | +published by the IEEE in 802.11-2007 (or possibly later versions). | |
| 17 | +References to this standard will be given as "802.11-2007 8.1.5". | |
| @@ -0,0 +1,295 @@ | ||
| 1 | +============================= | |
| 2 | +mac80211 subsystem (advanced) | |
| 3 | +============================= | |
| 4 | + | |
| 5 | +Information contained within this part of the book is of interest only | |
| 6 | +for advanced interaction of mac80211 with drivers to exploit more | |
| 7 | +hardware capabilities and improve performance. | |
| 8 | + | |
| 9 | +LED support | |
| 10 | +=========== | |
| 11 | + | |
| 12 | +Mac80211 supports various ways of blinking LEDs. Wherever possible, | |
| 13 | +device LEDs should be exposed as LED class devices and hooked up to the | |
| 14 | +appropriate trigger, which will then be triggered appropriately by | |
| 15 | +mac80211. | |
| 16 | + | |
| 17 | +.. kernel-doc:: include/net/mac80211.h | |
| 18 | + :functions: ieee80211_get_tx_led_name | |
| 19 | + | |
| 20 | +.. kernel-doc:: include/net/mac80211.h | |
| 21 | + :functions: ieee80211_get_rx_led_name | |
| 22 | + | |
| 23 | +.. kernel-doc:: include/net/mac80211.h | |
| 24 | + :functions: ieee80211_get_assoc_led_name | |
| 25 | + | |
| 26 | +.. kernel-doc:: include/net/mac80211.h | |
| 27 | + :functions: ieee80211_get_radio_led_name | |
| 28 | + | |
| 29 | +.. kernel-doc:: include/net/mac80211.h | |
| 30 | + :functions: ieee80211_tpt_blink | |
| 31 | + | |
| 32 | +.. kernel-doc:: include/net/mac80211.h | |
| 33 | + :functions: ieee80211_tpt_led_trigger_flags | |
| 34 | + | |
| 35 | +.. kernel-doc:: include/net/mac80211.h | |
| 36 | + :functions: ieee80211_create_tpt_led_trigger | |
| 37 | + | |
| 38 | +Hardware crypto acceleration | |
| 39 | +============================ | |
| 40 | + | |
| 41 | +.. kernel-doc:: include/net/mac80211.h | |
| 42 | + :doc: Hardware crypto acceleration | |
| 43 | + | |
| 44 | +.. kernel-doc:: include/net/mac80211.h | |
| 45 | + :functions: set_key_cmd | |
| 46 | + | |
| 47 | +.. kernel-doc:: include/net/mac80211.h | |
| 48 | + :functions: ieee80211_key_conf | |
| 49 | + | |
| 50 | +.. kernel-doc:: include/net/mac80211.h | |
| 51 | + :functions: ieee80211_key_flags | |
| 52 | + | |
| 53 | +.. kernel-doc:: include/net/mac80211.h | |
| 54 | + :functions: ieee80211_get_tkip_p1k | |
| 55 | + | |
| 56 | +.. kernel-doc:: include/net/mac80211.h | |
| 57 | + :functions: ieee80211_get_tkip_p1k_iv | |
| 58 | + | |
| 59 | +.. kernel-doc:: include/net/mac80211.h | |
| 60 | + :functions: ieee80211_get_tkip_p2k | |
| 61 | + | |
| 62 | +Powersave support | |
| 63 | +================= | |
| 64 | + | |
| 65 | +.. kernel-doc:: include/net/mac80211.h | |
| 66 | + :doc: Powersave support | |
| 67 | + | |
| 68 | +Beacon filter support | |
| 69 | +===================== | |
| 70 | + | |
| 71 | +.. kernel-doc:: include/net/mac80211.h | |
| 72 | + :doc: Beacon filter support | |
| 73 | + | |
| 74 | +.. kernel-doc:: include/net/mac80211.h | |
| 75 | + :functions: ieee80211_beacon_loss | |
| 76 | + | |
| 77 | +Multiple queues and QoS support | |
| 78 | +=============================== | |
| 79 | + | |
| 80 | +TBD | |
| 81 | + | |
| 82 | +.. kernel-doc:: include/net/mac80211.h | |
| 83 | + :functions: ieee80211_tx_queue_params | |
| 84 | + | |
| 85 | +Access point mode support | |
| 86 | +========================= | |
| 87 | + | |
| 88 | +TBD | |
| 89 | + | |
| 90 | +Some parts of the if_conf should be discussed here instead | |
| 91 | + | |
| 92 | +Insert notes about VLAN interfaces with hw crypto here or in the hw | |
| 93 | +crypto chapter. | |
| 94 | + | |
| 95 | +support for powersaving clients | |
| 96 | +------------------------------- | |
| 97 | + | |
| 98 | +.. kernel-doc:: include/net/mac80211.h | |
| 99 | + :doc: AP support for powersaving clients | |
| 100 | + | |
| 101 | +.. kernel-doc:: include/net/mac80211.h | |
| 102 | + :functions: ieee80211_get_buffered_bc | |
| 103 | + | |
| 104 | +.. kernel-doc:: include/net/mac80211.h | |
| 105 | + :functions: ieee80211_beacon_get | |
| 106 | + | |
| 107 | +.. kernel-doc:: include/net/mac80211.h | |
| 108 | + :functions: ieee80211_sta_eosp | |
| 109 | + | |
| 110 | +.. kernel-doc:: include/net/mac80211.h | |
| 111 | + :functions: ieee80211_frame_release_type | |
| 112 | + | |
| 113 | +.. kernel-doc:: include/net/mac80211.h | |
| 114 | + :functions: ieee80211_sta_ps_transition | |
| 115 | + | |
| 116 | +.. kernel-doc:: include/net/mac80211.h | |
| 117 | + :functions: ieee80211_sta_ps_transition_ni | |
| 118 | + | |
| 119 | +.. kernel-doc:: include/net/mac80211.h | |
| 120 | + :functions: ieee80211_sta_set_buffered | |
| 121 | + | |
| 122 | +.. kernel-doc:: include/net/mac80211.h | |
| 123 | + :functions: ieee80211_sta_block_awake | |
| 124 | + | |
| 125 | +Supporting multiple virtual interfaces | |
| 126 | +====================================== | |
| 127 | + | |
| 128 | +TBD | |
| 129 | + | |
| 130 | +Note: WDS with identical MAC address should almost always be OK | |
| 131 | + | |
| 132 | +Insert notes about having multiple virtual interfaces with different MAC | |
| 133 | +addresses here, note which configurations are supported by mac80211, add | |
| 134 | +notes about supporting hw crypto with it. | |
| 135 | + | |
| 136 | +.. kernel-doc:: include/net/mac80211.h | |
| 137 | + :functions: ieee80211_iterate_active_interfaces | |
| 138 | + | |
| 139 | +.. kernel-doc:: include/net/mac80211.h | |
| 140 | + :functions: ieee80211_iterate_active_interfaces_atomic | |
| 141 | + | |
| 142 | +Station handling | |
| 143 | +================ | |
| 144 | + | |
| 145 | +TODO | |
| 146 | + | |
| 147 | +.. kernel-doc:: include/net/mac80211.h | |
| 148 | + :functions: ieee80211_sta | |
| 149 | + | |
| 150 | +.. kernel-doc:: include/net/mac80211.h | |
| 151 | + :functions: sta_notify_cmd | |
| 152 | + | |
| 153 | +.. kernel-doc:: include/net/mac80211.h | |
| 154 | + :functions: ieee80211_find_sta | |
| 155 | + | |
| 156 | +.. kernel-doc:: include/net/mac80211.h | |
| 157 | + :functions: ieee80211_find_sta_by_ifaddr | |
| 158 | + | |
| 159 | +Hardware scan offload | |
| 160 | +===================== | |
| 161 | + | |
| 162 | +TBD | |
| 163 | + | |
| 164 | +.. kernel-doc:: include/net/mac80211.h | |
| 165 | + :functions: ieee80211_scan_completed | |
| 166 | + | |
| 167 | +Aggregation | |
| 168 | +=========== | |
| 169 | + | |
| 170 | +TX A-MPDU aggregation | |
| 171 | +--------------------- | |
| 172 | + | |
| 173 | +.. kernel-doc:: net/mac80211/agg-tx.c | |
| 174 | + :doc: TX A-MPDU aggregation | |
| 175 | + | |
| 176 | +.. WARNING: DOCPROC directive not supported: !Cnet/mac80211/agg-tx.c | |
| 177 | + | |
| 178 | +RX A-MPDU aggregation | |
| 179 | +--------------------- | |
| 180 | + | |
| 181 | +.. kernel-doc:: net/mac80211/agg-rx.c | |
| 182 | + :doc: RX A-MPDU aggregation | |
| 183 | + | |
| 184 | +.. WARNING: DOCPROC directive not supported: !Cnet/mac80211/agg-rx.c | |
| 185 | + | |
| 186 | +.. kernel-doc:: include/net/mac80211.h | |
| 187 | + :functions: ieee80211_ampdu_mlme_action | |
| 188 | + | |
| 189 | +Spatial Multiplexing Powersave (SMPS) | |
| 190 | +===================================== | |
| 191 | + | |
| 192 | +.. kernel-doc:: include/net/mac80211.h | |
| 193 | + :doc: Spatial multiplexing power save | |
| 194 | + | |
| 195 | +.. kernel-doc:: include/net/mac80211.h | |
| 196 | + :functions: ieee80211_request_smps | |
| 197 | + | |
| 198 | +.. kernel-doc:: include/net/mac80211.h | |
| 199 | + :functions: ieee80211_smps_mode | |
| 200 | + | |
| 201 | +TBD | |
| 202 | + | |
| 203 | +This part of the book describes the rate control algorithm interface and | |
| 204 | +how it relates to mac80211 and drivers. | |
| 205 | + | |
| 206 | +Rate Control API | |
| 207 | +================ | |
| 208 | + | |
| 209 | +TBD | |
| 210 | + | |
| 211 | +.. kernel-doc:: include/net/mac80211.h | |
| 212 | + :functions: ieee80211_start_tx_ba_session | |
| 213 | + | |
| 214 | +.. kernel-doc:: include/net/mac80211.h | |
| 215 | + :functions: ieee80211_start_tx_ba_cb_irqsafe | |
| 216 | + | |
| 217 | +.. kernel-doc:: include/net/mac80211.h | |
| 218 | + :functions: ieee80211_stop_tx_ba_session | |
| 219 | + | |
| 220 | +.. kernel-doc:: include/net/mac80211.h | |
| 221 | + :functions: ieee80211_stop_tx_ba_cb_irqsafe | |
| 222 | + | |
| 223 | +.. kernel-doc:: include/net/mac80211.h | |
| 224 | + :functions: ieee80211_rate_control_changed | |
| 225 | + | |
| 226 | +.. kernel-doc:: include/net/mac80211.h | |
| 227 | + :functions: ieee80211_tx_rate_control | |
| 228 | + | |
| 229 | +.. kernel-doc:: include/net/mac80211.h | |
| 230 | + :functions: rate_control_send_low | |
| 231 | + | |
| 232 | +TBD | |
| 233 | + | |
| 234 | +This part of the book describes mac80211 internals. | |
| 235 | + | |
| 236 | +Key handling | |
| 237 | +============ | |
| 238 | + | |
| 239 | +Key handling basics | |
| 240 | +------------------- | |
| 241 | + | |
| 242 | +.. kernel-doc:: net/mac80211/key.c | |
| 243 | + :doc: Key handling basics | |
| 244 | + | |
| 245 | +MORE TBD | |
| 246 | +-------- | |
| 247 | + | |
| 248 | +TBD | |
| 249 | + | |
| 250 | +Receive processing | |
| 251 | +================== | |
| 252 | + | |
| 253 | +TBD | |
| 254 | + | |
| 255 | +Transmit processing | |
| 256 | +=================== | |
| 257 | + | |
| 258 | +TBD | |
| 259 | + | |
| 260 | +Station info handling | |
| 261 | +===================== | |
| 262 | + | |
| 263 | +Programming information | |
| 264 | +----------------------- | |
| 265 | + | |
| 266 | +.. kernel-doc:: net/mac80211/sta_info.h | |
| 267 | + :functions: sta_info | |
| 268 | + | |
| 269 | +.. kernel-doc:: net/mac80211/sta_info.h | |
| 270 | + :functions: ieee80211_sta_info_flags | |
| 271 | + | |
| 272 | +STA information lifetime rules | |
| 273 | +------------------------------ | |
| 274 | + | |
| 275 | +.. kernel-doc:: net/mac80211/sta_info.c | |
| 276 | + :doc: STA information lifetime rules | |
| 277 | + | |
| 278 | +Aggregation | |
| 279 | +=========== | |
| 280 | + | |
| 281 | +.. kernel-doc:: net/mac80211/sta_info.h | |
| 282 | + :functions: sta_ampdu_mlme | |
| 283 | + | |
| 284 | +.. kernel-doc:: net/mac80211/sta_info.h | |
| 285 | + :functions: tid_ampdu_tx | |
| 286 | + | |
| 287 | +.. kernel-doc:: net/mac80211/sta_info.h | |
| 288 | + :functions: tid_ampdu_rx | |
| 289 | + | |
| 290 | +Synchronisation | |
| 291 | +=============== | |
| 292 | + | |
| 293 | +TBD | |
| 294 | + | |
| 295 | +Locking, lots of RCU | |
| @@ -0,0 +1,216 @@ | ||
| 1 | +=========================== | |
| 2 | +mac80211 subsystem (basics) | |
| 3 | +=========================== | |
| 4 | + | |
| 5 | +You should read and understand the information contained within this | |
| 6 | +part of the book while implementing a mac80211 driver. In some chapters, | |
| 7 | +advanced usage is noted, those may be skipped if this isn't needed. | |
| 8 | + | |
| 9 | +This part of the book only covers station and monitor mode | |
| 10 | +functionality, additional information required to implement the other | |
| 11 | +modes is covered in the second part of the book. | |
| 12 | + | |
| 13 | +Basic hardware handling | |
| 14 | +======================= | |
| 15 | + | |
| 16 | +TBD | |
| 17 | + | |
| 18 | +This chapter shall contain information on getting a hw struct allocated | |
| 19 | +and registered with mac80211. | |
| 20 | + | |
| 21 | +Since it is required to allocate rates/modes before registering a hw | |
| 22 | +struct, this chapter shall also contain information on setting up the | |
| 23 | +rate/mode structs. | |
| 24 | + | |
| 25 | +Additionally, some discussion about the callbacks and the general | |
| 26 | +programming model should be in here, including the definition of | |
| 27 | +ieee80211_ops which will be referred to a lot. | |
| 28 | + | |
| 29 | +Finally, a discussion of hardware capabilities should be done with | |
| 30 | +references to other parts of the book. | |
| 31 | + | |
| 32 | +.. kernel-doc:: include/net/mac80211.h | |
| 33 | + :functions: ieee80211_hw | |
| 34 | + | |
| 35 | +.. kernel-doc:: include/net/mac80211.h | |
| 36 | + :functions: ieee80211_hw_flags | |
| 37 | + | |
| 38 | +.. kernel-doc:: include/net/mac80211.h | |
| 39 | + :functions: SET_IEEE80211_DEV | |
| 40 | + | |
| 41 | +.. kernel-doc:: include/net/mac80211.h | |
| 42 | + :functions: SET_IEEE80211_PERM_ADDR | |
| 43 | + | |
| 44 | +.. kernel-doc:: include/net/mac80211.h | |
| 45 | + :functions: ieee80211_ops | |
| 46 | + | |
| 47 | +.. kernel-doc:: include/net/mac80211.h | |
| 48 | + :functions: ieee80211_alloc_hw | |
| 49 | + | |
| 50 | +.. kernel-doc:: include/net/mac80211.h | |
| 51 | + :functions: ieee80211_register_hw | |
| 52 | + | |
| 53 | +.. kernel-doc:: include/net/mac80211.h | |
| 54 | + :functions: ieee80211_unregister_hw | |
| 55 | + | |
| 56 | +.. kernel-doc:: include/net/mac80211.h | |
| 57 | + :functions: ieee80211_free_hw | |
| 58 | + | |
| 59 | +PHY configuration | |
| 60 | +================= | |
| 61 | + | |
| 62 | +TBD | |
| 63 | + | |
| 64 | +This chapter should describe PHY handling including start/stop callbacks | |
| 65 | +and the various structures used. | |
| 66 | + | |
| 67 | +.. kernel-doc:: include/net/mac80211.h | |
| 68 | + :functions: ieee80211_conf | |
| 69 | + | |
| 70 | +.. kernel-doc:: include/net/mac80211.h | |
| 71 | + :functions: ieee80211_conf_flags | |
| 72 | + | |
| 73 | +Virtual interfaces | |
| 74 | +================== | |
| 75 | + | |
| 76 | +TBD | |
| 77 | + | |
| 78 | +This chapter should describe virtual interface basics that are relevant | |
| 79 | +to the driver (VLANs, MGMT etc are not.) It should explain the use of | |
| 80 | +the add_iface/remove_iface callbacks as well as the interface | |
| 81 | +configuration callbacks. | |
| 82 | + | |
| 83 | +Things related to AP mode should be discussed there. | |
| 84 | + | |
| 85 | +Things related to supporting multiple interfaces should be in the | |
| 86 | +appropriate chapter, a BIG FAT note should be here about this though and | |
| 87 | +the recommendation to allow only a single interface in STA mode at | |
| 88 | +first! | |
| 89 | + | |
| 90 | +.. kernel-doc:: include/net/mac80211.h | |
| 91 | + :functions: ieee80211_vif | |
| 92 | + | |
| 93 | +Receive and transmit processing | |
| 94 | +=============================== | |
| 95 | + | |
| 96 | +what should be here | |
| 97 | +------------------- | |
| 98 | + | |
| 99 | +TBD | |
| 100 | + | |
| 101 | +This should describe the receive and transmit paths in mac80211/the | |
| 102 | +drivers as well as transmit status handling. | |
| 103 | + | |
| 104 | +Frame format | |
| 105 | +------------ | |
| 106 | + | |
| 107 | +.. kernel-doc:: include/net/mac80211.h | |
| 108 | + :doc: Frame format | |
| 109 | + | |
| 110 | +Packet alignment | |
| 111 | +---------------- | |
| 112 | + | |
| 113 | +.. kernel-doc:: net/mac80211/rx.c | |
| 114 | + :doc: Packet alignment | |
| 115 | + | |
| 116 | +Calling into mac80211 from interrupts | |
| 117 | +------------------------------------- | |
| 118 | + | |
| 119 | +.. kernel-doc:: include/net/mac80211.h | |
| 120 | + :doc: Calling mac80211 from interrupts | |
| 121 | + | |
| 122 | +functions/definitions | |
| 123 | +--------------------- | |
| 124 | + | |
| 125 | +.. kernel-doc:: include/net/mac80211.h | |
| 126 | + :functions: ieee80211_rx_status | |
| 127 | + | |
| 128 | +.. kernel-doc:: include/net/mac80211.h | |
| 129 | + :functions: mac80211_rx_flags | |
| 130 | + | |
| 131 | +.. kernel-doc:: include/net/mac80211.h | |
| 132 | + :functions: mac80211_tx_info_flags | |
| 133 | + | |
| 134 | +.. kernel-doc:: include/net/mac80211.h | |
| 135 | + :functions: mac80211_tx_control_flags | |
| 136 | + | |
| 137 | +.. kernel-doc:: include/net/mac80211.h | |
| 138 | + :functions: mac80211_rate_control_flags | |
| 139 | + | |
| 140 | +.. kernel-doc:: include/net/mac80211.h | |
| 141 | + :functions: ieee80211_tx_rate | |
| 142 | + | |
| 143 | +.. kernel-doc:: include/net/mac80211.h | |
| 144 | + :functions: ieee80211_tx_info | |
| 145 | + | |
| 146 | +.. kernel-doc:: include/net/mac80211.h | |
| 147 | + :functions: ieee80211_tx_info_clear_status | |
| 148 | + | |
| 149 | +.. kernel-doc:: include/net/mac80211.h | |
| 150 | + :functions: ieee80211_rx | |
| 151 | + | |
| 152 | +.. kernel-doc:: include/net/mac80211.h | |
| 153 | + :functions: ieee80211_rx_ni | |
| 154 | + | |
| 155 | +.. kernel-doc:: include/net/mac80211.h | |
| 156 | + :functions: ieee80211_rx_irqsafe | |
| 157 | + | |
| 158 | +.. kernel-doc:: include/net/mac80211.h | |
| 159 | + :functions: ieee80211_tx_status | |
| 160 | + | |
| 161 | +.. kernel-doc:: include/net/mac80211.h | |
| 162 | + :functions: ieee80211_tx_status_ni | |
| 163 | + | |
| 164 | +.. kernel-doc:: include/net/mac80211.h | |
| 165 | + :functions: ieee80211_tx_status_irqsafe | |
| 166 | + | |
| 167 | +.. kernel-doc:: include/net/mac80211.h | |
| 168 | + :functions: ieee80211_rts_get | |
| 169 | + | |
| 170 | +.. kernel-doc:: include/net/mac80211.h | |
| 171 | + :functions: ieee80211_rts_duration | |
| 172 | + | |
| 173 | +.. kernel-doc:: include/net/mac80211.h | |
| 174 | + :functions: ieee80211_ctstoself_get | |
| 175 | + | |
| 176 | +.. kernel-doc:: include/net/mac80211.h | |
| 177 | + :functions: ieee80211_ctstoself_duration | |
| 178 | + | |
| 179 | +.. kernel-doc:: include/net/mac80211.h | |
| 180 | + :functions: ieee80211_generic_frame_duration | |
| 181 | + | |
| 182 | +.. kernel-doc:: include/net/mac80211.h | |
| 183 | + :functions: ieee80211_wake_queue | |
| 184 | + | |
| 185 | +.. kernel-doc:: include/net/mac80211.h | |
| 186 | + :functions: ieee80211_stop_queue | |
| 187 | + | |
| 188 | +.. kernel-doc:: include/net/mac80211.h | |
| 189 | + :functions: ieee80211_wake_queues | |
| 190 | + | |
| 191 | +.. kernel-doc:: include/net/mac80211.h | |
| 192 | + :functions: ieee80211_stop_queues | |
| 193 | + | |
| 194 | +.. kernel-doc:: include/net/mac80211.h | |
| 195 | + :functions: ieee80211_queue_stopped | |
| 196 | + | |
| 197 | +Frame filtering | |
| 198 | +=============== | |
| 199 | + | |
| 200 | +.. kernel-doc:: include/net/mac80211.h | |
| 201 | + :doc: Frame filtering | |
| 202 | + | |
| 203 | +.. kernel-doc:: include/net/mac80211.h | |
| 204 | + :functions: ieee80211_filter_flags | |
| 205 | + | |
| 206 | +The mac80211 workqueue | |
| 207 | +====================== | |
| 208 | + | |
| 209 | +.. kernel-doc:: include/net/mac80211.h | |
| 210 | + :doc: mac80211 workqueue | |
| 211 | + | |
| 212 | +.. kernel-doc:: include/net/mac80211.h | |
| 213 | + :functions: ieee80211_queue_work | |
| 214 | + | |
| 215 | +.. kernel-doc:: include/net/mac80211.h | |
| 216 | + :functions: ieee80211_queue_delayed_work | |
| @@ -6,7 +6,7 @@ Description: · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Being used for adding and removing rbd block devices. |
| 8 | 8 | |
| 9 | −Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name] | |
| 9 | +Usage: <mon ip addr> <options> <pool name> <rbd image name> [<snap name>] | |
| 10 | 10 | |
| 11 | 11 | $ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add |
| 12 | 12 | |
| @@ -14,9 +14,13 @@ The snapshot name can be "-" or omitted to map the image read/write. A <dev-id> · 1 unmodified line | ||
| 14 | 14 | will be assigned for any registered block device. If snapshot is used, it will |
| 15 | 15 | be mapped read-only. |
| 16 | 16 | |
| 17 | −Removal of a device: | |
| 17 | +Usage: <dev-id> [force] | |
| 18 | 18 | |
| 19 | − $ echo <dev-id> > /sys/bus/rbd/remove | |
| 19 | + $ echo 2 > /sys/bus/rbd/remove | |
| 20 | + | |
| 21 | +Optional "force" argument which when passed will wait for running requests and | |
| 22 | +then unmap the image. Requests sent to the driver after initiating the removal | |
| 23 | +will be failed. (August 2016, since 4.9.) | |
| 20 | 24 | |
| 21 | 25 | What: /sys/bus/rbd/add_single_major |
| 22 | 26 | Date: December 2013 |
| @@ -43,10 +47,25 @@ Description: Available only if rbd module is inserted with single_major · 20 unmodified lines | ||
| 43 | 47 | Entries under /sys/bus/rbd/devices/<dev-id>/ |
| 44 | 48 | -------------------------------------------- |
| 45 | 49 | |
| 50 | +client_addr | |
| 51 | + | |
| 52 | + The ceph unique client entity_addr_t (address + nonce). | |
| 53 | + The format is <address>:<port>/<nonce>: '1.2.3.4:1234/5678' or | |
| 54 | + '[1:2:3:4:5:6:7:8]:1234/5678'. (August 2016, since 4.9.) | |
| 55 | + | |
| 46 | 56 | client_id |
| 47 | 57 | |
| 48 | 58 | The ceph unique client id that was assigned for this specific session. |
| 49 | 59 | |
| 60 | +cluster_fsid | |
| 61 | + | |
| 62 | + The ceph cluster UUID. (August 2016, since 4.9.) | |
| 63 | + | |
| 64 | +config_info | |
| 65 | + | |
| 66 | + The string written into /sys/bus/rbd/add{,_single_major}. (August | |
| 67 | + 2016, since 4.9.) | |
| 68 | + | |
| 50 | 69 | features |
| 51 | 70 | |
| 52 | 71 | A hexadecimal encoding of the feature bits for this image. |
| @@ -92,6 +111,10 @@ current_snap · 39 unmodified lines | ||
| 92 | 111 | |
| 93 | 112 | The current snapshot for which the device is mapped. |
| 94 | 113 | |
| 114 | +snap_id | |
| 115 | + | |
| 116 | + The current snapshot's id. (August 2016, since 4.9.) | |
| 117 | + | |
| 95 | 118 | parent |
| 96 | 119 | |
| 97 | 120 | Information identifying the chain of parent images in a layered rbd |
| @@ -220,8 +220,11 @@ What: /sys/class/cxl/<card>/reset · 219 unmodified lines | ||
| 220 | 220 | Date: October 2014 |
| 221 | 221 | Contact: linuxppc-dev@lists.ozlabs.org |
| 222 | 222 | Description: write only |
| 223 | − Writing 1 will issue a PERST to card which may cause the card | |
| 224 | − to reload the FPGA depending on load_image_on_perst. | |
| 223 | + Writing 1 will issue a PERST to card provided there are no | |
| 224 | + contexts active on any one of the card AFUs. This may cause | |
| 225 | + the card to reload the FPGA depending on load_image_on_perst. | |
| 226 | + Writing -1 will do a force PERST irrespective of any active | |
| 227 | + contexts on the card AFUs. | |
| 225 | 228 | Users: https://github.com/ibm-capi/libcxl |
| 226 | 229 | |
| 227 | 230 | What: /sys/class/cxl/<card>/perst_reloads_same_image (not in a guest) |
| @@ -24,7 +24,8 @@ Description: · 23 unmodified lines | ||
| 24 | 24 | of led events. |
| 25 | 25 | You can change triggers in a similar manner to the way an IO |
| 26 | 26 | scheduler is chosen. Trigger specific parameters can appear in |
| 27 | − /sys/class/leds/<led> once a given trigger is selected. | |
| 27 | + /sys/class/leds/<led> once a given trigger is selected. For | |
| 28 | + their documentation see sysfs-class-led-trigger-*. | |
| 28 | 29 | |
| 29 | 30 | What: /sys/class/leds/<led>/inverted |
| 30 | 31 | Date: January 2011 |
| @@ -0,0 +1,36 @@ | ||
| 1 | +What: /sys/class/leds/<led>/delay_on | |
| 2 | +Date: Jun 2012 | |
| 3 | +KernelVersion: 3.6 | |
| 4 | +Contact: linux-leds@vger.kernel.org | |
| 5 | +Description: | |
| 6 | + Specifies for how many milliseconds the LED has to stay at | |
| 7 | + LED_FULL brightness after it has been armed. | |
| 8 | + Defaults to 100 ms. | |
| 9 | + | |
| 10 | +What: /sys/class/leds/<led>/delay_off | |
| 11 | +Date: Jun 2012 | |
| 12 | +KernelVersion: 3.6 | |
| 13 | +Contact: linux-leds@vger.kernel.org | |
| 14 | +Description: | |
| 15 | + Specifies for how many milliseconds the LED has to stay at | |
| 16 | + LED_OFF brightness after it has been armed. | |
| 17 | + Defaults to 100 ms. | |
| 18 | + | |
| 19 | +What: /sys/class/leds/<led>/invert | |
| 20 | +Date: Jun 2012 | |
| 21 | +KernelVersion: 3.6 | |
| 22 | +Contact: linux-leds@vger.kernel.org | |
| 23 | +Description: | |
| 24 | + Reverse the blink logic. If set to 0 (default) blink on for | |
| 25 | + delay_on ms, then blink off for delay_off ms, leaving the LED | |
| 26 | + normally off. If set to 1, blink off for delay_off ms, then | |
| 27 | + blink on for delay_on ms, leaving the LED normally on. | |
| 28 | + Setting this value also immediately changes the LED state. | |
| 29 | + | |
| 30 | +What: /sys/class/leds/<led>/shot | |
| 31 | +Date: Jun 2012 | |
| 32 | +KernelVersion: 3.6 | |
| 33 | +Contact: linux-leds@vger.kernel.org | |
| 34 | +Description: | |
| 35 | + Write any non-empty string to signal an events, this starts a | |
| 36 | + blink sequence if not already running. | |
| @@ -0,0 +1,12 @@ | ||
| 1 | +What: /sys/class/leds/<led>/ports/<port> | |
| 2 | +Date: September 2016 | |
| 3 | +KernelVersion: 4.9 | |
| 4 | +Contact: linux-leds@vger.kernel.org | |
| 5 | + linux-usb@vger.kernel.org | |
| 6 | +Description: | |
| 7 | + Every dir entry represents a single USB port that can be | |
| 8 | + selected for the USB port trigger. Selecting ports makes trigger | |
| 9 | + observing them for any connected devices and lighting on LED if | |
| 10 | + there are any. | |
| 11 | + Echoing "1" value selects USB port. Echoing "0" unselects it. | |
| 12 | + Current state can be also read. | |
| @@ -153,7 +153,7 @@ Description: · 152 unmodified lines | ||
| 153 | 153 | |
| 154 | 154 | What: /sys/class/mic/mic(x)/heartbeat_enable |
| 155 | 155 | Date: March 2015 |
| 156 | −KernelVersion: 3.20 | |
| 156 | +KernelVersion: 4.4 | |
| 157 | 157 | Contact: Ashutosh Dixit <ashutosh.dixit@intel.com> |
| 158 | 158 | Description: |
| 159 | 159 | The MIC drivers detect and inform user space about card crashes |
| @@ -22,7 +22,7 @@ Description: · 21 unmodified lines | ||
| 22 | 22 | What: /sys/class/power_supply/max14577-charger/device/fast_charge_timer |
| 23 | 23 | Date: October 2014 |
| 24 | 24 | KernelVersion: 3.18.0 |
| 25 | −Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com> | |
| 25 | +Contact: Krzysztof Kozlowski <krzk@kernel.org> | |
| 26 | 26 | Description: |
| 27 | 27 | This entry shows and sets the maximum time the max14577 |
| 28 | 28 | charger operates in fast-charge mode. When the timer expires |
| @@ -36,7 +36,7 @@ Description: · 7 unmodified lines | ||
| 36 | 36 | What: /sys/class/power_supply/max77693-charger/device/fast_charge_timer |
| 37 | 37 | Date: January 2015 |
| 38 | 38 | KernelVersion: 3.19.0 |
| 39 | −Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com> | |
| 39 | +Contact: Krzysztof Kozlowski <krzk@kernel.org> | |
| 40 | 40 | Description: |
| 41 | 41 | This entry shows and sets the maximum time the max77693 |
| 42 | 42 | charger operates in fast-charge mode. When the timer expires |
| @@ -50,7 +50,7 @@ Description: · 7 unmodified lines | ||
| 50 | 50 | What: /sys/class/power_supply/max77693-charger/device/top_off_threshold_current |
| 51 | 51 | Date: January 2015 |
| 52 | 52 | KernelVersion: 3.19.0 |
| 53 | −Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com> | |
| 53 | +Contact: Krzysztof Kozlowski <krzk@kernel.org> | |
| 54 | 54 | Description: |
| 55 | 55 | This entry shows and sets the charging current threshold for |
| 56 | 56 | entering top-off charging mode. When charging current in fast |
| @@ -65,7 +65,7 @@ Description: · 8 unmodified lines | ||
| 65 | 65 | What: /sys/class/power_supply/max77693-charger/device/top_off_timer |
| 66 | 66 | Date: January 2015 |
| 67 | 67 | KernelVersion: 3.19.0 |
| 68 | −Contact: Krzysztof Kozlowski <k.kozlowski@samsung.com> | |
| 68 | +Contact: Krzysztof Kozlowski <krzk@kernel.org> | |
| 69 | 69 | Description: |
| 70 | 70 | This entry shows and sets the maximum time the max77693 |
| 71 | 71 | charger operates in top-off charge mode. When the timer expires |
| @@ -35,6 +35,12 @@ Description: Displays a set of alternate modes supported by a wheel. Each · 34 unmodified lines | ||
| 35 | 35 | DF-EX <*--------> G25 <-> G27 |
| 36 | 36 | DF-EX <*----------------> G27 |
| 37 | 37 | |
| 38 | + G29: | |
| 39 | + DF-EX <*> DFP <-> G25 <-> G27 <-> G29 | |
| 40 | + DF-EX <*--------> G25 <-> G27 <-> G29 | |
| 41 | + DF-EX <*----------------> G27 <-> G29 | |
| 42 | + DF-EX <*------------------------> G29 | |
| 43 | + | |
| 38 | 44 | DFGT: |
| 39 | 45 | DF-EX <*> DFP <-> DFGT |
| 40 | 46 | DF-EX <*--------> DFGT |
| @@ -50,3 +56,12 @@ Description: Displays the real model of the wheel regardless of any · 9 unmodified lines | ||
| 50 | 56 | alternate mode the wheel might be switched to. |
| 51 | 57 | It is a read-only value. |
| 52 | 58 | This entry is not created for devices that have only one mode. |
| 59 | + | |
| 60 | +What: /sys/bus/hid/drivers/logitech/<dev>/combine_pedals | |
| 61 | +Date: Sep 2016 | |
| 62 | +KernelVersion: 4.9 | |
| 63 | +Contact: Simon Wood <simon@mungewell.org> | |
| 64 | +Description: Controls whether a combined value of accelerator and brake is | |
| 65 | + reported on the Y axis of the controller. Useful for older games | |
| 66 | + which can do not work with separate accelerator/brake axis. | |
| 67 | + Off ('0') by default, enabled by setting '1'. | |
| @@ -24,6 +24,7 @@ What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance · 23 unmodified lines | ||
| 24 | 24 | Date: August 2014 |
| 25 | 25 | Contact: linux-input@vger.kernel.org |
| 26 | 26 | Description: |
| 27 | + <obsoleted by the LED class API now exported by the driver> | |
| 27 | 28 | Writing to this file sets the status LED luminance (1..127) |
| 28 | 29 | when the stylus does not touch the tablet surface, and no |
| 29 | 30 | button is pressed on the stylus. This luminance level is |
| @@ -33,6 +34,7 @@ What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance · 3 unmodified lines | ||
| 33 | 34 | Date: August 2014 |
| 34 | 35 | Contact: linux-input@vger.kernel.org |
| 35 | 36 | Description: |
| 37 | + <obsoleted by the LED class API now exported by the driver> | |
| 36 | 38 | Writing to this file sets the status LED luminance (1..127) |
| 37 | 39 | when the stylus touches the tablet surface, or any button is |
| 38 | 40 | pressed on the stylus. |
| @@ -41,6 +43,7 @@ What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select · 2 unmodified lines | ||
| 41 | 43 | Date: August 2014 |
| 42 | 44 | Contact: linux-input@vger.kernel.org |
| 43 | 45 | Description: |
| 46 | + <obsoleted by the LED class API now exported by the driver> | |
| 44 | 47 | Writing to this file sets which one of the four (for Intuos 4 |
| 45 | 48 | and Intuos 5) or of the right four (for Cintiq 21UX2 and Cintiq |
| 46 | 49 | 24HD) status LEDs is active (0..3). The other three LEDs on the |
| @@ -50,6 +53,7 @@ What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select · 3 unmodified lines | ||
| 50 | 53 | Date: August 2014 |
| 51 | 54 | Contact: linux-input@vger.kernel.org |
| 52 | 55 | Description: |
| 56 | + <obsoleted by the LED class API now exported by the driver> | |
| 53 | 57 | Writing to this file sets which one of the left four (for Cintiq 21UX2 |
| 54 | 58 | and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on |
| 55 | 59 | the left are always inactive. |
| @@ -91,6 +95,7 @@ What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/<serial_number>/r · 35 unmodified lines | ||
| 91 | 95 | Date: July 2015 |
| 92 | 96 | Contact: linux-input@vger.kernel.org |
| 93 | 97 | Description: |
| 98 | + <obsoleted by the LED class API now exported by the driver> | |
| 94 | 99 | Reading from this file reports the mode status of the |
| 95 | 100 | remote as indicated by the LED lights on the device. If no |
| 96 | 101 | reports have been received from the paired device, reading |
| @@ -1,31 +0,0 @@ | ||
| 1 | −What: /sys/bus/i2c/devices/<busnum>-<devaddr>/pressure0_input | |
| 2 | −Date: June 2010 | |
| 3 | −Contact: Christoph Mair <christoph.mair@gmail.com> | |
| 4 | −Description: Start a pressure measurement and read the result. Values | |
| 5 | − represent the ambient air pressure in pascal (0.01 millibar). | |
| 6 | − | |
| 7 | − Reading: returns the current air pressure. | |
| 8 | − | |
| 9 | − | |
| 10 | −What: /sys/bus/i2c/devices/<busnum>-<devaddr>/temp0_input | |
| 11 | −Date: June 2010 | |
| 12 | −Contact: Christoph Mair <christoph.mair@gmail.com> | |
| 13 | −Description: Measure the ambient temperature. The returned value represents | |
| 14 | − the ambient temperature in units of 0.1 degree celsius. | |
| 15 | − | |
| 16 | − Reading: returns the current temperature. | |
| 17 | − | |
| 18 | − | |
| 19 | −What: /sys/bus/i2c/devices/<busnum>-<devaddr>/oversampling | |
| 20 | −Date: June 2010 | |
| 21 | −Contact: Christoph Mair <christoph.mair@gmail.com> | |
| 22 | −Description: Tell the bmp085 to use more samples to calculate a pressure | |
| 23 | − value. When writing to this file the chip will use 2^x samples | |
| 24 | − to calculate the next pressure value with x being the value | |
| 25 | − written. Using this feature will decrease RMS noise and | |
| 26 | − increase the measurement time. | |
| 27 | − | |
| 28 | − Reading: returns the current oversampling setting. | |
| 29 | − | |
| 30 | − Writing: sets a new oversampling setting. | |
| 31 | − Accepted values: 0..3. | |
| @@ -0,0 +1,53 @@ | ||
| 1 | +What: /sys/kernel/irq | |
| 2 | +Date: September 2016 | |
| 3 | +KernelVersion: 4.9 | |
| 4 | +Contact: Craig Gallek <kraig@google.com> | |
| 5 | +Description: Directory containing information about the system's IRQs. | |
| 6 | + Specifically, data from the associated struct irq_desc. | |
| 7 | + The information here is similar to that in /proc/interrupts | |
| 8 | + but in a more machine-friendly format. This directory contains | |
| 9 | + one subdirectory for each Linux IRQ number. | |
| 10 | + | |
| 11 | +What: /sys/kernel/irq/<irq>/actions | |
| 12 | +Date: September 2016 | |
| 13 | +KernelVersion: 4.9 | |
| 14 | +Contact: Craig Gallek <kraig@google.com> | |
| 15 | +Description: The IRQ action chain. A comma-separated list of zero or more | |
| 16 | + device names associated with this interrupt. | |
| 17 | + | |
| 18 | +What: /sys/kernel/irq/<irq>/chip_name | |
| 19 | +Date: September 2016 | |
| 20 | +KernelVersion: 4.9 | |
| 21 | +Contact: Craig Gallek <kraig@google.com> | |
| 22 | +Description: Human-readable chip name supplied by the associated device | |
| 23 | + driver. | |
| 24 | + | |
| 25 | +What: /sys/kernel/irq/<irq>/hwirq | |
| 26 | +Date: September 2016 | |
| 27 | +KernelVersion: 4.9 | |
| 28 | +Contact: Craig Gallek <kraig@google.com> | |
| 29 | +Description: When interrupt translation domains are used, this file contains | |
| 30 | + the underlying hardware IRQ number used for this Linux IRQ. | |
| 31 | + | |
| 32 | +What: /sys/kernel/irq/<irq>/name | |
| 33 | +Date: September 2016 | |
| 34 | +KernelVersion: 4.9 | |
| 35 | +Contact: Craig Gallek <kraig@google.com> | |
| 36 | +Description: Human-readable flow handler name as defined by the irq chip | |
| 37 | + driver. | |
| 38 | + | |
| 39 | +What: /sys/kernel/irq/<irq>/per_cpu_count | |
| 40 | +Date: September 2016 | |
| 41 | +KernelVersion: 4.9 | |
| 42 | +Contact: Craig Gallek <kraig@google.com> | |
| 43 | +Description: The number of times the interrupt has fired since boot. This | |
| 44 | + is a comma-separated list of counters; one per CPU in CPU id | |
| 45 | + order. NOTE: This file consistently shows counters for all | |
| 46 | + CPU ids. This differs from the behavior of /proc/interrupts | |
| 47 | + which only shows counters for online CPUs. | |
| 48 | + | |
| 49 | +What: /sys/kernel/irq/<irq>/type | |
| 50 | +Date: September 2016 | |
| 51 | +KernelVersion: 4.9 | |
| 52 | +Contact: Craig Gallek <kraig@google.com> | |
| 53 | +Description: The type of the interrupt. Either the string 'level' or 'edge'. | |
| @@ -1,8 +1,13 @@ | ||
| 1 | +.. _changes: | |
| 2 | + | |
| 3 | +Minimal requerements to compile the Kernel | |
| 4 | +++++++++++++++++++++++++++++++++++++++++++ | |
| 5 | + | |
| 1 | 6 | Intro |
| 2 | 7 | ===== |
| 3 | 8 | |
| 4 | 9 | This document is designed to provide a list of the minimum levels of |
| 5 | −software necessary to run the 3.0 kernels. | |
| 10 | +software necessary to run the 4.x kernels. | |
| 6 | 11 | |
| 7 | 12 | This document is originally based on my "Changes" file for 2.0.x kernels |
| 8 | 13 | and therefore owes credit to the same people as that file (Jared Mauch, |
| @@ -10,9 +15,9 @@ Axel Boldt, Alessandro Sigala, and countless other users all over the · 1 unmodified line | ||
| 10 | 15 | 'net). |
| 11 | 16 | |
| 12 | 17 | Current Minimal Requirements |
| 13 | −============================ | |
| 18 | +**************************** | |
| 14 | 19 | |
| 15 | −Upgrade to at *least* these software revisions before thinking you've | |
| 20 | +Upgrade to at **least** these software revisions before thinking you've | |
| 16 | 21 | encountered a bug! If you're unsure what version you're currently |
| 17 | 22 | running, the suggested command should tell you. |
| 18 | 23 | |
| @@ -21,34 +26,40 @@ running a Linux kernel. Also, not all tools are necessary on all · 2 unmodified lines | ||
| 21 | 26 | systems; obviously, if you don't have any ISDN hardware, for example, |
| 22 | 27 | you probably needn't concern yourself with isdn4k-utils. |
| 23 | 28 | |
| 24 | −o GNU C 3.2 # gcc --version | |
| 25 | −o GNU make 3.80 # make --version | |
| 26 | −o binutils 2.12 # ld -v | |
| 27 | −o util-linux 2.10o # fdformat --version | |
| 28 | −o module-init-tools 0.9.10 # depmod -V | |
| 29 | −o e2fsprogs 1.41.4 # e2fsck -V | |
| 30 | −o jfsutils 1.1.3 # fsck.jfs -V | |
| 31 | −o reiserfsprogs 3.6.3 # reiserfsck -V | |
| 32 | −o xfsprogs 2.6.0 # xfs_db -V | |
| 33 | −o squashfs-tools 4.0 # mksquashfs -version | |
| 34 | −o btrfs-progs 0.18 # btrfsck | |
| 35 | −o pcmciautils 004 # pccardctl -V | |
| 36 | −o quota-tools 3.09 # quota -V | |
| 37 | −o PPP 2.4.0 # pppd --version | |
| 38 | −o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version | |
| 39 | −o nfs-utils 1.0.5 # showmount --version | |
| 40 | −o procps 3.2.0 # ps --version | |
| 41 | −o oprofile 0.9 # oprofiled --version | |
| 42 | −o udev 081 # udevd --version | |
| 43 | −o grub 0.93 # grub --version || grub-install --version | |
| 44 | −o mcelog 0.6 # mcelog --version | |
| 45 | −o iptables 1.4.2 # iptables -V | |
| 46 | −o openssl & libcrypto 1.0.0 # openssl version | |
| 47 | −o bc 1.06.95 # bc --version | |
| 48 | − | |
| 29 | +====================== =============== ======================================== | |
| 30 | + Program Minimal version Command to check the version | |
| 31 | +====================== =============== ======================================== | |
| 32 | +GNU C 3.2 gcc --version | |
| 33 | +GNU make 3.80 make --version | |
| 34 | +binutils 2.12 ld -v | |
| 35 | +util-linux 2.10o fdformat --version | |
| 36 | +module-init-tools 0.9.10 depmod -V | |
| 37 | +e2fsprogs 1.41.4 e2fsck -V | |
| 38 | +jfsutils 1.1.3 fsck.jfs -V | |
| 39 | +reiserfsprogs 3.6.3 reiserfsck -V | |
| 40 | +xfsprogs 2.6.0 xfs_db -V | |
| 41 | +squashfs-tools 4.0 mksquashfs -version | |
| 42 | +btrfs-progs 0.18 btrfsck | |
| 43 | +pcmciautils 004 pccardctl -V | |
| 44 | +quota-tools 3.09 quota -V | |
| 45 | +PPP 2.4.0 pppd --version | |
| 46 | +isdn4k-utils 3.1pre1 isdnctrl 2>&1|grep version | |
| 47 | +nfs-utils 1.0.5 showmount --version | |
| 48 | +procps 3.2.0 ps --version | |
| 49 | +oprofile 0.9 oprofiled --version | |
| 50 | +udev 081 udevd --version | |
| 51 | +grub 0.93 grub --version || grub-install --version | |
| 52 | +mcelog 0.6 mcelog --version | |
| 53 | +iptables 1.4.2 iptables -V | |
| 54 | +openssl & libcrypto 1.0.0 openssl version | |
| 55 | +bc 1.06.95 bc --version | |
| 56 | +Sphinx\ [#f1]_ 1.2 sphinx-build --version | |
| 57 | +====================== =============== ======================================== | |
| 58 | + | |
| 59 | +.. [#f1] Sphinx is needed only to build the Kernel documentation | |
| 49 | 60 | |
| 50 | 61 | Kernel compilation |
| 51 | −================== | |
| 62 | +****************** | |
| 52 | 63 | |
| 53 | 64 | GCC |
| 54 | 65 | --- |
| @@ -64,16 +75,16 @@ You will need GNU make 3.80 or later to build the kernel. · 9 unmodified lines | ||
| 64 | 75 | Binutils |
| 65 | 76 | -------- |
| 66 | 77 | |
| 67 | −Linux on IA-32 has recently switched from using as86 to using gas for | |
| 68 | −assembling the 16-bit boot code, removing the need for as86 to compile | |
| 78 | +Linux on IA-32 has recently switched from using ``as86`` to using ``gas`` for | |
| 79 | +assembling the 16-bit boot code, removing the need for ``as86`` to compile | |
| 69 | 80 | your kernel. This change does, however, mean that you need a recent |
| 70 | 81 | release of binutils. |
| 71 | 82 | |
| 72 | 83 | Perl |
| 73 | 84 | ---- |
| 74 | 85 | |
| 75 | −You will need perl 5 and the following modules: Getopt::Long, Getopt::Std, | |
| 76 | −File::Basename, and File::Find to build the kernel. | |
| 86 | +You will need perl 5 and the following modules: ``Getopt::Long``, | |
| 87 | +``Getopt::Std``, ``File::Basename``, and ``File::Find`` to build the kernel. | |
| 77 | 88 | |
| 78 | 89 | BC |
| 79 | 90 | -- |
| @@ -93,7 +104,7 @@ and higher. · 13 unmodified lines | ||
| 93 | 104 | |
| 94 | 105 | |
| 95 | 106 | System utilities |
| 96 | −================ | |
| 107 | +**************** | |
| 97 | 108 | |
| 98 | 109 | Architectural changes |
| 99 | 110 | --------------------- |
| @@ -115,7 +126,7 @@ well as the desired DocBook stylesheets. · 15 unmodified lines | ||
| 115 | 126 | Util-linux |
| 116 | 127 | ---------- |
| 117 | 128 | |
| 118 | −New versions of util-linux provide *fdisk support for larger disks, | |
| 129 | +New versions of util-linux provide ``fdisk`` support for larger disks, | |
| 119 | 130 | support new options to mount, recognize more supported partition |
| 120 | 131 | types, have a fdformat which works with 2.4 kernels, and similar goodies. |
| 121 | 132 | You'll probably want to upgrade. |
| @@ -125,54 +136,57 @@ Ksymoops · 3 unmodified lines | ||
| 125 | 136 | |
| 126 | 137 | If the unthinkable happens and your kernel oopses, you may need the |
| 127 | 138 | ksymoops tool to decode it, but in most cases you don't. |
| 128 | −It is generally preferred to build the kernel with CONFIG_KALLSYMS so | |
| 139 | +It is generally preferred to build the kernel with ``CONFIG_KALLSYMS`` so | |
| 129 | 140 | that it produces readable dumps that can be used as-is (this also |
| 130 | 141 | produces better output than ksymoops). If for some reason your kernel |
| 131 | −is not build with CONFIG_KALLSYMS and you have no way to rebuild and | |
| 142 | +is not build with ``CONFIG_KALLSYMS`` and you have no way to rebuild and | |
| 132 | 143 | reproduce the Oops with that option, then you can still decode that Oops |
| 133 | 144 | with ksymoops. |
| 134 | 145 | |
| 135 | 146 | Module-Init-Tools |
| 136 | 147 | ----------------- |
| 137 | 148 | |
| 138 | −A new module loader is now in the kernel that requires module-init-tools | |
| 149 | +A new module loader is now in the kernel that requires ``module-init-tools`` | |
| 139 | 150 | to use. It is backward compatible with the 2.4.x series kernels. |
| 140 | 151 | |
| 141 | 152 | Mkinitrd |
| 142 | 153 | -------- |
| 143 | 154 | |
| 144 | −These changes to the /lib/modules file tree layout also require that | |
| 155 | +These changes to the ``/lib/modules`` file tree layout also require that | |
| 145 | 156 | mkinitrd be upgraded. |
| 146 | 157 | |
| 147 | 158 | E2fsprogs |
| 148 | 159 | --------- |
| 149 | 160 | |
| 150 | −The latest version of e2fsprogs fixes several bugs in fsck and | |
| 161 | +The latest version of ``e2fsprogs`` fixes several bugs in fsck and | |
| 151 | 162 | debugfs. Obviously, it's a good idea to upgrade. |
| 152 | 163 | |
| 153 | 164 | JFSutils |
| 154 | 165 | -------- |
| 155 | 166 | |
| 156 | −The jfsutils package contains the utilities for the file system. | |
| 167 | +The ``jfsutils`` package contains the utilities for the file system. | |
| 157 | 168 | The following utilities are available: |
| 158 | −o fsck.jfs - initiate replay of the transaction log, and check | |
| 169 | + | |
| 170 | +- ``fsck.jfs`` - initiate replay of the transaction log, and check | |
| 159 | 171 | and repair a JFS formatted partition. |
| 160 | −o mkfs.jfs - create a JFS formatted partition. | |
| 161 | −o other file system utilities are also available in this package. | |
| 172 | + | |
| 173 | +- ``mkfs.jfs`` - create a JFS formatted partition. | |
| 174 | + | |
| 175 | +- other file system utilities are also available in this package. | |
| 162 | 176 | |
| 163 | 177 | Reiserfsprogs |
| 164 | 178 | ------------- |
| 165 | 179 | |
| 166 | 180 | The reiserfsprogs package should be used for reiserfs-3.6.x |
| 167 | 181 | (Linux kernels 2.4.x). It is a combined package and contains working |
| 168 | −versions of mkreiserfs, resize_reiserfs, debugreiserfs and | |
| 169 | −reiserfsck. These utils work on both i386 and alpha platforms. | |
| 182 | +versions of ``mkreiserfs``, ``resize_reiserfs``, ``debugreiserfs`` and | |
| 183 | +``reiserfsck``. These utils work on both i386 and alpha platforms. | |
| 170 | 184 | |
| 171 | 185 | Xfsprogs |
| 172 | 186 | -------- |
| 173 | 187 | |
| 174 | −The latest version of xfsprogs contains mkfs.xfs, xfs_db, and the | |
| 175 | −xfs_repair utilities, among others, for the XFS filesystem. It is | |
| 188 | +The latest version of ``xfsprogs`` contains ``mkfs.xfs``, ``xfs_db``, and the | |
| 189 | +``xfs_repair`` utilities, among others, for the XFS filesystem. It is | |
| 176 | 190 | architecture independent and any version from 2.0.0 onward should |
| 177 | 191 | work correctly with this version of the XFS kernel code (2.6.0 or |
| 178 | 192 | later is recommended, due to some significant improvements). |
| @@ -180,7 +194,7 @@ later is recommended, due to some significant improvements). · 1 unmodified line | ||
| 180 | 194 | PCMCIAutils |
| 181 | 195 | ----------- |
| 182 | 196 | |
| 183 | −PCMCIAutils replaces pcmcia-cs. It properly sets up | |
| 197 | +PCMCIAutils replaces ``pcmcia-cs``. It properly sets up | |
| 184 | 198 | PCMCIA sockets at system startup and loads the appropriate modules |
| 185 | 199 | for 16-bit PCMCIA devices if the kernel is modularized and the hotplug |
| 186 | 200 | subsystem is used. |
| @@ -198,19 +212,20 @@ Intel IA32 microcode · 11 unmodified lines | ||
| 198 | 212 | |
| 199 | 213 | A driver has been added to allow updating of Intel IA32 microcode, |
| 200 | 214 | accessible as a normal (misc) character device. If you are not using |
| 201 | −udev you may need to: | |
| 215 | +udev you may need to:: | |
| 202 | 216 | |
| 203 | −mkdir /dev/cpu | |
| 204 | −mknod /dev/cpu/microcode c 10 184 | |
| 205 | −chmod 0644 /dev/cpu/microcode | |
| 217 | + mkdir /dev/cpu | |
| 218 | + mknod /dev/cpu/microcode c 10 184 | |
| 219 | + chmod 0644 /dev/cpu/microcode | |
| 206 | 220 | |
| 207 | 221 | as root before you can use this. You'll probably also want to |
| 208 | 222 | get the user-space microcode_ctl utility to use with this. |
| 209 | 223 | |
| 210 | 224 | udev |
| 211 | 225 | ---- |
| 212 | −udev is a userspace application for populating /dev dynamically with | |
| 213 | −only entries for devices actually present. udev replaces the basic | |
| 226 | + | |
| 227 | +``udev`` is a userspace application for populating ``/dev`` dynamically with | |
| 228 | +only entries for devices actually present. ``udev`` replaces the basic | |
| 214 | 229 | functionality of devfs, while allowing persistent device naming for |
| 215 | 230 | devices. |
| 216 | 231 | |
| @@ -218,10 +233,10 @@ FUSE · 1 unmodified line | ||
| 218 | 233 | ---- |
| 219 | 234 | |
| 220 | 235 | Needs libfuse 2.4.0 or later. Absolute minimum is 2.3.0 but mount |
| 221 | −options 'direct_io' and 'kernel_cache' won't work. | |
| 236 | +options ``direct_io`` and ``kernel_cache`` won't work. | |
| 222 | 237 | |
| 223 | 238 | Networking |
| 224 | −========== | |
| 239 | +********** | |
| 225 | 240 | |
| 226 | 241 | General changes |
| 227 | 242 | --------------- |
| @@ -243,9 +258,9 @@ enable it to operate over diverse media layers. If you use PPP, · 15 unmodified lines | ||
| 243 | 258 | upgrade pppd to at least 2.4.0. |
| 244 | 259 | |
| 245 | 260 | If you are not using udev, you must have the device file /dev/ppp |
| 246 | −which can be made by: | |
| 261 | +which can be made by:: | |
| 247 | 262 | |
| 248 | −mknod /dev/ppp c 108 0 | |
| 263 | + mknod /dev/ppp c 108 0 | |
| 249 | 264 | |
| 250 | 265 | as root. |
| 251 | 266 | |
| @@ -260,22 +275,22 @@ NFS-utils · 8 unmodified lines | ||
| 260 | 275 | |
| 261 | 276 | In ancient (2.4 and earlier) kernels, the nfs server needed to know |
| 262 | 277 | about any client that expected to be able to access files via NFS. This |
| 263 | −information would be given to the kernel by "mountd" when the client | |
| 264 | −mounted the filesystem, or by "exportfs" at system startup. exportfs | |
| 265 | −would take information about active clients from /var/lib/nfs/rmtab. | |
| 278 | +information would be given to the kernel by ``mountd`` when the client | |
| 279 | +mounted the filesystem, or by ``exportfs`` at system startup. exportfs | |
| 280 | +would take information about active clients from ``/var/lib/nfs/rmtab``. | |
| 266 | 281 | |
| 267 | 282 | This approach is quite fragile as it depends on rmtab being correct |
| 268 | 283 | which is not always easy, particularly when trying to implement |
| 269 | −fail-over. Even when the system is working well, rmtab suffers from | |
| 284 | +fail-over. Even when the system is working well, ``rmtab`` suffers from | |
| 270 | 285 | getting lots of old entries that never get removed. |
| 271 | 286 | |
| 272 | 287 | With modern kernels we have the option of having the kernel tell mountd |
| 273 | 288 | when it gets a request from an unknown host, and mountd can give |
| 274 | 289 | appropriate export information to the kernel. This removes the |
| 275 | −dependency on rmtab and means that the kernel only needs to know about | |
| 290 | +dependency on ``rmtab`` and means that the kernel only needs to know about | |
| 276 | 291 | currently active clients. |
| 277 | 292 | |
| 278 | −To enable this new functionality, you need to: | |
| 293 | +To enable this new functionality, you need to:: | |
| 279 | 294 | |
| 280 | 295 | mount -t nfsd nfsd /proc/fs/nfsd |
| 281 | 296 | |
| @@ -287,8 +302,32 @@ mcelog · 5 unmodified lines | ||
| 287 | 302 | ------ |
| 288 | 303 | |
| 289 | 304 | On x86 kernels the mcelog utility is needed to process and log machine check |
| 290 | −events when CONFIG_X86_MCE is enabled. Machine check events are errors reported | |
| 291 | −by the CPU. Processing them is strongly encouraged. | |
| 305 | +events when ``CONFIG_X86_MCE`` is enabled. Machine check events are errors | |
| 306 | +reported by the CPU. Processing them is strongly encouraged. | |
| 307 | + | |
| 308 | +Kernel documentation | |
| 309 | +******************** | |
| 310 | + | |
| 311 | +Sphinx | |
| 312 | +------ | |
| 313 | + | |
| 314 | +The ReST markups currently used by the Documentation/ files are meant to be | |
| 315 | +built with ``Sphinx`` version 1.2 or upper. If you're desiring to build | |
| 316 | +PDF outputs, it is recommended to use version 1.4.6. | |
| 317 | + | |
| 318 | +.. note:: | |
| 319 | + | |
| 320 | + Please notice that, for PDF and LaTeX output, you'll also need ``XeLaTeX`` | |
| 321 | + version 3.14159265. Depending on the distribution, you may also need | |
| 322 | + to install a series of ``texlive`` packages that provide the minimal | |
| 323 | + set of functionalities required for ``XeLaTex`` to work. | |
| 324 | + | |
| 325 | +Other tools | |
| 326 | +----------- | |
| 327 | + | |
| 328 | +In order to produce documentation from DocBook, you'll also need ``xmlto``. | |
| 329 | +Please notice, however, that we're currently migrating all documents to use | |
| 330 | +``Sphinx``. | |
| 292 | 331 | |
| 293 | 332 | Getting updated software |
| 294 | 333 | ======================== |
| @@ -298,114 +337,149 @@ Kernel compilation · 3 unmodified lines | ||
| 298 | 337 | |
| 299 | 338 | gcc |
| 300 | 339 | --- |
| 301 | −o <ftp://ftp.gnu.org/gnu/gcc/> | |
| 340 | + | |
| 341 | +- <ftp://ftp.gnu.org/gnu/gcc/> | |
| 302 | 342 | |
| 303 | 343 | Make |
| 304 | 344 | ---- |
| 305 | −o <ftp://ftp.gnu.org/gnu/make/> | |
| 345 | + | |
| 346 | +- <ftp://ftp.gnu.org/gnu/make/> | |
| 306 | 347 | |
| 307 | 348 | Binutils |
| 308 | 349 | -------- |
| 309 | −o <ftp://ftp.kernel.org/pub/linux/devel/binutils/> | |
| 350 | + | |
| 351 | +- <ftp://ftp.kernel.org/pub/linux/devel/binutils/> | |
| 310 | 352 | |
| 311 | 353 | OpenSSL |
| 312 | 354 | ------- |
| 313 | −o <https://www.openssl.org/> | |
| 355 | + | |
| 356 | +- <https://www.openssl.org/> | |
| 314 | 357 | |
| 315 | 358 | System utilities |
| 316 | 359 | **************** |
| 317 | 360 | |
| 318 | 361 | Util-linux |
| 319 | 362 | ---------- |
| 320 | −o <ftp://ftp.kernel.org/pub/linux/utils/util-linux/> | |
| 363 | + | |
| 364 | +- <ftp://ftp.kernel.org/pub/linux/utils/util-linux/> | |
| 321 | 365 | |
| 322 | 366 | Ksymoops |
| 323 | 367 | -------- |
| 324 | −o <ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/> | |
| 368 | + | |
| 369 | +- <ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/> | |
| 325 | 370 | |
| 326 | 371 | Module-Init-Tools |
| 327 | 372 | ----------------- |
| 328 | −o <ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/> | |
| 373 | + | |
| 374 | +- <ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/> | |
| 329 | 375 | |
| 330 | 376 | Mkinitrd |
| 331 | 377 | -------- |
| 332 | −o <https://code.launchpad.net/initrd-tools/main> | |
| 378 | + | |
| 379 | +- <https://code.launchpad.net/initrd-tools/main> | |
| 333 | 380 | |
| 334 | 381 | E2fsprogs |
| 335 | 382 | --------- |
| 336 | −o <http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.29.tar.gz> | |
| 383 | + | |
| 384 | +- <http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.29.tar.gz> | |
| 337 | 385 | |
| 338 | 386 | JFSutils |
| 339 | 387 | -------- |
| 340 | −o <http://jfs.sourceforge.net/> | |
| 388 | + | |
| 389 | +- <http://jfs.sourceforge.net/> | |
| 341 | 390 | |
| 342 | 391 | Reiserfsprogs |
| 343 | 392 | ------------- |
| 344 | −o <http://www.kernel.org/pub/linux/utils/fs/reiserfs/> | |
| 393 | + | |
| 394 | +- <http://www.kernel.org/pub/linux/utils/fs/reiserfs/> | |
| 345 | 395 | |
| 346 | 396 | Xfsprogs |
| 347 | 397 | -------- |
| 348 | −o <ftp://oss.sgi.com/projects/xfs/> | |
| 398 | + | |
| 399 | +- <ftp://oss.sgi.com/projects/xfs/> | |
| 349 | 400 | |
| 350 | 401 | Pcmciautils |
| 351 | 402 | ----------- |
| 352 | −o <ftp://ftp.kernel.org/pub/linux/utils/kernel/pcmcia/> | |
| 403 | + | |
| 404 | +- <ftp://ftp.kernel.org/pub/linux/utils/kernel/pcmcia/> | |
| 353 | 405 | |
| 354 | 406 | Quota-tools |
| 355 | −---------- | |
| 356 | −o <http://sourceforge.net/projects/linuxquota/> | |
| 407 | +----------- | |
| 408 | + | |
| 409 | +- <http://sourceforge.net/projects/linuxquota/> | |
| 357 | 410 | |
| 358 | 411 | DocBook Stylesheets |
| 359 | 412 | ------------------- |
| 360 | −o <http://sourceforge.net/projects/docbook/files/docbook-dsssl/> | |
| 413 | + | |
| 414 | +- <http://sourceforge.net/projects/docbook/files/docbook-dsssl/> | |
| 361 | 415 | |
| 362 | 416 | XMLTO XSLT Frontend |
| 363 | 417 | ------------------- |
| 364 | −o <http://cyberelk.net/tim/xmlto/> | |
| 418 | + | |
| 419 | +- <http://cyberelk.net/tim/xmlto/> | |
| 365 | 420 | |
| 366 | 421 | Intel P6 microcode |
| 367 | 422 | ------------------ |
| 368 | −o <https://downloadcenter.intel.com/> | |
| 423 | + | |
| 424 | +- <https://downloadcenter.intel.com/> | |
| 369 | 425 | |
| 370 | 426 | udev |
| 371 | 427 | ---- |
| 372 | −o <http://www.freedesktop.org/software/systemd/man/udev.html> | |
| 428 | + | |
| 429 | +- <http://www.freedesktop.org/software/systemd/man/udev.html> | |
| 373 | 430 | |
| 374 | 431 | FUSE |
| 375 | 432 | ---- |
| 376 | −o <http://sourceforge.net/projects/fuse> | |
| 433 | + | |
| 434 | +- <http://sourceforge.net/projects/fuse> | |
| 377 | 435 | |
| 378 | 436 | mcelog |
| 379 | 437 | ------ |
| 380 | −o <http://www.mcelog.org/> | |
| 438 | + | |
| 439 | +- <http://www.mcelog.org/> | |
| 381 | 440 | |
| 382 | 441 | Networking |
| 383 | 442 | ********** |
| 384 | 443 | |
| 385 | 444 | PPP |
| 386 | 445 | --- |
| 387 | −o <ftp://ftp.samba.org/pub/ppp/> | |
| 446 | + | |
| 447 | +- <ftp://ftp.samba.org/pub/ppp/> | |
| 388 | 448 | |
| 389 | 449 | Isdn4k-utils |
| 390 | 450 | ------------ |
| 391 | −o <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/> | |
| 451 | + | |
| 452 | +- <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/> | |
| 392 | 453 | |
| 393 | 454 | NFS-utils |
| 394 | 455 | --------- |
| 395 | −o <http://sourceforge.net/project/showfiles.php?group_id=14> | |
| 456 | + | |
| 457 | +- <http://sourceforge.net/project/showfiles.php?group_id=14> | |
| 396 | 458 | |
| 397 | 459 | Iptables |
| 398 | 460 | -------- |
| 399 | −o <http://www.iptables.org/downloads.html> | |
| 461 | + | |
| 462 | +- <http://www.iptables.org/downloads.html> | |
| 400 | 463 | |
| 401 | 464 | Ip-route2 |
| 402 | 465 | --------- |
| 403 | −o <https://www.kernel.org/pub/linux/utils/net/iproute2/> | |
| 466 | + | |
| 467 | +- <https://www.kernel.org/pub/linux/utils/net/iproute2/> | |
| 404 | 468 | |
| 405 | 469 | OProfile |
| 406 | 470 | -------- |
| 407 | −o <http://oprofile.sf.net/download/> | |
| 471 | + | |
| 472 | +- <http://oprofile.sf.net/download/> | |
| 408 | 473 | |
| 409 | 474 | NFS-Utils |
| 410 | 475 | --------- |
| 411 | −o <http://nfs.sourceforge.net/> | |
| 476 | + | |
| 477 | +- <http://nfs.sourceforge.net/> | |
| 478 | + | |
| 479 | +Kernel documentation | |
| 480 | +******************** | |
| 481 | + | |
| 482 | +Sphinx | |
| 483 | +------ | |
| 484 | + | |
| 485 | +- <http://www.sphinx-doc.org/> | |
| @@ -19,7 +19,7 @@ please contact the Linux Foundation's Technical Advisory Board at · 18 unmodified lines | ||
| 19 | 19 | will work to resolve the issue to the best of their ability. For more |
| 20 | 20 | information on who is on the Technical Advisory Board and what their |
| 21 | 21 | role is, please see: |
| 22 | − http://www.linuxfoundation.org/programs/advisory-councils/tab | |
| 22 | + http://www.linuxfoundation.org/projects/linux/tab | |
| 23 | 23 | |
| 24 | 24 | As a reviewer of code, please strive to keep things civil and focused on |
| 25 | 25 | the technical issues involved. We are all humans, and frustrations can |
| @@ -1,8 +1,10 @@ | ||
| 1 | +.. _codingstyle: | |
| 1 | 2 | |
| 2 | − Linux kernel coding style | |
| 3 | +Linux kernel coding style | |
| 4 | +========================= | |
| 3 | 5 | |
| 4 | 6 | This is a short document describing the preferred coding style for the |
| 5 | −linux kernel. Coding style is very personal, and I won't _force_ my | |
| 7 | +linux kernel. Coding style is very personal, and I won't **force** my | |
| 6 | 8 | views on anybody, but this is what goes for anything that I have to be |
| 7 | 9 | able to maintain, and I'd prefer it for most other things too. Please |
| 8 | 10 | at least consider the points made here. |
| @@ -13,7 +15,8 @@ and NOT read it. Burn them, it's a great symbolic gesture. · 4 unmodified lines | ||
| 13 | 15 | Anyway, here goes: |
| 14 | 16 | |
| 15 | 17 | |
| 16 | − Chapter 1: Indentation | |
| 18 | +1) Indentation | |
| 19 | +-------------- | |
| 17 | 20 | |
| 18 | 21 | Tabs are 8 characters, and thus indentations are also 8 characters. |
| 19 | 22 | There are heretic movements that try to make indentations 4 (or even 2!) |
| @@ -36,8 +39,10 @@ benefit of warning you when you're nesting your functions too deep. · 16 unmodified lines | ||
| 36 | 39 | Heed that warning. |
| 37 | 40 | |
| 38 | 41 | The preferred way to ease multiple indentation levels in a switch statement is |
| 39 | −to align the "switch" and its subordinate "case" labels in the same column | |
| 40 | −instead of "double-indenting" the "case" labels. E.g.: | |
| 42 | +to align the ``switch`` and its subordinate ``case`` labels in the same column | |
| 43 | +instead of ``double-indenting`` the ``case`` labels. E.g.: | |
| 44 | + | |
| 45 | +.. code-block:: c | |
| 41 | 46 | |
| 42 | 47 | switch (suffix) { |
| 43 | 48 | case 'G': |
| @@ -59,6 +64,8 @@ instead of "double-indenting" the "case" labels. E.g.: · 15 unmodified lines | ||
| 59 | 64 | Don't put multiple statements on a single line unless you have |
| 60 | 65 | something to hide: |
| 61 | 66 | |
| 67 | +.. code-block:: c | |
| 68 | + | |
| 62 | 69 | if (condition) do_this; |
| 63 | 70 | do_something_everytime; |
| 64 | 71 | |
| @@ -71,7 +78,8 @@ used for indentation, and the above example is deliberately broken. · 6 unmodified lines | ||
| 71 | 78 | Get a decent editor and don't leave whitespace at the end of lines. |
| 72 | 79 | |
| 73 | 80 | |
| 74 | − Chapter 2: Breaking long lines and strings | |
| 81 | +2) Breaking long lines and strings | |
| 82 | +---------------------------------- | |
| 75 | 83 | |
| 76 | 84 | Coding style is all about readability and maintainability using commonly |
| 77 | 85 | available tools. |
| @@ -87,7 +95,8 @@ with a long argument list. However, never break user-visible strings such as · 9 unmodified lines | ||
| 87 | 95 | printk messages, because that breaks the ability to grep for them. |
| 88 | 96 | |
| 89 | 97 | |
| 90 | − Chapter 3: Placing Braces and Spaces | |
| 98 | +3) Placing Braces and Spaces | |
| 99 | +---------------------------- | |
| 91 | 100 | |
| 92 | 101 | The other issue that always comes up in C styling is the placement of |
| 93 | 102 | braces. Unlike the indent size, there are few technical reasons to |
| @@ -95,6 +104,8 @@ choose one placement strategy over the other, but the preferred way, as · 1 unmodified line | ||
| 95 | 104 | shown to us by the prophets Kernighan and Ritchie, is to put the opening |
| 96 | 105 | brace last on the line, and put the closing brace first, thusly: |
| 97 | 106 | |
| 107 | +.. code-block:: c | |
| 108 | + | |
| 98 | 109 | if (x is true) { |
| 99 | 110 | we do y |
| 100 | 111 | } |
| @@ -102,6 +113,8 @@ brace last on the line, and put the closing brace first, thusly: · 1 unmodified line | ||
| 102 | 113 | This applies to all non-function statement blocks (if, switch, for, |
| 103 | 114 | while, do). E.g.: |
| 104 | 115 | |
| 116 | +.. code-block:: c | |
| 117 | + | |
| 105 | 118 | switch (action) { |
| 106 | 119 | case KOBJ_ADD: |
| 107 | 120 | return "add"; |
| @@ -116,6 +129,8 @@ while, do). E.g.: · 8 unmodified lines | ||
| 116 | 129 | However, there is one special case, namely functions: they have the |
| 117 | 130 | opening brace at the beginning of the next line, thus: |
| 118 | 131 | |
| 132 | +.. code-block:: c | |
| 133 | + | |
| 119 | 134 | int function(int x) |
| 120 | 135 | { |
| 121 | 136 | body of function |
| @@ -123,20 +138,24 @@ opening brace at the beginning of the next line, thus: · 1 unmodified line | ||
| 123 | 138 | |
| 124 | 139 | Heretic people all over the world have claimed that this inconsistency |
| 125 | 140 | is ... well ... inconsistent, but all right-thinking people know that |
| 126 | −(a) K&R are _right_ and (b) K&R are right. Besides, functions are | |
| 141 | +(a) K&R are **right** and (b) K&R are right. Besides, functions are | |
| 127 | 142 | special anyway (you can't nest them in C). |
| 128 | 143 | |
| 129 | −Note that the closing brace is empty on a line of its own, _except_ in | |
| 144 | +Note that the closing brace is empty on a line of its own, **except** in | |
| 130 | 145 | the cases where it is followed by a continuation of the same statement, |
| 131 | −ie a "while" in a do-statement or an "else" in an if-statement, like | |
| 146 | +ie a ``while`` in a do-statement or an ``else`` in an if-statement, like | |
| 132 | 147 | this: |
| 133 | 148 | |
| 149 | +.. code-block:: c | |
| 150 | + | |
| 134 | 151 | do { |
| 135 | 152 | body of do-loop |
| 136 | 153 | } while (condition); |
| 137 | 154 | |
| 138 | 155 | and |
| 139 | 156 | |
| 157 | +.. code-block:: c | |
| 158 | + | |
| 140 | 159 | if (x == y) { |
| 141 | 160 | .. |
| 142 | 161 | } else if (x > y) { |
| @@ -155,11 +174,15 @@ comments on. · 12 unmodified lines | ||
| 155 | 174 | |
| 156 | 175 | Do not unnecessarily use braces where a single statement will do. |
| 157 | 176 | |
| 177 | +.. code-block:: c | |
| 178 | + | |
| 158 | 179 | if (condition) |
| 159 | 180 | action(); |
| 160 | 181 | |
| 161 | 182 | and |
| 162 | 183 | |
| 184 | +.. code-block:: none | |
| 185 | + | |
| 163 | 186 | if (condition) |
| 164 | 187 | do_this(); |
| 165 | 188 | else |
| @@ -168,6 +191,8 @@ and · 2 unmodified lines | ||
| 168 | 191 | This does not apply if only one branch of a conditional statement is a single |
| 169 | 192 | statement; in the latter case use braces in both branches: |
| 170 | 193 | |
| 194 | +.. code-block:: c | |
| 195 | + | |
| 171 | 196 | if (condition) { |
| 172 | 197 | do_this(); |
| 173 | 198 | do_that(); |
| @@ -175,57 +200,67 @@ statement; in the latter case use braces in both branches: · 1 unmodified line | ||
| 175 | 200 | otherwise(); |
| 176 | 201 | } |
| 177 | 202 | |
| 178 | − 3.1: Spaces | |
| 203 | +3.1) Spaces | |
| 204 | +*********** | |
| 179 | 205 | |
| 180 | 206 | Linux kernel style for use of spaces depends (mostly) on |
| 181 | 207 | function-versus-keyword usage. Use a space after (most) keywords. The |
| 182 | 208 | notable exceptions are sizeof, typeof, alignof, and __attribute__, which look |
| 183 | 209 | somewhat like functions (and are usually used with parentheses in Linux, |
| 184 | −although they are not required in the language, as in: "sizeof info" after | |
| 185 | −"struct fileinfo info;" is declared). | |
| 210 | +although they are not required in the language, as in: ``sizeof info`` after | |
| 211 | +``struct fileinfo info;`` is declared). | |
| 186 | 212 | |
| 187 | −So use a space after these keywords: | |
| 213 | +So use a space after these keywords:: | |
| 188 | 214 | |
| 189 | 215 | if, switch, case, for, do, while |
| 190 | 216 | |
| 191 | 217 | but not with sizeof, typeof, alignof, or __attribute__. E.g., |
| 192 | 218 | |
| 219 | +.. code-block:: c | |
| 220 | + | |
| 221 | + | |
| 193 | 222 | s = sizeof(struct file); |
| 194 | 223 | |
| 195 | 224 | Do not add spaces around (inside) parenthesized expressions. This example is |
| 196 | −*bad*: | |
| 225 | +**bad**: | |
| 226 | + | |
| 227 | +.. code-block:: c | |
| 228 | + | |
| 197 | 229 | |
| 198 | 230 | s = sizeof( struct file ); |
| 199 | 231 | |
| 200 | 232 | When declaring pointer data or a function that returns a pointer type, the |
| 201 | −preferred use of '*' is adjacent to the data name or function name and not | |
| 233 | +preferred use of ``*`` is adjacent to the data name or function name and not | |
| 202 | 234 | adjacent to the type name. Examples: |
| 203 | 235 | |
| 236 | +.. code-block:: c | |
| 237 | + | |
| 238 | + | |
| 204 | 239 | char *linux_banner; |
| 205 | 240 | unsigned long long memparse(char *ptr, char **retptr); |
| 206 | 241 | char *match_strdup(substring_t *s); |
| 207 | 242 | |
| 208 | 243 | Use one space around (on each side of) most binary and ternary operators, |
| 209 | −such as any of these: | |
| 244 | +such as any of these:: | |
| 210 | 245 | |
| 211 | 246 | = + - < > * / % | & ^ <= >= == != ? : |
| 212 | 247 | |
| 213 | −but no space after unary operators: | |
| 248 | +but no space after unary operators:: | |
| 214 | 249 | |
| 215 | 250 | & * + - ~ ! sizeof typeof alignof __attribute__ defined |
| 216 | 251 | |
| 217 | −no space before the postfix increment & decrement unary operators: | |
| 252 | +no space before the postfix increment & decrement unary operators:: | |
| 218 | 253 | |
| 219 | 254 | ++ -- |
| 220 | 255 | |
| 221 | −no space after the prefix increment & decrement unary operators: | |
| 256 | +no space after the prefix increment & decrement unary operators:: | |
| 222 | 257 | |
| 223 | 258 | ++ -- |
| 224 | 259 | |
| 225 | −and no space around the '.' and "->" structure member operators. | |
| 260 | +and no space around the ``.`` and ``->`` structure member operators. | |
| 226 | 261 | |
| 227 | 262 | Do not leave trailing whitespace at the ends of lines. Some editors with |
| 228 | −"smart" indentation will insert whitespace at the beginning of new lines as | |
| 263 | +``smart`` indentation will insert whitespace at the beginning of new lines as | |
| 229 | 264 | appropriate, so you can start typing the next line of code right away. |
| 230 | 265 | However, some such editors do not remove the whitespace if you end up not |
| 231 | 266 | putting a line of code there, such as if you leave a blank line. As a result, |
| @@ -237,22 +272,23 @@ of patches, this may make later patches in the series fail by changing their · 5 unmodified lines | ||
| 237 | 272 | context lines. |
| 238 | 273 | |
| 239 | 274 | |
| 240 | − Chapter 4: Naming | |
| 275 | +4) Naming | |
| 276 | +--------- | |
| 241 | 277 | |
| 242 | 278 | C is a Spartan language, and so should your naming be. Unlike Modula-2 |
| 243 | 279 | and Pascal programmers, C programmers do not use cute names like |
| 244 | 280 | ThisVariableIsATemporaryCounter. A C programmer would call that |
| 245 | −variable "tmp", which is much easier to write, and not the least more | |
| 281 | +variable ``tmp``, which is much easier to write, and not the least more | |
| 246 | 282 | difficult to understand. |
| 247 | 283 | |
| 248 | 284 | HOWEVER, while mixed-case names are frowned upon, descriptive names for |
| 249 | −global variables are a must. To call a global function "foo" is a | |
| 285 | +global variables are a must. To call a global function ``foo`` is a | |
| 250 | 286 | shooting offense. |
| 251 | 287 | |
| 252 | −GLOBAL variables (to be used only if you _really_ need them) need to | |
| 288 | +GLOBAL variables (to be used only if you **really** need them) need to | |
| 253 | 289 | have descriptive names, as do global functions. If you have a function |
| 254 | 290 | that counts the number of active users, you should call that |
| 255 | −"count_active_users()" or similar, you should _not_ call it "cntusr()". | |
| 291 | +``count_active_users()`` or similar, you should **not** call it ``cntusr()``. | |
| 256 | 292 | |
| 257 | 293 | Encoding the type of a function into the name (so-called Hungarian |
| 258 | 294 | notation) is brain damaged - the compiler knows the types anyway and can |
| @@ -260,9 +296,9 @@ check those, and it only confuses the programmer. No wonder MicroSoft · 1 unmodified line | ||
| 260 | 296 | makes buggy programs. |
| 261 | 297 | |
| 262 | 298 | LOCAL variable names should be short, and to the point. If you have |
| 263 | −some random integer loop counter, it should probably be called "i". | |
| 264 | −Calling it "loop_counter" is non-productive, if there is no chance of it | |
| 265 | −being mis-understood. Similarly, "tmp" can be just about any type of | |
| 299 | +some random integer loop counter, it should probably be called ``i``. | |
| 300 | +Calling it ``loop_counter`` is non-productive, if there is no chance of it | |
| 301 | +being mis-understood. Similarly, ``tmp`` can be just about any type of | |
| 266 | 302 | variable that is used to hold a temporary value. |
| 267 | 303 | |
| 268 | 304 | If you are afraid to mix up your local variable names, you have another |
| @@ -270,59 +306,69 @@ problem, which is called the function-growth-hormone-imbalance syndrome. · 1 unmodified line | ||
| 270 | 306 | See chapter 6 (Functions). |
| 271 | 307 | |
| 272 | 308 | |
| 273 | − Chapter 5: Typedefs | |
| 309 | +5) Typedefs | |
| 310 | +----------- | |
| 311 | + | |
| 312 | +Please don't use things like ``vps_t``. | |
| 313 | +It's a **mistake** to use typedef for structures and pointers. When you see a | |
| 314 | + | |
| 315 | +.. code-block:: c | |
| 274 | 316 | |
| 275 | −Please don't use things like "vps_t". | |
| 276 | −It's a _mistake_ to use typedef for structures and pointers. When you see a | |
| 277 | 317 | |
| 278 | 318 | vps_t a; |
| 279 | 319 | |
| 280 | 320 | in the source, what does it mean? |
| 281 | 321 | In contrast, if it says |
| 282 | 322 | |
| 323 | +.. code-block:: c | |
| 324 | + | |
| 283 | 325 | struct virtual_container *a; |
| 284 | 326 | |
| 285 | −you can actually tell what "a" is. | |
| 327 | +you can actually tell what ``a`` is. | |
| 286 | 328 | |
| 287 | −Lots of people think that typedefs "help readability". Not so. They are | |
| 329 | +Lots of people think that typedefs ``help readability``. Not so. They are | |
| 288 | 330 | useful only for: |
| 289 | 331 | |
| 290 | − (a) totally opaque objects (where the typedef is actively used to _hide_ | |
| 332 | + (a) totally opaque objects (where the typedef is actively used to **hide** | |
| 291 | 333 | what the object is). |
| 292 | 334 | |
| 293 | − Example: "pte_t" etc. opaque objects that you can only access using | |
| 335 | + Example: ``pte_t`` etc. opaque objects that you can only access using | |
| 294 | 336 | the proper accessor functions. |
| 295 | 337 | |
| 296 | − NOTE! Opaqueness and "accessor functions" are not good in themselves. | |
| 297 | − The reason we have them for things like pte_t etc. is that there | |
| 298 | − really is absolutely _zero_ portably accessible information there. | |
| 338 | + .. note:: | |
| 339 | + | |
| 340 | + Opaqueness and ``accessor functions`` are not good in themselves. | |
| 341 | + The reason we have them for things like pte_t etc. is that there | |
| 342 | + really is absolutely **zero** portably accessible information there. | |
| 299 | 343 | |
| 300 | − (b) Clear integer types, where the abstraction _helps_ avoid confusion | |
| 301 | − whether it is "int" or "long". | |
| 344 | + (b) Clear integer types, where the abstraction **helps** avoid confusion | |
| 345 | + whether it is ``int`` or ``long``. | |
| 302 | 346 | |
| 303 | 347 | u8/u16/u32 are perfectly fine typedefs, although they fit into |
| 304 | 348 | category (d) better than here. |
| 305 | 349 | |
| 306 | − NOTE! Again - there needs to be a _reason_ for this. If something is | |
| 307 | − "unsigned long", then there's no reason to do | |
| 350 | + .. note:: | |
| 351 | + | |
| 352 | + Again - there needs to be a **reason** for this. If something is | |
| 353 | + ``unsigned long``, then there's no reason to do | |
| 308 | 354 | |
| 309 | 355 | typedef unsigned long myflags_t; |
| 310 | 356 | |
| 311 | 357 | but if there is a clear reason for why it under certain circumstances |
| 312 | − might be an "unsigned int" and under other configurations might be | |
| 313 | − "unsigned long", then by all means go ahead and use a typedef. | |
| 358 | + might be an ``unsigned int`` and under other configurations might be | |
| 359 | + ``unsigned long``, then by all means go ahead and use a typedef. | |
| 314 | 360 | |
| 315 | − (c) when you use sparse to literally create a _new_ type for | |
| 361 | + (c) when you use sparse to literally create a **new** type for | |
| 316 | 362 | type-checking. |
| 317 | 363 | |
| 318 | 364 | (d) New types which are identical to standard C99 types, in certain |
| 319 | 365 | exceptional circumstances. |
| 320 | 366 | |
| 321 | 367 | Although it would only take a short amount of time for the eyes and |
| 322 | − brain to become accustomed to the standard types like 'uint32_t', | |
| 368 | + brain to become accustomed to the standard types like ``uint32_t``, | |
| 323 | 369 | some people object to their use anyway. |
| 324 | 370 | |
| 325 | − Therefore, the Linux-specific 'u8/u16/u32/u64' types and their | |
| 371 | + Therefore, the Linux-specific ``u8/u16/u32/u64`` types and their | |
| 326 | 372 | signed equivalents which are identical to standard types are |
| 327 | 373 | permitted -- although they are not mandatory in new code of your |
| 328 | 374 | own. |
| @@ -333,7 +379,7 @@ useful only for: · 4 unmodified lines | ||
| 333 | 379 | (e) Types safe for use in userspace. |
| 334 | 380 | |
| 335 | 381 | In certain structures which are visible to userspace, we cannot |
| 336 | − require C99 types and cannot use the 'u32' form above. Thus, we | |
| 382 | + require C99 types and cannot use the ``u32`` form above. Thus, we | |
| 337 | 383 | use __u32 and similar types in all structures which are shared |
| 338 | 384 | with userspace. |
| 339 | 385 | |
| @@ -341,10 +387,11 @@ Maybe there are other cases too, but the rule should basically be to NEVER · 1 unmodified line | ||
| 341 | 387 | EVER use a typedef unless you can clearly match one of those rules. |
| 342 | 388 | |
| 343 | 389 | In general, a pointer, or a struct that has elements that can reasonably |
| 344 | −be directly accessed should _never_ be a typedef. | |
| 390 | +be directly accessed should **never** be a typedef. | |
| 345 | 391 | |
| 346 | 392 | |
| 347 | − Chapter 6: Functions | |
| 393 | +6) Functions | |
| 394 | +------------ | |
| 348 | 395 | |
| 349 | 396 | Functions should be short and sweet, and do just one thing. They should |
| 350 | 397 | fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, |
| @@ -372,8 +419,10 @@ and it gets confused. You know you're brilliant, but maybe you'd like · 21 unmodified lines | ||
| 372 | 419 | to understand what you did 2 weeks from now. |
| 373 | 420 | |
| 374 | 421 | In source files, separate functions with one blank line. If the function is |
| 375 | −exported, the EXPORT* macro for it should follow immediately after the closing | |
| 376 | −function brace line. E.g.: | |
| 422 | +exported, the **EXPORT** macro for it should follow immediately after the | |
| 423 | +closing function brace line. E.g.: | |
| 424 | + | |
| 425 | +.. code-block:: c | |
| 377 | 426 | |
| 378 | 427 | int system_is_up(void) |
| 379 | 428 | { |
| @@ -386,7 +435,8 @@ Although this is not required by the C language, it is preferred in Linux · 6 unmodified lines | ||
| 386 | 435 | because it is a simple way to add valuable information for the reader. |
| 387 | 436 | |
| 388 | 437 | |
| 389 | − Chapter 7: Centralized exiting of functions | |
| 438 | +7) Centralized exiting of functions | |
| 439 | +----------------------------------- | |
| 390 | 440 | |
| 391 | 441 | Albeit deprecated by some people, the equivalent of the goto statement is |
| 392 | 442 | used frequently by compilers in form of the unconditional jump instruction. |
| @@ -396,18 +446,21 @@ locations and some common work such as cleanup has to be done. If there is no · 3 unmodified lines | ||
| 396 | 446 | cleanup needed then just return directly. |
| 397 | 447 | |
| 398 | 448 | Choose label names which say what the goto does or why the goto exists. An |
| 399 | −example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid | |
| 400 | −using GW-BASIC names like "err1:" and "err2:". Also don't name them after the | |
| 401 | −goto location like "err_kmalloc_failed:" | |
| 449 | +example of a good name could be ``out_free_buffer:`` if the goto frees ``buffer``. | |
| 450 | +Avoid using GW-BASIC names like ``err1:`` and ``err2:``, as you would have to | |
| 451 | +renumber them if you ever add or remove exit paths, and they make correctness | |
| 452 | +difficult to verify anyway. | |
| 402 | 453 | |
| 403 | 454 | The rationale for using gotos is: |
| 404 | 455 | |
| 405 | 456 | - unconditional statements are easier to understand and follow |
| 406 | 457 | - nesting is reduced |
| 407 | 458 | - errors by not updating individual exit points when making |
| 408 | − modifications are prevented | |
| 459 | + modifications are prevented | |
| 409 | 460 | - saves the compiler work to optimize redundant code away ;) |
| 410 | 461 | |
| 462 | +.. code-block:: c | |
| 463 | + | |
| 411 | 464 | int fun(int a) |
| 412 | 465 | { |
| 413 | 466 | int result = 0; |
| @@ -425,27 +478,41 @@ The rationale for using gotos is: · 11 unmodified lines | ||
| 425 | 478 | goto out_buffer; |
| 426 | 479 | } |
| 427 | 480 | ... |
| 428 | − out_buffer: | |
| 481 | + out_free_buffer: | |
| 429 | 482 | kfree(buffer); |
| 430 | 483 | return result; |
| 431 | 484 | } |
| 432 | 485 | |
| 433 | −A common type of bug to be aware of is "one err bugs" which look like this: | |
| 486 | +A common type of bug to be aware of is ``one err bugs`` which look like this: | |
| 487 | + | |
| 488 | +.. code-block:: c | |
| 434 | 489 | |
| 435 | 490 | err: |
| 436 | 491 | kfree(foo->bar); |
| 437 | 492 | kfree(foo); |
| 438 | 493 | return ret; |
| 439 | 494 | |
| 440 | −The bug in this code is that on some exit paths "foo" is NULL. Normally the | |
| 441 | −fix for this is to split it up into two error labels "err_bar:" and "err_foo:". | |
| 495 | +The bug in this code is that on some exit paths ``foo`` is NULL. Normally the | |
| 496 | +fix for this is to split it up into two error labels ``err_free_bar:`` and | |
| 497 | +``err_free_foo:``: | |
| 442 | 498 | |
| 499 | +.. code-block:: c | |
| 443 | 500 | |
| 444 | − Chapter 8: Commenting | |
| 501 | + err_free_bar: | |
| 502 | + kfree(foo->bar); | |
| 503 | + err_free_foo: | |
| 504 | + kfree(foo); | |
| 505 | + return ret; | |
| 506 | + | |
| 507 | +Ideally you should simulate errors to test all exit paths. | |
| 508 | + | |
| 509 | + | |
| 510 | +8) Commenting | |
| 511 | +------------- | |
| 445 | 512 | |
| 446 | 513 | Comments are good, but there is also a danger of over-commenting. NEVER |
| 447 | 514 | try to explain HOW your code works in a comment: it's much better to |
| 448 | −write the code so that the _working_ is obvious, and it's a waste of | |
| 515 | +write the code so that the **working** is obvious, and it's a waste of | |
| 449 | 516 | time to explain badly written code. |
| 450 | 517 | |
| 451 | 518 | Generally, you want your comments to tell WHAT your code does, not HOW. |
| @@ -461,11 +528,10 @@ When commenting the kernel API functions, please use the kernel-doc format. · 9 unmodified lines | ||
| 461 | 528 | See the files Documentation/kernel-documentation.rst and scripts/kernel-doc |
| 462 | 529 | for details. |
| 463 | 530 | |
| 464 | −Linux style for comments is the C89 "/* ... */" style. | |
| 465 | −Don't use C99-style "// ..." comments. | |
| 466 | − | |
| 467 | 531 | The preferred style for long (multi-line) comments is: |
| 468 | 532 | |
| 533 | +.. code-block:: c | |
| 534 | + | |
| 469 | 535 | /* |
| 470 | 536 | * This is the preferred style for multi-line |
| 471 | 537 | * comments in the Linux kernel source code. |
| @@ -478,6 +544,8 @@ The preferred style for long (multi-line) comments is: · 6 unmodified lines | ||
| 478 | 544 | For files in net/ and drivers/net/ the preferred style for long (multi-line) |
| 479 | 545 | comments is a little different. |
| 480 | 546 | |
| 547 | +.. code-block:: c | |
| 548 | + | |
| 481 | 549 | /* The preferred comment style for files in net/ and drivers/net |
| 482 | 550 | * looks like this. |
| 483 | 551 | * |
| @@ -491,10 +559,11 @@ multiple data declarations). This leaves you room for a small comment on each · 7 unmodified lines | ||
| 491 | 559 | item, explaining its use. |
| 492 | 560 | |
| 493 | 561 | |
| 494 | − Chapter 9: You've made a mess of it | |
| 562 | +9) You've made a mess of it | |
| 563 | +--------------------------- | |
| 495 | 564 | |
| 496 | 565 | That's OK, we all do. You've probably been told by your long-time Unix |
| 497 | −user helper that "GNU emacs" automatically formats the C sources for | |
| 566 | +user helper that ``GNU emacs`` automatically formats the C sources for | |
| 498 | 567 | you, and you've noticed that yes, it does do that, but the defaults it |
| 499 | 568 | uses are less than desirable (in fact, they are worse than random |
| 500 | 569 | typing - an infinite number of monkeys typing into GNU emacs would never |
| @@ -503,63 +572,66 @@ make a good program). · 2 unmodified lines | ||
| 503 | 572 | So, you can either get rid of GNU emacs, or change it to use saner |
| 504 | 573 | values. To do the latter, you can stick the following in your .emacs file: |
| 505 | 574 | |
| 506 | −(defun c-lineup-arglist-tabs-only (ignored) | |
| 507 | − "Line up argument lists by tabs, not spaces" | |
| 508 | − (let* ((anchor (c-langelem-pos c-syntactic-element)) | |
| 509 | − (column (c-langelem-2nd-pos c-syntactic-element)) | |
| 510 | − (offset (- (1+ column) anchor)) | |
| 511 | − (steps (floor offset c-basic-offset))) | |
| 512 | − (* (max steps 1) | |
| 513 | − c-basic-offset))) | |
| 514 | − | |
| 515 | −(add-hook 'c-mode-common-hook | |
| 516 | − (lambda () | |
| 517 | − ;; Add kernel style | |
| 518 | − (c-add-style | |
| 519 | − "linux-tabs-only" | |
| 520 | − '("linux" (c-offsets-alist | |
| 521 | − (arglist-cont-nonempty | |
| 522 | − c-lineup-gcc-asm-reg | |
| 523 | − c-lineup-arglist-tabs-only)))))) | |
| 524 | − | |
| 525 | −(add-hook 'c-mode-hook | |
| 526 | − (lambda () | |
| 527 | − (let ((filename (buffer-file-name))) | |
| 528 | − ;; Enable kernel mode for the appropriate files | |
| 529 | − (when (and filename | |
| 530 | − (string-match (expand-file-name "~/src/linux-trees") | |
| 531 | − filename)) | |
| 532 | − (setq indent-tabs-mode t) | |
| 533 | − (setq show-trailing-whitespace t) | |
| 534 | − (c-set-style "linux-tabs-only"))))) | |
| 575 | +.. code-block:: none | |
| 576 | + | |
| 577 | + (defun c-lineup-arglist-tabs-only (ignored) | |
| 578 | + "Line up argument lists by tabs, not spaces" | |
| 579 | + (let* ((anchor (c-langelem-pos c-syntactic-element)) | |
| 580 | + (column (c-langelem-2nd-pos c-syntactic-element)) | |
| 581 | + (offset (- (1+ column) anchor)) | |
| 582 | + (steps (floor offset c-basic-offset))) | |
| 583 | + (* (max steps 1) | |
| 584 | + c-basic-offset))) | |
| 585 | + | |
| 586 | + (add-hook 'c-mode-common-hook | |
| 587 | + (lambda () | |
| 588 | + ;; Add kernel style | |
| 589 | + (c-add-style | |
| 590 | + "linux-tabs-only" | |
| 591 | + '("linux" (c-offsets-alist | |
| 592 | + (arglist-cont-nonempty | |
| 593 | + c-lineup-gcc-asm-reg | |
| 594 | + c-lineup-arglist-tabs-only)))))) | |
| 595 | + | |
| 596 | + (add-hook 'c-mode-hook | |
| 597 | + (lambda () | |
| 598 | + (let ((filename (buffer-file-name))) | |
| 599 | + ;; Enable kernel mode for the appropriate files | |
| 600 | + (when (and filename | |
| 601 | + (string-match (expand-file-name "~/src/linux-trees") | |
| 602 | + filename)) | |
| 603 | + (setq indent-tabs-mode t) | |
| 604 | + (setq show-trailing-whitespace t) | |
| 605 | + (c-set-style "linux-tabs-only"))))) | |
| 535 | 606 | |
| 536 | 607 | This will make emacs go better with the kernel coding style for C |
| 537 | −files below ~/src/linux-trees. | |
| 608 | +files below ``~/src/linux-trees``. | |
| 538 | 609 | |
| 539 | 610 | But even if you fail in getting emacs to do sane formatting, not |
| 540 | −everything is lost: use "indent". | |
| 611 | +everything is lost: use ``indent``. | |
| 541 | 612 | |
| 542 | 613 | Now, again, GNU indent has the same brain-dead settings that GNU emacs |
| 543 | 614 | has, which is why you need to give it a few command line options. |
| 544 | 615 | However, that's not too bad, because even the makers of GNU indent |
| 545 | 616 | recognize the authority of K&R (the GNU people aren't evil, they are |
| 546 | 617 | just severely misguided in this matter), so you just give indent the |
| 547 | −options "-kr -i8" (stands for "K&R, 8 character indents"), or use | |
| 548 | −"scripts/Lindent", which indents in the latest style. | |
| 618 | +options ``-kr -i8`` (stands for ``K&R, 8 character indents``), or use | |
| 619 | +``scripts/Lindent``, which indents in the latest style. | |
| 549 | 620 | |
| 550 | −"indent" has a lot of options, and especially when it comes to comment | |
| 621 | +``indent`` has a lot of options, and especially when it comes to comment | |
| 551 | 622 | re-formatting you may want to take a look at the man page. But |
| 552 | −remember: "indent" is not a fix for bad programming. | |
| 623 | +remember: ``indent`` is not a fix for bad programming. | |
| 553 | 624 | |
| 554 | 625 | |
| 555 | − Chapter 10: Kconfig configuration files | |
| 626 | +10) Kconfig configuration files | |
| 627 | +------------------------------- | |
| 556 | 628 | |
| 557 | 629 | For all of the Kconfig* configuration files throughout the source tree, |
| 558 | −the indentation is somewhat different. Lines under a "config" definition | |
| 630 | +the indentation is somewhat different. Lines under a ``config`` definition | |
| 559 | 631 | are indented with one tab, while help text is indented an additional two |
| 560 | −spaces. Example: | |
| 632 | +spaces. Example:: | |
| 561 | 633 | |
| 562 | −config AUDIT | |
| 634 | + config AUDIT | |
| 563 | 635 | bool "Auditing support" |
| 564 | 636 | depends on NET |
| 565 | 637 | help |
| @@ -569,9 +641,9 @@ config AUDIT · 3 unmodified lines | ||
| 569 | 641 | auditing without CONFIG_AUDITSYSCALL. |
| 570 | 642 | |
| 571 | 643 | Seriously dangerous features (such as write support for certain |
| 572 | −filesystems) should advertise this prominently in their prompt string: | |
| 644 | +filesystems) should advertise this prominently in their prompt string:: | |
| 573 | 645 | |
| 574 | −config ADFS_FS_RW | |
| 646 | + config ADFS_FS_RW | |
| 575 | 647 | bool "ADFS write support (DANGEROUS)" |
| 576 | 648 | depends on ADFS_FS |
| 577 | 649 | ... |
| @@ -580,41 +652,45 @@ For full documentation on the configuration files, see the file · 2 unmodified lines | ||
| 580 | 652 | Documentation/kbuild/kconfig-language.txt. |
| 581 | 653 | |
| 582 | 654 | |
| 583 | − Chapter 11: Data structures | |
| 655 | +11) Data structures | |
| 656 | +------------------- | |
| 584 | 657 | |
| 585 | 658 | Data structures that have visibility outside the single-threaded |
| 586 | 659 | environment they are created and destroyed in should always have |
| 587 | 660 | reference counts. In the kernel, garbage collection doesn't exist (and |
| 588 | 661 | outside the kernel garbage collection is slow and inefficient), which |
| 589 | −means that you absolutely _have_ to reference count all your uses. | |
| 662 | +means that you absolutely **have** to reference count all your uses. | |
| 590 | 663 | |
| 591 | 664 | Reference counting means that you can avoid locking, and allows multiple |
| 592 | 665 | users to have access to the data structure in parallel - and not having |
| 593 | 666 | to worry about the structure suddenly going away from under them just |
| 594 | 667 | because they slept or did something else for a while. |
| 595 | 668 | |
| 596 | −Note that locking is _not_ a replacement for reference counting. | |
| 669 | +Note that locking is **not** a replacement for reference counting. | |
| 597 | 670 | Locking is used to keep data structures coherent, while reference |
| 598 | 671 | counting is a memory management technique. Usually both are needed, and |
| 599 | 672 | they are not to be confused with each other. |
| 600 | 673 | |
| 601 | 674 | Many data structures can indeed have two levels of reference counting, |
| 602 | −when there are users of different "classes". The subclass count counts | |
| 675 | +when there are users of different ``classes``. The subclass count counts | |
| 603 | 676 | the number of subclass users, and decrements the global count just once |
| 604 | 677 | when the subclass count goes to zero. |
| 605 | 678 | |
| 606 | −Examples of this kind of "multi-level-reference-counting" can be found in | |
| 607 | −memory management ("struct mm_struct": mm_users and mm_count), and in | |
| 608 | −filesystem code ("struct super_block": s_count and s_active). | |
| 679 | +Examples of this kind of ``multi-level-reference-counting`` can be found in | |
| 680 | +memory management (``struct mm_struct``: mm_users and mm_count), and in | |
| 681 | +filesystem code (``struct super_block``: s_count and s_active). | |
| 609 | 682 | |
| 610 | 683 | Remember: if another thread can find your data structure, and you don't |
| 611 | 684 | have a reference count on it, you almost certainly have a bug. |
| 612 | 685 | |
| 613 | 686 | |
| 614 | − Chapter 12: Macros, Enums and RTL | |
| 687 | +12) Macros, Enums and RTL | |
| 688 | +------------------------- | |
| 615 | 689 | |
| 616 | 690 | Names of macros defining constants and labels in enums are capitalized. |
| 617 | 691 | |
| 692 | +.. code-block:: c | |
| 693 | + | |
| 618 | 694 | #define CONSTANT 0x12345 |
| 619 | 695 | |
| 620 | 696 | Enums are preferred when defining several related constants. |
| @@ -626,7 +702,9 @@ Generally, inline functions are preferable to macros resembling functions. · 5 unmodified lines | ||
| 626 | 702 | |
| 627 | 703 | Macros with multiple statements should be enclosed in a do - while block: |
| 628 | 704 | |
| 629 | − #define macrofun(a, b, c) \ | |
| 705 | +.. code-block:: c | |
| 706 | + | |
| 707 | + #define macrofun(a, b, c) \ | |
| 630 | 708 | do { \ |
| 631 | 709 | if (a == 5) \ |
| 632 | 710 | do_this(b, c); \ |
| @@ -636,17 +714,21 @@ Things to avoid when using macros: · 3 unmodified lines | ||
| 636 | 714 | |
| 637 | 715 | 1) macros that affect control flow: |
| 638 | 716 | |
| 717 | +.. code-block:: c | |
| 718 | + | |
| 639 | 719 | #define FOO(x) \ |
| 640 | 720 | do { \ |
| 641 | 721 | if (blah(x) < 0) \ |
| 642 | 722 | return -EBUGGERED; \ |
| 643 | 723 | } while (0) |
| 644 | 724 | |
| 645 | −is a _very_ bad idea. It looks like a function call but exits the "calling" | |
| 725 | +is a **very** bad idea. It looks like a function call but exits the ``calling`` | |
| 646 | 726 | function; don't break the internal parsers of those who will read the code. |
| 647 | 727 | |
| 648 | 728 | 2) macros that depend on having a local variable with a magic name: |
| 649 | 729 | |
| 730 | +.. code-block:: c | |
| 731 | + | |
| 650 | 732 | #define FOO(val) bar(index, val) |
| 651 | 733 | |
| 652 | 734 | might look like a good thing, but it's confusing as hell when one reads the |
| @@ -659,18 +741,22 @@ bite you if somebody e.g. turns FOO into an inline function. · 6 unmodified lines | ||
| 659 | 741 | must enclose the expression in parentheses. Beware of similar issues with |
| 660 | 742 | macros using parameters. |
| 661 | 743 | |
| 744 | +.. code-block:: c | |
| 745 | + | |
| 662 | 746 | #define CONSTANT 0x4000 |
| 663 | 747 | #define CONSTEXP (CONSTANT | 3) |
| 664 | 748 | |
| 665 | 749 | 5) namespace collisions when defining local variables in macros resembling |
| 666 | 750 | functions: |
| 667 | 751 | |
| 668 | −#define FOO(x) \ | |
| 669 | −({ \ | |
| 670 | − typeof(x) ret; \ | |
| 671 | − ret = calc_ret(x); \ | |
| 672 | − (ret); \ | |
| 673 | −}) | |
| 752 | +.. code-block:: c | |
| 753 | + | |
| 754 | + #define FOO(x) \ | |
| 755 | + ({ \ | |
| 756 | + typeof(x) ret; \ | |
| 757 | + ret = calc_ret(x); \ | |
| 758 | + (ret); \ | |
| 759 | + }) | |
| 674 | 760 | |
| 675 | 761 | ret is a common name for a local variable - __foo_ret is less likely |
| 676 | 762 | to collide with an existing variable. |
| @@ -679,11 +765,12 @@ The cpp manual deals with macros exhaustively. The gcc internals manual also · 2 unmodified lines | ||
| 679 | 765 | covers RTL which is used frequently with assembly language in the kernel. |
| 680 | 766 | |
| 681 | 767 | |
| 682 | − Chapter 13: Printing kernel messages | |
| 768 | +13) Printing kernel messages | |
| 769 | +---------------------------- | |
| 683 | 770 | |
| 684 | 771 | Kernel developers like to be seen as literate. Do mind the spelling |
| 685 | 772 | of kernel messages to make a good impression. Do not use crippled |
| 686 | −words like "dont"; use "do not" or "don't" instead. Make the messages | |
| 773 | +words like ``dont``; use ``do not`` or ``don't`` instead. Make the messages | |
| 687 | 774 | concise, clear, and unambiguous. |
| 688 | 775 | |
| 689 | 776 | Kernel messages do not have to be terminated with a period. |
| @@ -713,7 +800,8 @@ already inside a debug-related #ifdef section, printk(KERN_DEBUG ...) can be · 23 unmodified lines | ||
| 713 | 800 | used. |
| 714 | 801 | |
| 715 | 802 | |
| 716 | − Chapter 14: Allocating memory | |
| 803 | +14) Allocating memory | |
| 804 | +--------------------- | |
| 717 | 805 | |
| 718 | 806 | The kernel provides the following general purpose memory allocators: |
| 719 | 807 | kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and |
| @@ -722,6 +810,8 @@ about them. · 2 unmodified lines | ||
| 722 | 810 | |
| 723 | 811 | The preferred form for passing a size of a struct is the following: |
| 724 | 812 | |
| 813 | +.. code-block:: c | |
| 814 | + | |
| 725 | 815 | p = kmalloc(sizeof(*p), ...); |
| 726 | 816 | |
| 727 | 817 | The alternative form where struct name is spelled out hurts readability and |
| @@ -734,20 +824,25 @@ language. · 6 unmodified lines | ||
| 734 | 824 | |
| 735 | 825 | The preferred form for allocating an array is the following: |
| 736 | 826 | |
| 827 | +.. code-block:: c | |
| 828 | + | |
| 737 | 829 | p = kmalloc_array(n, sizeof(...), ...); |
| 738 | 830 | |
| 739 | 831 | The preferred form for allocating a zeroed array is the following: |
| 740 | 832 | |
| 833 | +.. code-block:: c | |
| 834 | + | |
| 741 | 835 | p = kcalloc(n, sizeof(...), ...); |
| 742 | 836 | |
| 743 | 837 | Both forms check for overflow on the allocation size n * sizeof(...), |
| 744 | 838 | and return NULL if that occurred. |
| 745 | 839 | |
| 746 | 840 | |
| 747 | − Chapter 15: The inline disease | |
| 841 | +15) The inline disease | |
| 842 | +---------------------- | |
| 748 | 843 | |
| 749 | 844 | There appears to be a common misperception that gcc has a magic "make me |
| 750 | −faster" speedup option called "inline". While the use of inlines can be | |
| 845 | +faster" speedup option called ``inline``. While the use of inlines can be | |
| 751 | 846 | appropriate (for example as a means of replacing macros, see Chapter 12), it |
| 752 | 847 | very often is not. Abundant use of the inline keyword leads to a much bigger |
| 753 | 848 | kernel, which in turn slows the system as a whole down, due to a bigger |
| @@ -771,26 +866,27 @@ appears outweighs the potential value of the hint that tells gcc to do · 17 unmodified lines | ||
| 771 | 866 | something it would have done anyway. |
| 772 | 867 | |
| 773 | 868 | |
| 774 | − Chapter 16: Function return values and names | |
| 869 | +16) Function return values and names | |
| 870 | +------------------------------------ | |
| 775 | 871 | |
| 776 | 872 | Functions can return values of many different kinds, and one of the |
| 777 | 873 | most common is a value indicating whether the function succeeded or |
| 778 | 874 | failed. Such a value can be represented as an error-code integer |
| 779 | −(-Exxx = failure, 0 = success) or a "succeeded" boolean (0 = failure, | |
| 875 | +(-Exxx = failure, 0 = success) or a ``succeeded`` boolean (0 = failure, | |
| 780 | 876 | non-zero = success). |
| 781 | 877 | |
| 782 | 878 | Mixing up these two sorts of representations is a fertile source of |
| 783 | 879 | difficult-to-find bugs. If the C language included a strong distinction |
| 784 | 880 | between integers and booleans then the compiler would find these mistakes |
| 785 | 881 | for us... but it doesn't. To help prevent such bugs, always follow this |
| 786 | −convention: | |
| 882 | +convention:: | |
| 787 | 883 | |
| 788 | 884 | If the name of a function is an action or an imperative command, |
| 789 | 885 | the function should return an error-code integer. If the name |
| 790 | 886 | is a predicate, the function should return a "succeeded" boolean. |
| 791 | 887 | |
| 792 | −For example, "add work" is a command, and the add_work() function returns 0 | |
| 793 | −for success or -EBUSY for failure. In the same way, "PCI device present" is | |
| 888 | +For example, ``add work`` is a command, and the add_work() function returns 0 | |
| 889 | +for success or -EBUSY for failure. In the same way, ``PCI device present`` is | |
| 794 | 890 | a predicate, and the pci_dev_present() function returns 1 if it succeeds in |
| 795 | 891 | finding a matching device or 0 if it doesn't. |
| 796 | 892 | |
| @@ -805,17 +901,22 @@ result. Typical examples would be functions that return pointers; they use · 8 unmodified lines | ||
| 805 | 901 | NULL or the ERR_PTR mechanism to report failure. |
| 806 | 902 | |
| 807 | 903 | |
| 808 | − Chapter 17: Don't re-invent the kernel macros | |
| 904 | +17) Don't re-invent the kernel macros | |
| 905 | +------------------------------------- | |
| 809 | 906 | |
| 810 | 907 | The header file include/linux/kernel.h contains a number of macros that |
| 811 | 908 | you should use, rather than explicitly coding some variant of them yourself. |
| 812 | 909 | For example, if you need to calculate the length of an array, take advantage |
| 813 | 910 | of the macro |
| 814 | 911 | |
| 912 | +.. code-block:: c | |
| 913 | + | |
| 815 | 914 | #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) |
| 816 | 915 | |
| 817 | 916 | Similarly, if you need to calculate the size of some structure member, use |
| 818 | 917 | |
| 918 | +.. code-block:: c | |
| 919 | + | |
| 819 | 920 | #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f)) |
| 820 | 921 | |
| 821 | 922 | There are also min() and max() macros that do strict type checking if you |
| @@ -823,16 +924,21 @@ need them. Feel free to peruse that header file to see what else is already · 1 unmodified line | ||
| 823 | 924 | defined that you shouldn't reproduce in your code. |
| 824 | 925 | |
| 825 | 926 | |
| 826 | − Chapter 18: Editor modelines and other cruft | |
| 927 | +18) Editor modelines and other cruft | |
| 928 | +------------------------------------ | |
| 827 | 929 | |
| 828 | 930 | Some editors can interpret configuration information embedded in source files, |
| 829 | 931 | indicated with special markers. For example, emacs interprets lines marked |
| 830 | 932 | like this: |
| 831 | 933 | |
| 934 | +.. code-block:: c | |
| 935 | + | |
| 832 | 936 | -*- mode: c -*- |
| 833 | 937 | |
| 834 | 938 | Or like this: |
| 835 | 939 | |
| 940 | +.. code-block:: c | |
| 941 | + | |
| 836 | 942 | /* |
| 837 | 943 | Local Variables: |
| 838 | 944 | compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c" |
| @@ -841,6 +947,8 @@ Or like this: · 2 unmodified lines | ||
| 841 | 947 | |
| 842 | 948 | Vim interprets markers that look like this: |
| 843 | 949 | |
| 950 | +.. code-block:: c | |
| 951 | + | |
| 844 | 952 | /* vim:set sw=8 noet */ |
| 845 | 953 | |
| 846 | 954 | Do not include any of these in source files. People have their own personal |
| @@ -850,7 +958,8 @@ own custom mode, or may have some other magic method for making indentation · 3 unmodified lines | ||
| 850 | 958 | work correctly. |
| 851 | 959 | |
| 852 | 960 | |
| 853 | − Chapter 19: Inline assembly | |
| 961 | +19) Inline assembly | |
| 962 | +------------------- | |
| 854 | 963 | |
| 855 | 964 | In architecture-specific code, you may need to use inline assembly to interface |
| 856 | 965 | with CPU or platform functionality. Don't hesitate to do so when necessary. |
| @@ -863,7 +972,7 @@ that inline assembly can use C parameters. · 6 unmodified lines | ||
| 863 | 972 | |
| 864 | 973 | Large, non-trivial assembly functions should go in .S files, with corresponding |
| 865 | 974 | C prototypes defined in C header files. The C prototypes for assembly |
| 866 | −functions should use "asmlinkage". | |
| 975 | +functions should use ``asmlinkage``. | |
| 867 | 976 | |
| 868 | 977 | You may need to mark your asm statement as volatile, to prevent GCC from |
| 869 | 978 | removing it if GCC doesn't notice any side effects. You don't always need to |
| @@ -874,12 +983,15 @@ instructions, put each instruction on a separate line in a separate quoted · 4 unmodified lines | ||
| 874 | 983 | string, and end each string except the last with \n\t to properly indent the |
| 875 | 984 | next instruction in the assembly output: |
| 876 | 985 | |
| 986 | +.. code-block:: c | |
| 987 | + | |
| 877 | 988 | asm ("magic %reg1, #42\n\t" |
| 878 | 989 | "more_magic %reg2, %reg3" |
| 879 | 990 | : /* outputs */ : /* inputs */ : /* clobbers */); |
| 880 | 991 | |
| 881 | 992 | |
| 882 | − Chapter 20: Conditional Compilation | |
| 993 | +20) Conditional Compilation | |
| 994 | +--------------------------- | |
| 883 | 995 | |
| 884 | 996 | Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c |
| 885 | 997 | files; doing so makes code harder to read and logic harder to follow. Instead, |
| @@ -903,6 +1015,8 @@ unused, delete it.) · 17 unmodified lines | ||
| 903 | 1015 | Within code, where possible, use the IS_ENABLED macro to convert a Kconfig |
| 904 | 1016 | symbol into a C boolean expression, and use it in a normal C conditional: |
| 905 | 1017 | |
| 1018 | +.. code-block:: c | |
| 1019 | + | |
| 906 | 1020 | if (IS_ENABLED(CONFIG_SOMETHING)) { |
| 907 | 1021 | ... |
| 908 | 1022 | } |
| @@ -918,12 +1032,15 @@ At the end of any non-trivial #if or #ifdef block (more than a few lines), · 9 unmodified lines | ||
| 918 | 1032 | place a comment after the #endif on the same line, noting the conditional |
| 919 | 1033 | expression used. For instance: |
| 920 | 1034 | |
| 1035 | +.. code-block:: c | |
| 1036 | + | |
| 921 | 1037 | #ifdef CONFIG_SOMETHING |
| 922 | 1038 | ... |
| 923 | 1039 | #endif /* CONFIG_SOMETHING */ |
| 924 | 1040 | |
| 925 | 1041 | |
| 926 | − Appendix I: References | |
| 1042 | +Appendix I) References | |
| 1043 | +---------------------- | |
| 927 | 1044 | |
| 928 | 1045 | The C Programming Language, Second Edition |
| 929 | 1046 | by Brian W. Kernighan and Dennis M. Ritchie. |
| @@ -943,4 +1060,3 @@ language C, URL: http://www.open-std.org/JTC1/SC22/WG14/ · 13 unmodified lines | ||
| 943 | 1060 | |
| 944 | 1061 | Kernel CodingStyle, by greg@kroah.com at OLS 2002: |
| 945 | 1062 | http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ |
| 946 | − | |
| @@ -699,7 +699,7 @@ to use the dma_sync_*() interfaces. · 698 unmodified lines | ||
| 699 | 699 | dma_addr_t mapping; |
| 700 | 700 | |
| 701 | 701 | mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE); |
| 702 | − if (dma_mapping_error(cp->dev, dma_handle)) { | |
| 702 | + if (dma_mapping_error(cp->dev, mapping)) { | |
| 703 | 703 | /* |
| 704 | 704 | * reduce current DMA mapping usage, |
| 705 | 705 | * delay and try again later or |
| @@ -931,10 +931,8 @@ to "Closing". · 225 unmodified lines | ||
| 931 | 931 | |
| 932 | 932 | 1) Struct scatterlist requirements. |
| 933 | 933 | |
| 934 | − Don't invent the architecture specific struct scatterlist; just use | |
| 935 | − <asm-generic/scatterlist.h>. You need to enable | |
| 936 | − CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs | |
| 937 | − (including software IOMMU). | |
| 934 | + You need to enable CONFIG_NEED_SG_DMA_LENGTH if the architecture | |
| 935 | + supports IOMMUs (including software IOMMU). | |
| 938 | 936 | |
| 939 | 937 | 2) ARCH_DMA_MINALIGN |
| 940 | 938 | |
| @@ -277,14 +277,26 @@ and <size> parameters are provided to do partial page mapping, it is · 276 unmodified lines | ||
| 277 | 277 | recommended that you never use these unless you really know what the |
| 278 | 278 | cache width is. |
| 279 | 279 | |
| 280 | +dma_addr_t | |
| 281 | +dma_map_resource(struct device *dev, phys_addr_t phys_addr, size_t size, | |
| 282 | + enum dma_data_direction dir, unsigned long attrs) | |
| 283 | + | |
| 284 | +void | |
| 285 | +dma_unmap_resource(struct device *dev, dma_addr_t addr, size_t size, | |
| 286 | + enum dma_data_direction dir, unsigned long attrs) | |
| 287 | + | |
| 288 | +API for mapping and unmapping for MMIO resources. All the notes and | |
| 289 | +warnings for the other mapping APIs apply here. The API should only be | |
| 290 | +used to map device MMIO resources, mapping of RAM is not permitted. | |
| 291 | + | |
| 280 | 292 | int |
| 281 | 293 | dma_mapping_error(struct device *dev, dma_addr_t dma_addr) |
| 282 | 294 | |
| 283 | −In some circumstances dma_map_single() and dma_map_page() will fail to create | |
| 284 | −a mapping. A driver can check for these errors by testing the returned | |
| 285 | −DMA address with dma_mapping_error(). A non-zero return value means the mapping | |
| 286 | −could not be created and the driver should take appropriate action (e.g. | |
| 287 | −reduce current DMA mapping usage or delay and try again later). | |
| 295 | +In some circumstances dma_map_single(), dma_map_page() and dma_map_resource() | |
| 296 | +will fail to create a mapping. A driver can check for these errors by testing | |
| 297 | +the returned DMA address with dma_mapping_error(). A non-zero return value | |
| 298 | +means the mapping could not be created and the driver should take appropriate | |
| 299 | +action (e.g. reduce current DMA mapping usage or delay and try again later). | |
| 288 | 300 | |
| 289 | 301 | int |
| 290 | 302 | dma_map_sg(struct device *dev, struct scatterlist *sg, |
| @@ -126,3 +126,20 @@ means that we won't try quite as hard to get them. · 125 unmodified lines | ||
| 126 | 126 | |
| 127 | 127 | NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM, |
| 128 | 128 | though ARM64 patches will likely be posted soon. |
| 129 | + | |
| 130 | +DMA_ATTR_NO_WARN | |
| 131 | +---------------- | |
| 132 | + | |
| 133 | +This tells the DMA-mapping subsystem to suppress allocation failure reports | |
| 134 | +(similarly to __GFP_NOWARN). | |
| 135 | + | |
| 136 | +On some architectures allocation failures are reported with error messages | |
| 137 | +to the system logs. Although this can help to identify and debug problems, | |
| 138 | +drivers which handle failures (eg, retry later) have no problems with them, | |
| 139 | +and can actually flood the system logs with error messages that aren't any | |
| 140 | +problem at all, depending on the implementation of the retry mechanism. | |
| 141 | + | |
| 142 | +So, this provides a way for drivers to avoid those error messages on calls | |
| 143 | +where allocation failures are not a problem, and shouldn't bother the logs. | |
| 144 | + | |
| 145 | +NOTE: At the moment DMA_ATTR_NO_WARN is only implemented on PowerPC. | |
| @@ -1,584 +0,0 @@ | ||
| 1 | −<?xml version="1.0" encoding="UTF-8"?> | |
| 2 | −<!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | |
| 3 | − "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> | |
| 4 | −<set> | |
| 5 | − <setinfo> | |
| 6 | − <title>The 802.11 subsystems – for kernel developers</title> | |
| 7 | − <subtitle> | |
| 8 | − Explaining wireless 802.11 networking in the Linux kernel | |
| 9 | − </subtitle> | |
| 10 | − | |
| 11 | − <copyright> | |
| 12 | − <year>2007-2009</year> | |
| 13 | − <holder>Johannes Berg</holder> | |
| 14 | − </copyright> | |
| 15 | − | |
| 16 | − <authorgroup> | |
| 17 | − <author> | |
| 18 | − <firstname>Johannes</firstname> | |
| 19 | − <surname>Berg</surname> | |
| 20 | − <affiliation> | |
| 21 | − <address><email>johannes@sipsolutions.net</email></address> | |
| 22 | − </affiliation> | |
| 23 | − </author> | |
| 24 | − </authorgroup> | |
| 25 | − | |
| 26 | − <legalnotice> | |
| 27 | − <para> | |
| 28 | − This documentation is free software; you can redistribute | |
| 29 | − it and/or modify it under the terms of the GNU General Public | |
| 30 | − License version 2 as published by the Free Software Foundation. | |
| 31 | − </para> | |
| 32 | − <para> | |
| 33 | − This documentation is distributed in the hope that it will be | |
| 34 | − useful, but WITHOUT ANY WARRANTY; without even the implied | |
| 35 | − warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | |
| 36 | − See the GNU General Public License for more details. | |
| 37 | − </para> | |
| 38 | − <para> | |
| 39 | − You should have received a copy of the GNU General Public | |
| 40 | − License along with this documentation; if not, write to the Free | |
| 41 | − Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, | |
| 42 | − MA 02111-1307 USA | |
| 43 | − </para> | |
| 44 | − <para> | |
| 45 | − For more details see the file COPYING in the source | |
| 46 | − distribution of Linux. | |
| 47 | − </para> | |
| 48 | − </legalnotice> | |
| 49 | − | |
| 50 | − <abstract> | |
| 51 | − <para> | |
| 52 | − These books attempt to give a description of the | |
| 53 | − various subsystems that play a role in 802.11 wireless | |
| 54 | − networking in Linux. Since these books are for kernel | |
| 55 | − developers they attempts to document the structures | |
| 56 | − and functions used in the kernel as well as giving a | |
| 57 | − higher-level overview. | |
| 58 | − </para> | |
| 59 | − <para> | |
| 60 | − The reader is expected to be familiar with the 802.11 | |
| 61 | − standard as published by the IEEE in 802.11-2007 (or | |
| 62 | − possibly later versions). References to this standard | |
| 63 | − will be given as "802.11-2007 8.1.5". | |
| 64 | − </para> | |
| 65 | − </abstract> | |
| 66 | − </setinfo> | |
| 67 | − <book id="cfg80211-developers-guide"> | |
| 68 | − <bookinfo> | |
| 69 | − <title>The cfg80211 subsystem</title> | |
| 70 | − | |
| 71 | − <abstract> | |
| 72 | −!Pinclude/net/cfg80211.h Introduction | |
| 73 | − </abstract> | |
| 74 | − </bookinfo> | |
| 75 | − <chapter> | |
| 76 | − <title>Device registration</title> | |
| 77 | −!Pinclude/net/cfg80211.h Device registration | |
| 78 | −!Finclude/net/cfg80211.h ieee80211_channel_flags | |
| 79 | −!Finclude/net/cfg80211.h ieee80211_channel | |
| 80 | −!Finclude/net/cfg80211.h ieee80211_rate_flags | |
| 81 | −!Finclude/net/cfg80211.h ieee80211_rate | |
| 82 | −!Finclude/net/cfg80211.h ieee80211_sta_ht_cap | |
| 83 | −!Finclude/net/cfg80211.h ieee80211_supported_band | |
| 84 | −!Finclude/net/cfg80211.h cfg80211_signal_type | |
| 85 | −!Finclude/net/cfg80211.h wiphy_params_flags | |
| 86 | −!Finclude/net/cfg80211.h wiphy_flags | |
| 87 | −!Finclude/net/cfg80211.h wiphy | |
| 88 | −!Finclude/net/cfg80211.h wireless_dev | |
| 89 | −!Finclude/net/cfg80211.h wiphy_new | |
| 90 | −!Finclude/net/cfg80211.h wiphy_register | |
| 91 | −!Finclude/net/cfg80211.h wiphy_unregister | |
| 92 | −!Finclude/net/cfg80211.h wiphy_free | |
| 93 | − | |
| 94 | −!Finclude/net/cfg80211.h wiphy_name | |
| 95 | −!Finclude/net/cfg80211.h wiphy_dev | |
| 96 | −!Finclude/net/cfg80211.h wiphy_priv | |
| 97 | −!Finclude/net/cfg80211.h priv_to_wiphy | |
| 98 | −!Finclude/net/cfg80211.h set_wiphy_dev | |
| 99 | −!Finclude/net/cfg80211.h wdev_priv | |
| 100 | −!Finclude/net/cfg80211.h ieee80211_iface_limit | |
| 101 | −!Finclude/net/cfg80211.h ieee80211_iface_combination | |
| 102 | −!Finclude/net/cfg80211.h cfg80211_check_combinations | |
| 103 | − </chapter> | |
| 104 | − <chapter> | |
| 105 | − <title>Actions and configuration</title> | |
| 106 | −!Pinclude/net/cfg80211.h Actions and configuration | |
| 107 | −!Finclude/net/cfg80211.h cfg80211_ops | |
| 108 | −!Finclude/net/cfg80211.h vif_params | |
| 109 | −!Finclude/net/cfg80211.h key_params | |
| 110 | −!Finclude/net/cfg80211.h survey_info_flags | |
| 111 | −!Finclude/net/cfg80211.h survey_info | |
| 112 | −!Finclude/net/cfg80211.h cfg80211_beacon_data | |
| 113 | −!Finclude/net/cfg80211.h cfg80211_ap_settings | |
| 114 | −!Finclude/net/cfg80211.h station_parameters | |
| 115 | −!Finclude/net/cfg80211.h rate_info_flags | |
| 116 | −!Finclude/net/cfg80211.h rate_info | |
| 117 | −!Finclude/net/cfg80211.h station_info | |
| 118 | −!Finclude/net/cfg80211.h monitor_flags | |
| 119 | −!Finclude/net/cfg80211.h mpath_info_flags | |
| 120 | −!Finclude/net/cfg80211.h mpath_info | |
| 121 | −!Finclude/net/cfg80211.h bss_parameters | |
| 122 | −!Finclude/net/cfg80211.h ieee80211_txq_params | |
| 123 | −!Finclude/net/cfg80211.h cfg80211_crypto_settings | |
| 124 | −!Finclude/net/cfg80211.h cfg80211_auth_request | |
| 125 | −!Finclude/net/cfg80211.h cfg80211_assoc_request | |
| 126 | −!Finclude/net/cfg80211.h cfg80211_deauth_request | |
| 127 | −!Finclude/net/cfg80211.h cfg80211_disassoc_request | |
| 128 | −!Finclude/net/cfg80211.h cfg80211_ibss_params | |
| 129 | −!Finclude/net/cfg80211.h cfg80211_connect_params | |
| 130 | −!Finclude/net/cfg80211.h cfg80211_pmksa | |
| 131 | −!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt | |
| 132 | −!Finclude/net/cfg80211.h cfg80211_auth_timeout | |
| 133 | −!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp | |
| 134 | −!Finclude/net/cfg80211.h cfg80211_assoc_timeout | |
| 135 | −!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt | |
| 136 | −!Finclude/net/cfg80211.h cfg80211_ibss_joined | |
| 137 | −!Finclude/net/cfg80211.h cfg80211_connect_result | |
| 138 | −!Finclude/net/cfg80211.h cfg80211_connect_bss | |
| 139 | −!Finclude/net/cfg80211.h cfg80211_connect_timeout | |
| 140 | −!Finclude/net/cfg80211.h cfg80211_roamed | |
| 141 | −!Finclude/net/cfg80211.h cfg80211_disconnected | |
| 142 | −!Finclude/net/cfg80211.h cfg80211_ready_on_channel | |
| 143 | −!Finclude/net/cfg80211.h cfg80211_remain_on_channel_expired | |
| 144 | −!Finclude/net/cfg80211.h cfg80211_new_sta | |
| 145 | −!Finclude/net/cfg80211.h cfg80211_rx_mgmt | |
| 146 | −!Finclude/net/cfg80211.h cfg80211_mgmt_tx_status | |
| 147 | −!Finclude/net/cfg80211.h cfg80211_cqm_rssi_notify | |
| 148 | −!Finclude/net/cfg80211.h cfg80211_cqm_pktloss_notify | |
| 149 | −!Finclude/net/cfg80211.h cfg80211_michael_mic_failure | |
| 150 | − </chapter> | |
| 151 | − <chapter> | |
| 152 | − <title>Scanning and BSS list handling</title> | |
| 153 | −!Pinclude/net/cfg80211.h Scanning and BSS list handling | |
| 154 | −!Finclude/net/cfg80211.h cfg80211_ssid | |
| 155 | −!Finclude/net/cfg80211.h cfg80211_scan_request | |
| 156 | −!Finclude/net/cfg80211.h cfg80211_scan_done | |
| 157 | −!Finclude/net/cfg80211.h cfg80211_bss | |
| 158 | −!Finclude/net/cfg80211.h cfg80211_inform_bss | |
| 159 | −!Finclude/net/cfg80211.h cfg80211_inform_bss_frame_data | |
| 160 | −!Finclude/net/cfg80211.h cfg80211_inform_bss_data | |
| 161 | −!Finclude/net/cfg80211.h cfg80211_unlink_bss | |
| 162 | −!Finclude/net/cfg80211.h cfg80211_find_ie | |
| 163 | −!Finclude/net/cfg80211.h ieee80211_bss_get_ie | |
| 164 | − </chapter> | |
| 165 | − <chapter> | |
| 166 | − <title>Utility functions</title> | |
| 167 | −!Pinclude/net/cfg80211.h Utility functions | |
| 168 | −!Finclude/net/cfg80211.h ieee80211_channel_to_frequency | |
| 169 | −!Finclude/net/cfg80211.h ieee80211_frequency_to_channel | |
| 170 | −!Finclude/net/cfg80211.h ieee80211_get_channel | |
| 171 | −!Finclude/net/cfg80211.h ieee80211_get_response_rate | |
| 172 | −!Finclude/net/cfg80211.h ieee80211_hdrlen | |
| 173 | −!Finclude/net/cfg80211.h ieee80211_get_hdrlen_from_skb | |
| 174 | −!Finclude/net/cfg80211.h ieee80211_radiotap_iterator | |
| 175 | − </chapter> | |
| 176 | − <chapter> | |
| 177 | − <title>Data path helpers</title> | |
| 178 | −!Pinclude/net/cfg80211.h Data path helpers | |
| 179 | −!Finclude/net/cfg80211.h ieee80211_data_to_8023 | |
| 180 | −!Finclude/net/cfg80211.h ieee80211_data_from_8023 | |
| 181 | −!Finclude/net/cfg80211.h ieee80211_amsdu_to_8023s | |
| 182 | −!Finclude/net/cfg80211.h cfg80211_classify8021d | |
| 183 | − </chapter> | |
| 184 | − <chapter> | |
| 185 | − <title>Regulatory enforcement infrastructure</title> | |
| 186 | −!Pinclude/net/cfg80211.h Regulatory enforcement infrastructure | |
| 187 | −!Finclude/net/cfg80211.h regulatory_hint | |
| 188 | −!Finclude/net/cfg80211.h wiphy_apply_custom_regulatory | |
| 189 | −!Finclude/net/cfg80211.h freq_reg_info | |
| 190 | − </chapter> | |
| 191 | − <chapter> | |
| 192 | − <title>RFkill integration</title> | |
| 193 | −!Pinclude/net/cfg80211.h RFkill integration | |
| 194 | −!Finclude/net/cfg80211.h wiphy_rfkill_set_hw_state | |
| 195 | −!Finclude/net/cfg80211.h wiphy_rfkill_start_polling | |
| 196 | −!Finclude/net/cfg80211.h wiphy_rfkill_stop_polling | |
| 197 | − </chapter> | |
| 198 | − <chapter> | |
| 199 | − <title>Test mode</title> | |
| 200 | −!Pinclude/net/cfg80211.h Test mode | |
| 201 | −!Finclude/net/cfg80211.h cfg80211_testmode_alloc_reply_skb | |
| 202 | −!Finclude/net/cfg80211.h cfg80211_testmode_reply | |
| 203 | −!Finclude/net/cfg80211.h cfg80211_testmode_alloc_event_skb | |
| 204 | −!Finclude/net/cfg80211.h cfg80211_testmode_event | |
| 205 | − </chapter> | |
| 206 | − </book> | |
| 207 | − <book id="mac80211-developers-guide"> | |
| 208 | − <bookinfo> | |
| 209 | − <title>The mac80211 subsystem</title> | |
| 210 | − <abstract> | |
| 211 | −!Pinclude/net/mac80211.h Introduction | |
| 212 | −!Pinclude/net/mac80211.h Warning | |
| 213 | − </abstract> | |
| 214 | − </bookinfo> | |
| 215 | − | |
| 216 | − <toc></toc> | |
| 217 | − | |
| 218 | − <!-- | |
| 219 | − Generally, this document shall be ordered by increasing complexity. | |
| 220 | − It is important to note that readers should be able to read only | |
| 221 | − the first few sections to get a working driver and only advanced | |
| 222 | − usage should require reading the full document. | |
| 223 | − --> | |
| 224 | − | |
| 225 | − <part> | |
| 226 | − <title>The basic mac80211 driver interface</title> | |
| 227 | − <partintro> | |
| 228 | − <para> | |
| 229 | − You should read and understand the information contained | |
| 230 | − within this part of the book while implementing a driver. | |
| 231 | − In some chapters, advanced usage is noted, that may be | |
| 232 | − skipped at first. | |
| 233 | − </para> | |
| 234 | − <para> | |
| 235 | − This part of the book only covers station and monitor mode | |
| 236 | − functionality, additional information required to implement | |
| 237 | − the other modes is covered in the second part of the book. | |
| 238 | − </para> | |
| 239 | − </partintro> | |
| 240 | − | |
| 241 | − <chapter id="basics"> | |
| 242 | − <title>Basic hardware handling</title> | |
| 243 | − <para>TBD</para> | |
| 244 | − <para> | |
| 245 | − This chapter shall contain information on getting a hw | |
| 246 | − struct allocated and registered with mac80211. | |
| 247 | − </para> | |
| 248 | − <para> | |
| 249 | − Since it is required to allocate rates/modes before registering | |
| 250 | − a hw struct, this chapter shall also contain information on setting | |
| 251 | − up the rate/mode structs. | |
| 252 | − </para> | |
| 253 | − <para> | |
| 254 | − Additionally, some discussion about the callbacks and | |
| 255 | − the general programming model should be in here, including | |
| 256 | − the definition of ieee80211_ops which will be referred to | |
| 257 | − a lot. | |
| 258 | − </para> | |
| 259 | − <para> | |
| 260 | − Finally, a discussion of hardware capabilities should be done | |
| 261 | − with references to other parts of the book. | |
| 262 | − </para> | |
| 263 | − <!-- intentionally multiple !F lines to get proper order --> | |
| 264 | −!Finclude/net/mac80211.h ieee80211_hw | |
| 265 | −!Finclude/net/mac80211.h ieee80211_hw_flags | |
| 266 | −!Finclude/net/mac80211.h SET_IEEE80211_DEV | |
| 267 | −!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR | |
| 268 | −!Finclude/net/mac80211.h ieee80211_ops | |
| 269 | −!Finclude/net/mac80211.h ieee80211_alloc_hw | |
| 270 | −!Finclude/net/mac80211.h ieee80211_register_hw | |
| 271 | −!Finclude/net/mac80211.h ieee80211_unregister_hw | |
| 272 | −!Finclude/net/mac80211.h ieee80211_free_hw | |
| 273 | − </chapter> | |
| 274 | − | |
| 275 | − <chapter id="phy-handling"> | |
| 276 | − <title>PHY configuration</title> | |
| 277 | − <para>TBD</para> | |
| 278 | − <para> | |
| 279 | − This chapter should describe PHY handling including | |
| 280 | − start/stop callbacks and the various structures used. | |
| 281 | − </para> | |
| 282 | −!Finclude/net/mac80211.h ieee80211_conf | |
| 283 | −!Finclude/net/mac80211.h ieee80211_conf_flags | |
| 284 | − </chapter> | |
| 285 | − | |
| 286 | − <chapter id="iface-handling"> | |
| 287 | − <title>Virtual interfaces</title> | |
| 288 | − <para>TBD</para> | |
| 289 | − <para> | |
| 290 | − This chapter should describe virtual interface basics | |
| 291 | − that are relevant to the driver (VLANs, MGMT etc are not.) | |
| 292 | − It should explain the use of the add_iface/remove_iface | |
| 293 | − callbacks as well as the interface configuration callbacks. | |
| 294 | − </para> | |
| 295 | − <para>Things related to AP mode should be discussed there.</para> | |
| 296 | − <para> | |
| 297 | − Things related to supporting multiple interfaces should be | |
| 298 | − in the appropriate chapter, a BIG FAT note should be here about | |
| 299 | − this though and the recommendation to allow only a single | |
| 300 | − interface in STA mode at first! | |
| 301 | − </para> | |
| 302 | −!Finclude/net/mac80211.h ieee80211_vif | |
| 303 | − </chapter> | |
| 304 | − | |
| 305 | − <chapter id="rx-tx"> | |
| 306 | − <title>Receive and transmit processing</title> | |
| 307 | − <sect1> | |
| 308 | − <title>what should be here</title> | |
| 309 | − <para>TBD</para> | |
| 310 | − <para> | |
| 311 | − This should describe the receive and transmit | |
| 312 | − paths in mac80211/the drivers as well as | |
| 313 | − transmit status handling. | |
| 314 | − </para> | |
| 315 | − </sect1> | |
| 316 | − <sect1> | |
| 317 | − <title>Frame format</title> | |
| 318 | −!Pinclude/net/mac80211.h Frame format | |
| 319 | − </sect1> | |
| 320 | − <sect1> | |
| 321 | − <title>Packet alignment</title> | |
| 322 | −!Pnet/mac80211/rx.c Packet alignment | |
| 323 | − </sect1> | |
| 324 | − <sect1> | |
| 325 | − <title>Calling into mac80211 from interrupts</title> | |
| 326 | −!Pinclude/net/mac80211.h Calling mac80211 from interrupts | |
| 327 | − </sect1> | |
| 328 | − <sect1> | |
| 329 | − <title>functions/definitions</title> | |
| 330 | −!Finclude/net/mac80211.h ieee80211_rx_status | |
| 331 | −!Finclude/net/mac80211.h mac80211_rx_flags | |
| 332 | −!Finclude/net/mac80211.h mac80211_tx_info_flags | |
| 333 | −!Finclude/net/mac80211.h mac80211_tx_control_flags | |
| 334 | −!Finclude/net/mac80211.h mac80211_rate_control_flags | |
| 335 | −!Finclude/net/mac80211.h ieee80211_tx_rate | |
| 336 | −!Finclude/net/mac80211.h ieee80211_tx_info | |
| 337 | −!Finclude/net/mac80211.h ieee80211_tx_info_clear_status | |
| 338 | −!Finclude/net/mac80211.h ieee80211_rx | |
| 339 | −!Finclude/net/mac80211.h ieee80211_rx_ni | |
| 340 | −!Finclude/net/mac80211.h ieee80211_rx_irqsafe | |
| 341 | −!Finclude/net/mac80211.h ieee80211_tx_status | |
| 342 | −!Finclude/net/mac80211.h ieee80211_tx_status_ni | |
| 343 | −!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe | |
| 344 | −!Finclude/net/mac80211.h ieee80211_rts_get | |
| 345 | −!Finclude/net/mac80211.h ieee80211_rts_duration | |
| 346 | −!Finclude/net/mac80211.h ieee80211_ctstoself_get | |
| 347 | −!Finclude/net/mac80211.h ieee80211_ctstoself_duration | |
| 348 | −!Finclude/net/mac80211.h ieee80211_generic_frame_duration | |
| 349 | −!Finclude/net/mac80211.h ieee80211_wake_queue | |
| 350 | −!Finclude/net/mac80211.h ieee80211_stop_queue | |
| 351 | −!Finclude/net/mac80211.h ieee80211_wake_queues | |
| 352 | −!Finclude/net/mac80211.h ieee80211_stop_queues | |
| 353 | −!Finclude/net/mac80211.h ieee80211_queue_stopped | |
| 354 | − </sect1> | |
| 355 | − </chapter> | |
| 356 | − | |
| 357 | − <chapter id="filters"> | |
| 358 | − <title>Frame filtering</title> | |
| 359 | −!Pinclude/net/mac80211.h Frame filtering | |
| 360 | −!Finclude/net/mac80211.h ieee80211_filter_flags | |
| 361 | − </chapter> | |
| 362 | − | |
| 363 | − <chapter id="workqueue"> | |
| 364 | − <title>The mac80211 workqueue</title> | |
| 365 | −!Pinclude/net/mac80211.h mac80211 workqueue | |
| 366 | −!Finclude/net/mac80211.h ieee80211_queue_work | |
| 367 | −!Finclude/net/mac80211.h ieee80211_queue_delayed_work | |
| 368 | − </chapter> | |
| 369 | − </part> | |
| 370 | − | |
| 371 | − <part id="advanced"> | |
| 372 | − <title>Advanced driver interface</title> | |
| 373 | − <partintro> | |
| 374 | − <para> | |
| 375 | − Information contained within this part of the book is | |
| 376 | − of interest only for advanced interaction of mac80211 | |
| 377 | − with drivers to exploit more hardware capabilities and | |
| 378 | − improve performance. | |
| 379 | − </para> | |
| 380 | − </partintro> | |
| 381 | − | |
| 382 | − <chapter id="led-support"> | |
| 383 | − <title>LED support</title> | |
| 384 | − <para> | |
| 385 | − Mac80211 supports various ways of blinking LEDs. Wherever possible, | |
| 386 | − device LEDs should be exposed as LED class devices and hooked up to | |
| 387 | − the appropriate trigger, which will then be triggered appropriately | |
| 388 | − by mac80211. | |
| 389 | − </para> | |
| 390 | −!Finclude/net/mac80211.h ieee80211_get_tx_led_name | |
| 391 | −!Finclude/net/mac80211.h ieee80211_get_rx_led_name | |
| 392 | −!Finclude/net/mac80211.h ieee80211_get_assoc_led_name | |
| 393 | −!Finclude/net/mac80211.h ieee80211_get_radio_led_name | |
| 394 | −!Finclude/net/mac80211.h ieee80211_tpt_blink | |
| 395 | −!Finclude/net/mac80211.h ieee80211_tpt_led_trigger_flags | |
| 396 | −!Finclude/net/mac80211.h ieee80211_create_tpt_led_trigger | |
| 397 | − </chapter> | |
| 398 | − | |
| 399 | − <chapter id="hardware-crypto-offload"> | |
| 400 | − <title>Hardware crypto acceleration</title> | |
| 401 | −!Pinclude/net/mac80211.h Hardware crypto acceleration | |
| 402 | − <!-- intentionally multiple !F lines to get proper order --> | |
| 403 | −!Finclude/net/mac80211.h set_key_cmd | |
| 404 | −!Finclude/net/mac80211.h ieee80211_key_conf | |
| 405 | −!Finclude/net/mac80211.h ieee80211_key_flags | |
| 406 | −!Finclude/net/mac80211.h ieee80211_get_tkip_p1k | |
| 407 | −!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv | |
| 408 | −!Finclude/net/mac80211.h ieee80211_get_tkip_p2k | |
| 409 | − </chapter> | |
| 410 | − | |
| 411 | − <chapter id="powersave"> | |
| 412 | − <title>Powersave support</title> | |
| 413 | −!Pinclude/net/mac80211.h Powersave support | |
| 414 | − </chapter> | |
| 415 | − | |
| 416 | − <chapter id="beacon-filter"> | |
| 417 | − <title>Beacon filter support</title> | |
| 418 | −!Pinclude/net/mac80211.h Beacon filter support | |
| 419 | −!Finclude/net/mac80211.h ieee80211_beacon_loss | |
| 420 | − </chapter> | |
| 421 | − | |
| 422 | − <chapter id="qos"> | |
| 423 | − <title>Multiple queues and QoS support</title> | |
| 424 | − <para>TBD</para> | |
| 425 | −!Finclude/net/mac80211.h ieee80211_tx_queue_params | |
| 426 | − </chapter> | |
| 427 | − | |
| 428 | − <chapter id="AP"> | |
| 429 | − <title>Access point mode support</title> | |
| 430 | − <para>TBD</para> | |
| 431 | − <para>Some parts of the if_conf should be discussed here instead</para> | |
| 432 | − <para> | |
| 433 | − Insert notes about VLAN interfaces with hw crypto here or | |
| 434 | − in the hw crypto chapter. | |
| 435 | − </para> | |
| 436 | − <section id="ps-client"> | |
| 437 | − <title>support for powersaving clients</title> | |
| 438 | −!Pinclude/net/mac80211.h AP support for powersaving clients | |
| 439 | −!Finclude/net/mac80211.h ieee80211_get_buffered_bc | |
| 440 | −!Finclude/net/mac80211.h ieee80211_beacon_get | |
| 441 | −!Finclude/net/mac80211.h ieee80211_sta_eosp | |
| 442 | −!Finclude/net/mac80211.h ieee80211_frame_release_type | |
| 443 | −!Finclude/net/mac80211.h ieee80211_sta_ps_transition | |
| 444 | −!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni | |
| 445 | −!Finclude/net/mac80211.h ieee80211_sta_set_buffered | |
| 446 | −!Finclude/net/mac80211.h ieee80211_sta_block_awake | |
| 447 | − </section> | |
| 448 | − </chapter> | |
| 449 | − | |
| 450 | − <chapter id="multi-iface"> | |
| 451 | − <title>Supporting multiple virtual interfaces</title> | |
| 452 | − <para>TBD</para> | |
| 453 | − <para> | |
| 454 | − Note: WDS with identical MAC address should almost always be OK | |
| 455 | − </para> | |
| 456 | − <para> | |
| 457 | − Insert notes about having multiple virtual interfaces with | |
| 458 | − different MAC addresses here, note which configurations are | |
| 459 | − supported by mac80211, add notes about supporting hw crypto | |
| 460 | − with it. | |
| 461 | − </para> | |
| 462 | −!Finclude/net/mac80211.h ieee80211_iterate_active_interfaces | |
| 463 | −!Finclude/net/mac80211.h ieee80211_iterate_active_interfaces_atomic | |
| 464 | − </chapter> | |
| 465 | − | |
| 466 | − <chapter id="station-handling"> | |
| 467 | − <title>Station handling</title> | |
| 468 | − <para>TODO</para> | |
| 469 | −!Finclude/net/mac80211.h ieee80211_sta | |
| 470 | −!Finclude/net/mac80211.h sta_notify_cmd | |
| 471 | −!Finclude/net/mac80211.h ieee80211_find_sta | |
| 472 | −!Finclude/net/mac80211.h ieee80211_find_sta_by_ifaddr | |
| 473 | − </chapter> | |
| 474 | − | |
| 475 | − <chapter id="hardware-scan-offload"> | |
| 476 | − <title>Hardware scan offload</title> | |
| 477 | − <para>TBD</para> | |
| 478 | −!Finclude/net/mac80211.h ieee80211_scan_completed | |
| 479 | − </chapter> | |
| 480 | − | |
| 481 | − <chapter id="aggregation"> | |
| 482 | − <title>Aggregation</title> | |
| 483 | − <sect1> | |
| 484 | − <title>TX A-MPDU aggregation</title> | |
| 485 | −!Pnet/mac80211/agg-tx.c TX A-MPDU aggregation | |
| 486 | −!Cnet/mac80211/agg-tx.c | |
| 487 | − </sect1> | |
| 488 | − <sect1> | |
| 489 | − <title>RX A-MPDU aggregation</title> | |
| 490 | −!Pnet/mac80211/agg-rx.c RX A-MPDU aggregation | |
| 491 | −!Cnet/mac80211/agg-rx.c | |
| 492 | −!Finclude/net/mac80211.h ieee80211_ampdu_mlme_action | |
| 493 | − </sect1> | |
| 494 | − </chapter> | |
| 495 | − | |
| 496 | − <chapter id="smps"> | |
| 497 | − <title>Spatial Multiplexing Powersave (SMPS)</title> | |
| 498 | −!Pinclude/net/mac80211.h Spatial multiplexing power save | |
| 499 | −!Finclude/net/mac80211.h ieee80211_request_smps | |
| 500 | −!Finclude/net/mac80211.h ieee80211_smps_mode | |
| 501 | − </chapter> | |
| 502 | − </part> | |
| 503 | − | |
| 504 | − <part id="rate-control"> | |
| 505 | − <title>Rate control interface</title> | |
| 506 | − <partintro> | |
| 507 | − <para>TBD</para> | |
| 508 | − <para> | |
| 509 | − This part of the book describes the rate control algorithm | |
| 510 | − interface and how it relates to mac80211 and drivers. | |
| 511 | − </para> | |
| 512 | − </partintro> | |
| 513 | − <chapter id="ratecontrol-api"> | |
| 514 | − <title>Rate Control API</title> | |
| 515 | − <para>TBD</para> | |
| 516 | −!Finclude/net/mac80211.h ieee80211_start_tx_ba_session | |
| 517 | −!Finclude/net/mac80211.h ieee80211_start_tx_ba_cb_irqsafe | |
| 518 | −!Finclude/net/mac80211.h ieee80211_stop_tx_ba_session | |
| 519 | −!Finclude/net/mac80211.h ieee80211_stop_tx_ba_cb_irqsafe | |
| 520 | −!Finclude/net/mac80211.h ieee80211_rate_control_changed | |
| 521 | −!Finclude/net/mac80211.h ieee80211_tx_rate_control | |
| 522 | −!Finclude/net/mac80211.h rate_control_send_low | |
| 523 | − </chapter> | |
| 524 | − </part> | |
| 525 | − | |
| 526 | − <part id="internal"> | |
| 527 | − <title>Internals</title> | |
| 528 | − <partintro> | |
| 529 | − <para>TBD</para> | |
| 530 | − <para> | |
| 531 | − This part of the book describes mac80211 internals. | |
| 532 | − </para> | |
| 533 | − </partintro> | |
| 534 | − | |
| 535 | − <chapter id="key-handling"> | |
| 536 | − <title>Key handling</title> | |
| 537 | − <sect1> | |
| 538 | − <title>Key handling basics</title> | |
| 539 | −!Pnet/mac80211/key.c Key handling basics | |
| 540 | − </sect1> | |
| 541 | − <sect1> | |
| 542 | − <title>MORE TBD</title> | |
| 543 | − <para>TBD</para> | |
| 544 | − </sect1> | |
| 545 | − </chapter> | |
| 546 | − | |
| 547 | − <chapter id="rx-processing"> | |
| 548 | − <title>Receive processing</title> | |
| 549 | − <para>TBD</para> | |
| 550 | − </chapter> | |
| 551 | − | |
| 552 | − <chapter id="tx-processing"> | |
| 553 | − <title>Transmit processing</title> | |
| 554 | − <para>TBD</para> | |
| 555 | − </chapter> | |
| 556 | − | |
| 557 | − <chapter id="sta-info"> | |
| 558 | − <title>Station info handling</title> | |
| 559 | − <sect1> | |
| 560 | − <title>Programming information</title> | |
| 561 | −!Fnet/mac80211/sta_info.h sta_info | |
| 562 | −!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags | |
| 563 | − </sect1> | |
| 564 | − <sect1> | |
| 565 | − <title>STA information lifetime rules</title> | |
| 566 | −!Pnet/mac80211/sta_info.c STA information lifetime rules | |
| 567 | − </sect1> | |
| 568 | − </chapter> | |
| 569 | − | |
| 570 | − <chapter id="aggregation-internals"> | |
| 571 | − <title>Aggregation</title> | |
| 572 | −!Fnet/mac80211/sta_info.h sta_ampdu_mlme | |
| 573 | −!Fnet/mac80211/sta_info.h tid_ampdu_tx | |
| 574 | −!Fnet/mac80211/sta_info.h tid_ampdu_rx | |
| 575 | − </chapter> | |
| 576 | − | |
| 577 | − <chapter id="synchronisation"> | |
| 578 | − <title>Synchronisation</title> | |
| 579 | − <para>TBD</para> | |
| 580 | − <para>Locking, lots of RCU</para> | |
| 581 | − </chapter> | |
| 582 | − </part> | |
| 583 | − </book> | |
| 584 | −</set> | |
| @@ -6,13 +6,13 @@ · 5 unmodified lines | ||
| 6 | 6 | # To add a new book the only step required is to add the book to the |
| 7 | 7 | # list of DOCBOOKS. |
| 8 | 8 | |
| 9 | −DOCBOOKS := z8530book.xml device-drivers.xml \ | |
| 9 | +DOCBOOKS := z8530book.xml \ | |
| 10 | 10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ |
| 11 | 11 | writing_usb_driver.xml networking.xml \ |
| 12 | 12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ |
| 13 | 13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ |
| 14 | 14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ |
| 15 | − 80211.xml debugobjects.xml sh.xml regulator.xml \ | |
| 15 | + debugobjects.xml sh.xml regulator.xml \ | |
| 16 | 16 | alsa-driver-api.xml writing-an-alsa-driver.xml \ |
| 17 | 17 | tracepoint.xml w1.xml \ |
| 18 | 18 | writing_musb_glue_layer.xml crypto-API.xml iio.xml |
| @@ -22,9 +22,15 @@ ifeq ($(DOCBOOKS),) · 3 unmodified lines | ||
| 22 | 22 | # Skip DocBook build if the user explicitly requested no DOCBOOKS. |
| 23 | 23 | .DEFAULT: |
| 24 | 24 | @echo " SKIP DocBook $@ target (DOCBOOKS=\"\" specified)." |
| 25 | +else | |
| 26 | +ifneq ($(SPHINXDIRS),) | |
| 25 | 27 | |
| 28 | +# Skip DocBook build if the user explicitly requested a sphinx dir | |
| 29 | +.DEFAULT: | |
| 30 | + @echo " SKIP DocBook $@ target (SPHINXDIRS specified)." | |
| 26 | 31 | else |
| 27 | 32 | |
| 33 | + | |
| 28 | 34 | ### |
| 29 | 35 | # The build process is as follows (targets): |
| 30 | 36 | # (xmldocs) [by docproc] |
| @@ -66,6 +72,7 @@ installmandocs: mandocs · 35 unmodified lines | ||
| 66 | 72 | |
| 67 | 73 | # no-op for the DocBook toolchain |
| 68 | 74 | epubdocs: |
| 75 | +latexdocs: | |
| 69 | 76 | |
| 70 | 77 | ### |
| 71 | 78 | #External programs used |
| @@ -221,6 +228,7 @@ silent_gen_xml = : · 149 unmodified lines | ||
| 221 | 228 | echo "</programlisting>") > $@ |
| 222 | 229 | |
| 223 | 230 | endif # DOCBOOKS="" |
| 231 | +endif # SPHINDIR=... | |
| 224 | 232 | |
| 225 | 233 | ### |
| 226 | 234 | # Help targets as used by the top-level makefile |
| @@ -797,7 +797,8 @@ kernel crypto API | Caller · 796 unmodified lines | ||
| 797 | 797 | include/linux/crypto.h and their definition can be seen below. |
| 798 | 798 | The former function registers a single transformation, while |
| 799 | 799 | the latter works on an array of transformation descriptions. |
| 800 | − The latter is useful when registering transformations in bulk. | |
| 800 | + The latter is useful when registering transformations in bulk, | |
| 801 | + for example when a driver implements multiple transformations. | |
| 801 | 802 | </para> |
| 802 | 803 | |
| 803 | 804 | <programlisting> |
| @@ -822,18 +823,31 @@ kernel crypto API | Caller · 18 unmodified lines | ||
| 822 | 823 | </para> |
| 823 | 824 | |
| 824 | 825 | <para> |
| 825 | − The bulk registration / unregistration functions require | |
| 826 | − that struct crypto_alg is an array of count size. These | |
| 827 | − functions simply loop over that array and register / | |
| 828 | − unregister each individual algorithm. If an error occurs, | |
| 829 | − the loop is terminated at the offending algorithm definition. | |
| 830 | − That means, the algorithms prior to the offending algorithm | |
| 831 | − are successfully registered. Note, the caller has no way of | |
| 832 | − knowing which cipher implementations have successfully | |
| 833 | − registered. If this is important to know, the caller should | |
| 834 | − loop through the different implementations using the single | |
| 835 | − instance *_alg functions for each individual implementation. | |
| 826 | + The bulk registration/unregistration functions | |
| 827 | + register/unregister each transformation in the given array of | |
| 828 | + length count. They handle errors as follows: | |
| 836 | 829 | </para> |
| 830 | + <itemizedlist> | |
| 831 | + <listitem> | |
| 832 | + <para> | |
| 833 | + crypto_register_algs() succeeds if and only if it | |
| 834 | + successfully registers all the given transformations. If an | |
| 835 | + error occurs partway through, then it rolls back successful | |
| 836 | + registrations before returning the error code. Note that if | |
| 837 | + a driver needs to handle registration errors for individual | |
| 838 | + transformations, then it will need to use the non-bulk | |
| 839 | + function crypto_register_alg() instead. | |
| 840 | + </para> | |
| 841 | + </listitem> | |
| 842 | + <listitem> | |
| 843 | + <para> | |
| 844 | + crypto_unregister_algs() tries to unregister all the given | |
| 845 | + transformations, continuing on error. It logs errors and | |
| 846 | + always returns zero. | |
| 847 | + </para> | |
| 848 | + </listitem> | |
| 849 | + </itemizedlist> | |
| 850 | + | |
| 837 | 851 | </sect1> |
| 838 | 852 | |
| 839 | 853 | <sect1><title>Single-Block Symmetric Ciphers [CIPHER]</title> |
| @@ -1,521 +0,0 @@ | ||
| 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="LinuxDriversAPI"> | |
| 6 | − <bookinfo> | |
| 7 | − <title>Linux Device Drivers</title> | |
| 8 | − | |
| 9 | − <legalnotice> | |
| 10 | − <para> | |
| 11 | − This documentation is free software; you can redistribute | |
| 12 | − it and/or modify it under the terms of the GNU General Public | |
| 13 | − License as published by the Free Software Foundation; either | |
| 14 | − version 2 of the License, or (at your option) any later | |
| 15 | − version. | |
| 16 | − </para> | |
| 17 | − | |
| 18 | − <para> | |
| 19 | − This program is distributed in the hope that it will be | |
| 20 | − useful, but WITHOUT ANY WARRANTY; without even the implied | |
| 21 | − warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | |
| 22 | − See the GNU General Public License for more details. | |
| 23 | − </para> | |
| 24 | − | |
| 25 | − <para> | |
| 26 | − You should have received a copy of the GNU General Public | |
| 27 | − License along with this program; if not, write to the Free | |
| 28 | − Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, | |
| 29 | − MA 02111-1307 USA | |
| 30 | − </para> | |
| 31 | − | |
| 32 | − <para> | |
| 33 | − For more details see the file COPYING in the source | |
| 34 | − distribution of Linux. | |
| 35 | − </para> | |
| 36 | − </legalnotice> | |
| 37 | − </bookinfo> | |
| 38 | − | |
| 39 | −<toc></toc> | |
| 40 | − | |
| 41 | − <chapter id="Basics"> | |
| 42 | − <title>Driver Basics</title> | |
| 43 | − <sect1><title>Driver Entry and Exit points</title> | |
| 44 | −!Iinclude/linux/init.h | |
| 45 | − </sect1> | |
| 46 | − | |
| 47 | − <sect1><title>Atomic and pointer manipulation</title> | |
| 48 | −!Iarch/x86/include/asm/atomic.h | |
| 49 | − </sect1> | |
| 50 | − | |
| 51 | − <sect1><title>Delaying, scheduling, and timer routines</title> | |
| 52 | −!Iinclude/linux/sched.h | |
| 53 | −!Ekernel/sched/core.c | |
| 54 | −!Ikernel/sched/cpupri.c | |
| 55 | −!Ikernel/sched/fair.c | |
| 56 | −!Iinclude/linux/completion.h | |
| 57 | −!Ekernel/time/timer.c | |
| 58 | − </sect1> | |
| 59 | − <sect1><title>Wait queues and Wake events</title> | |
| 60 | −!Iinclude/linux/wait.h | |
| 61 | −!Ekernel/sched/wait.c | |
| 62 | − </sect1> | |
| 63 | − <sect1><title>High-resolution timers</title> | |
| 64 | −!Iinclude/linux/ktime.h | |
| 65 | −!Iinclude/linux/hrtimer.h | |
| 66 | −!Ekernel/time/hrtimer.c | |
| 67 | − </sect1> | |
| 68 | − <sect1><title>Workqueues and Kevents</title> | |
| 69 | −!Iinclude/linux/workqueue.h | |
| 70 | −!Ekernel/workqueue.c | |
| 71 | − </sect1> | |
| 72 | − <sect1><title>Internal Functions</title> | |
| 73 | −!Ikernel/exit.c | |
| 74 | −!Ikernel/signal.c | |
| 75 | −!Iinclude/linux/kthread.h | |
| 76 | −!Ekernel/kthread.c | |
| 77 | − </sect1> | |
| 78 | − | |
| 79 | − <sect1><title>Kernel objects manipulation</title> | |
| 80 | −<!-- | |
| 81 | −X!Iinclude/linux/kobject.h | |
| 82 | −--> | |
| 83 | −!Elib/kobject.c | |
| 84 | − </sect1> | |
| 85 | − | |
| 86 | − <sect1><title>Kernel utility functions</title> | |
| 87 | −!Iinclude/linux/kernel.h | |
| 88 | −!Ekernel/printk/printk.c | |
| 89 | −!Ekernel/panic.c | |
| 90 | −!Ekernel/sys.c | |
| 91 | −!Ekernel/rcu/srcu.c | |
| 92 | −!Ekernel/rcu/tree.c | |
| 93 | −!Ekernel/rcu/tree_plugin.h | |
| 94 | −!Ekernel/rcu/update.c | |
| 95 | − </sect1> | |
| 96 | − | |
| 97 | − <sect1><title>Device Resource Management</title> | |
| 98 | −!Edrivers/base/devres.c | |
| 99 | − </sect1> | |
| 100 | − | |
| 101 | − </chapter> | |
| 102 | − | |
| 103 | − <chapter id="devdrivers"> | |
| 104 | − <title>Device drivers infrastructure</title> | |
| 105 | − <sect1><title>The Basic Device Driver-Model Structures </title> | |
| 106 | −!Iinclude/linux/device.h | |
| 107 | − </sect1> | |
| 108 | − <sect1><title>Device Drivers Base</title> | |
| 109 | −!Idrivers/base/init.c | |
| 110 | −!Edrivers/base/driver.c | |
| 111 | −!Edrivers/base/core.c | |
| 112 | −!Edrivers/base/syscore.c | |
| 113 | −!Edrivers/base/class.c | |
| 114 | −!Idrivers/base/node.c | |
| 115 | −!Edrivers/base/firmware_class.c | |
| 116 | −!Edrivers/base/transport_class.c | |
| 117 | −<!-- Cannot be included, because | |
| 118 | − attribute_container_add_class_device_adapter | |
| 119 | − and attribute_container_classdev_to_container | |
| 120 | − exceed allowed 44 characters maximum | |
| 121 | −X!Edrivers/base/attribute_container.c | |
| 122 | −--> | |
| 123 | −!Edrivers/base/dd.c | |
| 124 | −<!-- | |
| 125 | −X!Edrivers/base/interface.c | |
| 126 | −--> | |
| 127 | −!Iinclude/linux/platform_device.h | |
| 128 | −!Edrivers/base/platform.c | |
| 129 | −!Edrivers/base/bus.c | |
| 130 | − </sect1> | |
| 131 | − <sect1> | |
| 132 | − <title>Buffer Sharing and Synchronization</title> | |
| 133 | − <para> | |
| 134 | − The dma-buf subsystem provides the framework for sharing buffers | |
| 135 | − for hardware (DMA) access across multiple device drivers and | |
| 136 | − subsystems, and for synchronizing asynchronous hardware access. | |
| 137 | − </para> | |
| 138 | − <para> | |
| 139 | − This is used, for example, by drm "prime" multi-GPU support, but | |
| 140 | − is of course not limited to GPU use cases. | |
| 141 | − </para> | |
| 142 | − <para> | |
| 143 | − The three main components of this are: (1) dma-buf, representing | |
| 144 | − a sg_table and exposed to userspace as a file descriptor to allow | |
| 145 | − passing between devices, (2) fence, which provides a mechanism | |
| 146 | − to signal when one device as finished access, and (3) reservation, | |
| 147 | − which manages the shared or exclusive fence(s) associated with | |
| 148 | − the buffer. | |
| 149 | − </para> | |
| 150 | − <sect2><title>dma-buf</title> | |
| 151 | −!Edrivers/dma-buf/dma-buf.c | |
| 152 | −!Iinclude/linux/dma-buf.h | |
| 153 | − </sect2> | |
| 154 | − <sect2><title>reservation</title> | |
| 155 | −!Pdrivers/dma-buf/reservation.c Reservation Object Overview | |
| 156 | −!Edrivers/dma-buf/reservation.c | |
| 157 | −!Iinclude/linux/reservation.h | |
| 158 | − </sect2> | |
| 159 | − <sect2><title>fence</title> | |
| 160 | −!Edrivers/dma-buf/fence.c | |
| 161 | −!Iinclude/linux/fence.h | |
| 162 | −!Edrivers/dma-buf/seqno-fence.c | |
| 163 | −!Iinclude/linux/seqno-fence.h | |
| 164 | −!Edrivers/dma-buf/fence-array.c | |
| 165 | −!Iinclude/linux/fence-array.h | |
| 166 | −!Edrivers/dma-buf/reservation.c | |
| 167 | −!Iinclude/linux/reservation.h | |
| 168 | −!Edrivers/dma-buf/sync_file.c | |
| 169 | −!Iinclude/linux/sync_file.h | |
| 170 | − </sect2> | |
| 171 | − </sect1> | |
| 172 | − <sect1><title>Device Drivers DMA Management</title> | |
| 173 | −!Edrivers/base/dma-coherent.c | |
| 174 | −!Edrivers/base/dma-mapping.c | |
| 175 | − </sect1> | |
| 176 | − <sect1><title>Device Drivers Power Management</title> | |
| 177 | −!Edrivers/base/power/main.c | |
| 178 | − </sect1> | |
| 179 | − <sect1><title>Device Drivers ACPI Support</title> | |
| 180 | −<!-- Internal functions only | |
| 181 | −X!Edrivers/acpi/sleep/main.c | |
| 182 | −X!Edrivers/acpi/sleep/wakeup.c | |
| 183 | −X!Edrivers/acpi/motherboard.c | |
| 184 | −X!Edrivers/acpi/bus.c | |
| 185 | −--> | |
| 186 | −!Edrivers/acpi/scan.c | |
| 187 | −!Idrivers/acpi/scan.c | |
| 188 | −<!-- No correct structured comments | |
| 189 | −X!Edrivers/acpi/pci_bind.c | |
| 190 | −--> | |
| 191 | − </sect1> | |
| 192 | − <sect1><title>Device drivers PnP support</title> | |
| 193 | −!Idrivers/pnp/core.c | |
| 194 | −<!-- No correct structured comments | |
| 195 | −X!Edrivers/pnp/system.c | |
| 196 | − --> | |
| 197 | −!Edrivers/pnp/card.c | |
| 198 | −!Idrivers/pnp/driver.c | |
| 199 | −!Edrivers/pnp/manager.c | |
| 200 | −!Edrivers/pnp/support.c | |
| 201 | − </sect1> | |
| 202 | − <sect1><title>Userspace IO devices</title> | |
| 203 | −!Edrivers/uio/uio.c | |
| 204 | −!Iinclude/linux/uio_driver.h | |
| 205 | − </sect1> | |
| 206 | − </chapter> | |
| 207 | − | |
| 208 | − <chapter id="parportdev"> | |
| 209 | − <title>Parallel Port Devices</title> | |
| 210 | −!Iinclude/linux/parport.h | |
| 211 | −!Edrivers/parport/ieee1284.c | |
| 212 | −!Edrivers/parport/share.c | |
| 213 | −!Idrivers/parport/daisy.c | |
| 214 | − </chapter> | |
| 215 | − | |
| 216 | − <chapter id="message_devices"> | |
| 217 | − <title>Message-based devices</title> | |
| 218 | − <sect1><title>Fusion message devices</title> | |
| 219 | −!Edrivers/message/fusion/mptbase.c | |
| 220 | −!Idrivers/message/fusion/mptbase.c | |
| 221 | −!Edrivers/message/fusion/mptscsih.c | |
| 222 | −!Idrivers/message/fusion/mptscsih.c | |
| 223 | −!Idrivers/message/fusion/mptctl.c | |
| 224 | −!Idrivers/message/fusion/mptspi.c | |
| 225 | −!Idrivers/message/fusion/mptfc.c | |
| 226 | −!Idrivers/message/fusion/mptlan.c | |
| 227 | − </sect1> | |
| 228 | − </chapter> | |
| 229 | − | |
| 230 | − <chapter id="snddev"> | |
| 231 | − <title>Sound Devices</title> | |
| 232 | −!Iinclude/sound/core.h | |
| 233 | −!Esound/sound_core.c | |
| 234 | −!Iinclude/sound/pcm.h | |
| 235 | −!Esound/core/pcm.c | |
| 236 | −!Esound/core/device.c | |
| 237 | −!Esound/core/info.c | |
| 238 | −!Esound/core/rawmidi.c | |
| 239 | −!Esound/core/sound.c | |
| 240 | −!Esound/core/memory.c | |
| 241 | −!Esound/core/pcm_memory.c | |
| 242 | −!Esound/core/init.c | |
| 243 | −!Esound/core/isadma.c | |
| 244 | −!Esound/core/control.c | |
| 245 | −!Esound/core/pcm_lib.c | |
| 246 | −!Esound/core/hwdep.c | |
| 247 | −!Esound/core/pcm_native.c | |
| 248 | −!Esound/core/memalloc.c | |
| 249 | −<!-- FIXME: Removed for now since no structured comments in source | |
| 250 | −X!Isound/sound_firmware.c | |
| 251 | −--> | |
| 252 | − </chapter> | |
| 253 | − | |
| 254 | − | |
| 255 | − <chapter id="uart16x50"> | |
| 256 | − <title>16x50 UART Driver</title> | |
| 257 | −!Edrivers/tty/serial/serial_core.c | |
| 258 | −!Edrivers/tty/serial/8250/8250_core.c | |
| 259 | − </chapter> | |
| 260 | − | |
| 261 | − <chapter id="fbdev"> | |
| 262 | − <title>Frame Buffer Library</title> | |
| 263 | − | |
| 264 | − <para> | |
| 265 | − The frame buffer drivers depend heavily on four data structures. | |
| 266 | − These structures are declared in include/linux/fb.h. They are | |
| 267 | − fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. | |
| 268 | − The last three can be made available to and from userland. | |
| 269 | − </para> | |
| 270 | − | |
| 271 | − <para> | |
| 272 | − fb_info defines the current state of a particular video card. | |
| 273 | − Inside fb_info, there exists a fb_ops structure which is a | |
| 274 | − collection of needed functions to make fbdev and fbcon work. | |
| 275 | − fb_info is only visible to the kernel. | |
| 276 | − </para> | |
| 277 | − | |
| 278 | − <para> | |
| 279 | − fb_var_screeninfo is used to describe the features of a video card | |
| 280 | − that are user defined. With fb_var_screeninfo, things such as | |
| 281 | − depth and the resolution may be defined. | |
| 282 | − </para> | |
| 283 | − | |
| 284 | − <para> | |
| 285 | − The next structure is fb_fix_screeninfo. This defines the | |
| 286 | − properties of a card that are created when a mode is set and can't | |
| 287 | − be changed otherwise. A good example of this is the start of the | |
| 288 | − frame buffer memory. This "locks" the address of the frame buffer | |
| 289 | − memory, so that it cannot be changed or moved. | |
| 290 | − </para> | |
| 291 | − | |
| 292 | − <para> | |
| 293 | − The last structure is fb_monospecs. In the old API, there was | |
| 294 | − little importance for fb_monospecs. This allowed for forbidden things | |
| 295 | − such as setting a mode of 800x600 on a fix frequency monitor. With | |
| 296 | − the new API, fb_monospecs prevents such things, and if used | |
| 297 | − correctly, can prevent a monitor from being cooked. fb_monospecs | |
| 298 | − will not be useful until kernels 2.5.x. | |
| 299 | − </para> | |
| 300 | − | |
| 301 | − <sect1><title>Frame Buffer Memory</title> | |
| 302 | −!Edrivers/video/fbdev/core/fbmem.c | |
| 303 | − </sect1> | |
| 304 | −<!-- | |
| 305 | − <sect1><title>Frame Buffer Console</title> | |
| 306 | −X!Edrivers/video/console/fbcon.c | |
| 307 | − </sect1> | |
| 308 | −--> | |
| 309 | − <sect1><title>Frame Buffer Colormap</title> | |
| 310 | −!Edrivers/video/fbdev/core/fbcmap.c | |
| 311 | − </sect1> | |
| 312 | −<!-- FIXME: | |
| 313 | − drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment | |
| 314 | − out until somebody adds docs. KAO | |
| 315 | − <sect1><title>Frame Buffer Generic Functions</title> | |
| 316 | −X!Idrivers/video/fbgen.c | |
| 317 | − </sect1> | |
| 318 | −KAO --> | |
| 319 | − <sect1><title>Frame Buffer Video Mode Database</title> | |
| 320 | −!Idrivers/video/fbdev/core/modedb.c | |
| 321 | −!Edrivers/video/fbdev/core/modedb.c | |
| 322 | − </sect1> | |
| 323 | − <sect1><title>Frame Buffer Macintosh Video Mode Database</title> | |
| 324 | −!Edrivers/video/fbdev/macmodes.c | |
| 325 | − </sect1> | |
| 326 | − <sect1><title>Frame Buffer Fonts</title> | |
| 327 | − <para> | |
| 328 | − Refer to the file lib/fonts/fonts.c for more information. | |
| 329 | − </para> | |
| 330 | −<!-- FIXME: Removed for now since no structured comments in source | |
| 331 | −X!Ilib/fonts/fonts.c | |
| 332 | −--> | |
| 333 | − </sect1> | |
| 334 | − </chapter> | |
| 335 | − | |
| 336 | − <chapter id="input_subsystem"> | |
| 337 | − <title>Input Subsystem</title> | |
| 338 | − <sect1><title>Input core</title> | |
| 339 | −!Iinclude/linux/input.h | |
| 340 | −!Edrivers/input/input.c | |
| 341 | −!Edrivers/input/ff-core.c | |
| 342 | −!Edrivers/input/ff-memless.c | |
| 343 | − </sect1> | |
| 344 | − <sect1><title>Multitouch Library</title> | |
| 345 | −!Iinclude/linux/input/mt.h | |
| 346 | −!Edrivers/input/input-mt.c | |
| 347 | − </sect1> | |
| 348 | − <sect1><title>Polled input devices</title> | |
| 349 | −!Iinclude/linux/input-polldev.h | |
| 350 | −!Edrivers/input/input-polldev.c | |
| 351 | − </sect1> | |
| 352 | − <sect1><title>Matrix keyboards/keypads</title> | |
| 353 | −!Iinclude/linux/input/matrix_keypad.h | |
| 354 | − </sect1> | |
| 355 | − <sect1><title>Sparse keymap support</title> | |
| 356 | −!Iinclude/linux/input/sparse-keymap.h | |
| 357 | −!Edrivers/input/sparse-keymap.c | |
| 358 | − </sect1> | |
| 359 | − </chapter> | |
| 360 | − | |
| 361 | − <chapter id="spi"> | |
| 362 | − <title>Serial Peripheral Interface (SPI)</title> | |
| 363 | − <para> | |
| 364 | − SPI is the "Serial Peripheral Interface", widely used with | |
| 365 | − embedded systems because it is a simple and efficient | |
| 366 | − interface: basically a multiplexed shift register. | |
| 367 | − Its three signal wires hold a clock (SCK, often in the range | |
| 368 | − of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and | |
| 369 | − a "Master In, Slave Out" (MISO) data line. | |
| 370 | − SPI is a full duplex protocol; for each bit shifted out the | |
| 371 | − MOSI line (one per clock) another is shifted in on the MISO line. | |
| 372 | − Those bits are assembled into words of various sizes on the | |
| 373 | − way to and from system memory. | |
| 374 | − An additional chipselect line is usually active-low (nCS); | |
| 375 | − four signals are normally used for each peripheral, plus | |
| 376 | − sometimes an interrupt. | |
| 377 | − </para> | |
| 378 | − <para> | |
| 379 | − The SPI bus facilities listed here provide a generalized | |
| 380 | − interface to declare SPI busses and devices, manage them | |
| 381 | − according to the standard Linux driver model, and perform | |
| 382 | − input/output operations. | |
| 383 | − At this time, only "master" side interfaces are supported, | |
| 384 | − where Linux talks to SPI peripherals and does not implement | |
| 385 | − such a peripheral itself. | |
| 386 | − (Interfaces to support implementing SPI slaves would | |
| 387 | − necessarily look different.) | |
| 388 | − </para> | |
| 389 | − <para> | |
| 390 | − The programming interface is structured around two kinds of driver, | |
| 391 | − and two kinds of device. | |
| 392 | − A "Controller Driver" abstracts the controller hardware, which may | |
| 393 | − be as simple as a set of GPIO pins or as complex as a pair of FIFOs | |
| 394 | − connected to dual DMA engines on the other side of the SPI shift | |
| 395 | − register (maximizing throughput). Such drivers bridge between | |
| 396 | − whatever bus they sit on (often the platform bus) and SPI, and | |
| 397 | − expose the SPI side of their device as a | |
| 398 | − <structname>struct spi_master</structname>. | |
| 399 | − SPI devices are children of that master, represented as a | |
| 400 | − <structname>struct spi_device</structname> and manufactured from | |
| 401 | − <structname>struct spi_board_info</structname> descriptors which | |
| 402 | − are usually provided by board-specific initialization code. | |
| 403 | − A <structname>struct spi_driver</structname> is called a | |
| 404 | − "Protocol Driver", and is bound to a spi_device using normal | |
| 405 | − driver model calls. | |
| 406 | − </para> | |
| 407 | − <para> | |
| 408 | − The I/O model is a set of queued messages. Protocol drivers | |
| 409 | − submit one or more <structname>struct spi_message</structname> | |
| 410 | − objects, which are processed and completed asynchronously. | |
| 411 | − (There are synchronous wrappers, however.) Messages are | |
| 412 | − built from one or more <structname>struct spi_transfer</structname> | |
| 413 | − objects, each of which wraps a full duplex SPI transfer. | |
| 414 | − A variety of protocol tweaking options are needed, because | |
| 415 | − different chips adopt very different policies for how they | |
| 416 | − use the bits transferred with SPI. | |
| 417 | − </para> | |
| 418 | −!Iinclude/linux/spi/spi.h | |
| 419 | −!Fdrivers/spi/spi.c spi_register_board_info | |
| 420 | −!Edrivers/spi/spi.c | |
| 421 | − </chapter> | |
| 422 | − | |
| 423 | − <chapter id="i2c"> | |
| 424 | − <title>I<superscript>2</superscript>C and SMBus Subsystem</title> | |
| 425 | − | |
| 426 | − <para> | |
| 427 | − I<superscript>2</superscript>C (or without fancy typography, "I2C") | |
| 428 | − is an acronym for the "Inter-IC" bus, a simple bus protocol which is | |
| 429 | − widely used where low data rate communications suffice. | |
| 430 | − Since it's also a licensed trademark, some vendors use another | |
| 431 | − name (such as "Two-Wire Interface", TWI) for the same bus. | |
| 432 | − I2C only needs two signals (SCL for clock, SDA for data), conserving | |
| 433 | − board real estate and minimizing signal quality issues. | |
| 434 | − Most I2C devices use seven bit addresses, and bus speeds of up | |
| 435 | − to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet | |
| 436 | − found wide use. | |
| 437 | − I2C is a multi-master bus; open drain signaling is used to | |
| 438 | − arbitrate between masters, as well as to handshake and to | |
| 439 | − synchronize clocks from slower clients. | |
| 440 | − </para> | |
| 441 | − | |
| 442 | − <para> | |
| 443 | − The Linux I2C programming interfaces support only the master | |
| 444 | − side of bus interactions, not the slave side. | |
| 445 | − The programming interface is structured around two kinds of driver, | |
| 446 | − and two kinds of device. | |
| 447 | − An I2C "Adapter Driver" abstracts the controller hardware; it binds | |
| 448 | − to a physical device (perhaps a PCI device or platform_device) and | |
| 449 | − exposes a <structname>struct i2c_adapter</structname> representing | |
| 450 | − each I2C bus segment it manages. | |
| 451 | − On each I2C bus segment will be I2C devices represented by a | |
| 452 | − <structname>struct i2c_client</structname>. Those devices will | |
| 453 | − be bound to a <structname>struct i2c_driver</structname>, | |
| 454 | − which should follow the standard Linux driver model. | |
| 455 | − (At this writing, a legacy model is more widely used.) | |
| 456 | − There are functions to perform various I2C protocol operations; at | |
| 457 | − this writing all such functions are usable only from task context. | |
| 458 | − </para> | |
| 459 | − | |
| 460 | − <para> | |
| 461 | − The System Management Bus (SMBus) is a sibling protocol. Most SMBus | |
| 462 | − systems are also I2C conformant. The electrical constraints are | |
| 463 | − tighter for SMBus, and it standardizes particular protocol messages | |
| 464 | − and idioms. Controllers that support I2C can also support most | |
| 465 | − SMBus operations, but SMBus controllers don't support all the protocol | |
| 466 | − options that an I2C controller will. | |
| 467 | − There are functions to perform various SMBus protocol operations, | |
| 468 | − either using I2C primitives or by issuing SMBus commands to | |
| 469 | − i2c_adapter devices which don't support those I2C operations. | |
| 470 | − </para> | |
| 471 | − | |
| 472 | −!Iinclude/linux/i2c.h | |
| 473 | −!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info | |
| 474 | −!Edrivers/i2c/i2c-core.c | |
| 475 | − </chapter> | |
| 476 | − | |
| 477 | − <chapter id="hsi"> | |
| 478 | − <title>High Speed Synchronous Serial Interface (HSI)</title> | |
| 479 | − | |
| 480 | − <para> | |
| 481 | − High Speed Synchronous Serial Interface (HSI) is a | |
| 482 | − serial interface mainly used for connecting application | |
| 483 | − engines (APE) with cellular modem engines (CMT) in cellular | |
| 484 | − handsets. | |
| 485 | − | |
| 486 | − HSI provides multiplexing for up to 16 logical channels, | |
| 487 | − low-latency and full duplex communication. | |
| 488 | − </para> | |
| 489 | − | |
| 490 | −!Iinclude/linux/hsi/hsi.h | |
| 491 | −!Edrivers/hsi/hsi_core.c | |
| 492 | − </chapter> | |
| 493 | − | |
| 494 | − <chapter id="pwm"> | |
| 495 | − <title>Pulse-Width Modulation (PWM)</title> | |
| 496 | − <para> | |
| 497 | − Pulse-width modulation is a modulation technique primarily used to | |
| 498 | − control power supplied to electrical devices. | |
| 499 | − </para> | |
| 500 | − <para> | |
| 501 | − The PWM framework provides an abstraction for providers and consumers | |
| 502 | − of PWM signals. A controller that provides one or more PWM signals is | |
| 503 | − registered as <structname>struct pwm_chip</structname>. Providers are | |
| 504 | − expected to embed this structure in a driver-specific structure. This | |
| 505 | − structure contains fields that describe a particular chip. | |
| 506 | − </para> | |
| 507 | − <para> | |
| 508 | − A chip exposes one or more PWM signal sources, each of which exposed | |
| 509 | − as a <structname>struct pwm_device</structname>. Operations can be | |
| 510 | − performed on PWM devices to control the period, duty cycle, polarity | |
| 511 | − and active state of the signal. | |
| 512 | − </para> | |
| 513 | − <para> | |
| 514 | − Note that PWM devices are exclusive resources: they can always only be | |
| 515 | − used by one consumer at a time. | |
| 516 | − </para> | |
| 517 | −!Iinclude/linux/pwm.h | |
| 518 | −!Edrivers/pwm/core.c | |
| 519 | − </chapter> | |
| 520 | − | |
| 521 | −</book> | |
| @@ -483,7 +483,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); · 482 unmodified lines | ||
| 483 | 483 | <function>get_user()</function> |
| 484 | 484 | / |
| 485 | 485 | <function>put_user()</function> |
| 486 | − <filename class="headerfile">include/asm/uaccess.h</filename> | |
| 486 | + <filename class="headerfile">include/linux/uaccess.h</filename> | |
| 487 | 487 | </title> |
| 488 | 488 | |
| 489 | 489 | <para> |
| @@ -1,5 +1,5 @@ | ||
| 1 | 1 | HOWTO do Linux kernel development |
| 2 | −--------------------------------- | |
| 2 | +================================= | |
| 3 | 3 | |
| 4 | 4 | This is the be-all, end-all document on this topic. It contains |
| 5 | 5 | instructions on how to become a Linux kernel developer and how to learn |
| @@ -28,6 +28,7 @@ kernel development. Assembly (any architecture) is not required unless · 22 unmodified lines | ||
| 28 | 28 | you plan to do low-level development for that architecture. Though they |
| 29 | 29 | are not a good substitute for a solid C education and/or years of |
| 30 | 30 | experience, the following books are good for, if anything, reference: |
| 31 | + | |
| 31 | 32 | - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall] |
| 32 | 33 | - "Practical C Programming" by Steve Oualline [O'Reilly] |
| 33 | 34 | - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] |
| @@ -64,7 +65,8 @@ people on the mailing lists are not lawyers, and you should not rely on · 30 unmodified lines | ||
| 64 | 65 | their statements on legal matters. |
| 65 | 66 | |
| 66 | 67 | For common questions and answers about the GPL, please see: |
| 67 | − http://www.gnu.org/licenses/gpl-faq.html | |
| 68 | + | |
| 69 | + https://www.gnu.org/licenses/gpl-faq.html | |
| 68 | 70 | |
| 69 | 71 | |
| 70 | 72 | Documentation |
| @@ -82,96 +84,118 @@ linux-api@vger.kernel.org. · 11 unmodified lines | ||
| 82 | 84 | |
| 83 | 85 | Here is a list of files that are in the kernel source tree that are |
| 84 | 86 | required reading: |
| 87 | + | |
| 85 | 88 | README |
| 86 | 89 | This file gives a short background on the Linux kernel and describes |
| 87 | 90 | what is necessary to do to configure and build the kernel. People |
| 88 | 91 | who are new to the kernel should start here. |
| 89 | 92 | |
| 90 | − Documentation/Changes | |
| 93 | + :ref:`Documentation/Changes <changes>` | |
| 91 | 94 | This file gives a list of the minimum levels of various software |
| 92 | 95 | packages that are necessary to build and run the kernel |
| 93 | 96 | successfully. |
| 94 | 97 | |
| 95 | − Documentation/CodingStyle | |
| 98 | + :ref:`Documentation/CodingStyle <codingstyle>` | |
| 96 | 99 | This describes the Linux kernel coding style, and some of the |
| 97 | 100 | rationale behind it. All new code is expected to follow the |
| 98 | 101 | guidelines in this document. Most maintainers will only accept |
| 99 | 102 | patches if these rules are followed, and many people will only |
| 100 | 103 | review code if it is in the proper style. |
| 101 | 104 | |
| 102 | − Documentation/SubmittingPatches | |
| 103 | − Documentation/SubmittingDrivers | |
| 105 | + :ref:`Documentation/SubmittingPatches <submittingpatches>` and :ref:`Documentation/SubmittingDrivers <submittingdrivers>` | |
| 104 | 106 | These files describe in explicit detail how to successfully create |
| 105 | 107 | and send a patch, including (but not limited to): |
| 108 | + | |
| 106 | 109 | - Email contents |
| 107 | 110 | - Email format |
| 108 | 111 | - Who to send it to |
| 112 | + | |
| 109 | 113 | Following these rules will not guarantee success (as all patches are |
| 110 | 114 | subject to scrutiny for content and style), but not following them |
| 111 | 115 | will almost always prevent it. |
| 112 | 116 | |
| 113 | 117 | Other excellent descriptions of how to create patches properly are: |
| 118 | + | |
| 114 | 119 | "The Perfect Patch" |
| 115 | − http://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 120 | + https://www.ozlabs.org/~akpm/stuff/tpp.txt | |
| 121 | + | |
| 116 | 122 | "Linux kernel patch submission format" |
| 117 | 123 | http://linux.yyz.us/patch-format.html |
| 118 | 124 | |
| 119 | − Documentation/stable_api_nonsense.txt | |
| 125 | + :ref:`Documentation/stable_api_nonsense.txt <stable_api_nonsense>` | |
| 120 | 126 | This file describes the rationale behind the conscious decision to |
| 121 | 127 | not have a stable API within the kernel, including things like: |
| 128 | + | |
| 122 | 129 | - Subsystem shim-layers (for compatibility?) |
| 123 | 130 | - Driver portability between Operating Systems. |
| 124 | 131 | - Mitigating rapid change within the kernel source tree (or |
| 125 | 132 | preventing rapid change) |
| 133 | + | |
| 126 | 134 | This document is crucial for understanding the Linux development |
| 127 | 135 | philosophy and is very important for people moving to Linux from |
| 128 | 136 | development on other Operating Systems. |
| 129 | 137 | |
| 130 | − Documentation/SecurityBugs | |
| 138 | + :ref:`Documentation/SecurityBugs <securitybugs>` | |
| 131 | 139 | If you feel you have found a security problem in the Linux kernel, |
| 132 | 140 | please follow the steps in this document to help notify the kernel |
| 133 | 141 | developers, and help solve the issue. |
| 134 | 142 | |
| 135 | − Documentation/ManagementStyle | |
| 143 | + :ref:`Documentation/ManagementStyle <managementstyle>` | |
| 136 | 144 | This document describes how Linux kernel maintainers operate and the |
| 137 | 145 | shared ethos behind their methodologies. This is important reading |
| 138 | 146 | for anyone new to kernel development (or anyone simply curious about |
| 139 | 147 | it), as it resolves a lot of common misconceptions and confusion |
| 140 | 148 | about the unique behavior of kernel maintainers. |
| 141 | 149 | |
| 142 | − Documentation/stable_kernel_rules.txt | |
| 150 | + :ref:`Documentation/stable_kernel_rules.txt <stable_kernel_rules>` | |
| 143 | 151 | This file describes the rules on how the stable kernel releases |
| 144 | 152 | happen, and what to do if you want to get a change into one of these |
| 145 | 153 | releases. |
| 146 | 154 | |
| 147 | − Documentation/kernel-docs.txt | |
| 155 | + :ref:`Documentation/kernel-docs.txt <kernel_docs>` | |
| 148 | 156 | A list of external documentation that pertains to kernel |
| 149 | 157 | development. Please consult this list if you do not find what you |
| 150 | 158 | are looking for within the in-kernel documentation. |
| 151 | 159 | |
| 152 | − Documentation/applying-patches.txt | |
| 160 | + :ref:`Documentation/applying-patches.txt <applying_patches>` | |
| 153 | 161 | A good introduction describing exactly what a patch is and how to |
| 154 | 162 | apply it to the different development branches of the kernel. |
| 155 | 163 | |
| 156 | 164 | The kernel also has a large number of documents that can be |
| 157 | −automatically generated from the source code itself. This includes a | |
| 165 | +automatically generated from the source code itself or from | |
| 166 | +ReStructuredText markups (ReST), like this one. This includes a | |
| 158 | 167 | full description of the in-kernel API, and rules on how to handle |
| 159 | −locking properly. The documents will be created in the | |
| 160 | −Documentation/DocBook/ directory and can be generated as PDF, | |
| 161 | −Postscript, HTML, and man pages by running: | |
| 168 | +locking properly. | |
| 169 | + | |
| 170 | +All such documents can be generated as PDF or HTML by running:: | |
| 171 | + | |
| 162 | 172 | make pdfdocs |
| 163 | − make psdocs | |
| 164 | 173 | make htmldocs |
| 165 | − make mandocs | |
| 174 | + | |
| 166 | 175 | respectively from the main kernel source directory. |
| 167 | 176 | |
| 177 | +The documents that uses ReST markup will be generated at Documentation/output. | |
| 178 | +They can also be generated on LaTeX and ePub formats with:: | |
| 179 | + | |
| 180 | + make latexdocs | |
| 181 | + make epubdocs | |
| 182 | + | |
| 183 | +Currently, there are some documents written on DocBook that are in | |
| 184 | +the process of conversion to ReST. Such documents will be created in the | |
| 185 | +Documentation/DocBook/ directory and can be generated also as | |
| 186 | +Postscript or man pages by running:: | |
| 187 | + | |
| 188 | + make psdocs | |
| 189 | + make mandocs | |
| 168 | 190 | |
| 169 | 191 | Becoming A Kernel Developer |
| 170 | 192 | --------------------------- |
| 171 | 193 | |
| 172 | 194 | If you do not know anything about Linux kernel development, you should |
| 173 | 195 | look at the Linux KernelNewbies project: |
| 174 | − http://kernelnewbies.org | |
| 196 | + | |
| 197 | + https://kernelnewbies.org | |
| 198 | + | |
| 175 | 199 | It consists of a helpful mailing list where you can ask almost any type |
| 176 | 200 | of basic kernel development question (make sure to search the archives |
| 177 | 201 | first, before asking something that has already been answered in the |
| @@ -187,7 +211,9 @@ apply a patch. · 9 unmodified lines | ||
| 187 | 211 | If you do not know where you want to start, but you want to look for |
| 188 | 212 | some task to start doing to join into the kernel development community, |
| 189 | 213 | go to the Linux Kernel Janitor's project: |
| 190 | − http://kernelnewbies.org/KernelJanitors | |
| 214 | + | |
| 215 | + https://kernelnewbies.org/KernelJanitors | |
| 216 | + | |
| 191 | 217 | It is a great place to start. It describes a list of relatively simple |
| 192 | 218 | problems that need to be cleaned up and fixed within the Linux kernel |
| 193 | 219 | source tree. Working with the developers in charge of this project, you |
| @@ -199,7 +225,8 @@ If you already have a chunk of code that you want to put into the kernel · 5 unmodified lines | ||
| 199 | 225 | tree, but need some help getting it in the proper form, the |
| 200 | 226 | kernel-mentors project was created to help you out with this. It is a |
| 201 | 227 | mailing list, and can be found at: |
| 202 | − http://selenic.com/mailman/listinfo/kernel-mentors | |
| 228 | + | |
| 229 | + https://selenic.com/mailman/listinfo/kernel-mentors | |
| 203 | 230 | |
| 204 | 231 | Before making any actual modifications to the Linux kernel code, it is |
| 205 | 232 | imperative to understand how the code in question works. For this |
| @@ -209,6 +236,7 @@ tools. One such tool that is particularly recommended is the Linux · 3 unmodified lines | ||
| 209 | 236 | Cross-Reference project, which is able to present source code in a |
| 210 | 237 | self-referential, indexed webpage format. An excellent up-to-date |
| 211 | 238 | repository of the kernel code may be found at: |
| 239 | + | |
| 212 | 240 | http://lxr.free-electrons.com/ |
| 213 | 241 | |
| 214 | 242 | |
| @@ -218,6 +246,7 @@ The development process · 3 unmodified lines | ||
| 218 | 246 | Linux kernel development process currently consists of a few different |
| 219 | 247 | main kernel "branches" and lots of different subsystem-specific kernel |
| 220 | 248 | branches. These different branches are: |
| 249 | + | |
| 221 | 250 | - main 4.x kernel tree |
| 222 | 251 | - 4.x.y -stable kernel tree |
| 223 | 252 | - 4.x -git kernel patches |
| @@ -227,14 +256,15 @@ branches. These different branches are: · 3 unmodified lines | ||
| 227 | 256 | 4.x kernel tree |
| 228 | 257 | ----------------- |
| 229 | 258 | 4.x kernels are maintained by Linus Torvalds, and can be found on |
| 230 | −kernel.org in the pub/linux/kernel/v4.x/ directory. Its development | |
| 259 | +https://kernel.org in the pub/linux/kernel/v4.x/ directory. Its development | |
| 231 | 260 | process is as follows: |
| 261 | + | |
| 232 | 262 | - As soon as a new kernel is released a two weeks window is open, |
| 233 | 263 | during this period of time maintainers can submit big diffs to |
| 234 | 264 | Linus, usually the patches that have already been included in the |
| 235 | 265 | -next kernel for a few weeks. The preferred way to submit big changes |
| 236 | 266 | is using git (the kernel's source management tool, more information |
| 237 | − can be found at http://git-scm.com/) but plain patches are also just | |
| 267 | + can be found at https://git-scm.com/) but plain patches are also just | |
| 238 | 268 | fine. |
| 239 | 269 | - After two weeks a -rc1 kernel is released it is now possible to push |
| 240 | 270 | only patches that do not include new features that could affect the |
| @@ -253,9 +283,10 @@ process is as follows: · 12 unmodified lines | ||
| 253 | 283 | |
| 254 | 284 | It is worth mentioning what Andrew Morton wrote on the linux-kernel |
| 255 | 285 | mailing list about kernel releases: |
| 256 | − "Nobody knows when a kernel will be released, because it's | |
| 286 | + | |
| 287 | + *"Nobody knows when a kernel will be released, because it's | |
| 257 | 288 | released according to perceived bug status, not according to a |
| 258 | − preconceived timeline." | |
| 289 | + preconceived timeline."* | |
| 259 | 290 | |
| 260 | 291 | 4.x.y -stable kernel tree |
| 261 | 292 | ------------------------- |
| @@ -301,7 +332,7 @@ submission and other already ongoing work are avoided. · 39 unmodified lines | ||
| 301 | 332 | Most of these repositories are git trees, but there are also other SCMs |
| 302 | 333 | in use, or patch queues being published as quilt series. Addresses of |
| 303 | 334 | these subsystem repositories are listed in the MAINTAINERS file. Many |
| 304 | −of them can be browsed at http://git.kernel.org/. | |
| 335 | +of them can be browsed at https://git.kernel.org/. | |
| 305 | 336 | |
| 306 | 337 | Before a proposed patch is committed to such a subsystem tree, it is |
| 307 | 338 | subject to review which primarily happens on mailing lists (see the |
| @@ -310,7 +341,7 @@ process is tracked with the tool patchwork. Patchwork offers a web · 2 unmodified lines | ||
| 310 | 341 | interface which shows patch postings, any comments on a patch or |
| 311 | 342 | revisions to it, and maintainers can mark patches as under review, |
| 312 | 343 | accepted, or rejected. Most of these patchwork sites are listed at |
| 313 | −http://patchwork.kernel.org/. | |
| 344 | +https://patchwork.kernel.org/. | |
| 314 | 345 | |
| 315 | 346 | 4.x -next kernel tree for integration tests |
| 316 | 347 | ------------------------------------------- |
| @@ -318,7 +349,8 @@ Before updates from subsystem trees are merged into the mainline 4.x · 1 unmodified line | ||
| 318 | 349 | tree, they need to be integration-tested. For this purpose, a special |
| 319 | 350 | testing repository exists into which virtually all subsystem trees are |
| 320 | 351 | pulled on an almost daily basis: |
| 321 | − http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git | |
| 352 | + | |
| 353 | + https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git | |
| 322 | 354 | |
| 323 | 355 | This way, the -next kernel gives a summary outlook onto what will be |
| 324 | 356 | expected to go into the mainline kernel at the next merge period. |
| @@ -328,10 +360,11 @@ Adventurous testers are very welcome to runtime-test the -next kernel. · 3 unmodified lines | ||
| 328 | 360 | Bug Reporting |
| 329 | 361 | ------------- |
| 330 | 362 | |
| 331 | −bugzilla.kernel.org is where the Linux kernel developers track kernel | |
| 363 | +https://bugzilla.kernel.org is where the Linux kernel developers track kernel | |
| 332 | 364 | bugs. Users are encouraged to report all bugs that they find in this |
| 333 | 365 | tool. For details on how to use the kernel bugzilla, please see: |
| 334 | − http://bugzilla.kernel.org/page.cgi?id=faq.html | |
| 366 | + | |
| 367 | + https://bugzilla.kernel.org/page.cgi?id=faq.html | |
| 335 | 368 | |
| 336 | 369 | The file REPORTING-BUGS in the main kernel source directory has a good |
| 337 | 370 | template for how to report a possible kernel bug, and details what kind |
| @@ -349,13 +382,14 @@ your skills, and other developers will be aware of your presence. Fixing · 11 unmodified lines | ||
| 349 | 382 | bugs is one of the best ways to get merits among other developers, because |
| 350 | 383 | not many people like wasting time fixing other people's bugs. |
| 351 | 384 | |
| 352 | −To work in the already reported bug reports, go to http://bugzilla.kernel.org. | |
| 385 | +To work in the already reported bug reports, go to https://bugzilla.kernel.org. | |
| 353 | 386 | If you want to be advised of the future bug reports, you can subscribe to the |
| 354 | 387 | bugme-new mailing list (only new bug reports are mailed here) or to the |
| 355 | 388 | bugme-janitor mailing list (every change in the bugzilla is mailed here) |
| 356 | 389 | |
| 357 | − http://lists.linux-foundation.org/mailman/listinfo/bugme-new | |
| 358 | − http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors | |
| 390 | + https://lists.linux-foundation.org/mailman/listinfo/bugme-new | |
| 391 | + | |
| 392 | + https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors | |
| 359 | 393 | |
| 360 | 394 | |
| 361 | 395 | |
| @@ -365,10 +399,14 @@ Mailing lists · 3 unmodified lines | ||
| 365 | 399 | As some of the above documents describe, the majority of the core kernel |
| 366 | 400 | developers participate on the Linux Kernel Mailing list. Details on how |
| 367 | 401 | to subscribe and unsubscribe from the list can be found at: |
| 402 | + | |
| 368 | 403 | http://vger.kernel.org/vger-lists.html#linux-kernel |
| 404 | + | |
| 369 | 405 | There are archives of the mailing list on the web in many different |
| 370 | 406 | places. Use a search engine to find these archives. For example: |
| 407 | + | |
| 371 | 408 | http://dir.gmane.org/gmane.linux.kernel |
| 409 | + | |
| 372 | 410 | It is highly recommended that you search the archives about the topic |
| 373 | 411 | you want to bring up, before you post it to the list. A lot of things |
| 374 | 412 | already discussed in detail are only recorded at the mailing list |
| @@ -381,11 +419,13 @@ groups. · 6 unmodified lines | ||
| 381 | 419 | |
| 382 | 420 | Many of the lists are hosted on kernel.org. Information on them can be |
| 383 | 421 | found at: |
| 422 | + | |
| 384 | 423 | http://vger.kernel.org/vger-lists.html |
| 385 | 424 | |
| 386 | 425 | Please remember to follow good behavioral habits when using the lists. |
| 387 | 426 | Though a bit cheesy, the following URL has some simple guidelines for |
| 388 | 427 | interacting with the list (or any list): |
| 428 | + | |
| 389 | 429 | http://www.albion.com/netiquette/ |
| 390 | 430 | |
| 391 | 431 | If multiple people respond to your mail, the CC: list of recipients may |
| @@ -400,13 +440,14 @@ add your statements between the individual quoted sections instead of · 8 unmodified lines | ||
| 400 | 440 | writing at the top of the mail. |
| 401 | 441 | |
| 402 | 442 | If you add patches to your mail, make sure they are plain readable text |
| 403 | −as stated in Documentation/SubmittingPatches. Kernel developers don't | |
| 404 | −want to deal with attachments or compressed patches; they may want | |
| 405 | −to comment on individual lines of your patch, which works only that way. | |
| 406 | −Make sure you use a mail program that does not mangle spaces and tab | |
| 407 | −characters. A good first test is to send the mail to yourself and try | |
| 408 | −to apply your own patch by yourself. If that doesn't work, get your | |
| 409 | −mail program fixed or change it until it works. | |
| 443 | +as stated in Documentation/SubmittingPatches. | |
| 444 | +Kernel developers don't want to deal with | |
| 445 | +attachments or compressed patches; they may want to comment on | |
| 446 | +individual lines of your patch, which works only that way. Make sure you | |
| 447 | +use a mail program that does not mangle spaces and tab characters. A | |
| 448 | +good first test is to send the mail to yourself and try to apply your | |
| 449 | +own patch by yourself. If that doesn't work, get your mail program fixed | |
| 450 | +or change it until it works. | |
| 410 | 451 | |
| 411 | 452 | Above all, please remember to show respect to other subscribers. |
| 412 | 453 | |
| @@ -418,6 +459,7 @@ The goal of the kernel community is to provide the best possible kernel · 5 unmodified lines | ||
| 418 | 459 | there is. When you submit a patch for acceptance, it will be reviewed |
| 419 | 460 | on its technical merits and those alone. So, what should you be |
| 420 | 461 | expecting? |
| 462 | + | |
| 421 | 463 | - criticism |
| 422 | 464 | - comments |
| 423 | 465 | - requests for change |
| @@ -432,6 +474,7 @@ If there are no responses to your posting, wait a few days and try · 8 unmodified lines | ||
| 432 | 474 | again, sometimes things get lost in the huge volume. |
| 433 | 475 | |
| 434 | 476 | What should you not do? |
| 477 | + | |
| 435 | 478 | - expect your patch to be accepted without question |
| 436 | 479 | - become defensive |
| 437 | 480 | - ignore comments |
| @@ -445,8 +488,8 @@ Remember, being wrong is acceptable as long as you are willing to work · 7 unmodified lines | ||
| 445 | 488 | toward a solution that is right. |
| 446 | 489 | |
| 447 | 490 | It is normal that the answers to your first patch might simply be a list |
| 448 | −of a dozen things you should correct. This does _not_ imply that your | |
| 449 | −patch will not be accepted, and it is _not_ meant against you | |
| 491 | +of a dozen things you should correct. This does **not** imply that your | |
| 492 | +patch will not be accepted, and it is **not** meant against you | |
| 450 | 493 | personally. Simply correct all issues raised against your patch and |
| 451 | 494 | resend it. |
| 452 | 495 | |
| @@ -457,7 +500,9 @@ Differences between the kernel community and corporate structures · 4 unmodified lines | ||
| 457 | 500 | The kernel community works differently than most traditional corporate |
| 458 | 501 | development environments. Here are a list of things that you can try to |
| 459 | 502 | do to avoid problems: |
| 503 | + | |
| 460 | 504 | Good things to say regarding your proposed changes: |
| 505 | + | |
| 461 | 506 | - "This solves multiple problems." |
| 462 | 507 | - "This deletes 2000 lines of code." |
| 463 | 508 | - "Here is a patch that explains what I am trying to describe." |
| @@ -466,6 +511,7 @@ do to avoid problems: · 2 unmodified lines | ||
| 466 | 511 | - "This increases performance on typical machines..." |
| 467 | 512 | |
| 468 | 513 | Bad things you should avoid saying: |
| 514 | + | |
| 469 | 515 | - "We did it this way in AIX/ptx/Solaris, so therefore it must be |
| 470 | 516 | good..." |
| 471 | 517 | - "I've being doing this for 20 years, so..." |
| @@ -527,17 +573,18 @@ The reasons for breaking things up are the following: · 55 unmodified lines | ||
| 527 | 573 | and simplify (or simply re-order) patches before submitting them. |
| 528 | 574 | |
| 529 | 575 | Here is an analogy from kernel developer Al Viro: |
| 530 | − "Think of a teacher grading homework from a math student. The | |
| 576 | + | |
| 577 | + *"Think of a teacher grading homework from a math student. The | |
| 531 | 578 | teacher does not want to see the student's trials and errors |
| 532 | 579 | before they came up with the solution. They want to see the |
| 533 | 580 | cleanest, most elegant answer. A good student knows this, and |
| 534 | 581 | would never submit her intermediate work before the final |
| 535 | − solution." | |
| 582 | + solution.* | |
| 536 | 583 | |
| 537 | − The same is true of kernel development. The maintainers and | |
| 584 | + *The same is true of kernel development. The maintainers and | |
| 538 | 585 | reviewers do not want to see the thought process behind the |
| 539 | 586 | solution to the problem one is solving. They want to see a |
| 540 | − simple and elegant solution." | |
| 587 | + simple and elegant solution."* | |
| 541 | 588 | |
| 542 | 589 | It may be challenging to keep the balance between presenting an elegant |
| 543 | 590 | solution and working together with the community and discussing your |
| @@ -565,6 +612,7 @@ When sending in your patches, pay special attention to what you say in · 21 unmodified lines | ||
| 565 | 612 | the text in your email. This information will become the ChangeLog |
| 566 | 613 | information for the patch, and will be preserved for everyone to see for |
| 567 | 614 | all time. It should describe the patch completely, containing: |
| 615 | + | |
| 568 | 616 | - why the change is necessary |
| 569 | 617 | - the overall design approach in the patch |
| 570 | 618 | - implementation details |
| @@ -572,12 +620,11 @@ all time. It should describe the patch completely, containing: · 1 unmodified line | ||
| 572 | 620 | |
| 573 | 621 | For more details on what this should all look like, please see the |
| 574 | 622 | ChangeLog section of the document: |
| 623 | + | |
| 575 | 624 | "The Perfect Patch" |
| 576 | 625 | http://www.ozlabs.org/~akpm/stuff/tpp.txt |
| 577 | 626 | |
| 578 | 627 | |
| 579 | − | |
| 580 | − | |
| 581 | 628 | All of these things are sometimes very hard to do. It can take years to |
| 582 | 629 | perfect these practices (if at all). It's a continuous process of |
| 583 | 630 | improvement that requires a lot of patience and determination. But |
| @@ -588,8 +635,9 @@ start exactly where you are now. · 4 unmodified lines | ||
| 588 | 635 | |
| 589 | 636 | |
| 590 | 637 | ---------- |
| 638 | + | |
| 591 | 639 | Thanks to Paolo Ciarrocchi who allowed the "Development Process" |
| 592 | −(http://lwn.net/Articles/94386/) section | |
| 640 | +(https://lwn.net/Articles/94386/) section | |
| 593 | 641 | to be based on text he had written, and to Randy Dunlap and Gerrit |
| 594 | 642 | Huizenga for some of the list of things you should and should not say. |
| 595 | 643 | Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, |
| @@ -1,3 +1 @@ | ||
| 1 | −subdir-y := accounting auxdisplay blackfin \ | |
| 2 | − filesystems filesystems ia64 laptops mic misc-devices \ | |
| 3 | − networking pcmcia prctl ptp timers vDSO watchdog | |
| 1 | +subdir-y := | |
| @@ -5,6 +5,9 @@ · 4 unmodified lines | ||
| 5 | 5 | # You can set these variables from the command line. |
| 6 | 6 | SPHINXBUILD = sphinx-build |
| 7 | 7 | SPHINXOPTS = |
| 8 | +SPHINXDIRS = . | |
| 9 | +_SPHINXDIRS = $(patsubst $(srctree)/Documentation/%/conf.py,%,$(wildcard $(srctree)/Documentation/*/conf.py)) | |
| 10 | +SPHINX_CONF = conf.py | |
| 8 | 11 | PAPER = |
| 9 | 12 | BUILDDIR = $(obj)/output |
| 10 | 13 | |
| @@ -25,38 +28,62 @@ else ifneq ($(DOCBOOKS),) · 14 unmodified lines | ||
| 25 | 28 | |
| 26 | 29 | else # HAVE_SPHINX |
| 27 | 30 | |
| 28 | −# User-friendly check for rst2pdf | |
| 29 | −HAVE_RST2PDF := $(shell if python -c "import rst2pdf" >/dev/null 2>&1; then echo 1; else echo 0; fi) | |
| 31 | +# User-friendly check for pdflatex | |
| 32 | +HAVE_PDFLATEX := $(shell if which xelatex >/dev/null 2>&1; then echo 1; else echo 0; fi) | |
| 30 | 33 | |
| 31 | 34 | # Internal variables. |
| 32 | 35 | PAPEROPT_a4 = -D latex_paper_size=a4 |
| 33 | 36 | PAPEROPT_letter = -D latex_paper_size=letter |
| 34 | 37 | KERNELDOC = $(srctree)/scripts/kernel-doc |
| 35 | 38 | KERNELDOC_CONF = -D kerneldoc_srctree=$(srctree) -D kerneldoc_bin=$(KERNELDOC) |
| 36 | −ALLSPHINXOPTS = -D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) -d $(BUILDDIR)/.doctrees $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) -c $(srctree)/$(src) $(SPHINXOPTS) $(srctree)/$(src) | |
| 39 | +ALLSPHINXOPTS = $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) | |
| 37 | 40 | # the i18n builder cannot share the environment and doctrees with the others |
| 38 | 41 | I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . |
| 39 | 42 | |
| 40 | −quiet_cmd_sphinx = SPHINX $@ | |
| 41 | − cmd_sphinx = BUILDDIR=$(BUILDDIR) $(SPHINXBUILD) -b $2 $(ALLSPHINXOPTS) $(BUILDDIR)/$2 | |
| 43 | +# commands; the 'cmd' from scripts/Kbuild.include is not *loopable* | |
| 44 | +loop_cmd = $(echo-cmd) $(cmd_$(1)) | |
| 45 | + | |
| 46 | +# $2 sphinx builder e.g. "html" | |
| 47 | +# $3 name of the build subfolder / e.g. "media", used as: | |
| 48 | +# * dest folder relative to $(BUILDDIR) and | |
| 49 | +# * cache folder relative to $(BUILDDIR)/.doctrees | |
| 50 | +# $4 dest subfolder e.g. "man" for man pages at media/man | |
| 51 | +# $5 reST source folder relative to $(srctree)/$(src), | |
| 52 | +# e.g. "media" for the linux-tv book-set at ./Documentation/media | |
| 53 | + | |
| 54 | +quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4); | |
| 55 | + cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media all;\ | |
| 56 | + BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \ | |
| 57 | + $(SPHINXBUILD) \ | |
| 58 | + -b $2 \ | |
| 59 | + -c $(abspath $(srctree)/$(src)) \ | |
| 60 | + -d $(abspath $(BUILDDIR)/.doctrees/$3) \ | |
| 61 | + -D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \ | |
| 62 | + $(ALLSPHINXOPTS) \ | |
| 63 | + $(abspath $(srctree)/$(src)/$5) \ | |
| 64 | + $(abspath $(BUILDDIR)/$3/$4); | |
| 42 | 65 | |
| 43 | 66 | htmldocs: |
| 44 | − $(MAKE) BUILDDIR=$(BUILDDIR) -f $(srctree)/Documentation/media/Makefile $@ | |
| 45 | − $(call cmd,sphinx,html) | |
| 67 | + @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var))) | |
| 46 | 68 | |
| 47 | −pdfdocs: | |
| 48 | −ifeq ($(HAVE_RST2PDF),0) | |
| 49 | − $(warning The Python 'rst2pdf' module was not found. Make sure you have the module installed to produce PDF output.) | |
| 69 | +latexdocs: | |
| 70 | +ifeq ($(HAVE_PDFLATEX),0) | |
| 71 | + $(warning The 'xelatex' command was not found. Make sure you have it installed and in PATH to produce PDF output.) | |
| 50 | 72 | @echo " SKIP Sphinx $@ target." |
| 51 | −else # HAVE_RST2PDF | |
| 52 | − $(call cmd,sphinx,pdf) | |
| 53 | −endif # HAVE_RST2PDF | |
| 73 | +else # HAVE_PDFLATEX | |
| 74 | + @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,latex,$(var),latex,$(var))) | |
| 75 | +endif # HAVE_PDFLATEX | |
| 76 | + | |
| 77 | +pdfdocs: latexdocs | |
| 78 | +ifneq ($(HAVE_PDFLATEX),0) | |
| 79 | + $(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX=xelatex LATEXOPTS="-interaction=nonstopmode" -C $(BUILDDIR)/$(var)/latex) | |
| 80 | +endif # HAVE_PDFLATEX | |
| 54 | 81 | |
| 55 | 82 | epubdocs: |
| 56 | − $(call cmd,sphinx,epub) | |
| 83 | + @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,epub,$(var),epub,$(var))) | |
| 57 | 84 | |
| 58 | 85 | xmldocs: |
| 59 | − $(call cmd,sphinx,xml) | |
| 86 | + @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,xml,$(var),xml,$(var))) | |
| 60 | 87 | |
| 61 | 88 | # no-ops for the Sphinx toolchain |
| 62 | 89 | sgmldocs: |
| @@ -72,7 +99,14 @@ endif # HAVE_SPHINX · 9 unmodified lines | ||
| 72 | 99 | dochelp: |
| 73 | 100 | @echo ' Linux kernel internal documentation in different formats (Sphinx):' |
| 74 | 101 | @echo ' htmldocs - HTML' |
| 102 | + @echo ' latexdocs - LaTeX' | |
| 75 | 103 | @echo ' pdfdocs - PDF' |
| 76 | 104 | @echo ' epubdocs - EPUB' |
| 77 | 105 | @echo ' xmldocs - XML' |
| 78 | 106 | @echo ' cleandocs - clean all generated files' |
| 107 | + @echo | |
| 108 | + @echo ' make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2' | |
| 109 | + @echo ' valid values for SPHINXDIRS are: $(_SPHINXDIRS)' | |
| 110 | + @echo | |
| 111 | + @echo ' make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build' | |
| 112 | + @echo ' configuration. This is e.g. useful to build with nit-picking config.' | |
| @@ -1,10 +1,12 @@ | ||
| 1 | +.. _managementstyle: | |
| 1 | 2 | |
| 2 | − Linux kernel management style | |
| 3 | +Linux kernel management style | |
| 4 | +============================= | |
| 3 | 5 | |
| 4 | 6 | This is a short document describing the preferred (or made up, depending |
| 5 | 7 | on who you ask) management style for the linux kernel. It's meant to |
| 6 | 8 | mirror the CodingStyle document to some degree, and mainly written to |
| 7 | −avoid answering (*) the same (or similar) questions over and over again. | |
| 9 | +avoid answering [#f1]_ the same (or similar) questions over and over again. | |
| 8 | 10 | |
| 9 | 11 | Management style is very personal and much harder to quantify than |
| 10 | 12 | simple coding style rules, so this document may or may not have anything |
| @@ -14,50 +16,52 @@ might not actually be true. You'll have to decide for yourself. · 3 unmodified lines | ||
| 14 | 16 | Btw, when talking about "kernel manager", it's all about the technical |
| 15 | 17 | lead persons, not the people who do traditional management inside |
| 16 | 18 | companies. If you sign purchase orders or you have any clue about the |
| 17 | −budget of your group, you're almost certainly not a kernel manager. | |
| 18 | −These suggestions may or may not apply to you. | |
| 19 | +budget of your group, you're almost certainly not a kernel manager. | |
| 20 | +These suggestions may or may not apply to you. | |
| 19 | 21 | |
| 20 | 22 | First off, I'd suggest buying "Seven Habits of Highly Effective |
| 21 | −People", and NOT read it. Burn it, it's a great symbolic gesture. | |
| 23 | +People", and NOT read it. Burn it, it's a great symbolic gesture. | |
| 22 | 24 | |
| 23 | −(*) This document does so not so much by answering the question, but by | |
| 24 | −making it painfully obvious to the questioner that we don't have a clue | |
| 25 | −to what the answer is. | |
| 25 | +.. [#f1] This document does so not so much by answering the question, but by | |
| 26 | + making it painfully obvious to the questioner that we don't have a clue | |
| 27 | + to what the answer is. | |
| 26 | 28 | |
| 27 | 29 | Anyway, here goes: |
| 28 | 30 | |
| 31 | +.. _decisions: | |
| 29 | 32 | |
| 30 | − Chapter 1: Decisions | |
| 33 | +1) Decisions | |
| 34 | +------------ | |
| 31 | 35 | |
| 32 | 36 | Everybody thinks managers make decisions, and that decision-making is |
| 33 | 37 | important. The bigger and more painful the decision, the bigger the |
| 34 | 38 | manager must be to make it. That's very deep and obvious, but it's not |
| 35 | −actually true. | |
| 39 | +actually true. | |
| 36 | 40 | |
| 37 | −The name of the game is to _avoid_ having to make a decision. In | |
| 41 | +The name of the game is to **avoid** having to make a decision. In | |
| 38 | 42 | particular, if somebody tells you "choose (a) or (b), we really need you |
| 39 | 43 | to decide on this", you're in trouble as a manager. The people you |
| 40 | 44 | manage had better know the details better than you, so if they come to |
| 41 | 45 | you for a technical decision, you're screwed. You're clearly not |
| 42 | −competent to make that decision for them. | |
| 46 | +competent to make that decision for them. | |
| 43 | 47 | |
| 44 | 48 | (Corollary:if the people you manage don't know the details better than |
| 45 | −you, you're also screwed, although for a totally different reason. | |
| 46 | −Namely that you are in the wrong job, and that _they_ should be managing | |
| 47 | −your brilliance instead). | |
| 49 | +you, you're also screwed, although for a totally different reason. | |
| 50 | +Namely that you are in the wrong job, and that **they** should be managing | |
| 51 | +your brilliance instead). | |
| 48 | 52 | |
| 49 | −So the name of the game is to _avoid_ decisions, at least the big and | |
| 53 | +So the name of the game is to **avoid** decisions, at least the big and | |
| 50 | 54 | painful ones. Making small and non-consequential decisions is fine, and |
| 51 | 55 | makes you look like you know what you're doing, so what a kernel manager |
| 52 | 56 | needs to do is to turn the big and painful ones into small things where |
| 53 | −nobody really cares. | |
| 57 | +nobody really cares. | |
| 54 | 58 | |
| 55 | 59 | It helps to realize that the key difference between a big decision and a |
| 56 | 60 | small one is whether you can fix your decision afterwards. Any decision |
| 57 | 61 | can be made small by just always making sure that if you were wrong (and |
| 58 | −you _will_ be wrong), you can always undo the damage later by | |
| 62 | +you **will** be wrong), you can always undo the damage later by | |
| 59 | 63 | backtracking. Suddenly, you get to be doubly managerial for making |
| 60 | −_two_ inconsequential decisions - the wrong one _and_ the right one. | |
| 64 | +**two** inconsequential decisions - the wrong one **and** the right one. | |
| 61 | 65 | |
| 62 | 66 | And people will even see that as true leadership (*cough* bullshit |
| 63 | 67 | *cough*). |
| @@ -65,10 +69,10 @@ And people will even see that as true leadership (*cough* bullshit · 1 unmodified line | ||
| 65 | 69 | Thus the key to avoiding big decisions becomes to just avoiding to do |
| 66 | 70 | things that can't be undone. Don't get ushered into a corner from which |
| 67 | 71 | you cannot escape. A cornered rat may be dangerous - a cornered manager |
| 68 | −is just pitiful. | |
| 72 | +is just pitiful. | |
| 69 | 73 | |
| 70 | 74 | It turns out that since nobody would be stupid enough to ever really let |
| 71 | −a kernel manager have huge fiscal responsibility _anyway_, it's usually | |
| 75 | +a kernel manager have huge fiscal responsibility **anyway**, it's usually | |
| 72 | 76 | fairly easy to backtrack. Since you're not going to be able to waste |
| 73 | 77 | huge amounts of money that you might not be able to repay, the only |
| 74 | 78 | thing you can backtrack on is a technical decision, and there |
| @@ -76,113 +80,118 @@ back-tracking is very easy: just tell everybody that you were an · 1 unmodified line | ||
| 76 | 80 | incompetent nincompoop, say you're sorry, and undo all the worthless |
| 77 | 81 | work you had people work on for the last year. Suddenly the decision |
| 78 | 82 | you made a year ago wasn't a big decision after all, since it could be |
| 79 | −easily undone. | |
| 83 | +easily undone. | |
| 80 | 84 | |
| 81 | 85 | It turns out that some people have trouble with this approach, for two |
| 82 | 86 | reasons: |
| 87 | + | |
| 83 | 88 | - admitting you were an idiot is harder than it looks. We all like to |
| 84 | 89 | maintain appearances, and coming out in public to say that you were |
| 85 | − wrong is sometimes very hard indeed. | |
| 90 | + wrong is sometimes very hard indeed. | |
| 86 | 91 | - having somebody tell you that what you worked on for the last year |
| 87 | 92 | wasn't worthwhile after all can be hard on the poor lowly engineers |
| 88 | − too, and while the actual _work_ was easy enough to undo by just | |
| 93 | + too, and while the actual **work** was easy enough to undo by just | |
| 89 | 94 | deleting it, you may have irrevocably lost the trust of that |
| 90 | 95 | engineer. And remember: "irrevocable" was what we tried to avoid in |
| 91 | 96 | the first place, and your decision ended up being a big one after |
| 92 | − all. | |
| 97 | + all. | |
| 93 | 98 | |
| 94 | 99 | Happily, both of these reasons can be mitigated effectively by just |
| 95 | 100 | admitting up-front that you don't have a friggin' clue, and telling |
| 96 | 101 | people ahead of the fact that your decision is purely preliminary, and |
| 97 | 102 | might be the wrong thing. You should always reserve the right to change |
| 98 | −your mind, and make people very _aware_ of that. And it's much easier | |
| 99 | −to admit that you are stupid when you haven't _yet_ done the really | |
| 103 | +your mind, and make people very **aware** of that. And it's much easier | |
| 104 | +to admit that you are stupid when you haven't **yet** done the really | |
| 100 | 105 | stupid thing. |
| 101 | 106 | |
| 102 | 107 | Then, when it really does turn out to be stupid, people just roll their |
| 103 | −eyes and say "Oops, he did it again". | |
| 108 | +eyes and say "Oops, he did it again". | |
| 104 | 109 | |
| 105 | 110 | This preemptive admission of incompetence might also make the people who |
| 106 | 111 | actually do the work also think twice about whether it's worth doing or |
| 107 | −not. After all, if _they_ aren't certain whether it's a good idea, you | |
| 112 | +not. After all, if **they** aren't certain whether it's a good idea, you | |
| 108 | 113 | sure as hell shouldn't encourage them by promising them that what they |
| 109 | 114 | work on will be included. Make them at least think twice before they |
| 110 | −embark on a big endeavor. | |
| 115 | +embark on a big endeavor. | |
| 111 | 116 | |
| 112 | 117 | Remember: they'd better know more about the details than you do, and |
| 113 | 118 | they usually already think they have the answer to everything. The best |
| 114 | 119 | thing you can do as a manager is not to instill confidence, but rather a |
| 115 | −healthy dose of critical thinking on what they do. | |
| 120 | +healthy dose of critical thinking on what they do. | |
| 116 | 121 | |
| 117 | 122 | Btw, another way to avoid a decision is to plaintively just whine "can't |
| 118 | 123 | we just do both?" and look pitiful. Trust me, it works. If it's not |
| 119 | 124 | clear which approach is better, they'll eventually figure it out. The |
| 120 | 125 | answer may end up being that both teams get so frustrated by the |
| 121 | −situation that they just give up. | |
| 126 | +situation that they just give up. | |
| 122 | 127 | |
| 123 | 128 | That may sound like a failure, but it's usually a sign that there was |
| 124 | 129 | something wrong with both projects, and the reason the people involved |
| 125 | 130 | couldn't decide was that they were both wrong. You end up coming up |
| 126 | 131 | smelling like roses, and you avoided yet another decision that you could |
| 127 | −have screwed up on. | |
| 132 | +have screwed up on. | |
| 128 | 133 | |
| 129 | 134 | |
| 130 | − Chapter 2: People | |
| 135 | +2) People | |
| 136 | +--------- | |
| 131 | 137 | |
| 132 | 138 | Most people are idiots, and being a manager means you'll have to deal |
| 133 | −with it, and perhaps more importantly, that _they_ have to deal with | |
| 134 | −_you_. | |
| 139 | +with it, and perhaps more importantly, that **they** have to deal with | |
| 140 | +**you**. | |
| 135 | 141 | |
| 136 | 142 | It turns out that while it's easy to undo technical mistakes, it's not |
| 137 | 143 | as easy to undo personality disorders. You just have to live with |
| 138 | −theirs - and yours. | |
| 144 | +theirs - and yours. | |
| 139 | 145 | |
| 140 | 146 | However, in order to prepare yourself as a kernel manager, it's best to |
| 141 | 147 | remember not to burn any bridges, bomb any innocent villagers, or |
| 142 | 148 | alienate too many kernel developers. It turns out that alienating people |
| 143 | 149 | is fairly easy, and un-alienating them is hard. Thus "alienating" |
| 144 | 150 | immediately falls under the heading of "not reversible", and becomes a |
| 145 | −no-no according to Chapter 1. | |
| 151 | +no-no according to :ref:`decisions`. | |
| 146 | 152 | |
| 147 | 153 | There's just a few simple rules here: |
| 154 | + | |
| 148 | 155 | (1) don't call people d*ckheads (at least not in public) |
| 149 | 156 | (2) learn how to apologize when you forgot rule (1) |
| 150 | 157 | |
| 151 | 158 | The problem with #1 is that it's very easy to do, since you can say |
| 152 | −"you're a d*ckhead" in millions of different ways (*), sometimes without | |
| 159 | +"you're a d*ckhead" in millions of different ways [#f2]_, sometimes without | |
| 153 | 160 | even realizing it, and almost always with a white-hot conviction that |
| 154 | −you are right. | |
| 161 | +you are right. | |
| 155 | 162 | |
| 156 | 163 | And the more convinced you are that you are right (and let's face it, |
| 157 | −you can call just about _anybody_ a d*ckhead, and you often _will_ be | |
| 158 | −right), the harder it ends up being to apologize afterwards. | |
| 164 | +you can call just about **anybody** a d*ckhead, and you often **will** be | |
| 165 | +right), the harder it ends up being to apologize afterwards. | |
| 159 | 166 | |
| 160 | 167 | To solve this problem, you really only have two options: |
| 168 | + | |
| 161 | 169 | - get really good at apologies |
| 162 | 170 | - spread the "love" out so evenly that nobody really ends up feeling |
| 163 | 171 | like they get unfairly targeted. Make it inventive enough, and they |
| 164 | − might even be amused. | |
| 172 | + might even be amused. | |
| 165 | 173 | |
| 166 | 174 | The option of being unfailingly polite really doesn't exist. Nobody will |
| 167 | 175 | trust somebody who is so clearly hiding his true character. |
| 168 | 176 | |
| 169 | −(*) Paul Simon sang "Fifty Ways to Leave Your Lover", because quite | |
| 170 | −frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't | |
| 171 | −scan nearly as well. But I'm sure he thought about it. | |
| 177 | +.. [#f2] Paul Simon sang "Fifty Ways to Leave Your Lover", because quite | |
| 178 | + frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't | |
| 179 | + scan nearly as well. But I'm sure he thought about it. | |
| 172 | 180 | |
| 173 | 181 | |
| 174 | − Chapter 3: People II - the Good Kind | |
| 182 | +3) People II - the Good Kind | |
| 183 | +---------------------------- | |
| 175 | 184 | |
| 176 | 185 | While it turns out that most people are idiots, the corollary to that is |
| 177 | 186 | sadly that you are one too, and that while we can all bask in the secure |
| 178 | 187 | knowledge that we're better than the average person (let's face it, |
| 179 | 188 | nobody ever believes that they're average or below-average), we should |
| 180 | 189 | also admit that we're not the sharpest knife around, and there will be |
| 181 | −other people that are less of an idiot than you are. | |
| 190 | +other people that are less of an idiot than you are. | |
| 182 | 191 | |
| 183 | −Some people react badly to smart people. Others take advantage of them. | |
| 192 | +Some people react badly to smart people. Others take advantage of them. | |
| 184 | 193 | |
| 185 | −Make sure that you, as a kernel maintainer, are in the second group. | |
| 194 | +Make sure that you, as a kernel maintainer, are in the second group. | |
| 186 | 195 | Suck up to them, because they are the people who will make your job |
| 187 | 196 | easier. In particular, they'll be able to make your decisions for you, |
| 188 | 197 | which is what the game is all about. |
| @@ -191,7 +200,7 @@ So when you find somebody smarter than you are, just coast along. Your · 2 unmodified lines | ||
| 191 | 200 | management responsibilities largely become ones of saying "Sounds like a |
| 192 | 201 | good idea - go wild", or "That sounds good, but what about xxx?". The |
| 193 | 202 | second version in particular is a great way to either learn something |
| 194 | −new about "xxx" or seem _extra_ managerial by pointing out something the | |
| 203 | +new about "xxx" or seem **extra** managerial by pointing out something the | |
| 195 | 204 | smarter person hadn't thought about. In either case, you win. |
| 196 | 205 | |
| 197 | 206 | One thing to look out for is to realize that greatness in one area does |
| @@ -199,47 +208,49 @@ not necessarily translate to other areas. So you might prod people in · 1 unmodified line | ||
| 199 | 208 | specific directions, but let's face it, they might be good at what they |
| 200 | 209 | do, and suck at everything else. The good news is that people tend to |
| 201 | 210 | naturally gravitate back to what they are good at, so it's not like you |
| 202 | −are doing something irreversible when you _do_ prod them in some | |
| 211 | +are doing something irreversible when you **do** prod them in some | |
| 203 | 212 | direction, just don't push too hard. |
| 204 | 213 | |
| 205 | 214 | |
| 206 | − Chapter 4: Placing blame | |
| 215 | +4) Placing blame | |
| 216 | +---------------- | |
| 207 | 217 | |
| 208 | 218 | Things will go wrong, and people want somebody to blame. Tag, you're it. |
| 209 | 219 | |
| 210 | 220 | It's not actually that hard to accept the blame, especially if people |
| 211 | −kind of realize that it wasn't _all_ your fault. Which brings us to the | |
| 221 | +kind of realize that it wasn't **all** your fault. Which brings us to the | |
| 212 | 222 | best way of taking the blame: do it for another guy. You'll feel good |
| 213 | 223 | for taking the fall, he'll feel good about not getting blamed, and the |
| 214 | 224 | guy who lost his whole 36GB porn-collection because of your incompetence |
| 215 | 225 | will grudgingly admit that you at least didn't try to weasel out of it. |
| 216 | 226 | |
| 217 | 227 | Then make the developer who really screwed up (if you can find him) know |
| 218 | −_in_private_ that he screwed up. Not just so he can avoid it in the | |
| 228 | +**in_private** that he screwed up. Not just so he can avoid it in the | |
| 219 | 229 | future, but so that he knows he owes you one. And, perhaps even more |
| 220 | 230 | importantly, he's also likely the person who can fix it. Because, let's |
| 221 | −face it, it sure ain't you. | |
| 231 | +face it, it sure ain't you. | |
| 222 | 232 | |
| 223 | −Taking the blame is also why you get to be manager in the first place. | |
| 233 | +Taking the blame is also why you get to be manager in the first place. | |
| 224 | 234 | It's part of what makes people trust you, and allow you the potential |
| 225 | 235 | glory, because you're the one who gets to say "I screwed up". And if |
| 226 | 236 | you've followed the previous rules, you'll be pretty good at saying that |
| 227 | −by now. | |
| 237 | +by now. | |
| 228 | 238 | |
| 229 | 239 | |
| 230 | − Chapter 5: Things to avoid | |
| 240 | +5) Things to avoid | |
| 241 | +------------------ | |
| 231 | 242 | |
| 232 | 243 | There's one thing people hate even more than being called "d*ckhead", |
| 233 | 244 | and that is being called a "d*ckhead" in a sanctimonious voice. The |
| 234 | 245 | first you can apologize for, the second one you won't really get the |
| 235 | 246 | chance. They likely will no longer be listening even if you otherwise |
| 236 | −do a good job. | |
| 247 | +do a good job. | |
| 237 | 248 | |
| 238 | 249 | We all think we're better than anybody else, which means that when |
| 239 | −somebody else puts on airs, it _really_ rubs us the wrong way. You may | |
| 250 | +somebody else puts on airs, it **really** rubs us the wrong way. You may | |
| 240 | 251 | be morally and intellectually superior to everybody around you, but |
| 241 | −don't try to make it too obvious unless you really _intend_ to irritate | |
| 242 | −somebody (*). | |
| 252 | +don't try to make it too obvious unless you really **intend** to irritate | |
| 253 | +somebody [#f3]_. | |
| 243 | 254 | |
| 244 | 255 | Similarly, don't be too polite or subtle about things. Politeness easily |
| 245 | 256 | ends up going overboard and hiding the problem, and as they say, "On the |
| @@ -251,15 +262,16 @@ Some humor can help pad both the bluntness and the moralizing. Going · 5 unmodified lines | ||
| 251 | 262 | overboard to the point of being ridiculous can drive a point home |
| 252 | 263 | without making it painful to the recipient, who just thinks you're being |
| 253 | 264 | silly. It can thus help get through the personal mental block we all |
| 254 | −have about criticism. | |
| 265 | +have about criticism. | |
| 255 | 266 | |
| 256 | −(*) Hint: internet newsgroups that are not directly related to your work | |
| 257 | −are great ways to take out your frustrations at other people. Write | |
| 258 | −insulting posts with a sneer just to get into a good flame every once in | |
| 259 | −a while, and you'll feel cleansed. Just don't crap too close to home. | |
| 267 | +.. [#f3] Hint: internet newsgroups that are not directly related to your work | |
| 268 | + are great ways to take out your frustrations at other people. Write | |
| 269 | + insulting posts with a sneer just to get into a good flame every once in | |
| 270 | + a while, and you'll feel cleansed. Just don't crap too close to home. | |
| 260 | 271 | |
| 261 | 272 | |
| 262 | − Chapter 6: Why me? | |
| 273 | +6) Why me? | |
| 274 | +---------- | |
| 263 | 275 | |
| 264 | 276 | Since your main responsibility seems to be to take the blame for other |
| 265 | 277 | peoples mistakes, and make it painfully obvious to everybody else that |
| @@ -268,9 +280,9 @@ first place? · 2 unmodified lines | ||
| 268 | 280 | |
| 269 | 281 | First off, while you may or may not get screaming teenage girls (or |
| 270 | 282 | boys, let's not be judgmental or sexist here) knocking on your dressing |
| 271 | −room door, you _will_ get an immense feeling of personal accomplishment | |
| 283 | +room door, you **will** get an immense feeling of personal accomplishment | |
| 272 | 284 | for being "in charge". Never mind the fact that you're really leading |
| 273 | 285 | by trying to keep up with everybody else and running after them as fast |
| 274 | −as you can. Everybody will still think you're the person in charge. | |
| 286 | +as you can. Everybody will still think you're the person in charge. | |
| 275 | 287 | |
| 276 | 288 | It's a great job if you can hack it. |
| @@ -49,25 +49,17 @@ depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and · 48 unmodified lines | ||
| 49 | 49 | CONFIG_PCIEAER = y. |
| 50 | 50 | |
| 51 | 51 | 2.2 Load PCI Express AER Root Driver |
| 52 | −There is a case where a system has AER support in BIOS. Enabling the AER | |
| 53 | −Root driver and having AER support in BIOS may result unpredictable | |
| 54 | −behavior. To avoid this conflict, a successful load of the AER Root driver | |
| 55 | −requires ACPI _OSC support in the BIOS to allow the AER Root driver to | |
| 56 | −request for native control of AER. See the PCI FW 3.0 Specification for | |
| 57 | −details regarding OSC usage. Currently, lots of firmwares don't provide | |
| 58 | −_OSC support while they use PCI Express. To support such firmwares, | |
| 59 | −forceload, a parameter of type bool, could enable AER to continue to | |
| 60 | −be initiated although firmwares have no _OSC support. To enable the | |
| 61 | −walkaround, pls. add aerdriver.forceload=y to kernel boot parameter line | |
| 62 | −when booting kernel. Note that forceload=n by default. | |
| 63 | − | |
| 64 | −nosourceid, another parameter of type bool, can be used when broken | |
| 65 | −hardware (mostly chipsets) has root ports that cannot obtain the reporting | |
| 66 | −source ID. nosourceid=n by default. | |
| 52 | + | |
| 53 | +Some systems have AER support in firmware. Enabling Linux AER support at | |
| 54 | +the same time the firmware handles AER may result in unpredictable | |
| 55 | +behavior. Therefore, Linux does not handle AER events unless the firmware | |
| 56 | +grants AER control to the OS via the ACPI _OSC method. See the PCI FW 3.0 | |
| 57 | +Specification for details regarding _OSC usage. | |
| 67 | 58 | |
| 68 | 59 | 2.3 AER error output |
| 69 | −When a PCI-E AER error is captured, an error message will be outputted to | |
| 70 | −console. If it's a correctable error, it is outputted as a warning. | |
| 60 | + | |
| 61 | +When a PCIe AER error is captured, an error message will be output to | |
| 62 | +console. If it's a correctable error, it is output as a warning. | |
| 71 | 63 | Otherwise, it is printed as an error. So users could choose different |
| 72 | 64 | log level to filter out correctable error messages. |
| 73 | 65 | |
| @@ -2493,6 +2493,28 @@ or some future “lazy” · 2492 unmodified lines | ||
| 2493 | 2493 | variant of <tt>call_rcu()</tt> that might one day be created for |
| 2494 | 2494 | energy-efficiency purposes. |
| 2495 | 2495 | |
| 2496 | +<p> | |
| 2497 | +That said, there are limits. | |
| 2498 | +RCU requires that the <tt>rcu_head</tt> structure be aligned to a | |
| 2499 | +two-byte boundary, and passing a misaligned <tt>rcu_head</tt> | |
| 2500 | +structure to one of the <tt>call_rcu()</tt> family of functions | |
| 2501 | +will result in a splat. | |
| 2502 | +It is therefore necessary to exercise caution when packing | |
| 2503 | +structures containing fields of type <tt>rcu_head</tt>. | |
| 2504 | +Why not a four-byte or even eight-byte alignment requirement? | |
| 2505 | +Because the m68k architecture provides only two-byte alignment, | |
| 2506 | +and thus acts as alignment's least common denominator. | |
| 2507 | + | |
| 2508 | +<p> | |
| 2509 | +The reason for reserving the bottom bit of pointers to | |
| 2510 | +<tt>rcu_head</tt> structures is to leave the door open to | |
| 2511 | +“lazy” callbacks whose invocations can safely be deferred. | |
| 2512 | +Deferring invocation could potentially have energy-efficiency | |
| 2513 | +benefits, but only if the rate of non-lazy callbacks decreases | |
| 2514 | +significantly for some important workload. | |
| 2515 | +In the meantime, reserving the bottom bit keeps this option open | |
| 2516 | +in case it one day becomes useful. | |
| 2517 | + | |
| 2496 | 2518 | <h3><a name="Performance, Scalability, Response Time, and Reliability"> |
| 2497 | 2519 | Performance, Scalability, Response Time, and Reliability</a></h3> |
| 2498 | 2520 | |
| @@ -57,7 +57,7 @@ Call Trace: · 56 unmodified lines | ||
| 57 | 57 | [<ffffffff817db154>] kernel_thread_helper+0x4/0x10 |
| 58 | 58 | [<ffffffff81066430>] ? finish_task_switch+0x80/0x110 |
| 59 | 59 | [<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe |
| 60 | − [<ffffffff81097510>] ? __init_kthread_worker+0x70/0x70 | |
| 60 | + [<ffffffff81097510>] ? __kthread_init_worker+0x70/0x70 | |
| 61 | 61 | [<ffffffff817db150>] ? gs_change+0xb/0xb |
| 62 | 62 | |
| 63 | 63 | Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows: |
| @@ -10,21 +10,6 @@ status messages via printk(), which can be examined via the dmesg · 9 unmodified lines | ||
| 10 | 10 | command (perhaps grepping for "torture"). The test is started |
| 11 | 11 | when the module is loaded, and stops when the module is unloaded. |
| 12 | 12 | |
| 13 | −CONFIG_RCU_TORTURE_TEST_RUNNABLE | |
| 14 | − | |
| 15 | −It is also possible to specify CONFIG_RCU_TORTURE_TEST=y, which will | |
| 16 | −result in the tests being loaded into the base kernel. In this case, | |
| 17 | −the CONFIG_RCU_TORTURE_TEST_RUNNABLE config option is used to specify | |
| 18 | −whether the RCU torture tests are to be started immediately during | |
| 19 | −boot or whether the /proc/sys/kernel/rcutorture_runnable file is used | |
| 20 | −to enable them. This /proc file can be used to repeatedly pause and | |
| 21 | −restart the tests, regardless of the initial state specified by the | |
| 22 | −CONFIG_RCU_TORTURE_TEST_RUNNABLE config option. | |
| 23 | − | |
| 24 | −You will normally -not- want to start the RCU torture tests during boot | |
| 25 | −(and thus the default is CONFIG_RCU_TORTURE_TEST_RUNNABLE=n), but doing | |
| 26 | −this can sometimes be useful in finding boot-time bugs. | |
| 27 | − | |
| 28 | 13 | |
| 29 | 14 | MODULE PARAMETERS |
| 30 | 15 | |
| @@ -1,9 +1,15 @@ | ||
| 1 | +.. _securitybugs: | |
| 2 | + | |
| 3 | +Security bugs | |
| 4 | +============= | |
| 5 | + | |
| 1 | 6 | Linux kernel developers take security very seriously. As such, we'd |
| 2 | 7 | like to know when a security bug is found so that it can be fixed and |
| 3 | 8 | disclosed as quickly as possible. Please report security bugs to the |
| 4 | 9 | Linux kernel security team. |
| 5 | 10 | |
| 6 | 11 | 1) Contact |
| 12 | +---------- | |
| 7 | 13 | |
| 8 | 14 | The Linux kernel security team can be contacted by email at |
| 9 | 15 | <security@kernel.org>. This is a private list of security officers |
| @@ -18,6 +24,7 @@ Any exploit code is very helpful and will not be released without · 8 unmodified lines | ||
| 18 | 24 | consent from the reporter unless it has already been made public. |
| 19 | 25 | |
| 20 | 26 | 2) Disclosure |
| 27 | +------------- | |
| 21 | 28 | |
| 22 | 29 | The goal of the Linux kernel security team is to work with the |
| 23 | 30 | bug submitter to bug resolution as well as disclosure. We prefer |
| @@ -33,6 +40,7 @@ to a few weeks. As a basic default policy, we expect report date to · 9 unmodified lines | ||
| 33 | 40 | disclosure date to be on the order of 7 days. |
| 34 | 41 | |
| 35 | 42 | 3) Non-disclosure agreements |
| 43 | +---------------------------- | |
| 36 | 44 | |
| 37 | 45 | The Linux kernel security team is not a formal body and therefore unable |
| 38 | 46 | to enter any non-disclosure agreements. |
| @@ -1,109 +1,120 @@ | ||
| 1 | +.. _submitchecklist: | |
| 2 | + | |
| 1 | 3 | Linux Kernel patch submission checklist |
| 2 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 4 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 3 | 5 | |
| 4 | 6 | Here are some basic things that developers should do if they want to see their |
| 5 | 7 | kernel patch submissions accepted more quickly. |
| 6 | 8 | |
| 7 | 9 | These are all above and beyond the documentation that is provided in |
| 8 | −Documentation/SubmittingPatches and elsewhere regarding submitting Linux | |
| 9 | −kernel patches. | |
| 10 | +:ref:`Documentation/SubmittingPatches <submittingpatches>` | |
| 11 | +and elsewhere regarding submitting Linux kernel patches. | |
| 10 | 12 | |
| 11 | 13 | |
| 12 | −1: If you use a facility then #include the file that defines/declares | |
| 14 | +1) If you use a facility then #include the file that defines/declares | |
| 13 | 15 | that facility. Don't depend on other header files pulling in ones |
| 14 | 16 | that you use. |
| 15 | 17 | |
| 16 | −2: Builds cleanly with applicable or modified CONFIG options =y, =m, and | |
| 17 | − =n. No gcc warnings/errors, no linker warnings/errors. | |
| 18 | +2) Builds cleanly: | |
| 19 | + | |
| 20 | + a) with applicable or modified ``CONFIG`` options ``=y``, ``=m``, and | |
| 21 | + ``=n``. No ``gcc`` warnings/errors, no linker warnings/errors. | |
| 18 | 22 | |
| 19 | −2b: Passes allnoconfig, allmodconfig | |
| 23 | + b) Passes ``allnoconfig``, ``allmodconfig`` | |
| 20 | 24 | |
| 21 | −2c: Builds successfully when using O=builddir | |
| 25 | + c) Builds successfully when using ``O=builddir`` | |
| 22 | 26 | |
| 23 | −3: Builds on multiple CPU architectures by using local cross-compile tools | |
| 27 | +3) Builds on multiple CPU architectures by using local cross-compile tools | |
| 24 | 28 | or some other build farm. |
| 25 | 29 | |
| 26 | −4: ppc64 is a good architecture for cross-compilation checking because it | |
| 27 | − tends to use `unsigned long' for 64-bit quantities. | |
| 30 | +4) ppc64 is a good architecture for cross-compilation checking because it | |
| 31 | + tends to use ``unsigned long`` for 64-bit quantities. | |
| 28 | 32 | |
| 29 | −5: Check your patch for general style as detailed in | |
| 30 | − Documentation/CodingStyle. Check for trivial violations with the | |
| 31 | − patch style checker prior to submission (scripts/checkpatch.pl). | |
| 33 | +5) Check your patch for general style as detailed in | |
| 34 | + :ref:`Documentation/CodingStyle <codingstyle>`. | |
| 35 | + Check for trivial violations with the patch style checker prior to | |
| 36 | + submission (``scripts/checkpatch.pl``). | |
| 32 | 37 | You should be able to justify all violations that remain in |
| 33 | 38 | your patch. |
| 34 | 39 | |
| 35 | −6: Any new or modified CONFIG options don't muck up the config menu. | |
| 40 | +6) Any new or modified ``CONFIG`` options don't muck up the config menu. | |
| 36 | 41 | |
| 37 | −7: All new Kconfig options have help text. | |
| 42 | +7) All new ``Kconfig`` options have help text. | |
| 38 | 43 | |
| 39 | −8: Has been carefully reviewed with respect to relevant Kconfig | |
| 44 | +8) Has been carefully reviewed with respect to relevant ``Kconfig`` | |
| 40 | 45 | combinations. This is very hard to get right with testing -- brainpower |
| 41 | 46 | pays off here. |
| 42 | 47 | |
| 43 | −9: Check cleanly with sparse. | |
| 48 | +9) Check cleanly with sparse. | |
| 49 | + | |
| 50 | +10) Use ``make checkstack`` and ``make namespacecheck`` and fix any problems | |
| 51 | + that they find. | |
| 52 | + | |
| 53 | + .. note:: | |
| 44 | 54 | |
| 45 | −10: Use 'make checkstack' and 'make namespacecheck' and fix any problems | |
| 46 | − that they find. Note: checkstack does not point out problems explicitly, | |
| 47 | − but any one function that uses more than 512 bytes on the stack is a | |
| 48 | − candidate for change. | |
| 55 | + ``checkstack`` does not point out problems explicitly, | |
| 56 | + but any one function that uses more than 512 bytes on the stack is a | |
| 57 | + candidate for change. | |
| 49 | 58 | |
| 50 | −11: Include kernel-doc to document global kernel APIs. (Not required for | |
| 51 | − static functions, but OK there also.) Use 'make htmldocs' or 'make | |
| 52 | − mandocs' to check the kernel-doc and fix any issues. | |
| 59 | +11) Include :ref:`kernel-doc <kernel_doc>` to document global kernel APIs. | |
| 60 | + (Not required for static functions, but OK there also.) Use | |
| 61 | + ``make htmldocs`` or ``make pdfdocs`` to check the | |
| 62 | + :ref:`kernel-doc <kernel_doc>` and fix any issues. | |
| 53 | 63 | |
| 54 | −12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, | |
| 55 | − CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, | |
| 56 | − CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_PROVE_RCU | |
| 57 | − and CONFIG_DEBUG_OBJECTS_RCU_HEAD all simultaneously enabled. | |
| 64 | +12) Has been tested with ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, | |
| 65 | + ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, | |
| 66 | + ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, | |
| 67 | + ``CONFIG_PROVE_RCU`` and ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` all | |
| 68 | + simultaneously enabled. | |
| 58 | 69 | |
| 59 | −13: Has been build- and runtime tested with and without CONFIG_SMP and | |
| 60 | − CONFIG_PREEMPT. | |
| 70 | +13) Has been build- and runtime tested with and without ``CONFIG_SMP`` and | |
| 71 | + ``CONFIG_PREEMPT.`` | |
| 61 | 72 | |
| 62 | −14: If the patch affects IO/Disk, etc: has been tested with and without | |
| 63 | − CONFIG_LBDAF. | |
| 73 | +14) If the patch affects IO/Disk, etc: has been tested with and without | |
| 74 | + ``CONFIG_LBDAF.`` | |
| 64 | 75 | |
| 65 | −15: All codepaths have been exercised with all lockdep features enabled. | |
| 76 | +15) All codepaths have been exercised with all lockdep features enabled. | |
| 66 | 77 | |
| 67 | −16: All new /proc entries are documented under Documentation/ | |
| 78 | +16) All new ``/proc`` entries are documented under ``Documentation/`` | |
| 68 | 79 | |
| 69 | −17: All new kernel boot parameters are documented in | |
| 70 | − Documentation/kernel-parameters.txt. | |
| 80 | +17) All new kernel boot parameters are documented in | |
| 81 | + ``Documentation/kernel-parameters.txt``. | |
| 71 | 82 | |
| 72 | −18: All new module parameters are documented with MODULE_PARM_DESC() | |
| 83 | +18) All new module parameters are documented with ``MODULE_PARM_DESC()`` | |
| 73 | 84 | |
| 74 | −19: All new userspace interfaces are documented in Documentation/ABI/. | |
| 75 | − See Documentation/ABI/README for more information. | |
| 85 | +19) All new userspace interfaces are documented in ``Documentation/ABI/``. | |
| 86 | + See ``Documentation/ABI/README`` for more information. | |
| 76 | 87 | Patches that change userspace interfaces should be CCed to |
| 77 | 88 | linux-api@vger.kernel.org. |
| 78 | 89 | |
| 79 | −20: Check that it all passes `make headers_check'. | |
| 90 | +20) Check that it all passes ``make headers_check``. | |
| 80 | 91 | |
| 81 | −21: Has been checked with injection of at least slab and page-allocation | |
| 82 | − failures. See Documentation/fault-injection/. | |
| 92 | +21) Has been checked with injection of at least slab and page-allocation | |
| 93 | + failures. See ``Documentation/fault-injection/``. | |
| 83 | 94 | |
| 84 | 95 | If the new code is substantial, addition of subsystem-specific fault |
| 85 | 96 | injection might be appropriate. |
| 86 | 97 | |
| 87 | −22: Newly-added code has been compiled with `gcc -W' (use "make | |
| 88 | − EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for | |
| 89 | − finding bugs like "warning: comparison between signed and unsigned". | |
| 98 | +22) Newly-added code has been compiled with ``gcc -W`` (use | |
| 99 | + ``make EXTRA_CFLAGS=-W``). This will generate lots of noise, but is good | |
| 100 | + for finding bugs like "warning: comparison between signed and unsigned". | |
| 90 | 101 | |
| 91 | −23: Tested after it has been merged into the -mm patchset to make sure | |
| 102 | +23) Tested after it has been merged into the -mm patchset to make sure | |
| 92 | 103 | that it still works with all of the other queued patches and various |
| 93 | 104 | changes in the VM, VFS, and other subsystems. |
| 94 | 105 | |
| 95 | −24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the | |
| 96 | − source code that explains the logic of what they are doing and why. | |
| 106 | +24) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a | |
| 107 | + comment in the source code that explains the logic of what they are doing | |
| 108 | + and why. | |
| 97 | 109 | |
| 98 | −25: If any ioctl's are added by the patch, then also update | |
| 99 | − Documentation/ioctl/ioctl-number.txt. | |
| 110 | +25) If any ioctl's are added by the patch, then also update | |
| 111 | + ``Documentation/ioctl/ioctl-number.txt``. | |
| 100 | 112 | |
| 101 | −26: If your modified source code depends on or uses any of the kernel | |
| 102 | − APIs or features that are related to the following kconfig symbols, | |
| 103 | − then test multiple builds with the related kconfig symbols disabled | |
| 104 | − and/or =m (if that option is available) [not all of these at the | |
| 113 | +26) If your modified source code depends on or uses any of the kernel | |
| 114 | + APIs or features that are related to the following ``Kconfig`` symbols, | |
| 115 | + then test multiple builds with the related ``Kconfig`` symbols disabled | |
| 116 | + and/or ``=m`` (if that option is available) [not all of these at the | |
| 105 | 117 | same time, just various/random combinations of them]: |
| 106 | 118 | |
| 107 | − CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI, | |
| 108 | − CONFIG_BLOCK, CONFIG_PM, CONFIG_MAGIC_SYSRQ, | |
| 109 | − CONFIG_NET, CONFIG_INET=n (but latter with CONFIG_NET=y) | |
| 119 | + ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, | |
| 120 | + ``CONFIG_NET``, ``CONFIG_INET=n`` (but latter with ``CONFIG_NET=y``). | |
| @@ -1,5 +1,7 @@ | ||
| 1 | +.. _submittingdrivers: | |
| 2 | + | |
| 1 | 3 | Submitting Drivers For The Linux Kernel |
| 2 | −--------------------------------------- | |
| 4 | +======================================= | |
| 3 | 5 | |
| 4 | 6 | This document is intended to explain how to submit device drivers to the |
| 5 | 7 | various kernel trees. Note that if you are interested in video card drivers |
| @@ -38,42 +40,48 @@ Linux 2.4: · 32 unmodified lines | ||
| 38 | 40 | maintainer does not respond or you cannot find the appropriate |
| 39 | 41 | maintainer then please contact Willy Tarreau <w@1wt.eu>. |
| 40 | 42 | |
| 41 | −Linux 2.6: | |
| 43 | +Linux 2.6 and upper: | |
| 42 | 44 | The same rules apply as 2.4 except that you should follow linux-kernel |
| 43 | − to track changes in API's. The final contact point for Linux 2.6 | |
| 45 | + to track changes in API's. The final contact point for Linux 2.6+ | |
| 44 | 46 | submissions is Andrew Morton. |
| 45 | 47 | |
| 46 | 48 | What Criteria Determine Acceptance |
| 47 | 49 | ---------------------------------- |
| 48 | 50 | |
| 49 | −Licensing: The code must be released to us under the | |
| 51 | +Licensing: | |
| 52 | + The code must be released to us under the | |
| 50 | 53 | GNU General Public License. We don't insist on any kind |
| 51 | 54 | of exclusive GPL licensing, and if you wish the driver |
| 52 | 55 | to be useful to other communities such as BSD you may well |
| 53 | 56 | wish to release under multiple licenses. |
| 54 | 57 | See accepted licenses at include/linux/module.h |
| 55 | 58 | |
| 56 | −Copyright: The copyright owner must agree to use of GPL. | |
| 59 | +Copyright: | |
| 60 | + The copyright owner must agree to use of GPL. | |
| 57 | 61 | It's best if the submitter and copyright owner |
| 58 | 62 | are the same person/entity. If not, the name of |
| 59 | 63 | the person/entity authorizing use of GPL should be |
| 60 | 64 | listed in case it's necessary to verify the will of |
| 61 | 65 | the copyright owner. |
| 62 | 66 | |
| 63 | −Interfaces: If your driver uses existing interfaces and behaves like | |
| 67 | +Interfaces: | |
| 68 | + If your driver uses existing interfaces and behaves like | |
| 64 | 69 | other drivers in the same class it will be much more likely |
| 65 | 70 | to be accepted than if it invents gratuitous new ones. |
| 66 | 71 | If you need to implement a common API over Linux and NT |
| 67 | 72 | drivers do it in userspace. |
| 68 | 73 | |
| 69 | −Code: Please use the Linux style of code formatting as documented | |
| 70 | − in Documentation/CodingStyle. If you have sections of code | |
| 74 | +Code: | |
| 75 | + Please use the Linux style of code formatting as documented | |
| 76 | + in :ref:`Documentation/CodingStyle <codingStyle>`. | |
| 77 | + If you have sections of code | |
| 71 | 78 | that need to be in other formats, for example because they |
| 72 | 79 | are shared with a windows driver kit and you want to |
| 73 | 80 | maintain them just once separate them out nicely and note |
| 74 | 81 | this fact. |
| 75 | 82 | |
| 76 | −Portability: Pointers are not always 32bits, not all computers are little | |
| 83 | +Portability: | |
| 84 | + Pointers are not always 32bits, not all computers are little | |
| 77 | 85 | endian, people do not all have floating point and you |
| 78 | 86 | shouldn't use inline x86 assembler in your driver without |
| 79 | 87 | careful thought. Pure x86 drivers generally are not popular. |
| @@ -81,12 +89,14 @@ Portability: Pointers are not always 32bits, not all computers are little · 1 unmodified line | ||
| 81 | 89 | but it is easy to make sure the code can easily be made |
| 82 | 90 | portable. |
| 83 | 91 | |
| 84 | −Clarity: It helps if anyone can see how to fix the driver. It helps | |
| 92 | +Clarity: | |
| 93 | + It helps if anyone can see how to fix the driver. It helps | |
| 85 | 94 | you because you get patches not bug reports. If you submit a |
| 86 | 95 | driver that intentionally obfuscates how the hardware works |
| 87 | 96 | it will go in the bitbucket. |
| 88 | 97 | |
| 89 | −PM support: Since Linux is used on many portable and desktop systems, your | |
| 98 | +PM support: | |
| 99 | + Since Linux is used on many portable and desktop systems, your | |
| 90 | 100 | driver is likely to be used on such a system and therefore it |
| 91 | 101 | should support basic power management by implementing, if |
| 92 | 102 | necessary, the .suspend and .resume methods used during the |
| @@ -101,7 +111,8 @@ PM support: Since Linux is used on many portable and desktop systems, your · 8 unmodified lines | ||
| 101 | 111 | complete overview of the power management issues related to |
| 102 | 112 | drivers see Documentation/power/devices.txt . |
| 103 | 113 | |
| 104 | −Control: In general if there is active maintenance of a driver by | |
| 114 | +Control: | |
| 115 | + In general if there is active maintenance of a driver by | |
| 105 | 116 | the author then patches will be redirected to them unless |
| 106 | 117 | they are totally obvious and without need of checking. |
| 107 | 118 | If you want to be the contact and update point for the |
| @@ -111,13 +122,15 @@ Control: In general if there is active maintenance of a driver by · 3 unmodified lines | ||
| 111 | 122 | What Criteria Do Not Determine Acceptance |
| 112 | 123 | ----------------------------------------- |
| 113 | 124 | |
| 114 | −Vendor: Being the hardware vendor and maintaining the driver is | |
| 125 | +Vendor: | |
| 126 | + Being the hardware vendor and maintaining the driver is | |
| 115 | 127 | often a good thing. If there is a stable working driver from |
| 116 | 128 | other people already in the tree don't expect 'we are the |
| 117 | 129 | vendor' to get your driver chosen. Ideally work with the |
| 118 | 130 | existing driver author to build a single perfect driver. |
| 119 | 131 | |
| 120 | −Author: It doesn't matter if a large Linux company wrote the driver, | |
| 132 | +Author: | |
| 133 | + It doesn't matter if a large Linux company wrote the driver, | |
| 121 | 134 | or you did. Nobody has any special access to the kernel |
| 122 | 135 | tree. Anyone who tells you otherwise isn't telling the |
| 123 | 136 | whole story. |
| @@ -127,8 +140,10 @@ Resources · 3 unmodified lines | ||
| 127 | 140 | --------- |
| 128 | 141 | |
| 129 | 142 | Linux kernel master tree: |
| 130 | − ftp.??.kernel.org:/pub/linux/kernel/... | |
| 131 | − ?? == your country code, such as "us", "uk", "fr", etc. | |
| 143 | + ftp.\ *country_code*\ .kernel.org:/pub/linux/kernel/... | |
| 144 | + | |
| 145 | + where *country_code* == your country code, such as | |
| 146 | + **us**, **uk**, **fr**, etc. | |
| 132 | 147 | |
| 133 | 148 | http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git |
| 134 | 149 | |
| @@ -141,14 +156,19 @@ Linux Device Drivers, Third Edition (covers 2.6.10): · 6 unmodified lines | ||
| 141 | 156 | |
| 142 | 157 | LWN.net: |
| 143 | 158 | Weekly summary of kernel development activity - http://lwn.net/ |
| 159 | + | |
| 144 | 160 | 2.6 API changes: |
| 161 | + | |
| 145 | 162 | http://lwn.net/Articles/2.6-kernel-api/ |
| 163 | + | |
| 146 | 164 | Porting drivers from prior kernels to 2.6: |
| 165 | + | |
| 147 | 166 | http://lwn.net/Articles/driver-porting/ |
| 148 | 167 | |
| 149 | 168 | KernelNewbies: |
| 150 | 169 | Documentation and assistance for new kernel programmers |
| 151 | − http://kernelnewbies.org/ | |
| 170 | + | |
| 171 | + http://kernelnewbies.org/ | |
| 152 | 172 | |
| 153 | 173 | Linux USB project: |
| 154 | 174 | http://www.linux-usb.org/ |
| @@ -1,9 +1,7 @@ | ||
| 1 | +.. _submittingpatches: | |
| 1 | 2 | |
| 2 | − How to Get Your Change Into the Linux Kernel | |
| 3 | − or | |
| 4 | − Care And Operation Of Your Linus Torvalds | |
| 5 | − | |
| 6 | − | |
| 3 | +How to Get Your Change Into the Linux Kernel or Care And Operation Of Your Linus Torvalds | |
| 4 | +========================================================================================= | |
| 7 | 5 | |
| 8 | 6 | For a person or company who wishes to submit a change to the Linux |
| 9 | 7 | kernel, the process can sometimes be daunting if you're not familiar |
| @@ -12,57 +10,59 @@ can greatly increase the chances of your change being accepted. · 2 unmodified lines | ||
| 12 | 10 | |
| 13 | 11 | This document contains a large number of suggestions in a relatively terse |
| 14 | 12 | format. For detailed information on how the kernel development process |
| 15 | −works, see Documentation/development-process. Also, read | |
| 16 | −Documentation/SubmitChecklist for a list of items to check before | |
| 13 | +works, see :ref:`Documentation/development-process <development_process_main>`. | |
| 14 | +Also, read :ref:`Documentation/SubmitChecklist <submitchecklist>` | |
| 15 | +for a list of items to check before | |
| 17 | 16 | submitting code. If you are submitting a driver, also read |
| 18 | −Documentation/SubmittingDrivers; for device tree binding patches, read | |
| 17 | +:ref:`Documentation/SubmittingDrivers <submittingdrivers>`; | |
| 18 | +for device tree binding patches, read | |
| 19 | 19 | Documentation/devicetree/bindings/submitting-patches.txt. |
| 20 | 20 | |
| 21 | −Many of these steps describe the default behavior of the git version | |
| 22 | −control system; if you use git to prepare your patches, you'll find much | |
| 21 | +Many of these steps describe the default behavior of the ``git`` version | |
| 22 | +control system; if you use ``git`` to prepare your patches, you'll find much | |
| 23 | 23 | of the mechanical work done for you, though you'll still need to prepare |
| 24 | −and document a sensible set of patches. In general, use of git will make | |
| 24 | +and document a sensible set of patches. In general, use of ``git`` will make | |
| 25 | 25 | your life as a kernel developer easier. |
| 26 | 26 | |
| 27 | −-------------------------------------------- | |
| 28 | −SECTION 1 - CREATING AND SENDING YOUR CHANGE | |
| 29 | −-------------------------------------------- | |
| 27 | +Creating and Sending your Change | |
| 28 | +******************************** | |
| 30 | 29 | |
| 31 | 30 | |
| 32 | 31 | 0) Obtain a current source tree |
| 33 | 32 | ------------------------------- |
| 34 | 33 | |
| 35 | 34 | If you do not have a repository with the current kernel source handy, use |
| 36 | −git to obtain one. You'll want to start with the mainline repository, | |
| 37 | −which can be grabbed with: | |
| 35 | +``git`` to obtain one. You'll want to start with the mainline repository, | |
| 36 | +which can be grabbed with:: | |
| 38 | 37 | |
| 39 | − git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git | |
| 38 | + git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git | |
| 40 | 39 | |
| 41 | 40 | Note, however, that you may not want to develop against the mainline tree |
| 42 | 41 | directly. Most subsystem maintainers run their own trees and want to see |
| 43 | −patches prepared against those trees. See the "T:" entry for the subsystem | |
| 42 | +patches prepared against those trees. See the **T:** entry for the subsystem | |
| 44 | 43 | in the MAINTAINERS file to find that tree, or simply ask the maintainer if |
| 45 | 44 | the tree is not listed there. |
| 46 | 45 | |
| 47 | 46 | It is still possible to download kernel releases via tarballs (as described |
| 48 | 47 | in the next section), but that is the hard way to do kernel development. |
| 49 | 48 | |
| 50 | −1) "diff -up" | |
| 51 | −------------ | |
| 49 | +1) ``diff -up`` | |
| 50 | +--------------- | |
| 52 | 51 | |
| 53 | −If you must generate your patches by hand, use "diff -up" or "diff -uprN" | |
| 52 | +If you must generate your patches by hand, use ``diff -up`` or ``diff -uprN`` | |
| 54 | 53 | to create patches. Git generates patches in this form by default; if |
| 55 | −you're using git, you can skip this section entirely. | |
| 54 | +you're using ``git``, you can skip this section entirely. | |
| 56 | 55 | |
| 57 | 56 | All changes to the Linux kernel occur in the form of patches, as |
| 58 | −generated by diff(1). When creating your patch, make sure to create it | |
| 59 | −in "unified diff" format, as supplied by the '-u' argument to diff(1). | |
| 60 | −Also, please use the '-p' argument which shows which C function each | |
| 61 | −change is in - that makes the resultant diff a lot easier to read. | |
| 57 | +generated by :manpage:`diff(1)`. When creating your patch, make sure to | |
| 58 | +create it in "unified diff" format, as supplied by the ``-u`` argument | |
| 59 | +to :manpage:`diff(1)`. | |
| 60 | +Also, please use the ``-p`` argument which shows which C function each | |
| 61 | +change is in - that makes the resultant ``diff`` a lot easier to read. | |
| 62 | 62 | Patches should be based in the root kernel source directory, |
| 63 | 63 | not in any lower subdirectory. |
| 64 | 64 | |
| 65 | −To create a patch for a single file, it is often sufficient to do: | |
| 65 | +To create a patch for a single file, it is often sufficient to do:: | |
| 66 | 66 | |
| 67 | 67 | SRCTREE= linux |
| 68 | 68 | MYFILE= drivers/net/mydriver.c |
| @@ -74,8 +74,8 @@ To create a patch for a single file, it is often sufficient to do: · 5 unmodified lines | ||
| 74 | 74 | diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch |
| 75 | 75 | |
| 76 | 76 | To create a patch for multiple files, you should unpack a "vanilla", |
| 77 | −or unmodified kernel source tree, and generate a diff against your | |
| 78 | −own source tree. For example: | |
| 77 | +or unmodified kernel source tree, and generate a ``diff`` against your | |
| 78 | +own source tree. For example:: | |
| 79 | 79 | |
| 80 | 80 | MYSRC= /devel/linux |
| 81 | 81 | |
| @@ -84,27 +84,27 @@ own source tree. For example: · 2 unmodified lines | ||
| 84 | 84 | diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \ |
| 85 | 85 | linux-3.19-vanilla $MYSRC > /tmp/patch |
| 86 | 86 | |
| 87 | −"dontdiff" is a list of files which are generated by the kernel during | |
| 88 | −the build process, and should be ignored in any diff(1)-generated | |
| 87 | +``dontdiff`` is a list of files which are generated by the kernel during | |
| 88 | +the build process, and should be ignored in any :manpage:`diff(1)`-generated | |
| 89 | 89 | patch. |
| 90 | 90 | |
| 91 | 91 | Make sure your patch does not include any extra files which do not |
| 92 | 92 | belong in a patch submission. Make sure to review your patch -after- |
| 93 | −generating it with diff(1), to ensure accuracy. | |
| 93 | +generating it with :manpage:`diff(1)`, to ensure accuracy. | |
| 94 | 94 | |
| 95 | 95 | If your changes produce a lot of deltas, you need to split them into |
| 96 | −individual patches which modify things in logical stages; see section | |
| 97 | −#3. This will facilitate review by other kernel developers, | |
| 96 | +individual patches which modify things in logical stages; see | |
| 97 | +:ref:`split_changes`. This will facilitate review by other kernel developers, | |
| 98 | 98 | very important if you want your patch accepted. |
| 99 | 99 | |
| 100 | −If you're using git, "git rebase -i" can help you with this process. If | |
| 101 | −you're not using git, quilt <http://savannah.nongnu.org/projects/quilt> | |
| 100 | +If you're using ``git``, ``git rebase -i`` can help you with this process. If | |
| 101 | +you're not using ``git``, ``quilt`` <http://savannah.nongnu.org/projects/quilt> | |
| 102 | 102 | is another popular alternative. |
| 103 | 103 | |
| 104 | +.. _describe_changes: | |
| 104 | 105 | |
| 105 | − | |
| 106 | −2) Describe your changes. | |
| 107 | −------------------------- | |
| 106 | +2) Describe your changes | |
| 107 | +------------------------ | |
| 108 | 108 | |
| 109 | 109 | Describe your problem. Whether your patch is a one-line bug fix or |
| 110 | 110 | 5000 lines of a new feature, there must be an underlying problem that |
| @@ -137,11 +137,11 @@ as you intend it to. · 26 unmodified lines | ||
| 137 | 137 | |
| 138 | 138 | The maintainer will thank you if you write your patch description in a |
| 139 | 139 | form which can be easily pulled into Linux's source code management |
| 140 | −system, git, as a "commit log". See #15, below. | |
| 140 | +system, ``git``, as a "commit log". See :ref:`explicit_in_reply_to`. | |
| 141 | 141 | |
| 142 | 142 | Solve only one problem per patch. If your description starts to get |
| 143 | 143 | long, that's a sign that you probably need to split up your patch. |
| 144 | −See #3, next. | |
| 144 | +See :ref:`split_changes`. | |
| 145 | 145 | |
| 146 | 146 | When you submit or resubmit a patch or patch series, include the |
| 147 | 147 | complete patch description and justification for it. Don't just |
| @@ -160,7 +160,7 @@ its behaviour. · 12 unmodified lines | ||
| 160 | 160 | If the patch fixes a logged bug entry, refer to that bug entry by |
| 161 | 161 | number and URL. If the patch follows from a mailing list discussion, |
| 162 | 162 | give a URL to the mailing list archive; use the https://lkml.kernel.org/ |
| 163 | −redirector with a Message-Id, to ensure that the links cannot become | |
| 163 | +redirector with a ``Message-Id``, to ensure that the links cannot become | |
| 164 | 164 | stale. |
| 165 | 165 | |
| 166 | 166 | However, try to make your explanation understandable without external |
| @@ -171,7 +171,7 @@ patch as submitted. · 4 unmodified lines | ||
| 171 | 171 | If you want to refer to a specific commit, don't just refer to the |
| 172 | 172 | SHA-1 ID of the commit. Please also include the oneline summary of |
| 173 | 173 | the commit, to make it easier for reviewers to know what it is about. |
| 174 | −Example: | |
| 174 | +Example:: | |
| 175 | 175 | |
| 176 | 176 | Commit e21d2170f36602ae2708 ("video: remove unnecessary |
| 177 | 177 | platform_set_drvdata()") removed the unnecessary |
| @@ -185,23 +185,25 @@ there is no collision with your six-character ID now, that condition may · 7 unmodified lines | ||
| 185 | 185 | change five years from now. |
| 186 | 186 | |
| 187 | 187 | If your patch fixes a bug in a specific commit, e.g. you found an issue using |
| 188 | −git-bisect, please use the 'Fixes:' tag with the first 12 characters of the | |
| 189 | −SHA-1 ID, and the one line summary. For example: | |
| 188 | +``git bisect``, please use the 'Fixes:' tag with the first 12 characters of | |
| 189 | +the SHA-1 ID, and the one line summary. For example:: | |
| 190 | 190 | |
| 191 | 191 | Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()") |
| 192 | 192 | |
| 193 | −The following git-config settings can be used to add a pretty format for | |
| 194 | −outputting the above style in the git log or git show commands | |
| 193 | +The following ``git config`` settings can be used to add a pretty format for | |
| 194 | +outputting the above style in the ``git log`` or ``git show`` commands:: | |
| 195 | 195 | |
| 196 | 196 | [core] |
| 197 | 197 | abbrev = 12 |
| 198 | 198 | [pretty] |
| 199 | 199 | fixes = Fixes: %h (\"%s\") |
| 200 | 200 | |
| 201 | −3) Separate your changes. | |
| 202 | −------------------------- | |
| 201 | +.. _split_changes: | |
| 202 | + | |
| 203 | +3) Separate your changes | |
| 204 | +------------------------ | |
| 203 | 205 | |
| 204 | −Separate each _logical change_ into a separate patch. | |
| 206 | +Separate each **logical change** into a separate patch. | |
| 205 | 207 | |
| 206 | 208 | For example, if your changes include both bug fixes and performance |
| 207 | 209 | enhancements for a single driver, separate those changes into two |
| @@ -217,12 +219,12 @@ change that can be verified by reviewers. Each patch should be justifiable · 9 unmodified lines | ||
| 217 | 219 | on its own merits. |
| 218 | 220 | |
| 219 | 221 | If one patch depends on another patch in order for a change to be |
| 220 | −complete, that is OK. Simply note "this patch depends on patch X" | |
| 222 | +complete, that is OK. Simply note **"this patch depends on patch X"** | |
| 221 | 223 | in your patch description. |
| 222 | 224 | |
| 223 | 225 | When dividing your change into a series of patches, take special care to |
| 224 | 226 | ensure that the kernel builds and runs properly after each patch in the |
| 225 | −series. Developers using "git bisect" to track down a problem can end up | |
| 227 | +series. Developers using ``git bisect`` to track down a problem can end up | |
| 226 | 228 | splitting your patch series at any point; they will not thank you if you |
| 227 | 229 | introduce bugs in the middle. |
| 228 | 230 | |
| @@ -231,11 +233,13 @@ then only post say 15 or so at a time and wait for review and integration. · 2 unmodified lines | ||
| 231 | 233 | |
| 232 | 234 | |
| 233 | 235 | |
| 234 | −4) Style-check your changes. | |
| 235 | −---------------------------- | |
| 236 | +4) Style-check your changes | |
| 237 | +--------------------------- | |
| 236 | 238 | |
| 237 | 239 | Check your patch for basic style violations, details of which can be |
| 238 | −found in Documentation/CodingStyle. Failure to do so simply wastes | |
| 240 | +found in | |
| 241 | +:ref:`Documentation/CodingStyle <codingstyle>`. | |
| 242 | +Failure to do so simply wastes | |
| 239 | 243 | the reviewers time and will get your patch rejected, probably |
| 240 | 244 | without even being read. |
| 241 | 245 | |
| @@ -260,8 +264,8 @@ You should be able to justify all violations that remain in your · 18 unmodified lines | ||
| 260 | 264 | patch. |
| 261 | 265 | |
| 262 | 266 | |
| 263 | −5) Select the recipients for your patch. | |
| 264 | −---------------------------------------- | |
| 267 | +5) Select the recipients for your patch | |
| 268 | +--------------------------------------- | |
| 265 | 269 | |
| 266 | 270 | You should always copy the appropriate subsystem maintainer(s) on any patch |
| 267 | 271 | to code that they maintain; look through the MAINTAINERS file and the |
| @@ -295,13 +299,14 @@ to allow distributors to get the patch out to users; in such cases, · 27 unmodified lines | ||
| 295 | 299 | obviously, the patch should not be sent to any public lists. |
| 296 | 300 | |
| 297 | 301 | Patches that fix a severe bug in a released kernel should be directed |
| 298 | −toward the stable maintainers by putting a line like this: | |
| 302 | +toward the stable maintainers by putting a line like this:: | |
| 299 | 303 | |
| 300 | 304 | Cc: stable@vger.kernel.org |
| 301 | 305 | |
| 302 | 306 | into the sign-off area of your patch (note, NOT an email recipient). You |
| 303 | −should also read Documentation/stable_kernel_rules.txt in addition to this | |
| 304 | −file. | |
| 307 | +should also read | |
| 308 | +:ref:`Documentation/stable_kernel_rules.txt <stable_kernel_rules>` | |
| 309 | +in addition to this file. | |
| 305 | 310 | |
| 306 | 311 | Note, however, that some subsystem maintainers want to come to their own |
| 307 | 312 | conclusions on which patches should go to the stable trees. The networking |
| @@ -312,28 +317,30 @@ If changes affect userland-kernel interfaces, please send the MAN-PAGES · 4 unmodified lines | ||
| 312 | 317 | maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at |
| 313 | 318 | least a notification of the change, so that some information makes its way |
| 314 | 319 | into the manual pages. User-space API changes should also be copied to |
| 315 | −linux-api@vger.kernel.org. | |
| 320 | +linux-api@vger.kernel.org. | |
| 316 | 321 | |
| 317 | 322 | For small patches you may want to CC the Trivial Patch Monkey |
| 318 | 323 | trivial@kernel.org which collects "trivial" patches. Have a look |
| 319 | 324 | into the MAINTAINERS file for its current manager. |
| 325 | + | |
| 320 | 326 | Trivial patches must qualify for one of the following rules: |
| 321 | − Spelling fixes in documentation | |
| 322 | − Spelling fixes for errors which could break grep(1) | |
| 323 | − Warning fixes (cluttering with useless warnings is bad) | |
| 324 | − Compilation fixes (only if they are actually correct) | |
| 325 | − Runtime fixes (only if they actually fix things) | |
| 326 | − Removing use of deprecated functions/macros | |
| 327 | − Contact detail and documentation fixes | |
| 328 | − Non-portable code replaced by portable code (even in arch-specific, | |
| 329 | − since people copy, as long as it's trivial) | |
| 330 | − Any fix by the author/maintainer of the file (ie. patch monkey | |
| 331 | − in re-transmission mode) | |
| 327 | + | |
| 328 | +- Spelling fixes in documentation | |
| 329 | +- Spelling fixes for errors which could break :manpage:`grep(1)` | |
| 330 | +- Warning fixes (cluttering with useless warnings is bad) | |
| 331 | +- Compilation fixes (only if they are actually correct) | |
| 332 | +- Runtime fixes (only if they actually fix things) | |
| 333 | +- Removing use of deprecated functions/macros | |
| 334 | +- Contact detail and documentation fixes | |
| 335 | +- Non-portable code replaced by portable code (even in arch-specific, | |
| 336 | + since people copy, as long as it's trivial) | |
| 337 | +- Any fix by the author/maintainer of the file (ie. patch monkey | |
| 338 | + in re-transmission mode) | |
| 332 | 339 | |
| 333 | 340 | |
| 334 | 341 | |
| 335 | −6) No MIME, no links, no compression, no attachments. Just plain text. | |
| 336 | −----------------------------------------------------------------------- | |
| 342 | +6) No MIME, no links, no compression, no attachments. Just plain text | |
| 343 | +---------------------------------------------------------------------- | |
| 337 | 344 | |
| 338 | 345 | Linus and other kernel developers need to be able to read and comment |
| 339 | 346 | on the changes you are submitting. It is important for a kernel |
| @@ -341,8 +348,11 @@ developer to be able to "quote" your changes, using standard e-mail · 1 unmodified line | ||
| 341 | 348 | tools, so that they may comment on specific portions of your code. |
| 342 | 349 | |
| 343 | 350 | For this reason, all patches should be submitted by e-mail "inline". |
| 344 | −WARNING: Be wary of your editor's word-wrap corrupting your patch, | |
| 345 | −if you choose to cut-n-paste your patch. | |
| 351 | + | |
| 352 | +.. warning:: | |
| 353 | + | |
| 354 | + Be wary of your editor's word-wrap corrupting your patch, | |
| 355 | + if you choose to cut-n-paste your patch. | |
| 346 | 356 | |
| 347 | 357 | Do not attach the patch as a MIME attachment, compressed or not. |
| 348 | 358 | Many popular e-mail applications will not always transmit a MIME |
| @@ -353,11 +363,12 @@ decreasing the likelihood of your MIME-attached change being accepted. · 4 unmodified lines | ||
| 353 | 363 | Exception: If your mailer is mangling patches then someone may ask |
| 354 | 364 | you to re-send them using MIME. |
| 355 | 365 | |
| 356 | −See Documentation/email-clients.txt for hints about configuring | |
| 357 | −your e-mail client so that it sends your patches untouched. | |
| 366 | +See :ref:`Documentation/email-clients.txt <email_clients>` | |
| 367 | +for hints about configuring your e-mail client so that it sends your patches | |
| 368 | +untouched. | |
| 358 | 369 | |
| 359 | −7) E-mail size. | |
| 360 | −--------------- | |
| 370 | +7) E-mail size | |
| 371 | +-------------- | |
| 361 | 372 | |
| 362 | 373 | Large changes are not appropriate for mailing lists, and some |
| 363 | 374 | maintainers. If your patch, uncompressed, exceeds 300 kB in size, |
| @@ -366,8 +377,8 @@ server, and provide instead a URL (link) pointing to your patch. But note · 2 unmodified lines | ||
| 366 | 377 | that if your patch exceeds 300 kB, it almost certainly needs to be broken up |
| 367 | 378 | anyway. |
| 368 | 379 | |
| 369 | −8) Respond to review comments. | |
| 370 | −------------------------------ | |
| 380 | +8) Respond to review comments | |
| 381 | +----------------------------- | |
| 371 | 382 | |
| 372 | 383 | Your patch will almost certainly get comments from reviewers on ways in |
| 373 | 384 | which the patch can be improved. You must respond to those comments; |
| @@ -382,8 +393,8 @@ reviewers sometimes get grumpy. Even in that case, though, respond · 8 unmodified lines | ||
| 382 | 393 | politely and address the problems they have pointed out. |
| 383 | 394 | |
| 384 | 395 | |
| 385 | −9) Don't get discouraged - or impatient. | |
| 386 | −---------------------------------------- | |
| 396 | +9) Don't get discouraged - or impatient | |
| 397 | +--------------------------------------- | |
| 387 | 398 | |
| 388 | 399 | After you have submitted your change, be patient and wait. Reviewers are |
| 389 | 400 | busy people and may not get to your patch right away. |
| @@ -419,9 +430,10 @@ patch, which certifies that you wrote it or otherwise have the right to · 29 unmodified lines | ||
| 419 | 430 | pass it on as an open-source patch. The rules are pretty simple: if you |
| 420 | 431 | can certify the below: |
| 421 | 432 | |
| 422 | − Developer's Certificate of Origin 1.1 | |
| 433 | +Developer's Certificate of Origin 1.1 | |
| 434 | +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
| 423 | 435 | |
| 424 | − By making a contribution to this project, I certify that: | |
| 436 | +By making a contribution to this project, I certify that: | |
| 425 | 437 | |
| 426 | 438 | (a) The contribution was created in whole or in part by me and I |
| 427 | 439 | have the right to submit it under the open source license |
| @@ -445,7 +457,7 @@ can certify the below: · 17 unmodified lines | ||
| 445 | 457 | maintained indefinitely and may be redistributed consistent with |
| 446 | 458 | this project or the open source license(s) involved. |
| 447 | 459 | |
| 448 | −then you just add a line saying | |
| 460 | +then you just add a line saying:: | |
| 449 | 461 | |
| 450 | 462 | Signed-off-by: Random J Developer <random@developer.example.org> |
| 451 | 463 | |
| @@ -466,7 +478,7 @@ you add a line between the last Signed-off-by header and yours, indicating · 14 unmodified lines | ||
| 466 | 478 | the nature of your changes. While there is nothing mandatory about this, it |
| 467 | 479 | seems like prepending the description with your mail and/or name, all |
| 468 | 480 | enclosed in square brackets, is noticeable enough to make it obvious that |
| 469 | −you are responsible for last-minute changes. Example : | |
| 481 | +you are responsible for last-minute changes. Example:: | |
| 470 | 482 | |
| 471 | 483 | Signed-off-by: Random J Developer <random@developer.example.org> |
| 472 | 484 | [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] |
| @@ -481,15 +493,15 @@ which appears in the changelog. · 8 unmodified lines | ||
| 481 | 493 | Special note to back-porters: It seems to be a common and useful practice |
| 482 | 494 | to insert an indication of the origin of a patch at the top of the commit |
| 483 | 495 | message (just after the subject line) to facilitate tracking. For instance, |
| 484 | −here's what we see in a 3.x-stable release: | |
| 496 | +here's what we see in a 3.x-stable release:: | |
| 485 | 497 | |
| 486 | −Date: Tue Oct 7 07:26:38 2014 -0400 | |
| 498 | + Date: Tue Oct 7 07:26:38 2014 -0400 | |
| 487 | 499 | |
| 488 | 500 | libata: Un-break ATA blacklist |
| 489 | 501 | |
| 490 | 502 | commit 1c40279960bcd7d52dbdf1d466b20d24b99176c8 upstream. |
| 491 | 503 | |
| 492 | −And here's what might appear in an older kernel once a patch is backported: | |
| 504 | +And here's what might appear in an older kernel once a patch is backported:: | |
| 493 | 505 | |
| 494 | 506 | Date: Tue May 13 22:12:27 2008 +0200 |
| 495 | 507 | |
| @@ -529,7 +541,7 @@ When in doubt people should refer to the original discussion in the mailing · 33 unmodified lines | ||
| 529 | 541 | list archives. |
| 530 | 542 | |
| 531 | 543 | If a person has had the opportunity to comment on a patch, but has not |
| 532 | −provided such comments, you may optionally add a "Cc:" tag to the patch. | |
| 544 | +provided such comments, you may optionally add a ``Cc:`` tag to the patch. | |
| 533 | 545 | This is the only tag which might be added without an explicit action by the |
| 534 | 546 | person it names - but it should indicate that this person was copied on the |
| 535 | 547 | patch. This tag documents that potentially interested parties |
| @@ -552,11 +564,12 @@ future patches, and ensures credit for the testers. · 16 unmodified lines | ||
| 552 | 564 | Reviewed-by:, instead, indicates that the patch has been reviewed and found |
| 553 | 565 | acceptable according to the Reviewer's Statement: |
| 554 | 566 | |
| 555 | − Reviewer's statement of oversight | |
| 567 | +Reviewer's statement of oversight | |
| 568 | +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
| 556 | 569 | |
| 557 | − By offering my Reviewed-by: tag, I state that: | |
| 570 | +By offering my Reviewed-by: tag, I state that: | |
| 558 | 571 | |
| 559 | − (a) I have carried out a technical review of this patch to | |
| 572 | + (a) I have carried out a technical review of this patch to | |
| 560 | 573 | evaluate its appropriateness and readiness for inclusion into |
| 561 | 574 | the mainline kernel. |
| 562 | 575 | |
| @@ -594,24 +607,25 @@ A Fixes: tag indicates that the patch fixes an issue in a previous commit. It · 31 unmodified lines | ||
| 594 | 607 | is used to make it easy to determine where a bug originated, which can help |
| 595 | 608 | review a bug fix. This tag also assists the stable kernel team in determining |
| 596 | 609 | which stable kernel versions should receive your fix. This is the preferred |
| 597 | −method for indicating a bug fixed by the patch. See #2 above for more details. | |
| 610 | +method for indicating a bug fixed by the patch. See :ref:`describe_changes` | |
| 611 | +for more details. | |
| 598 | 612 | |
| 599 | 613 | |
| 600 | 614 | 14) The canonical patch format |
| 601 | 615 | ------------------------------ |
| 602 | 616 | |
| 603 | 617 | This section describes how the patch itself should be formatted. Note |
| 604 | −that, if you have your patches stored in a git repository, proper patch | |
| 605 | −formatting can be had with "git format-patch". The tools cannot create | |
| 618 | +that, if you have your patches stored in a ``git`` repository, proper patch | |
| 619 | +formatting can be had with ``git format-patch``. The tools cannot create | |
| 606 | 620 | the necessary text, though, so read the instructions below anyway. |
| 607 | 621 | |
| 608 | −The canonical patch subject line is: | |
| 622 | +The canonical patch subject line is:: | |
| 609 | 623 | |
| 610 | 624 | Subject: [PATCH 001/123] subsystem: summary phrase |
| 611 | 625 | |
| 612 | 626 | The canonical patch message body contains the following: |
| 613 | 627 | |
| 614 | − - A "from" line specifying the patch author (only needed if the person | |
| 628 | + - A ``from`` line specifying the patch author (only needed if the person | |
| 615 | 629 | sending the patch is not the author). |
| 616 | 630 | |
| 617 | 631 | - An empty line. |
| @@ -619,46 +633,46 @@ The canonical patch message body contains the following: · 1 unmodified line | ||
| 619 | 633 | - The body of the explanation, line wrapped at 75 columns, which will |
| 620 | 634 | be copied to the permanent changelog to describe this patch. |
| 621 | 635 | |
| 622 | − - The "Signed-off-by:" lines, described above, which will | |
| 636 | + - The ``Signed-off-by:`` lines, described above, which will | |
| 623 | 637 | also go in the changelog. |
| 624 | 638 | |
| 625 | − - A marker line containing simply "---". | |
| 639 | + - A marker line containing simply ``---``. | |
| 626 | 640 | |
| 627 | 641 | - Any additional comments not suitable for the changelog. |
| 628 | 642 | |
| 629 | − - The actual patch (diff output). | |
| 643 | + - The actual patch (``diff`` output). | |
| 630 | 644 | |
| 631 | 645 | The Subject line format makes it very easy to sort the emails |
| 632 | 646 | alphabetically by subject line - pretty much any email reader will |
| 633 | 647 | support that - since because the sequence number is zero-padded, |
| 634 | 648 | the numerical and alphabetic sort is the same. |
| 635 | 649 | |
| 636 | −The "subsystem" in the email's Subject should identify which | |
| 650 | +The ``subsystem`` in the email's Subject should identify which | |
| 637 | 651 | area or subsystem of the kernel is being patched. |
| 638 | 652 | |
| 639 | −The "summary phrase" in the email's Subject should concisely | |
| 640 | −describe the patch which that email contains. The "summary | |
| 641 | −phrase" should not be a filename. Do not use the same "summary | |
| 642 | −phrase" for every patch in a whole patch series (where a "patch | |
| 643 | −series" is an ordered sequence of multiple, related patches). | |
| 653 | +The ``summary phrase`` in the email's Subject should concisely | |
| 654 | +describe the patch which that email contains. The ``summary | |
| 655 | +phrase`` should not be a filename. Do not use the same ``summary | |
| 656 | +phrase`` for every patch in a whole patch series (where a ``patch | |
| 657 | +series`` is an ordered sequence of multiple, related patches). | |
| 644 | 658 | |
| 645 | −Bear in mind that the "summary phrase" of your email becomes a | |
| 659 | +Bear in mind that the ``summary phrase`` of your email becomes a | |
| 646 | 660 | globally-unique identifier for that patch. It propagates all the way |
| 647 | −into the git changelog. The "summary phrase" may later be used in | |
| 661 | +into the ``git`` changelog. The ``summary phrase`` may later be used in | |
| 648 | 662 | developer discussions which refer to the patch. People will want to |
| 649 | −google for the "summary phrase" to read discussion regarding that | |
| 663 | +google for the ``summary phrase`` to read discussion regarding that | |
| 650 | 664 | patch. It will also be the only thing that people may quickly see |
| 651 | 665 | when, two or three months later, they are going through perhaps |
| 652 | −thousands of patches using tools such as "gitk" or "git log | |
| 653 | −--oneline". | |
| 666 | +thousands of patches using tools such as ``gitk`` or ``git log | |
| 667 | +--oneline``. | |
| 654 | 668 | |
| 655 | −For these reasons, the "summary" must be no more than 70-75 | |
| 669 | +For these reasons, the ``summary`` must be no more than 70-75 | |
| 656 | 670 | characters, and it must describe both what the patch changes, as well |
| 657 | 671 | as why the patch might be necessary. It is challenging to be both |
| 658 | 672 | succinct and descriptive, but that is what a well-written summary |
| 659 | 673 | should do. |
| 660 | 674 | |
| 661 | −The "summary phrase" may be prefixed by tags enclosed in square | |
| 675 | +The ``summary phrase`` may be prefixed by tags enclosed in square | |
| 662 | 676 | brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are |
| 663 | 677 | not considered part of the summary phrase, but describe how the patch |
| 664 | 678 | should be treated. Common tags might include a version descriptor if |
| @@ -670,19 +684,19 @@ that developers understand the order in which the patches should be · 5 unmodified lines | ||
| 670 | 684 | applied and that they have reviewed or applied all of the patches in |
| 671 | 685 | the patch series. |
| 672 | 686 | |
| 673 | −A couple of example Subjects: | |
| 687 | +A couple of example Subjects:: | |
| 674 | 688 | |
| 675 | 689 | Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching |
| 676 | 690 | Subject: [PATCH v2 01/27] x86: fix eflags tracking |
| 677 | 691 | |
| 678 | −The "from" line must be the very first line in the message body, | |
| 692 | +The ``from`` line must be the very first line in the message body, | |
| 679 | 693 | and has the form: |
| 680 | 694 | |
| 681 | 695 | From: Original Author <author@example.com> |
| 682 | 696 | |
| 683 | −The "from" line specifies who will be credited as the author of the | |
| 684 | −patch in the permanent changelog. If the "from" line is missing, | |
| 685 | −then the "From:" line from the email header will be used to determine | |
| 697 | +The ``from`` line specifies who will be credited as the author of the | |
| 698 | +patch in the permanent changelog. If the ``from`` line is missing, | |
| 699 | +then the ``From:`` line from the email header will be used to determine | |
| 686 | 700 | the patch author in the changelog. |
| 687 | 701 | |
| 688 | 702 | The explanation body will be committed to the permanent source |
| @@ -694,35 +708,37 @@ especially useful for people who might be searching the commit logs · 5 unmodified lines | ||
| 694 | 708 | looking for the applicable patch. If a patch fixes a compile failure, |
| 695 | 709 | it may not be necessary to include _all_ of the compile failures; just |
| 696 | 710 | enough that it is likely that someone searching for the patch can find |
| 697 | −it. As in the "summary phrase", it is important to be both succinct as | |
| 711 | +it. As in the ``summary phrase``, it is important to be both succinct as | |
| 698 | 712 | well as descriptive. |
| 699 | 713 | |
| 700 | −The "---" marker line serves the essential purpose of marking for patch | |
| 714 | +The ``---`` marker line serves the essential purpose of marking for patch | |
| 701 | 715 | handling tools where the changelog message ends. |
| 702 | 716 | |
| 703 | −One good use for the additional comments after the "---" marker is for | |
| 704 | −a diffstat, to show what files have changed, and the number of | |
| 705 | −inserted and deleted lines per file. A diffstat is especially useful | |
| 717 | +One good use for the additional comments after the ``---`` marker is for | |
| 718 | +a ``diffstat``, to show what files have changed, and the number of | |
| 719 | +inserted and deleted lines per file. A ``diffstat`` is especially useful | |
| 706 | 720 | on bigger patches. Other comments relevant only to the moment or the |
| 707 | 721 | maintainer, not suitable for the permanent changelog, should also go |
| 708 | −here. A good example of such comments might be "patch changelogs" | |
| 722 | +here. A good example of such comments might be ``patch changelogs`` | |
| 709 | 723 | which describe what has changed between the v1 and v2 version of the |
| 710 | 724 | patch. |
| 711 | 725 | |
| 712 | −If you are going to include a diffstat after the "---" marker, please | |
| 713 | −use diffstat options "-p 1 -w 70" so that filenames are listed from | |
| 726 | +If you are going to include a ``diffstat`` after the ``---`` marker, please | |
| 727 | +use ``diffstat`` options ``-p 1 -w 70`` so that filenames are listed from | |
| 714 | 728 | the top of the kernel source tree and don't use too much horizontal |
| 715 | −space (easily fit in 80 columns, maybe with some indentation). (git | |
| 729 | +space (easily fit in 80 columns, maybe with some indentation). (``git`` | |
| 716 | 730 | generates appropriate diffstats by default.) |
| 717 | 731 | |
| 718 | 732 | See more details on the proper patch format in the following |
| 719 | 733 | references. |
| 720 | 734 | |
| 735 | +.. _explicit_in_reply_to: | |
| 736 | + | |
| 721 | 737 | 15) Explicit In-Reply-To headers |
| 722 | 738 | -------------------------------- |
| 723 | 739 | |
| 724 | 740 | It can be helpful to manually add In-Reply-To: headers to a patch |
| 725 | −(e.g., when using "git send-email") to associate the patch with | |
| 741 | +(e.g., when using ``git send-email``) to associate the patch with | |
| 726 | 742 | previous relevant discussion, e.g. to link a bug fix to the email with |
| 727 | 743 | the bug report. However, for a multi-patch series, it is generally |
| 728 | 744 | best to avoid using In-Reply-To: to link to older versions of the |
| @@ -732,12 +748,12 @@ helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in · 3 unmodified lines | ||
| 732 | 748 | the cover email text) to link to an earlier version of the patch series. |
| 733 | 749 | |
| 734 | 750 | |
| 735 | −16) Sending "git pull" requests | |
| 736 | −------------------------------- | |
| 751 | +16) Sending ``git pull`` requests | |
| 752 | +--------------------------------- | |
| 737 | 753 | |
| 738 | 754 | If you have a series of patches, it may be most convenient to have the |
| 739 | 755 | maintainer pull them directly into the subsystem repository with a |
| 740 | −"git pull" operation. Note, however, that pulling patches from a developer | |
| 756 | +``git pull`` operation. Note, however, that pulling patches from a developer | |
| 741 | 757 | requires a higher degree of trust than taking patches from a mailing list. |
| 742 | 758 | As a result, many subsystem maintainers are reluctant to take pull |
| 743 | 759 | requests, especially from new, unknown developers. If in doubt you can use |
| @@ -746,7 +762,7 @@ series, giving the maintainer the option of using either. · 2 unmodified lines | ||
| 746 | 762 | |
| 747 | 763 | A pull request should have [GIT] or [PULL] in the subject line. The |
| 748 | 764 | request itself should include the repository name and the branch of |
| 749 | −interest on a single line; it should look something like: | |
| 765 | +interest on a single line; it should look something like:: | |
| 750 | 766 | |
| 751 | 767 | Please pull from |
| 752 | 768 | |
| @@ -755,10 +771,10 @@ interest on a single line; it should look something like: · 2 unmodified lines | ||
| 755 | 771 | to get these changes: |
| 756 | 772 | |
| 757 | 773 | A pull request should also include an overall message saying what will be |
| 758 | −included in the request, a "git shortlog" listing of the patches | |
| 759 | −themselves, and a diffstat showing the overall effect of the patch series. | |
| 774 | +included in the request, a ``git shortlog`` listing of the patches | |
| 775 | +themselves, and a ``diffstat`` showing the overall effect of the patch series. | |
| 760 | 776 | The easiest way to get all this information together is, of course, to let |
| 761 | −git do it for you with the "git request-pull" command. | |
| 777 | +``git`` do it for you with the ``git request-pull`` command. | |
| 762 | 778 | |
| 763 | 779 | Some maintainers (including Linus) want to see pull requests from signed |
| 764 | 780 | commits; that increases their confidence that the request actually came |
| @@ -770,8 +786,8 @@ signed by one or more core kernel developers. This step can be hard for · 5 unmodified lines | ||
| 770 | 786 | new developers, but there is no way around it. Attending conferences can |
| 771 | 787 | be a good way to find developers who can sign your key. |
| 772 | 788 | |
| 773 | −Once you have prepared a patch series in git that you wish to have somebody | |
| 774 | −pull, create a signed tag with "git tag -s". This will create a new tag | |
| 789 | +Once you have prepared a patch series in ``git`` that you wish to have somebody | |
| 790 | +pull, create a signed tag with ``git tag -s``. This will create a new tag | |
| 775 | 791 | identifying the last commit in the series and containing a signature |
| 776 | 792 | created with your private key. You will also have the opportunity to add a |
| 777 | 793 | changelog-style message to the tag; this is an ideal place to describe the |
| @@ -782,14 +798,13 @@ are working from, don't forget to push the signed tag explicitly to the · 4 unmodified lines | ||
| 782 | 798 | public tree. |
| 783 | 799 | |
| 784 | 800 | When generating your pull request, use the signed tag as the target. A |
| 785 | −command like this will do the trick: | |
| 801 | +command like this will do the trick:: | |
| 786 | 802 | |
| 787 | 803 | git request-pull master git://my.public.tree/linux.git my-signed-tag |
| 788 | 804 | |
| 789 | 805 | |
| 790 | −---------------------- | |
| 791 | −SECTION 2 - REFERENCES | |
| 792 | −---------------------- | |
| 806 | +REFERENCES | |
| 807 | +********** | |
| 793 | 808 | |
| 794 | 809 | Andrew Morton, "The perfect patch" (tpp). |
| 795 | 810 | <http://www.ozlabs.org/~akpm/stuff/tpp.txt> |
| @@ -799,23 +814,28 @@ Jeff Garzik, "Linux kernel patch submission format". · 3 unmodified lines | ||
| 799 | 814 | |
| 800 | 815 | Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". |
| 801 | 816 | <http://www.kroah.com/log/linux/maintainer.html> |
| 817 | + | |
| 802 | 818 | <http://www.kroah.com/log/linux/maintainer-02.html> |
| 819 | + | |
| 803 | 820 | <http://www.kroah.com/log/linux/maintainer-03.html> |
| 821 | + | |
| 804 | 822 | <http://www.kroah.com/log/linux/maintainer-04.html> |
| 823 | + | |
| 805 | 824 | <http://www.kroah.com/log/linux/maintainer-05.html> |
| 825 | + | |
| 806 | 826 | <http://www.kroah.com/log/linux/maintainer-06.html> |
| 807 | 827 | |
| 808 | 828 | NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! |
| 809 | 829 | <https://lkml.org/lkml/2005/7/11/336> |
| 810 | 830 | |
| 811 | 831 | Kernel Documentation/CodingStyle: |
| 812 | − <Documentation/CodingStyle> | |
| 832 | + :ref:`Documentation/CodingStyle <codingstyle>` | |
| 813 | 833 | |
| 814 | 834 | Linus Torvalds's mail on the canonical patch format: |
| 815 | 835 | <http://lkml.org/lkml/2005/4/7/183> |
| 816 | 836 | |
| 817 | 837 | Andi Kleen, "On submitting kernel patches" |
| 818 | 838 | Some strategies to get difficult or controversial changes in. |
| 839 | + | |
| 819 | 840 | http://halobates.de/on-submitting-patches.pdf |
| 820 | 841 | |
| 821 | −-- | |
| @@ -1,7 +0,0 @@ | ||
| 1 | −# List of programs to build | |
| 2 | −hostprogs-y := getdelays | |
| 3 | − | |
| 4 | −# Tell kbuild to always build the programs | |
| 5 | −always := $(hostprogs-y) | |
| 6 | − | |
| 7 | −HOSTCFLAGS_getdelays.o += -I$(objtree)/usr/include | |
| @@ -54,9 +54,9 @@ are sent to userspace without requiring a command. If it is the last exiting · 53 unmodified lines | ||
| 54 | 54 | task of a thread group, the per-tgid statistics are also sent. More details |
| 55 | 55 | are given in the taskstats interface description. |
| 56 | 56 | |
| 57 | −The getdelays.c userspace utility in this directory allows simple commands to | |
| 58 | −be run and the corresponding delay statistics to be displayed. It also serves | |
| 59 | −as an example of using the taskstats interface. | |
| 57 | +The getdelays.c userspace utility in tools/accounting directory allows simple | |
| 58 | +commands to be run and the corresponding delay statistics to be displayed. It | |
| 59 | +also serves as an example of using the taskstats interface. | |
| 60 | 60 | |
| 61 | 61 | Usage |
| 62 | 62 | ----- |
| @@ -0,0 +1,96 @@ | ||
| 1 | +Special Usage Model of the ACPI Control Method Lid Device | |
| 2 | + | |
| 3 | +Copyright (C) 2016, Intel Corporation | |
| 4 | +Author: Lv Zheng <lv.zheng@intel.com> | |
| 5 | + | |
| 6 | + | |
| 7 | +Abstract: | |
| 8 | + | |
| 9 | +Platforms containing lids convey lid state (open/close) to OSPMs using a | |
| 10 | +control method lid device. To implement this, the AML tables issue | |
| 11 | +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has | |
| 12 | +changed. The _LID control method for the lid device must be implemented to | |
| 13 | +report the "current" state of the lid as either "opened" or "closed". | |
| 14 | + | |
| 15 | +For most platforms, both the _LID method and the lid notifications are | |
| 16 | +reliable. However, there are exceptions. In order to work with these | |
| 17 | +exceptional buggy platforms, special restrictions and expections should be | |
| 18 | +taken into account. This document describes the restrictions and the | |
| 19 | +expections of the Linux ACPI lid device driver. | |
| 20 | + | |
| 21 | + | |
| 22 | +1. Restrictions of the returning value of the _LID control method | |
| 23 | + | |
| 24 | +The _LID control method is described to return the "current" lid state. | |
| 25 | +However the word of "current" has ambiguity, some buggy AML tables return | |
| 26 | +the lid state upon the last lid notification instead of returning the lid | |
| 27 | +state upon the last _LID evaluation. There won't be difference when the | |
| 28 | +_LID control method is evaluated during the runtime, the problem is its | |
| 29 | +initial returning value. When the AML tables implement this control method | |
| 30 | +with cached value, the initial returning value is likely not reliable. | |
| 31 | +There are platforms always retun "closed" as initial lid state. | |
| 32 | + | |
| 33 | +2. Restrictions of the lid state change notifications | |
| 34 | + | |
| 35 | +There are buggy AML tables never notifying when the lid device state is | |
| 36 | +changed to "opened". Thus the "opened" notification is not guaranteed. But | |
| 37 | +it is guaranteed that the AML tables always notify "closed" when the lid | |
| 38 | +state is changed to "closed". The "closed" notification is normally used to | |
| 39 | +trigger some system power saving operations on Windows. Since it is fully | |
| 40 | +tested, it is reliable from all AML tables. | |
| 41 | + | |
| 42 | +3. Expections for the userspace users of the ACPI lid device driver | |
| 43 | + | |
| 44 | +The ACPI button driver exports the lid state to the userspace via the | |
| 45 | +following file: | |
| 46 | + /proc/acpi/button/lid/LID0/state | |
| 47 | +This file actually calls the _LID control method described above. And given | |
| 48 | +the previous explanation, it is not reliable enough on some platforms. So | |
| 49 | +it is advised for the userspace program to not to solely rely on this file | |
| 50 | +to determine the actual lid state. | |
| 51 | + | |
| 52 | +The ACPI button driver emits the following input event to the userspace: | |
| 53 | + SW_LID | |
| 54 | +The ACPI lid device driver is implemented to try to deliver the platform | |
| 55 | +triggered events to the userspace. However, given the fact that the buggy | |
| 56 | +firmware cannot make sure "opened"/"closed" events are paired, the ACPI | |
| 57 | +button driver uses the following 3 modes in order not to trigger issues. | |
| 58 | + | |
| 59 | +If the userspace hasn't been prepared to ignore the unreliable "opened" | |
| 60 | +events and the unreliable initial state notification, Linux users can use | |
| 61 | +the following kernel parameters to handle the possible issues: | |
| 62 | +A. button.lid_init_state=method: | |
| 63 | + When this option is specified, the ACPI button driver reports the | |
| 64 | + initial lid state using the returning value of the _LID control method | |
| 65 | + and whether the "opened"/"closed" events are paired fully relies on the | |
| 66 | + firmware implementation. | |
| 67 | + This option can be used to fix some platforms where the returning value | |
| 68 | + of the _LID control method is reliable but the initial lid state | |
| 69 | + notification is missing. | |
| 70 | + This option is the default behavior during the period the userspace | |
| 71 | + isn't ready to handle the buggy AML tables. | |
| 72 | +B. button.lid_init_state=open: | |
| 73 | + When this option is specified, the ACPI button driver always reports the | |
| 74 | + initial lid state as "opened" and whether the "opened"/"closed" events | |
| 75 | + are paired fully relies on the firmware implementation. | |
| 76 | + This may fix some platforms where the returning value of the _LID | |
| 77 | + control method is not reliable and the initial lid state notification is | |
| 78 | + missing. | |
| 79 | + | |
| 80 | +If the userspace has been prepared to ignore the unreliable "opened" events | |
| 81 | +and the unreliable initial state notification, Linux users should always | |
| 82 | +use the following kernel parameter: | |
| 83 | +C. button.lid_init_state=ignore: | |
| 84 | + When this option is specified, the ACPI button driver never reports the | |
| 85 | + initial lid state and there is a compensation mechanism implemented to | |
| 86 | + ensure that the reliable "closed" notifications can always be delievered | |
| 87 | + to the userspace by always pairing "closed" input events with complement | |
| 88 | + "opened" input events. But there is still no guarantee that the "opened" | |
| 89 | + notifications can be delivered to the userspace when the lid is actually | |
| 90 | + opens given that some AML tables do not send "opened" notifications | |
| 91 | + reliably. | |
| 92 | + In this mode, if everything is correctly implemented by the platform | |
| 93 | + firmware, the old userspace programs should still work. Otherwise, the | |
| 94 | + new userspace programs are required to work with the ACPI button driver. | |
| 95 | + This option will be the default behavior after the userspace is ready to | |
| 96 | + handle the buggy AML tables. | |
| @@ -28,8 +28,8 @@ index, like the ASL example below shows: · 27 unmodified lines | ||
| 28 | 28 | ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), |
| 29 | 29 | Package () |
| 30 | 30 | { |
| 31 | − Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }}, | |
| 32 | − Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }}, | |
| 31 | + Package () {"reset-gpios", Package() {^BTH, 1, 1, 0 }}, | |
| 32 | + Package () {"shutdown-gpios", Package() {^BTH, 0, 0, 0 }}, | |
| 33 | 33 | } |
| 34 | 34 | }) |
| 35 | 35 | } |
| @@ -48,7 +48,7 @@ Since ACPI GpioIo() resource does not have a field saying whether it is · 12 unmodified lines | ||
| 48 | 48 | active low or high, the "active_low" argument can be used here. Setting |
| 49 | 49 | it to 1 marks the GPIO as active low. |
| 50 | 50 | |
| 51 | −In our Bluetooth example the "reset-gpio" refers to the second GpioIo() | |
| 51 | +In our Bluetooth example the "reset-gpios" refers to the second GpioIo() | |
| 52 | 52 | resource, second pin in that resource with the GPIO number of 31. |
| 53 | 53 | |
| 54 | 54 | ACPI GPIO Mappings Provided by Drivers |
| @@ -83,8 +83,8 @@ static const struct acpi_gpio_params reset_gpio = { 1, 1, false }; · 28 unmodified lines | ||
| 83 | 83 | static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false }; |
| 84 | 84 | |
| 85 | 85 | static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = { |
| 86 | − { "reset-gpio", &reset_gpio, 1 }, | |
| 87 | − { "shutdown-gpio", &shutdown_gpio, 1 }, | |
| 86 | + { "reset-gpios", &reset_gpio, 1 }, | |
| 87 | + { "shutdown-gpios", &shutdown_gpio, 1 }, | |
| 88 | 88 | { }, |
| 89 | 89 | }; |
| 90 | 90 | |
| @@ -1,9 +1,13 @@ | ||
| 1 | +.. _applying_patches: | |
| 1 | 2 | |
| 2 | − Applying Patches To The Linux Kernel | |
| 3 | − ------------------------------------ | |
| 3 | +Applying Patches To The Linux Kernel | |
| 4 | +++++++++++++++++++++++++++++++++++++ | |
| 4 | 5 | |
| 5 | − Original by: Jesper Juhl, August 2005 | |
| 6 | − Last update: 2006-01-05 | |
| 6 | +Original by: | |
| 7 | + Jesper Juhl, August 2005 | |
| 8 | + | |
| 9 | +Last update: | |
| 10 | + 2016-09-14 | |
| 7 | 11 | |
| 8 | 12 | |
| 9 | 13 | A frequently asked question on the Linux Kernel Mailing List is how to apply |
| @@ -17,10 +21,12 @@ their specific patches) is also provided. · 7 unmodified lines | ||
| 17 | 21 | |
| 18 | 22 | |
| 19 | 23 | What is a patch? |
| 20 | −--- | |
| 21 | − A patch is a small text document containing a delta of changes between two | |
| 22 | −different versions of a source tree. Patches are created with the `diff' | |
| 24 | +================ | |
| 25 | + | |
| 26 | +A patch is a small text document containing a delta of changes between two | |
| 27 | +different versions of a source tree. Patches are created with the ``diff`` | |
| 23 | 28 | program. |
| 29 | + | |
| 24 | 30 | To correctly apply a patch you need to know what base it was generated from |
| 25 | 31 | and what new version the patch will change the source tree into. These |
| 26 | 32 | should both be present in the patch file metadata or be possible to deduce |
| @@ -28,8 +34,9 @@ from the filename. · 1 unmodified line | ||
| 28 | 34 | |
| 29 | 35 | |
| 30 | 36 | How do I apply or revert a patch? |
| 31 | −--- | |
| 32 | − You apply a patch with the `patch' program. The patch program reads a diff | |
| 37 | +================================= | |
| 38 | + | |
| 39 | +You apply a patch with the ``patch`` program. The patch program reads a diff | |
| 33 | 40 | (or patch) file and makes the changes to the source tree described in it. |
| 34 | 41 | |
| 35 | 42 | Patches for the Linux kernel are generated relative to the parent directory |
| @@ -38,26 +45,33 @@ holding the kernel source dir. · 2 unmodified lines | ||
| 38 | 45 | This means that paths to files inside the patch file contain the name of the |
| 39 | 46 | kernel source directories it was generated against (or some other directory |
| 40 | 47 | names like "a/" and "b/"). |
| 48 | + | |
| 41 | 49 | Since this is unlikely to match the name of the kernel source dir on your |
| 42 | 50 | local machine (but is often useful info to see what version an otherwise |
| 43 | 51 | unlabeled patch was generated against) you should change into your kernel |
| 44 | 52 | source directory and then strip the first element of the path from filenames |
| 45 | −in the patch file when applying it (the -p1 argument to `patch' does this). | |
| 53 | +in the patch file when applying it (the ``-p1`` argument to ``patch`` does | |
| 54 | +this). | |
| 46 | 55 | |
| 47 | 56 | To revert a previously applied patch, use the -R argument to patch. |
| 48 | −So, if you applied a patch like this: | |
| 57 | +So, if you applied a patch like this:: | |
| 58 | + | |
| 49 | 59 | patch -p1 < ../patch-x.y.z |
| 50 | 60 | |
| 51 | −You can revert (undo) it like this: | |
| 61 | +You can revert (undo) it like this:: | |
| 62 | + | |
| 52 | 63 | patch -R -p1 < ../patch-x.y.z |
| 53 | 64 | |
| 54 | 65 | |
| 55 | −How do I feed a patch/diff file to `patch'? | |
| 56 | −--- | |
| 57 | − This (as usual with Linux and other UNIX like operating systems) can be | |
| 66 | +How do I feed a patch/diff file to ``patch``? | |
| 67 | +============================================= | |
| 68 | + | |
| 69 | +This (as usual with Linux and other UNIX like operating systems) can be | |
| 58 | 70 | done in several different ways. |
| 71 | + | |
| 59 | 72 | In all the examples below I feed the file (in uncompressed form) to patch |
| 60 | −via stdin using the following syntax: | |
| 73 | +via stdin using the following syntax:: | |
| 74 | + | |
| 61 | 75 | patch -p1 < path/to/patch-x.y.z |
| 62 | 76 | |
| 63 | 77 | If you just want to be able to follow the examples below and don't want to |
| @@ -65,35 +79,40 @@ know of more than one way to use patch, then you can stop reading this · 1 unmodified line | ||
| 65 | 79 | section here. |
| 66 | 80 | |
| 67 | 81 | Patch can also get the name of the file to use via the -i argument, like |
| 68 | −this: | |
| 82 | +this:: | |
| 83 | + | |
| 69 | 84 | patch -p1 -i path/to/patch-x.y.z |
| 70 | 85 | |
| 71 | −If your patch file is compressed with gzip or bzip2 and you don't want to | |
| 86 | +If your patch file is compressed with gzip or xz and you don't want to | |
| 72 | 87 | uncompress it before applying it, then you can feed it to patch like this |
| 73 | −instead: | |
| 74 | − zcat path/to/patch-x.y.z.gz | patch -p1 | |
| 75 | − bzcat path/to/patch-x.y.z.bz2 | patch -p1 | |
| 88 | +instead:: | |
| 89 | + | |
| 90 | + xzcat path/to/patch-x.y.z.xz | patch -p1 | |
| 91 | + bzcat path/to/patch-x.y.z.gz | patch -p1 | |
| 76 | 92 | |
| 77 | 93 | If you wish to uncompress the patch file by hand first before applying it |
| 78 | 94 | (what I assume you've done in the examples below), then you simply run |
| 79 | −gunzip or bunzip2 on the file -- like this: | |
| 95 | +gunzip or xz on the file -- like this:: | |
| 96 | + | |
| 80 | 97 | gunzip patch-x.y.z.gz |
| 81 | − bunzip2 patch-x.y.z.bz2 | |
| 98 | + xz -d patch-x.y.z.xz | |
| 82 | 99 | |
| 83 | 100 | Which will leave you with a plain text patch-x.y.z file that you can feed to |
| 84 | −patch via stdin or the -i argument, as you prefer. | |
| 101 | +patch via stdin or the ``-i`` argument, as you prefer. | |
| 85 | 102 | |
| 86 | −A few other nice arguments for patch are -s which causes patch to be silent | |
| 103 | +A few other nice arguments for patch are ``-s`` which causes patch to be silent | |
| 87 | 104 | except for errors which is nice to prevent errors from scrolling out of the |
| 88 | −screen too fast, and --dry-run which causes patch to just print a listing of | |
| 89 | −what would happen, but doesn't actually make any changes. Finally --verbose | |
| 105 | +screen too fast, and ``--dry-run`` which causes patch to just print a listing of | |
| 106 | +what would happen, but doesn't actually make any changes. Finally ``--verbose`` | |
| 90 | 107 | tells patch to print more information about the work being done. |
| 91 | 108 | |
| 92 | 109 | |
| 93 | 110 | Common errors when patching |
| 94 | −--- | |
| 95 | − When patch applies a patch file it attempts to verify the sanity of the | |
| 111 | +=========================== | |
| 112 | + | |
| 113 | +When patch applies a patch file it attempts to verify the sanity of the | |
| 96 | 114 | file in different ways. |
| 115 | + | |
| 97 | 116 | Checking that the file looks like a valid patch file and checking the code |
| 98 | 117 | around the bits being modified matches the context provided in the patch are |
| 99 | 118 | just two of the basic sanity checks patch does. |
| @@ -111,13 +130,13 @@ everything looks good it has just moved up or down a bit, and patch will · 11 unmodified lines | ||
| 111 | 130 | usually adjust the line numbers and apply the patch. |
| 112 | 131 | |
| 113 | 132 | Whenever patch applies a patch that it had to modify a bit to make it fit |
| 114 | −it'll tell you about it by saying the patch applied with 'fuzz'. | |
| 133 | +it'll tell you about it by saying the patch applied with **fuzz**. | |
| 115 | 134 | You should be wary of such changes since even though patch probably got it |
| 116 | 135 | right it doesn't /always/ get it right, and the result will sometimes be |
| 117 | 136 | wrong. |
| 118 | 137 | |
| 119 | 138 | When patch encounters a change that it can't fix up with fuzz it rejects it |
| 120 | −outright and leaves a file with a .rej extension (a reject file). You can | |
| 139 | +outright and leaves a file with a ``.rej`` extension (a reject file). You can | |
| 121 | 140 | read this file to see exactly what change couldn't be applied, so you can |
| 122 | 141 | go fix it up by hand if you wish. |
| 123 | 142 | |
| @@ -132,43 +151,47 @@ to start with a fresh tree downloaded in full from kernel.org. · 8 unmodified lines | ||
| 132 | 151 | |
| 133 | 152 | Let's look a bit more at some of the messages patch can produce. |
| 134 | 153 | |
| 135 | −If patch stops and presents a "File to patch:" prompt, then patch could not | |
| 154 | +If patch stops and presents a ``File to patch:`` prompt, then patch could not | |
| 136 | 155 | find a file to be patched. Most likely you forgot to specify -p1 or you are |
| 137 | 156 | in the wrong directory. Less often, you'll find patches that need to be |
| 138 | −applied with -p0 instead of -p1 (reading the patch file should reveal if | |
| 157 | +applied with ``-p0`` instead of ``-p1`` (reading the patch file should reveal if | |
| 139 | 158 | this is the case -- if so, then this is an error by the person who created |
| 140 | 159 | the patch but is not fatal). |
| 141 | 160 | |
| 142 | −If you get "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." or a | |
| 161 | +If you get ``Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).`` or a | |
| 143 | 162 | message similar to that, then it means that patch had to adjust the location |
| 144 | 163 | of the change (in this example it needed to move 7 lines from where it |
| 145 | 164 | expected to make the change to make it fit). |
| 165 | + | |
| 146 | 166 | The resulting file may or may not be OK, depending on the reason the file |
| 147 | 167 | was different than expected. |
| 168 | + | |
| 148 | 169 | This often happens if you try to apply a patch that was generated against a |
| 149 | 170 | different kernel version than the one you are trying to patch. |
| 150 | 171 | |
| 151 | −If you get a message like "Hunk #3 FAILED at 2387.", then it means that the | |
| 172 | +If you get a message like ``Hunk #3 FAILED at 2387.``, then it means that the | |
| 152 | 173 | patch could not be applied correctly and the patch program was unable to |
| 153 | −fuzz its way through. This will generate a .rej file with the change that | |
| 154 | −caused the patch to fail and also a .orig file showing you the original | |
| 174 | +fuzz its way through. This will generate a ``.rej`` file with the change that | |
| 175 | +caused the patch to fail and also a ``.orig`` file showing you the original | |
| 155 | 176 | content that couldn't be changed. |
| 156 | 177 | |
| 157 | −If you get "Reversed (or previously applied) patch detected! Assume -R? [n]" | |
| 178 | +If you get ``Reversed (or previously applied) patch detected! Assume -R? [n]`` | |
| 158 | 179 | then patch detected that the change contained in the patch seems to have |
| 159 | 180 | already been made. |
| 181 | + | |
| 160 | 182 | If you actually did apply this patch previously and you just re-applied it |
| 161 | 183 | in error, then just say [n]o and abort this patch. If you applied this patch |
| 162 | 184 | previously and actually intended to revert it, but forgot to specify -R, |
| 163 | −then you can say [y]es here to make patch revert it for you. | |
| 185 | +then you can say [**y**]es here to make patch revert it for you. | |
| 186 | + | |
| 164 | 187 | This can also happen if the creator of the patch reversed the source and |
| 165 | 188 | destination directories when creating the patch, and in that case reverting |
| 166 | 189 | the patch will in fact apply it. |
| 167 | 190 | |
| 168 | −A message similar to "patch: **** unexpected end of file in patch" or "patch | |
| 169 | −unexpectedly ends in middle of line" means that patch could make no sense of | |
| 170 | −the file you fed to it. Either your download is broken, you tried to feed | |
| 171 | −patch a compressed patch file without uncompressing it first, or the patch | |
| 191 | +A message similar to ``patch: **** unexpected end of file in patch`` or | |
| 192 | +``patch unexpectedly ends in middle of line`` means that patch could make no | |
| 193 | +sense of the file you fed to it. Either your download is broken, you tried to | |
| 194 | +feed patch a compressed patch file without uncompressing it first, or the patch | |
| 172 | 195 | file that you are using has been mangled by a mail client or mail transfer |
| 173 | 196 | agent along the way somewhere, e.g., by splitting a long line into two lines. |
| 174 | 197 | Often these warnings can easily be fixed by joining (concatenating) the |
| @@ -182,28 +205,32 @@ to start over with a fresh download of a full kernel tree and the patch you · 7 unmodified lines | ||
| 182 | 205 | wish to apply. |
| 183 | 206 | |
| 184 | 207 | |
| 185 | −Are there any alternatives to `patch'? | |
| 186 | −--- | |
| 187 | − Yes there are alternatives. | |
| 208 | +Are there any alternatives to ``patch``? | |
| 209 | +======================================== | |
| 188 | 210 | |
| 189 | − You can use the `interdiff' program (http://cyberelk.net/tim/patchutils/) to | |
| 211 | + | |
| 212 | +Yes there are alternatives. | |
| 213 | + | |
| 214 | +You can use the ``interdiff`` program (http://cyberelk.net/tim/patchutils/) to | |
| 190 | 215 | generate a patch representing the differences between two patches and then |
| 191 | 216 | apply the result. |
| 192 | −This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single | |
| 217 | + | |
| 218 | +This will let you move from something like 4.7.2 to 4.7.3 in a single | |
| 193 | 219 | step. The -z flag to interdiff will even let you feed it patches in gzip or |
| 194 | 220 | bzip2 compressed form directly without the use of zcat or bzcat or manual |
| 195 | 221 | decompression. |
| 196 | 222 | |
| 197 | −Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step: | |
| 198 | − interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 | |
| 223 | +Here's how you'd go from 4.7.2 to 4.7.3 in a single step:: | |
| 224 | + | |
| 225 | + interdiff -z ../patch-4.7.2.gz ../patch-4.7.3.gz | patch -p1 | |
| 199 | 226 | |
| 200 | 227 | Although interdiff may save you a step or two you are generally advised to |
| 201 | 228 | do the additional steps since interdiff can get things wrong in some cases. |
| 202 | 229 | |
| 203 | − Another alternative is `ketchup', which is a python script for automatic | |
| 230 | +Another alternative is ``ketchup``, which is a python script for automatic | |
| 204 | 231 | downloading and applying of patches (http://www.selenic.com/ketchup/). |
| 205 | 232 | |
| 206 | − Other nice tools are diffstat, which shows a summary of changes made by a | |
| 233 | +Other nice tools are diffstat, which shows a summary of changes made by a | |
| 207 | 234 | patch; lsdiff, which displays a short listing of affected files in a patch |
| 208 | 235 | file, along with (optionally) the line numbers of the start of each patch; |
| 209 | 236 | and grepdiff, which displays a list of the files modified by a patch where |
| @@ -211,99 +238,103 @@ the patch contains a given regular expression. · 1 unmodified line | ||
| 211 | 238 | |
| 212 | 239 | |
| 213 | 240 | Where can I download the patches? |
| 214 | −--- | |
| 215 | − The patches are available at http://kernel.org/ | |
| 241 | +================================= | |
| 242 | + | |
| 243 | +The patches are available at http://kernel.org/ | |
| 216 | 244 | Most recent patches are linked from the front page, but they also have |
| 217 | 245 | specific homes. |
| 218 | 246 | |
| 219 | −The 2.6.x.y (-stable) and 2.6.x patches live at | |
| 220 | − ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ | |
| 247 | +The 4.x.y (-stable) and 4.x patches live at | |
| 221 | 248 | |
| 222 | −The -rc patches live at | |
| 223 | − ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ | |
| 249 | + ftp://ftp.kernel.org/pub/linux/kernel/v4.x/ | |
| 224 | 250 | |
| 225 | −The -git patches live at | |
| 226 | − ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ | |
| 251 | +The -rc patches live at | |
| 227 | 252 | |
| 228 | −The -mm kernels live at | |
| 229 | − ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ | |
| 253 | + ftp://ftp.kernel.org/pub/linux/kernel/v4.x/testing/ | |
| 230 | 254 | |
| 231 | −In place of ftp.kernel.org you can use ftp.cc.kernel.org, where cc is a | |
| 255 | +In place of ``ftp.kernel.org`` you can use ``ftp.cc.kernel.org``, where cc is a | |
| 232 | 256 | country code. This way you'll be downloading from a mirror site that's most |
| 233 | 257 | likely geographically closer to you, resulting in faster downloads for you, |
| 234 | 258 | less bandwidth used globally and less load on the main kernel.org servers -- |
| 235 | 259 | these are good things, so do use mirrors when possible. |
| 236 | 260 | |
| 237 | 261 | |
| 238 | −The 2.6.x kernels | |
| 239 | −--- | |
| 240 | − These are the base stable releases released by Linus. The highest numbered | |
| 262 | +The 4.x kernels | |
| 263 | +=============== | |
| 264 | + | |
| 265 | +These are the base stable releases released by Linus. The highest numbered | |
| 241 | 266 | release is the most recent. |
| 242 | 267 | |
| 243 | 268 | If regressions or other serious flaws are found, then a -stable fix patch |
| 244 | −will be released (see below) on top of this base. Once a new 2.6.x base | |
| 269 | +will be released (see below) on top of this base. Once a new 4.x base | |
| 245 | 270 | kernel is released, a patch is made available that is a delta between the |
| 246 | −previous 2.6.x kernel and the new one. | |
| 271 | +previous 4.x kernel and the new one. | |
| 272 | + | |
| 273 | +To apply a patch moving from 4.6 to 4.7, you'd do the following (note | |
| 274 | +that such patches do **NOT** apply on top of 4.x.y kernels but on top of the | |
| 275 | +base 4.x kernel -- if you need to move from 4.x.y to 4.x+1 you need to | |
| 276 | +first revert the 4.x.y patch). | |
| 277 | + | |
| 278 | +Here are some examples:: | |
| 247 | 279 | |
| 248 | −To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note | |
| 249 | −that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the | |
| 250 | −base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to | |
| 251 | −first revert the 2.6.x.y patch). | |
| 280 | + # moving from 4.6 to 4.7 | |
| 252 | 281 | |
| 253 | −Here are some examples: | |
| 282 | + $ cd ~/linux-4.6 # change to kernel source dir | |
| 283 | + $ patch -p1 < ../patch-4.7 # apply the 4.7 patch | |
| 284 | + $ cd .. | |
| 285 | + $ mv linux-4.6 linux-4.7 # rename source dir | |
| 254 | 286 | |
| 255 | −# moving from 2.6.11 to 2.6.12 | |
| 256 | −$ cd ~/linux-2.6.11 # change to kernel source dir | |
| 257 | −$ patch -p1 < ../patch-2.6.12 # apply the 2.6.12 patch | |
| 258 | −$ cd .. | |
| 259 | −$ mv linux-2.6.11 linux-2.6.12 # rename source dir | |
| 287 | + # moving from 4.6.1 to 4.7 | |
| 260 | 288 | |
| 261 | −# moving from 2.6.11.1 to 2.6.12 | |
| 262 | −$ cd ~/linux-2.6.11.1 # change to kernel source dir | |
| 263 | −$ patch -p1 -R < ../patch-2.6.11.1 # revert the 2.6.11.1 patch | |
| 264 | − # source dir is now 2.6.11 | |
| 265 | −$ patch -p1 < ../patch-2.6.12 # apply new 2.6.12 patch | |
| 266 | −$ cd .. | |
| 267 | −$ mv linux-2.6.11.1 linux-2.6.12 # rename source dir | |
| 289 | + $ cd ~/linux-4.6.1 # change to kernel source dir | |
| 290 | + $ patch -p1 -R < ../patch-4.6.1 # revert the 4.6.1 patch | |
| 291 | + # source dir is now 4.6 | |
| 292 | + $ patch -p1 < ../patch-4.7 # apply new 4.7 patch | |
| 293 | + $ cd .. | |
| 294 | + $ mv linux-4.6.1 linux-4.7 # rename source dir | |
| 268 | 295 | |
| 269 | 296 | |
| 270 | −The 2.6.x.y kernels | |
| 271 | −--- | |
| 272 | − Kernels with 4-digit versions are -stable kernels. They contain small(ish) | |
| 297 | +The 4.x.y kernels | |
| 298 | +================= | |
| 299 | + | |
| 300 | +Kernels with 3-digit versions are -stable kernels. They contain small(ish) | |
| 273 | 301 | critical fixes for security problems or significant regressions discovered |
| 274 | −in a given 2.6.x kernel. | |
| 302 | +in a given 4.x kernel. | |
| 275 | 303 | |
| 276 | 304 | This is the recommended branch for users who want the most recent stable |
| 277 | 305 | kernel and are not interested in helping test development/experimental |
| 278 | 306 | versions. |
| 279 | 307 | |
| 280 | −If no 2.6.x.y kernel is available, then the highest numbered 2.6.x kernel is | |
| 308 | +If no 4.x.y kernel is available, then the highest numbered 4.x kernel is | |
| 281 | 309 | the current stable kernel. |
| 282 | 310 | |
| 283 | − note: the -stable team usually do make incremental patches available as well | |
| 311 | +.. note:: | |
| 312 | + | |
| 313 | + The -stable team usually do make incremental patches available as well | |
| 284 | 314 | as patches against the latest mainline release, but I only cover the |
| 285 | 315 | non-incremental ones below. The incremental ones can be found at |
| 286 | − ftp://ftp.kernel.org/pub/linux/kernel/v2.6/incr/ | |
| 316 | + ftp://ftp.kernel.org/pub/linux/kernel/v4.x/incr/ | |
| 287 | 317 | |
| 288 | −These patches are not incremental, meaning that for example the 2.6.12.3 | |
| 289 | −patch does not apply on top of the 2.6.12.2 kernel source, but rather on top | |
| 290 | −of the base 2.6.12 kernel source . | |
| 291 | −So, in order to apply the 2.6.12.3 patch to your existing 2.6.12.2 kernel | |
| 292 | −source you have to first back out the 2.6.12.2 patch (so you are left with a | |
| 293 | −base 2.6.12 kernel source) and then apply the new 2.6.12.3 patch. | |
| 318 | +These patches are not incremental, meaning that for example the 4.7.3 | |
| 319 | +patch does not apply on top of the 4.7.2 kernel source, but rather on top | |
| 320 | +of the base 4.7 kernel source. | |
| 294 | 321 | |
| 295 | −Here's a small example: | |
| 322 | +So, in order to apply the 4.7.3 patch to your existing 4.7.2 kernel | |
| 323 | +source you have to first back out the 4.7.2 patch (so you are left with a | |
| 324 | +base 4.7 kernel source) and then apply the new 4.7.3 patch. | |
| 296 | 325 | |
| 297 | −$ cd ~/linux-2.6.12.2 # change into the kernel source dir | |
| 298 | −$ patch -p1 -R < ../patch-2.6.12.2 # revert the 2.6.12.2 patch | |
| 299 | −$ patch -p1 < ../patch-2.6.12.3 # apply the new 2.6.12.3 patch | |
| 300 | −$ cd .. | |
| 301 | −$ mv linux-2.6.12.2 linux-2.6.12.3 # rename the kernel source dir | |
| 326 | +Here's a small example:: | |
| 302 | 327 | |
| 328 | + $ cd ~/linux-4.7.2 # change to the kernel source dir | |
| 329 | + $ patch -p1 -R < ../patch-4.7.2 # revert the 4.7.2 patch | |
| 330 | + $ patch -p1 < ../patch-4.7.3 # apply the new 4.7.3 patch | |
| 331 | + $ cd .. | |
| 332 | + $ mv linux-4.7.2 linux-4.7.3 # rename the kernel source dir | |
| 303 | 333 | |
| 304 | 334 | The -rc kernels |
| 305 | −--- | |
| 306 | − These are release-candidate kernels. These are development kernels released | |
| 335 | +=============== | |
| 336 | + | |
| 337 | +These are release-candidate kernels. These are development kernels released | |
| 307 | 338 | by Linus whenever he deems the current git (the kernel's source management |
| 308 | 339 | tool) tree to be in a reasonably sane state adequate for testing. |
| 309 | 340 | |
| @@ -317,39 +348,44 @@ This is a good branch to run for people who want to help out testing · 7 unmodified lines | ||
| 317 | 348 | development kernels but do not want to run some of the really experimental |
| 318 | 349 | stuff (such people should see the sections about -git and -mm kernels below). |
| 319 | 350 | |
| 320 | −The -rc patches are not incremental, they apply to a base 2.6.x kernel, just | |
| 321 | −like the 2.6.x.y patches described above. The kernel version before the -rcN | |
| 351 | +The -rc patches are not incremental, they apply to a base 4.x kernel, just | |
| 352 | +like the 4.x.y patches described above. The kernel version before the -rcN | |
| 322 | 353 | suffix denotes the version of the kernel that this -rc kernel will eventually |
| 323 | 354 | turn into. |
| 324 | −So, 2.6.13-rc5 means that this is the fifth release candidate for the 2.6.13 | |
| 325 | −kernel and the patch should be applied on top of the 2.6.12 kernel source. | |
| 326 | 355 | |
| 327 | −Here are 3 examples of how to apply these patches: | |
| 356 | +So, 4.8-rc5 means that this is the fifth release candidate for the 4.8 | |
| 357 | +kernel and the patch should be applied on top of the 4.7 kernel source. | |
| 328 | 358 | |
| 329 | −# first an example of moving from 2.6.12 to 2.6.13-rc3 | |
| 330 | −$ cd ~/linux-2.6.12 # change into the 2.6.12 source dir | |
| 331 | −$ patch -p1 < ../patch-2.6.13-rc3 # apply the 2.6.13-rc3 patch | |
| 332 | −$ cd .. | |
| 333 | −$ mv linux-2.6.12 linux-2.6.13-rc3 # rename the source dir | |
| 359 | +Here are 3 examples of how to apply these patches:: | |
| 334 | 360 | |
| 335 | −# now let's move from 2.6.13-rc3 to 2.6.13-rc5 | |
| 336 | −$ cd ~/linux-2.6.13-rc3 # change into the 2.6.13-rc3 dir | |
| 337 | −$ patch -p1 -R < ../patch-2.6.13-rc3 # revert the 2.6.13-rc3 patch | |
| 338 | −$ patch -p1 < ../patch-2.6.13-rc5 # apply the new 2.6.13-rc5 patch | |
| 339 | −$ cd .. | |
| 340 | −$ mv linux-2.6.13-rc3 linux-2.6.13-rc5 # rename the source dir | |
| 361 | + # first an example of moving from 4.7 to 4.8-rc3 | |
| 341 | 362 | |
| 342 | −# finally let's try and move from 2.6.12.3 to 2.6.13-rc5 | |
| 343 | −$ cd ~/linux-2.6.12.3 # change to the kernel source dir | |
| 344 | −$ patch -p1 -R < ../patch-2.6.12.3 # revert the 2.6.12.3 patch | |
| 345 | −$ patch -p1 < ../patch-2.6.13-rc5 # apply new 2.6.13-rc5 patch | |
| 346 | −$ cd .. | |
| 347 | −$ mv linux-2.6.12.3 linux-2.6.13-rc5 # rename the kernel source dir | |
| 363 | + $ cd ~/linux-4.7 # change to the 4.7 source dir | |
| 364 | + $ patch -p1 < ../patch-4.8-rc3 # apply the 4.8-rc3 patch | |
| 365 | + $ cd .. | |
| 366 | + $ mv linux-4.7 linux-4.8-rc3 # rename the source dir | |
| 367 | + | |
| 368 | + # now let's move from 4.8-rc3 to 4.8-rc5 | |
| 369 | + | |
| 370 | + $ cd ~/linux-4.8-rc3 # change to the 4.8-rc3 dir | |
| 371 | + $ patch -p1 -R < ../patch-4.8-rc3 # revert the 4.8-rc3 patch | |
| 372 | + $ patch -p1 < ../patch-4.8-rc5 # apply the new 4.8-rc5 patch | |
| 373 | + $ cd .. | |
| 374 | + $ mv linux-4.8-rc3 linux-4.8-rc5 # rename the source dir | |
| 375 | + | |
| 376 | + # finally let's try and move from 4.7.3 to 4.8-rc5 | |
| 377 | + | |
| 378 | + $ cd ~/linux-4.7.3 # change to the kernel source dir | |
| 379 | + $ patch -p1 -R < ../patch-4.7.3 # revert the 4.7.3 patch | |
| 380 | + $ patch -p1 < ../patch-4.8-rc5 # apply new 4.8-rc5 patch | |
| 381 | + $ cd .. | |
| 382 | + $ mv linux-4.7.3 linux-4.8-rc5 # rename the kernel source dir | |
| 348 | 383 | |
| 349 | 384 | |
| 350 | 385 | The -git kernels |
| 351 | −--- | |
| 352 | − These are daily snapshots of Linus' kernel tree (managed in a git | |
| 386 | +================ | |
| 387 | + | |
| 388 | +These are daily snapshots of Linus' kernel tree (managed in a git | |
| 353 | 389 | repository, hence the name). |
| 354 | 390 | |
| 355 | 391 | These patches are usually released daily and represent the current state of |
| @@ -357,91 +393,66 @@ Linus's tree. They are more experimental than -rc kernels since they are · 1 unmodified line | ||
| 357 | 393 | generated automatically without even a cursory glance to see if they are |
| 358 | 394 | sane. |
| 359 | 395 | |
| 360 | −-git patches are not incremental and apply either to a base 2.6.x kernel or | |
| 361 | −a base 2.6.x-rc kernel -- you can see which from their name. | |
| 362 | −A patch named 2.6.12-git1 applies to the 2.6.12 kernel source and a patch | |
| 363 | −named 2.6.13-rc3-git2 applies to the source of the 2.6.13-rc3 kernel. | |
| 364 | − | |
| 365 | −Here are some examples of how to apply these patches: | |
| 366 | − | |
| 367 | −# moving from 2.6.12 to 2.6.12-git1 | |
| 368 | −$ cd ~/linux-2.6.12 # change to the kernel source dir | |
| 369 | −$ patch -p1 < ../patch-2.6.12-git1 # apply the 2.6.12-git1 patch | |
| 370 | −$ cd .. | |
| 371 | −$ mv linux-2.6.12 linux-2.6.12-git1 # rename the kernel source dir | |
| 372 | − | |
| 373 | −# moving from 2.6.12-git1 to 2.6.13-rc2-git3 | |
| 374 | −$ cd ~/linux-2.6.12-git1 # change to the kernel source dir | |
| 375 | −$ patch -p1 -R < ../patch-2.6.12-git1 # revert the 2.6.12-git1 patch | |
| 376 | − # we now have a 2.6.12 kernel | |
| 377 | −$ patch -p1 < ../patch-2.6.13-rc2 # apply the 2.6.13-rc2 patch | |
| 378 | − # the kernel is now 2.6.13-rc2 | |
| 379 | −$ patch -p1 < ../patch-2.6.13-rc2-git3 # apply the 2.6.13-rc2-git3 patch | |
| 380 | − # the kernel is now 2.6.13-rc2-git3 | |
| 381 | −$ cd .. | |
| 382 | −$ mv linux-2.6.12-git1 linux-2.6.13-rc2-git3 # rename source dir | |
| 383 | − | |
| 384 | − | |
| 385 | −The -mm kernels | |
| 386 | −--- | |
| 387 | − These are experimental kernels released by Andrew Morton. | |
| 388 | − | |
| 389 | −The -mm tree serves as a sort of proving ground for new features and other | |
| 390 | −experimental patches. | |
| 391 | −Once a patch has proved its worth in -mm for a while Andrew pushes it on to | |
| 392 | −Linus for inclusion in mainline. | |
| 393 | − | |
| 394 | −Although it's encouraged that patches flow to Linus via the -mm tree, this | |
| 395 | −is not always enforced. | |
| 396 | −Subsystem maintainers (or individuals) sometimes push their patches directly | |
| 397 | −to Linus, even though (or after) they have been merged and tested in -mm (or | |
| 398 | −sometimes even without prior testing in -mm). | |
| 399 | − | |
| 400 | −You should generally strive to get your patches into mainline via -mm to | |
| 401 | −ensure maximum testing. | |
| 402 | − | |
| 403 | −This branch is in constant flux and contains many experimental features, a | |
| 396 | +-git patches are not incremental and apply either to a base 4.x kernel or | |
| 397 | +a base 4.x-rc kernel -- you can see which from their name. | |
| 398 | +A patch named 4.7-git1 applies to the 4.7 kernel source and a patch | |
| 399 | +named 4.8-rc3-git2 applies to the source of the 4.8-rc3 kernel. | |
| 400 | + | |
| 401 | +Here are some examples of how to apply these patches:: | |
| 402 | + | |
| 403 | + # moving from 4.7 to 4.7-git1 | |
| 404 | + | |
| 405 | + $ cd ~/linux-4.7 # change to the kernel source dir | |
| 406 | + $ patch -p1 < ../patch-4.7-git1 # apply the 4.7-git1 patch | |
| 407 | + $ cd .. | |
| 408 | + $ mv linux-4.7 linux-4.7-git1 # rename the kernel source dir | |
| 409 | + | |
| 410 | + # moving from 4.7-git1 to 4.8-rc2-git3 | |
| 411 | + | |
| 412 | + $ cd ~/linux-4.7-git1 # change to the kernel source dir | |
| 413 | + $ patch -p1 -R < ../patch-4.7-git1 # revert the 4.7-git1 patch | |
| 414 | + # we now have a 4.7 kernel | |
| 415 | + $ patch -p1 < ../patch-4.8-rc2 # apply the 4.8-rc2 patch | |
| 416 | + # the kernel is now 4.8-rc2 | |
| 417 | + $ patch -p1 < ../patch-4.8-rc2-git3 # apply the 4.8-rc2-git3 patch | |
| 418 | + # the kernel is now 4.8-rc2-git3 | |
| 419 | + $ cd .. | |
| 420 | + $ mv linux-4.7-git1 linux-4.8-rc2-git3 # rename source dir | |
| 421 | + | |
| 422 | + | |
| 423 | +The -mm patches and the linux-next tree | |
| 424 | +======================================= | |
| 425 | + | |
| 426 | +The -mm patches are experimental patches released by Andrew Morton. | |
| 427 | + | |
| 428 | +In the past, -mm tree were used to also test subsystem patches, but this | |
| 429 | +function is now done via the | |
| 430 | +:ref:`linux-next <https://www.kernel.org/doc/man-pages/linux-next.html>` | |
| 431 | +tree. The Subsystem maintainers push their patches first to linux-next, | |
| 432 | +and, during the merge window, sends them directly to Linus. | |
| 433 | + | |
| 434 | +The -mm patches serve as a sort of proving ground for new features and other | |
| 435 | +experimental patches that aren't merged via a subsystem tree. | |
| 436 | +Once such patches has proved its worth in -mm for a while Andrew pushes | |
| 437 | +it on to Linus for inclusion in mainline. | |
| 438 | + | |
| 439 | +The linux-next tree is daily updated, and includes the -mm patches. | |
| 440 | +Both are in constant flux and contains many experimental features, a | |
| 404 | 441 | lot of debugging patches not appropriate for mainline etc., and is the most |
| 405 | 442 | experimental of the branches described in this document. |
| 406 | 443 | |
| 407 | −These kernels are not appropriate for use on systems that are supposed to be | |
| 444 | +These patches are not appropriate for use on systems that are supposed to be | |
| 408 | 445 | stable and they are more risky to run than any of the other branches (make |
| 409 | 446 | sure you have up-to-date backups -- that goes for any experimental kernel but |
| 410 | −even more so for -mm kernels). | |
| 411 | − | |
| 412 | −These kernels in addition to all the other experimental patches they contain | |
| 413 | −usually also contain any changes in the mainline -git kernels available at | |
| 414 | −the time of release. | |
| 415 | − | |
| 416 | −Testing of -mm kernels is greatly appreciated since the whole point of the | |
| 417 | −tree is to weed out regressions, crashes, data corruption bugs, build | |
| 418 | −breakage (and any other bug in general) before changes are merged into the | |
| 419 | −more stable mainline Linus tree. | |
| 420 | −But testers of -mm should be aware that breakage in this tree is more common | |
| 421 | −than in any other tree. | |
| 422 | − | |
| 423 | −The -mm kernels are not released on a fixed schedule, but usually a few -mm | |
| 424 | −kernels are released in between each -rc kernel (1 to 3 is common). | |
| 425 | −The -mm kernels apply to either a base 2.6.x kernel (when no -rc kernels | |
| 426 | −have been released yet) or to a Linus -rc kernel. | |
| 427 | − | |
| 428 | −Here are some examples of applying the -mm patches: | |
| 429 | − | |
| 430 | −# moving from 2.6.12 to 2.6.12-mm1 | |
| 431 | −$ cd ~/linux-2.6.12 # change to the 2.6.12 source dir | |
| 432 | −$ patch -p1 < ../2.6.12-mm1 # apply the 2.6.12-mm1 patch | |
| 433 | −$ cd .. | |
| 434 | −$ mv linux-2.6.12 linux-2.6.12-mm1 # rename the source appropriately | |
| 435 | − | |
| 436 | −# moving from 2.6.12-mm1 to 2.6.13-rc3-mm3 | |
| 437 | −$ cd ~/linux-2.6.12-mm1 | |
| 438 | −$ patch -p1 -R < ../2.6.12-mm1 # revert the 2.6.12-mm1 patch | |
| 439 | − # we now have a 2.6.12 source | |
| 440 | −$ patch -p1 < ../patch-2.6.13-rc3 # apply the 2.6.13-rc3 patch | |
| 441 | − # we now have a 2.6.13-rc3 source | |
| 442 | −$ patch -p1 < ../2.6.13-rc3-mm3 # apply the 2.6.13-rc3-mm3 patch | |
| 443 | −$ cd .. | |
| 444 | −$ mv linux-2.6.12-mm1 linux-2.6.13-rc3-mm3 # rename the source dir | |
| 447 | +even more so for -mm patches or using a Kernel from the linux-next tree). | |
| 448 | + | |
| 449 | +Testing of -mm patches and linux-next is greatly appreciated since the whole | |
| 450 | +point of those are to weed out regressions, crashes, data corruption bugs, | |
| 451 | +build breakage (and any other bug in general) before changes are merged into | |
| 452 | +the more stable mainline Linus tree. | |
| 453 | + | |
| 454 | +But testers of -mm and linux-next should be aware that breakages are | |
| 455 | +more common than in any other tree. | |
| 445 | 456 | |
| 446 | 457 | |
| 447 | 458 | This concludes this list of explanations of the various kernel trees. |
| @@ -8,8 +8,6 @@ Interrupts · 7 unmodified lines | ||
| 8 | 8 | - ARM Interrupt subsystem documentation |
| 9 | 9 | IXP4xx |
| 10 | 10 | - Intel IXP4xx Network processor. |
| 11 | −Makefile | |
| 12 | − - Build sourcefiles as part of the Documentation-build for arm | |
| 13 | 11 | Netwinder |
| 14 | 12 | - Netwinder specific documentation |
| 15 | 13 | Porting |
| @@ -18,13 +18,17 @@ and config2 fields of the perf_event_attr structure. The "events" · 17 unmodified lines | ||
| 18 | 18 | directory provides configuration templates for all documented |
| 19 | 19 | events, that can be used with perf tool. For example "xp_valid_flit" |
| 20 | 20 | is an equivalent of "type=0x8,event=0x4". Other parameters must be |
| 21 | −explicitly specified. For events originating from device, "node" | |
| 22 | −defines its index. All crosspoint events require "xp" (index), | |
| 23 | −"port" (device port number) and "vc" (virtual channel ID) and | |
| 24 | −"dir" (direction). Watchpoints (special "event" value 0xfe) also | |
| 25 | −require comparator values ("cmp_l" and "cmp_h") and "mask", being | |
| 26 | −index of the comparator mask. | |
| 21 | +explicitly specified. | |
| 27 | 22 | |
| 23 | +For events originating from device, "node" defines its index. | |
| 24 | + | |
| 25 | +Crosspoint PMU events require "xp" (index), "bus" (bus number) | |
| 26 | +and "vc" (virtual channel ID). | |
| 27 | + | |
| 28 | +Crosspoint watchpoint-based events (special "event" value 0xfe) | |
| 29 | +require "xp" and "vc" as as above plus "port" (device port index), | |
| 30 | +"dir" (transmit/receive direction), comparator values ("cmp_l" | |
| 31 | +and "cmp_h") and "mask", being index of the comparator mask. | |
| 28 | 32 | Masks are defined separately from the event description |
| 29 | 33 | (due to limited number of the config values) in the "cmp_mask" |
| 30 | 34 | directory, with first 8 configurable by user and additional |
| @@ -31,6 +31,8 @@ SunXi family · 30 unmodified lines | ||
| 31 | 31 | + User Manual |
| 32 | 32 | http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf |
| 33 | 33 | |
| 34 | + - Next Thing Co GR8 (sun5i) | |
| 35 | + | |
| 34 | 36 | * Dual ARM Cortex-A7 based SoCs |
| 35 | 37 | - Allwinner A20 (sun7i) |
| 36 | 38 | + User Manual |
| @@ -73,4 +75,13 @@ SunXi family · 36 unmodified lines | ||
| 73 | 75 | * Octa ARM Cortex-A7 based SoCs |
| 74 | 76 | - Allwinner A83T |
| 75 | 77 | + Datasheet |
| 76 | − http://dl.linux-sunxi.org/A83T/A83T_datasheet_Revision_1.1.pdf | |
| 78 | + https://github.com/allwinner-zh/documents/raw/master/A83T/A83T_Datasheet_v1.3_20150510.pdf | |
| 79 | + + User Manual | |
| 80 | + https://github.com/allwinner-zh/documents/raw/master/A83T/A83T_User_Manual_v1.5.1_20150513.pdf | |
| 81 | + | |
| 82 | + * Quad ARM Cortex-A53 based SoCs | |
| 83 | + - Allwinner A64 | |
| 84 | + + Datasheet | |
| 85 | + http://dl.linux-sunxi.org/A64/A64_Datasheet_V1.1.pdf | |
| 86 | + + User Manual | |
| 87 | + http://dl.linux-sunxi.org/A64/Allwinner%20A64%20User%20Manual%20v1.0.pdf | |
| @@ -61,3 +61,5 @@ stable kernels. · 60 unmodified lines | ||
| 61 | 61 | | Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | |
| 62 | 62 | | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 | |
| 63 | 63 | | Cavium | ThunderX SMMUv2 | #27704 | N/A | |
| 64 | +| | | | | | |
| 65 | +| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | | |
| @@ -1,7 +0,0 @@ | ||
| 1 | −# List of programs to build | |
| 2 | −hostprogs-y := cfag12864b-example | |
| 3 | − | |
| 4 | −# Tell kbuild to always build the programs | |
| 5 | −always := $(hostprogs-y) | |
| 6 | − | |
| 7 | −HOSTCFLAGS_cfag12864b-example.o += -I$(objtree)/usr/include | |
| @@ -101,5 +101,5 @@ Although the LCD won't get updated until the next refresh time arrives. · 100 unmodified lines | ||
| 101 | 101 | Also, you can mmap the framebuffer: open & mmap, munmap & close... |
| 102 | 102 | which is the best option for most uses. |
| 103 | 103 | |
| 104 | −Check Documentation/auxdisplay/cfag12864b-example.c | |
| 104 | +Check samples/auxdisplay/cfag12864b-example.c | |
| 105 | 105 | for a real working userspace complete program with usage examples. |
| @@ -1,10 +1,6 @@ | ||
| 1 | 1 | 00-INDEX |
| 2 | 2 | - This file |
| 3 | −Makefile | |
| 4 | − - Makefile for gptimers example file. | |
| 5 | 3 | bfin-gpio-notes.txt |
| 6 | 4 | - Notes in developing/using bfin-gpio driver. |
| 7 | 5 | bfin-spi-notes.txt |
| 8 | 6 | - Notes for using bfin spi bus driver. |
| 9 | −gptimers-example.c | |
| 10 | − - gptimers example | |
| @@ -1,5 +0,0 @@ | ||
| 1 | −ifneq ($(CONFIG_BLACKFIN),) | |
| 2 | −ifneq ($(CONFIG_BFIN_GPTIMERS),) | |
| 3 | −obj-m := gptimers-example.o | |
| 4 | −endif | |
| 5 | −endif | |
| @@ -115,7 +115,7 @@ i. Per-queue limits/values exported to the generic layer by the driver · 114 unmodified lines | ||
| 115 | 115 | |
| 116 | 116 | Various parameters that the generic i/o scheduler logic uses are set at |
| 117 | 117 | a per-queue level (e.g maximum request size, maximum number of segments in |
| 118 | −a scatter-gather list, hardsect size) | |
| 118 | +a scatter-gather list, logical block size) | |
| 119 | 119 | |
| 120 | 120 | Some parameters that were earlier available as global arrays indexed by |
| 121 | 121 | major/minor are now directly associated with the queue. Some of these may |
| @@ -156,7 +156,7 @@ Some new queue property settings: · 34 unmodified lines | ||
| 156 | 156 | blk_queue_max_segment_size(q, max_seg_size) |
| 157 | 157 | Maximum size of a clustered segment, 64kB default. |
| 158 | 158 | |
| 159 | − blk_queue_hardsect_size(q, hardsect_size) | |
| 159 | + blk_queue_logical_block_size(q, logical_block_size) | |
| 160 | 160 | Lowest possible sector size that the hardware can operate |
| 161 | 161 | on, 512 bytes default. |
| 162 | 162 | |
| @@ -31,24 +31,25 @@ serve as a convenient shorthand for the implementation of the · 30 unmodified lines | ||
| 31 | 31 | hardware-specific bits for the hypothetical "foo" hardware. |
| 32 | 32 | |
| 33 | 33 | Tying the two halves of this interface together is struct clk_hw, which |
| 34 | −is defined in struct clk_foo and pointed to within struct clk. This | |
| 34 | +is defined in struct clk_foo and pointed to within struct clk_core. This | |
| 35 | 35 | allows for easy navigation between the two discrete halves of the common |
| 36 | 36 | clock interface. |
| 37 | 37 | |
| 38 | 38 | Part 2 - common data structures and api |
| 39 | 39 | |
| 40 | −Below is the common struct clk definition from | |
| 41 | −include/linux/clk-private.h, modified for brevity: | |
| 40 | +Below is the common struct clk_core definition from | |
| 41 | +drivers/clk/clk.c, modified for brevity: | |
| 42 | 42 | |
| 43 | − struct clk { | |
| 43 | + struct clk_core { | |
| 44 | 44 | const char *name; |
| 45 | 45 | const struct clk_ops *ops; |
| 46 | 46 | struct clk_hw *hw; |
| 47 | − char **parent_names; | |
| 48 | − struct clk **parents; | |
| 49 | − struct clk *parent; | |
| 50 | − struct hlist_head children; | |
| 51 | − struct hlist_node child_node; | |
| 47 | + struct module *owner; | |
| 48 | + struct clk_core *parent; | |
| 49 | + const char **parent_names; | |
| 50 | + struct clk_core **parents; | |
| 51 | + u8 num_parents; | |
| 52 | + u8 new_parent_index; | |
| 52 | 53 | ... |
| 53 | 54 | }; |
| 54 | 55 | |
| @@ -56,16 +57,19 @@ The members above make up the core of the clk tree topology. The clk · 1 unmodified line | ||
| 56 | 57 | api itself defines several driver-facing functions which operate on |
| 57 | 58 | struct clk. That api is documented in include/linux/clk.h. |
| 58 | 59 | |
| 59 | −Platforms and devices utilizing the common struct clk use the struct | |
| 60 | −clk_ops pointer in struct clk to perform the hardware-specific parts of | |
| 61 | −the operations defined in clk.h: | |
| 60 | +Platforms and devices utilizing the common struct clk_core use the struct | |
| 61 | +clk_ops pointer in struct clk_core to perform the hardware-specific parts of | |
| 62 | +the operations defined in clk-provider.h: | |
| 62 | 63 | |
| 63 | 64 | struct clk_ops { |
| 64 | 65 | int (*prepare)(struct clk_hw *hw); |
| 65 | 66 | void (*unprepare)(struct clk_hw *hw); |
| 67 | + int (*is_prepared)(struct clk_hw *hw); | |
| 68 | + void (*unprepare_unused)(struct clk_hw *hw); | |
| 66 | 69 | int (*enable)(struct clk_hw *hw); |
| 67 | 70 | void (*disable)(struct clk_hw *hw); |
| 68 | 71 | int (*is_enabled)(struct clk_hw *hw); |
| 72 | + void (*disable_unused)(struct clk_hw *hw); | |
| 69 | 73 | unsigned long (*recalc_rate)(struct clk_hw *hw, |
| 70 | 74 | unsigned long parent_rate); |
| 71 | 75 | long (*round_rate)(struct clk_hw *hw, |
| @@ -84,6 +88,8 @@ the operations defined in clk.h: · 12 unmodified lines | ||
| 84 | 88 | u8 index); |
| 85 | 89 | unsigned long (*recalc_accuracy)(struct clk_hw *hw, |
| 86 | 90 | unsigned long parent_accuracy); |
| 91 | + int (*get_phase)(struct clk_hw *hw); | |
| 92 | + int (*set_phase)(struct clk_hw *hw, int degrees); | |
| 87 | 93 | void (*init)(struct clk_hw *hw); |
| 88 | 94 | int (*debug_init)(struct clk_hw *hw, |
| 89 | 95 | struct dentry *dentry); |
| @@ -91,7 +97,7 @@ the operations defined in clk.h: · 1 unmodified line | ||
| 91 | 97 | |
| 92 | 98 | Part 3 - hardware clk implementations |
| 93 | 99 | |
| 94 | −The strength of the common struct clk comes from its .ops and .hw pointers | |
| 100 | +The strength of the common struct clk_core comes from its .ops and .hw pointers | |
| 95 | 101 | which abstract the details of struct clk from the hardware-specific bits, and |
| 96 | 102 | vice versa. To illustrate consider the simple gateable clk implementation in |
| 97 | 103 | drivers/clk/clk-gate.c: |
| @@ -107,7 +113,7 @@ struct clk_gate contains struct clk_hw hw as well as hardware-specific · 9 unmodified lines | ||
| 107 | 113 | knowledge about which register and bit controls this clk's gating. |
| 108 | 114 | Nothing about clock topology or accounting, such as enable_count or |
| 109 | 115 | notifier_count, is needed here. That is all handled by the common |
| 110 | −framework code and struct clk. | |
| 116 | +framework code and struct clk_core. | |
| 111 | 117 | |
| 112 | 118 | Let's walk through enabling this clk from driver code: |
| 113 | 119 | |
| @@ -139,22 +145,18 @@ static void clk_gate_set_bit(struct clk_gate *gate) · 25 unmodified lines | ||
| 139 | 145 | |
| 140 | 146 | Note that to_clk_gate is defined as: |
| 141 | 147 | |
| 142 | −#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, clk) | |
| 148 | +#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw) | |
| 143 | 149 | |
| 144 | 150 | This pattern of abstraction is used for every clock hardware |
| 145 | 151 | representation. |
| 146 | 152 | |
| 147 | 153 | Part 4 - supporting your own clk hardware |
| 148 | 154 | |
| 149 | −When implementing support for a new type of clock it only necessary to | |
| 155 | +When implementing support for a new type of clock it is only necessary to | |
| 150 | 156 | include the following header: |
| 151 | 157 | |
| 152 | 158 | #include <linux/clk-provider.h> |
| 153 | 159 | |
| 154 | −include/linux/clk.h is included within that header and clk-private.h | |
| 155 | −must never be included from the code which implements the operations for | |
| 156 | −a clock. More on that below in Part 5. | |
| 157 | − | |
| 158 | 160 | To construct a clk hardware structure for your platform you must define |
| 159 | 161 | the following: |
| 160 | 162 | |
| @@ -14,11 +14,17 @@ · 13 unmodified lines | ||
| 14 | 14 | |
| 15 | 15 | import sys |
| 16 | 16 | import os |
| 17 | +import sphinx | |
| 18 | + | |
| 19 | +# Get Sphinx version | |
| 20 | +major, minor, patch = map(int, sphinx.__version__.split(".")) | |
| 21 | + | |
| 17 | 22 | |
| 18 | 23 | # If extensions (or modules to document with autodoc) are in another directory, |
| 19 | 24 | # add these directories to sys.path here. If the directory is relative to the |
| 20 | 25 | # documentation root, use os.path.abspath to make it absolute, like shown here. |
| 21 | 26 | sys.path.insert(0, os.path.abspath('sphinx')) |
| 27 | +from load_config import loadConfig | |
| 22 | 28 | |
| 23 | 29 | # -- General configuration ------------------------------------------------ |
| 24 | 30 | |
| @@ -28,14 +34,13 @@ sys.path.insert(0, os.path.abspath('sphinx')) · 3 unmodified lines | ||
| 28 | 34 | # Add any Sphinx extension module names here, as strings. They can be |
| 29 | 35 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom |
| 30 | 36 | # ones. |
| 31 | −extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include'] | |
| 37 | +extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain'] | |
| 32 | 38 | |
| 33 | −# Gracefully handle missing rst2pdf. | |
| 34 | −try: | |
| 35 | − import rst2pdf | |
| 36 | − extensions += ['rst2pdf.pdfbuilder'] | |
| 37 | −except ImportError: | |
| 38 | − pass | |
| 39 | +# The name of the math extension changed on Sphinx 1.4 | |
| 40 | +if minor > 3: | |
| 41 | + extensions.append("sphinx.ext.imgmath") | |
| 42 | +else: | |
| 43 | + extensions.append("sphinx.ext.pngmath") | |
| 39 | 44 | |
| 40 | 45 | # Add any paths that contain templates here, relative to this directory. |
| 41 | 46 | templates_path = ['_templates'] |
| @@ -252,23 +257,92 @@ htmlhelp_basename = 'TheLinuxKerneldoc' · 210 unmodified lines | ||
| 252 | 257 | |
| 253 | 258 | latex_elements = { |
| 254 | 259 | # The paper size ('letterpaper' or 'a4paper'). |
| 255 | −#'papersize': 'letterpaper', | |
| 260 | +'papersize': 'a4paper', | |
| 256 | 261 | |
| 257 | 262 | # The font size ('10pt', '11pt' or '12pt'). |
| 258 | −#'pointsize': '10pt', | |
| 259 | − | |
| 260 | −# Additional stuff for the LaTeX preamble. | |
| 261 | −#'preamble': '', | |
| 263 | +'pointsize': '8pt', | |
| 262 | 264 | |
| 263 | 265 | # Latex figure (float) alignment |
| 264 | 266 | #'figure_align': 'htbp', |
| 267 | + | |
| 268 | +# Don't mangle with UTF-8 chars | |
| 269 | +'inputenc': '', | |
| 270 | +'utf8extra': '', | |
| 271 | + | |
| 272 | +# Additional stuff for the LaTeX preamble. | |
| 273 | + 'preamble': ''' | |
| 274 | + % Adjust margins | |
| 275 | + \\usepackage[margin=0.5in, top=1in, bottom=1in]{geometry} | |
| 276 | + | |
| 277 | + % Allow generate some pages in landscape | |
| 278 | + \\usepackage{lscape} | |
| 279 | + | |
| 280 | + % Put notes in color and let them be inside a table | |
| 281 | + \\definecolor{NoteColor}{RGB}{204,255,255} | |
| 282 | + \\definecolor{WarningColor}{RGB}{255,204,204} | |
| 283 | + \\definecolor{AttentionColor}{RGB}{255,255,204} | |
| 284 | + \\definecolor{OtherColor}{RGB}{204,204,204} | |
| 285 | + \\newlength{\\mynoticelength} | |
| 286 | + \\makeatletter\\newenvironment{coloredbox}[1]{% | |
| 287 | + \\setlength{\\fboxrule}{1pt} | |
| 288 | + \\setlength{\\fboxsep}{7pt} | |
| 289 | + \\setlength{\\mynoticelength}{\\linewidth} | |
| 290 | + \\addtolength{\\mynoticelength}{-2\\fboxsep} | |
| 291 | + \\addtolength{\\mynoticelength}{-2\\fboxrule} | |
| 292 | + \\begin{lrbox}{\\@tempboxa}\\begin{minipage}{\\mynoticelength}}{\\end{minipage}\\end{lrbox}% | |
| 293 | + \\ifthenelse% | |
| 294 | + {\\equal{\\py@noticetype}{note}}% | |
| 295 | + {\\colorbox{NoteColor}{\\usebox{\\@tempboxa}}}% | |
| 296 | + {% | |
| 297 | + \\ifthenelse% | |
| 298 | + {\\equal{\\py@noticetype}{warning}}% | |
| 299 | + {\\colorbox{WarningColor}{\\usebox{\\@tempboxa}}}% | |
| 300 | + {% | |
| 301 | + \\ifthenelse% | |
| 302 | + {\\equal{\\py@noticetype}{attention}}% | |
| 303 | + {\\colorbox{AttentionColor}{\\usebox{\\@tempboxa}}}% | |
| 304 | + {\\colorbox{OtherColor}{\\usebox{\\@tempboxa}}}% | |
| 305 | + }% | |
| 306 | + }% | |
| 307 | + }\\makeatother | |
| 308 | + | |
| 309 | + \\makeatletter | |
| 310 | + \\renewenvironment{notice}[2]{% | |
| 311 | + \\def\\py@noticetype{#1} | |
| 312 | + \\begin{coloredbox}{#1} | |
| 313 | + \\bf\\it | |
| 314 | + \\par\\strong{#2} | |
| 315 | + \\csname py@noticestart@#1\\endcsname | |
| 316 | + } | |
| 317 | + { | |
| 318 | + \\csname py@noticeend@\\py@noticetype\\endcsname | |
| 319 | + \\end{coloredbox} | |
| 320 | + } | |
| 321 | + \\makeatother | |
| 322 | + | |
| 323 | + % Use some font with UTF-8 support with XeLaTeX | |
| 324 | + \\usepackage{fontspec} | |
| 325 | + \\setsansfont{DejaVu Serif} | |
| 326 | + \\setromanfont{DejaVu Sans} | |
| 327 | + \\setmonofont{DejaVu Sans Mono} | |
| 328 | + | |
| 329 | + % To allow adjusting table sizes | |
| 330 | + \\usepackage{adjustbox} | |
| 331 | + | |
| 332 | + ''' | |
| 265 | 333 | } |
| 266 | 334 | |
| 267 | 335 | # Grouping the document tree into LaTeX files. List of tuples |
| 268 | 336 | # (source start file, target name, title, |
| 269 | 337 | # author, documentclass [howto, manual, or own class]). |
| 270 | 338 | latex_documents = [ |
| 271 | − (master_doc, 'TheLinuxKernel.tex', 'The Linux Kernel Documentation', | |
| 339 | + ('kernel-documentation', 'kernel-documentation.tex', 'The Linux Kernel Documentation', | |
| 340 | + 'The kernel development community', 'manual'), | |
| 341 | + ('development-process/index', 'development-process.tex', 'Linux Kernel Development Documentation', | |
| 342 | + 'The kernel development community', 'manual'), | |
| 343 | + ('gpu/index', 'gpu.tex', 'Linux GPU Driver Developer\'s Guide', | |
| 344 | + 'The kernel development community', 'manual'), | |
| 345 | + ('media/index', 'media.tex', 'Linux Media Subsystem Documentation', | |
| 272 | 346 | 'The kernel development community', 'manual'), |
| 273 | 347 | ] |
| 274 | 348 | |
| @@ -419,3 +493,9 @@ pdf_documents = [ · 144 unmodified lines | ||
| 419 | 493 | # line arguments. |
| 420 | 494 | kerneldoc_bin = '../scripts/kernel-doc' |
| 421 | 495 | kerneldoc_srctree = '..' |
| 496 | + | |
| 497 | +# ------------------------------------------------------------------------------ | |
| 498 | +# Since loadConfig overwrites settings from the global namespace, it has to be | |
| 499 | +# the last statement in the conf.py file | |
| 500 | +# ------------------------------------------------------------------------------ | |
| 501 | +loadConfig(globals()) | |
| @@ -1,10 +1,18 @@ | ||
| 1 | −Copyright 2010 Nicolas Palix <npalix@diku.dk> | |
| 2 | −Copyright 2010 Julia Lawall <julia@diku.dk> | |
| 3 | −Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr> | |
| 1 | +.. Copyright 2010 Nicolas Palix <npalix@diku.dk> | |
| 2 | +.. Copyright 2010 Julia Lawall <julia@diku.dk> | |
| 3 | +.. Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr> | |
| 4 | 4 | |
| 5 | +.. highlight:: none | |
| 5 | 6 | |
| 6 | − Getting Coccinelle | |
| 7 | −~~~~~~~~~~~~~~~~~~~~ | |
| 7 | +Coccinelle | |
| 8 | +========== | |
| 9 | + | |
| 10 | +Coccinelle is a tool for pattern matching and text transformation that has | |
| 11 | +many uses in kernel development, including the application of complex, | |
| 12 | +tree-wide patches and detection of problematic programming patterns. | |
| 13 | + | |
| 14 | +Getting Coccinelle | |
| 15 | +------------------- | |
| 8 | 16 | |
| 9 | 17 | The semantic patches included in the kernel use features and options |
| 10 | 18 | which are provided by Coccinelle version 1.0.0-rc11 and above. |
| @@ -22,24 +30,23 @@ of many distributions, e.g. : · 11 unmodified lines | ||
| 22 | 30 | - NetBSD |
| 23 | 31 | - FreeBSD |
| 24 | 32 | |
| 25 | − | |
| 26 | 33 | You can get the latest version released from the Coccinelle homepage at |
| 27 | 34 | http://coccinelle.lip6.fr/ |
| 28 | 35 | |
| 29 | 36 | Information and tips about Coccinelle are also provided on the wiki |
| 30 | 37 | pages at http://cocci.ekstranet.diku.dk/wiki/doku.php |
| 31 | 38 | |
| 32 | −Once you have it, run the following command: | |
| 39 | +Once you have it, run the following command:: | |
| 33 | 40 | |
| 34 | 41 | ./configure |
| 35 | 42 | make |
| 36 | 43 | |
| 37 | −as a regular user, and install it with | |
| 44 | +as a regular user, and install it with:: | |
| 38 | 45 | |
| 39 | 46 | sudo make install |
| 40 | 47 | |
| 41 | − Supplemental documentation | |
| 42 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 48 | +Supplemental documentation | |
| 49 | +--------------------------- | |
| 43 | 50 | |
| 44 | 51 | For supplemental documentation refer to the wiki: |
| 45 | 52 | |
| @@ -47,49 +54,52 @@ https://bottest.wiki.kernel.org/coccicheck · 1 unmodified line | ||
| 47 | 54 | |
| 48 | 55 | The wiki documentation always refers to the linux-next version of the script. |
| 49 | 56 | |
| 50 | − Using Coccinelle on the Linux kernel | |
| 51 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 57 | +Using Coccinelle on the Linux kernel | |
| 58 | +------------------------------------ | |
| 52 | 59 | |
| 53 | 60 | A Coccinelle-specific target is defined in the top level |
| 54 | −Makefile. This target is named 'coccicheck' and calls the 'coccicheck' | |
| 55 | −front-end in the 'scripts' directory. | |
| 61 | +Makefile. This target is named ``coccicheck`` and calls the ``coccicheck`` | |
| 62 | +front-end in the ``scripts`` directory. | |
| 56 | 63 | |
| 57 | −Four basic modes are defined: patch, report, context, and org. The mode to | |
| 58 | −use is specified by setting the MODE variable with 'MODE=<mode>'. | |
| 64 | +Four basic modes are defined: ``patch``, ``report``, ``context``, and | |
| 65 | +``org``. The mode to use is specified by setting the MODE variable with | |
| 66 | +``MODE=<mode>``. | |
| 59 | 67 | |
| 60 | −'patch' proposes a fix, when possible. | |
| 68 | +- ``patch`` proposes a fix, when possible. | |
| 61 | 69 | |
| 62 | −'report' generates a list in the following format: | |
| 70 | +- ``report`` generates a list in the following format: | |
| 63 | 71 | file:line:column-column: message |
| 64 | 72 | |
| 65 | −'context' highlights lines of interest and their context in a | |
| 66 | −diff-like style.Lines of interest are indicated with '-'. | |
| 73 | +- ``context`` highlights lines of interest and their context in a | |
| 74 | + diff-like style.Lines of interest are indicated with ``-``. | |
| 67 | 75 | |
| 68 | −'org' generates a report in the Org mode format of Emacs. | |
| 76 | +- ``org`` generates a report in the Org mode format of Emacs. | |
| 69 | 77 | |
| 70 | 78 | Note that not all semantic patches implement all modes. For easy use |
| 71 | 79 | of Coccinelle, the default mode is "report". |
| 72 | 80 | |
| 73 | 81 | Two other modes provide some common combinations of these modes. |
| 74 | 82 | |
| 75 | −'chain' tries the previous modes in the order above until one succeeds. | |
| 83 | +- ``chain`` tries the previous modes in the order above until one succeeds. | |
| 84 | + | |
| 85 | +- ``rep+ctxt`` runs successively the report mode and the context mode. | |
| 86 | + It should be used with the C option (described later) | |
| 87 | + which checks the code on a file basis. | |
| 76 | 88 | |
| 77 | −'rep+ctxt' runs successively the report mode and the context mode. | |
| 78 | − It should be used with the C option (described later) | |
| 79 | − which checks the code on a file basis. | |
| 89 | +Examples | |
| 90 | +~~~~~~~~ | |
| 80 | 91 | |
| 81 | −Examples: | |
| 82 | − To make a report for every semantic patch, run the following command: | |
| 92 | +To make a report for every semantic patch, run the following command:: | |
| 83 | 93 | |
| 84 | 94 | make coccicheck MODE=report |
| 85 | 95 | |
| 86 | − To produce patches, run: | |
| 96 | +To produce patches, run:: | |
| 87 | 97 | |
| 88 | 98 | make coccicheck MODE=patch |
| 89 | 99 | |
| 90 | 100 | |
| 91 | 101 | The coccicheck target applies every semantic patch available in the |
| 92 | −sub-directories of 'scripts/coccinelle' to the entire Linux kernel. | |
| 102 | +sub-directories of ``scripts/coccinelle`` to the entire Linux kernel. | |
| 93 | 103 | |
| 94 | 104 | For each semantic patch, a commit message is proposed. It gives a |
| 95 | 105 | description of the problem being checked by the semantic patch, and |
| @@ -99,15 +109,15 @@ As any static code analyzer, Coccinelle produces false · 3 unmodified lines | ||
| 99 | 109 | positives. Thus, reports must be carefully checked, and patches |
| 100 | 110 | reviewed. |
| 101 | 111 | |
| 102 | −To enable verbose messages set the V= variable, for example: | |
| 112 | +To enable verbose messages set the V= variable, for example:: | |
| 103 | 113 | |
| 104 | 114 | make coccicheck MODE=report V=1 |
| 105 | 115 | |
| 106 | − Coccinelle parallelization | |
| 107 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 116 | +Coccinelle parallelization | |
| 117 | +--------------------------- | |
| 108 | 118 | |
| 109 | 119 | By default, coccicheck tries to run as parallel as possible. To change |
| 110 | −the parallelism, set the J= variable. For example, to run across 4 CPUs: | |
| 120 | +the parallelism, set the J= variable. For example, to run across 4 CPUs:: | |
| 111 | 121 | |
| 112 | 122 | make coccicheck MODE=report J=4 |
| 113 | 123 | |
| @@ -115,44 +125,47 @@ As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization, · 1 unmodified line | ||
| 115 | 125 | if support for this is detected you will benefit from parmap parallelization. |
| 116 | 126 | |
| 117 | 127 | When parmap is enabled coccicheck will enable dynamic load balancing by using |
| 118 | −'--chunksize 1' argument, this ensures we keep feeding threads with work | |
| 128 | +``--chunksize 1`` argument, this ensures we keep feeding threads with work | |
| 119 | 129 | one by one, so that we avoid the situation where most work gets done by only |
| 120 | 130 | a few threads. With dynamic load balancing, if a thread finishes early we keep |
| 121 | 131 | feeding it more work. |
| 122 | 132 | |
| 123 | 133 | When parmap is enabled, if an error occurs in Coccinelle, this error |
| 124 | −value is propagated back, the return value of the 'make coccicheck' | |
| 134 | +value is propagated back, the return value of the ``make coccicheck`` | |
| 125 | 135 | captures this return value. |
| 126 | 136 | |
| 127 | − Using Coccinelle with a single semantic patch | |
| 128 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 137 | +Using Coccinelle with a single semantic patch | |
| 138 | +--------------------------------------------- | |
| 129 | 139 | |
| 130 | 140 | The optional make variable COCCI can be used to check a single |
| 131 | 141 | semantic patch. In that case, the variable must be initialized with |
| 132 | 142 | the name of the semantic patch to apply. |
| 133 | 143 | |
| 134 | −For instance: | |
| 144 | +For instance:: | |
| 135 | 145 | |
| 136 | 146 | make coccicheck COCCI=<my_SP.cocci> MODE=patch |
| 137 | −or | |
| 147 | + | |
| 148 | +or:: | |
| 149 | + | |
| 138 | 150 | make coccicheck COCCI=<my_SP.cocci> MODE=report |
| 139 | 151 | |
| 140 | 152 | |
| 141 | − Controlling Which Files are Processed by Coccinelle | |
| 142 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 153 | +Controlling Which Files are Processed by Coccinelle | |
| 154 | +--------------------------------------------------- | |
| 155 | + | |
| 143 | 156 | By default the entire kernel source tree is checked. |
| 144 | 157 | |
| 145 | −To apply Coccinelle to a specific directory, M= can be used. | |
| 146 | −For example, to check drivers/net/wireless/ one may write: | |
| 158 | +To apply Coccinelle to a specific directory, ``M=`` can be used. | |
| 159 | +For example, to check drivers/net/wireless/ one may write:: | |
| 147 | 160 | |
| 148 | 161 | make coccicheck M=drivers/net/wireless/ |
| 149 | 162 | |
| 150 | 163 | To apply Coccinelle on a file basis, instead of a directory basis, the |
| 151 | −following command may be used: | |
| 164 | +following command may be used:: | |
| 152 | 165 | |
| 153 | 166 | make C=1 CHECK="scripts/coccicheck" |
| 154 | 167 | |
| 155 | −To check only newly edited code, use the value 2 for the C flag, i.e. | |
| 168 | +To check only newly edited code, use the value 2 for the C flag, i.e.:: | |
| 156 | 169 | |
| 157 | 170 | make C=2 CHECK="scripts/coccicheck" |
| 158 | 171 | |
| @@ -166,8 +179,8 @@ semantic patch as shown in the previous section. · 7 unmodified lines | ||
| 166 | 179 | The "report" mode is the default. You can select another one with the |
| 167 | 180 | MODE variable explained above. |
| 168 | 181 | |
| 169 | − Debugging Coccinelle SmPL patches | |
| 170 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 182 | +Debugging Coccinelle SmPL patches | |
| 183 | +--------------------------------- | |
| 171 | 184 | |
| 172 | 185 | Using coccicheck is best as it provides in the spatch command line |
| 173 | 186 | include options matching the options used when we compile the kernel. |
| @@ -177,8 +190,8 @@ manually run Coccinelle with debug options added. · 3 unmodified lines | ||
| 177 | 190 | Alternatively you can debug running Coccinelle against SmPL patches |
| 178 | 191 | by asking for stderr to be redirected to stderr, by default stderr |
| 179 | 192 | is redirected to /dev/null, if you'd like to capture stderr you |
| 180 | −can specify the DEBUG_FILE="file.txt" option to coccicheck. For | |
| 181 | −instance: | |
| 193 | +can specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For | |
| 194 | +instance:: | |
| 182 | 195 | |
| 183 | 196 | rm -f cocci.err |
| 184 | 197 | make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err |
| @@ -186,7 +199,7 @@ instance: · 1 unmodified line | ||
| 186 | 199 | |
| 187 | 200 | You can use SPFLAGS to add debugging flags, for instance you may want to |
| 188 | 201 | add both --profile --show-trying to SPFLAGS when debugging. For instance |
| 189 | −you may want to use: | |
| 202 | +you may want to use:: | |
| 190 | 203 | |
| 191 | 204 | rm -f err.log |
| 192 | 205 | export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci |
| @@ -198,24 +211,24 @@ work. · 5 unmodified lines | ||
| 198 | 211 | |
| 199 | 212 | DEBUG_FILE support is only supported when using coccinelle >= 1.2. |
| 200 | 213 | |
| 201 | − .cocciconfig support | |
| 202 | −~~~~~~~~~~~~~~~~~~~~~~ | |
| 214 | +.cocciconfig support | |
| 215 | +-------------------- | |
| 203 | 216 | |
| 204 | 217 | Coccinelle supports reading .cocciconfig for default Coccinelle options that |
| 205 | 218 | should be used every time spatch is spawned, the order of precedence for |
| 206 | 219 | variables for .cocciconfig is as follows: |
| 207 | 220 | |
| 208 | − o Your current user's home directory is processed first | |
| 209 | − o Your directory from which spatch is called is processed next | |
| 210 | − o The directory provided with the --dir option is processed last, if used | |
| 221 | +- Your current user's home directory is processed first | |
| 222 | +- Your directory from which spatch is called is processed next | |
| 223 | +- The directory provided with the --dir option is processed last, if used | |
| 211 | 224 | |
| 212 | 225 | Since coccicheck runs through make, it naturally runs from the kernel |
| 213 | 226 | proper dir, as such the second rule above would be implied for picking up a |
| 214 | −.cocciconfig when using 'make coccicheck'. | |
| 227 | +.cocciconfig when using ``make coccicheck``. | |
| 215 | 228 | |
| 216 | −'make coccicheck' also supports using M= targets.If you do not supply | |
| 229 | +``make coccicheck`` also supports using M= targets.If you do not supply | |
| 217 | 230 | any M= target, it is assumed you want to target the entire kernel. |
| 218 | −The kernel coccicheck script has: | |
| 231 | +The kernel coccicheck script has:: | |
| 219 | 232 | |
| 220 | 233 | if [ "$KBUILD_EXTMOD" = "" ] ; then |
| 221 | 234 | OPTIONS="--dir $srctree $COCCIINCLUDE" |
| @@ -235,12 +248,12 @@ override any of the kernel's .coccicheck's settings using SPFLAGS. · 13 unmodified lines | ||
| 235 | 248 | |
| 236 | 249 | We help Coccinelle when used against Linux with a set of sensible defaults |
| 237 | 250 | options for Linux with our own Linux .cocciconfig. This hints to coccinelle |
| 238 | −git can be used for 'git grep' queries over coccigrep. A timeout of 200 | |
| 251 | +git can be used for ``git grep`` queries over coccigrep. A timeout of 200 | |
| 239 | 252 | seconds should suffice for now. |
| 240 | 253 | |
| 241 | 254 | The options picked up by coccinelle when reading a .cocciconfig do not appear |
| 242 | 255 | as arguments to spatch processes running on your system, to confirm what |
| 243 | −options will be used by Coccinelle run: | |
| 256 | +options will be used by Coccinelle run:: | |
| 244 | 257 | |
| 245 | 258 | spatch --print-options-only |
| 246 | 259 | |
| @@ -252,219 +265,227 @@ carries its own .cocciconfig, you will need to use SPFLAGS to use idutils if · 5 unmodified lines | ||
| 252 | 265 | desired. See below section "Additional flags" for more details on how to use |
| 253 | 266 | idutils. |
| 254 | 267 | |
| 255 | − Additional flags | |
| 256 | −~~~~~~~~~~~~~~~~~~ | |
| 268 | +Additional flags | |
| 269 | +---------------- | |
| 257 | 270 | |
| 258 | 271 | Additional flags can be passed to spatch through the SPFLAGS |
| 259 | 272 | variable. This works as Coccinelle respects the last flags |
| 260 | −given to it when options are in conflict. | |
| 273 | +given to it when options are in conflict. :: | |
| 261 | 274 | |
| 262 | 275 | make SPFLAGS=--use-glimpse coccicheck |
| 263 | 276 | |
| 264 | 277 | Coccinelle supports idutils as well but requires coccinelle >= 1.0.6. |
| 265 | 278 | When no ID file is specified coccinelle assumes your ID database file |
| 266 | 279 | is in the file .id-utils.index on the top level of the kernel, coccinelle |
| 267 | −carries a script scripts/idutils_index.sh which creates the database with | |
| 280 | +carries a script scripts/idutils_index.sh which creates the database with:: | |
| 268 | 281 | |
| 269 | 282 | mkid -i C --output .id-utils.index |
| 270 | 283 | |
| 271 | 284 | If you have another database filename you can also just symlink with this |
| 272 | −name. | |
| 285 | +name. :: | |
| 273 | 286 | |
| 274 | 287 | make SPFLAGS=--use-idutils coccicheck |
| 275 | 288 | |
| 276 | 289 | Alternatively you can specify the database filename explicitly, for |
| 277 | −instance: | |
| 290 | +instance:: | |
| 278 | 291 | |
| 279 | 292 | make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck |
| 280 | 293 | |
| 281 | −See spatch --help to learn more about spatch options. | |
| 294 | +See ``spatch --help`` to learn more about spatch options. | |
| 282 | 295 | |
| 283 | −Note that the '--use-glimpse' and '--use-idutils' options | |
| 296 | +Note that the ``--use-glimpse`` and ``--use-idutils`` options | |
| 284 | 297 | require external tools for indexing the code. None of them is |
| 285 | 298 | thus active by default. However, by indexing the code with |
| 286 | 299 | one of these tools, and according to the cocci file used, |
| 287 | 300 | spatch could proceed the entire code base more quickly. |
| 288 | 301 | |
| 289 | − SmPL patch specific options | |
| 290 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 302 | +SmPL patch specific options | |
| 303 | +--------------------------- | |
| 291 | 304 | |
| 292 | 305 | SmPL patches can have their own requirements for options passed |
| 293 | 306 | to Coccinelle. SmPL patch specific options can be provided by |
| 294 | −providing them at the top of the SmPL patch, for instance: | |
| 307 | +providing them at the top of the SmPL patch, for instance:: | |
| 295 | 308 | |
| 296 | −// Options: --no-includes --include-headers | |
| 309 | + // Options: --no-includes --include-headers | |
| 297 | 310 | |
| 298 | − SmPL patch Coccinelle requirements | |
| 299 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 311 | +SmPL patch Coccinelle requirements | |
| 312 | +---------------------------------- | |
| 300 | 313 | |
| 301 | 314 | As Coccinelle features get added some more advanced SmPL patches |
| 302 | 315 | may require newer versions of Coccinelle. If an SmPL patch requires |
| 303 | 316 | at least a version of Coccinelle, this can be specified as follows, |
| 304 | −as an example if requiring at least Coccinelle >= 1.0.5: | |
| 317 | +as an example if requiring at least Coccinelle >= 1.0.5:: | |
| 305 | 318 | |
| 306 | −// Requires: 1.0.5 | |
| 319 | + // Requires: 1.0.5 | |
| 307 | 320 | |
| 308 | − Proposing new semantic patches | |
| 309 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 321 | +Proposing new semantic patches | |
| 322 | +------------------------------- | |
| 310 | 323 | |
| 311 | 324 | New semantic patches can be proposed and submitted by kernel |
| 312 | 325 | developers. For sake of clarity, they should be organized in the |
| 313 | −sub-directories of 'scripts/coccinelle/'. | |
| 326 | +sub-directories of ``scripts/coccinelle/``. | |
| 314 | 327 | |
| 315 | 328 | |
| 316 | − Detailed description of the 'report' mode | |
| 317 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 329 | +Detailed description of the ``report`` mode | |
| 330 | +------------------------------------------- | |
| 331 | + | |
| 332 | +``report`` generates a list in the following format:: | |
| 318 | 333 | |
| 319 | −'report' generates a list in the following format: | |
| 320 | 334 | file:line:column-column: message |
| 321 | 335 | |
| 322 | −Example: | |
| 336 | +Example | |
| 337 | +~~~~~~~ | |
| 323 | 338 | |
| 324 | −Running | |
| 339 | +Running:: | |
| 325 | 340 | |
| 326 | 341 | make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci |
| 327 | 342 | |
| 328 | −will execute the following part of the SmPL script. | |
| 343 | +will execute the following part of the SmPL script:: | |
| 329 | 344 | |
| 330 | −<smpl> | |
| 331 | −@r depends on !context && !patch && (org || report)@ | |
| 332 | −expression x; | |
| 333 | −position p; | |
| 334 | −@@ | |
| 345 | + <smpl> | |
| 346 | + @r depends on !context && !patch && (org || report)@ | |
| 347 | + expression x; | |
| 348 | + position p; | |
| 349 | + @@ | |
| 335 | 350 | |
| 336 | − ERR_PTR@p(PTR_ERR(x)) | |
| 351 | + ERR_PTR@p(PTR_ERR(x)) | |
| 337 | 352 | |
| 338 | −@script:python depends on report@ | |
| 339 | −p << r.p; | |
| 340 | −x << r.x; | |
| 341 | −@@ | |
| 353 | + @script:python depends on report@ | |
| 354 | + p << r.p; | |
| 355 | + x << r.x; | |
| 356 | + @@ | |
| 342 | 357 | |
| 343 | −msg="ERR_CAST can be used with %s" % (x) | |
| 344 | −coccilib.report.print_report(p[0], msg) | |
| 345 | −</smpl> | |
| 358 | + msg="ERR_CAST can be used with %s" % (x) | |
| 359 | + coccilib.report.print_report(p[0], msg) | |
| 360 | + </smpl> | |
| 346 | 361 | |
| 347 | 362 | This SmPL excerpt generates entries on the standard output, as |
| 348 | −illustrated below: | |
| 363 | +illustrated below:: | |
| 349 | 364 | |
| 350 | −/home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg | |
| 351 | −/home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth | |
| 352 | −/home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg | |
| 365 | + /home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg | |
| 366 | + /home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth | |
| 367 | + /home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg | |
| 353 | 368 | |
| 354 | 369 | |
| 355 | − Detailed description of the 'patch' mode | |
| 356 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 370 | +Detailed description of the ``patch`` mode | |
| 371 | +------------------------------------------ | |
| 357 | 372 | |
| 358 | −When the 'patch' mode is available, it proposes a fix for each problem | |
| 373 | +When the ``patch`` mode is available, it proposes a fix for each problem | |
| 359 | 374 | identified. |
| 360 | 375 | |
| 361 | −Example: | |
| 376 | +Example | |
| 377 | +~~~~~~~ | |
| 378 | + | |
| 379 | +Running:: | |
| 362 | 380 | |
| 363 | −Running | |
| 364 | 381 | make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci |
| 365 | 382 | |
| 366 | −will execute the following part of the SmPL script. | |
| 383 | +will execute the following part of the SmPL script:: | |
| 367 | 384 | |
| 368 | −<smpl> | |
| 369 | −@ depends on !context && patch && !org && !report @ | |
| 370 | −expression x; | |
| 371 | −@@ | |
| 385 | + <smpl> | |
| 386 | + @ depends on !context && patch && !org && !report @ | |
| 387 | + expression x; | |
| 388 | + @@ | |
| 372 | 389 | |
| 373 | −- ERR_PTR(PTR_ERR(x)) | |
| 374 | −+ ERR_CAST(x) | |
| 375 | −</smpl> | |
| 390 | + - ERR_PTR(PTR_ERR(x)) | |
| 391 | + + ERR_CAST(x) | |
| 392 | + </smpl> | |
| 376 | 393 | |
| 377 | 394 | This SmPL excerpt generates patch hunks on the standard output, as |
| 378 | −illustrated below: | |
| 395 | +illustrated below:: | |
| 379 | 396 | |
| 380 | −diff -u -p a/crypto/ctr.c b/crypto/ctr.c | |
| 381 | −--- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 | |
| 382 | −+++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200 | |
| 383 | −@@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct | |
| 397 | + diff -u -p a/crypto/ctr.c b/crypto/ctr.c | |
| 398 | + --- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 | |
| 399 | + +++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200 | |
| 400 | + @@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct | |
| 384 | 401 | alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, |
| 385 | 402 | CRYPTO_ALG_TYPE_MASK); |
| 386 | 403 | if (IS_ERR(alg)) |
| 387 | −- return ERR_PTR(PTR_ERR(alg)); | |
| 388 | −+ return ERR_CAST(alg); | |
| 389 | − | |
| 404 | + - return ERR_PTR(PTR_ERR(alg)); | |
| 405 | + + return ERR_CAST(alg); | |
| 406 | + | |
| 390 | 407 | /* Block size must be >= 4 bytes. */ |
| 391 | 408 | err = -EINVAL; |
| 392 | 409 | |
| 393 | − Detailed description of the 'context' mode | |
| 394 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 410 | +Detailed description of the ``context`` mode | |
| 411 | +-------------------------------------------- | |
| 395 | 412 | |
| 396 | −'context' highlights lines of interest and their context | |
| 413 | +``context`` highlights lines of interest and their context | |
| 397 | 414 | in a diff-like style. |
| 398 | 415 | |
| 399 | −NOTE: The diff-like output generated is NOT an applicable patch. The | |
| 400 | − intent of the 'context' mode is to highlight the important lines | |
| 401 | − (annotated with minus, '-') and gives some surrounding context | |
| 416 | + **NOTE**: The diff-like output generated is NOT an applicable patch. The | |
| 417 | + intent of the ``context`` mode is to highlight the important lines | |
| 418 | + (annotated with minus, ``-``) and gives some surrounding context | |
| 402 | 419 | lines around. This output can be used with the diff mode of |
| 403 | 420 | Emacs to review the code. |
| 404 | 421 | |
| 405 | −Example: | |
| 422 | +Example | |
| 423 | +~~~~~~~ | |
| 424 | + | |
| 425 | +Running:: | |
| 406 | 426 | |
| 407 | −Running | |
| 408 | 427 | make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci |
| 409 | 428 | |
| 410 | −will execute the following part of the SmPL script. | |
| 429 | +will execute the following part of the SmPL script:: | |
| 411 | 430 | |
| 412 | −<smpl> | |
| 413 | −@ depends on context && !patch && !org && !report@ | |
| 414 | −expression x; | |
| 415 | −@@ | |
| 431 | + <smpl> | |
| 432 | + @ depends on context && !patch && !org && !report@ | |
| 433 | + expression x; | |
| 434 | + @@ | |
| 416 | 435 | |
| 417 | −* ERR_PTR(PTR_ERR(x)) | |
| 418 | −</smpl> | |
| 436 | + * ERR_PTR(PTR_ERR(x)) | |
| 437 | + </smpl> | |
| 419 | 438 | |
| 420 | 439 | This SmPL excerpt generates diff hunks on the standard output, as |
| 421 | −illustrated below: | |
| 440 | +illustrated below:: | |
| 422 | 441 | |
| 423 | −diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing | |
| 424 | −--- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 | |
| 425 | −+++ /tmp/nothing | |
| 426 | −@@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct | |
| 442 | + diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing | |
| 443 | + --- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 | |
| 444 | + +++ /tmp/nothing | |
| 445 | + @@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct | |
| 427 | 446 | alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, |
| 428 | 447 | CRYPTO_ALG_TYPE_MASK); |
| 429 | 448 | if (IS_ERR(alg)) |
| 430 | −- return ERR_PTR(PTR_ERR(alg)); | |
| 431 | − | |
| 449 | + - return ERR_PTR(PTR_ERR(alg)); | |
| 450 | + | |
| 432 | 451 | /* Block size must be >= 4 bytes. */ |
| 433 | 452 | err = -EINVAL; |
| 434 | 453 | |
| 435 | − Detailed description of the 'org' mode | |
| 436 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 454 | +Detailed description of the ``org`` mode | |
| 455 | +---------------------------------------- | |
| 456 | + | |
| 457 | +``org`` generates a report in the Org mode format of Emacs. | |
| 437 | 458 | |
| 438 | −'org' generates a report in the Org mode format of Emacs. | |
| 459 | +Example | |
| 460 | +~~~~~~~ | |
| 439 | 461 | |
| 440 | −Example: | |
| 462 | +Running:: | |
| 441 | 463 | |
| 442 | −Running | |
| 443 | 464 | make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci |
| 444 | 465 | |
| 445 | −will execute the following part of the SmPL script. | |
| 466 | +will execute the following part of the SmPL script:: | |
| 446 | 467 | |
| 447 | −<smpl> | |
| 448 | −@r depends on !context && !patch && (org || report)@ | |
| 449 | −expression x; | |
| 450 | −position p; | |
| 451 | −@@ | |
| 468 | + <smpl> | |
| 469 | + @r depends on !context && !patch && (org || report)@ | |
| 470 | + expression x; | |
| 471 | + position p; | |
| 472 | + @@ | |
| 452 | 473 | |
| 453 | − ERR_PTR@p(PTR_ERR(x)) | |
| 474 | + ERR_PTR@p(PTR_ERR(x)) | |
| 454 | 475 | |
| 455 | −@script:python depends on org@ | |
| 456 | −p << r.p; | |
| 457 | −x << r.x; | |
| 458 | −@@ | |
| 476 | + @script:python depends on org@ | |
| 477 | + p << r.p; | |
| 478 | + x << r.x; | |
| 479 | + @@ | |
| 459 | 480 | |
| 460 | −msg="ERR_CAST can be used with %s" % (x) | |
| 461 | −msg_safe=msg.replace("[","@(").replace("]",")") | |
| 462 | −coccilib.org.print_todo(p[0], msg_safe) | |
| 463 | −</smpl> | |
| 481 | + msg="ERR_CAST can be used with %s" % (x) | |
| 482 | + msg_safe=msg.replace("[","@(").replace("]",")") | |
| 483 | + coccilib.org.print_todo(p[0], msg_safe) | |
| 484 | + </smpl> | |
| 464 | 485 | |
| 465 | 486 | This SmPL excerpt generates Org entries on the standard output, as |
| 466 | −illustrated below: | |
| 487 | +illustrated below:: | |
| 467 | 488 | |
| 468 | −* TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]] | |
| 469 | −* TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]] | |
| 470 | −* TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]] | |
| 489 | + * TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]] | |
| 490 | + * TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]] | |
| 491 | + * TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]] | |
| @@ -0,0 +1,256 @@ | ||
| 1 | +Using gcov with the Linux kernel | |
| 2 | +================================ | |
| 3 | + | |
| 4 | +gcov profiling kernel support enables the use of GCC's coverage testing | |
| 5 | +tool gcov_ with the Linux kernel. Coverage data of a running kernel | |
| 6 | +is exported in gcov-compatible format via the "gcov" debugfs directory. | |
| 7 | +To get coverage data for a specific file, change to the kernel build | |
| 8 | +directory and use gcov with the ``-o`` option as follows (requires root):: | |
| 9 | + | |
| 10 | + # cd /tmp/linux-out | |
| 11 | + # gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel spinlock.c | |
| 12 | + | |
| 13 | +This will create source code files annotated with execution counts | |
| 14 | +in the current directory. In addition, graphical gcov front-ends such | |
| 15 | +as lcov_ can be used to automate the process of collecting data | |
| 16 | +for the entire kernel and provide coverage overviews in HTML format. | |
| 17 | + | |
| 18 | +Possible uses: | |
| 19 | + | |
| 20 | +* debugging (has this line been reached at all?) | |
| 21 | +* test improvement (how do I change my test to cover these lines?) | |
| 22 | +* minimizing kernel configurations (do I need this option if the | |
| 23 | + associated code is never run?) | |
| 24 | + | |
| 25 | +.. _gcov: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html | |
| 26 | +.. _lcov: http://ltp.sourceforge.net/coverage/lcov.php | |
| 27 | + | |
| 28 | + | |
| 29 | +Preparation | |
| 30 | +----------- | |
| 31 | + | |
| 32 | +Configure the kernel with:: | |
| 33 | + | |
| 34 | + CONFIG_DEBUG_FS=y | |
| 35 | + CONFIG_GCOV_KERNEL=y | |
| 36 | + | |
| 37 | +select the gcc's gcov format, default is autodetect based on gcc version:: | |
| 38 | + | |
| 39 | + CONFIG_GCOV_FORMAT_AUTODETECT=y | |
| 40 | + | |
| 41 | +and to get coverage data for the entire kernel:: | |
| 42 | + | |
| 43 | + CONFIG_GCOV_PROFILE_ALL=y | |
| 44 | + | |
| 45 | +Note that kernels compiled with profiling flags will be significantly | |
| 46 | +larger and run slower. Also CONFIG_GCOV_PROFILE_ALL may not be supported | |
| 47 | +on all architectures. | |
| 48 | + | |
| 49 | +Profiling data will only become accessible once debugfs has been | |
| 50 | +mounted:: | |
| 51 | + | |
| 52 | + mount -t debugfs none /sys/kernel/debug | |
| 53 | + | |
| 54 | + | |
| 55 | +Customization | |
| 56 | +------------- | |
| 57 | + | |
| 58 | +To enable profiling for specific files or directories, add a line | |
| 59 | +similar to the following to the respective kernel Makefile: | |
| 60 | + | |
| 61 | +- For a single file (e.g. main.o):: | |
| 62 | + | |
| 63 | + GCOV_PROFILE_main.o := y | |
| 64 | + | |
| 65 | +- For all files in one directory:: | |
| 66 | + | |
| 67 | + GCOV_PROFILE := y | |
| 68 | + | |
| 69 | +To exclude files from being profiled even when CONFIG_GCOV_PROFILE_ALL | |
| 70 | +is specified, use:: | |
| 71 | + | |
| 72 | + GCOV_PROFILE_main.o := n | |
| 73 | + | |
| 74 | +and:: | |
| 75 | + | |
| 76 | + GCOV_PROFILE := n | |
| 77 | + | |
| 78 | +Only files which are linked to the main kernel image or are compiled as | |
| 79 | +kernel modules are supported by this mechanism. | |
| 80 | + | |
| 81 | + | |
| 82 | +Files | |
| 83 | +----- | |
| 84 | + | |
| 85 | +The gcov kernel support creates the following files in debugfs: | |
| 86 | + | |
| 87 | +``/sys/kernel/debug/gcov`` | |
| 88 | + Parent directory for all gcov-related files. | |
| 89 | + | |
| 90 | +``/sys/kernel/debug/gcov/reset`` | |
| 91 | + Global reset file: resets all coverage data to zero when | |
| 92 | + written to. | |
| 93 | + | |
| 94 | +``/sys/kernel/debug/gcov/path/to/compile/dir/file.gcda`` | |
| 95 | + The actual gcov data file as understood by the gcov | |
| 96 | + tool. Resets file coverage data to zero when written to. | |
| 97 | + | |
| 98 | +``/sys/kernel/debug/gcov/path/to/compile/dir/file.gcno`` | |
| 99 | + Symbolic link to a static data file required by the gcov | |
| 100 | + tool. This file is generated by gcc when compiling with | |
| 101 | + option ``-ftest-coverage``. | |
| 102 | + | |
| 103 | + | |
| 104 | +Modules | |
| 105 | +------- | |
| 106 | + | |
| 107 | +Kernel modules may contain cleanup code which is only run during | |
| 108 | +module unload time. The gcov mechanism provides a means to collect | |
| 109 | +coverage data for such code by keeping a copy of the data associated | |
| 110 | +with the unloaded module. This data remains available through debugfs. | |
| 111 | +Once the module is loaded again, the associated coverage counters are | |
| 112 | +initialized with the data from its previous instantiation. | |
| 113 | + | |
| 114 | +This behavior can be deactivated by specifying the gcov_persist kernel | |
| 115 | +parameter:: | |
| 116 | + | |
| 117 | + gcov_persist=0 | |
| 118 | + | |
| 119 | +At run-time, a user can also choose to discard data for an unloaded | |
| 120 | +module by writing to its data file or the global reset file. | |
| 121 | + | |
| 122 | + | |
| 123 | +Separated build and test machines | |
| 124 | +--------------------------------- | |
| 125 | + | |
| 126 | +The gcov kernel profiling infrastructure is designed to work out-of-the | |
| 127 | +box for setups where kernels are built and run on the same machine. In | |
| 128 | +cases where the kernel runs on a separate machine, special preparations | |
| 129 | +must be made, depending on where the gcov tool is used: | |
| 130 | + | |
| 131 | +a) gcov is run on the TEST machine | |
| 132 | + | |
| 133 | + The gcov tool version on the test machine must be compatible with the | |
| 134 | + gcc version used for kernel build. Also the following files need to be | |
| 135 | + copied from build to test machine: | |
| 136 | + | |
| 137 | + from the source tree: | |
| 138 | + - all C source files + headers | |
| 139 | + | |
| 140 | + from the build tree: | |
| 141 | + - all C source files + headers | |
| 142 | + - all .gcda and .gcno files | |
| 143 | + - all links to directories | |
| 144 | + | |
| 145 | + It is important to note that these files need to be placed into the | |
| 146 | + exact same file system location on the test machine as on the build | |
| 147 | + machine. If any of the path components is symbolic link, the actual | |
| 148 | + directory needs to be used instead (due to make's CURDIR handling). | |
| 149 | + | |
| 150 | +b) gcov is run on the BUILD machine | |
| 151 | + | |
| 152 | + The following files need to be copied after each test case from test | |
| 153 | + to build machine: | |
| 154 | + | |
| 155 | + from the gcov directory in sysfs: | |
| 156 | + - all .gcda files | |
| 157 | + - all links to .gcno files | |
| 158 | + | |
| 159 | + These files can be copied to any location on the build machine. gcov | |
| 160 | + must then be called with the -o option pointing to that directory. | |
| 161 | + | |
| 162 | + Example directory setup on the build machine:: | |
| 163 | + | |
| 164 | + /tmp/linux: kernel source tree | |
| 165 | + /tmp/out: kernel build directory as specified by make O= | |
| 166 | + /tmp/coverage: location of the files copied from the test machine | |
| 167 | + | |
| 168 | + [user@build] cd /tmp/out | |
| 169 | + [user@build] gcov -o /tmp/coverage/tmp/out/init main.c | |
| 170 | + | |
| 171 | + | |
| 172 | +Troubleshooting | |
| 173 | +--------------- | |
| 174 | + | |
| 175 | +Problem | |
| 176 | + Compilation aborts during linker step. | |
| 177 | + | |
| 178 | +Cause | |
| 179 | + Profiling flags are specified for source files which are not | |
| 180 | + linked to the main kernel or which are linked by a custom | |
| 181 | + linker procedure. | |
| 182 | + | |
| 183 | +Solution | |
| 184 | + Exclude affected source files from profiling by specifying | |
| 185 | + ``GCOV_PROFILE := n`` or ``GCOV_PROFILE_basename.o := n`` in the | |
| 186 | + corresponding Makefile. | |
| 187 | + | |
| 188 | +Problem | |
| 189 | + Files copied from sysfs appear empty or incomplete. | |
| 190 | + | |
| 191 | +Cause | |
| 192 | + Due to the way seq_file works, some tools such as cp or tar | |
| 193 | + may not correctly copy files from sysfs. | |
| 194 | + | |
| 195 | +Solution | |
| 196 | + Use ``cat``' to read ``.gcda`` files and ``cp -d`` to copy links. | |
| 197 | + Alternatively use the mechanism shown in Appendix B. | |
| 198 | + | |
| 199 | + | |
| 200 | +Appendix A: gather_on_build.sh | |
| 201 | +------------------------------ | |
| 202 | + | |
| 203 | +Sample script to gather coverage meta files on the build machine | |
| 204 | +(see 6a):: | |
| 205 | + | |
| 206 | + #!/bin/bash | |
| 207 | + | |
| 208 | + KSRC=$1 | |
| 209 | + KOBJ=$2 | |
| 210 | + DEST=$3 | |
| 211 | + | |
| 212 | + if [ -z "$KSRC" ] || [ -z "$KOBJ" ] || [ -z "$DEST" ]; then | |
| 213 | + echo "Usage: $0 <ksrc directory> <kobj directory> <output.tar.gz>" >&2 | |
| 214 | + exit 1 | |
| 215 | + fi | |
| 216 | + | |
| 217 | + KSRC=$(cd $KSRC; printf "all:\n\t@echo \${CURDIR}\n" | make -f -) | |
| 218 | + KOBJ=$(cd $KOBJ; printf "all:\n\t@echo \${CURDIR}\n" | make -f -) | |
| 219 | + | |
| 220 | + find $KSRC $KOBJ \( -name '*.gcno' -o -name '*.[ch]' -o -type l \) -a \ | |
| 221 | + -perm /u+r,g+r | tar cfz $DEST -P -T - | |
| 222 | + | |
| 223 | + if [ $? -eq 0 ] ; then | |
| 224 | + echo "$DEST successfully created, copy to test system and unpack with:" | |
| 225 | + echo " tar xfz $DEST -P" | |
| 226 | + else | |
| 227 | + echo "Could not create file $DEST" | |
| 228 | + fi | |
| 229 | + | |
| 230 | + | |
| 231 | +Appendix B: gather_on_test.sh | |
| 232 | +----------------------------- | |
| 233 | + | |
| 234 | +Sample script to gather coverage data files on the test machine | |
| 235 | +(see 6b):: | |
| 236 | + | |
| 237 | + #!/bin/bash -e | |
| 238 | + | |
| 239 | + DEST=$1 | |
| 240 | + GCDA=/sys/kernel/debug/gcov | |
| 241 | + | |
| 242 | + if [ -z "$DEST" ] ; then | |
| 243 | + echo "Usage: $0 <output.tar.gz>" >&2 | |
| 244 | + exit 1 | |
| 245 | + fi | |
| 246 | + | |
| 247 | + TEMPDIR=$(mktemp -d) | |
| 248 | + echo Collecting data.. | |
| 249 | + find $GCDA -type d -exec mkdir -p $TEMPDIR/\{\} \; | |
| 250 | + find $GCDA -name '*.gcda' -exec sh -c 'cat < $0 > '$TEMPDIR'/$0' {} \; | |
| 251 | + find $GCDA -name '*.gcno' -exec sh -c 'cp -d $0 '$TEMPDIR'/$0' {} \; | |
| 252 | + tar czf $DEST -C $TEMPDIR sys | |
| 253 | + rm -rf $TEMPDIR | |
| 254 | + | |
| 255 | + echo "$DEST successfully created, copy to build system and unpack with:" | |
| 256 | + echo " tar xfz $DEST" | |
| @@ -1,3 +1,5 @@ | ||
| 1 | +.. highlight:: none | |
| 2 | + | |
| 1 | 3 | Debugging kernel and modules via gdb |
| 2 | 4 | ==================================== |
| 3 | 5 | |
| @@ -13,54 +15,58 @@ be transferred to the other gdb stubs as well. · 9 unmodified lines | ||
| 13 | 15 | Requirements |
| 14 | 16 | ------------ |
| 15 | 17 | |
| 16 | − o gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true | |
| 17 | − for distributions) | |
| 18 | +- gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true | |
| 19 | + for distributions) | |
| 18 | 20 | |
| 19 | 21 | |
| 20 | 22 | Setup |
| 21 | 23 | ----- |
| 22 | 24 | |
| 23 | − o Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and | |
| 24 | − www.qemu.org for more details). For cross-development, | |
| 25 | − http://landley.net/aboriginal/bin keeps a pool of machine images and | |
| 26 | − toolchains that can be helpful to start from. | |
| 25 | +- Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and | |
| 26 | + www.qemu.org for more details). For cross-development, | |
| 27 | + http://landley.net/aboriginal/bin keeps a pool of machine images and | |
| 28 | + toolchains that can be helpful to start from. | |
| 27 | 29 | |
| 28 | − o Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave | |
| 29 | − CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports | |
| 30 | − CONFIG_FRAME_POINTER, keep it enabled. | |
| 30 | +- Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave | |
| 31 | + CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports | |
| 32 | + CONFIG_FRAME_POINTER, keep it enabled. | |
| 31 | 33 | |
| 32 | − o Install that kernel on the guest. | |
| 34 | +- Install that kernel on the guest. | |
| 35 | + Alternatively, QEMU allows to boot the kernel directly using -kernel, | |
| 36 | + -append, -initrd command line switches. This is generally only useful if | |
| 37 | + you do not depend on modules. See QEMU documentation for more details on | |
| 38 | + this mode. | |
| 33 | 39 | |
| 34 | − Alternatively, QEMU allows to boot the kernel directly using -kernel, | |
| 35 | − -append, -initrd command line switches. This is generally only useful if | |
| 36 | − you do not depend on modules. See QEMU documentation for more details on | |
| 37 | − this mode. | |
| 40 | +- Enable the gdb stub of QEMU/KVM, either | |
| 38 | 41 | |
| 39 | − o Enable the gdb stub of QEMU/KVM, either | |
| 40 | 42 | - at VM startup time by appending "-s" to the QEMU command line |
| 41 | − or | |
| 43 | + | |
| 44 | + or | |
| 45 | + | |
| 42 | 46 | - during runtime by issuing "gdbserver" from the QEMU monitor |
| 43 | 47 | console |
| 44 | 48 | |
| 45 | − o cd /path/to/linux-build | |
| 49 | +- cd /path/to/linux-build | |
| 46 | 50 | |
| 47 | − o Start gdb: gdb vmlinux | |
| 51 | +- Start gdb: gdb vmlinux | |
| 48 | 52 | |
| 49 | − Note: Some distros may restrict auto-loading of gdb scripts to known safe | |
| 50 | − directories. In case gdb reports to refuse loading vmlinux-gdb.py, add | |
| 53 | + Note: Some distros may restrict auto-loading of gdb scripts to known safe | |
| 54 | + directories. In case gdb reports to refuse loading vmlinux-gdb.py, add:: | |
| 51 | 55 | |
| 52 | 56 | add-auto-load-safe-path /path/to/linux-build |
| 53 | 57 | |
| 54 | − to ~/.gdbinit. See gdb help for more details. | |
| 58 | + to ~/.gdbinit. See gdb help for more details. | |
| 59 | + | |
| 60 | +- Attach to the booted guest:: | |
| 55 | 61 | |
| 56 | − o Attach to the booted guest: | |
| 57 | 62 | (gdb) target remote :1234 |
| 58 | 63 | |
| 59 | 64 | |
| 60 | 65 | Examples of using the Linux-provided gdb helpers |
| 61 | 66 | ------------------------------------------------ |
| 62 | 67 | |
| 63 | − o Load module (and main kernel) symbols: | |
| 68 | +- Load module (and main kernel) symbols:: | |
| 69 | + | |
| 64 | 70 | (gdb) lx-symbols |
| 65 | 71 | loading vmlinux |
| 66 | 72 | scanning for modules in /home/user/linux/build |
| @@ -72,17 +78,20 @@ Examples of using the Linux-provided gdb helpers · 5 unmodified lines | ||
| 72 | 78 | ... |
| 73 | 79 | loading @0xffffffffa0000000: /home/user/linux/build/drivers/ata/ata_generic.ko |
| 74 | 80 | |
| 75 | − o Set a breakpoint on some not yet loaded module function, e.g.: | |
| 81 | +- Set a breakpoint on some not yet loaded module function, e.g.:: | |
| 82 | + | |
| 76 | 83 | (gdb) b btrfs_init_sysfs |
| 77 | 84 | Function "btrfs_init_sysfs" not defined. |
| 78 | 85 | Make breakpoint pending on future shared library load? (y or [n]) y |
| 79 | 86 | Breakpoint 1 (btrfs_init_sysfs) pending. |
| 80 | 87 | |
| 81 | − o Continue the target | |
| 88 | +- Continue the target:: | |
| 89 | + | |
| 82 | 90 | (gdb) c |
| 83 | 91 | |
| 84 | − o Load the module on the target and watch the symbols being loaded as well as | |
| 85 | − the breakpoint hit: | |
| 92 | +- Load the module on the target and watch the symbols being loaded as well as | |
| 93 | + the breakpoint hit:: | |
| 94 | + | |
| 86 | 95 | loading @0xffffffffa0034000: /home/user/linux/build/lib/libcrc32c.ko |
| 87 | 96 | loading @0xffffffffa0050000: /home/user/linux/build/lib/lzo/lzo_compress.ko |
| 88 | 97 | loading @0xffffffffa006e000: /home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko |
| @@ -91,7 +100,8 @@ Examples of using the Linux-provided gdb helpers · 2 unmodified lines | ||
| 91 | 100 | Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36 |
| 92 | 101 | 36 btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj); |
| 93 | 102 | |
| 94 | − o Dump the log buffer of the target kernel: | |
| 103 | +- Dump the log buffer of the target kernel:: | |
| 104 | + | |
| 95 | 105 | (gdb) lx-dmesg |
| 96 | 106 | [ 0.000000] Initializing cgroup subsys cpuset |
| 97 | 107 | [ 0.000000] Initializing cgroup subsys cpu |
| @@ -102,19 +112,22 @@ Examples of using the Linux-provided gdb helpers · 4 unmodified lines | ||
| 102 | 112 | [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved |
| 103 | 113 | .... |
| 104 | 114 | |
| 105 | − o Examine fields of the current task struct: | |
| 115 | +- Examine fields of the current task struct:: | |
| 116 | + | |
| 106 | 117 | (gdb) p $lx_current().pid |
| 107 | 118 | $1 = 4998 |
| 108 | 119 | (gdb) p $lx_current().comm |
| 109 | 120 | $2 = "modprobe\000\000\000\000\000\000\000" |
| 110 | 121 | |
| 111 | − o Make use of the per-cpu function for the current or a specified CPU: | |
| 122 | +- Make use of the per-cpu function for the current or a specified CPU:: | |
| 123 | + | |
| 112 | 124 | (gdb) p $lx_per_cpu("runqueues").nr_running |
| 113 | 125 | $3 = 1 |
| 114 | 126 | (gdb) p $lx_per_cpu("runqueues", 2).nr_running |
| 115 | 127 | $4 = 0 |
| 116 | 128 | |
| 117 | − o Dig into hrtimers using the container_of helper: | |
| 129 | +- Dig into hrtimers using the container_of helper:: | |
| 130 | + | |
| 118 | 131 | (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next |
| 119 | 132 | (gdb) p *$container_of($next, "struct hrtimer", "node") |
| 120 | 133 | $5 = { |
| @@ -144,7 +157,7 @@ List of commands and functions · 23 unmodified lines | ||
| 144 | 157 | ------------------------------ |
| 145 | 158 | |
| 146 | 159 | The number of commands and convenience functions may evolve over the time, |
| 147 | −this is just a snapshot of the initial version: | |
| 160 | +this is just a snapshot of the initial version:: | |
| 148 | 161 | |
| 149 | 162 | (gdb) apropos lx |
| 150 | 163 | function lx_current -- Return current task |
| @@ -0,0 +1,173 @@ | ||
| 1 | +The Kernel Address Sanitizer (KASAN) | |
| 2 | +==================================== | |
| 3 | + | |
| 4 | +Overview | |
| 5 | +-------- | |
| 6 | + | |
| 7 | +KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides | |
| 8 | +a fast and comprehensive solution for finding use-after-free and out-of-bounds | |
| 9 | +bugs. | |
| 10 | + | |
| 11 | +KASAN uses compile-time instrumentation for checking every memory access, | |
| 12 | +therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is | |
| 13 | +required for detection of out-of-bounds accesses to stack or global variables. | |
| 14 | + | |
| 15 | +Currently KASAN is supported only for the x86_64 and arm64 architectures. | |
| 16 | + | |
| 17 | +Usage | |
| 18 | +----- | |
| 19 | + | |
| 20 | +To enable KASAN configure kernel with:: | |
| 21 | + | |
| 22 | + CONFIG_KASAN = y | |
| 23 | + | |
| 24 | +and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline and | |
| 25 | +inline are compiler instrumentation types. The former produces smaller binary | |
| 26 | +the latter is 1.1 - 2 times faster. Inline instrumentation requires a GCC | |
| 27 | +version 5.0 or later. | |
| 28 | + | |
| 29 | +KASAN works with both SLUB and SLAB memory allocators. | |
| 30 | +For better bug detection and nicer reporting, enable CONFIG_STACKTRACE. | |
| 31 | + | |
| 32 | +To disable instrumentation for specific files or directories, add a line | |
| 33 | +similar to the following to the respective kernel Makefile: | |
| 34 | + | |
| 35 | +- For a single file (e.g. main.o):: | |
| 36 | + | |
| 37 | + KASAN_SANITIZE_main.o := n | |
| 38 | + | |
| 39 | +- For all files in one directory:: | |
| 40 | + | |
| 41 | + KASAN_SANITIZE := n | |
| 42 | + | |
| 43 | +Error reports | |
| 44 | +~~~~~~~~~~~~~ | |
| 45 | + | |
| 46 | +A typical out of bounds access report looks like this:: | |
| 47 | + | |
| 48 | + ================================================================== | |
| 49 | + BUG: AddressSanitizer: out of bounds access in kmalloc_oob_right+0x65/0x75 [test_kasan] at addr ffff8800693bc5d3 | |
| 50 | + Write of size 1 by task modprobe/1689 | |
| 51 | + ============================================================================= | |
| 52 | + BUG kmalloc-128 (Not tainted): kasan error | |
| 53 | + ----------------------------------------------------------------------------- | |
| 54 | + | |
| 55 | + Disabling lock debugging due to kernel taint | |
| 56 | + INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689 | |
| 57 | + __slab_alloc+0x4b4/0x4f0 | |
| 58 | + kmem_cache_alloc_trace+0x10b/0x190 | |
| 59 | + kmalloc_oob_right+0x3d/0x75 [test_kasan] | |
| 60 | + init_module+0x9/0x47 [test_kasan] | |
| 61 | + do_one_initcall+0x99/0x200 | |
| 62 | + load_module+0x2cb3/0x3b20 | |
| 63 | + SyS_finit_module+0x76/0x80 | |
| 64 | + system_call_fastpath+0x12/0x17 | |
| 65 | + INFO: Slab 0xffffea0001a4ef00 objects=17 used=7 fp=0xffff8800693bd728 flags=0x100000000004080 | |
| 66 | + INFO: Object 0xffff8800693bc558 @offset=1368 fp=0xffff8800693bc720 | |
| 67 | + | |
| 68 | + Bytes b4 ffff8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ | |
| 69 | + Object ffff8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk | |
| 70 | + Object ffff8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk | |
| 71 | + Object ffff8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk | |
| 72 | + Object ffff8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk | |
| 73 | + Object ffff8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk | |
| 74 | + Object ffff8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk | |
| 75 | + Object ffff8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk | |
| 76 | + Object ffff8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. | |
| 77 | + Redzone ffff8800693bc5d8: cc cc cc cc cc cc cc cc ........ | |
| 78 | + Padding ffff8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ | |
| 79 | + CPU: 0 PID: 1689 Comm: modprobe Tainted: G B 3.18.0-rc1-mm1+ #98 | |
| 80 | + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 | |
| 81 | + ffff8800693bc000 0000000000000000 ffff8800693bc558 ffff88006923bb78 | |
| 82 | + ffffffff81cc68ae 00000000000000f3 ffff88006d407600 ffff88006923bba8 | |
| 83 | + ffffffff811fd848 ffff88006d407600 ffffea0001a4ef00 ffff8800693bc558 | |
| 84 | + Call Trace: | |
| 85 | + [<ffffffff81cc68ae>] dump_stack+0x46/0x58 | |
| 86 | + [<ffffffff811fd848>] print_trailer+0xf8/0x160 | |
| 87 | + [<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan] | |
| 88 | + [<ffffffff811ff0f5>] object_err+0x35/0x40 | |
| 89 | + [<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan] | |
| 90 | + [<ffffffff8120b9fa>] kasan_report_error+0x38a/0x3f0 | |
| 91 | + [<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40 | |
| 92 | + [<ffffffff8120b344>] ? kasan_unpoison_shadow+0x14/0x40 | |
| 93 | + [<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40 | |
| 94 | + [<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan] | |
| 95 | + [<ffffffff8120a995>] __asan_store1+0x75/0xb0 | |
| 96 | + [<ffffffffa0002601>] ? kmem_cache_oob+0x1d/0xc3 [test_kasan] | |
| 97 | + [<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan] | |
| 98 | + [<ffffffffa0002065>] kmalloc_oob_right+0x65/0x75 [test_kasan] | |
| 99 | + [<ffffffffa00026b0>] init_module+0x9/0x47 [test_kasan] | |
| 100 | + [<ffffffff810002d9>] do_one_initcall+0x99/0x200 | |
| 101 | + [<ffffffff811e4e5c>] ? __vunmap+0xec/0x160 | |
| 102 | + [<ffffffff81114f63>] load_module+0x2cb3/0x3b20 | |
| 103 | + [<ffffffff8110fd70>] ? m_show+0x240/0x240 | |
| 104 | + [<ffffffff81115f06>] SyS_finit_module+0x76/0x80 | |
| 105 | + [<ffffffff81cd3129>] system_call_fastpath+0x12/0x17 | |
| 106 | + Memory state around the buggy address: | |
| 107 | + ffff8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | |
| 108 | + ffff8800693bc380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 fc | |
| 109 | + ffff8800693bc400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | |
| 110 | + ffff8800693bc480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | |
| 111 | + ffff8800693bc500: fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00 | |
| 112 | + >ffff8800693bc580: 00 00 00 00 00 00 00 00 00 00 03 fc fc fc fc fc | |
| 113 | + ^ | |
| 114 | + ffff8800693bc600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | |
| 115 | + ffff8800693bc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | |
| 116 | + ffff8800693bc700: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb | |
| 117 | + ffff8800693bc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb | |
| 118 | + ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb | |
| 119 | + ================================================================== | |
| 120 | + | |
| 121 | +The header of the report discribe what kind of bug happened and what kind of | |
| 122 | +access caused it. It's followed by the description of the accessed slub object | |
| 123 | +(see 'SLUB Debug output' section in Documentation/vm/slub.txt for details) and | |
| 124 | +the description of the accessed memory page. | |
| 125 | + | |
| 126 | +In the last section the report shows memory state around the accessed address. | |
| 127 | +Reading this part requires some understanding of how KASAN works. | |
| 128 | + | |
| 129 | +The state of each 8 aligned bytes of memory is encoded in one shadow byte. | |
| 130 | +Those 8 bytes can be accessible, partially accessible, freed or be a redzone. | |
| 131 | +We use the following encoding for each shadow byte: 0 means that all 8 bytes | |
| 132 | +of the corresponding memory region are accessible; number N (1 <= N <= 7) means | |
| 133 | +that the first N bytes are accessible, and other (8 - N) bytes are not; | |
| 134 | +any negative value indicates that the entire 8-byte word is inaccessible. | |
| 135 | +We use different negative values to distinguish between different kinds of | |
| 136 | +inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h). | |
| 137 | + | |
| 138 | +In the report above the arrows point to the shadow byte 03, which means that | |
| 139 | +the accessed address is partially accessible. | |
| 140 | + | |
| 141 | + | |
| 142 | +Implementation details | |
| 143 | +---------------------- | |
| 144 | + | |
| 145 | +From a high level, our approach to memory error detection is similar to that | |
| 146 | +of kmemcheck: use shadow memory to record whether each byte of memory is safe | |
| 147 | +to access, and use compile-time instrumentation to check shadow memory on each | |
| 148 | +memory access. | |
| 149 | + | |
| 150 | +AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory | |
| 151 | +(e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and | |
| 152 | +offset to translate a memory address to its corresponding shadow address. | |
| 153 | + | |
| 154 | +Here is the function which translates an address to its corresponding shadow | |
| 155 | +address:: | |
| 156 | + | |
| 157 | + static inline void *kasan_mem_to_shadow(const void *addr) | |
| 158 | + { | |
| 159 | + return ((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT) | |
| 160 | + + KASAN_SHADOW_OFFSET; | |
| 161 | + } | |
| 162 | + | |
| 163 | +where ``KASAN_SHADOW_SCALE_SHIFT = 3``. | |
| 164 | + | |
| 165 | +Compile-time instrumentation used for checking memory accesses. Compiler inserts | |
| 166 | +function calls (__asan_load*(addr), __asan_store*(addr)) before each memory | |
| 167 | +access of size 1, 2, 4, 8 or 16. These functions check whether memory access is | |
| 168 | +valid or not by checking corresponding shadow memory. | |
| 169 | + | |
| 170 | +GCC 5.0 has possibility to perform inline instrumentation. Instead of making | |
| 171 | +function calls GCC directly inserts the code to check the shadow memory. | |
| 172 | +This option significantly enlarges kernel but it gives x1.1-x2 performance | |
| 173 | +boost over outline instrumented kernel. | |
| @@ -12,38 +12,38 @@ To achieve this goal it does not collect coverage in soft/hard interrupts · 11 unmodified lines | ||
| 12 | 12 | and instrumentation of some inherently non-deterministic parts of kernel is |
| 13 | 13 | disbled (e.g. scheduler, locking). |
| 14 | 14 | |
| 15 | −Usage: | |
| 16 | −====== | |
| 15 | +Usage | |
| 16 | +----- | |
| 17 | 17 | |
| 18 | −Configure kernel with: | |
| 18 | +Configure the kernel with:: | |
| 19 | 19 | |
| 20 | 20 | CONFIG_KCOV=y |
| 21 | 21 | |
| 22 | 22 | CONFIG_KCOV requires gcc built on revision 231296 or later. |
| 23 | −Profiling data will only become accessible once debugfs has been mounted: | |
| 23 | +Profiling data will only become accessible once debugfs has been mounted:: | |
| 24 | 24 | |
| 25 | 25 | mount -t debugfs none /sys/kernel/debug |
| 26 | 26 | |
| 27 | −The following program demonstrates kcov usage from within a test program: | |
| 28 | − | |
| 29 | −#include <stdio.h> | |
| 30 | −#include <stddef.h> | |
| 31 | −#include <stdint.h> | |
| 32 | −#include <stdlib.h> | |
| 33 | −#include <sys/types.h> | |
| 34 | −#include <sys/stat.h> | |
| 35 | −#include <sys/ioctl.h> | |
| 36 | −#include <sys/mman.h> | |
| 37 | −#include <unistd.h> | |
| 38 | −#include <fcntl.h> | |
| 39 | − | |
| 40 | −#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) | |
| 41 | −#define KCOV_ENABLE _IO('c', 100) | |
| 42 | −#define KCOV_DISABLE _IO('c', 101) | |
| 43 | −#define COVER_SIZE (64<<10) | |
| 44 | − | |
| 45 | −int main(int argc, char **argv) | |
| 46 | −{ | |
| 27 | +The following program demonstrates kcov usage from within a test program:: | |
| 28 | + | |
| 29 | + #include <stdio.h> | |
| 30 | + #include <stddef.h> | |
| 31 | + #include <stdint.h> | |
| 32 | + #include <stdlib.h> | |
| 33 | + #include <sys/types.h> | |
| 34 | + #include <sys/stat.h> | |
| 35 | + #include <sys/ioctl.h> | |
| 36 | + #include <sys/mman.h> | |
| 37 | + #include <unistd.h> | |
| 38 | + #include <fcntl.h> | |
| 39 | + | |
| 40 | + #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) | |
| 41 | + #define KCOV_ENABLE _IO('c', 100) | |
| 42 | + #define KCOV_DISABLE _IO('c', 101) | |
| 43 | + #define COVER_SIZE (64<<10) | |
| 44 | + | |
| 45 | + int main(int argc, char **argv) | |
| 46 | + { | |
| 47 | 47 | int fd; |
| 48 | 48 | unsigned long *cover, n, i; |
| 49 | 49 | |
| @@ -83,24 +83,24 @@ int main(int argc, char **argv) · 33 unmodified lines | ||
| 83 | 83 | if (close(fd)) |
| 84 | 84 | perror("close"), exit(1); |
| 85 | 85 | return 0; |
| 86 | −} | |
| 87 | − | |
| 88 | −After piping through addr2line output of the program looks as follows: | |
| 89 | − | |
| 90 | −SyS_read | |
| 91 | −fs/read_write.c:562 | |
| 92 | −__fdget_pos | |
| 93 | −fs/file.c:774 | |
| 94 | −__fget_light | |
| 95 | −fs/file.c:746 | |
| 96 | −__fget_light | |
| 97 | −fs/file.c:750 | |
| 98 | −__fget_light | |
| 99 | −fs/file.c:760 | |
| 100 | −__fdget_pos | |
| 101 | −fs/file.c:784 | |
| 102 | −SyS_read | |
| 103 | −fs/read_write.c:562 | |
| 86 | + } | |
| 87 | + | |
| 88 | +After piping through addr2line output of the program looks as follows:: | |
| 89 | + | |
| 90 | + SyS_read | |
| 91 | + fs/read_write.c:562 | |
| 92 | + __fdget_pos | |
| 93 | + fs/file.c:774 | |
| 94 | + __fget_light | |
| 95 | + fs/file.c:746 | |
| 96 | + __fget_light | |
| 97 | + fs/file.c:750 | |
| 98 | + __fget_light | |
| 99 | + fs/file.c:760 | |
| 100 | + __fdget_pos | |
| 101 | + fs/file.c:784 | |
| 102 | + SyS_read | |
| 103 | + fs/read_write.c:562 | |
| 104 | 104 | |
| 105 | 105 | If a program needs to collect coverage from several threads (independently), |
| 106 | 106 | it needs to open /sys/kernel/debug/kcov in each thread separately. |
| @@ -0,0 +1,733 @@ | ||
| 1 | +Getting started with kmemcheck | |
| 2 | +============================== | |
| 3 | + | |
| 4 | +Vegard Nossum <vegardno@ifi.uio.no> | |
| 5 | + | |
| 6 | + | |
| 7 | +Introduction | |
| 8 | +------------ | |
| 9 | + | |
| 10 | +kmemcheck is a debugging feature for the Linux Kernel. More specifically, it | |
| 11 | +is a dynamic checker that detects and warns about some uses of uninitialized | |
| 12 | +memory. | |
| 13 | + | |
| 14 | +Userspace programmers might be familiar with Valgrind's memcheck. The main | |
| 15 | +difference between memcheck and kmemcheck is that memcheck works for userspace | |
| 16 | +programs only, and kmemcheck works for the kernel only. The implementations | |
| 17 | +are of course vastly different. Because of this, kmemcheck is not as accurate | |
| 18 | +as memcheck, but it turns out to be good enough in practice to discover real | |
| 19 | +programmer errors that the compiler is not able to find through static | |
| 20 | +analysis. | |
| 21 | + | |
| 22 | +Enabling kmemcheck on a kernel will probably slow it down to the extent that | |
| 23 | +the machine will not be usable for normal workloads such as e.g. an | |
| 24 | +interactive desktop. kmemcheck will also cause the kernel to use about twice | |
| 25 | +as much memory as normal. For this reason, kmemcheck is strictly a debugging | |
| 26 | +feature. | |
| 27 | + | |
| 28 | + | |
| 29 | +Downloading | |
| 30 | +----------- | |
| 31 | + | |
| 32 | +As of version 2.6.31-rc1, kmemcheck is included in the mainline kernel. | |
| 33 | + | |
| 34 | + | |
| 35 | +Configuring and compiling | |
| 36 | +------------------------- | |
| 37 | + | |
| 38 | +kmemcheck only works for the x86 (both 32- and 64-bit) platform. A number of | |
| 39 | +configuration variables must have specific settings in order for the kmemcheck | |
| 40 | +menu to even appear in "menuconfig". These are: | |
| 41 | + | |
| 42 | +- ``CONFIG_CC_OPTIMIZE_FOR_SIZE=n`` | |
| 43 | + This option is located under "General setup" / "Optimize for size". | |
| 44 | + | |
| 45 | + Without this, gcc will use certain optimizations that usually lead to | |
| 46 | + false positive warnings from kmemcheck. An example of this is a 16-bit | |
| 47 | + field in a struct, where gcc may load 32 bits, then discard the upper | |
| 48 | + 16 bits. kmemcheck sees only the 32-bit load, and may trigger a | |
| 49 | + warning for the upper 16 bits (if they're uninitialized). | |
| 50 | + | |
| 51 | +- ``CONFIG_SLAB=y`` or ``CONFIG_SLUB=y`` | |
| 52 | + This option is located under "General setup" / "Choose SLAB | |
| 53 | + allocator". | |
| 54 | + | |
| 55 | +- ``CONFIG_FUNCTION_TRACER=n`` | |
| 56 | + This option is located under "Kernel hacking" / "Tracers" / "Kernel | |
| 57 | + Function Tracer" | |
| 58 | + | |
| 59 | + When function tracing is compiled in, gcc emits a call to another | |
| 60 | + function at the beginning of every function. This means that when the | |
| 61 | + page fault handler is called, the ftrace framework will be called | |
| 62 | + before kmemcheck has had a chance to handle the fault. If ftrace then | |
| 63 | + modifies memory that was tracked by kmemcheck, the result is an | |
| 64 | + endless recursive page fault. | |
| 65 | + | |
| 66 | +- ``CONFIG_DEBUG_PAGEALLOC=n`` | |
| 67 | + This option is located under "Kernel hacking" / "Memory Debugging" | |
| 68 | + / "Debug page memory allocations". | |
| 69 | + | |
| 70 | +In addition, I highly recommend turning on ``CONFIG_DEBUG_INFO=y``. This is also | |
| 71 | +located under "Kernel hacking". With this, you will be able to get line number | |
| 72 | +information from the kmemcheck warnings, which is extremely valuable in | |
| 73 | +debugging a problem. This option is not mandatory, however, because it slows | |
| 74 | +down the compilation process and produces a much bigger kernel image. | |
| 75 | + | |
| 76 | +Now the kmemcheck menu should be visible (under "Kernel hacking" / "Memory | |
| 77 | +Debugging" / "kmemcheck: trap use of uninitialized memory"). Here follows | |
| 78 | +a description of the kmemcheck configuration variables: | |
| 79 | + | |
| 80 | +- ``CONFIG_KMEMCHECK`` | |
| 81 | + This must be enabled in order to use kmemcheck at all... | |
| 82 | + | |
| 83 | +- ``CONFIG_KMEMCHECK_``[``DISABLED`` | ``ENABLED`` | ``ONESHOT``]``_BY_DEFAULT`` | |
| 84 | + This option controls the status of kmemcheck at boot-time. "Enabled" | |
| 85 | + will enable kmemcheck right from the start, "disabled" will boot the | |
| 86 | + kernel as normal (but with the kmemcheck code compiled in, so it can | |
| 87 | + be enabled at run-time after the kernel has booted), and "one-shot" is | |
| 88 | + a special mode which will turn kmemcheck off automatically after | |
| 89 | + detecting the first use of uninitialized memory. | |
| 90 | + | |
| 91 | + If you are using kmemcheck to actively debug a problem, then you | |
| 92 | + probably want to choose "enabled" here. | |
| 93 | + | |
| 94 | + The one-shot mode is mostly useful in automated test setups because it | |
| 95 | + can prevent floods of warnings and increase the chances of the machine | |
| 96 | + surviving in case something is really wrong. In other cases, the one- | |
| 97 | + shot mode could actually be counter-productive because it would turn | |
| 98 | + itself off at the very first error -- in the case of a false positive | |
| 99 | + too -- and this would come in the way of debugging the specific | |
| 100 | + problem you were interested in. | |
| 101 | + | |
| 102 | + If you would like to use your kernel as normal, but with a chance to | |
| 103 | + enable kmemcheck in case of some problem, it might be a good idea to | |
| 104 | + choose "disabled" here. When kmemcheck is disabled, most of the run- | |
| 105 | + time overhead is not incurred, and the kernel will be almost as fast | |
| 106 | + as normal. | |
| 107 | + | |
| 108 | +- ``CONFIG_KMEMCHECK_QUEUE_SIZE`` | |
| 109 | + Select the maximum number of error reports to store in an internal | |
| 110 | + (fixed-size) buffer. Since errors can occur virtually anywhere and in | |
| 111 | + any context, we need a temporary storage area which is guaranteed not | |
| 112 | + to generate any other page faults when accessed. The queue will be | |
| 113 | + emptied as soon as a tasklet may be scheduled. If the queue is full, | |
| 114 | + new error reports will be lost. | |
| 115 | + | |
| 116 | + The default value of 64 is probably fine. If some code produces more | |
| 117 | + than 64 errors within an irqs-off section, then the code is likely to | |
| 118 | + produce many, many more, too, and these additional reports seldom give | |
| 119 | + any more information (the first report is usually the most valuable | |
| 120 | + anyway). | |
| 121 | + | |
| 122 | + This number might have to be adjusted if you are not using serial | |
| 123 | + console or similar to capture the kernel log. If you are using the | |
| 124 | + "dmesg" command to save the log, then getting a lot of kmemcheck | |
| 125 | + warnings might overflow the kernel log itself, and the earlier reports | |
| 126 | + will get lost in that way instead. Try setting this to 10 or so on | |
| 127 | + such a setup. | |
| 128 | + | |
| 129 | +- ``CONFIG_KMEMCHECK_SHADOW_COPY_SHIFT`` | |
| 130 | + Select the number of shadow bytes to save along with each entry of the | |
| 131 | + error-report queue. These bytes indicate what parts of an allocation | |
| 132 | + are initialized, uninitialized, etc. and will be displayed when an | |
| 133 | + error is detected to help the debugging of a particular problem. | |
| 134 | + | |
| 135 | + The number entered here is actually the logarithm of the number of | |
| 136 | + bytes that will be saved. So if you pick for example 5 here, kmemcheck | |
| 137 | + will save 2^5 = 32 bytes. | |
| 138 | + | |
| 139 | + The default value should be fine for debugging most problems. It also | |
| 140 | + fits nicely within 80 columns. | |
| 141 | + | |
| 142 | +- ``CONFIG_KMEMCHECK_PARTIAL_OK`` | |
| 143 | + This option (when enabled) works around certain GCC optimizations that | |
| 144 | + produce 32-bit reads from 16-bit variables where the upper 16 bits are | |
| 145 | + thrown away afterwards. | |
| 146 | + | |
| 147 | + The default value (enabled) is recommended. This may of course hide | |
| 148 | + some real errors, but disabling it would probably produce a lot of | |
| 149 | + false positives. | |
| 150 | + | |
| 151 | +- ``CONFIG_KMEMCHECK_BITOPS_OK`` | |
| 152 | + This option silences warnings that would be generated for bit-field | |
| 153 | + accesses where not all the bits are initialized at the same time. This | |
| 154 | + may also hide some real bugs. | |
| 155 | + | |
| 156 | + This option is probably obsolete, or it should be replaced with | |
| 157 | + the kmemcheck-/bitfield-annotations for the code in question. The | |
| 158 | + default value is therefore fine. | |
| 159 | + | |
| 160 | +Now compile the kernel as usual. | |
| 161 | + | |
| 162 | + | |
| 163 | +How to use | |
| 164 | +---------- | |
| 165 | + | |
| 166 | +Booting | |
| 167 | +~~~~~~~ | |
| 168 | + | |
| 169 | +First some information about the command-line options. There is only one | |
| 170 | +option specific to kmemcheck, and this is called "kmemcheck". It can be used | |
| 171 | +to override the default mode as chosen by the ``CONFIG_KMEMCHECK_*_BY_DEFAULT`` | |
| 172 | +option. Its possible settings are: | |
| 173 | + | |
| 174 | +- ``kmemcheck=0`` (disabled) | |
| 175 | +- ``kmemcheck=1`` (enabled) | |
| 176 | +- ``kmemcheck=2`` (one-shot mode) | |
| 177 | + | |
| 178 | +If SLUB debugging has been enabled in the kernel, it may take precedence over | |
| 179 | +kmemcheck in such a way that the slab caches which are under SLUB debugging | |
| 180 | +will not be tracked by kmemcheck. In order to ensure that this doesn't happen | |
| 181 | +(even though it shouldn't by default), use SLUB's boot option ``slub_debug``, | |
| 182 | +like this: ``slub_debug=-`` | |
| 183 | + | |
| 184 | +In fact, this option may also be used for fine-grained control over SLUB vs. | |
| 185 | +kmemcheck. For example, if the command line includes | |
| 186 | +``kmemcheck=1 slub_debug=,dentry``, then SLUB debugging will be used only | |
| 187 | +for the "dentry" slab cache, and with kmemcheck tracking all the other | |
| 188 | +caches. This is advanced usage, however, and is not generally recommended. | |
| 189 | + | |
| 190 | + | |
| 191 | +Run-time enable/disable | |
| 192 | +~~~~~~~~~~~~~~~~~~~~~~~ | |
| 193 | + | |
| 194 | +When the kernel has booted, it is possible to enable or disable kmemcheck at | |
| 195 | +run-time. WARNING: This feature is still experimental and may cause false | |
| 196 | +positive warnings to appear. Therefore, try not to use this. If you find that | |
| 197 | +it doesn't work properly (e.g. you see an unreasonable amount of warnings), I | |
| 198 | +will be happy to take bug reports. | |
| 199 | + | |
| 200 | +Use the file ``/proc/sys/kernel/kmemcheck`` for this purpose, e.g.:: | |
| 201 | + | |
| 202 | + $ echo 0 > /proc/sys/kernel/kmemcheck # disables kmemcheck | |
| 203 | + | |
| 204 | +The numbers are the same as for the ``kmemcheck=`` command-line option. | |
| 205 | + | |
| 206 | + | |
| 207 | +Debugging | |
| 208 | +~~~~~~~~~ | |
| 209 | + | |
| 210 | +A typical report will look something like this:: | |
| 211 | + | |
| 212 | + WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024) | |
| 213 | + 80000000000000000000000000000000000000000088ffff0000000000000000 | |
| 214 | + i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u | |
| 215 | + ^ | |
| 216 | + | |
| 217 | + Pid: 1856, comm: ntpdate Not tainted 2.6.29-rc5 #264 945P-A | |
| 218 | + RIP: 0010:[<ffffffff8104ede8>] [<ffffffff8104ede8>] __dequeue_signal+0xc8/0x190 | |
| 219 | + RSP: 0018:ffff88003cdf7d98 EFLAGS: 00210002 | |
| 220 | + RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009 | |
| 221 | + RDX: ffff88003e5d6018 RSI: ffff88003e5d6024 RDI: ffff88003cdf7e84 | |
| 222 | + RBP: ffff88003cdf7db8 R08: ffff88003e5d6000 R09: 0000000000000000 | |
| 223 | + R10: 0000000000000080 R11: 0000000000000000 R12: 000000000000000e | |
| 224 | + R13: ffff88003cdf7e78 R14: ffff88003d530710 R15: ffff88003d5a98c8 | |
| 225 | + FS: 0000000000000000(0000) GS:ffff880001982000(0063) knlGS:00000 | |
| 226 | + CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 | |
| 227 | + CR2: ffff88003f806ea0 CR3: 000000003c036000 CR4: 00000000000006a0 | |
| 228 | + DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 | |
| 229 | + DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 | |
| 230 | + [<ffffffff8104f04e>] dequeue_signal+0x8e/0x170 | |
| 231 | + [<ffffffff81050bd8>] get_signal_to_deliver+0x98/0x390 | |
| 232 | + [<ffffffff8100b87d>] do_notify_resume+0xad/0x7d0 | |
| 233 | + [<ffffffff8100c7b5>] int_signal+0x12/0x17 | |
| 234 | + [<ffffffffffffffff>] 0xffffffffffffffff | |
| 235 | + | |
| 236 | +The single most valuable information in this report is the RIP (or EIP on 32- | |
| 237 | +bit) value. This will help us pinpoint exactly which instruction that caused | |
| 238 | +the warning. | |
| 239 | + | |
| 240 | +If your kernel was compiled with ``CONFIG_DEBUG_INFO=y``, then all we have to do | |
| 241 | +is give this address to the addr2line program, like this:: | |
| 242 | + | |
| 243 | + $ addr2line -e vmlinux -i ffffffff8104ede8 | |
| 244 | + arch/x86/include/asm/string_64.h:12 | |
| 245 | + include/asm-generic/siginfo.h:287 | |
| 246 | + kernel/signal.c:380 | |
| 247 | + kernel/signal.c:410 | |
| 248 | + | |
| 249 | +The "``-e vmlinux``" tells addr2line which file to look in. **IMPORTANT:** | |
| 250 | +This must be the vmlinux of the kernel that produced the warning in the | |
| 251 | +first place! If not, the line number information will almost certainly be | |
| 252 | +wrong. | |
| 253 | + | |
| 254 | +The "``-i``" tells addr2line to also print the line numbers of inlined | |
| 255 | +functions. In this case, the flag was very important, because otherwise, | |
| 256 | +it would only have printed the first line, which is just a call to | |
| 257 | +``memcpy()``, which could be called from a thousand places in the kernel, and | |
| 258 | +is therefore not very useful. These inlined functions would not show up in | |
| 259 | +the stack trace above, simply because the kernel doesn't load the extra | |
| 260 | +debugging information. This technique can of course be used with ordinary | |
| 261 | +kernel oopses as well. | |
| 262 | + | |
| 263 | +In this case, it's the caller of ``memcpy()`` that is interesting, and it can be | |
| 264 | +found in ``include/asm-generic/siginfo.h``, line 287:: | |
| 265 | + | |
| 266 | + 281 static inline void copy_siginfo(struct siginfo *to, struct siginfo *from) | |
| 267 | + 282 { | |
| 268 | + 283 if (from->si_code < 0) | |
| 269 | + 284 memcpy(to, from, sizeof(*to)); | |
| 270 | + 285 else | |
| 271 | + 286 /* _sigchld is currently the largest know union member */ | |
| 272 | + 287 memcpy(to, from, __ARCH_SI_PREAMBLE_SIZE + sizeof(from->_sifields._sigchld)); | |
| 273 | + 288 } | |
| 274 | + | |
| 275 | +Since this was a read (kmemcheck usually warns about reads only, though it can | |
| 276 | +warn about writes to unallocated or freed memory as well), it was probably the | |
| 277 | +"from" argument which contained some uninitialized bytes. Following the chain | |
| 278 | +of calls, we move upwards to see where "from" was allocated or initialized, | |
| 279 | +``kernel/signal.c``, line 380:: | |
| 280 | + | |
| 281 | + 359 static void collect_signal(int sig, struct sigpending *list, siginfo_t *info) | |
| 282 | + 360 { | |
| 283 | + ... | |
| 284 | + 367 list_for_each_entry(q, &list->list, list) { | |
| 285 | + 368 if (q->info.si_signo == sig) { | |
| 286 | + 369 if (first) | |
| 287 | + 370 goto still_pending; | |
| 288 | + 371 first = q; | |
| 289 | + ... | |
| 290 | + 377 if (first) { | |
| 291 | + 378 still_pending: | |
| 292 | + 379 list_del_init(&first->list); | |
| 293 | + 380 copy_siginfo(info, &first->info); | |
| 294 | + 381 __sigqueue_free(first); | |
| 295 | + ... | |
| 296 | + 392 } | |
| 297 | + 393 } | |
| 298 | + | |
| 299 | +Here, it is ``&first->info`` that is being passed on to ``copy_siginfo()``. The | |
| 300 | +variable ``first`` was found on a list -- passed in as the second argument to | |
| 301 | +``collect_signal()``. We continue our journey through the stack, to figure out | |
| 302 | +where the item on "list" was allocated or initialized. We move to line 410:: | |
| 303 | + | |
| 304 | + 395 static int __dequeue_signal(struct sigpending *pending, sigset_t *mask, | |
| 305 | + 396 siginfo_t *info) | |
| 306 | + 397 { | |
| 307 | + ... | |
| 308 | + 410 collect_signal(sig, pending, info); | |
| 309 | + ... | |
| 310 | + 414 } | |
| 311 | + | |
| 312 | +Now we need to follow the ``pending`` pointer, since that is being passed on to | |
| 313 | +``collect_signal()`` as ``list``. At this point, we've run out of lines from the | |
| 314 | +"addr2line" output. Not to worry, we just paste the next addresses from the | |
| 315 | +kmemcheck stack dump, i.e.:: | |
| 316 | + | |
| 317 | + [<ffffffff8104f04e>] dequeue_signal+0x8e/0x170 | |
| 318 | + [<ffffffff81050bd8>] get_signal_to_deliver+0x98/0x390 | |
| 319 | + [<ffffffff8100b87d>] do_notify_resume+0xad/0x7d0 | |
| 320 | + [<ffffffff8100c7b5>] int_signal+0x12/0x17 | |
| 321 | + | |
| 322 | + $ addr2line -e vmlinux -i ffffffff8104f04e ffffffff81050bd8 \ | |
| 323 | + ffffffff8100b87d ffffffff8100c7b5 | |
| 324 | + kernel/signal.c:446 | |
| 325 | + kernel/signal.c:1806 | |
| 326 | + arch/x86/kernel/signal.c:805 | |
| 327 | + arch/x86/kernel/signal.c:871 | |
| 328 | + arch/x86/kernel/entry_64.S:694 | |
| 329 | + | |
| 330 | +Remember that since these addresses were found on the stack and not as the | |
| 331 | +RIP value, they actually point to the _next_ instruction (they are return | |
| 332 | +addresses). This becomes obvious when we look at the code for line 446:: | |
| 333 | + | |
| 334 | + 422 int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info) | |
| 335 | + 423 { | |
| 336 | + ... | |
| 337 | + 431 signr = __dequeue_signal(&tsk->signal->shared_pending, | |
| 338 | + 432 mask, info); | |
| 339 | + 433 /* | |
| 340 | + 434 * itimer signal ? | |
| 341 | + 435 * | |
| 342 | + 436 * itimers are process shared and we restart periodic | |
| 343 | + 437 * itimers in the signal delivery path to prevent DoS | |
| 344 | + 438 * attacks in the high resolution timer case. This is | |
| 345 | + 439 * compliant with the old way of self restarting | |
| 346 | + 440 * itimers, as the SIGALRM is a legacy signal and only | |
| 347 | + 441 * queued once. Changing the restart behaviour to | |
| 348 | + 442 * restart the timer in the signal dequeue path is | |
| 349 | + 443 * reducing the timer noise on heavy loaded !highres | |
| 350 | + 444 * systems too. | |
| 351 | + 445 */ | |
| 352 | + 446 if (unlikely(signr == SIGALRM)) { | |
| 353 | + ... | |
| 354 | + 489 } | |
| 355 | + | |
| 356 | +So instead of looking at 446, we should be looking at 431, which is the line | |
| 357 | +that executes just before 446. Here we see that what we are looking for is | |
| 358 | +``&tsk->signal->shared_pending``. | |
| 359 | + | |
| 360 | +Our next task is now to figure out which function that puts items on this | |
| 361 | +``shared_pending`` list. A crude, but efficient tool, is ``git grep``:: | |
| 362 | + | |
| 363 | + $ git grep -n 'shared_pending' kernel/ | |
| 364 | + ... | |
| 365 | + kernel/signal.c:828: pending = group ? &t->signal->shared_pending : &t->pending; | |
| 366 | + kernel/signal.c:1339: pending = group ? &t->signal->shared_pending : &t->pending; | |
| 367 | + ... | |
| 368 | + | |
| 369 | +There were more results, but none of them were related to list operations, | |
| 370 | +and these were the only assignments. We inspect the line numbers more closely | |
| 371 | +and find that this is indeed where items are being added to the list:: | |
| 372 | + | |
| 373 | + 816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t, | |
| 374 | + 817 int group) | |
| 375 | + 818 { | |
| 376 | + ... | |
| 377 | + 828 pending = group ? &t->signal->shared_pending : &t->pending; | |
| 378 | + ... | |
| 379 | + 851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN && | |
| 380 | + 852 (is_si_special(info) || | |
| 381 | + 853 info->si_code >= 0))); | |
| 382 | + 854 if (q) { | |
| 383 | + 855 list_add_tail(&q->list, &pending->list); | |
| 384 | + ... | |
| 385 | + 890 } | |
| 386 | + | |
| 387 | +and:: | |
| 388 | + | |
| 389 | + 1309 int send_sigqueue(struct sigqueue *q, struct task_struct *t, int group) | |
| 390 | + 1310 { | |
| 391 | + .... | |
| 392 | + 1339 pending = group ? &t->signal->shared_pending : &t->pending; | |
| 393 | + 1340 list_add_tail(&q->list, &pending->list); | |
| 394 | + .... | |
| 395 | + 1347 } | |
| 396 | + | |
| 397 | +In the first case, the list element we are looking for, ``q``, is being | |
| 398 | +returned from the function ``__sigqueue_alloc()``, which looks like an | |
| 399 | +allocation function. Let's take a look at it:: | |
| 400 | + | |
| 401 | + 187 static struct sigqueue *__sigqueue_alloc(struct task_struct *t, gfp_t flags, | |
| 402 | + 188 int override_rlimit) | |
| 403 | + 189 { | |
| 404 | + 190 struct sigqueue *q = NULL; | |
| 405 | + 191 struct user_struct *user; | |
| 406 | + 192 | |
| 407 | + 193 /* | |
| 408 | + 194 * We won't get problems with the target's UID changing under us | |
| 409 | + 195 * because changing it requires RCU be used, and if t != current, the | |
| 410 | + 196 * caller must be holding the RCU readlock (by way of a spinlock) and | |
| 411 | + 197 * we use RCU protection here | |
| 412 | + 198 */ | |
| 413 | + 199 user = get_uid(__task_cred(t)->user); | |
| 414 | + 200 atomic_inc(&user->sigpending); | |
| 415 | + 201 if (override_rlimit || | |
| 416 | + 202 atomic_read(&user->sigpending) <= | |
| 417 | + 203 t->signal->rlim[RLIMIT_SIGPENDING].rlim_cur) | |
| 418 | + 204 q = kmem_cache_alloc(sigqueue_cachep, flags); | |
| 419 | + 205 if (unlikely(q == NULL)) { | |
| 420 | + 206 atomic_dec(&user->sigpending); | |
| 421 | + 207 free_uid(user); | |
| 422 | + 208 } else { | |
| 423 | + 209 INIT_LIST_HEAD(&q->list); | |
| 424 | + 210 q->flags = 0; | |
| 425 | + 211 q->user = user; | |
| 426 | + 212 } | |
| 427 | + 213 | |
| 428 | + 214 return q; | |
| 429 | + 215 } | |
| 430 | + | |
| 431 | +We see that this function initializes ``q->list``, ``q->flags``, and | |
| 432 | +``q->user``. It seems that now is the time to look at the definition of | |
| 433 | +``struct sigqueue``, e.g.:: | |
| 434 | + | |
| 435 | + 14 struct sigqueue { | |
| 436 | + 15 struct list_head list; | |
| 437 | + 16 int flags; | |
| 438 | + 17 siginfo_t info; | |
| 439 | + 18 struct user_struct *user; | |
| 440 | + 19 }; | |
| 441 | + | |
| 442 | +And, you might remember, it was a ``memcpy()`` on ``&first->info`` that | |
| 443 | +caused the warning, so this makes perfect sense. It also seems reasonable | |
| 444 | +to assume that it is the caller of ``__sigqueue_alloc()`` that has the | |
| 445 | +responsibility of filling out (initializing) this member. | |
| 446 | + | |
| 447 | +But just which fields of the struct were uninitialized? Let's look at | |
| 448 | +kmemcheck's report again:: | |
| 449 | + | |
| 450 | + WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (ffff88003e4a2024) | |
| 451 | + 80000000000000000000000000000000000000000088ffff0000000000000000 | |
| 452 | + i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u | |
| 453 | + ^ | |
| 454 | + | |
| 455 | +These first two lines are the memory dump of the memory object itself, and | |
| 456 | +the shadow bytemap, respectively. The memory object itself is in this case | |
| 457 | +``&first->info``. Just beware that the start of this dump is NOT the start | |
| 458 | +of the object itself! The position of the caret (^) corresponds with the | |
| 459 | +address of the read (ffff88003e4a2024). | |
| 460 | + | |
| 461 | +The shadow bytemap dump legend is as follows: | |
| 462 | + | |
| 463 | +- i: initialized | |
| 464 | +- u: uninitialized | |
| 465 | +- a: unallocated (memory has been allocated by the slab layer, but has not | |
| 466 | + yet been handed off to anybody) | |
| 467 | +- f: freed (memory has been allocated by the slab layer, but has been freed | |
| 468 | + by the previous owner) | |
| 469 | + | |
| 470 | +In order to figure out where (relative to the start of the object) the | |
| 471 | +uninitialized memory was located, we have to look at the disassembly. For | |
| 472 | +that, we'll need the RIP address again:: | |
| 473 | + | |
| 474 | + RIP: 0010:[<ffffffff8104ede8>] [<ffffffff8104ede8>] __dequeue_signal+0xc8/0x190 | |
| 475 | + | |
| 476 | + $ objdump -d --no-show-raw-insn vmlinux | grep -C 8 ffffffff8104ede8: | |
| 477 | + ffffffff8104edc8: mov %r8,0x8(%r8) | |
| 478 | + ffffffff8104edcc: test %r10d,%r10d | |
| 479 | + ffffffff8104edcf: js ffffffff8104ee88 <__dequeue_signal+0x168> | |
| 480 | + ffffffff8104edd5: mov %rax,%rdx | |
| 481 | + ffffffff8104edd8: mov $0xc,%ecx | |
| 482 | + ffffffff8104eddd: mov %r13,%rdi | |
| 483 | + ffffffff8104ede0: mov $0x30,%eax | |
| 484 | + ffffffff8104ede5: mov %rdx,%rsi | |
| 485 | + ffffffff8104ede8: rep movsl %ds:(%rsi),%es:(%rdi) | |
| 486 | + ffffffff8104edea: test $0x2,%al | |
| 487 | + ffffffff8104edec: je ffffffff8104edf0 <__dequeue_signal+0xd0> | |
| 488 | + ffffffff8104edee: movsw %ds:(%rsi),%es:(%rdi) | |
| 489 | + ffffffff8104edf0: test $0x1,%al | |
| 490 | + ffffffff8104edf2: je ffffffff8104edf5 <__dequeue_signal+0xd5> | |
| 491 | + ffffffff8104edf4: movsb %ds:(%rsi),%es:(%rdi) | |
| 492 | + ffffffff8104edf5: mov %r8,%rdi | |
| 493 | + ffffffff8104edf8: callq ffffffff8104de60 <__sigqueue_free> | |
| 494 | + | |
| 495 | +As expected, it's the "``rep movsl``" instruction from the ``memcpy()`` | |
| 496 | +that causes the warning. We know about ``REP MOVSL`` that it uses the register | |
| 497 | +``RCX`` to count the number of remaining iterations. By taking a look at the | |
| 498 | +register dump again (from the kmemcheck report), we can figure out how many | |
| 499 | +bytes were left to copy:: | |
| 500 | + | |
| 501 | + RAX: 0000000000000030 RBX: ffff88003d4ea968 RCX: 0000000000000009 | |
| 502 | + | |
| 503 | +By looking at the disassembly, we also see that ``%ecx`` is being loaded | |
| 504 | +with the value ``$0xc`` just before (ffffffff8104edd8), so we are very | |
| 505 | +lucky. Keep in mind that this is the number of iterations, not bytes. And | |
| 506 | +since this is a "long" operation, we need to multiply by 4 to get the | |
| 507 | +number of bytes. So this means that the uninitialized value was encountered | |
| 508 | +at 4 * (0xc - 0x9) = 12 bytes from the start of the object. | |
| 509 | + | |
| 510 | +We can now try to figure out which field of the "``struct siginfo``" that | |
| 511 | +was not initialized. This is the beginning of the struct:: | |
| 512 | + | |
| 513 | + 40 typedef struct siginfo { | |
| 514 | + 41 int si_signo; | |
| 515 | + 42 int si_errno; | |
| 516 | + 43 int si_code; | |
| 517 | + 44 | |
| 518 | + 45 union { | |
| 519 | + .. | |
| 520 | + 92 } _sifields; | |
| 521 | + 93 } siginfo_t; | |
| 522 | + | |
| 523 | +On 64-bit, the int is 4 bytes long, so it must the union member that has | |
| 524 | +not been initialized. We can verify this using gdb:: | |
| 525 | + | |
| 526 | + $ gdb vmlinux | |
| 527 | + ... | |
| 528 | + (gdb) p &((struct siginfo *) 0)->_sifields | |
| 529 | + $1 = (union {...} *) 0x10 | |
| 530 | + | |
| 531 | +Actually, it seems that the union member is located at offset 0x10 -- which | |
| 532 | +means that gcc has inserted 4 bytes of padding between the members ``si_code`` | |
| 533 | +and ``_sifields``. We can now get a fuller picture of the memory dump:: | |
| 534 | + | |
| 535 | + _----------------------------=> si_code | |
| 536 | + / _--------------------=> (padding) | |
| 537 | + | / _------------=> _sifields(._kill._pid) | |
| 538 | + | | / _----=> _sifields(._kill._uid) | |
| 539 | + | | | / | |
| 540 | + -------|-------|-------|-------| | |
| 541 | + 80000000000000000000000000000000000000000088ffff0000000000000000 | |
| 542 | + i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u u u | |
| 543 | + | |
| 544 | +This allows us to realize another important fact: ``si_code`` contains the | |
| 545 | +value 0x80. Remember that x86 is little endian, so the first 4 bytes | |
| 546 | +"80000000" are really the number 0x00000080. With a bit of research, we | |
| 547 | +find that this is actually the constant ``SI_KERNEL`` defined in | |
| 548 | +``include/asm-generic/siginfo.h``:: | |
| 549 | + | |
| 550 | + 144 #define SI_KERNEL 0x80 /* sent by the kernel from somewhere */ | |
| 551 | + | |
| 552 | +This macro is used in exactly one place in the x86 kernel: In ``send_signal()`` | |
| 553 | +in ``kernel/signal.c``:: | |
| 554 | + | |
| 555 | + 816 static int send_signal(int sig, struct siginfo *info, struct task_struct *t, | |
| 556 | + 817 int group) | |
| 557 | + 818 { | |
| 558 | + ... | |
| 559 | + 828 pending = group ? &t->signal->shared_pending : &t->pending; | |
| 560 | + ... | |
| 561 | + 851 q = __sigqueue_alloc(t, GFP_ATOMIC, (sig < SIGRTMIN && | |
| 562 | + 852 (is_si_special(info) || | |
| 563 | + 853 info->si_code >= 0))); | |
| 564 | + 854 if (q) { | |
| 565 | + 855 list_add_tail(&q->list, &pending->list); | |
| 566 | + 856 switch ((unsigned long) info) { | |
| 567 | + ... | |
| 568 | + 865 case (unsigned long) SEND_SIG_PRIV: | |
| 569 | + 866 q->info.si_signo = sig; | |
| 570 | + 867 q->info.si_errno = 0; | |
| 571 | + 868 q->info.si_code = SI_KERNEL; | |
| 572 | + 869 q->info.si_pid = 0; | |
| 573 | + 870 q->info.si_uid = 0; | |
| 574 | + 871 break; | |
| 575 | + ... | |
| 576 | + 890 } | |
| 577 | + | |
| 578 | +Not only does this match with the ``.si_code`` member, it also matches the place | |
| 579 | +we found earlier when looking for where siginfo_t objects are enqueued on the | |
| 580 | +``shared_pending`` list. | |
| 581 | + | |
| 582 | +So to sum up: It seems that it is the padding introduced by the compiler | |
| 583 | +between two struct fields that is uninitialized, and this gets reported when | |
| 584 | +we do a ``memcpy()`` on the struct. This means that we have identified a false | |
| 585 | +positive warning. | |
| 586 | + | |
| 587 | +Normally, kmemcheck will not report uninitialized accesses in ``memcpy()`` calls | |
| 588 | +when both the source and destination addresses are tracked. (Instead, we copy | |
| 589 | +the shadow bytemap as well). In this case, the destination address clearly | |
| 590 | +was not tracked. We can dig a little deeper into the stack trace from above:: | |
| 591 | + | |
| 592 | + arch/x86/kernel/signal.c:805 | |
| 593 | + arch/x86/kernel/signal.c:871 | |
| 594 | + arch/x86/kernel/entry_64.S:694 | |
| 595 | + | |
| 596 | +And we clearly see that the destination siginfo object is located on the | |
| 597 | +stack:: | |
| 598 | + | |
| 599 | + 782 static void do_signal(struct pt_regs *regs) | |
| 600 | + 783 { | |
| 601 | + 784 struct k_sigaction ka; | |
| 602 | + 785 siginfo_t info; | |
| 603 | + ... | |
| 604 | + 804 signr = get_signal_to_deliver(&info, &ka, regs, NULL); | |
| 605 | + ... | |
| 606 | + 854 } | |
| 607 | + | |
| 608 | +And this ``&info`` is what eventually gets passed to ``copy_siginfo()`` as the | |
| 609 | +destination argument. | |
| 610 | + | |
| 611 | +Now, even though we didn't find an actual error here, the example is still a | |
| 612 | +good one, because it shows how one would go about to find out what the report | |
| 613 | +was all about. | |
| 614 | + | |
| 615 | + | |
| 616 | +Annotating false positives | |
| 617 | +~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 618 | + | |
| 619 | +There are a few different ways to make annotations in the source code that | |
| 620 | +will keep kmemcheck from checking and reporting certain allocations. Here | |
| 621 | +they are: | |
| 622 | + | |
| 623 | +- ``__GFP_NOTRACK_FALSE_POSITIVE`` | |
| 624 | + This flag can be passed to ``kmalloc()`` or ``kmem_cache_alloc()`` | |
| 625 | + (therefore also to other functions that end up calling one of | |
| 626 | + these) to indicate that the allocation should not be tracked | |
| 627 | + because it would lead to a false positive report. This is a "big | |
| 628 | + hammer" way of silencing kmemcheck; after all, even if the false | |
| 629 | + positive pertains to particular field in a struct, for example, we | |
| 630 | + will now lose the ability to find (real) errors in other parts of | |
| 631 | + the same struct. | |
| 632 | + | |
| 633 | + Example:: | |
| 634 | + | |
| 635 | + /* No warnings will ever trigger on accessing any part of x */ | |
| 636 | + x = kmalloc(sizeof *x, GFP_KERNEL | __GFP_NOTRACK_FALSE_POSITIVE); | |
| 637 | + | |
| 638 | +- ``kmemcheck_bitfield_begin(name)``/``kmemcheck_bitfield_end(name)`` and | |
| 639 | + ``kmemcheck_annotate_bitfield(ptr, name)`` | |
| 640 | + The first two of these three macros can be used inside struct | |
| 641 | + definitions to signal, respectively, the beginning and end of a | |
| 642 | + bitfield. Additionally, this will assign the bitfield a name, which | |
| 643 | + is given as an argument to the macros. | |
| 644 | + | |
| 645 | + Having used these markers, one can later use | |
| 646 | + kmemcheck_annotate_bitfield() at the point of allocation, to indicate | |
| 647 | + which parts of the allocation is part of a bitfield. | |
| 648 | + | |
| 649 | + Example:: | |
| 650 | + | |
| 651 | + struct foo { | |
| 652 | + int x; | |
| 653 | + | |
| 654 | + kmemcheck_bitfield_begin(flags); | |
| 655 | + int flag_a:1; | |
| 656 | + int flag_b:1; | |
| 657 | + kmemcheck_bitfield_end(flags); | |
| 658 | + | |
| 659 | + int y; | |
| 660 | + }; | |
| 661 | + | |
| 662 | + struct foo *x = kmalloc(sizeof *x); | |
| 663 | + | |
| 664 | + /* No warnings will trigger on accessing the bitfield of x */ | |
| 665 | + kmemcheck_annotate_bitfield(x, flags); | |
| 666 | + | |
| 667 | + Note that ``kmemcheck_annotate_bitfield()`` can be used even before the | |
| 668 | + return value of ``kmalloc()`` is checked -- in other words, passing NULL | |
| 669 | + as the first argument is legal (and will do nothing). | |
| 670 | + | |
| 671 | + | |
| 672 | +Reporting errors | |
| 673 | +---------------- | |
| 674 | + | |
| 675 | +As we have seen, kmemcheck will produce false positive reports. Therefore, it | |
| 676 | +is not very wise to blindly post kmemcheck warnings to mailing lists and | |
| 677 | +maintainers. Instead, I encourage maintainers and developers to find errors | |
| 678 | +in their own code. If you get a warning, you can try to work around it, try | |
| 679 | +to figure out if it's a real error or not, or simply ignore it. Most | |
| 680 | +developers know their own code and will quickly and efficiently determine the | |
| 681 | +root cause of a kmemcheck report. This is therefore also the most efficient | |
| 682 | +way to work with kmemcheck. | |
| 683 | + | |
| 684 | +That said, we (the kmemcheck maintainers) will always be on the lookout for | |
| 685 | +false positives that we can annotate and silence. So whatever you find, | |
| 686 | +please drop us a note privately! Kernel configs and steps to reproduce (if | |
| 687 | +available) are of course a great help too. | |
| 688 | + | |
| 689 | +Happy hacking! | |
| 690 | + | |
| 691 | + | |
| 692 | +Technical description | |
| 693 | +--------------------- | |
| 694 | + | |
| 695 | +kmemcheck works by marking memory pages non-present. This means that whenever | |
| 696 | +somebody attempts to access the page, a page fault is generated. The page | |
| 697 | +fault handler notices that the page was in fact only hidden, and so it calls | |
| 698 | +on the kmemcheck code to make further investigations. | |
| 699 | + | |
| 700 | +When the investigations are completed, kmemcheck "shows" the page by marking | |
| 701 | +it present (as it would be under normal circumstances). This way, the | |
| 702 | +interrupted code can continue as usual. | |
| 703 | + | |
| 704 | +But after the instruction has been executed, we should hide the page again, so | |
| 705 | +that we can catch the next access too! Now kmemcheck makes use of a debugging | |
| 706 | +feature of the processor, namely single-stepping. When the processor has | |
| 707 | +finished the one instruction that generated the memory access, a debug | |
| 708 | +exception is raised. From here, we simply hide the page again and continue | |
| 709 | +execution, this time with the single-stepping feature turned off. | |
| 710 | + | |
| 711 | +kmemcheck requires some assistance from the memory allocator in order to work. | |
| 712 | +The memory allocator needs to | |
| 713 | + | |
| 714 | + 1. Tell kmemcheck about newly allocated pages and pages that are about to | |
| 715 | + be freed. This allows kmemcheck to set up and tear down the shadow memory | |
| 716 | + for the pages in question. The shadow memory stores the status of each | |
| 717 | + byte in the allocation proper, e.g. whether it is initialized or | |
| 718 | + uninitialized. | |
| 719 | + | |
| 720 | + 2. Tell kmemcheck which parts of memory should be marked uninitialized. | |
| 721 | + There are actually a few more states, such as "not yet allocated" and | |
| 722 | + "recently freed". | |
| 723 | + | |
| 724 | +If a slab cache is set up using the SLAB_NOTRACK flag, it will never return | |
| 725 | +memory that can take page faults because of kmemcheck. | |
| 726 | + | |
| 727 | +If a slab cache is NOT set up using the SLAB_NOTRACK flag, callers can still | |
| 728 | +request memory with the __GFP_NOTRACK or __GFP_NOTRACK_FALSE_POSITIVE flags. | |
| 729 | +This does not prevent the page faults from occurring, however, but marks the | |
| 730 | +object in question as being initialized so that no warnings will ever be | |
| 731 | +produced for this object. | |
| 732 | + | |
| 733 | +Currently, the SLAB and SLUB allocators are supported by kmemcheck. | |
| @@ -1,15 +1,12 @@ | ||
| 1 | 1 | Kernel Memory Leak Detector |
| 2 | 2 | =========================== |
| 3 | 3 | |
| 4 | −Introduction | |
| 5 | −------------ | |
| 6 | − | |
| 7 | 4 | Kmemleak provides a way of detecting possible kernel memory leaks in a |
| 8 | 5 | way similar to a tracing garbage collector |
| 9 | 6 | (https://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors), |
| 10 | 7 | with the difference that the orphan objects are not freed but only |
| 11 | 8 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the |
| 12 | −Valgrind tool (memcheck --leak-check) to detect the memory leaks in | |
| 9 | +Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in | |
| 13 | 10 | user-space applications. |
| 14 | 11 | Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile. |
| 15 | 12 | |
| @@ -19,20 +16,20 @@ Usage · 3 unmodified lines | ||
| 19 | 16 | CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel |
| 20 | 17 | thread scans the memory every 10 minutes (by default) and prints the |
| 21 | 18 | number of new unreferenced objects found. To display the details of all |
| 22 | −the possible memory leaks: | |
| 19 | +the possible memory leaks:: | |
| 23 | 20 | |
| 24 | 21 | # mount -t debugfs nodev /sys/kernel/debug/ |
| 25 | 22 | # cat /sys/kernel/debug/kmemleak |
| 26 | 23 | |
| 27 | −To trigger an intermediate memory scan: | |
| 24 | +To trigger an intermediate memory scan:: | |
| 28 | 25 | |
| 29 | 26 | # echo scan > /sys/kernel/debug/kmemleak |
| 30 | 27 | |
| 31 | −To clear the list of all current possible memory leaks: | |
| 28 | +To clear the list of all current possible memory leaks:: | |
| 32 | 29 | |
| 33 | 30 | # echo clear > /sys/kernel/debug/kmemleak |
| 34 | 31 | |
| 35 | −New leaks will then come up upon reading /sys/kernel/debug/kmemleak | |
| 32 | +New leaks will then come up upon reading ``/sys/kernel/debug/kmemleak`` | |
| 36 | 33 | again. |
| 37 | 34 | |
| 38 | 35 | Note that the orphan objects are listed in the order they were allocated |
| @@ -40,22 +37,31 @@ and one object at the beginning of the list may cause other subsequent · 1 unmodified line | ||
| 40 | 37 | objects to be reported as orphan. |
| 41 | 38 | |
| 42 | 39 | Memory scanning parameters can be modified at run-time by writing to the |
| 43 | −/sys/kernel/debug/kmemleak file. The following parameters are supported: | |
| 44 | − | |
| 45 | − off - disable kmemleak (irreversible) | |
| 46 | − stack=on - enable the task stacks scanning (default) | |
| 47 | − stack=off - disable the tasks stacks scanning | |
| 48 | − scan=on - start the automatic memory scanning thread (default) | |
| 49 | − scan=off - stop the automatic memory scanning thread | |
| 50 | − scan=<secs> - set the automatic memory scanning period in seconds | |
| 51 | − (default 600, 0 to stop the automatic scanning) | |
| 52 | − scan - trigger a memory scan | |
| 53 | − clear - clear list of current memory leak suspects, done by | |
| 54 | − marking all current reported unreferenced objects grey, | |
| 55 | − or free all kmemleak objects if kmemleak has been disabled. | |
| 56 | − dump=<addr> - dump information about the object found at <addr> | |
| 57 | − | |
| 58 | −Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on | |
| 40 | +``/sys/kernel/debug/kmemleak`` file. The following parameters are supported: | |
| 41 | + | |
| 42 | +- off | |
| 43 | + disable kmemleak (irreversible) | |
| 44 | +- stack=on | |
| 45 | + enable the task stacks scanning (default) | |
| 46 | +- stack=off | |
| 47 | + disable the tasks stacks scanning | |
| 48 | +- scan=on | |
| 49 | + start the automatic memory scanning thread (default) | |
| 50 | +- scan=off | |
| 51 | + stop the automatic memory scanning thread | |
| 52 | +- scan=<secs> | |
| 53 | + set the automatic memory scanning period in seconds | |
| 54 | + (default 600, 0 to stop the automatic scanning) | |
| 55 | +- scan | |
| 56 | + trigger a memory scan | |
| 57 | +- clear | |
| 58 | + clear list of current memory leak suspects, done by | |
| 59 | + marking all current reported unreferenced objects grey, | |
| 60 | + or free all kmemleak objects if kmemleak has been disabled. | |
| 61 | +- dump=<addr> | |
| 62 | + dump information about the object found at <addr> | |
| 63 | + | |
| 64 | +Kmemleak can also be disabled at boot-time by passing ``kmemleak=off`` on | |
| 59 | 65 | the kernel command line. |
| 60 | 66 | |
| 61 | 67 | Memory may be allocated or freed before kmemleak is initialised and |
| @@ -63,13 +69,14 @@ these actions are stored in an early log buffer. The size of this buffer · 1 unmodified line | ||
| 63 | 69 | is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option. |
| 64 | 70 | |
| 65 | 71 | If CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF are enabled, the kmemleak is |
| 66 | −disabled by default. Passing "kmemleak=on" on the kernel command | |
| 72 | +disabled by default. Passing ``kmemleak=on`` on the kernel command | |
| 67 | 73 | line enables the function. |
| 68 | 74 | |
| 69 | 75 | Basic Algorithm |
| 70 | 76 | --------------- |
| 71 | 77 | |
| 72 | −The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and | |
| 78 | +The memory allocations via :c:func:`kmalloc`, :c:func:`vmalloc`, | |
| 79 | +:c:func:`kmem_cache_alloc` and | |
| 73 | 80 | friends are traced and the pointers, together with additional |
| 74 | 81 | information like size and stack trace, are stored in a rbtree. |
| 75 | 82 | The corresponding freeing function calls are tracked and the pointers |
| @@ -113,13 +120,13 @@ when doing development. To work around these situations you can use the · 37 unmodified lines | ||
| 113 | 120 | you can find new unreferenced objects; this should help with testing |
| 114 | 121 | specific sections of code. |
| 115 | 122 | |
| 116 | −To test a critical section on demand with a clean kmemleak do: | |
| 123 | +To test a critical section on demand with a clean kmemleak do:: | |
| 117 | 124 | |
| 118 | 125 | # echo clear > /sys/kernel/debug/kmemleak |
| 119 | 126 | ... test your kernel or modules ... |
| 120 | 127 | # echo scan > /sys/kernel/debug/kmemleak |
| 121 | 128 | |
| 122 | −Then as usual to get your report with: | |
| 129 | +Then as usual to get your report with:: | |
| 123 | 130 | |
| 124 | 131 | # cat /sys/kernel/debug/kmemleak |
| 125 | 132 | |
| @@ -131,7 +138,7 @@ disabled by the user or due to an fatal error, internal kmemleak objects · 5 unmodified lines | ||
| 131 | 138 | won't be freed when kmemleak is disabled, and those objects may occupy |
| 132 | 139 | a large part of physical memory. |
| 133 | 140 | |
| 134 | −In this situation, you may reclaim memory with: | |
| 141 | +In this situation, you may reclaim memory with:: | |
| 135 | 142 | |
| 136 | 143 | # echo clear > /sys/kernel/debug/kmemleak |
| 137 | 144 | |
| @@ -140,20 +147,29 @@ Kmemleak API · 2 unmodified lines | ||
| 140 | 147 | |
| 141 | 148 | See the include/linux/kmemleak.h header for the functions prototype. |
| 142 | 149 | |
| 143 | −kmemleak_init - initialize kmemleak | |
| 144 | −kmemleak_alloc - notify of a memory block allocation | |
| 145 | −kmemleak_alloc_percpu - notify of a percpu memory block allocation | |
| 146 | −kmemleak_free - notify of a memory block freeing | |
| 147 | −kmemleak_free_part - notify of a partial memory block freeing | |
| 148 | −kmemleak_free_percpu - notify of a percpu memory block freeing | |
| 149 | −kmemleak_update_trace - update object allocation stack trace | |
| 150 | −kmemleak_not_leak - mark an object as not a leak | |
| 151 | −kmemleak_ignore - do not scan or report an object as leak | |
| 152 | −kmemleak_scan_area - add scan areas inside a memory block | |
| 153 | −kmemleak_no_scan - do not scan a memory block | |
| 154 | −kmemleak_erase - erase an old value in a pointer variable | |
| 155 | −kmemleak_alloc_recursive - as kmemleak_alloc but checks the recursiveness | |
| 156 | −kmemleak_free_recursive - as kmemleak_free but checks the recursiveness | |
| 150 | +- ``kmemleak_init`` - initialize kmemleak | |
| 151 | +- ``kmemleak_alloc`` - notify of a memory block allocation | |
| 152 | +- ``kmemleak_alloc_percpu`` - notify of a percpu memory block allocation | |
| 153 | +- ``kmemleak_free`` - notify of a memory block freeing | |
| 154 | +- ``kmemleak_free_part`` - notify of a partial memory block freeing | |
| 155 | +- ``kmemleak_free_percpu`` - notify of a percpu memory block freeing | |
| 156 | +- ``kmemleak_update_trace`` - update object allocation stack trace | |
| 157 | +- ``kmemleak_not_leak`` - mark an object as not a leak | |
| 158 | +- ``kmemleak_ignore`` - do not scan or report an object as leak | |
| 159 | +- ``kmemleak_scan_area`` - add scan areas inside a memory block | |
| 160 | +- ``kmemleak_no_scan`` - do not scan a memory block | |
| 161 | +- ``kmemleak_erase`` - erase an old value in a pointer variable | |
| 162 | +- ``kmemleak_alloc_recursive`` - as kmemleak_alloc but checks the recursiveness | |
| 163 | +- ``kmemleak_free_recursive`` - as kmemleak_free but checks the recursiveness | |
| 164 | + | |
| 165 | +The following functions take a physical address as the object pointer | |
| 166 | +and only perform the corresponding action if the address has a lowmem | |
| 167 | +mapping: | |
| 168 | + | |
| 169 | +- ``kmemleak_alloc_phys`` | |
| 170 | +- ``kmemleak_free_part_phys`` | |
| 171 | +- ``kmemleak_not_leak_phys`` | |
| 172 | +- ``kmemleak_ignore_phys`` | |
| 157 | 173 | |
| 158 | 174 | Dealing with false positives/negatives |
| 159 | 175 | -------------------------------------- |
| @@ -1,11 +1,20 @@ | ||
| 1 | −Copyright 2004 Linus Torvalds | |
| 2 | −Copyright 2004 Pavel Machek <pavel@ucw.cz> | |
| 3 | −Copyright 2006 Bob Copeland <me@bobcopeland.com> | |
| 1 | +.. Copyright 2004 Linus Torvalds | |
| 2 | +.. Copyright 2004 Pavel Machek <pavel@ucw.cz> | |
| 3 | +.. Copyright 2006 Bob Copeland <me@bobcopeland.com> | |
| 4 | + | |
| 5 | +Sparse | |
| 6 | +====== | |
| 7 | + | |
| 8 | +Sparse is a semantic checker for C programs; it can be used to find a | |
| 9 | +number of potential problems with kernel code. See | |
| 10 | +https://lwn.net/Articles/689907/ for an overview of sparse; this document | |
| 11 | +contains some kernel-specific sparse information. | |
| 12 | + | |
| 4 | 13 | |
| 5 | 14 | Using sparse for typechecking |
| 6 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 15 | +----------------------------- | |
| 7 | 16 | |
| 8 | −"__bitwise" is a type attribute, so you have to do something like this: | |
| 17 | +"__bitwise" is a type attribute, so you have to do something like this:: | |
| 9 | 18 | |
| 10 | 19 | typedef int __bitwise pm_request_t; |
| 11 | 20 | |
| @@ -20,13 +29,13 @@ but in this case we really _do_ want to force the conversion). And because · 8 unmodified lines | ||
| 20 | 29 | the enum values are all the same type, now "enum pm_request" will be that |
| 21 | 30 | type too. |
| 22 | 31 | |
| 23 | −And with gcc, all the __bitwise/__force stuff goes away, and it all ends | |
| 24 | −up looking just like integers to gcc. | |
| 32 | +And with gcc, all the "__bitwise"/"__force stuff" goes away, and it all | |
| 33 | +ends up looking just like integers to gcc. | |
| 25 | 34 | |
| 26 | 35 | Quite frankly, you don't need the enum there. The above all really just |
| 27 | 36 | boils down to one special "int __bitwise" type. |
| 28 | 37 | |
| 29 | −So the simpler way is to just do | |
| 38 | +So the simpler way is to just do:: | |
| 30 | 39 | |
| 31 | 40 | typedef int __bitwise pm_request_t; |
| 32 | 41 | |
| @@ -50,7 +59,7 @@ __bitwise - noisy stuff; in particular, __le*/__be* are that. We really · 17 unmodified lines | ||
| 50 | 59 | don't want to drown in noise unless we'd explicitly asked for it. |
| 51 | 60 | |
| 52 | 61 | Using sparse for lock checking |
| 53 | −~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| 62 | +------------------------------ | |
| 54 | 63 | |
| 55 | 64 | The following macros are undefined for gcc and defined during a sparse |
| 56 | 65 | run to use the "context" tracking feature of sparse, applied to |
| @@ -69,22 +78,22 @@ annotation is needed. The tree annotations above are for cases where · 12 unmodified lines | ||
| 69 | 78 | sparse would otherwise report a context imbalance. |
| 70 | 79 | |
| 71 | 80 | Getting sparse |
| 72 | −~~~~~~~~~~~~~~ | |
| 81 | +-------------- | |
| 73 | 82 | |
| 74 | 83 | You can get latest released versions from the Sparse homepage at |
| 75 | 84 | https://sparse.wiki.kernel.org/index.php/Main_Page |
| 76 | 85 | |
| 77 | 86 | Alternatively, you can get snapshots of the latest development version |
| 78 | −of sparse using git to clone.. | |
| 87 | +of sparse using git to clone:: | |
| 79 | 88 | |
| 80 | 89 | git://git.kernel.org/pub/scm/devel/sparse/sparse.git |
| 81 | 90 | |
| 82 | −DaveJ has hourly generated tarballs of the git tree available at.. | |
| 91 | +DaveJ has hourly generated tarballs of the git tree available at:: | |
| 83 | 92 | |
| 84 | 93 | http://www.codemonkey.org.uk/projects/git-snapshots/sparse/ |
| 85 | 94 | |
| 86 | 95 | |
| 87 | −Once you have it, just do | |
| 96 | +Once you have it, just do:: | |
| 88 | 97 | |
| 89 | 98 | make |
| 90 | 99 | make install |
| @@ -92,7 +101,7 @@ Once you have it, just do · 1 unmodified line | ||
| 92 | 101 | as a regular user, and it will install sparse in your ~/bin directory. |
| 93 | 102 | |
| 94 | 103 | Using sparse |
| 95 | −~~~~~~~~~~~~ | |
| 104 | +------------ | |
| 96 | 105 | |
| 97 | 106 | Do a kernel make with "make C=1" to run sparse on all the C files that get |
| 98 | 107 | recompiled, or use "make C=2" to run sparse on the files whether they need to |
| @@ -101,7 +110,7 @@ have already built it. · 2 unmodified lines | ||
| 101 | 110 | |
| 102 | 111 | The optional make variable CF can be used to pass arguments to sparse. The |
| 103 | 112 | build system passes -Wbitwise to sparse automatically. To perform endianness |
| 104 | −checks, you may define __CHECK_ENDIAN__: | |
| 113 | +checks, you may define __CHECK_ENDIAN__:: | |
| 105 | 114 | |
| 106 | 115 | make C=2 CF="-D__CHECK_ENDIAN__" |
| 107 | 116 | |
| @@ -0,0 +1,25 @@ | ||
| 1 | +================================ | |
| 2 | +Development tools for the kernel | |
| 3 | +================================ | |
| 4 | + | |
| 5 | +This document is a collection of documents about development tools that can | |
| 6 | +be used to work on the kernel. For now, the documents have been pulled | |
| 7 | +together without any significant effot to integrate them into a coherent | |
| 8 | +whole; patches welcome! | |
| 9 | + | |
| 10 | +.. class:: toc-title | |
| 11 | + | |
| 12 | + Table of contents | |
| 13 | + | |
| 14 | +.. toctree:: | |
| 15 | + :maxdepth: 2 | |
| 16 | + | |
| 17 | + coccinelle | |
| 18 | + sparse | |
| 19 | + kcov | |
| 20 | + gcov | |
| 21 | + kasan | |
| 22 | + ubsan | |
| 23 | + kmemleak | |
| 24 | + kmemcheck | |
| 25 | + gdb-kernel-debugging | |
| @@ -1,7 +1,5 @@ | ||
| 1 | −Undefined Behavior Sanitizer - UBSAN | |
| 2 | − | |
| 3 | −Overview | |
| 4 | −-------- | |
| 1 | +The Undefined Behavior Sanitizer - UBSAN | |
| 2 | +======================================== | |
| 5 | 3 | |
| 6 | 4 | UBSAN is a runtime undefined behaviour checker. |
| 7 | 5 | |
| @@ -10,11 +8,13 @@ Compiler inserts code that perform certain kinds of checks before operations · 2 unmodified lines | ||
| 10 | 8 | that may cause UB. If check fails (i.e. UB detected) __ubsan_handle_* |
| 11 | 9 | function called to print error message. |
| 12 | 10 | |
| 13 | −GCC has that feature since 4.9.x [1] (see -fsanitize=undefined option and | |
| 14 | −its suboptions). GCC 5.x has more checkers implemented [2]. | |
| 11 | +GCC has that feature since 4.9.x [1_] (see ``-fsanitize=undefined`` option and | |
| 12 | +its suboptions). GCC 5.x has more checkers implemented [2_]. | |
| 15 | 13 | |
| 16 | 14 | Report example |
| 17 | −--------------- | |
| 15 | +-------------- | |
| 16 | + | |
| 17 | +:: | |
| 18 | 18 | |
| 19 | 19 | ================================================================================ |
| 20 | 20 | UBSAN: Undefined behaviour in ../include/linux/bitops.h:110:33 |
| @@ -47,29 +47,33 @@ Report example · 26 unmodified lines | ||
| 47 | 47 | Usage |
| 48 | 48 | ----- |
| 49 | 49 | |
| 50 | −To enable UBSAN configure kernel with: | |
| 50 | +To enable UBSAN configure kernel with:: | |
| 51 | 51 | |
| 52 | 52 | CONFIG_UBSAN=y |
| 53 | 53 | |
| 54 | −and to check the entire kernel: | |
| 54 | +and to check the entire kernel:: | |
| 55 | 55 | |
| 56 | 56 | CONFIG_UBSAN_SANITIZE_ALL=y |
| 57 | 57 | |
| 58 | 58 | To enable instrumentation for specific files or directories, add a line |
| 59 | 59 | similar to the following to the respective kernel Makefile: |
| 60 | 60 | |
| 61 | − For a single file (e.g. main.o): | |
| 62 | − UBSAN_SANITIZE_main.o := y | |
| 61 | +- For a single file (e.g. main.o):: | |
| 62 | + | |
| 63 | + UBSAN_SANITIZE_main.o := y | |
| 63 | 64 | |
| 64 | − For all files in one directory: | |
| 65 | − UBSAN_SANITIZE := y | |
| 65 | +- For all files in one directory:: | |
| 66 | + | |
| 67 | + UBSAN_SANITIZE := y | |
| 66 | 68 | |
| 67 | 69 | To exclude files from being instrumented even if |
| 68 | −CONFIG_UBSAN_SANITIZE_ALL=y, use: | |
| 70 | +``CONFIG_UBSAN_SANITIZE_ALL=y``, use:: | |
| 71 | + | |
| 72 | + UBSAN_SANITIZE_main.o := n | |
| 73 | + | |
| 74 | +and:: | |
| 69 | 75 | |
| 70 | − UBSAN_SANITIZE_main.o := n | |
| 71 | − and: | |
| 72 | − UBSAN_SANITIZE := n | |
| 76 | + UBSAN_SANITIZE := n | |
| 73 | 77 | |
| 74 | 78 | Detection of unaligned accesses controlled through the separate option - |
| 75 | 79 | CONFIG_UBSAN_ALIGNMENT. It's off by default on architectures that support |
| @@ -80,5 +84,5 @@ reports. · 4 unmodified lines | ||
| 80 | 84 | References |
| 81 | 85 | ---------- |
| 82 | 86 | |
| 83 | −[1] - https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html | |
| 84 | −[2] - https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html | |
| 87 | +.. _1: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html | |
| 88 | +.. _2: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html | |
| @@ -1,16 +1,8 @@ | ||
| 1 | −1: A GUIDE TO THE KERNEL DEVELOPMENT PROCESS | |
| 1 | +Introdution | |
| 2 | +=========== | |
| 2 | 3 | |
| 3 | −The purpose of this document is to help developers (and their managers) | |
| 4 | −work with the development community with a minimum of frustration. It is | |
| 5 | −an attempt to document how this community works in a way which is | |
| 6 | −accessible to those who are not intimately familiar with Linux kernel | |
| 7 | −development (or, indeed, free software development in general). While | |
| 8 | −there is some technical material here, this is very much a process-oriented | |
| 9 | −discussion which does not require a deep knowledge of kernel programming to | |
| 10 | −understand. | |
| 11 | − | |
| 12 | − | |
| 13 | −1.1: EXECUTIVE SUMMARY | |
| 4 | +Executive summary | |
| 5 | +----------------- | |
| 14 | 6 | |
| 15 | 7 | The rest of this section covers the scope of the kernel development process |
| 16 | 8 | and the kinds of frustrations that developers and their employers can |
| @@ -20,41 +12,41 @@ availability to users, community support in many forms, and the ability to · 3 unmodified lines | ||
| 20 | 12 | influence the direction of kernel development. Code contributed to the |
| 21 | 13 | Linux kernel must be made available under a GPL-compatible license. |
| 22 | 14 | |
| 23 | −Section 2 introduces the development process, the kernel release cycle, and | |
| 24 | −the mechanics of the merge window. The various phases in the patch | |
| 25 | −development, review, and merging cycle are covered. There is some | |
| 15 | +:ref:`development_process` introduces the development process, the kernel | |
| 16 | +release cycle, and the mechanics of the merge window. The various phases in | |
| 17 | +the patch development, review, and merging cycle are covered. There is some | |
| 26 | 18 | discussion of tools and mailing lists. Developers wanting to get started |
| 27 | 19 | with kernel development are encouraged to track down and fix bugs as an |
| 28 | 20 | initial exercise. |
| 29 | 21 | |
| 30 | −Section 3 covers early-stage project planning, with an emphasis on | |
| 31 | −involving the development community as soon as possible. | |
| 22 | +:ref:`development_early_stage` covers early-stage project planning, with an | |
| 23 | +emphasis on involving the development community as soon as possible. | |
| 32 | 24 | |
| 33 | −Section 4 is about the coding process; several pitfalls which have been | |
| 34 | −encountered by other developers are discussed. Some requirements for | |
| 25 | +:ref:`development_coding` is about the coding process; several pitfalls which | |
| 26 | +have been encountered by other developers are discussed. Some requirements for | |
| 35 | 27 | patches are covered, and there is an introduction to some of the tools |
| 36 | 28 | which can help to ensure that kernel patches are correct. |
| 37 | 29 | |
| 38 | −Section 5 talks about the process of posting patches for review. To be | |
| 39 | −taken seriously by the development community, patches must be properly | |
| 40 | −formatted and described, and they must be sent to the right place. | |
| 30 | +:ref:`development_posting` talks about the process of posting patches for | |
| 31 | +review. To be taken seriously by the development community, patches must be | |
| 32 | +properly formatted and described, and they must be sent to the right place. | |
| 41 | 33 | Following the advice in this section should help to ensure the best |
| 42 | 34 | possible reception for your work. |
| 43 | 35 | |
| 44 | −Section 6 covers what happens after posting patches; the job is far from | |
| 45 | −done at that point. Working with reviewers is a crucial part of the | |
| 46 | −development process; this section offers a number of tips on how to avoid | |
| 47 | −problems at this important stage. Developers are cautioned against | |
| 36 | +:ref:`development_followthrough` covers what happens after posting patches; the | |
| 37 | +job is far from done at that point. Working with reviewers is a crucial part | |
| 38 | +of the development process; this section offers a number of tips on how to | |
| 39 | +avoid problems at this important stage. Developers are cautioned against | |
| 48 | 40 | assuming that the job is done when a patch is merged into the mainline. |
| 49 | 41 | |
| 50 | −Section 7 introduces a couple of "advanced" topics: managing patches with | |
| 51 | −git and reviewing patches posted by others. | |
| 52 | − | |
| 53 | −Section 8 concludes the document with pointers to sources for more | |
| 54 | −information on kernel development. | |
| 42 | +:ref:`development_advancedtopics` introduces a couple of "advanced" topics: | |
| 43 | +managing patches with git and reviewing patches posted by others. | |
| 55 | 44 | |
| 45 | +:ref:`development_conclusion` concludes the document with pointers to sources | |
| 46 | +for more information on kernel development. | |
| 56 | 47 | |
| 57 | −1.2: WHAT THIS DOCUMENT IS ABOUT | |
| 48 | +What this document is about | |
| 49 | +--------------------------- | |
| 58 | 50 | |
| 59 | 51 | The Linux kernel, at over 8 million lines of code and well over 1000 |
| 60 | 52 | contributors to each release, is one of the largest and most active free |
| @@ -108,8 +100,8 @@ community is always in need of developers who will help to make the kernel · 47 unmodified lines | ||
| 108 | 100 | better; the following text should help you - or those who work for you - |
| 109 | 101 | join our community. |
| 110 | 102 | |
| 111 | − | |
| 112 | −1.3: CREDITS | |
| 103 | +Credits | |
| 104 | +------- | |
| 113 | 105 | |
| 114 | 106 | This document was written by Jonathan Corbet, corbet@lwn.net. It has been |
| 115 | 107 | improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland |
| @@ -120,8 +112,8 @@ Jochen Voß. · 4 unmodified lines | ||
| 120 | 112 | This work was supported by the Linux Foundation; thanks especially to |
| 121 | 113 | Amanda McPherson, who saw the value of this effort and made it all happen. |
| 122 | 114 | |
| 123 | − | |
| 124 | −1.4: THE IMPORTANCE OF GETTING CODE INTO THE MAINLINE | |
| 115 | +The importance of getting code into the mainline | |
| 116 | +------------------------------------------------ | |
| 125 | 117 | |
| 126 | 118 | Some companies and developers occasionally wonder why they should bother |
| 127 | 119 | learning how to work with the kernel community and get their code into the |
| @@ -233,8 +225,8 @@ commercial life, after which a new version must be released. At that · 105 unmodified lines | ||
| 233 | 225 | point, vendors whose code is in the mainline and well maintained will be |
| 234 | 226 | much better positioned to get the new product ready for market quickly. |
| 235 | 227 | |
| 236 | − | |
| 237 | −1.5: LICENSING | |
| 228 | +Licensing | |
| 229 | +--------- | |
| 238 | 230 | |
| 239 | 231 | Code is contributed to the Linux kernel under a number of licenses, but all |
| 240 | 232 | code must be compatible with version 2 of the GNU General Public License |
| @@ -1,4 +1,7 @@ | ||
| 1 | −2: HOW THE DEVELOPMENT PROCESS WORKS | |
| 1 | +.. _development_process: | |
| 2 | + | |
| 3 | +How the development process works | |
| 4 | +================================= | |
| 2 | 5 | |
| 3 | 6 | Linux kernel development in the early 1990's was a pretty loose affair, |
| 4 | 7 | with relatively small numbers of users and developers involved. With a |
| @@ -7,19 +10,21 @@ course of one year, the kernel has since had to evolve a number of · 2 unmodified lines | ||
| 7 | 10 | processes to keep development happening smoothly. A solid understanding of |
| 8 | 11 | how the process works is required in order to be an effective part of it. |
| 9 | 12 | |
| 10 | − | |
| 11 | −2.1: THE BIG PICTURE | |
| 13 | +The big picture | |
| 14 | +--------------- | |
| 12 | 15 | |
| 13 | 16 | The kernel developers use a loosely time-based release process, with a new |
| 14 | 17 | major kernel release happening every two or three months. The recent |
| 15 | 18 | release history looks like this: |
| 16 | 19 | |
| 20 | + ====== ================= | |
| 17 | 21 | 2.6.38 March 14, 2011 |
| 18 | 22 | 2.6.37 January 4, 2011 |
| 19 | 23 | 2.6.36 October 20, 2010 |
| 20 | 24 | 2.6.35 August 1, 2010 |
| 21 | 25 | 2.6.34 May 15, 2010 |
| 22 | 26 | 2.6.33 February 24, 2010 |
| 27 | + ====== ================= | |
| 23 | 28 | |
| 24 | 29 | Every 2.6.x release is a major kernel release with new features, internal |
| 25 | 30 | API changes, and more. A typical 2.6 release can contain nearly 10,000 |
| @@ -68,6 +73,7 @@ At that point the whole process starts over again. · 42 unmodified lines | ||
| 68 | 73 | As an example, here is how the 2.6.38 development cycle went (all dates in |
| 69 | 74 | 2011): |
| 70 | 75 | |
| 76 | + ============== =============================== | |
| 71 | 77 | January 4 2.6.37 stable release |
| 72 | 78 | January 18 2.6.38-rc1, merge window closes |
| 73 | 79 | January 21 2.6.38-rc2 |
| @@ -78,6 +84,7 @@ As an example, here is how the 2.6.38 development cycle went (all dates in · 4 unmodified lines | ||
| 78 | 84 | March 1 2.6.38-rc7 |
| 79 | 85 | March 7 2.6.38-rc8 |
| 80 | 86 | March 14 2.6.38 stable release |
| 87 | + ============== =============================== | |
| 81 | 88 | |
| 82 | 89 | How do the developers decide when to close the development cycle and create |
| 83 | 90 | the stable release? The most significant metric used is the list of |
| @@ -105,11 +112,13 @@ next development kernel. Kernels will typically receive stable updates for · 21 unmodified lines | ||
| 105 | 112 | a little more than one development cycle past their initial release. So, |
| 106 | 113 | for example, the 2.6.36 kernel's history looked like: |
| 107 | 114 | |
| 115 | + ============== =============================== | |
| 108 | 116 | October 10 2.6.36 stable release |
| 109 | 117 | November 22 2.6.36.1 |
| 110 | 118 | December 9 2.6.36.2 |
| 111 | 119 | January 7 2.6.36.3 |
| 112 | 120 | February 17 2.6.36.4 |
| 121 | + ============== =============================== | |
| 113 | 122 | |
| 114 | 123 | 2.6.36.4 was the final stable update for the 2.6.36 release. |
| 115 | 124 | |
| @@ -117,9 +126,11 @@ Some kernels are designated "long term" kernels; they will receive support · 1 unmodified line | ||
| 117 | 126 | for a longer period. As of this writing, the current long term kernels |
| 118 | 127 | and their maintainers are: |
| 119 | 128 | |
| 129 | + ====== ====================== =========================== | |
| 120 | 130 | 2.6.27 Willy Tarreau (Deep-frozen stable kernel) |
| 121 | 131 | 2.6.32 Greg Kroah-Hartman |
| 122 | 132 | 2.6.35 Andi Kleen (Embedded flag kernel) |
| 133 | + ====== ====================== =========================== | |
| 123 | 134 | |
| 124 | 135 | The selection of a kernel for long-term support is purely a matter of a |
| 125 | 136 | maintainer having the need and the time to maintain that release. There |
| @@ -127,7 +138,8 @@ are no known plans for long-term support for any specific upcoming · 1 unmodified line | ||
| 127 | 138 | release. |
| 128 | 139 | |
| 129 | 140 | |
| 130 | −2.2: THE LIFECYCLE OF A PATCH | |
| 141 | +The lifecycle of a patch | |
| 142 | +------------------------ | |
| 131 | 143 | |
| 132 | 144 | Patches do not go directly from the developer's keyboard into the mainline |
| 133 | 145 | kernel. There is, instead, a somewhat involved (if somewhat informal) |
| @@ -195,8 +207,8 @@ is to try to cut the process down to a single "merging into the mainline" · 61 unmodified lines | ||
| 195 | 207 | step. This approach invariably leads to frustration for everybody |
| 196 | 208 | involved. |
| 197 | 209 | |
| 198 | − | |
| 199 | −2.3: HOW PATCHES GET INTO THE KERNEL | |
| 210 | +How patches get into the Kernel | |
| 211 | +------------------------------- | |
| 200 | 212 | |
| 201 | 213 | There is exactly one person who can merge patches into the mainline kernel |
| 202 | 214 | repository: Linus Torvalds. But, of the over 9,500 patches which went |
| @@ -242,7 +254,8 @@ finding the right maintainer. Sending patches directly to Linus is not · 39 unmodified lines | ||
| 242 | 254 | normally the right way to go. |
| 243 | 255 | |
| 244 | 256 | |
| 245 | −2.4: NEXT TREES | |
| 257 | +Next trees | |
| 258 | +---------- | |
| 246 | 259 | |
| 247 | 260 | The chain of subsystem trees guides the flow of patches into the kernel, |
| 248 | 261 | but it also raises an interesting question: what if somebody wants to look |
| @@ -294,7 +307,8 @@ all patches merged during a given merge window should really have found · 45 unmodified lines | ||
| 294 | 307 | their way into linux-next some time before the merge window opens. |
| 295 | 308 | |
| 296 | 309 | |
| 297 | −2.4.1: STAGING TREES | |
| 310 | +Staging trees | |
| 311 | +------------- | |
| 298 | 312 | |
| 299 | 313 | The kernel source tree contains the drivers/staging/ directory, where |
| 300 | 314 | many sub-directories for drivers or filesystems that are on their way to |
| @@ -322,7 +336,8 @@ staging drivers. So staging is, at best, a stop on the way toward becoming · 21 unmodified lines | ||
| 322 | 336 | a proper mainline driver. |
| 323 | 337 | |
| 324 | 338 | |
| 325 | −2.5: TOOLS | |
| 339 | +Tools | |
| 340 | +----- | |
| 326 | 341 | |
| 327 | 342 | As can be seen from the above text, the kernel development process depends |
| 328 | 343 | heavily on the ability to herd collections of patches in various |
| @@ -368,7 +383,8 @@ upstream. For the management of certain kinds of trees (-mm, for example), · 39 unmodified lines | ||
| 368 | 383 | quilt is the best tool for the job. |
| 369 | 384 | |
| 370 | 385 | |
| 371 | −2.6: MAILING LISTS | |
| 386 | +Mailing lists | |
| 387 | +------------- | |
| 372 | 388 | |
| 373 | 389 | A great deal of Linux kernel development work is done by way of mailing |
| 374 | 390 | lists. It is hard to be a fully-functioning member of the community |
| @@ -436,7 +452,8 @@ filesystem, etc. subsystems. The best place to look for mailing lists is · 61 unmodified lines | ||
| 436 | 452 | in the MAINTAINERS file packaged with the kernel source. |
| 437 | 453 | |
| 438 | 454 | |
| 439 | −2.7: GETTING STARTED WITH KERNEL DEVELOPMENT | |
| 455 | +Getting started with Kernel development | |
| 456 | +--------------------------------------- | |
| 440 | 457 | |
| 441 | 458 | Questions about how to get started with the kernel development process are |
| 442 | 459 | common - from both individuals and companies. Equally common are missteps |
| @@ -463,6 +480,8 @@ they wish for by these means. · 20 unmodified lines | ||
| 463 | 480 | |
| 464 | 481 | Andrew Morton gives this advice for aspiring kernel developers |
| 465 | 482 | |
| 483 | +:: | |
| 484 | + | |
| 466 | 485 | The #1 project for all kernel beginners should surely be "make sure |
| 467 | 486 | that the kernel runs perfectly at all times on all machines which |
| 468 | 487 | you can lay your hands on". Usually the way to do this is to work |
| @@ -1,4 +1,7 @@ | ||
| 1 | −3: EARLY-STAGE PLANNING | |
| 1 | +.. _development_early_stage: | |
| 2 | + | |
| 3 | +Early-stage planning | |
| 4 | +==================== | |
| 2 | 5 | |
| 3 | 6 | When contemplating a Linux kernel development project, it can be tempting |
| 4 | 7 | to jump right in and start coding. As with any significant project, |
| @@ -7,7 +10,8 @@ line of code is written. Some time spent in early planning and · 2 unmodified lines | ||
| 7 | 10 | communication can save far more time later on. |
| 8 | 11 | |
| 9 | 12 | |
| 10 | −3.1: SPECIFYING THE PROBLEM | |
| 13 | +Specifying the problem | |
| 14 | +---------------------- | |
| 11 | 15 | |
| 12 | 16 | Like any engineering project, a successful kernel enhancement starts with a |
| 13 | 17 | clear description of the problem to be solved. In some cases, this step is |
| @@ -64,7 +68,8 @@ answers to a short set of questions: · 50 unmodified lines | ||
| 64 | 68 | Only then does it make sense to start considering possible solutions. |
| 65 | 69 | |
| 66 | 70 | |
| 67 | −3.2: EARLY DISCUSSION | |
| 71 | +Early discussion | |
| 72 | +---------------- | |
| 68 | 73 | |
| 69 | 74 | When planning a kernel development project, it makes great sense to hold |
| 70 | 75 | discussions with the community before launching into implementation. Early |
| @@ -117,7 +122,8 @@ In each of these cases, a great deal of pain and extra work could have been · 46 unmodified lines | ||
| 117 | 122 | avoided with some early discussion with the kernel developers. |
| 118 | 123 | |
| 119 | 124 | |
| 120 | −3.3: WHO DO YOU TALK TO? | |
| 125 | +Who do you talk to? | |
| 126 | +------------------- | |
| 121 | 127 | |
| 122 | 128 | When developers decide to take their plans public, the next question will |
| 123 | 129 | be: where do we start? The answer is to find the right mailing list(s) and |
| @@ -141,6 +147,8 @@ development project. · 17 unmodified lines | ||
| 141 | 147 | The task of finding the right maintainer is sometimes challenging enough |
| 142 | 148 | that the kernel developers have added a script to ease the process: |
| 143 | 149 | |
| 150 | +:: | |
| 151 | + | |
| 144 | 152 | .../scripts/get_maintainer.pl |
| 145 | 153 | |
| 146 | 154 | This script will return the current maintainer(s) for a given file or |
| @@ -155,7 +163,8 @@ If all else fails, talking to Andrew Morton can be an effective way to · 8 unmodified lines | ||
| 155 | 163 | track down a maintainer for a specific piece of code. |
| 156 | 164 | |
| 157 | 165 | |
| 158 | −3.4: WHEN TO POST? | |
| 166 | +When to post? | |
| 167 | +------------- | |
| 159 | 168 | |
| 160 | 169 | If possible, posting your plans during the early stages can only be |
| 161 | 170 | helpful. Describe the problem being solved and any plans that have been |
| @@ -179,7 +188,8 @@ idea. The best thing to do in this situation is to proceed, keeping the · 17 unmodified lines | ||
| 179 | 188 | community informed as you go. |
| 180 | 189 | |
| 181 | 190 | |
| 182 | −3.5: GETTING OFFICIAL BUY-IN | |
| 191 | +Getting official buy-in | |
| 192 | +----------------------- | |
| 183 | 193 | |
| 184 | 194 | If your work is being done in a corporate environment - as most Linux |
| 185 | 195 | kernel work is - you must, obviously, have permission from suitably |
| @@ -1,4 +1,7 @@ | ||
| 1 | −4: GETTING THE CODE RIGHT | |
| 1 | +.. _development_coding: | |
| 2 | + | |
| 3 | +Getting the code right | |
| 4 | +====================== | |
| 2 | 5 | |
| 3 | 6 | While there is much to be said for a solid and community-oriented design |
| 4 | 7 | process, the proof of any kernel development project is in the resulting |
| @@ -12,9 +15,11 @@ will shift toward doing things right and the tools which can help in that · 7 unmodified lines | ||
| 12 | 15 | quest. |
| 13 | 16 | |
| 14 | 17 | |
| 15 | −4.1: PITFALLS | |
| 18 | +Pitfalls | |
| 19 | +--------- | |
| 16 | 20 | |
| 17 | −* Coding style | |
| 21 | +Coding style | |
| 22 | +************ | |
| 18 | 23 | |
| 19 | 24 | The kernel has long had a standard coding style, described in |
| 20 | 25 | Documentation/CodingStyle. For much of that time, the policies described |
| @@ -54,7 +59,8 @@ style (a line which becomes far less readable if split to fit within the · 33 unmodified lines | ||
| 54 | 59 | 80-column limit, for example), just do it. |
| 55 | 60 | |
| 56 | 61 | |
| 57 | −* Abstraction layers | |
| 62 | +Abstraction layers | |
| 63 | +****************** | |
| 58 | 64 | |
| 59 | 65 | Computer Science professors teach students to make extensive use of |
| 60 | 66 | abstraction layers in the name of flexibility and information hiding. |
| @@ -87,7 +93,8 @@ implement that functionality at a higher level. There is no value in · 26 unmodified lines | ||
| 87 | 93 | replicating the same code throughout the kernel. |
| 88 | 94 | |
| 89 | 95 | |
| 90 | −* #ifdef and preprocessor use in general | |
| 96 | +#ifdef and preprocessor use in general | |
| 97 | +************************************** | |
| 91 | 98 | |
| 92 | 99 | The C preprocessor seems to present a powerful temptation to some C |
| 93 | 100 | programmers, who see it as a way to efficiently encode a great deal of |
| @@ -113,7 +120,8 @@ easier to read, do not evaluate their arguments multiple times, and allow · 19 unmodified lines | ||
| 113 | 120 | the compiler to perform type checking on the arguments and return value. |
| 114 | 121 | |
| 115 | 122 | |
| 116 | −* Inline functions | |
| 123 | +Inline functions | |
| 124 | +**************** | |
| 117 | 125 | |
| 118 | 126 | Inline functions present a hazard of their own, though. Programmers can |
| 119 | 127 | become enamored of the perceived efficiency inherent in avoiding a function |
| @@ -137,7 +145,8 @@ placement of "inline" keywords may not just be excessive; it could also be · 17 unmodified lines | ||
| 137 | 145 | irrelevant. |
| 138 | 146 | |
| 139 | 147 | |
| 140 | −* Locking | |
| 148 | +Locking | |
| 149 | +******* | |
| 141 | 150 | |
| 142 | 151 | In May, 2006, the "Devicescape" networking stack was, with great |
| 143 | 152 | fanfare, released under the GPL and made available for inclusion in the |
| @@ -151,7 +160,7 @@ This code showed a number of signs of having been developed behind · 7 unmodified lines | ||
| 151 | 160 | corporate doors. But one large problem in particular was that it was not |
| 152 | 161 | designed to work on multiprocessor systems. Before this networking stack |
| 153 | 162 | (now called mac80211) could be merged, a locking scheme needed to be |
| 154 | −retrofitted onto it. | |
| 163 | +retrofitted onto it. | |
| 155 | 164 | |
| 156 | 165 | Once upon a time, Linux kernel code could be developed without thinking |
| 157 | 166 | about the concurrency issues presented by multiprocessor systems. Now, |
| @@ -169,7 +178,8 @@ enough to pick the right tool for the job. Code which shows a lack of · 11 unmodified lines | ||
| 169 | 178 | attention to concurrency will have a difficult path into the mainline. |
| 170 | 179 | |
| 171 | 180 | |
| 172 | −* Regressions | |
| 181 | +Regressions | |
| 182 | +*********** | |
| 173 | 183 | |
| 174 | 184 | One final hazard worth mentioning is this: it can be tempting to make a |
| 175 | 185 | change (which may bring big improvements) which causes something to break |
| @@ -185,6 +195,8 @@ change if it brings new functionality to ten systems for each one it · 9 unmodified lines | ||
| 185 | 195 | breaks? The best answer to this question was expressed by Linus in July, |
| 186 | 196 | 2007: |
| 187 | 197 | |
| 198 | +:: | |
| 199 | + | |
| 188 | 200 | So we don't fix bugs by introducing new problems. That way lies |
| 189 | 201 | madness, and nobody ever knows if you actually make any real |
| 190 | 202 | progress at all. Is it two steps forwards, one step back, or one |
| @@ -201,8 +213,8 @@ reason, a great deal of thought, clear documentation, and wide review for · 10 unmodified lines | ||
| 201 | 213 | user-space interfaces is always required. |
| 202 | 214 | |
| 203 | 215 | |
| 204 | − | |
| 205 | −4.2: CODE CHECKING TOOLS | |
| 216 | +Code checking tools | |
| 217 | +------------------- | |
| 206 | 218 | |
| 207 | 219 | For now, at least, the writing of error-free code remains an ideal that few |
| 208 | 220 | of us can reach. What we can hope to do, though, is to catch and fix as |
| @@ -250,7 +262,7 @@ testing purposes. In particular, you should turn on: · 41 unmodified lines | ||
| 250 | 262 | There are quite a few other debugging options, some of which will be |
| 251 | 263 | discussed below. Some of them have a significant performance impact and |
| 252 | 264 | should not be used all of the time. But some time spent learning the |
| 253 | −available options will likely be paid back many times over in short order. | |
| 265 | +available options will likely be paid back many times over in short order. | |
| 254 | 266 | |
| 255 | 267 | One of the heavier debugging tools is the locking checker, or "lockdep." |
| 256 | 268 | This tool will track the acquisition and release of every lock (spinlock or |
| @@ -263,7 +275,7 @@ occasion, deadlock. This kind of problem can be painful (for both · 6 unmodified lines | ||
| 263 | 275 | developers and users) in a deployed system; lockdep allows them to be found |
| 264 | 276 | in an automated manner ahead of time. Code with any sort of non-trivial |
| 265 | 277 | locking should be run with lockdep enabled before being submitted for |
| 266 | −inclusion. | |
| 278 | +inclusion. | |
| 267 | 279 | |
| 268 | 280 | As a diligent kernel programmer, you will, beyond doubt, check the return |
| 269 | 281 | status of any operation (such as a memory allocation) which can fail. The |
| @@ -300,7 +312,7 @@ Documentation/coccinelle.txt for more information. · 30 unmodified lines | ||
| 300 | 312 | Other kinds of portability errors are best found by compiling your code for |
| 301 | 313 | other architectures. If you do not happen to have an S/390 system or a |
| 302 | 314 | Blackfin development board handy, you can still perform the compilation |
| 303 | −step. A large set of cross compilers for x86 systems can be found at | |
| 315 | +step. A large set of cross compilers for x86 systems can be found at | |
| 304 | 316 | |
| 305 | 317 | http://www.kernel.org/pub/tools/crosstool/ |
| 306 | 318 | |
| @@ -308,7 +320,8 @@ Some time spent installing and using these compilers will help avoid · 1 unmodified line | ||
| 308 | 320 | embarrassment later. |
| 309 | 321 | |
| 310 | 322 | |
| 311 | −4.3: DOCUMENTATION | |
| 323 | +Documentation | |
| 324 | +------------- | |
| 312 | 325 | |
| 313 | 326 | Documentation has often been more the exception than the rule with kernel |
| 314 | 327 | development. Even so, adequate documentation will help to ease the merging |
| @@ -364,7 +377,8 @@ out. Anything which might tempt a code janitor to make an incorrect · 49 unmodified lines | ||
| 364 | 377 | "cleanup" needs a comment saying why it is done the way it is. And so on. |
| 365 | 378 | |
| 366 | 379 | |
| 367 | −4.4: INTERNAL API CHANGES | |
| 380 | +Internal API changes | |
| 381 | +-------------------- | |
| 368 | 382 | |
| 369 | 383 | The binary interface provided by the kernel to user space cannot be broken |
| 370 | 384 | except under the most severe circumstances. The kernel's internal |
| @@ -1,4 +1,7 @@ | ||
| 1 | −5: POSTING PATCHES | |
| 1 | +.. _development_posting: | |
| 2 | + | |
| 3 | +Posting patches | |
| 4 | +=============== | |
| 2 | 5 | |
| 3 | 6 | Sooner or later, the time comes when your work is ready to be presented to |
| 4 | 7 | the community for review and, eventually, inclusion into the mainline |
| @@ -11,7 +14,8 @@ SubmittingDrivers, and SubmitChecklist in the kernel documentation · 6 unmodified lines | ||
| 11 | 14 | directory. |
| 12 | 15 | |
| 13 | 16 | |
| 14 | −5.1: WHEN TO POST | |
| 17 | +When to post | |
| 18 | +------------ | |
| 15 | 19 | |
| 16 | 20 | There is a constant temptation to avoid posting patches before they are |
| 17 | 21 | completely "ready." For simple patches, that is not a problem. If the |
| @@ -27,7 +31,8 @@ patches which are known to be half-baked, but those who do will come in · 9 unmodified lines | ||
| 27 | 31 | with the idea that they can help you drive the work in the right direction. |
| 28 | 32 | |
| 29 | 33 | |
| 30 | −5.2: BEFORE CREATING PATCHES | |
| 34 | +Before creating patches | |
| 35 | +----------------------- | |
| 31 | 36 | |
| 32 | 37 | There are a number of things which should be done before you consider |
| 33 | 38 | sending patches to the development community. These include: |
| @@ -52,7 +57,8 @@ As a general rule, putting in some extra thought before posting code almost · 18 unmodified lines | ||
| 52 | 57 | always pays back the effort in short order. |
| 53 | 58 | |
| 54 | 59 | |
| 55 | −5.3: PATCH PREPARATION | |
| 60 | +Patch preparation | |
| 61 | +----------------- | |
| 56 | 62 | |
| 57 | 63 | The preparation of patches for posting can be a surprising amount of work, |
| 58 | 64 | but, once again, attempting to save time here is not generally advisable |
| @@ -122,7 +128,8 @@ which takes quite a bit of time and thought after the "real work" has been · 63 unmodified lines | ||
| 122 | 128 | done. When done properly, though, it is time well spent. |
| 123 | 129 | |
| 124 | 130 | |
| 125 | −5.4: PATCH FORMATTING AND CHANGELOGS | |
| 131 | +Patch formatting and changelogs | |
| 132 | +------------------------------- | |
| 126 | 133 | |
| 127 | 134 | So now you have a perfect series of patches for posting, but the work is |
| 128 | 135 | not done quite yet. Each patch needs to be formatted into a message which |
| @@ -140,6 +147,8 @@ that end, each patch will be composed of the following: · 11 unmodified lines | ||
| 140 | 147 | subsystem name first, followed by the purpose of the patch. For |
| 141 | 148 | example: |
| 142 | 149 | |
| 150 | + :: | |
| 151 | + | |
| 143 | 152 | gpio: fix build on CONFIG_GPIO_SYSFS=n |
| 144 | 153 | |
| 145 | 154 | - A blank line followed by a detailed description of the contents of the |
| @@ -192,6 +201,8 @@ been associated with the development of this patch. They are described in · 46 unmodified lines | ||
| 192 | 201 | detail in the SubmittingPatches document; what follows here is a brief |
| 193 | 202 | summary. Each of these lines has the format: |
| 194 | 203 | |
| 204 | +:: | |
| 205 | + | |
| 195 | 206 | tag: Full Name <email address> optional-other-stuff |
| 196 | 207 | |
| 197 | 208 | The tags in common use are: |
| @@ -225,7 +236,8 @@ Be careful in the addition of tags to your patches: only Cc: is appropriate · 27 unmodified lines | ||
| 225 | 236 | for addition without the explicit permission of the person named. |
| 226 | 237 | |
| 227 | 238 | |
| 228 | −5.5: SENDING THE PATCH | |
| 239 | +Sending the patch | |
| 240 | +----------------- | |
| 229 | 241 | |
| 230 | 242 | Before you mail your patches, there are a couple of other things you should |
| 231 | 243 | take care of: |
| @@ -287,6 +299,8 @@ obvious maintainer, Andrew Morton is often the patch target of last resort. · 55 unmodified lines | ||
| 287 | 299 | Patches need good subject lines. The canonical format for a patch line is |
| 288 | 300 | something like: |
| 289 | 301 | |
| 302 | +:: | |
| 303 | + | |
| 290 | 304 | [PATCH nn/mm] subsys: one-line description of the patch |
| 291 | 305 | |
| 292 | 306 | where "nn" is the ordinal number of the patch, "mm" is the total number of |
| @@ -1,4 +1,7 @@ | ||
| 1 | −6: FOLLOWTHROUGH | |
| 1 | +.. _development_followthrough: | |
| 2 | + | |
| 3 | +Followthrough | |
| 4 | +============= | |
| 2 | 5 | |
| 3 | 6 | At this point, you have followed the guidelines given so far and, with the |
| 4 | 7 | addition of your own engineering skills, have posted a perfect series of |
| @@ -16,7 +19,8 @@ standards. A failure to participate in this process is quite likely to · 11 unmodified lines | ||
| 16 | 19 | prevent the inclusion of your patches into the mainline. |
| 17 | 20 | |
| 18 | 21 | |
| 19 | −6.1: WORKING WITH REVIEWERS | |
| 22 | +Working with reviewers | |
| 23 | +---------------------- | |
| 20 | 24 | |
| 21 | 25 | A patch of any significance will result in a number of comments from other |
| 22 | 26 | developers as they review the code. Working with reviewers can be, for |
| @@ -97,7 +101,8 @@ though, and not before all other alternatives have been explored. And bear · 74 unmodified lines | ||
| 97 | 101 | in mind, of course, that he may not agree with you either. |
| 98 | 102 | |
| 99 | 103 | |
| 100 | −6.2: WHAT HAPPENS NEXT | |
| 104 | +What happens next | |
| 105 | +----------------- | |
| 101 | 106 | |
| 102 | 107 | If a patch is considered to be a good thing to add to the kernel, and once |
| 103 | 108 | most of the review issues have been resolved, the next step is usually |
| @@ -177,7 +182,8 @@ it with the assumption that you will not be around to maintain it · 73 unmodified lines | ||
| 177 | 182 | afterward. |
| 178 | 183 | |
| 179 | 184 | |
| 180 | −6.3: OTHER THINGS THAT CAN HAPPEN | |
| 185 | +Other things that can happen | |
| 186 | +----------------------------- | |
| 181 | 187 | |
| 182 | 188 | One day, you may open your mail client and see that somebody has mailed you |
| 183 | 189 | a patch to your code. That is one of the advantages of having your code |
| @@ -1,11 +1,15 @@ | ||
| 1 | −7: ADVANCED TOPICS | |
| 1 | +.. _development_advancedtopics: | |
| 2 | + | |
| 3 | +Advanced topics | |
| 4 | +=============== | |
| 2 | 5 | |
| 3 | 6 | At this point, hopefully, you have a handle on how the development process |
| 4 | 7 | works. There is still more to learn, however! This section will cover a |
| 5 | 8 | number of topics which can be helpful for developers wanting to become a |
| 6 | 9 | regular part of the Linux kernel development process. |
| 7 | 10 | |
| 8 | −7.1: MANAGING PATCHES WITH GIT | |
| 11 | +Managing patches with git | |
| 12 | +------------------------- | |
| 9 | 13 | |
| 10 | 14 | The use of distributed version control for the kernel began in early 2002, |
| 11 | 15 | when Linus first started playing with the proprietary BitKeeper |
| @@ -114,6 +118,8 @@ radar. Kernel developers tend to get unhappy when they see that kind of · 102 unmodified lines | ||
| 114 | 118 | thing happening; putting up a git tree with unreviewed or off-topic patches |
| 115 | 119 | can affect your ability to get trees pulled in the future. Quoting Linus: |
| 116 | 120 | |
| 121 | +:: | |
| 122 | + | |
| 117 | 123 | You can send me patches, but for me to pull a git patch from you, I |
| 118 | 124 | need to know that you know what you're doing, and I need to be able |
| 119 | 125 | to trust things *without* then having to go and check every |
| @@ -141,7 +147,8 @@ format the request as other developers expect, and will also check to be · 21 unmodified lines | ||
| 141 | 147 | sure that you have remembered to push those changes to the public server. |
| 142 | 148 | |
| 143 | 149 | |
| 144 | −7.2: REVIEWING PATCHES | |
| 150 | +Reviewing patches | |
| 151 | +----------------- | |
| 145 | 152 | |
| 146 | 153 | Some readers will certainly object to putting this section with "advanced |
| 147 | 154 | topics" on the grounds that even beginning kernel developers should be |
| @@ -1,4 +1,7 @@ | ||
| 1 | −8: FOR MORE INFORMATION | |
| 1 | +.. _development_conclusion: | |
| 2 | + | |
| 3 | +For more information | |
| 4 | +==================== | |
| 2 | 5 | |
| 3 | 6 | There are numerous sources of information on Linux kernel development and |
| 4 | 7 | related topics. First among those will always be the Documentation |
| @@ -47,7 +50,8 @@ Documentation for git can be found at: · 42 unmodified lines | ||
| 47 | 50 | http://www.kernel.org/pub/software/scm/git/docs/user-manual.html |
| 48 | 51 | |
| 49 | 52 | |
| 50 | −9: CONCLUSION | |
| 53 | +Conclusion | |
| 54 | +========== | |
| 51 | 55 | |
| 52 | 56 | Congratulations to anybody who has made it through this long-winded |
| 53 | 57 | document. Hopefully it has provided a helpful understanding of how the |
| @@ -0,0 +1,10 @@ | ||
| 1 | +# -*- coding: utf-8; mode: python -*- | |
| 2 | + | |
| 3 | +project = 'Linux Kernel Development Documentation' | |
| 4 | + | |
| 5 | +tags.add("subproject") | |
| 6 | + | |
| 7 | +latex_documents = [ | |
| 8 | + ('index', 'development-process.tex', 'Linux Kernel Development Documentation', | |
| 9 | + 'The kernel development community', 'manual'), | |
| 10 | +] | |
| @@ -0,0 +1,29 @@ | ||
| 1 | +.. _development_process_main: | |
| 2 | + | |
| 3 | +A guide to the Kernel Development Process | |
| 4 | +========================================= | |
| 5 | + | |
| 6 | +Contents: | |
| 7 | + | |
| 8 | +.. toctree:: | |
| 9 | + :numbered: | |
| 10 | + :maxdepth: 2 | |
| 11 | + | |
| 12 | + 1.Intro | |
| 13 | + 2.Process | |
| 14 | + 3.Early-stage | |
| 15 | + 4.Coding | |
| 16 | + 5.Posting | |
| 17 | + 6.Followthrough | |
| 18 | + 7.AdvancedTopics | |
| 19 | + 8.Conclusion | |
| 20 | + | |
| 21 | +The purpose of this document is to help developers (and their managers) | |
| 22 | +work with the development community with a minimum of frustration. It is | |
| 23 | +an attempt to document how this community works in a way which is | |
| 24 | +accessible to those who are not intimately familiar with Linux kernel | |
| 25 | +development (or, indeed, free software development in general). While | |
| 26 | +there is some technical material here, this is very much a process-oriented | |
| 27 | +discussion which does not require a deep knowledge of kernel programming to | |
| 28 | +understand. | |
| 29 | + | |
| @@ -0,0 +1,9 @@ | ||
| 1 | +Linux Kernel Development Documentation | |
| 2 | +====================================== | |
| 3 | + | |
| 4 | +Contents: | |
| 5 | + | |
| 6 | +.. toctree:: | |
| 7 | + :maxdepth: 2 | |
| 8 | + | |
| 9 | + development-process | |
| @@ -90,6 +90,47 @@ Required Properties: · 89 unmodified lines | ||
| 90 | 90 | - interrupts : Should be single bit error interrupt, then double bit error |
| 91 | 91 | interrupt, in this order. |
| 92 | 92 | |
| 93 | +NAND FIFO ECC | |
| 94 | +Required Properties: | |
| 95 | +- compatible : Should be "altr,socfpga-nand-ecc" | |
| 96 | +- reg : Address and size for ECC block registers. | |
| 97 | +- altr,ecc-parent : phandle to parent NAND node. | |
| 98 | +- interrupts : Should be single bit error interrupt, then double bit error | |
| 99 | + interrupt, in this order. | |
| 100 | + | |
| 101 | +DMA FIFO ECC | |
| 102 | +Required Properties: | |
| 103 | +- compatible : Should be "altr,socfpga-dma-ecc" | |
| 104 | +- reg : Address and size for ECC block registers. | |
| 105 | +- altr,ecc-parent : phandle to parent DMA node. | |
| 106 | +- interrupts : Should be single bit error interrupt, then double bit error | |
| 107 | + interrupt, in this order. | |
| 108 | + | |
| 109 | +USB FIFO ECC | |
| 110 | +Required Properties: | |
| 111 | +- compatible : Should be "altr,socfpga-usb-ecc" | |
| 112 | +- reg : Address and size for ECC block registers. | |
| 113 | +- altr,ecc-parent : phandle to parent USB node. | |
| 114 | +- interrupts : Should be single bit error interrupt, then double bit error | |
| 115 | + interrupt, in this order. | |
| 116 | + | |
| 117 | +QSPI FIFO ECC | |
| 118 | +Required Properties: | |
| 119 | +- compatible : Should be "altr,socfpga-qspi-ecc" | |
| 120 | +- reg : Address and size for ECC block registers. | |
| 121 | +- altr,ecc-parent : phandle to parent QSPI node. | |
| 122 | +- interrupts : Should be single bit error interrupt, then double bit error | |
| 123 | + interrupt, in this order. | |
| 124 | + | |
| 125 | +SDMMC FIFO ECC | |
| 126 | +Required Properties: | |
| 127 | +- compatible : Should be "altr,socfpga-sdmmc-ecc" | |
| 128 | +- reg : Address and size for ECC block registers. | |
| 129 | +- altr,ecc-parent : phandle to parent SD/MMC node. | |
| 130 | +- interrupts : Should be single bit error interrupt, then double bit error | |
| 131 | + interrupt, in this order for port A, and then single bit error interrupt, | |
| 132 | + then double bit error interrupt in this order for port B. | |
| 133 | + | |
| 93 | 134 | Example: |
| 94 | 135 | |
| 95 | 136 | eccmgr: eccmgr@ffd06000 { |
| @@ -132,4 +173,61 @@ Example: · 36 unmodified lines | ||
| 132 | 173 | interrupts = <5 IRQ_TYPE_LEVEL_HIGH>, |
| 133 | 174 | <37 IRQ_TYPE_LEVEL_HIGH>; |
| 134 | 175 | }; |
| 176 | + | |
| 177 | + nand-buf-ecc@ff8c2000 { | |
| 178 | + compatible = "altr,socfpga-nand-ecc"; | |
| 179 | + reg = <0xff8c2000 0x400>; | |
| 180 | + altr,ecc-parent = <&nand>; | |
| 181 | + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>, | |
| 182 | + <43 IRQ_TYPE_LEVEL_HIGH>; | |
| 183 | + }; | |
| 184 | + | |
| 185 | + nand-rd-ecc@ff8c2400 { | |
| 186 | + compatible = "altr,socfpga-nand-ecc"; | |
| 187 | + reg = <0xff8c2400 0x400>; | |
| 188 | + altr,ecc-parent = <&nand>; | |
| 189 | + interrupts = <13 IRQ_TYPE_LEVEL_HIGH>, | |
| 190 | + <45 IRQ_TYPE_LEVEL_HIGH>; | |
| 191 | + }; | |
| 192 | + | |
| 193 | + nand-wr-ecc@ff8c2800 { | |
| 194 | + compatible = "altr,socfpga-nand-ecc"; | |
| 195 | + reg = <0xff8c2800 0x400>; | |
| 196 | + altr,ecc-parent = <&nand>; | |
| 197 | + interrupts = <12 IRQ_TYPE_LEVEL_HIGH>, | |
| 198 | + <44 IRQ_TYPE_LEVEL_HIGH>; | |
| 199 | + }; | |
| 200 | + | |
| 201 | + dma-ecc@ff8c8000 { | |
| 202 | + compatible = "altr,socfpga-dma-ecc"; | |
| 203 | + reg = <0xff8c8000 0x400>; | |
| 204 | + altr,ecc-parent = <&pdma>; | |
| 205 | + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>, | |
| 206 | + <42 IRQ_TYPE_LEVEL_HIGH>; | |
| 207 | + | |
| 208 | + usb0-ecc@ff8c8800 { | |
| 209 | + compatible = "altr,socfpga-usb-ecc"; | |
| 210 | + reg = <0xff8c8800 0x400>; | |
| 211 | + altr,ecc-parent = <&usb0>; | |
| 212 | + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>, | |
| 213 | + <34 IRQ_TYPE_LEVEL_HIGH>; | |
| 214 | + }; | |
| 215 | + | |
| 216 | + qspi-ecc@ff8c8400 { | |
| 217 | + compatible = "altr,socfpga-qspi-ecc"; | |
| 218 | + reg = <0xff8c8400 0x400>; | |
| 219 | + altr,ecc-parent = <&qspi>; | |
| 220 | + interrupts = <14 IRQ_TYPE_LEVEL_HIGH>, | |
| 221 | + <46 IRQ_TYPE_LEVEL_HIGH>; | |
| 222 | + }; | |
| 223 | + | |
| 224 | + sdmmc-ecc@ff8c2c00 { | |
| 225 | + compatible = "altr,socfpga-sdmmc-ecc"; | |
| 226 | + reg = <0xff8c2c00 0x400>; | |
| 227 | + altr,ecc-parent = <&mmc>; | |
| 228 | + interrupts = <15 IRQ_TYPE_LEVEL_HIGH>, | |
| 229 | + <47 IRQ_TYPE_LEVEL_HIGH>, | |
| 230 | + <16 IRQ_TYPE_LEVEL_HIGH>, | |
| 231 | + <48 IRQ_TYPE_LEVEL_HIGH>; | |
| 232 | + }; | |
| 135 | 233 | }; |
| @@ -25,6 +25,12 @@ to deliver its interrupts via SPIs. · 24 unmodified lines | ||
| 25 | 25 | - always-on : a boolean property. If present, the timer is powered through an |
| 26 | 26 | always-on power domain, therefore it never loses context. |
| 27 | 27 | |
| 28 | +- fsl,erratum-a008585 : A boolean property. Indicates the presence of | |
| 29 | + QorIQ erratum A-008585, which says that reading the counter is | |
| 30 | + unreliable unless the same value is returned by back-to-back reads. | |
| 31 | + This also affects writes to the tval register, due to the implicit | |
| 32 | + counter read. | |
| 33 | + | |
| 28 | 34 | ** Optional properties: |
| 29 | 35 | |
| 30 | 36 | - arm,cpu-registers-not-fw-configured : Firmware does not initialize |
| @@ -38,6 +38,10 @@ Raspberry Pi Compute Module · 37 unmodified lines | ||
| 38 | 38 | Required root node properties: |
| 39 | 39 | compatible = "raspberrypi,compute-module", "brcm,bcm2835"; |
| 40 | 40 | |
| 41 | +Raspberry Pi Zero | |
| 42 | +Required root node properties: | |
| 43 | +compatible = "raspberrypi,model-zero", "brcm,bcm2835"; | |
| 44 | + | |
| 41 | 45 | Generic BCM2835 board |
| 42 | 46 | Required root node properties: |
| 43 | 47 | compatible = "brcm,bcm2835"; |
| @@ -5,6 +5,10 @@ DA850/OMAP-L138/AM18x Evaluation Module (EVM) board · 4 unmodified lines | ||
| 5 | 5 | Required root node properties: |
| 6 | 6 | - compatible = "ti,da850-evm", "ti,da850"; |
| 7 | 7 | |
| 8 | +DA850/OMAP-L138/AM18x L138/C6748 Development Kit (LCDK) board | |
| 9 | +Required root node properties: | |
| 10 | + - compatible = "ti,da850-lcdk", "ti,da850"; | |
| 11 | + | |
| 8 | 12 | EnBW AM1808 based CMC board |
| 9 | 13 | Required root node properties: |
| 10 | 14 | - compatible = "enbw,cmc", "ti,da850; |
| @@ -175,38 +175,55 @@ Example: · 174 unmodified lines | ||
| 175 | 175 | }; |
| 176 | 176 | |
| 177 | 177 | ----------------------------------------------------------------------- |
| 178 | −Hisilicon HiP05 PCIe-SAS system controller | |
| 178 | +Hisilicon HiP05/HiP06 PCIe-SAS sub system controller | |
| 179 | 179 | |
| 180 | 180 | Required properties: |
| 181 | 181 | - compatible : "hisilicon,pcie-sas-subctrl", "syscon"; |
| 182 | 182 | - reg : Register address and size |
| 183 | 183 | |
| 184 | −The HiP05 PCIe-SAS system controller is shared by PCIe and SAS controllers in | |
| 185 | −HiP05 Soc to implement some basic configurations. | |
| 184 | +The PCIe-SAS sub system controller is shared by PCIe and SAS controllers in | |
| 185 | +HiP05 or HiP06 Soc to implement some basic configurations. | |
| 186 | 186 | |
| 187 | 187 | Example: |
| 188 | − /* for HiP05 PCIe-SAS system */ | |
| 189 | − pcie_sas: system_controller@0xb0000000 { | |
| 188 | + /* for HiP05 PCIe-SAS sub system */ | |
| 189 | + pcie_sas: system_controller@b0000000 { | |
| 190 | 190 | compatible = "hisilicon,pcie-sas-subctrl", "syscon"; |
| 191 | 191 | reg = <0xb0000000 0x10000>; |
| 192 | 192 | }; |
| 193 | 193 | |
| 194 | −Hisilicon HiP05 PERISUB system controller | |
| 194 | +Hisilicon HiP05/HiP06 PERI sub system controller | |
| 195 | 195 | |
| 196 | 196 | Required properties: |
| 197 | −- compatible : "hisilicon,hip05-perisubc", "syscon"; | |
| 197 | +- compatible : "hisilicon,peri-subctrl", "syscon"; | |
| 198 | 198 | - reg : Register address and size |
| 199 | 199 | |
| 200 | −The HiP05 PERISUB system controller is shared by peripheral controllers in | |
| 201 | −HiP05 Soc to implement some basic configurations. The peripheral | |
| 200 | +The PERI sub system controller is shared by peripheral controllers in | |
| 201 | +HiP05 or HiP06 Soc to implement some basic configurations. The peripheral | |
| 202 | 202 | controllers include mdio, ddr, iic, uart, timer and so on. |
| 203 | 203 | |
| 204 | 204 | Example: |
| 205 | − /* for HiP05 perisub-ctrl-c system */ | |
| 205 | + /* for HiP05 sub peri system */ | |
| 206 | 206 | peri_c_subctrl: syscon@80000000 { |
| 207 | − compatible = "hisilicon,hip05-perisubc", "syscon"; | |
| 207 | + compatible = "hisilicon,peri-subctrl", "syscon"; | |
| 208 | 208 | reg = <0x0 0x80000000 0x0 0x10000>; |
| 209 | 209 | }; |
| 210 | + | |
| 211 | +Hisilicon HiP05/HiP06 DSA sub system controller | |
| 212 | + | |
| 213 | +Required properties: | |
| 214 | +- compatible : "hisilicon,dsa-subctrl", "syscon"; | |
| 215 | +- reg : Register address and size | |
| 216 | + | |
| 217 | +The DSA sub system controller is shared by peripheral controllers in | |
| 218 | +HiP05 or HiP06 Soc to implement some basic configurations. | |
| 219 | + | |
| 220 | +Example: | |
| 221 | + /* for HiP05 dsa sub system */ | |
| 222 | + pcie_sas: system_controller@a0000000 { | |
| 223 | + compatible = "hisilicon,dsa-subctrl", "syscon"; | |
| 224 | + reg = <0xa0000000 0x10000>; | |
| 225 | + }; | |
| 226 | + | |
| 210 | 227 | ----------------------------------------------------------------------- |
| 211 | 228 | Hisilicon CPU controller |
| 212 | 229 | |
| @@ -8,8 +8,19 @@ Required root node property: · 7 unmodified lines | ||
| 8 | 8 | |
| 9 | 9 | - compatible: must contain "marvell,armada390" |
| 10 | 10 | |
| 11 | −In addition, boards using the Marvell Armada 398 SoC shall have the | |
| 12 | −following property before the previous one: | |
| 11 | +In addition, boards using the Marvell Armada 395 SoC shall have the | |
| 12 | +following property before the common "marvell,armada390" one: | |
| 13 | + | |
| 14 | +Required root node property: | |
| 15 | + | |
| 16 | +compatible: must contain "marvell,armada395" | |
| 17 | + | |
| 18 | +Example: | |
| 19 | + | |
| 20 | +compatible = "marvell,a395-gp", "marvell,armada395", "marvell,armada390"; | |
| 21 | + | |
| 22 | +Boards using the Marvell Armada 398 SoC shall have the following | |
| 23 | +property before the common "marvell,armada390" one: | |
| 13 | 24 | |
| 14 | 25 | Required root node property: |
| 15 | 26 | |
| @@ -0,0 +1,25 @@ | ||
| 1 | +Marvell Orion SoC Family Device Tree Bindings | |
| 2 | +--------------------------------------------- | |
| 3 | + | |
| 4 | +Boards with a SoC of the Marvell Orion family, eg 88f5181 | |
| 5 | + | |
| 6 | +* Required root node properties: | |
| 7 | +compatible: must contain "marvell,orion5x" | |
| 8 | + | |
| 9 | +In addition, the above compatible shall be extended with the specific | |
| 10 | +SoC. Currently known SoC compatibles are: | |
| 11 | + | |
| 12 | +"marvell,orion5x-88f5181" | |
| 13 | +"marvell,orion5x-88f5182" | |
| 14 | + | |
| 15 | +And in addition, the compatible shall be extended with the specific | |
| 16 | +board. Currently known boards are: | |
| 17 | + | |
| 18 | +"buffalo,lsgl" | |
| 19 | +"buffalo,lswsgl" | |
| 20 | +"buffalo,lswtgl" | |
| 21 | +"lacie,ethernet-disk-mini-v2" | |
| 22 | +"lacie,d2-network" | |
| 23 | +"marvell,rd-88f5182-nas" | |
| 24 | +"maxtor,shared-storage-2" | |
| 25 | +"netgear,wnr854t" | |
| @@ -5,7 +5,8 @@ The Mediatek apmixedsys controller provides the PLLs to the system. · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required Properties: |
| 7 | 7 | |
| 8 | −- compatible: Should be: | |
| 8 | +- compatible: Should be one of: | |
| 9 | + - "mediatek,mt2701-apmixedsys" | |
| 9 | 10 | - "mediatek,mt8135-apmixedsys" |
| 10 | 11 | - "mediatek,mt8173-apmixedsys" |
| 11 | 12 | - #clock-cells: Must be 1 |
| @@ -0,0 +1,22 @@ | ||
| 1 | +Mediatek bdpsys controller | |
| 2 | +============================ | |
| 3 | + | |
| 4 | +The Mediatek bdpsys controller provides various clocks to the system. | |
| 5 | + | |
| 6 | +Required Properties: | |
| 7 | + | |
| 8 | +- compatible: Should be: | |
| 9 | + - "mediatek,mt2701-bdpsys", "syscon" | |
| 10 | +- #clock-cells: Must be 1 | |
| 11 | + | |
| 12 | +The bdpsys controller uses the common clk binding from | |
| 13 | +Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 14 | +The available clocks are defined in dt-bindings/clock/mt*-clk.h. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + | |
| 18 | +bdpsys: clock-controller@1c000000 { | |
| 19 | + compatible = "mediatek,mt2701-bdpsys", "syscon"; | |
| 20 | + reg = <0 0x1c000000 0 0x1000>; | |
| 21 | + #clock-cells = <1>; | |
| 22 | +}; | |
| @@ -0,0 +1,22 @@ | ||
| 1 | +Mediatek ethsys controller | |
| 2 | +============================ | |
| 3 | + | |
| 4 | +The Mediatek ethsys controller provides various clocks to the system. | |
| 5 | + | |
| 6 | +Required Properties: | |
| 7 | + | |
| 8 | +- compatible: Should be: | |
| 9 | + - "mediatek,mt2701-ethsys", "syscon" | |
| 10 | +- #clock-cells: Must be 1 | |
| 11 | + | |
| 12 | +The ethsys controller uses the common clk binding from | |
| 13 | +Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 14 | +The available clocks are defined in dt-bindings/clock/mt*-clk.h. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + | |
| 18 | +ethsys: clock-controller@1b000000 { | |
| 19 | + compatible = "mediatek,mt2701-ethsys", "syscon"; | |
| 20 | + reg = <0 0x1b000000 0 0x1000>; | |
| 21 | + #clock-cells = <1>; | |
| 22 | +}; | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +Mediatek hifsys controller | |
| 2 | +============================ | |
| 3 | + | |
| 4 | +The Mediatek hifsys controller provides various clocks and reset | |
| 5 | +outputs to the system. | |
| 6 | + | |
| 7 | +Required Properties: | |
| 8 | + | |
| 9 | +- compatible: Should be: | |
| 10 | + - "mediatek,mt2701-hifsys", "syscon" | |
| 11 | +- #clock-cells: Must be 1 | |
| 12 | + | |
| 13 | +The hifsys controller uses the common clk binding from | |
| 14 | +Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 15 | +The available clocks are defined in dt-bindings/clock/mt*-clk.h. | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | +hifsys: clock-controller@1a000000 { | |
| 20 | + compatible = "mediatek,mt2701-hifsys", "syscon"; | |
| 21 | + reg = <0 0x1a000000 0 0x1000>; | |
| 22 | + #clock-cells = <1>; | |
| 23 | + #reset-cells = <1>; | |
| 24 | +}; | |
| @@ -5,7 +5,8 @@ The Mediatek imgsys controller provides various clocks to the system. · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required Properties: |
| 7 | 7 | |
| 8 | −- compatible: Should be: | |
| 8 | +- compatible: Should be one of: | |
| 9 | + - "mediatek,mt2701-imgsys", "syscon" | |
| 9 | 10 | - "mediatek,mt8173-imgsys", "syscon" |
| 10 | 11 | - #clock-cells: Must be 1 |
| 11 | 12 | |
| @@ -6,7 +6,8 @@ outputs to the system. · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required Properties: |
| 8 | 8 | |
| 9 | −- compatible: Should be: | |
| 9 | +- compatible: Should be one of: | |
| 10 | + - "mediatek,mt2701-infracfg", "syscon" | |
| 10 | 11 | - "mediatek,mt8135-infracfg", "syscon" |
| 11 | 12 | - "mediatek,mt8173-infracfg", "syscon" |
| 12 | 13 | - #clock-cells: Must be 1 |
| @@ -5,7 +5,8 @@ The Mediatek mmsys controller provides various clocks to the system. · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required Properties: |
| 7 | 7 | |
| 8 | −- compatible: Should be: | |
| 8 | +- compatible: Should be one of: | |
| 9 | + - "mediatek,mt2701-mmsys", "syscon" | |
| 9 | 10 | - "mediatek,mt8173-mmsys", "syscon" |
| 10 | 11 | - #clock-cells: Must be 1 |
| 11 | 12 | |
| @@ -6,7 +6,8 @@ outputs to the system. · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required Properties: |
| 8 | 8 | |
| 9 | −- compatible: Should be: | |
| 9 | +- compatible: Should be one of: | |
| 10 | + - "mediatek,mt2701-pericfg", "syscon" | |
| 10 | 11 | - "mediatek,mt8135-pericfg", "syscon" |
| 11 | 12 | - "mediatek,mt8173-pericfg", "syscon" |
| 12 | 13 | - #clock-cells: Must be 1 |
| @@ -5,7 +5,8 @@ The Mediatek topckgen controller provides various clocks to the system. · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required Properties: |
| 7 | 7 | |
| 8 | −- compatible: Should be: | |
| 8 | +- compatible: Should be one of: | |
| 9 | + - "mediatek,mt2701-topckgen" | |
| 9 | 10 | - "mediatek,mt8135-topckgen" |
| 10 | 11 | - "mediatek,mt8173-topckgen" |
| 11 | 12 | - #clock-cells: Must be 1 |
| @@ -5,7 +5,8 @@ The Mediatek vdecsys controller provides various clocks to the system. · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required Properties: |
| 7 | 7 | |
| 8 | −- compatible: Should be: | |
| 8 | +- compatible: Should be one of: | |
| 9 | + - "mediatek,mt2701-vdecsys", "syscon" | |
| 9 | 10 | - "mediatek,mt8173-vdecsys", "syscon" |
| 10 | 11 | - #clock-cells: Must be 1 |
| 11 | 12 | |
| @@ -180,3 +180,9 @@ Boards: · 179 unmodified lines | ||
| 180 | 180 | |
| 181 | 181 | - DRA722 EVM: Software Development Board for DRA722 |
| 182 | 182 | compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7" |
| 183 | + | |
| 184 | +- DM3730 Logic PD Torpedo + Wireless: Commercial System on Module with WiFi and Bluetooth | |
| 185 | + compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3" | |
| 186 | + | |
| 187 | +- DM3730 Logic PD SOM-LV: Commercial System on Module with WiFi and Bluetooth | |
| 188 | + compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3" | |
| @@ -31,6 +31,10 @@ Rockchip platforms device tree bindings · 30 unmodified lines | ||
| 31 | 31 | or |
| 32 | 32 | - compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288"; |
| 33 | 33 | |
| 34 | +- Firefly Firefly-RK3288 Reload board: | |
| 35 | + Required root node properties: | |
| 36 | + - compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288"; | |
| 37 | + | |
| 34 | 38 | - ChipSPARK PopMetal-RK3288 board: |
| 35 | 39 | Required root node properties: |
| 36 | 40 | - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288"; |
| @@ -110,6 +114,14 @@ Rockchip platforms device tree bindings · 73 unmodified lines | ||
| 110 | 114 | - Rockchip RK3229 Evaluation board: |
| 111 | 115 | - compatible = "rockchip,rk3229-evb", "rockchip,rk3229"; |
| 112 | 116 | |
| 117 | +- Rockchip RK3288 Fennec board: | |
| 118 | + Required root node properties: | |
| 119 | + - compatible = "rockchip,rk3288-fennec", "rockchip,rk3288"; | |
| 120 | + | |
| 113 | 121 | - Rockchip RK3399 evb: |
| 114 | 122 | Required root node properties: |
| 115 | 123 | - compatible = "rockchip,rk3399-evb", "rockchip,rk3399"; |
| 124 | + | |
| 125 | +- Tronsmart Orion R68 Meta | |
| 126 | + Required root node properties: | |
| 127 | + - compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368"; | |
| @@ -10,6 +10,7 @@ Properties: · 9 unmodified lines | ||
| 10 | 10 | - "samsung,exynos5260-pmu" - for Exynos5260 SoC. |
| 11 | 11 | - "samsung,exynos5410-pmu" - for Exynos5410 SoC, |
| 12 | 12 | - "samsung,exynos5420-pmu" - for Exynos5420 SoC. |
| 13 | + - "samsung,exynos5433-pmu" - for Exynos5433 SoC. | |
| 13 | 14 | - "samsung,exynos7-pmu" - for Exynos7 SoC. |
| 14 | 15 | second value must be always "syscon". |
| 15 | 16 | |
| @@ -49,6 +49,8 @@ Boards: · 48 unmodified lines | ||
| 49 | 49 | compatible = "renesas,genmai", "renesas,r7s72100" |
| 50 | 50 | - Gose |
| 51 | 51 | compatible = "renesas,gose", "renesas,r8a7793" |
| 52 | + - H3ULCB (RTP0RC7795SKB00010S) | |
| 53 | + compatible = "renesas,h3ulcb", "renesas,r8a7795"; | |
| 52 | 54 | - Henninger |
| 53 | 55 | compatible = "renesas,henninger", "renesas,r8a7791" |
| 54 | 56 | - Koelsch (RTP0RC7791SEB00010S) |
| @@ -63,9 +65,13 @@ Boards: · 8 unmodified lines | ||
| 63 | 65 | compatible = "renesas,marzen", "renesas,r8a7779" |
| 64 | 66 | - Porter (M2-LCDP) |
| 65 | 67 | compatible = "renesas,porter", "renesas,r8a7791" |
| 68 | + - RSKRZA1 (YR0K77210C000BE) | |
| 69 | + compatible = "renesas,rskrza1", "renesas,r7s72100" | |
| 66 | 70 | - Salvator-X (RTP0RC7795SIPB0010S) |
| 67 | 71 | compatible = "renesas,salvator-x", "renesas,r8a7795"; |
| 68 | 72 | - Salvator-X |
| 69 | 73 | compatible = "renesas,salvator-x", "renesas,r8a7796"; |
| 70 | 74 | - SILK (RTP0RC7794LCB00011S) |
| 71 | 75 | compatible = "renesas,silk", "renesas,r8a7794" |
| 76 | + - Wheat | |
| 77 | + compatible = "renesas,wheat", "renesas,r8a7792" | |
| @@ -14,3 +14,4 @@ using one of the following compatible strings: · 13 unmodified lines | ||
| 14 | 14 | allwinner,sun8i-a83t |
| 15 | 15 | allwinner,sun8i-h3 |
| 16 | 16 | allwinner,sun9i-a80 |
| 17 | + nextthing,gr8 | |
| @@ -4,3 +4,9 @@ Technologic Systems Platforms Device Tree Bindings · 3 unmodified lines | ||
| 4 | 4 | TS-4800 board |
| 5 | 5 | Required root node properties: |
| 6 | 6 | - compatible = "technologic,imx51-ts4800", "fsl,imx51"; |
| 7 | + | |
| 8 | +TS-4900 is a System-on-Module based on the Freescale i.MX6 System-on-Chip. | |
| 9 | +It can be mounted on a carrier board providing additional peripheral connectors. | |
| 10 | +Required root node properties: | |
| 11 | + - compatible = "technologic,imx6dl-ts4900", "fsl,imx6dl" | |
| 12 | + - compatible = "technologic,imx6q-ts4900", "fsl,imx6q" | |
| @@ -13,3 +13,27 @@ Low power management required properties: · 12 unmodified lines | ||
| 13 | 13 | |
| 14 | 14 | Bus matrix required properties: |
| 15 | 15 | - compatible = "zte,zx-bus-matrix" |
| 16 | + | |
| 17 | + | |
| 18 | +--------------------------------------- | |
| 19 | +- ZX296718 SoC: | |
| 20 | + Required root node properties: | |
| 21 | + - compatible = "zte,zx296718" | |
| 22 | + | |
| 23 | +ZX296718 EVB board: | |
| 24 | + - "zte,zx296718-evb" | |
| 25 | + | |
| 26 | +System management required properties: | |
| 27 | + - compatible = "zte,zx296718-aon-sysctrl" | |
| 28 | + - compatible = "zte,zx296718-sysctrl" | |
| 29 | + | |
| 30 | +Example: | |
| 31 | +aon_sysctrl: aon-sysctrl@116000 { | |
| 32 | + compatible = "zte,zx296718-aon-sysctrl", "syscon"; | |
| 33 | + reg = <0x116000 0x1000>; | |
| 34 | +}; | |
| 35 | + | |
| 36 | +sysctrl: sysctrl@1463000 { | |
| 37 | + compatible = "zte,zx296718-sysctrl", "syscon"; | |
| 38 | + reg = <0x1463000 0x1000>; | |
| 39 | +}; | |
| @@ -0,0 +1,17 @@ | ||
| 1 | +Binding for ASCII LCD displays on Imagination Technologies boards | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : should be one of: | |
| 5 | + "img,boston-lcd" | |
| 6 | + "mti,malta-lcd" | |
| 7 | + "mti,sead3-lcd" | |
| 8 | + | |
| 9 | +Required properties for "img,boston-lcd": | |
| 10 | +- reg : memory region locating the device registers | |
| 11 | + | |
| 12 | +Required properties for "mti,malta-lcd" or "mti,sead3-lcd": | |
| 13 | +- regmap: phandle of the system controller containing the LCD registers | |
| 14 | +- offset: offset in bytes to the LCD registers within the system controller | |
| 15 | + | |
| 16 | +The layout of the registers & properties of the display are determined | |
| 17 | +from the compatible string, making this binding somewhat trivial. | |
| @@ -0,0 +1,138 @@ | ||
| 1 | +Qualcomm External Bus Interface 2 (EBI2) | |
| 2 | + | |
| 3 | +The EBI2 contains two peripheral blocks: XMEM and LCDC. The XMEM handles any | |
| 4 | +external memory (such as NAND or other memory-mapped peripherals) whereas | |
| 5 | +LCDC handles LCD displays. | |
| 6 | + | |
| 7 | +As it says it connects devices to an external bus interface, meaning address | |
| 8 | +lines (up to 9 address lines so can only address 1KiB external memory space), | |
| 9 | +data lines (16 bits), OE (output enable), ADV (address valid, used on some | |
| 10 | +NOR flash memories), WE (write enable). This on top of 6 different chip selects | |
| 11 | +(CS0 thru CS5) so that in theory 6 different devices can be connected. | |
| 12 | + | |
| 13 | +Apparently this bus is clocked at 64MHz. It has dedicated pins on the package | |
| 14 | +and the bus can only come out on these pins, however if some of the pins are | |
| 15 | +unused they can be left unconnected or remuxed to be used as GPIO or in some | |
| 16 | +cases other orthogonal functions as well. | |
| 17 | + | |
| 18 | +Also CS1 and CS2 has -A and -B signals. Why they have that is unclear to me. | |
| 19 | + | |
| 20 | +The chip selects have the following memory range assignments. This region of | |
| 21 | +memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big. | |
| 22 | + | |
| 23 | +Chip Select Physical address base | |
| 24 | +CS0 GPIO134 0x1a800000-0x1b000000 (8MB) | |
| 25 | +CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB) | |
| 26 | +CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB) | |
| 27 | +CS3 GPIO133 0x1d000000-0x25000000 (128 MB) | |
| 28 | +CS4 GPIO132 0x1c800000-0x1d000000 (8MB) | |
| 29 | +CS5 GPIO131 0x1c000000-0x1c800000 (8MB) | |
| 30 | + | |
| 31 | +The APQ8060 Qualcomm Application Processor User Guide, 80-N7150-14 Rev. A, | |
| 32 | +August 6, 2012 contains some incomplete documentation of the EBI2. | |
| 33 | + | |
| 34 | +FIXME: the manual mentions "write precharge cycles" and "precharge cycles". | |
| 35 | +We have not been able to figure out which bit fields these correspond to | |
| 36 | +in the hardware, or what valid values exist. The current hypothesis is that | |
| 37 | +this is something just used on the FAST chip selects and that the SLOW | |
| 38 | +chip selects are understood fully. There is also a "byte device enable" | |
| 39 | +flag somewhere for 8bit memories. | |
| 40 | + | |
| 41 | +FIXME: The chipselects have SLOW and FAST configuration registers. It's a bit | |
| 42 | +unclear what this means, if they are mutually exclusive or can be used | |
| 43 | +together, or if some chip selects are hardwired to be FAST and others are SLOW | |
| 44 | +by design. | |
| 45 | + | |
| 46 | +The XMEM registers are totally undocumented but could be partially decoded | |
| 47 | +because the Cypress AN49576 Antioch Westbridge apparently has suspiciously | |
| 48 | +similar register layout, see: http://www.cypress.com/file/105771/download | |
| 49 | + | |
| 50 | +Required properties: | |
| 51 | +- compatible: should be one of: | |
| 52 | + "qcom,msm8660-ebi2" | |
| 53 | + "qcom,apq8060-ebi2" | |
| 54 | +- #address-cells: shoule be <2>: the first cell is the chipselect, | |
| 55 | + the second cell is the offset inside the memory range | |
| 56 | +- #size-cells: should be <1> | |
| 57 | +- ranges: should be set to: | |
| 58 | + ranges = <0 0x0 0x1a800000 0x00800000>, | |
| 59 | + <1 0x0 0x1b000000 0x00800000>, | |
| 60 | + <2 0x0 0x1b800000 0x00800000>, | |
| 61 | + <3 0x0 0x1d000000 0x08000000>, | |
| 62 | + <4 0x0 0x1c800000 0x00800000>, | |
| 63 | + <5 0x0 0x1c000000 0x00800000>; | |
| 64 | +- reg: two ranges of registers: EBI2 config and XMEM config areas | |
| 65 | +- reg-names: should be "ebi2", "xmem" | |
| 66 | +- clocks: two clocks, EBI_2X and EBI | |
| 67 | +- clock-names: shoule be "ebi2x", "ebi2" | |
| 68 | + | |
| 69 | +Optional subnodes: | |
| 70 | +- Nodes inside the EBI2 will be considered device nodes. | |
| 71 | + | |
| 72 | +The following optional properties are properties that can be tagged onto | |
| 73 | +any device subnode. We are assuming that there can be only ONE device per | |
| 74 | +chipselect subnode, else the properties will become ambigous. | |
| 75 | + | |
| 76 | +Optional properties arrays for SLOW chip selects: | |
| 77 | +- qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to | |
| 78 | + drive the data bus after OE is de-asserted, in order to avoid contention on | |
| 79 | + the data bus. They are inserted when reading one CS and switching to another | |
| 80 | + CS or read followed by write on the same CS. Valid values 0 thru 15. Minimum | |
| 81 | + value is actually 1, so a value of 0 will still yield 1 recovery cycle. | |
| 82 | +- qcom,xmem-write-hold-cycles: write hold cycles, these are extra cycles | |
| 83 | + inserted after every write minimum 1. The data out is driven from the time | |
| 84 | + WE is asserted until CS is asserted. With a hold of 1 (value = 0), the CS | |
| 85 | + stays active for 1 extra cycle etc. Valid values 0 thru 15. | |
| 86 | +- qcom,xmem-write-delta-cycles: initial latency for write cycles inserted for | |
| 87 | + the first write to a page or burst memory. Valid values 0 thru 255. | |
| 88 | +- qcom,xmem-read-delta-cycles: initial latency for read cycles inserted for the | |
| 89 | + first read to a page or burst memory. Valid values 0 thru 255. | |
| 90 | +- qcom,xmem-write-wait-cycles: number of wait cycles for every write access, 0=1 | |
| 91 | + cycle. Valid values 0 thru 15. | |
| 92 | +- qcom,xmem-read-wait-cycles: number of wait cycles for every read access, 0=1 | |
| 93 | + cycle. Valid values 0 thru 15. | |
| 94 | + | |
| 95 | +Optional properties arrays for FAST chip selects: | |
| 96 | +- qcom,xmem-address-hold-enable: this is a boolean property stating that we | |
| 97 | + shall hold the address for an extra cycle to meet hold time requirements | |
| 98 | + with ADV assertion. | |
| 99 | +- qcom,xmem-adv-to-oe-recovery-cycles: the number of cycles elapsed before an OE | |
| 100 | + assertion, with respect to the cycle where ADV (address valid) is asserted. | |
| 101 | + 2 means 2 cycles between ADV and OE. Valid values 0, 1, 2 or 3. | |
| 102 | +- qcom,xmem-read-hold-cycles: the length in cycles of the first segment of a | |
| 103 | + read transfer. For a single read trandfer this will be the time from CS | |
| 104 | + assertion to OE assertion. Valid values 0 thru 15. | |
| 105 | + | |
| 106 | + | |
| 107 | +Example: | |
| 108 | + | |
| 109 | +ebi2@1a100000 { | |
| 110 | + compatible = "qcom,apq8060-ebi2"; | |
| 111 | + #address-cells = <2>; | |
| 112 | + #size-cells = <1>; | |
| 113 | + ranges = <0 0x0 0x1a800000 0x00800000>, | |
| 114 | + <1 0x0 0x1b000000 0x00800000>, | |
| 115 | + <2 0x0 0x1b800000 0x00800000>, | |
| 116 | + <3 0x0 0x1d000000 0x08000000>, | |
| 117 | + <4 0x0 0x1c800000 0x00800000>, | |
| 118 | + <5 0x0 0x1c000000 0x00800000>; | |
| 119 | + reg = <0x1a100000 0x1000>, <0x1a110000 0x1000>; | |
| 120 | + reg-names = "ebi2", "xmem"; | |
| 121 | + clocks = <&gcc EBI2_2X_CLK>, <&gcc EBI2_CLK>; | |
| 122 | + clock-names = "ebi2x", "ebi2"; | |
| 123 | + /* Make sure to set up the pin control for the EBI2 */ | |
| 124 | + pinctrl-names = "default"; | |
| 125 | + pinctrl-0 = <&foo_ebi2_pins>; | |
| 126 | + | |
| 127 | + foo-ebi2@2,0 { | |
| 128 | + compatible = "foo"; | |
| 129 | + reg = <2 0x0 0x100>; | |
| 130 | + (...) | |
| 131 | + qcom,xmem-recovery-cycles = <0>; | |
| 132 | + qcom,xmem-write-hold-cycles = <3>; | |
| 133 | + qcom,xmem-write-delta-cycles = <31>; | |
| 134 | + qcom,xmem-read-delta-cycles = <28>; | |
| 135 | + qcom,xmem-write-wait-cycles = <9>; | |
| 136 | + qcom,xmem-read-wait-cycles = <9>; | |
| 137 | + }; | |
| 138 | +}; | |
| @@ -0,0 +1,45 @@ | ||
| 1 | +* Amlogic GXBB AO Clock and Reset Unit | |
| 2 | + | |
| 3 | +The Amlogic GXBB AO clock controller generates and supplies clock to various | |
| 4 | +controllers within the Always-On part of the SoC. | |
| 5 | + | |
| 6 | +Required Properties: | |
| 7 | + | |
| 8 | +- compatible: should be "amlogic,gxbb-aoclkc" | |
| 9 | +- reg: physical base address of the clock controller and length of memory | |
| 10 | + mapped region. | |
| 11 | + | |
| 12 | +- #clock-cells: should be 1. | |
| 13 | + | |
| 14 | +Each clock is assigned an identifier and client nodes can use this identifier | |
| 15 | +to specify the clock which they consume. All available clocks are defined as | |
| 16 | +preprocessor macros in the dt-bindings/clock/gxbb-aoclkc.h header and can be | |
| 17 | +used in device tree sources. | |
| 18 | + | |
| 19 | +- #reset-cells: should be 1. | |
| 20 | + | |
| 21 | +Each reset is assigned an identifier and client nodes can use this identifier | |
| 22 | +to specify the reset which they consume. All available resets are defined as | |
| 23 | +preprocessor macros in the dt-bindings/reset/gxbb-aoclkc.h header and can be | |
| 24 | +used in device tree sources. | |
| 25 | + | |
| 26 | +Example: AO Clock controller node: | |
| 27 | + | |
| 28 | + clkc_AO: clock-controller@040 { | |
| 29 | + compatible = "amlogic,gxbb-aoclkc"; | |
| 30 | + reg = <0x0 0x040 0x0 0x4>; | |
| 31 | + #clock-cells = <1>; | |
| 32 | + #reset-cells = <1>; | |
| 33 | + }; | |
| 34 | + | |
| 35 | +Example: UART controller node that consumes the clock and reset generated | |
| 36 | + by the clock controller: | |
| 37 | + | |
| 38 | + uart_AO: serial@4c0 { | |
| 39 | + compatible = "amlogic,meson-uart"; | |
| 40 | + reg = <0x4c0 0x14>; | |
| 41 | + interrupts = <0 90 1>; | |
| 42 | + clocks = <&clkc_AO CLKID_AO_UART1>; | |
| 43 | + resets = <&clkc_AO RESET_AO_UART1>; | |
| 44 | + status = "disabled"; | |
| 45 | + }; | |
| @@ -5,20 +5,50 @@ Technology (IDT). ARM integrated these oscillators deeply into their · 4 unmodified lines | ||
| 5 | 5 | reference designs by adding special control registers that manage such |
| 6 | 6 | oscillators to their system controllers. |
| 7 | 7 | |
| 8 | −The ARM system controller contains logic to serialize and initialize | |
| 8 | +The various ARM system controllers contain logic to serialize and initialize | |
| 9 | 9 | an ICST clock request after a write to the 32 bit register at an offset |
| 10 | 10 | into the system controller. Furthermore, to even be able to alter one of |
| 11 | 11 | these frequencies, the system controller must first be unlocked by |
| 12 | 12 | writing a special token to another offset in the system controller. |
| 13 | 13 | |
| 14 | +Some ARM hardware contain special versions of the serial interface that only | |
| 15 | +connects the low 8 bits of the VDW (missing one bit), hardwires RDW to | |
| 16 | +different values and sometimes also hardwire the output divider. They | |
| 17 | +therefore have special compatible strings as per this table (the OD value is | |
| 18 | +the value on the pins, not the resulting output divider): | |
| 19 | + | |
| 20 | +Hardware variant: RDW OD VDW | |
| 21 | + | |
| 22 | +Integrator/AP 22 1 Bit 8 0, rest variable | |
| 23 | +integratorap-cm | |
| 24 | + | |
| 25 | +Integrator/AP 46 3 Bit 8 0, rest variable | |
| 26 | +integratorap-sys | |
| 27 | + | |
| 28 | +Integrator/AP 22 or 1 17 or (33 or 25 MHz) | |
| 29 | +integratorap-pci 14 1 14 | |
| 30 | + | |
| 31 | +Integrator/CP 22 variable Bit 8 0, rest variable | |
| 32 | +integratorcp-cm-core | |
| 33 | + | |
| 34 | +Integrator/CP 22 variable Bit 8 0, rest variable | |
| 35 | +integratorcp-cm-mem | |
| 36 | + | |
| 14 | 37 | The ICST oscillator must be provided inside a system controller node. |
| 15 | 38 | |
| 16 | 39 | Required properties: |
| 40 | +- compatible: must be one of | |
| 41 | + "arm,syscon-icst525" | |
| 42 | + "arm,syscon-icst307" | |
| 43 | + "arm,syscon-icst525-integratorap-cm" | |
| 44 | + "arm,syscon-icst525-integratorap-sys" | |
| 45 | + "arm,syscon-icst525-integratorap-pci" | |
| 46 | + "arm,syscon-icst525-integratorcp-cm-core" | |
| 47 | + "arm,syscon-icst525-integratorcp-cm-mem" | |
| 17 | 48 | - lock-offset: the offset address into the system controller where the |
| 18 | 49 | unlocking register is located |
| 19 | 50 | - vco-offset: the offset address into the system controller where the |
| 20 | 51 | ICST control register is located (even 32 bit address) |
| 21 | −- compatible: must be one of "arm,syscon-icst525" or "arm,syscon-icst307" | |
| 22 | 52 | - #clock-cells: must be <0> |
| 23 | 53 | - clocks: parent clock, since the ICST needs a parent clock to derive its |
| 24 | 54 | frequency from, this attribute is compulsory. |
| @@ -0,0 +1,70 @@ | ||
| 1 | +* Peripheral Clock bindings for Marvell Armada 37xx SoCs | |
| 2 | + | |
| 3 | +Marvell Armada 37xx SoCs provide peripheral clocks which are | |
| 4 | +used as clock source for the peripheral of the SoC. | |
| 5 | + | |
| 6 | +There are two different blocks associated to north bridge and south | |
| 7 | +bridge. | |
| 8 | + | |
| 9 | +The peripheral clock consumer should specify the desired clock by | |
| 10 | +having the clock ID in its "clocks" phandle cell. | |
| 11 | + | |
| 12 | +The following is a list of provided IDs for Armada 370 North bridge clocks: | |
| 13 | +ID Clock name Description | |
| 14 | +----------------------------------- | |
| 15 | +0 mmc MMC controller | |
| 16 | +1 sata_host Sata Host | |
| 17 | +2 sec_at Security AT | |
| 18 | +3 sac_dap Security DAP | |
| 19 | +4 tsecm Security Engine | |
| 20 | +5 setm_tmx Serial Embedded Trace Module | |
| 21 | +6 avs Adaptive Voltage Scaling | |
| 22 | +7 sqf SPI | |
| 23 | +8 pwm PWM | |
| 24 | +9 i2c_2 I2C 2 | |
| 25 | +10 i2c_1 I2C 1 | |
| 26 | +11 ddr_phy DDR PHY | |
| 27 | +12 ddr_fclk DDR F clock | |
| 28 | +13 trace Trace | |
| 29 | +14 counter Counter | |
| 30 | +15 eip97 EIP 97 | |
| 31 | +16 cpu CPU | |
| 32 | + | |
| 33 | +The following is a list of provided IDs for Armada 370 South bridge clocks: | |
| 34 | +ID Clock name Description | |
| 35 | +----------------------------------- | |
| 36 | +0 gbe-50 50 MHz parent clock for Gigabit Ethernet | |
| 37 | +1 gbe-core parent clock for Gigabit Ethernet core | |
| 38 | +2 gbe-125 125 MHz parent clock for Gigabit Ethernet | |
| 39 | +3 gbe1-50 50 MHz clock for Gigabit Ethernet port 1 | |
| 40 | +4 gbe0-50 50 MHz clock for Gigabit Ethernet port 0 | |
| 41 | +5 gbe1-125 125 MHz clock for Gigabit Ethernet port 1 | |
| 42 | +6 gbe0-125 125 MHz clock for Gigabit Ethernet port 0 | |
| 43 | +7 gbe1-core Gigabit Ethernet core port 1 | |
| 44 | +8 gbe0-core Gigabit Ethernet core port 0 | |
| 45 | +9 gbe-bm Gigabit Ethernet Buffer Manager | |
| 46 | +10 sdio SDIO | |
| 47 | +11 usb32-sub2-sys USB 2 clock | |
| 48 | +12 usb32-ss-sys USB 3 clock | |
| 49 | + | |
| 50 | +Required properties: | |
| 51 | + | |
| 52 | +- compatible : shall be "marvell,armada-3700-periph-clock-nb" for the | |
| 53 | + north bridge block, or | |
| 54 | + "marvell,armada-3700-periph-clock-sb" for the south bridge block | |
| 55 | +- reg : must be the register address of North/South Bridge Clock register | |
| 56 | +- #clock-cells : from common clock binding; shall be set to 1 | |
| 57 | + | |
| 58 | +- clocks : list of the parent clock phandle in the following order: | |
| 59 | + TBG-A P, TBG-B P, TBG-A S, TBG-B S and finally the xtal clock. | |
| 60 | + | |
| 61 | + | |
| 62 | +Example: | |
| 63 | + | |
| 64 | +nb_perih_clk: nb-periph-clk@13000{ | |
| 65 | + compatible = "marvell,armada-3700-periph-clock-nb"; | |
| 66 | + reg = <0x13000 0x1000>; | |
| 67 | + clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>, | |
| 68 | + <&tbg 3>, <&xtalclk>; | |
| 69 | + #clock-cells = <1>; | |
| 70 | +}; | |
| @@ -0,0 +1,27 @@ | ||
| 1 | +* Time Base Generator Clock bindings for Marvell Armada 37xx SoCs | |
| 2 | + | |
| 3 | +Marvell Armada 37xx SoCs provde Time Base Generator clocks which are | |
| 4 | +used as parent clocks for the peripheral clocks. | |
| 5 | + | |
| 6 | +The TBG clock consumer should specify the desired clock by having the | |
| 7 | +clock ID in its "clocks" phandle cell. | |
| 8 | + | |
| 9 | +The following is a list of provided IDs and clock names on Armada 3700: | |
| 10 | + 0 = TBG A P | |
| 11 | + 1 = TBG B P | |
| 12 | + 2 = TBG A S | |
| 13 | + 3 = TBG B S | |
| 14 | + | |
| 15 | +Required properties: | |
| 16 | +- compatible : shall be "marvell,armada-3700-tbg-clock" | |
| 17 | +- reg : must be the register address of North Bridge PLL register | |
| 18 | +- #clock-cells : from common clock binding; shall be set to 1 | |
| 19 | + | |
| 20 | +Example: | |
| 21 | + | |
| 22 | +tbg: tbg@13200 { | |
| 23 | + compatible = "marvell,armada-3700-tbg-clock"; | |
| 24 | + reg = <0x13200 0x1000>; | |
| 25 | + clocks = <&xtalclk>; | |
| 26 | + #clock-cells = <1>; | |
| 27 | +}; | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +* Xtal Clock bindings for Marvell Armada 37xx SoCs | |
| 2 | + | |
| 3 | +Marvell Armada 37xx SoCs allow to determine the xtal clock frequencies by | |
| 4 | +reading the gpio latch register. | |
| 5 | + | |
| 6 | +This node must be a subnode of the node exposing the register address | |
| 7 | +of the GPIO block where the gpio latch is located. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible : shall be one of the following: | |
| 11 | + "marvell,armada-3700-xtal-clock" | |
| 12 | +- #clock-cells : from common clock binding; shall be set to 0 | |
| 13 | + | |
| 14 | +Optional properties: | |
| 15 | +- clock-output-names : from common clock binding; allows overwrite default clock | |
| 16 | + output names ("xtal") | |
| 17 | + | |
| 18 | +Example: | |
| 19 | +gpio1: gpio@13800 { | |
| 20 | + compatible = "marvell,armada-3700-gpio", "syscon", "simple-mfd"; | |
| 21 | + reg = <0x13800 0x1000>; | |
| 22 | + | |
| 23 | + xtalclk: xtal-clk { | |
| 24 | + compatible = "marvell,armada-3700-xtal-clock"; | |
| 25 | + clock-output-names = "xtal"; | |
| 26 | + #clock-cells = <0>; | |
| 27 | + }; | |
| 28 | +}; | |
| @@ -6,7 +6,8 @@ This binding uses the common clock binding[1]. · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible : shall be one of the following: |
| 9 | − "atmel,at91sam9x5-sckc": | |
| 9 | + "atmel,at91sam9x5-sckc" or | |
| 10 | + "atmel,sama5d4-sckc": | |
| 10 | 11 | at91 SCKC (Slow Clock Controller) |
| 11 | 12 | This node contains the slow clock definitions. |
| 12 | 13 | |
| @@ -0,0 +1,36 @@ | ||
| 1 | +Broadcom BCM53573 ILP clock | |
| 2 | +=========================== | |
| 3 | + | |
| 4 | +This binding uses the common clock binding: | |
| 5 | + Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 6 | + | |
| 7 | +This binding is used for ILP clock (sometimes referred as "slow clock") | |
| 8 | +on Broadcom BCM53573 devices using Cortex-A7 CPU. | |
| 9 | + | |
| 10 | +ILP's rate has to be calculated on runtime and it depends on ALP clock | |
| 11 | +which has to be referenced. | |
| 12 | + | |
| 13 | +This clock is part of PMU (Power Management Unit), a Broadcom's device | |
| 14 | +handing power-related aspects. Its node must be sub-node of the PMU | |
| 15 | +device. | |
| 16 | + | |
| 17 | +Required properties: | |
| 18 | +- compatible: "brcm,bcm53573-ilp" | |
| 19 | +- clocks: has to reference an ALP clock | |
| 20 | +- #clock-cells: should be <0> | |
| 21 | +- clock-output-names: from common clock bindings, should contain clock | |
| 22 | + name | |
| 23 | + | |
| 24 | +Example: | |
| 25 | + | |
| 26 | +pmu@18012000 { | |
| 27 | + compatible = "simple-mfd", "syscon"; | |
| 28 | + reg = <0x18012000 0x00001000>; | |
| 29 | + | |
| 30 | + ilp { | |
| 31 | + compatible = "brcm,bcm53573-ilp"; | |
| 32 | + clocks = <&alp>; | |
| 33 | + #clock-cells = <0>; | |
| 34 | + clock-output-names = "ilp"; | |
| 35 | + }; | |
| 36 | +}; | |
| @@ -10,6 +10,8 @@ Required Properties: · 9 unmodified lines | ||
| 10 | 10 | - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs. |
| 11 | 11 | - "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250 |
| 12 | 12 | SoCs. |
| 13 | + - "samsung,exynos5410-audss-clock" - controller compatible with Exynos5410 | |
| 14 | + SoCs. | |
| 13 | 15 | - "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420 |
| 14 | 16 | SoCs. |
| 15 | 17 | - reg: physical base address and length of the controller's register set. |
| @@ -91,5 +93,5 @@ i2s0: i2s@03830000 { · 75 unmodified lines | ||
| 91 | 93 | <&clock_audss EXYNOS_MOUT_AUDSS>, |
| 92 | 94 | <&clock_audss EXYNOS_MOUT_I2S>; |
| 93 | 95 | clock-names = "iis", "i2s_opclk0", "i2s_opclk1", |
| 94 | − "mout_audss", "mout_i2s"; | |
| 96 | + "mout_audss", "mout_i2s"; | |
| 95 | 97 | }; |
| @@ -12,24 +12,29 @@ Required Properties: · 11 unmodified lines | ||
| 12 | 12 | |
| 13 | 13 | - #clock-cells: should be 1. |
| 14 | 14 | |
| 15 | +- clocks: should contain an entry specifying the root clock from external | |
| 16 | + oscillator supplied through XXTI or XusbXTI pin. This clock should be | |
| 17 | + defined using standard clock bindings with "fin_pll" clock-output-name. | |
| 18 | + That clock is being passed internally to the 9 PLLs. | |
| 19 | + | |
| 15 | 20 | All available clocks are defined as preprocessor macros in |
| 16 | 21 | dt-bindings/clock/exynos5410.h header and can be used in device |
| 17 | 22 | tree sources. |
| 18 | 23 | |
| 19 | −External clock: | |
| 20 | − | |
| 21 | −There is clock that is generated outside the SoC. It | |
| 22 | −is expected that it is defined using standard clock bindings | |
| 23 | −with following clock-output-name: | |
| 24 | − | |
| 25 | − - "fin_pll" - PLL input clock from XXTI | |
| 26 | − | |
| 27 | 24 | Example 1: An example of a clock controller node is listed below. |
| 28 | 25 | |
| 26 | + fin_pll: xxti { | |
| 27 | + compatible = "fixed-clock"; | |
| 28 | + clock-frequency = <24000000>; | |
| 29 | + clock-output-names = "fin_pll"; | |
| 30 | + #clock-cells = <0>; | |
| 31 | + }; | |
| 32 | + | |
| 29 | 33 | clock: clock-controller@0x10010000 { |
| 30 | 34 | compatible = "samsung,exynos5410-clock"; |
| 31 | 35 | reg = <0x10010000 0x30000>; |
| 32 | 36 | #clock-cells = <1>; |
| 37 | + clocks = <&fin_pll>; | |
| 33 | 38 | }; |
| 34 | 39 | |
| 35 | 40 | Example 2: UART controller node that consumes the clock generated by the clock |
| @@ -1,10 +1,24 @@ | ||
| 1 | −Binding for Maxim MAX77686 32k clock generator block | |
| 1 | +Binding for Maxim MAX77686/MAX77802/MAX77620 32k clock generator block | |
| 2 | 2 | |
| 3 | −This is a part of device tree bindings of MAX77686 multi-function device. | |
| 4 | −More information can be found in bindings/mfd/max77686.txt file. | |
| 3 | +This is a part of device tree bindings of MAX77686/MAX77802/MAX77620 | |
| 4 | +multi-function device. More information can be found in MFD DT binding | |
| 5 | +doc as follows: | |
| 6 | + bindings/mfd/max77686.txt for MAX77686 and | |
| 7 | + bindings/mfd/max77802.txt for MAX77802 and | |
| 8 | + bindings/mfd/max77620.txt for MAX77620. | |
| 5 | 9 | |
| 6 | 10 | The MAX77686 contains three 32.768khz clock outputs that can be controlled |
| 7 | −(gated/ungated) over I2C. | |
| 11 | +(gated/ungated) over I2C. Clocks are defined as preprocessor macros in | |
| 12 | +dt-bindings/clock/maxim,max77686.h. | |
| 13 | + | |
| 14 | + | |
| 15 | +The MAX77802 contains two 32.768khz clock outputs that can be controlled | |
| 16 | +(gated/ungated) over I2C. Clocks are defined as preprocessor macros in | |
| 17 | +dt-bindings/clock/maxim,max77802.h. | |
| 18 | + | |
| 19 | +The MAX77686 contains one 32.768khz clock outputs that can be controlled | |
| 20 | +(gated/ungated) over I2C. Clocks are defined as preprocessor macros in | |
| 21 | +dt-bindings/clock/maxim,max77620.h. | |
| 8 | 22 | |
| 9 | 23 | Following properties should be presend in main device node of the MFD chip. |
| 10 | 24 | |
| @@ -17,30 +31,84 @@ Optional properties: · 6 unmodified lines | ||
| 17 | 31 | |
| 18 | 32 | Each clock is assigned an identifier and client nodes can use this identifier |
| 19 | 33 | to specify the clock which they consume. Following indices are allowed: |
| 20 | − - 0: 32khz_ap clock, | |
| 21 | − - 1: 32khz_cp clock, | |
| 22 | − - 2: 32khz_pmic clock. | |
| 34 | + - 0: 32khz_ap clock (max77686, max77802), 32khz_out0 (max77620) | |
| 35 | + - 1: 32khz_cp clock (max77686, max77802), | |
| 36 | + - 2: 32khz_pmic clock (max77686). | |
| 37 | + | |
| 38 | +Clocks are defined as preprocessor macros in above dt-binding header for | |
| 39 | +respective chips. | |
| 40 | + | |
| 41 | +Example: | |
| 42 | + | |
| 43 | +1. With MAX77686: | |
| 44 | + | |
| 45 | +#include <dt-bindings/clock/maxim,max77686.h> | |
| 46 | +/* ... */ | |
| 47 | + | |
| 48 | + Node of the MFD chip | |
| 49 | + max77686: max77686@09 { | |
| 50 | + compatible = "maxim,max77686"; | |
| 51 | + interrupt-parent = <&wakeup_eint>; | |
| 52 | + interrupts = <26 0>; | |
| 53 | + reg = <0x09>; | |
| 54 | + #clock-cells = <1>; | |
| 55 | + | |
| 56 | + /* ... */ | |
| 57 | + }; | |
| 58 | + | |
| 59 | + Clock consumer node | |
| 60 | + | |
| 61 | + foo@0 { | |
| 62 | + compatible = "bar,foo"; | |
| 63 | + /* ... */ | |
| 64 | + clock-names = "my-clock"; | |
| 65 | + clocks = <&max77686 MAX77686_CLK_PMIC>; | |
| 66 | + }; | |
| 67 | + | |
| 68 | +2. With MAX77802: | |
| 69 | + | |
| 70 | +#include <dt-bindings/clock/maxim,max77802.h> | |
| 71 | +/* ... */ | |
| 72 | + | |
| 73 | + Node of the MFD chip | |
| 74 | + max77802: max77802@09 { | |
| 75 | + compatible = "maxim,max77802"; | |
| 76 | + interrupt-parent = <&wakeup_eint>; | |
| 77 | + interrupts = <26 0>; | |
| 78 | + reg = <0x09>; | |
| 79 | + #clock-cells = <1>; | |
| 80 | + | |
| 81 | + /* ... */ | |
| 82 | + }; | |
| 83 | + | |
| 84 | + Clock consumer node | |
| 85 | + | |
| 86 | + foo@0 { | |
| 87 | + compatible = "bar,foo"; | |
| 88 | + /* ... */ | |
| 89 | + clock-names = "my-clock"; | |
| 90 | + clocks = <&max77802 MAX77802_CLK_32K_AP>; | |
| 91 | + }; | |
| 23 | 92 | |
| 24 | −Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77686.h | |
| 25 | −header and can be used in device tree sources. | |
| 26 | 93 | |
| 27 | −Example: Node of the MFD chip | |
| 94 | +3. With MAX77620: | |
| 28 | 95 | |
| 29 | − max77686: max77686@09 { | |
| 30 | − compatible = "maxim,max77686"; | |
| 31 | − interrupt-parent = <&wakeup_eint>; | |
| 32 | − interrupts = <26 0>; | |
| 33 | − reg = <0x09>; | |
| 34 | − #clock-cells = <1>; | |
| 96 | +#include <dt-bindings/clock/maxim,max77620.h> | |
| 97 | +/* ... */ | |
| 35 | 98 | |
| 36 | − /* ... */ | |
| 37 | − }; | |
| 99 | + Node of the MFD chip | |
| 100 | + max77620: max77620@3c { | |
| 101 | + compatible = "maxim,max77620"; | |
| 102 | + reg = <0x3c>; | |
| 103 | + #clock-cells = <1>; | |
| 104 | + /* ... */ | |
| 105 | + }; | |
| 38 | 106 | |
| 39 | −Example: Clock consumer node | |
| 107 | + Clock consumer node | |
| 40 | 108 | |
| 41 | − foo@0 { | |
| 42 | − compatible = "bar,foo"; | |
| 43 | − /* ... */ | |
| 44 | − clock-names = "my-clock"; | |
| 45 | − clocks = <&max77686 MAX77686_CLK_PMIC>; | |
| 46 | − }; | |
| 109 | + foo@0 { | |
| 110 | + compatible = "bar,foo"; | |
| 111 | + /* ... */ | |
| 112 | + clock-names = "my-clock"; | |
| 113 | + clocks = <&max77620 MAX77620_CLK_32K_OUT0>; | |
| 114 | + }; | |
| @@ -1,44 +0,0 @@ | ||
| 1 | −Binding for Maxim MAX77802 32k clock generator block | |
| 2 | − | |
| 3 | −This is a part of device tree bindings of MAX77802 multi-function device. | |
| 4 | −More information can be found in bindings/mfd/max77802.txt file. | |
| 5 | − | |
| 6 | −The MAX77802 contains two 32.768khz clock outputs that can be controlled | |
| 7 | −(gated/ungated) over I2C. | |
| 8 | − | |
| 9 | −Following properties should be present in main device node of the MFD chip. | |
| 10 | − | |
| 11 | −Required properties: | |
| 12 | −- #clock-cells: From common clock binding; shall be set to 1. | |
| 13 | − | |
| 14 | −Optional properties: | |
| 15 | −- clock-output-names: From common clock binding. | |
| 16 | − | |
| 17 | −Each clock is assigned an identifier and client nodes can use this identifier | |
| 18 | −to specify the clock which they consume. Following indices are allowed: | |
| 19 | − - 0: 32khz_ap clock, | |
| 20 | − - 1: 32khz_cp clock. | |
| 21 | − | |
| 22 | −Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max77802.h | |
| 23 | −header and can be used in device tree sources. | |
| 24 | − | |
| 25 | −Example: Node of the MFD chip | |
| 26 | − | |
| 27 | − max77802: max77802@09 { | |
| 28 | − compatible = "maxim,max77802"; | |
| 29 | − interrupt-parent = <&wakeup_eint>; | |
| 30 | − interrupts = <26 0>; | |
| 31 | − reg = <0x09>; | |
| 32 | − #clock-cells = <1>; | |
| 33 | − | |
| 34 | − /* ... */ | |
| 35 | − }; | |
| 36 | − | |
| 37 | −Example: Clock consumer node | |
| 38 | − | |
| 39 | − foo@0 { | |
| 40 | − compatible = "bar,foo"; | |
| 41 | − /* ... */ | |
| 42 | − clock-names = "my-clock"; | |
| 43 | − clocks = <&max77802 MAX77802_CLK_32K_AP>; | |
| 44 | − }; | |
| @@ -52,6 +52,7 @@ Required properties: · 51 unmodified lines | ||
| 52 | 52 | "marvell,dove-core-clock" - for Dove SoC core clocks |
| 53 | 53 | "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180) |
| 54 | 54 | "marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC |
| 55 | + "marvell,mv88f5181-core-clock" - for Orion MV88F5181 SoC | |
| 55 | 56 | "marvell,mv88f5182-core-clock" - for Orion MV88F5182 SoC |
| 56 | 57 | "marvell,mv88f5281-core-clock" - for Orion MV88F5281 SoC |
| 57 | 58 | "marvell,mv88f6183-core-clock" - for Orion MV88F6183 SoC |
| @@ -86,6 +86,8 @@ ID Clock Peripheral · 85 unmodified lines | ||
| 86 | 86 | 7 pex3 PCIe 3 |
| 87 | 87 | 8 pex0 PCIe 0 |
| 88 | 88 | 9 usb3h0 USB3 Host 0 |
| 89 | +10 usb3h1 USB3 Host 1 | |
| 90 | +15 sata0 SATA 0 | |
| 89 | 91 | 17 sdio SDIO |
| 90 | 92 | 22 xor0 XOR 0 |
| 91 | 93 | 28 xor1 XOR 1 |
| @@ -15,6 +15,7 @@ Required properties : · 14 unmodified lines | ||
| 15 | 15 | "qcom,gcc-msm8974pro" |
| 16 | 16 | "qcom,gcc-msm8974pro-ac" |
| 17 | 17 | "qcom,gcc-msm8996" |
| 18 | + "qcom,gcc-mdm9615" | |
| 18 | 19 | |
| 19 | 20 | - reg : shall contain base register location and length |
| 20 | 21 | - #clock-cells : shall contain 1 |
| @@ -22,6 +23,11 @@ Required properties : · 1 unmodified line | ||
| 22 | 23 | |
| 23 | 24 | Optional properties : |
| 24 | 25 | - #power-domain-cells : shall contain 1 |
| 26 | +- Qualcomm TSENS (thermal sensor device) on some devices can | |
| 27 | +be part of GCC and hence the TSENS properties can also be | |
| 28 | +part of the GCC/clock-controller node. | |
| 29 | +For more details on the TSENS properties please refer | |
| 30 | +Documentation/devicetree/bindings/thermal/qcom-tsens.txt | |
| 25 | 31 | |
| 26 | 32 | Example: |
| 27 | 33 | clock-controller@900000 { |
| @@ -31,3 +37,14 @@ Example: · 3 unmodified lines | ||
| 31 | 37 | #reset-cells = <1>; |
| 32 | 38 | #power-domain-cells = <1>; |
| 33 | 39 | }; |
| 40 | + | |
| 41 | +Example of GCC with TSENS properties: | |
| 42 | + clock-controller@900000 { | |
| 43 | + compatible = "qcom,gcc-apq8064"; | |
| 44 | + reg = <0x00900000 0x4000>; | |
| 45 | + nvmem-cells = <&tsens_calib>, <&tsens_backup>; | |
| 46 | + nvmem-cell-names = "calib", "calib_backup"; | |
| 47 | + #clock-cells = <1>; | |
| 48 | + #reset-cells = <1>; | |
| 49 | + #thermal-sensor-cells = <1>; | |
| 50 | + }; | |
| @@ -7,6 +7,7 @@ Required properties : · 6 unmodified lines | ||
| 7 | 7 | "qcom,lcc-msm8960" |
| 8 | 8 | "qcom,lcc-apq8064" |
| 9 | 9 | "qcom,lcc-ipq8064" |
| 10 | + "qcom,lcc-mdm9615" | |
| 10 | 11 | |
| 11 | 12 | - reg : shall contain base register location and length |
| 12 | 13 | - #clock-cells : shall contain 1 |
| @@ -1,16 +1,16 @@ | ||
| 1 | 1 | STMicroelectronics STM32 Reset and Clock Controller |
| 2 | 2 | =================================================== |
| 3 | 3 | |
| 4 | −The RCC IP is both a reset and a clock controller. This documentation only | |
| 5 | −describes the clock part. | |
| 4 | +The RCC IP is both a reset and a clock controller. | |
| 6 | 5 | |
| 7 | −Please also refer to clock-bindings.txt in this directory for common clock | |
| 8 | −controller binding usage. | |
| 6 | +Please refer to clock-bindings.txt for common clock controller binding usage. | |
| 7 | +Please also refer to reset.txt for common reset controller binding usage. | |
| 9 | 8 | |
| 10 | 9 | Required properties: |
| 11 | 10 | - compatible: Should be "st,stm32f42xx-rcc" |
| 12 | 11 | - reg: should be register base and length as documented in the |
| 13 | 12 | datasheet |
| 13 | +- #reset-cells: 1, see below | |
| 14 | 14 | - #clock-cells: 2, device nodes should specify the clock in their "clocks" |
| 15 | 15 | property, containing a phandle to the clock device node, an index selecting |
| 16 | 16 | between gated clocks and other clocks and an index specifying the clock to |
| @@ -19,6 +19,7 @@ Required properties: · 2 unmodified lines | ||
| 19 | 19 | Example: |
| 20 | 20 | |
| 21 | 21 | rcc: rcc@40023800 { |
| 22 | + #reset-cells = <1>; | |
| 22 | 23 | #clock-cells = <2> |
| 23 | 24 | compatible = "st,stm32f42xx-rcc", "st,stm32-rcc"; |
| 24 | 25 | reg = <0x40023800 0x400>; |
| @@ -35,16 +36,23 @@ from the first RCC clock enable register (RCC_AHB1ENR, address offset 0x30). · 10 unmodified lines | ||
| 35 | 36 | It is calculated as: index = register_offset / 4 * 32 + bit_offset. |
| 36 | 37 | Where bit_offset is the bit offset within the register (LSB is 0, MSB is 31). |
| 37 | 38 | |
| 39 | +To simplify the usage and to share bit definition with the reset and clock | |
| 40 | +drivers of the RCC IP, macros are available to generate the index in | |
| 41 | +human-readble format. | |
| 42 | + | |
| 43 | +For STM32F4 series, the macro are available here: | |
| 44 | + - include/dt-bindings/mfd/stm32f4-rcc.h | |
| 45 | + | |
| 38 | 46 | Example: |
| 39 | 47 | |
| 40 | 48 | /* Gated clock, AHB1 bit 0 (GPIOA) */ |
| 41 | 49 | ... { |
| 42 | − clocks = <&rcc 0 0> | |
| 50 | + clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)> | |
| 43 | 51 | }; |
| 44 | 52 | |
| 45 | 53 | /* Gated clock, AHB2 bit 4 (CRYP) */ |
| 46 | 54 | ... { |
| 47 | − clocks = <&rcc 0 36> | |
| 55 | + clocks = <&rcc 0 STM32F4_AHB2_CLOCK(CRYP)> | |
| 48 | 56 | }; |
| 49 | 57 | |
| 50 | 58 | Specifying other clocks |
| @@ -61,5 +69,25 @@ Example: · 10 unmodified lines | ||
| 61 | 69 | |
| 62 | 70 | /* Misc clock, FCLK */ |
| 63 | 71 | ... { |
| 64 | − clocks = <&rcc 1 1> | |
| 72 | + clocks = <&rcc 1 STM32F4_APB1_CLOCK(TIM2)> | |
| 73 | + }; | |
| 74 | + | |
| 75 | + | |
| 76 | +Specifying softreset control of devices | |
| 77 | +======================================= | |
| 78 | + | |
| 79 | +Device nodes should specify the reset channel required in their "resets" | |
| 80 | +property, containing a phandle to the reset device node and an index specifying | |
| 81 | +which channel to use. | |
| 82 | +The index is the bit number within the RCC registers bank, starting from RCC | |
| 83 | +base address. | |
| 84 | +It is calculated as: index = register_offset / 4 * 32 + bit_offset. | |
| 85 | +Where bit_offset is the bit offset within the register. | |
| 86 | +For example, for CRC reset: | |
| 87 | + crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140 | |
| 88 | + | |
| 89 | +example: | |
| 90 | + | |
| 91 | + timer2 { | |
| 92 | + resets = <&rcc STM32F4_APB1_RESET(TIM2)>; | |
| 65 | 93 | }; |
| @@ -1,49 +0,0 @@ | ||
| 1 | −Binding for a ST divider and multiplexer clock driver. | |
| 2 | − | |
| 3 | −This binding uses the common clock binding[1]. | |
| 4 | −Base address is located to the parent node. See clock binding[2] | |
| 5 | − | |
| 6 | −[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 7 | −[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt | |
| 8 | − | |
| 9 | −Required properties: | |
| 10 | − | |
| 11 | −- compatible : shall be: | |
| 12 | − "st,clkgena-divmux-c65-hs", "st,clkgena-divmux" | |
| 13 | − "st,clkgena-divmux-c65-ls", "st,clkgena-divmux" | |
| 14 | − "st,clkgena-divmux-c32-odf0", "st,clkgena-divmux" | |
| 15 | − "st,clkgena-divmux-c32-odf1", "st,clkgena-divmux" | |
| 16 | − "st,clkgena-divmux-c32-odf2", "st,clkgena-divmux" | |
| 17 | − "st,clkgena-divmux-c32-odf3", "st,clkgena-divmux" | |
| 18 | − | |
| 19 | −- #clock-cells : From common clock binding; shall be set to 1. | |
| 20 | − | |
| 21 | −- clocks : From common clock binding | |
| 22 | − | |
| 23 | −- clock-output-names : From common clock binding. | |
| 24 | − | |
| 25 | −Example: | |
| 26 | − | |
| 27 | − clockgen-a@fd345000 { | |
| 28 | − reg = <0xfd345000 0xb50>; | |
| 29 | − | |
| 30 | − clk_m_a1_div1: clk-m-a1-div1 { | |
| 31 | − #clock-cells = <1>; | |
| 32 | − compatible = "st,clkgena-divmux-c32-odf1", | |
| 33 | − "st,clkgena-divmux"; | |
| 34 | − | |
| 35 | − clocks = <&clk_m_a1_osc_prediv>, | |
| 36 | − <&clk_m_a1_pll0 1>, /* PLL0 PHI1 */ | |
| 37 | − <&clk_m_a1_pll1 1>; /* PLL1 PHI1 */ | |
| 38 | − | |
| 39 | − clock-output-names = "clk-m-rx-icn-ts", | |
| 40 | − "clk-m-rx-icn-vdp-0", | |
| 41 | − "", /* unused */ | |
| 42 | − "clk-m-prv-t1-bus", | |
| 43 | − "clk-m-icn-reg-12", | |
| 44 | − "clk-m-icn-reg-10", | |
| 45 | − "", /* unused */ | |
| 46 | − "clk-m-icn-st231"; | |
| 47 | − }; | |
| 48 | − }; | |
| 49 | − | |
| @@ -10,14 +10,7 @@ This binding uses the common clock binding[1]. · 9 unmodified lines | ||
| 10 | 10 | Required properties: |
| 11 | 11 | |
| 12 | 12 | - compatible : shall be: |
| 13 | − "st,stih416-clkgenc-vcc-hd", "st,clkgen-mux" | |
| 14 | − "st,stih416-clkgenf-vcc-fvdp", "st,clkgen-mux" | |
| 15 | − "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux" | |
| 16 | − "st,stih416-clkgenf-vcc-hd", "st,clkgen-mux" | |
| 17 | − "st,stih416-clkgenf-vcc-sd", "st,clkgen-mux" | |
| 18 | − "st,stih415-clkgen-a9-mux", "st,clkgen-mux" | |
| 19 | − "st,stih416-clkgen-a9-mux", "st,clkgen-mux" | |
| 20 | − "st,stih407-clkgen-a9-mux", "st,clkgen-mux" | |
| 13 | + "st,stih407-clkgen-a9-mux" | |
| 21 | 14 | |
| 22 | 15 | - #clock-cells : from common clock binding; shall be set to 0. |
| 23 | 16 | |
| @@ -27,10 +20,13 @@ Required properties: · 3 unmodified lines | ||
| 27 | 20 | |
| 28 | 21 | Example: |
| 29 | 22 | |
| 30 | − clk_m_hva: clk-m-hva@fd690868 { | |
| 23 | + clk_m_a9: clk-m-a9@92b0000 { | |
| 31 | 24 | #clock-cells = <0>; |
| 32 | − compatible = "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux"; | |
| 33 | − reg = <0xfd690868 4>; | |
| 25 | + compatible = "st,stih407-clkgen-a9-mux"; | |
| 26 | + reg = <0x92b0000 0x10000>; | |
| 34 | 27 | |
| 35 | − clocks = <&clockgen_f 1>, <&clk_m_a1_div0 3>; | |
| 28 | + clocks = <&clockgen_a9_pll 0>, | |
| 29 | + <&clockgen_a9_pll 0>, | |
| 30 | + <&clk_s_c0_flexgen 13>, | |
| 31 | + <&clk_m_a9_ext2f_div2>; | |
| 36 | 32 | }; |
| @@ -9,24 +9,10 @@ Base address is located to the parent node. See clock binding[2] · 8 unmodified lines | ||
| 9 | 9 | Required properties: |
| 10 | 10 | |
| 11 | 11 | - compatible : shall be: |
| 12 | − "st,clkgena-prediv-c65", "st,clkgena-prediv" | |
| 13 | − "st,clkgena-prediv-c32", "st,clkgena-prediv" | |
| 14 | − | |
| 15 | − "st,clkgena-plls-c65" | |
| 16 | − "st,plls-c32-a1x-0", "st,clkgen-plls-c32" | |
| 17 | − "st,plls-c32-a1x-1", "st,clkgen-plls-c32" | |
| 18 | − "st,stih415-plls-c32-a9", "st,clkgen-plls-c32" | |
| 19 | − "st,stih415-plls-c32-ddr", "st,clkgen-plls-c32" | |
| 20 | − "st,stih416-plls-c32-a9", "st,clkgen-plls-c32" | |
| 21 | − "st,stih416-plls-c32-ddr", "st,clkgen-plls-c32" | |
| 22 | − "st,stih407-plls-c32-a0", "st,clkgen-plls-c32" | |
| 23 | − "st,stih407-plls-c32-a9", "st,clkgen-plls-c32" | |
| 24 | − "sst,plls-c32-cx_0", "st,clkgen-plls-c32" | |
| 25 | − "sst,plls-c32-cx_1", "st,clkgen-plls-c32" | |
| 26 | − "st,stih418-plls-c28-a9", "st,clkgen-plls-c32" | |
| 27 | − | |
| 28 | − "st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32" | |
| 29 | − "st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32" | |
| 12 | + "st,clkgen-pll0" | |
| 13 | + "st,clkgen-pll1" | |
| 14 | + "st,stih407-clkgen-plla9" | |
| 15 | + "st,stih418-clkgen-plla9" | |
| 30 | 16 | |
| 31 | 17 | - #clock-cells : From common clock binding; shall be set to 1. |
| 32 | 18 | |
| @@ -36,17 +22,16 @@ Required properties: · 3 unmodified lines | ||
| 36 | 22 | |
| 37 | 23 | Example: |
| 38 | 24 | |
| 39 | − clockgen-a@fee62000 { | |
| 40 | − reg = <0xfee62000 0xb48>; | |
| 25 | + clockgen-a9@92b0000 { | |
| 26 | + compatible = "st,clkgen-c32"; | |
| 27 | + reg = <0x92b0000 0xffff>; | |
| 41 | 28 | |
| 42 | − clk_s_a0_pll: clk-s-a0-pll { | |
| 29 | + clockgen_a9_pll: clockgen-a9-pll { | |
| 43 | 30 | #clock-cells = <1>; |
| 44 | − compatible = "st,clkgena-plls-c65"; | |
| 31 | + compatible = "st,stih407-clkgen-plla9"; | |
| 45 | 32 | |
| 46 | 33 | clocks = <&clk_sysin>; |
| 47 | 34 | |
| 48 | − clock-output-names = "clk-s-a0-pll0-hs", | |
| 49 | − "clk-s-a0-pll0-ls", | |
| 50 | − "clk-s-a0-pll1"; | |
| 35 | + clock-output-names = "clockgen-a9-pll-odf"; | |
| 51 | 36 | }; |
| 52 | 37 | }; |
| @@ -1,36 +0,0 @@ | ||
| 1 | −Binding for a ST pre-divider clock driver. | |
| 2 | − | |
| 3 | −This binding uses the common clock binding[1]. | |
| 4 | −Base address is located to the parent node. See clock binding[2] | |
| 5 | − | |
| 6 | −[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 7 | −[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt | |
| 8 | − | |
| 9 | −Required properties: | |
| 10 | − | |
| 11 | −- compatible : shall be: | |
| 12 | − "st,clkgena-prediv-c65", "st,clkgena-prediv" | |
| 13 | − "st,clkgena-prediv-c32", "st,clkgena-prediv" | |
| 14 | − | |
| 15 | −- #clock-cells : From common clock binding; shall be set to 0. | |
| 16 | − | |
| 17 | −- clocks : From common clock binding | |
| 18 | − | |
| 19 | −- clock-output-names : From common clock binding. | |
| 20 | − | |
| 21 | −Example: | |
| 22 | − | |
| 23 | − clockgen-a@fd345000 { | |
| 24 | − reg = <0xfd345000 0xb50>; | |
| 25 | − | |
| 26 | − clk_m_a2_osc_prediv: clk-m-a2-osc-prediv { | |
| 27 | − #clock-cells = <0>; | |
| 28 | − compatible = "st,clkgena-prediv-c32", | |
| 29 | − "st,clkgena-prediv"; | |
| 30 | − | |
| 31 | − clocks = <&clk_sysin>; | |
| 32 | − | |
| 33 | − clock-output-names = "clk-m-a2-osc-prediv"; | |
| 34 | − }; | |
| 35 | − }; | |
| 36 | − | |
| @@ -1,61 +0,0 @@ | ||
| 1 | −Binding for a type of STMicroelectronics clock crossbar (VCC). | |
| 2 | − | |
| 3 | −The crossbar can take up to 4 input clocks and control up to 16 | |
| 4 | −output clocks. Not all inputs or outputs have to be in use in a | |
| 5 | −particular instantiation. Each output can be individually enabled, | |
| 6 | −select any of the input clocks and apply a divide (by 1,2,4 or 8) to | |
| 7 | −that selected clock. | |
| 8 | − | |
| 9 | −This binding uses the common clock binding[1]. | |
| 10 | − | |
| 11 | −[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 12 | − | |
| 13 | −Required properties: | |
| 14 | − | |
| 15 | −- compatible : shall be: | |
| 16 | − "st,stih416-clkgenc", "st,vcc" | |
| 17 | − "st,stih416-clkgenf", "st,vcc" | |
| 18 | − | |
| 19 | −- #clock-cells : from common clock binding; shall be set to 1. | |
| 20 | − | |
| 21 | −- reg : A Base address and length of the register set. | |
| 22 | − | |
| 23 | −- clocks : from common clock binding | |
| 24 | − | |
| 25 | −- clock-output-names : From common clock binding. The block has 16 | |
| 26 | − clock outputs but not all of them in a specific instance | |
| 27 | − have to be used in the SoC. If a clock name is left as | |
| 28 | − an empty string then no clock will be created for the | |
| 29 | − output associated with that string index. If fewer than | |
| 30 | − 16 strings are provided then no clocks will be created | |
| 31 | − for the remaining outputs. | |
| 32 | − | |
| 33 | −Example: | |
| 34 | − | |
| 35 | − clockgen_c_vcc: clockgen-c-vcc@0xfe8308ac { | |
| 36 | − #clock-cells = <1>; | |
| 37 | − compatible = "st,stih416-clkgenc", "st,clkgen-vcc"; | |
| 38 | − reg = <0xfe8308ac 12>; | |
| 39 | − | |
| 40 | − clocks = <&clk_s_vcc_hd>, | |
| 41 | − <&clockgen_c 1>, | |
| 42 | − <&clk_s_tmds_fromphy>, | |
| 43 | − <&clockgen_c 2>; | |
| 44 | − | |
| 45 | − clock-output-names = "clk-s-pix-hdmi", | |
| 46 | − "clk-s-pix-dvo", | |
| 47 | − "clk-s-out-dvo", | |
| 48 | − "clk-s-pix-hd", | |
| 49 | − "clk-s-hddac", | |
| 50 | − "clk-s-denc", | |
| 51 | − "clk-s-sddac", | |
| 52 | − "clk-s-pix-main", | |
| 53 | − "clk-s-pix-aux", | |
| 54 | − "clk-s-stfe-frc-0", | |
| 55 | − "clk-s-ref-mcru", | |
| 56 | − "clk-s-slave-mcru", | |
| 57 | − "clk-s-tmds-hdmi", | |
| 58 | − "clk-s-hdmi-reject-pll", | |
| 59 | − "clk-s-thsens"; | |
| 60 | − }; | |
| 61 | − | |
| @@ -13,14 +13,6 @@ address is common of all subnode. · 12 unmodified lines | ||
| 13 | 13 | ... |
| 14 | 14 | }; |
| 15 | 15 | |
| 16 | − prediv_node { | |
| 17 | − ... | |
| 18 | − }; | |
| 19 | − | |
| 20 | − divmux_node { | |
| 21 | − ... | |
| 22 | − }; | |
| 23 | − | |
| 24 | 16 | quadfs_node { |
| 25 | 17 | ... |
| 26 | 18 | }; |
| @@ -29,10 +21,6 @@ address is common of all subnode. · 2 unmodified lines | ||
| 29 | 21 | ... |
| 30 | 22 | }; |
| 31 | 23 | |
| 32 | − vcc_node { | |
| 33 | − ... | |
| 34 | − }; | |
| 35 | − | |
| 36 | 24 | flexgen_node { |
| 37 | 25 | ... |
| 38 | 26 | }; |
| @@ -43,11 +31,8 @@ This binding uses the common clock binding[1]. · 4 unmodified lines | ||
| 43 | 31 | Each subnode should use the binding described in [2]..[7] |
| 44 | 32 | |
| 45 | 33 | [1] Documentation/devicetree/bindings/clock/clock-bindings.txt |
| 46 | −[2] Documentation/devicetree/bindings/clock/st,clkgen-divmux.txt | |
| 47 | 34 | [3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt |
| 48 | 35 | [4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt |
| 49 | −[5] Documentation/devicetree/bindings/clock/st,clkgen-prediv.txt | |
| 50 | −[6] Documentation/devicetree/bindings/clock/st,vcc.txt | |
| 51 | 36 | [7] Documentation/devicetree/bindings/clock/st,quadfs.txt |
| 52 | 37 | [8] Documentation/devicetree/bindings/clock/st,flexgen.txt |
| 53 | 38 | |
| @@ -57,44 +42,27 @@ Required properties: · 3 unmodified lines | ||
| 57 | 42 | |
| 58 | 43 | Example: |
| 59 | 44 | |
| 60 | − clockgen-a@fee62000 { | |
| 61 | − | |
| 62 | − reg = <0xfee62000 0xb48>; | |
| 45 | + clockgen-a@090ff000 { | |
| 46 | + compatible = "st,clkgen-c32"; | |
| 47 | + reg = <0x90ff000 0x1000>; | |
| 63 | 48 | |
| 64 | 49 | clk_s_a0_pll: clk-s-a0-pll { |
| 65 | 50 | #clock-cells = <1>; |
| 66 | − compatible = "st,clkgena-plls-c65"; | |
| 67 | − | |
| 68 | − clocks = <&clk-sysin>; | |
| 69 | − | |
| 70 | − clock-output-names = "clk-s-a0-pll0-hs", | |
| 71 | − "clk-s-a0-pll0-ls", | |
| 72 | − "clk-s-a0-pll1"; | |
| 73 | − }; | |
| 74 | − | |
| 75 | − clk_s_a0_osc_prediv: clk-s-a0-osc-prediv { | |
| 76 | − #clock-cells = <0>; | |
| 77 | − compatible = "st,clkgena-prediv-c65", | |
| 78 | − "st,clkgena-prediv"; | |
| 51 | + compatible = "st,clkgen-pll0"; | |
| 79 | 52 | |
| 80 | 53 | clocks = <&clk_sysin>; |
| 81 | 54 | |
| 82 | − clock-output-names = "clk-s-a0-osc-prediv"; | |
| 55 | + clock-output-names = "clk-s-a0-pll-ofd-0"; | |
| 83 | 56 | }; |
| 84 | 57 | |
| 85 | − clk_s_a0_hs: clk-s-a0-hs { | |
| 58 | + clk_s_a0_flexgen: clk-s-a0-flexgen { | |
| 59 | + compatible = "st,flexgen"; | |
| 60 | + | |
| 86 | 61 | #clock-cells = <1>; |
| 87 | − compatible = "st,clkgena-divmux-c65-hs", | |
| 88 | − "st,clkgena-divmux"; | |
| 89 | 62 | |
| 90 | − clocks = <&clk-s_a0_osc_prediv>, | |
| 91 | − <&clk-s_a0_pll 0>, /* pll0 hs */ | |
| 92 | − <&clk-s_a0_pll 2>; /* pll1 */ | |
| 63 | + clocks = <&clk_s_a0_pll 0>, | |
| 64 | + <&clk_sysin>; | |
| 93 | 65 | |
| 94 | − clock-output-names = "clk-s-fdma-0", | |
| 95 | − "clk-s-fdma-1", | |
| 96 | − ""; /* clk-s-jit-sense */ | |
| 97 | − /* fourth output unused */ | |
| 66 | + clock-output-names = "clk-ic-lmi0"; | |
| 98 | 67 | }; |
| 99 | 68 | }; |
| 100 | − | |
| @@ -60,6 +60,10 @@ This binding uses the common clock binding[2]. · 59 unmodified lines | ||
| 60 | 60 | Required properties: |
| 61 | 61 | - compatible : shall be: |
| 62 | 62 | "st,flexgen" |
| 63 | + "st,flexgen-audio", "st,flexgen" (enable clock propagation on parent for | |
| 64 | + audio use case) | |
| 65 | + "st,flexgen-video", "st,flexgen" (enable clock propagation on parent | |
| 66 | + and activate synchronous mode) | |
| 63 | 67 | |
| 64 | 68 | - #clock-cells : from common clock binding; shall be set to 1 (multiple clock |
| 65 | 69 | outputs). |
| @@ -11,12 +11,8 @@ This binding uses the common clock binding[1]. · 10 unmodified lines | ||
| 11 | 11 | |
| 12 | 12 | Required properties: |
| 13 | 13 | - compatible : shall be: |
| 14 | − "st,stih416-quadfs216", "st,quadfs" | |
| 15 | − "st,stih416-quadfs432", "st,quadfs" | |
| 16 | − "st,stih416-quadfs660-E", "st,quadfs" | |
| 17 | − "st,stih416-quadfs660-F", "st,quadfs" | |
| 18 | − "st,stih407-quadfs660-C", "st,quadfs" | |
| 19 | − "st,stih407-quadfs660-D", "st,quadfs" | |
| 14 | + "st,quadfs" | |
| 15 | + "st,quadfs-pll" | |
| 20 | 16 | |
| 21 | 17 | |
| 22 | 18 | - #clock-cells : from common clock binding; shall be set to 1. |
| @@ -35,14 +31,15 @@ Required properties: · 12 unmodified lines | ||
| 35 | 31 | |
| 36 | 32 | Example: |
| 37 | 33 | |
| 38 | − clockgen_e: clockgen-e@fd3208bc { | |
| 39 | − #clock-cells = <1>; | |
| 40 | − compatible = "st,stih416-quadfs660-E", "st,quadfs"; | |
| 41 | − reg = <0xfd3208bc 0xB0>; | |
| 42 | − | |
| 43 | − clocks = <&clk_sysin>; | |
| 44 | − clock-output-names = "clk-m-pix-mdtp-0", | |
| 45 | − "clk-m-pix-mdtp-1", | |
| 46 | − "clk-m-pix-mdtp-2", | |
| 47 | − "clk-m-mpelpc"; | |
| 48 | − }; | |
| 34 | + clk_s_c0_quadfs: clk-s-c0-quadfs@9103000 { | |
| 35 | + #clock-cells = <1>; | |
| 36 | + compatible = "st,quadfs-pll"; | |
| 37 | + reg = <0x9103000 0x1000>; | |
| 38 | + | |
| 39 | + clocks = <&clk_sysin>; | |
| 40 | + | |
| 41 | + clock-output-names = "clk-s-c0-fs0-ch0", | |
| 42 | + "clk-s-c0-fs0-ch1", | |
| 43 | + "clk-s-c0-fs0-ch2", | |
| 44 | + "clk-s-c0-fs0-ch3"; | |
| 45 | + }; | |
| @@ -2,7 +2,10 @@ Allwinner Clock Control Unit Binding · 1 unmodified line | ||
| 2 | 2 | ------------------------------------ |
| 3 | 3 | |
| 4 | 4 | Required properties : |
| 5 | −- compatible: must contain one of the following compatible: | |
| 5 | +- compatible: must contain one of the following compatibles: | |
| 6 | + - "allwinner,sun6i-a31-ccu" | |
| 7 | + - "allwinner,sun8i-a23-ccu" | |
| 8 | + - "allwinner,sun8i-a33-ccu" | |
| 6 | 9 | - "allwinner,sun8i-h3-ccu" |
| 7 | 10 | |
| 8 | 11 | - reg: Must contain the registers base address and length |
| @@ -0,0 +1,134 @@ | ||
| 1 | +UniPhier clock controller | |
| 2 | + | |
| 3 | + | |
| 4 | +System clock | |
| 5 | +------------ | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: should be one of the following: | |
| 9 | + "socionext,uniphier-sld3-clock" - for sLD3 SoC. | |
| 10 | + "socionext,uniphier-ld4-clock" - for LD4 SoC. | |
| 11 | + "socionext,uniphier-pro4-clock" - for Pro4 SoC. | |
| 12 | + "socionext,uniphier-sld8-clock" - for sLD8 SoC. | |
| 13 | + "socionext,uniphier-pro5-clock" - for Pro5 SoC. | |
| 14 | + "socionext,uniphier-pxs2-clock" - for PXs2/LD6b SoC. | |
| 15 | + "socionext,uniphier-ld11-clock" - for LD11 SoC. | |
| 16 | + "socionext,uniphier-ld20-clock" - for LD20 SoC. | |
| 17 | +- #clock-cells: should be 1. | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + | |
| 21 | + sysctrl@61840000 { | |
| 22 | + compatible = "socionext,uniphier-sysctrl", | |
| 23 | + "simple-mfd", "syscon"; | |
| 24 | + reg = <0x61840000 0x4000>; | |
| 25 | + | |
| 26 | + clock { | |
| 27 | + compatible = "socionext,uniphier-ld20-clock"; | |
| 28 | + #clock-cells = <1>; | |
| 29 | + }; | |
| 30 | + | |
| 31 | + other nodes ... | |
| 32 | + }; | |
| 33 | + | |
| 34 | +Provided clocks: | |
| 35 | + | |
| 36 | + 8: ST DMAC | |
| 37 | +12: GIO (Giga bit stream I/O) | |
| 38 | +14: USB3 ch0 host | |
| 39 | +15: USB3 ch1 host | |
| 40 | +16: USB3 ch0 PHY0 | |
| 41 | +17: USB3 ch0 PHY1 | |
| 42 | +20: USB3 ch1 PHY0 | |
| 43 | +21: USB3 ch1 PHY1 | |
| 44 | + | |
| 45 | + | |
| 46 | +Media I/O (MIO) clock | |
| 47 | +--------------------- | |
| 48 | + | |
| 49 | +Required properties: | |
| 50 | +- compatible: should be one of the following: | |
| 51 | + "socionext,uniphier-sld3-mio-clock" - for sLD3 SoC. | |
| 52 | + "socionext,uniphier-ld4-mio-clock" - for LD4 SoC. | |
| 53 | + "socionext,uniphier-pro4-mio-clock" - for Pro4 SoC. | |
| 54 | + "socionext,uniphier-sld8-mio-clock" - for sLD8 SoC. | |
| 55 | + "socionext,uniphier-pro5-mio-clock" - for Pro5 SoC. | |
| 56 | + "socionext,uniphier-pxs2-mio-clock" - for PXs2/LD6b SoC. | |
| 57 | + "socionext,uniphier-ld11-mio-clock" - for LD11 SoC. | |
| 58 | + "socionext,uniphier-ld20-mio-clock" - for LD20 SoC. | |
| 59 | +- #clock-cells: should be 1. | |
| 60 | + | |
| 61 | +Example: | |
| 62 | + | |
| 63 | + mioctrl@59810000 { | |
| 64 | + compatible = "socionext,uniphier-mioctrl", | |
| 65 | + "simple-mfd", "syscon"; | |
| 66 | + reg = <0x59810000 0x800>; | |
| 67 | + | |
| 68 | + clock { | |
| 69 | + compatible = "socionext,uniphier-ld20-mio-clock"; | |
| 70 | + #clock-cells = <1>; | |
| 71 | + }; | |
| 72 | + | |
| 73 | + other nodes ... | |
| 74 | + }; | |
| 75 | + | |
| 76 | +Provided clocks: | |
| 77 | + | |
| 78 | + 0: SD ch0 host | |
| 79 | + 1: eMMC host | |
| 80 | + 2: SD ch1 host | |
| 81 | + 7: MIO DMAC | |
| 82 | + 8: USB2 ch0 host | |
| 83 | + 9: USB2 ch1 host | |
| 84 | +10: USB2 ch2 host | |
| 85 | +11: USB2 ch3 host | |
| 86 | +12: USB2 ch0 PHY | |
| 87 | +13: USB2 ch1 PHY | |
| 88 | +14: USB2 ch2 PHY | |
| 89 | +15: USB2 ch3 PHY | |
| 90 | + | |
| 91 | + | |
| 92 | +Peripheral clock | |
| 93 | +---------------- | |
| 94 | + | |
| 95 | +Required properties: | |
| 96 | +- compatible: should be one of the following: | |
| 97 | + "socionext,uniphier-sld3-peri-clock" - for sLD3 SoC. | |
| 98 | + "socionext,uniphier-ld4-peri-clock" - for LD4 SoC. | |
| 99 | + "socionext,uniphier-pro4-peri-clock" - for Pro4 SoC. | |
| 100 | + "socionext,uniphier-sld8-peri-clock" - for sLD8 SoC. | |
| 101 | + "socionext,uniphier-pro5-peri-clock" - for Pro5 SoC. | |
| 102 | + "socionext,uniphier-pxs2-peri-clock" - for PXs2/LD6b SoC. | |
| 103 | + "socionext,uniphier-ld11-peri-clock" - for LD11 SoC. | |
| 104 | + "socionext,uniphier-ld20-peri-clock" - for LD20 SoC. | |
| 105 | +- #clock-cells: should be 1. | |
| 106 | + | |
| 107 | +Example: | |
| 108 | + | |
| 109 | + perictrl@59820000 { | |
| 110 | + compatible = "socionext,uniphier-perictrl", | |
| 111 | + "simple-mfd", "syscon"; | |
| 112 | + reg = <0x59820000 0x200>; | |
| 113 | + | |
| 114 | + clock { | |
| 115 | + compatible = "socionext,uniphier-ld20-peri-clock"; | |
| 116 | + #clock-cells = <1>; | |
| 117 | + }; | |
| 118 | + | |
| 119 | + other nodes ... | |
| 120 | + }; | |
| 121 | + | |
| 122 | +Provided clocks: | |
| 123 | + | |
| 124 | + 0: UART ch0 | |
| 125 | + 1: UART ch1 | |
| 126 | + 2: UART ch2 | |
| 127 | + 3: UART ch3 | |
| 128 | + 4: I2C ch0 | |
| 129 | + 5: I2C ch1 | |
| 130 | + 6: I2C ch2 | |
| 131 | + 7: I2C ch3 | |
| 132 | + 8: I2C ch4 | |
| 133 | + 9: I2C ch5 | |
| 134 | +10: I2C ch6 | |
| @@ -8,6 +8,7 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | - compatible : shall be one of the following: |
| 9 | 9 | "apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock |
| 10 | 10 | "apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock |
| 11 | + "apm,xgene-pmd-clock" - for a X-Gene PMD clock | |
| 11 | 12 | "apm,xgene-device-clock" - for a X-Gene device clock |
| 12 | 13 | "apm,xgene-socpll-v2-clock" - for a X-Gene SoC PLL v2 clock |
| 13 | 14 | "apm,xgene-pcppll-v2-clock" - for a X-Gene PCP PLL v2 clock |
| @@ -22,6 +23,15 @@ Required properties for SoC or PCP PLL clocks: · 8 unmodified lines | ||
| 22 | 23 | Optional properties for PLL clocks: |
| 23 | 24 | - clock-names : shall be the name of the PLL. If missing, use the device name. |
| 24 | 25 | |
| 26 | +Required properties for PMD clocks: | |
| 27 | +- reg : shall be the physical register address for the pmd clock. | |
| 28 | +- clocks : shall be the input parent clock phandle for the clock. | |
| 29 | +- #clock-cells : shall be set to 1. | |
| 30 | +- clock-output-names : shall be the name of the clock referenced by derive | |
| 31 | + clock. | |
| 32 | +Optional properties for PLL clocks: | |
| 33 | +- clock-names : shall be the name of the clock. If missing, use the device name. | |
| 34 | + | |
| 25 | 35 | Required properties for device clocks: |
| 26 | 36 | - reg : shall be a list of address and length pairs describing the CSR |
| 27 | 37 | reset and/or the divider. Either may be omitted, but at least |
| @@ -59,6 +69,14 @@ For example: · 31 unmodified lines | ||
| 59 | 69 | type = <0>; |
| 60 | 70 | }; |
| 61 | 71 | |
| 72 | + pmd0clk: pmd0clk@7e200200 { | |
| 73 | + compatible = "apm,xgene-pmd-clock"; | |
| 74 | + #clock-cells = <1>; | |
| 75 | + clocks = <&pmdpll 0>; | |
| 76 | + reg = <0x0 0x7e200200 0x0 0x10>; | |
| 77 | + clock-output-names = "pmd0clk"; | |
| 78 | + }; | |
| 79 | + | |
| 62 | 80 | socpll: socpll@17000120 { |
| 63 | 81 | compatible = "apm,xgene-socpll-clock"; |
| 64 | 82 | #clock-cells = <1>; |
| @@ -0,0 +1,35 @@ | ||
| 1 | +Device Tree Clock bindings for ZTE zx296718 | |
| 2 | + | |
| 3 | +This binding uses the common clock binding[1]. | |
| 4 | + | |
| 5 | +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : shall be one of the following: | |
| 9 | + "zte,zx296718-topcrm": | |
| 10 | + zx296718 top clock selection, divider and gating | |
| 11 | + | |
| 12 | + "zte,zx296718-lsp0crm" and | |
| 13 | + "zte,zx296718-lsp1crm": | |
| 14 | + zx296718 device level clock selection and gating | |
| 15 | + | |
| 16 | +- reg: Address and length of the register set | |
| 17 | + | |
| 18 | +The clock consumer should specify the desired clock by having the clock | |
| 19 | +ID in its "clocks" phandle cell. See include/dt-bindings/clock/zx296718-clock.h | |
| 20 | +for the full list of zx296718 clock IDs. | |
| 21 | + | |
| 22 | + | |
| 23 | +topclk: topcrm@1461000 { | |
| 24 | + compatible = "zte,zx296718-topcrm-clk"; | |
| 25 | + reg = <0x01461000 0x1000>; | |
| 26 | + #clock-cells = <1>; | |
| 27 | +}; | |
| 28 | + | |
| 29 | +usbphy0:usb-phy0 { | |
| 30 | + compatible = "zte,zx296718-usb-phy"; | |
| 31 | + #phy-cells = <0>; | |
| 32 | + clocks = <&topclk USB20_PHY_CLK>; | |
| 33 | + clock-names = "phyclk"; | |
| 34 | + status = "okay"; | |
| 35 | +}; | |
| @@ -0,0 +1,19 @@ | ||
| 1 | + | |
| 2 | +* Rockchip rk3399 DFI device | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- compatible: Must be "rockchip,rk3399-dfi". | |
| 6 | +- reg: physical base address of each DFI and length of memory mapped region | |
| 7 | +- rockchip,pmu: phandle to the syscon managing the "pmu general register files" | |
| 8 | +- clocks: phandles for clock specified in "clock-names" property | |
| 9 | +- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon"; | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + dfi: dfi@0xff630000 { | |
| 13 | + compatible = "rockchip,rk3399-dfi"; | |
| 14 | + reg = <0x00 0xff630000 0x00 0x4000>; | |
| 15 | + rockchip,pmu = <&pmugrf>; | |
| 16 | + clocks = <&cru PCLK_DDR_MON>; | |
| 17 | + clock-names = "pclk_ddr_mon"; | |
| 18 | + status = "disabled"; | |
| 19 | + }; | |
| @@ -0,0 +1,209 @@ | ||
| 1 | +* Rockchip rk3399 DMC(Dynamic Memory Controller) device | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Must be "rockchip,rk3399-dmc". | |
| 5 | +- devfreq-events: Node to get DDR loading, Refer to | |
| 6 | + Documentation/devicetree/bindings/devfreq/ | |
| 7 | + rockchip-dfi.txt | |
| 8 | +- interrupts: The interrupt number to the CPU. The interrupt | |
| 9 | + specifier format depends on the interrupt controller. | |
| 10 | + It should be DCF interrupts, when DDR dvfs finish, | |
| 11 | + it will happen. | |
| 12 | +- clocks: Phandles for clock specified in "clock-names" property | |
| 13 | +- clock-names : The name of clock used by the DFI, must be | |
| 14 | + "pclk_ddr_mon"; | |
| 15 | +- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt | |
| 16 | + for details. | |
| 17 | +- center-supply: DMC supply node. | |
| 18 | +- status: Marks the node enabled/disabled. | |
| 19 | + | |
| 20 | +Following properties are ddr timing: | |
| 21 | + | |
| 22 | +- rockchip,dram_speed_bin : Value reference include/dt-bindings/clock/ddr.h, | |
| 23 | + it select ddr3 cl-trp-trcd type, default value | |
| 24 | + "DDR3_DEFAULT".it must selected according to | |
| 25 | + "Speed Bin" in ddr3 datasheet, DO NOT use | |
| 26 | + smaller "Speed Bin" than ddr3 exactly is. | |
| 27 | + | |
| 28 | +- rockchip,pd_idle : Config the PD_IDLE value, defined the power-down | |
| 29 | + idle period, memories are places into power-down | |
| 30 | + mode if bus is idle for PD_IDLE DFI clocks. | |
| 31 | + | |
| 32 | +- rockchip,sr_idle : Configure the SR_IDLE value, defined the | |
| 33 | + selfrefresh idle period, memories are places | |
| 34 | + into self-refresh mode if bus is idle for | |
| 35 | + SR_IDLE*1024 DFI clocks (DFI clocks freq is | |
| 36 | + half of dram's clocks), defaule value is "0". | |
| 37 | + | |
| 38 | +- rockchip,sr_mc_gate_idle : Defined the self-refresh with memory and | |
| 39 | + controller clock gating idle period, memories | |
| 40 | + are places into self-refresh mode and memory | |
| 41 | + controller clock arg gating if bus is idle for | |
| 42 | + sr_mc_gate_idle*1024 DFI clocks. | |
| 43 | + | |
| 44 | +- rockchip,srpd_lite_idle : Defined the self-refresh power down idle | |
| 45 | + period, memories are places into self-refresh | |
| 46 | + power down mode if bus is idle for | |
| 47 | + srpd_lite_idle*1024 DFI clocks. This parameter | |
| 48 | + is for LPDDR4 only. | |
| 49 | + | |
| 50 | +- rockchip,standby_idle : Defined the standby idle period, memories are | |
| 51 | + places into self-refresh than controller, pi, | |
| 52 | + phy and dram clock will gating if bus is idle | |
| 53 | + for standby_idle * DFI clocks. | |
| 54 | + | |
| 55 | +- rockchip,dram_dll_disb_freq : It's defined the DDR3 dll bypass frequency in | |
| 56 | + MHz, when ddr freq less than DRAM_DLL_DISB_FREQ, | |
| 57 | + ddr3 dll will bypssed note: if dll was bypassed, | |
| 58 | + the odt also stop working. | |
| 59 | + | |
| 60 | +- rockchip,phy_dll_disb_freq : Defined the PHY dll bypass frequency in | |
| 61 | + MHz (Mega Hz), when ddr freq less than | |
| 62 | + DRAM_DLL_DISB_FREQ, phy dll will bypssed. | |
| 63 | + note: phy dll and phy odt are independent. | |
| 64 | + | |
| 65 | +- rockchip,ddr3_odt_disb_freq : When dram type is DDR3, this parameter defined | |
| 66 | + the odt disable frequency in MHz (Mega Hz), | |
| 67 | + when ddr frequency less then ddr3_odt_disb_freq, | |
| 68 | + the odt on dram side and controller side are | |
| 69 | + both disabled. | |
| 70 | + | |
| 71 | +- rockchip,ddr3_drv : When dram type is DDR3, this parameter define | |
| 72 | + the dram side driver stength in ohm, default | |
| 73 | + value is DDR3_DS_40ohm. | |
| 74 | + | |
| 75 | +- rockchip,ddr3_odt : When dram type is DDR3, this parameter define | |
| 76 | + the dram side ODT stength in ohm, default value | |
| 77 | + is DDR3_ODT_120ohm. | |
| 78 | + | |
| 79 | +- rockchip,phy_ddr3_ca_drv : When dram type is DDR3, this parameter define | |
| 80 | + the phy side CA line(incluing command line, | |
| 81 | + address line and clock line) driver strength. | |
| 82 | + Default value is PHY_DRV_ODT_40. | |
| 83 | + | |
| 84 | +- rockchip,phy_ddr3_dq_drv : When dram type is DDR3, this parameter define | |
| 85 | + the phy side DQ line(incluing DQS/DQ/DM line) | |
| 86 | + driver strength. default value is PHY_DRV_ODT_40. | |
| 87 | + | |
| 88 | +- rockchip,phy_ddr3_odt : When dram type is DDR3, this parameter define the | |
| 89 | + phy side odt strength, default value is | |
| 90 | + PHY_DRV_ODT_240. | |
| 91 | + | |
| 92 | +- rockchip,lpddr3_odt_disb_freq : When dram type is LPDDR3, this parameter defined | |
| 93 | + then odt disable frequency in MHz (Mega Hz), | |
| 94 | + when ddr frequency less then ddr3_odt_disb_freq, | |
| 95 | + the odt on dram side and controller side are | |
| 96 | + both disabled. | |
| 97 | + | |
| 98 | +- rockchip,lpddr3_drv : When dram type is LPDDR3, this parameter define | |
| 99 | + the dram side driver stength in ohm, default | |
| 100 | + value is LP3_DS_34ohm. | |
| 101 | + | |
| 102 | +- rockchip,lpddr3_odt : When dram type is LPDDR3, this parameter define | |
| 103 | + the dram side ODT stength in ohm, default value | |
| 104 | + is LP3_ODT_240ohm. | |
| 105 | + | |
| 106 | +- rockchip,phy_lpddr3_ca_drv : When dram type is LPDDR3, this parameter define | |
| 107 | + the phy side CA line(incluing command line, | |
| 108 | + address line and clock line) driver strength. | |
| 109 | + default value is PHY_DRV_ODT_40. | |
| 110 | + | |
| 111 | +- rockchip,phy_lpddr3_dq_drv : When dram type is LPDDR3, this parameter define | |
| 112 | + the phy side DQ line(incluing DQS/DQ/DM line) | |
| 113 | + driver strength. default value is | |
| 114 | + PHY_DRV_ODT_40. | |
| 115 | + | |
| 116 | +- rockchip,phy_lpddr3_odt : When dram type is LPDDR3, this parameter define | |
| 117 | + the phy side odt strength, default value is | |
| 118 | + PHY_DRV_ODT_240. | |
| 119 | + | |
| 120 | +- rockchip,lpddr4_odt_disb_freq : When dram type is LPDDR4, this parameter | |
| 121 | + defined the odt disable frequency in | |
| 122 | + MHz (Mega Hz), when ddr frequency less then | |
| 123 | + ddr3_odt_disb_freq, the odt on dram side and | |
| 124 | + controller side are both disabled. | |
| 125 | + | |
| 126 | +- rockchip,lpddr4_drv : When dram type is LPDDR4, this parameter define | |
| 127 | + the dram side driver stength in ohm, default | |
| 128 | + value is LP4_PDDS_60ohm. | |
| 129 | + | |
| 130 | +- rockchip,lpddr4_dq_odt : When dram type is LPDDR4, this parameter define | |
| 131 | + the dram side ODT on dqs/dq line stength in ohm, | |
| 132 | + default value is LP4_DQ_ODT_40ohm. | |
| 133 | + | |
| 134 | +- rockchip,lpddr4_ca_odt : When dram type is LPDDR4, this parameter define | |
| 135 | + the dram side ODT on ca line stength in ohm, | |
| 136 | + default value is LP4_CA_ODT_40ohm. | |
| 137 | + | |
| 138 | +- rockchip,phy_lpddr4_ca_drv : When dram type is LPDDR4, this parameter define | |
| 139 | + the phy side CA line(incluing command address | |
| 140 | + line) driver strength. default value is | |
| 141 | + PHY_DRV_ODT_40. | |
| 142 | + | |
| 143 | +- rockchip,phy_lpddr4_ck_cs_drv : When dram type is LPDDR4, this parameter define | |
| 144 | + the phy side clock line and cs line driver | |
| 145 | + strength. default value is PHY_DRV_ODT_80. | |
| 146 | + | |
| 147 | +- rockchip,phy_lpddr4_dq_drv : When dram type is LPDDR4, this parameter define | |
| 148 | + the phy side DQ line(incluing DQS/DQ/DM line) | |
| 149 | + driver strength. default value is PHY_DRV_ODT_80. | |
| 150 | + | |
| 151 | +- rockchip,phy_lpddr4_odt : When dram type is LPDDR4, this parameter define | |
| 152 | + the phy side odt strength, default value is | |
| 153 | + PHY_DRV_ODT_60. | |
| 154 | + | |
| 155 | +Example: | |
| 156 | + dmc_opp_table: dmc_opp_table { | |
| 157 | + compatible = "operating-points-v2"; | |
| 158 | + | |
| 159 | + opp00 { | |
| 160 | + opp-hz = /bits/ 64 <300000000>; | |
| 161 | + opp-microvolt = <900000>; | |
| 162 | + }; | |
| 163 | + opp01 { | |
| 164 | + opp-hz = /bits/ 64 <666000000>; | |
| 165 | + opp-microvolt = <900000>; | |
| 166 | + }; | |
| 167 | + }; | |
| 168 | + | |
| 169 | + dmc: dmc { | |
| 170 | + compatible = "rockchip,rk3399-dmc"; | |
| 171 | + devfreq-events = <&dfi>; | |
| 172 | + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>; | |
| 173 | + clocks = <&cru SCLK_DDRCLK>; | |
| 174 | + clock-names = "dmc_clk"; | |
| 175 | + operating-points-v2 = <&dmc_opp_table>; | |
| 176 | + center-supply = <&ppvar_centerlogic>; | |
| 177 | + upthreshold = <15>; | |
| 178 | + downdifferential = <10>; | |
| 179 | + rockchip,ddr3_speed_bin = <21>; | |
| 180 | + rockchip,pd_idle = <0x40>; | |
| 181 | + rockchip,sr_idle = <0x2>; | |
| 182 | + rockchip,sr_mc_gate_idle = <0x3>; | |
| 183 | + rockchip,srpd_lite_idle = <0x4>; | |
| 184 | + rockchip,standby_idle = <0x2000>; | |
| 185 | + rockchip,dram_dll_dis_freq = <300>; | |
| 186 | + rockchip,phy_dll_dis_freq = <125>; | |
| 187 | + rockchip,auto_pd_dis_freq = <666>; | |
| 188 | + rockchip,ddr3_odt_dis_freq = <333>; | |
| 189 | + rockchip,ddr3_drv = <DDR3_DS_40ohm>; | |
| 190 | + rockchip,ddr3_odt = <DDR3_ODT_120ohm>; | |
| 191 | + rockchip,phy_ddr3_ca_drv = <PHY_DRV_ODT_40>; | |
| 192 | + rockchip,phy_ddr3_dq_drv = <PHY_DRV_ODT_40>; | |
| 193 | + rockchip,phy_ddr3_odt = <PHY_DRV_ODT_240>; | |
| 194 | + rockchip,lpddr3_odt_dis_freq = <333>; | |
| 195 | + rockchip,lpddr3_drv = <LP3_DS_34ohm>; | |
| 196 | + rockchip,lpddr3_odt = <LP3_ODT_240ohm>; | |
| 197 | + rockchip,phy_lpddr3_ca_drv = <PHY_DRV_ODT_40>; | |
| 198 | + rockchip,phy_lpddr3_dq_drv = <PHY_DRV_ODT_40>; | |
| 199 | + rockchip,phy_lpddr3_odt = <PHY_DRV_ODT_240>; | |
| 200 | + rockchip,lpddr4_odt_dis_freq = <333>; | |
| 201 | + rockchip,lpddr4_drv = <LP4_PDDS_60ohm>; | |
| 202 | + rockchip,lpddr4_dq_odt = <LP4_DQ_ODT_40ohm>; | |
| 203 | + rockchip,lpddr4_ca_odt = <LP4_CA_ODT_40ohm>; | |
| 204 | + rockchip,phy_lpddr4_ca_drv = <PHY_DRV_ODT_40>; | |
| 205 | + rockchip,phy_lpddr4_ck_cs_drv = <PHY_DRV_ODT_80>; | |
| 206 | + rockchip,phy_lpddr4_dq_drv = <PHY_DRV_ODT_80>; | |
| 207 | + rockchip,phy_lpddr4_odt = <PHY_DRV_ODT_60>; | |
| 208 | + status = "disabled"; | |
| 209 | + }; | |
| @@ -0,0 +1,48 @@ | ||
| 1 | +Dumb RGB to VGA DAC bridge | |
| 2 | +--------------------------- | |
| 3 | + | |
| 4 | +This binding is aimed for dumb RGB to VGA DAC based bridges that do not require | |
| 5 | +any configuration. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | + | |
| 9 | +- compatible: Must be "dumb-vga-dac" | |
| 10 | + | |
| 11 | +Required nodes: | |
| 12 | + | |
| 13 | +This device has two video ports. Their connections are modelled using the OF | |
| 14 | +graph bindings specified in Documentation/devicetree/bindings/graph.txt. | |
| 15 | + | |
| 16 | +- Video port 0 for RGB input | |
| 17 | +- Video port 1 for VGA output | |
| 18 | + | |
| 19 | + | |
| 20 | +Example | |
| 21 | +------- | |
| 22 | + | |
| 23 | +bridge { | |
| 24 | + compatible = "dumb-vga-dac"; | |
| 25 | + #address-cells = <1>; | |
| 26 | + #size-cells = <0>; | |
| 27 | + | |
| 28 | + ports { | |
| 29 | + #address-cells = <1>; | |
| 30 | + #size-cells = <0>; | |
| 31 | + | |
| 32 | + port@0 { | |
| 33 | + reg = <0>; | |
| 34 | + | |
| 35 | + vga_bridge_in: endpoint { | |
| 36 | + remote-endpoint = <&tcon0_out_vga>; | |
| 37 | + }; | |
| 38 | + }; | |
| 39 | + | |
| 40 | + port@1 { | |
| 41 | + reg = <1>; | |
| 42 | + | |
| 43 | + vga_bridge_out: endpoint { | |
| 44 | + remote-endpoint = <&vga_con_in>; | |
| 45 | + }; | |
| 46 | + }; | |
| 47 | + }; | |
| 48 | +}; | |
| @@ -21,8 +21,19 @@ Optional properties: · 20 unmodified lines | ||
| 21 | 21 | - video-ports: 24 bits value which defines how the video controller |
| 22 | 22 | output is wired to the TDA998x input - default: <0x230145> |
| 23 | 23 | |
| 24 | + - audio-ports: array of 8-bit values, 2 values per one DAI[1]. | |
| 25 | + The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S[2]. | |
| 26 | + The second value defines the tda998x AP_ENA reg content when the DAI | |
| 27 | + in question is used. The implementation allows one or two DAIs. If two | |
| 28 | + DAIs are defined, they must be of different type. | |
| 29 | + | |
| 30 | +[1] Documentation/sound/alsa/soc/DAI.txt | |
| 31 | +[2] include/dt-bindings/display/tda998x.h | |
| 32 | + | |
| 24 | 33 | Example: |
| 25 | 34 | |
| 35 | +#include <dt-bindings/display/tda998x.h> | |
| 36 | + | |
| 26 | 37 | tda998x: hdmi-encoder { |
| 27 | 38 | compatible = "nxp,tda998x"; |
| 28 | 39 | reg = <0x70>; |
| @@ -30,4 +41,11 @@ Example: · 1 unmodified line | ||
| 30 | 41 | interrupts = <27 2>; /* falling edge */ |
| 31 | 42 | pinctrl-0 = <&pmx_camera>; |
| 32 | 43 | pinctrl-names = "default"; |
| 44 | + video-ports = <0x230145>; | |
| 45 | + | |
| 46 | + #sound-dai-cells = <2>; | |
| 47 | + /* DAI-format AP_ENA reg value */ | |
| 48 | + audio-ports = < TDA998x_SPDIF 0x04 | |
| 49 | + TDA998x_I2S 0x03>; | |
| 50 | + | |
| 33 | 51 | }; |
| @@ -9,7 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | - reg: physical base address of the hdmi and length of memory mapped |
| 10 | 10 | region. |
| 11 | 11 | - interrupts: interrupt number to the cpu. |
| 12 | −- hpd-gpio: following information about the hotplug gpio pin. | |
| 12 | +- hpd-gpios: following information about the hotplug gpio pin. | |
| 13 | 13 | a) phandle of the gpio controller node. |
| 14 | 14 | b) pin number within the gpio controller. |
| 15 | 15 | c) optional flags and pull up/down. |
| @@ -56,7 +56,7 @@ Example: · 40 unmodified lines | ||
| 56 | 56 | compatible = "samsung,exynos4212-hdmi"; |
| 57 | 57 | reg = <0x14530000 0x100000>; |
| 58 | 58 | interrupts = <0 95 0>; |
| 59 | − hpd-gpio = <&gpx3 7 1>; | |
| 59 | + hpd-gpios = <&gpx3 7 1>; | |
| 60 | 60 | ddc = <&hdmi_ddc_node>; |
| 61 | 61 | phy = <&hdmi_phy_node>; |
| 62 | 62 | samsung,syscon-phandle = <&pmu_system_controller>; |
| @@ -14,17 +14,16 @@ Required properties: · 13 unmodified lines | ||
| 14 | 14 | - power-domains: Should be <&mmcc MDSS_GDSC>. |
| 15 | 15 | - clocks: device clocks |
| 16 | 16 | See ../clocks/clock-bindings.txt for details. |
| 17 | −- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin | |
| 18 | −- qcom,hdmi-tx-ddc-data-gpio: ddc data pin | |
| 19 | −- qcom,hdmi-tx-hpd-gpio: hpd pin | |
| 20 | 17 | - core-vdda-supply: phandle to supply regulator |
| 21 | 18 | - hdmi-mux-supply: phandle to mux regulator |
| 22 | 19 | - phys: the phandle for the HDMI PHY device |
| 23 | 20 | - phy-names: the name of the corresponding PHY device |
| 24 | 21 | |
| 25 | 22 | Optional properties: |
| 26 | −- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin | |
| 27 | −- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin | |
| 23 | +- hpd-gpios: hpd pin | |
| 24 | +- qcom,hdmi-tx-mux-en-gpios: hdmi mux enable pin | |
| 25 | +- qcom,hdmi-tx-mux-sel-gpios: hdmi mux select pin | |
| 26 | +- qcom,hdmi-tx-mux-lpm-gpios: hdmi mux lpm pin | |
| 28 | 27 | - power-domains: reference to the power domain(s), if available. |
| 29 | 28 | - pinctrl-names: the pin control state names; should contain "default" |
| 30 | 29 | - pinctrl-0: the default pinctrl state (active) |
| @@ -0,0 +1,7 @@ | ||
| 1 | +Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "innolux,g101ice-l01" | |
| 5 | + | |
| 6 | +This binding is compatible with the simple-panel binding, which is specified | |
| 7 | +in simple-panel.txt in this directory. | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +JDI model LT070ME05000 1200x1920 7" DSI Panel | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "jdi,lt070me05000" | |
| 5 | +- vddp-supply: phandle of the regulator that provides the supply voltage | |
| 6 | + Power IC supply (3-5V) | |
| 7 | +- iovcc-supply: phandle of the regulator that provides the supply voltage | |
| 8 | + IOVCC , power supply for LCM (1.8V) | |
| 9 | +- enable-gpios: phandle of gpio for enable line | |
| 10 | + LED_EN, LED backlight enable, High active | |
| 11 | +- reset-gpios: phandle of gpio for reset line | |
| 12 | + This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names | |
| 13 | + XRES, Reset, Low active | |
| 14 | +- dcdc-en-gpios: phandle of the gpio for power ic line | |
| 15 | + Power IC supply enable, High active | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + dsi0: qcom,mdss_dsi@4700000 { | |
| 20 | + panel@0 { | |
| 21 | + compatible = "jdi,lt070me05000"; | |
| 22 | + reg = <0>; | |
| 23 | + | |
| 24 | + vddp-supply = <&pm8921_l17>; | |
| 25 | + iovcc-supply = <&pm8921_lvs7>; | |
| 26 | + | |
| 27 | + enable-gpios = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>; | |
| 28 | + reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>; | |
| 29 | + dcdc-en-gpios = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>; | |
| 30 | + }; | |
| 31 | + }; | |
| @@ -0,0 +1,47 @@ | ||
| 1 | +TPO TPG110 Panel | |
| 2 | +================ | |
| 3 | + | |
| 4 | +This binding builds on the DPI bindings, adding a few properties | |
| 5 | +as a superset of a DPI. See panel-dpi.txt for the required DPI | |
| 6 | +bindings. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible : "tpo,tpg110" | |
| 10 | +- grestb-gpios : panel reset GPIO | |
| 11 | +- scen-gpios : serial control enable GPIO | |
| 12 | +- scl-gpios : serial control clock line GPIO | |
| 13 | +- sda-gpios : serial control data line GPIO | |
| 14 | + | |
| 15 | +Required nodes: | |
| 16 | +- Video port for DPI input, see panel-dpi.txt | |
| 17 | +- Panel timing for DPI setup, see panel-dpi.txt | |
| 18 | + | |
| 19 | +Example | |
| 20 | +------- | |
| 21 | + | |
| 22 | +panel { | |
| 23 | + compatible = "tpo,tpg110", "panel-dpi"; | |
| 24 | + grestb-gpios = <&stmpe_gpio44 5 GPIO_ACTIVE_LOW>; | |
| 25 | + scen-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>; | |
| 26 | + scl-gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>; | |
| 27 | + sda-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>; | |
| 28 | + backlight = <&bl>; | |
| 29 | + | |
| 30 | + port { | |
| 31 | + nomadik_clcd_panel: endpoint { | |
| 32 | + remote-endpoint = <&nomadik_clcd_pads>; | |
| 33 | + }; | |
| 34 | + }; | |
| 35 | + | |
| 36 | + panel-timing { | |
| 37 | + clock-frequency = <33200000>; | |
| 38 | + hactive = <800>; | |
| 39 | + hback-porch = <216>; | |
| 40 | + hfront-porch = <40>; | |
| 41 | + hsync-len = <1>; | |
| 42 | + vactive = <480>; | |
| 43 | + vback-porch = <35>; | |
| 44 | + vfront-porch = <10>; | |
| 45 | + vsync-len = <1>; | |
| 46 | + }; | |
| 47 | +}; | |
| @@ -6,8 +6,10 @@ buffer to an external LCD interface. · 5 unmodified lines | ||
| 6 | 6 | |
| 7 | 7 | Required properties: |
| 8 | 8 | - compatible: value should be one of the following |
| 9 | − "rockchip,rk3288-vop"; | |
| 10 | 9 | "rockchip,rk3036-vop"; |
| 10 | + "rockchip,rk3288-vop"; | |
| 11 | + "rockchip,rk3399-vop-big"; | |
| 12 | + "rockchip,rk3399-vop-lit"; | |
| 11 | 13 | |
| 12 | 14 | - interrupts: should contain a list of all VOP IP block interrupts in the |
| 13 | 15 | order: VSYNC, LCD_SYSTEM. The interrupt specifier |
| @@ -26,13 +26,14 @@ TCON · 25 unmodified lines | ||
| 26 | 26 | The TCON acts as a timing controller for RGB, LVDS and TV interfaces. |
| 27 | 27 | |
| 28 | 28 | Required properties: |
| 29 | − - compatible: value should be "allwinner,sun5i-a13-tcon". | |
| 29 | + - compatible: value must be either: | |
| 30 | + * allwinner,sun5i-a13-tcon | |
| 31 | + * allwinner,sun8i-a33-tcon | |
| 30 | 32 | - reg: base address and size of memory-mapped region |
| 31 | 33 | - interrupts: interrupt associated to this IP |
| 32 | 34 | - clocks: phandles to the clocks feeding the TCON. Three are needed: |
| 33 | 35 | - 'ahb': the interface clocks |
| 34 | 36 | - 'tcon-ch0': The clock driving the TCON channel 0 |
| 35 | − - 'tcon-ch1': The clock driving the TCON channel 1 | |
| 36 | 37 | - resets: phandles to the reset controllers driving the encoder |
| 37 | 38 | - "lcd": the reset line for the TCON channel 0 |
| 38 | 39 | |
| @@ -49,6 +50,33 @@ Required properties: · 10 unmodified lines | ||
| 49 | 50 | second the block connected to the TCON channel 1 (usually the TV |
| 50 | 51 | encoder) |
| 51 | 52 | |
| 53 | +On the A13, there is one more clock required: | |
| 54 | + - 'tcon-ch1': The clock driving the TCON channel 1 | |
| 55 | + | |
| 56 | +DRC | |
| 57 | +--- | |
| 58 | + | |
| 59 | +The DRC (Dynamic Range Controller), found in the latest Allwinner SoCs | |
| 60 | +(A31, A23, A33), allows to dynamically adjust pixel | |
| 61 | +brightness/contrast based on histogram measurements for LCD content | |
| 62 | +adaptive backlight control. | |
| 63 | + | |
| 64 | + | |
| 65 | +Required properties: | |
| 66 | + - compatible: value must be one of: | |
| 67 | + * allwinner,sun8i-a33-drc | |
| 68 | + - reg: base address and size of the memory-mapped region. | |
| 69 | + - interrupts: interrupt associated to this IP | |
| 70 | + - clocks: phandles to the clocks feeding the DRC | |
| 71 | + * ahb: the DRC interface clock | |
| 72 | + * mod: the DRC module clock | |
| 73 | + * ram: the DRC DRAM clock | |
| 74 | + - clock-names: the clock names mentioned above | |
| 75 | + - resets: phandles to the reset line driving the DRC | |
| 76 | + | |
| 77 | +- ports: A ports node with endpoint definitions as defined in | |
| 78 | + Documentation/devicetree/bindings/media/video-interfaces.txt. The | |
| 79 | + first port should be the input endpoints, the second one the outputs | |
| 52 | 80 | |
| 53 | 81 | Display Engine Backend |
| 54 | 82 | ---------------------- |
| @@ -59,6 +87,7 @@ system. · 4 unmodified lines | ||
| 59 | 87 | Required properties: |
| 60 | 88 | - compatible: value must be one of: |
| 61 | 89 | * allwinner,sun5i-a13-display-backend |
| 90 | + * allwinner,sun8i-a33-display-backend | |
| 62 | 91 | - reg: base address and size of the memory-mapped region. |
| 63 | 92 | - clocks: phandles to the clocks feeding the frontend and backend |
| 64 | 93 | * ahb: the backend interface clock |
| @@ -71,6 +100,14 @@ Required properties: · 6 unmodified lines | ||
| 71 | 100 | Documentation/devicetree/bindings/media/video-interfaces.txt. The |
| 72 | 101 | first port should be the input endpoints, the second one the output |
| 73 | 102 | |
| 103 | +On the A33, some additional properties are required: | |
| 104 | + - reg needs to have an additional region corresponding to the SAT | |
| 105 | + - reg-names need to be set, with "be" and "sat" | |
| 106 | + - clocks and clock-names need to have a phandle to the SAT bus | |
| 107 | + clocks, whose name will be "sat" | |
| 108 | + - resets and reset-names need to have a phandle to the SAT bus | |
| 109 | + resets, whose name will be "sat" | |
| 110 | + | |
| 74 | 111 | Display Engine Frontend |
| 75 | 112 | ----------------------- |
| 76 | 113 | |
| @@ -80,6 +117,7 @@ deinterlacing and color space conversion. · 3 unmodified lines | ||
| 80 | 117 | Required properties: |
| 81 | 118 | - compatible: value must be one of: |
| 82 | 119 | * allwinner,sun5i-a13-display-frontend |
| 120 | + * allwinner,sun8i-a33-display-frontend | |
| 83 | 121 | - reg: base address and size of the memory-mapped region. |
| 84 | 122 | - interrupts: interrupt associated to this IP |
| 85 | 123 | - clocks: phandles to the clocks feeding the frontend and backend |
| @@ -104,6 +142,7 @@ extra node. · 18 unmodified lines | ||
| 104 | 142 | Required properties: |
| 105 | 143 | - compatible: value must be one of: |
| 106 | 144 | * allwinner,sun5i-a13-display-engine |
| 145 | + * allwinner,sun8i-a33-display-engine | |
| 107 | 146 | |
| 108 | 147 | - allwinner,pipelines: list of phandle to the display engine |
| 109 | 148 | frontends available. |
| @@ -17,6 +17,18 @@ Optional properties: · 16 unmodified lines | ||
| 17 | 17 | the lcd controller. |
| 18 | 18 | - max-pixelclock: The maximum pixel clock that can be supported |
| 19 | 19 | by the lcd controller in KHz. |
| 20 | + - blue-and-red-wiring: Recognized values "straight" or "crossed". | |
| 21 | + This property deals with the LCDC revision 2 (found on AM335x) | |
| 22 | + color errata [1]. | |
| 23 | + - "straight" indicates normal wiring that supports RGB565, | |
| 24 | + BGR888, and XBGR8888 color formats. | |
| 25 | + - "crossed" indicates wiring that has blue and red wires | |
| 26 | + crossed. This setup supports BGR565, RGB888 and XRGB8888 | |
| 27 | + formats. | |
| 28 | + - If the property is not present or its value is not recognized | |
| 29 | + the legacy mode is assumed. This configuration supports RGB565, | |
| 30 | + RGB888 and XRGB8888 formats. However, depending on wiring, the red | |
| 31 | + and blue colors are swapped in either 16 or 24-bit color modes. | |
| 20 | 32 | |
| 21 | 33 | Optional nodes: |
| 22 | 34 | |
| @@ -24,6 +36,18 @@ Optional nodes: · 1 unmodified line | ||
| 24 | 36 | binding follows Documentation/devicetree/bindings/graph.txt and |
| 25 | 37 | suppors a single port with a single endpoint. |
| 26 | 38 | |
| 39 | + - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and | |
| 40 | + Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting | |
| 41 | + tfp410 DVI encoder or lcd panel to lcdc | |
| 42 | + | |
| 43 | +[1] There is an errata about AM335x color wiring. For 16-bit color mode | |
| 44 | + the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]), | |
| 45 | + but for 24 bit color modes the wiring of blue and red components is | |
| 46 | + crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is | |
| 47 | + for Blue[3-7]. For more details see section 3.1.1 in AM335x | |
| 48 | + Silicon Errata: | |
| 49 | + http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 | |
| 50 | + | |
| 27 | 51 | Example: |
| 28 | 52 | |
| 29 | 53 | fb: fb@4830e000 { |
| @@ -33,6 +57,8 @@ Example: · 3 unmodified lines | ||
| 33 | 57 | interrupts = <36>; |
| 34 | 58 | ti,hwmods = "lcdc"; |
| 35 | 59 | |
| 60 | + blue-and-red-wiring = "crossed"; | |
| 61 | + | |
| 36 | 62 | port { |
| 37 | 63 | lcdc_0: endpoint@0 { |
| 38 | 64 | remote-endpoint = <&hdmi_0>; |
| @@ -8,6 +8,7 @@ Required properties: · 7 unmodified lines | ||
| 8 | 8 | "fsl,imx51-sdma" |
| 9 | 9 | "fsl,imx53-sdma" |
| 10 | 10 | "fsl,imx6q-sdma" |
| 11 | + "fsl,imx7d-sdma" | |
| 11 | 12 | The -to variants should be preferred since they allow to determine the |
| 12 | 13 | correct ROM script addresses needed for the driver to work without additional |
| 13 | 14 | firmware. |
| @@ -1,4 +1,4 @@ | ||
| 1 | −* Renesas R-Car DMA Controller Device Tree bindings | |
| 1 | +* Renesas R-Car (RZ/G) DMA Controller Device Tree bindings | |
| 2 | 2 | |
| 3 | 3 | Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA |
| 4 | 4 | controller instances named DMAC capable of serving multiple clients. Channels |
| @@ -16,6 +16,8 @@ Required Properties: · 11 unmodified lines | ||
| 16 | 16 | |
| 17 | 17 | - compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback. |
| 18 | 18 | Examples with soctypes are: |
| 19 | + - "renesas,dmac-r8a7743" (RZ/G1M) | |
| 20 | + - "renesas,dmac-r8a7745" (RZ/G1E) | |
| 19 | 21 | - "renesas,dmac-r8a7790" (R-Car H2) |
| 20 | 22 | - "renesas,dmac-r8a7791" (R-Car M2-W) |
| 21 | 23 | - "renesas,dmac-r8a7792" (R-Car V2H) |
| @@ -7,6 +7,7 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - compatible: Must be one of |
| 8 | 8 | "allwinner,sun6i-a31-dma" |
| 9 | 9 | "allwinner,sun8i-a23-dma" |
| 10 | + "allwinner,sun8i-a83t-dma" | |
| 10 | 11 | "allwinner,sun8i-h3-dma" |
| 11 | 12 | - reg: Should contain the registers base address and length |
| 12 | 13 | - interrupts: Should contain a reference to the interrupt used by this device |
| @@ -0,0 +1,41 @@ | ||
| 1 | +Qualcomm's PM8941 USB ID Extcon device | |
| 2 | + | |
| 3 | +Some Qualcomm PMICs have a "misc" module that can be used to detect when | |
| 4 | +the USB ID pin has been pulled low or high. | |
| 5 | + | |
| 6 | +PROPERTIES | |
| 7 | + | |
| 8 | +- compatible: | |
| 9 | + Usage: required | |
| 10 | + Value type: <string> | |
| 11 | + Definition: Should contain "qcom,pm8941-misc"; | |
| 12 | + | |
| 13 | +- reg: | |
| 14 | + Usage: required | |
| 15 | + Value type: <u32> | |
| 16 | + Definition: Should contain the offset to the misc address space | |
| 17 | + | |
| 18 | +- interrupts: | |
| 19 | + Usage: required | |
| 20 | + Value type: <prop-encoded-array> | |
| 21 | + Definition: Should contain the usb id interrupt | |
| 22 | + | |
| 23 | +- interrupt-names: | |
| 24 | + Usage: required | |
| 25 | + Value type: <stringlist> | |
| 26 | + Definition: Should contain the string "usb_id" for the usb id interrupt | |
| 27 | + | |
| 28 | +Example: | |
| 29 | + | |
| 30 | + pmic { | |
| 31 | + usb_id: misc@900 { | |
| 32 | + compatible = "qcom,pm8941-misc"; | |
| 33 | + reg = <0x900>; | |
| 34 | + interrupts = <0x0 0x9 0 IRQ_TYPE_EDGE_BOTH>; | |
| 35 | + interrupt-names = "usb_id"; | |
| 36 | + }; | |
| 37 | + } | |
| 38 | + | |
| 39 | + usb-controller { | |
| 40 | + extcon = <&usb_id>; | |
| 41 | + }; | |
| @@ -0,0 +1,15 @@ | ||
| 1 | +* Amlogic Secure Monitor | |
| 2 | + | |
| 3 | +In the Amlogic SoCs the Secure Monitor code is used to provide access to the | |
| 4 | +NVMEM, enable JTAG, set USB boot, etc... | |
| 5 | + | |
| 6 | +Required properties for the secure monitor node: | |
| 7 | +- compatible: Should be "amlogic,meson-gxbb-sm" | |
| 8 | + | |
| 9 | +Example: | |
| 10 | + | |
| 11 | + firmware { | |
| 12 | + sm: secure-monitor { | |
| 13 | + compatible = "amlogic,meson-gxbb-sm"; | |
| 14 | + }; | |
| 15 | + }; | |
| @@ -0,0 +1,46 @@ | ||
| 1 | +Bindings for the Broadcom's brcm,bcm6345-gpio memory-mapped GPIO controllers. | |
| 2 | + | |
| 3 | +These bindings can be used on any BCM63xx SoC. However, BCM6338 and BCM6345 | |
| 4 | +are the only ones which don't need a pinctrl driver. | |
| 5 | +BCM6338 have 8-bit data and dirout registers, where GPIO state can be read | |
| 6 | +and/or written, and the direction changed from input to output. | |
| 7 | +BCM6345 have 16-bit data and dirout registers, where GPIO state can be read | |
| 8 | +and/or written, and the direction changed from input to output. | |
| 9 | + | |
| 10 | +Required properties: | |
| 11 | + - compatible: should be "brcm,bcm6345-gpio" | |
| 12 | + - reg-names: must contain | |
| 13 | + "dat" - data register | |
| 14 | + "dirout" - direction (output) register | |
| 15 | + - reg: address + size pairs describing the GPIO register sets; | |
| 16 | + order must correspond with the order of entries in reg-names | |
| 17 | + - #gpio-cells: must be set to 2. The first cell is the pin number and | |
| 18 | + the second cell is used to specify the gpio polarity: | |
| 19 | + 0 = active high | |
| 20 | + 1 = active low | |
| 21 | + - gpio-controller: Marks the device node as a gpio controller. | |
| 22 | + | |
| 23 | +Optional properties: | |
| 24 | + - native-endian: use native endian memory. | |
| 25 | + | |
| 26 | +Examples: | |
| 27 | + - BCM6338: | |
| 28 | + gpio: gpio-controller@fffe0407 { | |
| 29 | + compatible = "brcm,bcm6345-gpio"; | |
| 30 | + reg-names = "dirout", "dat"; | |
| 31 | + reg = <0xfffe0407 1>, <0xfffe040f 1>; | |
| 32 | + | |
| 33 | + #gpio-cells = <2>; | |
| 34 | + gpio-controller; | |
| 35 | + }; | |
| 36 | + | |
| 37 | + - BCM6345: | |
| 38 | + gpio: gpio-controller@fffe0406 { | |
| 39 | + compatible = "brcm,bcm6345-gpio"; | |
| 40 | + reg-names = "dirout", "dat"; | |
| 41 | + reg = <0xfffe0406 2>, <0xfffe040a 2>; | |
| 42 | + native-endian; | |
| 43 | + | |
| 44 | + #gpio-cells = <2>; | |
| 45 | + gpio-controller; | |
| 46 | + }; | |
| @@ -0,0 +1,36 @@ | ||
| 1 | +Aspeed GPIO controller Device Tree Bindings | |
| 2 | +------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio" | |
| 6 | + | |
| 7 | +- #gpio-cells : Should be two | |
| 8 | + - First cell is the GPIO line number | |
| 9 | + - Second cell is used to specify optional | |
| 10 | + parameters (unused) | |
| 11 | + | |
| 12 | +- reg : Address and length of the register set for the device | |
| 13 | +- gpio-controller : Marks the device node as a GPIO controller. | |
| 14 | +- interrupts : Interrupt specifier (see interrupt bindings for | |
| 15 | + details) | |
| 16 | +- interrupt-controller : Mark the GPIO controller as an interrupt-controller | |
| 17 | + | |
| 18 | +Optional properties: | |
| 19 | + | |
| 20 | +- interrupt-parent : The parent interrupt controller, optional if inherited | |
| 21 | + | |
| 22 | +The gpio and interrupt properties are further described in their respective | |
| 23 | +bindings documentation: | |
| 24 | + | |
| 25 | +- Documentation/devicetree/bindings/gpio/gpio.txt | |
| 26 | +- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt | |
| 27 | + | |
| 28 | + Example: | |
| 29 | + gpio@1e780000 { | |
| 30 | + #gpio-cells = <2>; | |
| 31 | + compatible = "aspeed,ast2400-gpio"; | |
| 32 | + gpio-controller; | |
| 33 | + interrupts = <20>; | |
| 34 | + reg = <0x1e780000 0x1000>; | |
| 35 | + interrupt-controller; | |
| 36 | + }; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +AXP209 GPIO controller | |
| 2 | + | |
| 3 | +This driver follows the usual GPIO bindings found in | |
| 4 | +Documentation/devicetree/bindings/gpio/gpio.txt | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible: Should be "x-powers,axp209-gpio" | |
| 8 | +- #gpio-cells: Should be two. The first cell is the pin number and the | |
| 9 | + second is the GPIO flags. | |
| 10 | +- gpio-controller: Marks the device node as a GPIO controller. | |
| 11 | + | |
| 12 | +This node must be a subnode of the axp20x PMIC, documented in | |
| 13 | +Documentation/devicetree/bindings/mfd/axp20x.txt | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | +axp209: pmic@34 { | |
| 18 | + compatible = "x-powers,axp209"; | |
| 19 | + reg = <0x34>; | |
| 20 | + interrupt-parent = <&nmi_intc>; | |
| 21 | + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; | |
| 22 | + interrupt-controller; | |
| 23 | + #interrupt-cells = <1>; | |
| 24 | + | |
| 25 | + axp_gpio: gpio { | |
| 26 | + compatible = "x-powers,axp209-gpio"; | |
| 27 | + gpio-controller; | |
| 28 | + #gpio-cells = <2>; | |
| 29 | + }; | |
| 30 | +}; | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +TPIC2810 GPIO controller bindings | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : Should be "ti,tpic2810". | |
| 5 | + - reg : The I2C address of the device | |
| 6 | + - gpio-controller : Marks the device node as a GPIO controller. | |
| 7 | + - #gpio-cells : Should be two. For consumer use see gpio.txt. | |
| 8 | + | |
| 9 | +Example: | |
| 10 | + | |
| 11 | + gpio@60 { | |
| 12 | + compatible = "ti,tpic2810"; | |
| 13 | + reg = <0x60>; | |
| 14 | + gpio-controller; | |
| 15 | + #gpio-cells = <2>; | |
| 16 | + }; | |
| @@ -1,16 +0,0 @@ | ||
| 1 | −* TPS65086 GPO Controller bindings | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | − - compatible : Should be "ti,tps65086-gpio". | |
| 5 | − - gpio-controller : Marks the device node as a GPIO Controller. | |
| 6 | − - #gpio-cells : Should be two. The first cell is the pin number | |
| 7 | − and the second cell is used to specify flags. | |
| 8 | − See ../gpio/gpio.txt for possible values. | |
| 9 | − | |
| 10 | −Example: | |
| 11 | − | |
| 12 | − gpio4: gpio { | |
| 13 | − compatible = "ti,tps65086-gpio"; | |
| 14 | − gpio-controller; | |
| 15 | − #gpio-cells = <2>; | |
| 16 | − }; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +* Technologic Systems I2C-FPGA's GPIO controller bindings | |
| 2 | + | |
| 3 | +This bindings describes the GPIO controller for Technologic's FPGA core. | |
| 4 | +TS-4900's FPGA encodes the GPIO state on 3 bits, whereas the TS-7970's FPGA | |
| 5 | +uses 2 bits: it doesn't use a dedicated input bit. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: Should be one of the following | |
| 9 | + "technologic,ts4900-gpio" | |
| 10 | + "technologic,ts7970-gpio" | |
| 11 | +- reg: Physical base address of the controller and length | |
| 12 | + of memory mapped region. | |
| 13 | +- #gpio-cells: Should be two. The first cell is the pin number. | |
| 14 | +- gpio-controller: Marks the device node as a gpio controller. | |
| 15 | + | |
| 16 | +Optional property: | |
| 17 | +- ngpios: Number of GPIOs this controller is instantiated with, | |
| 18 | + the default is 32. See gpio.txt for more details. | |
| 19 | + | |
| 20 | +Example: | |
| 21 | + | |
| 22 | +&i2c2 { | |
| 23 | + gpio8: gpio@28 { | |
| 24 | + compatible = "technologic,ts4900-gpio"; | |
| 25 | + reg = <0x28>; | |
| 26 | + #gpio-cells = <2>; | |
| 27 | + gpio-controller; | |
| 28 | + ngpios = <32>; | |
| 29 | + }; | |
| 30 | +}; | |
| @@ -44,26 +44,3 @@ Example for a PXA3xx platform: · 43 unmodified lines | ||
| 44 | 44 | interrupt-controller; |
| 45 | 45 | #interrupt-cells = <0x2>; |
| 46 | 46 | }; |
| 47 | − | |
| 48 | −* Marvell Orion GPIO Controller | |
| 49 | − | |
| 50 | −Required properties: | |
| 51 | −- compatible : Should be "marvell,orion-gpio" | |
| 52 | −- reg : Address and length of the register set for controller. | |
| 53 | −- gpio-controller : So we know this is a gpio controller. | |
| 54 | −- ngpio : How many gpios this controller has. | |
| 55 | −- interrupts : Up to 4 Interrupts for the controller. | |
| 56 | − | |
| 57 | −Optional properties: | |
| 58 | −- mask-offset : For SMP Orions, offset for Nth CPU | |
| 59 | − | |
| 60 | −Example: | |
| 61 | − | |
| 62 | − gpio0: gpio@10100 { | |
| 63 | − compatible = "marvell,orion-gpio"; | |
| 64 | − #gpio-cells = <2>; | |
| 65 | − gpio-controller; | |
| 66 | − reg = <0x10100 0x40>; | |
| 67 | − ngpio = <32>; | |
| 68 | − interrupts = <35>, <36>, <37>, <38>; | |
| 69 | − }; | |
| @@ -11,6 +11,7 @@ Required Properties: · 10 unmodified lines | ||
| 11 | 11 | - "renesas,gpio-r8a7793": for R8A7793 (R-Car M2-N) compatible GPIO controller. |
| 12 | 12 | - "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller. |
| 13 | 13 | - "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller. |
| 14 | + - "renesas,gpio-r8a7796": for R8A7796 (R-Car M3-W) compatible GPIO controller. | |
| 14 | 15 | - "renesas,gpio-rcar": for generic R-Car GPIO controller. |
| 15 | 16 | |
| 16 | 17 | - reg: Base address and length of each memory resource used by the GPIO |
| @@ -0,0 +1,18 @@ | ||
| 1 | +LTC4151 High Voltage I2C Current and Voltage Monitor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Must be "lltc,ltc4151" | |
| 5 | +- reg: I2C address | |
| 6 | + | |
| 7 | +Optional properties: | |
| 8 | +- shunt-resistor-micro-ohms | |
| 9 | + Shunt resistor value in micro-Ohms | |
| 10 | + Defaults to <1000> if unset. | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +ltc4151@6e { | |
| 15 | + compatible = "lltc,ltc4151"; | |
| 16 | + reg = <0x6e>; | |
| 17 | + shunt-resistor-micro-ohms = <1500>; | |
| 18 | +}; | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +Bindings for MAX6651 and MAX6650 I2C fan controllers | |
| 2 | + | |
| 3 | +Reference: | |
| 4 | +[1] https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | +- compatible : One of "maxim,max6650" or "maxim,max6651" | |
| 8 | +- reg : I2C address, one of 0x1b, 0x1f, 0x4b, 0x48. | |
| 9 | + | |
| 10 | +Optional properties, default is to retain the chip's current setting: | |
| 11 | +- maxim,fan-microvolt : The supply voltage of the fan, either 5000000 uV or | |
| 12 | + 12000000 uV. | |
| 13 | +- maxim,fan-prescale : Pre-scaling value, as per datasheet [1]. Lower values | |
| 14 | + allow more fine-grained control of slower fans. | |
| 15 | + Valid: 1, 2, 4, 8, 16. | |
| 16 | +- maxim,fan-target-rpm: Initial requested fan rotation speed. If specified, the | |
| 17 | + driver selects closed-loop mode and the requested speed. | |
| 18 | + This ensures the fan is already running before userspace | |
| 19 | + takes over. | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + fan-max6650: max6650@1b { | |
| 23 | + reg = <0x1b>; | |
| 24 | + compatible = "maxim,max6650"; | |
| 25 | + maxim,fan-microvolt = <12000000>; | |
| 26 | + maxim,fan-prescale = <4>; | |
| 27 | + maxim,fan-target-rpm = <1200>; | |
| 28 | + }; | |
| @@ -44,8 +44,7 @@ Required properties: · 43 unmodified lines | ||
| 44 | 44 | - our-claim-gpio: The GPIO that we use to claim the bus. |
| 45 | 45 | - their-claim-gpios: The GPIOs that the other sides use to claim the bus. |
| 46 | 46 | Note that some implementations may only support a single other master. |
| 47 | −- Standard I2C mux properties. See i2c-mux.txt in this directory. | |
| 48 | −- Single I2C child bus node at reg 0. See i2c-mux.txt in this directory. | |
| 47 | +- I2C arbitration bus node. See i2c-arb.txt in this directory. | |
| 49 | 48 | |
| 50 | 49 | Optional properties: |
| 51 | 50 | - slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us. |
| @@ -63,8 +62,6 @@ Example: · 11 unmodified lines | ||
| 63 | 62 | |
| 64 | 63 | i2c-arbitrator { |
| 65 | 64 | compatible = "i2c-arb-gpio-challenge"; |
| 66 | − #address-cells = <1>; | |
| 67 | − #size-cells = <0>; | |
| 68 | 65 | |
| 69 | 66 | i2c-parent = <&{/i2c@12CA0000}>; |
| 70 | 67 | |
| @@ -74,8 +71,7 @@ Example: · 3 unmodified lines | ||
| 74 | 71 | wait-retry-us = <3000>; |
| 75 | 72 | wait-free-us = <50000>; |
| 76 | 73 | |
| 77 | − i2c@0 { | |
| 78 | − reg = <0>; | |
| 74 | + i2c-arb { | |
| 79 | 75 | #address-cells = <1>; |
| 80 | 76 | #size-cells = <0>; |
| 81 | 77 | |
| @@ -0,0 +1,35 @@ | ||
| 1 | +Common i2c arbitration bus properties. | |
| 2 | + | |
| 3 | +- i2c-arb child node | |
| 4 | + | |
| 5 | +Required properties for the i2c-arb child node: | |
| 6 | +- #address-cells = <1>; | |
| 7 | +- #size-cells = <0>; | |
| 8 | + | |
| 9 | +Optional properties for i2c-arb child node: | |
| 10 | +- Child nodes conforming to i2c bus binding | |
| 11 | + | |
| 12 | + | |
| 13 | +Example : | |
| 14 | + | |
| 15 | + /* | |
| 16 | + An NXP pca9541 I2C bus master selector at address 0x74 | |
| 17 | + with a NXP pca8574 GPIO expander attached. | |
| 18 | + */ | |
| 19 | + | |
| 20 | + arb@74 { | |
| 21 | + compatible = "nxp,pca9541"; | |
| 22 | + reg = <0x74>; | |
| 23 | + | |
| 24 | + i2c-arb { | |
| 25 | + #address-cells = <1>; | |
| 26 | + #size-cells = <0>; | |
| 27 | + | |
| 28 | + gpio@38 { | |
| 29 | + compatible = "nxp,pca8574"; | |
| 30 | + reg = <0x38>; | |
| 31 | + #gpio-cells = <2>; | |
| 32 | + gpio-controller; | |
| 33 | + }; | |
| 34 | + }; | |
| 35 | + }; | |
| @@ -0,0 +1,41 @@ | ||
| 1 | +An i2c gate is useful to e.g. reduce the digital noise for RF tuners connected | |
| 2 | +to the i2c bus. Gates are similar to arbitrators in that you need to perform | |
| 3 | +some kind of operation to access the i2c bus past the arbitrator/gate, but | |
| 4 | +there are no competing masters to consider for gates and therefore there is | |
| 5 | +no arbitration happening for gates. | |
| 6 | + | |
| 7 | +Common i2c gate properties. | |
| 8 | + | |
| 9 | +- i2c-gate child node | |
| 10 | + | |
| 11 | +Required properties for the i2c-gate child node: | |
| 12 | +- #address-cells = <1>; | |
| 13 | +- #size-cells = <0>; | |
| 14 | + | |
| 15 | +Optional properties for i2c-gate child node: | |
| 16 | +- Child nodes conforming to i2c bus binding | |
| 17 | + | |
| 18 | + | |
| 19 | +Example : | |
| 20 | + | |
| 21 | + /* | |
| 22 | + An Invensense mpu9150 at address 0x68 featuring an on-chip Asahi | |
| 23 | + Kasei ak8975 compass behind a gate. | |
| 24 | + */ | |
| 25 | + | |
| 26 | + mpu9150@68 { | |
| 27 | + compatible = "invensense,mpu9150"; | |
| 28 | + reg = <0x68>; | |
| 29 | + interrupt-parent = <&gpio1>; | |
| 30 | + interrupts = <18 1>; | |
| 31 | + | |
| 32 | + i2c-gate { | |
| 33 | + #address-cells = <1>; | |
| 34 | + #size-cells = <0>; | |
| 35 | + | |
| 36 | + ax8975@c { | |
| 37 | + compatible = "ak,ak8975"; | |
| 38 | + reg = <0x0c>; | |
| 39 | + }; | |
| 40 | + }; | |
| 41 | + }; | |
| @@ -1,7 +1,7 @@ | ||
| 1 | 1 | Amlogic Meson I2C controller |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | − - compatible: must be "amlogic,meson6-i2c" | |
| 4 | + - compatible: must be "amlogic,meson6-i2c" or "amlogic,meson-gxbb-i2c" | |
| 5 | 5 | - reg: physical address and length of the device registers |
| 6 | 6 | - interrupts: a single interrupt specifier |
| 7 | 7 | - clocks: clock for the device |
| @@ -2,19 +2,32 @@ Common i2c bus multiplexer/switch properties. · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | An i2c bus multiplexer/switch will have several child busses that are |
| 4 | 4 | numbered uniquely in a device dependent manner. The nodes for an i2c bus |
| 5 | −multiplexer/switch will have one child node for each child | |
| 6 | −bus. | |
| 5 | +multiplexer/switch will have one child node for each child bus. | |
| 7 | 6 | |
| 8 | −Required properties: | |
| 7 | +Optional properties: | |
| 8 | +- #address-cells = <1>; | |
| 9 | + This property is required is the i2c-mux child node does not exist. | |
| 10 | + | |
| 11 | +- #size-cells = <0>; | |
| 12 | + This property is required is the i2c-mux child node does not exist. | |
| 13 | + | |
| 14 | +- i2c-mux | |
| 15 | + For i2c multiplexers/switches that have child nodes that are a mixture | |
| 16 | + of both i2c child busses and other child nodes, the 'i2c-mux' subnode | |
| 17 | + can be used for populating the i2c child busses. If an 'i2c-mux' | |
| 18 | + subnode is present, only subnodes of this will be considered as i2c | |
| 19 | + child busses. | |
| 20 | + | |
| 21 | +Required properties for the i2c-mux child node: | |
| 9 | 22 | - #address-cells = <1>; |
| 10 | 23 | - #size-cells = <0>; |
| 11 | 24 | |
| 12 | −Required properties for child nodes: | |
| 25 | +Required properties for i2c child bus nodes: | |
| 13 | 26 | - #address-cells = <1>; |
| 14 | 27 | - #size-cells = <0>; |
| 15 | 28 | - reg : The sub-bus number. |
| 16 | 29 | |
| 17 | −Optional properties for child nodes: | |
| 30 | +Optional properties for i2c child bus nodes: | |
| 18 | 31 | - Other properties specific to the multiplexer/switch hardware. |
| 19 | 32 | - Child nodes conforming to i2c bus binding |
| 20 | 33 | |
| @@ -11,6 +11,7 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | "renesas,i2c-r8a7793" |
| 12 | 12 | "renesas,i2c-r8a7794" |
| 13 | 13 | "renesas,i2c-r8a7795" |
| 14 | + "renesas,i2c-r8a7796" | |
| 14 | 15 | - reg: physical base address of the controller and length of memory mapped |
| 15 | 16 | region. |
| 16 | 17 | - interrupts: interrupt specifier. |
| @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below. · 31 unmodified lines | ||
| 32 | 32 | - clock-frequency |
| 33 | 33 | frequency of bus clock in Hz. |
| 34 | 34 | |
| 35 | +- i2c-bus | |
| 36 | + For I2C adapters that have child nodes that are a mixture of both I2C | |
| 37 | + devices and non-I2C devices, the 'i2c-bus' subnode can be used for | |
| 38 | + populating I2C devices. If the 'i2c-bus' subnode is present, only | |
| 39 | + subnodes of this will be considered as I2C slaves. The properties, | |
| 40 | + '#address-cells' and '#size-cells' must be defined under this subnode | |
| 41 | + if present. | |
| 42 | + | |
| 35 | 43 | - i2c-scl-falling-time-ns |
| 36 | 44 | Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C |
| 37 | 45 | specification. |
| @@ -0,0 +1,29 @@ | ||
| 1 | +* NXP PCA9541 I2C bus master selector | |
| 2 | + | |
| 3 | +Required Properties: | |
| 4 | + | |
| 5 | + - compatible: Must be "nxp,pca9541" | |
| 6 | + | |
| 7 | + - reg: The I2C address of the device. | |
| 8 | + | |
| 9 | + The following required properties are defined externally: | |
| 10 | + | |
| 11 | + - I2C arbitration bus node. See i2c-arb.txt in this directory. | |
| 12 | + | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | + i2c-arbitrator@74 { | |
| 17 | + compatible = "nxp,pca9541"; | |
| 18 | + reg = <0x74>; | |
| 19 | + | |
| 20 | + i2c-arb { | |
| 21 | + #address-cells = <1>; | |
| 22 | + #size-cells = <0>; | |
| 23 | + | |
| 24 | + eeprom@54 { | |
| 25 | + compatible = "at,24c08"; | |
| 26 | + reg = <0x54>; | |
| 27 | + }; | |
| 28 | + }; | |
| 29 | + }; | |
| @@ -38,6 +38,7 @@ dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O · 37 unmodified lines | ||
| 38 | 38 | dallas,ds75 Digital Thermometer and Thermostat |
| 39 | 39 | dlg,da9053 DA9053: flexible system level PMIC with multicore support |
| 40 | 40 | dlg,da9063 DA9063: system PMIC for quad-core application processors |
| 41 | +domintech,dmard09 DMARD09: 3-axis Accelerometer | |
| 41 | 42 | epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE |
| 42 | 43 | epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE |
| 43 | 44 | epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE |
| @@ -50,12 +51,12 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec · 6 unmodified lines | ||
| 50 | 51 | gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface |
| 51 | 52 | infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) |
| 52 | 53 | infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) |
| 53 | −isil,isl12057 Intersil ISL12057 I2C RTC Chip | |
| 54 | 54 | isil,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor |
| 55 | 55 | maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator |
| 56 | 56 | maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs |
| 57 | 57 | maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface |
| 58 | 58 | mc,rv3029c2 Real Time Clock Module with I2C-Bus |
| 59 | +mcube,mc3230 mCube 3-axis 8-bit digital accelerometer | |
| 59 | 60 | microchip,mcp4531-502 Microchip 7-bit Single I2C Digital Potentiometer (5k) |
| 60 | 61 | microchip,mcp4531-103 Microchip 7-bit Single I2C Digital Potentiometer (10k) |
| 61 | 62 | microchip,mcp4531-503 Microchip 7-bit Single I2C Digital Potentiometer (50k) |
| @@ -0,0 +1,19 @@ | ||
| 1 | +Device tree bindings for Domintech DMARD05, DMARD06, DMARD07 accelerometers | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : Should be "domintech,dmard05" | |
| 5 | + or "domintech,dmard06" | |
| 6 | + or "domintech,dmard07" | |
| 7 | + - reg : I2C address of the chip. Should be 0x1c | |
| 8 | + | |
| 9 | +Example: | |
| 10 | + &i2c1 { | |
| 11 | + /* ... */ | |
| 12 | + | |
| 13 | + accelerometer@1c { | |
| 14 | + compatible = "domintech,dmard06"; | |
| 15 | + reg = <0x1c>; | |
| 16 | + }; | |
| 17 | + | |
| 18 | + /* ... */ | |
| 19 | + }; | |
| @@ -0,0 +1,22 @@ | ||
| 1 | +Kionix KXSD9 Accelerometer device tree bindings | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: should be set to "kionix,kxsd9" | |
| 5 | + - reg: i2c slave address | |
| 6 | + | |
| 7 | +Optional properties: | |
| 8 | + - vdd-supply: The input supply for VDD | |
| 9 | + - iovdd-supply: The input supply for IOVDD | |
| 10 | + - interrupts: The movement detection interrupt | |
| 11 | + - mount-matrix: See mount-matrix.txt | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | +kxsd9@18 { | |
| 16 | + compatible = "kionix,kxsd9"; | |
| 17 | + reg = <0x18>; | |
| 18 | + interrupt-parent = <&foo>; | |
| 19 | + interrupts = <57 IRQ_TYPE_EDGE_FALLING>; | |
| 20 | + iovdd-supply = <&bar>; | |
| 21 | + vdd-supply = <&baz>; | |
| 22 | +}; | |
| @@ -0,0 +1,29 @@ | ||
| 1 | +* Mediatek AUXADC - Analog to Digital Converter on Mediatek mobile soc (mt65xx/mt81xx/mt27xx) | |
| 2 | +=============== | |
| 3 | + | |
| 4 | +The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found | |
| 5 | +in some Mediatek SoCs which among other things measures the temperatures | |
| 6 | +in the SoC. It can be used directly with register accesses, but it is also | |
| 7 | +used by thermal controller which reads the temperatures from the AUXADC | |
| 8 | +directly via its own bus interface. See | |
| 9 | +Documentation/devicetree/bindings/thermal/mediatek-thermal.txt | |
| 10 | +for the Thermal Controller which holds a phandle to the AUXADC. | |
| 11 | + | |
| 12 | +Required properties: | |
| 13 | + - compatible: Should be one of: | |
| 14 | + - "mediatek,mt2701-auxadc": For MT2701 family of SoCs | |
| 15 | + - "mediatek,mt8173-auxadc": For MT8173 family of SoCs | |
| 16 | + - reg: Address range of the AUXADC unit. | |
| 17 | + - clocks: Should contain a clock specifier for each entry in clock-names | |
| 18 | + - clock-names: Should contain "main". | |
| 19 | + - #io-channel-cells: Should be 1, see ../iio-bindings.txt | |
| 20 | + | |
| 21 | +Example: | |
| 22 | + | |
| 23 | +auxadc: adc@11001000 { | |
| 24 | + compatible = "mediatek,mt2701-auxadc"; | |
| 25 | + reg = <0 0x11001000 0 0x1000>; | |
| 26 | + clocks = <&pericfg CLK_PERI_AUXADC>; | |
| 27 | + clock-names = "main"; | |
| 28 | + #io-channel-cells = <1>; | |
| 29 | +}; | |
| @@ -0,0 +1,37 @@ | ||
| 1 | +* Texas Instruments' ADC12130/ADC12132/ADC12138 | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be one of | |
| 5 | + * "ti,adc12130" | |
| 6 | + * "ti,adc12132" | |
| 7 | + * "ti,adc12138" | |
| 8 | + - reg: SPI chip select number for the device | |
| 9 | + - interrupts: Should contain interrupt for EOC (end of conversion) | |
| 10 | + - clocks: phandle to conversion clock input | |
| 11 | + - spi-max-frequency: Definision as per | |
| 12 | + Documentation/devicetree/bindings/spi/spi-bus.txt | |
| 13 | + - vref-p-supply: The regulator supply for positive analog voltage reference | |
| 14 | + | |
| 15 | +Optional properties: | |
| 16 | + - vref-n-supply: The regulator supply for negative analog voltage reference | |
| 17 | + (Note that this must not go below GND or exceed vref-p) | |
| 18 | + If not specified, this is assumed to be analog ground. | |
| 19 | + - ti,acquisition-time: The number of conversion clock periods for the S/H's | |
| 20 | + acquisition time. Should be one of 6, 10, 18, 34. If not specified, | |
| 21 | + default value of 10 is used. | |
| 22 | + For high source impedances, this value can be increased to 18 or 34. | |
| 23 | + For less ADC accuracy and/or slower CCLK frequencies this value may be | |
| 24 | + decreased to 6. See section 6.0 INPUT SOURCE RESISTANCE in the | |
| 25 | + datasheet for details. | |
| 26 | + | |
| 27 | +Example: | |
| 28 | +adc@0 { | |
| 29 | + compatible = "ti,adc12138"; | |
| 30 | + reg = <0>; | |
| 31 | + interrupts = <28 IRQ_TYPE_EDGE_RISING>; | |
| 32 | + interrupt-parent = <&gpio1>; | |
| 33 | + clocks = <&cclk>; | |
| 34 | + vref-p-supply = <&ldo4_reg>; | |
| 35 | + spi-max-frequency = <5000000>; | |
| 36 | + ti,acquisition-time = <6>; | |
| 37 | +}; | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +* Texas Instruments ADC141S626 and ADC161S626 chips | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: Should be "ti,adc141s626" or "ti,adc161s626" | |
| 5 | + - reg: spi chip select number for the device | |
| 6 | + | |
| 7 | +Recommended properties: | |
| 8 | + - spi-max-frequency: Definition as per | |
| 9 | + Documentation/devicetree/bindings/spi/spi-bus.txt | |
| 10 | + | |
| 11 | +Example: | |
| 12 | +adc@0 { | |
| 13 | + compatible = "ti,adc161s626"; | |
| 14 | + reg = <0>; | |
| 15 | + spi-max-frequency = <4300000>; | |
| 16 | +}; | |
| @@ -0,0 +1,22 @@ | ||
| 1 | +* Atlas Scientific ORP-SM OEM sensor | |
| 2 | + | |
| 3 | +https://www.atlas-scientific.com/_files/_datasheets/_oem/ORP_oem_datasheet.pdf | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | + - compatible: must be "atlas,orp-sm" | |
| 8 | + - reg: the I2C address of the sensor | |
| 9 | + - interrupt-parent: should be the phandle for the interrupt controller | |
| 10 | + - interrupts: the sole interrupt generated by the device | |
| 11 | + | |
| 12 | + Refer to interrupt-controller/interrupts.txt for generic interrupt client | |
| 13 | + node bindings. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | +atlas@66 { | |
| 18 | + compatible = "atlas,orp-sm"; | |
| 19 | + reg = <0x66>; | |
| 20 | + interrupt-parent = <&gpio1>; | |
| 21 | + interrupts = <16 2>; | |
| 22 | +}; | |
| @@ -0,0 +1,29 @@ | ||
| 1 | +* Asahi Kasei AK8974 magnetometer sensor | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible : should be "asahi-kasei,ak8974" | |
| 6 | +- reg : the I2C address of the magnetometer | |
| 7 | + | |
| 8 | +Optional properties: | |
| 9 | + | |
| 10 | +- avdd-supply: regulator supply for the analog voltage | |
| 11 | + (see regulator/regulator.txt) | |
| 12 | +- dvdd-supply: regulator supply for the digital voltage | |
| 13 | + (see regulator/regulator.txt) | |
| 14 | +- interrupts: data ready (DRDY) and interrupt (INT1) lines | |
| 15 | + from the chip, the DRDY interrupt must be placed first. | |
| 16 | + The interrupts can be triggered on rising or falling | |
| 17 | + edges alike. | |
| 18 | +- mount-matrix: an optional 3x3 mounting rotation matrix | |
| 19 | + | |
| 20 | +Example: | |
| 21 | + | |
| 22 | +ak8974@0f { | |
| 23 | + compatible = "asahi-kasei,ak8974"; | |
| 24 | + reg = <0x0f>; | |
| 25 | + avdd-supply = <&foo_reg>; | |
| 26 | + dvdd-supply = <&bar_reg>; | |
| 27 | + interrupts = <0 IRQ_TYPE_EDGE_RISING>, | |
| 28 | + <1 IRQ_TYPE_EDGE_RISING>; | |
| 29 | +}; | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +Murata ZPA2326 pressure sensor | |
| 2 | + | |
| 3 | +Pressure sensor from Murata with SPI and I2C bus interfaces. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | +- compatible: "murata,zpa2326" | |
| 7 | +- reg: the I2C address or SPI chip select the device will respond to | |
| 8 | + | |
| 9 | +Recommended properties for SPI bus usage: | |
| 10 | +- spi-max-frequency: maximum SPI bus frequency as documented in | |
| 11 | + Documentation/devicetree/bindings/spi/spi-bus.txt | |
| 12 | + | |
| 13 | +Optional properties: | |
| 14 | +- vref-supply: an optional regulator that needs to be on to provide VREF | |
| 15 | + power to the sensor | |
| 16 | +- vdd-supply: an optional regulator that needs to be on to provide VDD | |
| 17 | + power to the sensor | |
| 18 | +- interrupt-parent: phandle to the parent interrupt controller as documented in | |
| 19 | + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt | |
| 20 | +- interrupts: interrupt mapping for IRQ as documented in | |
| 21 | + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + | |
| 25 | +zpa2326@5c { | |
| 26 | + compatible = "murata,zpa2326"; | |
| 27 | + reg = <0x5c>; | |
| 28 | + interrupt-parent = <&gpio>; | |
| 29 | + interrupts = <12>; | |
| 30 | + vdd-supply = <&ldo_1v8_gnss>; | |
| 31 | +}; | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +Semtech's SX9500 capacitive proximity button device driver | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: must be "semtech,sx9500" | |
| 5 | + - reg: i2c address where to find the device | |
| 6 | + - interrupt-parent : should be the phandle for the interrupt controller | |
| 7 | + - interrupts : the sole interrupt generated by the device | |
| 8 | + | |
| 9 | + Refer to interrupt-controller/interrupts.txt for generic | |
| 10 | + interrupt client node bindings. | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | + - reset-gpios: Reference to the GPIO connected to the device's active | |
| 14 | + low reset pin. | |
| 15 | + | |
| 16 | +Example: | |
| 17 | + | |
| 18 | +sx9500@28 { | |
| 19 | + compatible = "semtech,sx9500"; | |
| 20 | + reg = <0x28>; | |
| 21 | + interrupt-parent = <&gpio2>; | |
| 22 | + interrupts = <16 IRQ_TYPE_LEVEL_LOW>; | |
| 23 | + reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>; | |
| 24 | +}; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +Maxim thermocouple support | |
| 2 | + | |
| 3 | +* https://datasheets.maximintegrated.com/en/ds/MAX6675.pdf | |
| 4 | +* https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf | |
| 5 | + | |
| 6 | +Required properties: | |
| 7 | + | |
| 8 | + - compatible: must be "maxim,max31855" or "maxim,max6675" | |
| 9 | + - reg: SPI chip select number for the device | |
| 10 | + - spi-max-frequency: must be 4300000 | |
| 11 | + - spi-cpha: must be defined for max6675 to enable SPI mode 1 | |
| 12 | + | |
| 13 | + Refer to spi/spi-bus.txt for generic SPI slave bindings. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | + max31855@0 { | |
| 18 | + compatible = "maxim,max31855"; | |
| 19 | + reg = <0>; | |
| 20 | + spi-max-frequency = <4300000>; | |
| 21 | + }; | |
| @@ -0,0 +1,109 @@ | ||
| 1 | +Hisilicon RoCE DT description | |
| 2 | + | |
| 3 | +Hisilicon RoCE engine is a part of network subsystem. | |
| 4 | +It works depending on other part of network wubsytem, such as, gmac and | |
| 5 | +dsa fabric. | |
| 6 | + | |
| 7 | +Additional properties are described here: | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +- compatible: Should contain "hisilicon,hns-roce-v1". | |
| 11 | +- reg: Physical base address of the RoCE driver and | |
| 12 | +length of memory mapped region. | |
| 13 | +- eth-handle: phandle, specifies a reference to a node | |
| 14 | +representing a ethernet device. | |
| 15 | +- dsaf-handle: phandle, specifies a reference to a node | |
| 16 | +representing a dsaf device. | |
| 17 | +- node_guid: a number that uniquely identifies a device or component | |
| 18 | +- #address-cells: must be 2 | |
| 19 | +- #size-cells: must be 2 | |
| 20 | +Optional properties: | |
| 21 | +- dma-coherent: Present if DMA operations are coherent. | |
| 22 | +- interrupt-parent: the interrupt parent of this device. | |
| 23 | +- interrupts: should contain 32 completion event irq,1 async event irq | |
| 24 | +and 1 event overflow irq. | |
| 25 | +- interrupt-names:should be one of 34 irqs for roce device | |
| 26 | + - hns-roce-comp-0 ~ hns-roce-comp-31: 32 complete event irq | |
| 27 | + - hns-roce-async: 1 async event irq | |
| 28 | + - hns-roce-common: named common exception warning irq | |
| 29 | +Example: | |
| 30 | + infiniband@c4000000 { | |
| 31 | + compatible = "hisilicon,hns-roce-v1"; | |
| 32 | + reg = <0x0 0xc4000000 0x0 0x100000>; | |
| 33 | + dma-coherent; | |
| 34 | + eth-handle = <ð2 ð3 ð4 ð5 ð6 ð7>; | |
| 35 | + dsaf-handle = <&soc0_dsa>; | |
| 36 | + node-guid = [00 9A CD 00 00 01 02 03]; | |
| 37 | + #address-cells = <2>; | |
| 38 | + #size-cells = <2>; | |
| 39 | + interrupt-parent = <&mbigen_dsa>; | |
| 40 | + interrupts = <722 1>, | |
| 41 | + <723 1>, | |
| 42 | + <724 1>, | |
| 43 | + <725 1>, | |
| 44 | + <726 1>, | |
| 45 | + <727 1>, | |
| 46 | + <728 1>, | |
| 47 | + <729 1>, | |
| 48 | + <730 1>, | |
| 49 | + <731 1>, | |
| 50 | + <732 1>, | |
| 51 | + <733 1>, | |
| 52 | + <734 1>, | |
| 53 | + <735 1>, | |
| 54 | + <736 1>, | |
| 55 | + <737 1>, | |
| 56 | + <738 1>, | |
| 57 | + <739 1>, | |
| 58 | + <740 1>, | |
| 59 | + <741 1>, | |
| 60 | + <742 1>, | |
| 61 | + <743 1>, | |
| 62 | + <744 1>, | |
| 63 | + <745 1>, | |
| 64 | + <746 1>, | |
| 65 | + <747 1>, | |
| 66 | + <748 1>, | |
| 67 | + <749 1>, | |
| 68 | + <750 1>, | |
| 69 | + <751 1>, | |
| 70 | + <752 1>, | |
| 71 | + <753 1>, | |
| 72 | + <785 1>, | |
| 73 | + <754 4>; | |
| 74 | + | |
| 75 | + interrupt-names = "hns-roce-comp-0", | |
| 76 | + "hns-roce-comp-1", | |
| 77 | + "hns-roce-comp-2", | |
| 78 | + "hns-roce-comp-3", | |
| 79 | + "hns-roce-comp-4", | |
| 80 | + "hns-roce-comp-5", | |
| 81 | + "hns-roce-comp-6", | |
| 82 | + "hns-roce-comp-7", | |
| 83 | + "hns-roce-comp-8", | |
| 84 | + "hns-roce-comp-9", | |
| 85 | + "hns-roce-comp-10", | |
| 86 | + "hns-roce-comp-11", | |
| 87 | + "hns-roce-comp-12", | |
| 88 | + "hns-roce-comp-13", | |
| 89 | + "hns-roce-comp-14", | |
| 90 | + "hns-roce-comp-15", | |
| 91 | + "hns-roce-comp-16", | |
| 92 | + "hns-roce-comp-17", | |
| 93 | + "hns-roce-comp-18", | |
| 94 | + "hns-roce-comp-19", | |
| 95 | + "hns-roce-comp-20", | |
| 96 | + "hns-roce-comp-21", | |
| 97 | + "hns-roce-comp-22", | |
| 98 | + "hns-roce-comp-23", | |
| 99 | + "hns-roce-comp-24", | |
| 100 | + "hns-roce-comp-25", | |
| 101 | + "hns-roce-comp-26", | |
| 102 | + "hns-roce-comp-27", | |
| 103 | + "hns-roce-comp-28", | |
| 104 | + "hns-roce-comp-29", | |
| 105 | + "hns-roce-comp-30", | |
| 106 | + "hns-roce-comp-31", | |
| 107 | + "hns-roce-async", | |
| 108 | + "hns-roce-common"; | |
| 109 | + }; | |
| @@ -0,0 +1,49 @@ | ||
| 1 | +ADC attached resistor ladder buttons | |
| 2 | +------------------------------------ | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + - compatible: "adc-keys" | |
| 6 | + - io-channels: Phandle to an ADC channel | |
| 7 | + - io-channel-names = "buttons"; | |
| 8 | + - keyup-threshold-microvolt: Voltage at which all the keys are considered up. | |
| 9 | + | |
| 10 | +Optional properties: | |
| 11 | + - poll-interval: Poll interval time in milliseconds | |
| 12 | + - autorepeat: Boolean, Enable auto repeat feature of Linux input | |
| 13 | + subsystem. | |
| 14 | + | |
| 15 | +Each button (key) is represented as a sub-node of "adc-keys": | |
| 16 | + | |
| 17 | +Required subnode-properties: | |
| 18 | + - label: Descriptive name of the key. | |
| 19 | + - linux,code: Keycode to emit. | |
| 20 | + - press-threshold-microvolt: Voltage ADC input when this key is pressed. | |
| 21 | + | |
| 22 | +Example: | |
| 23 | + | |
| 24 | +#include <dt-bindings/input/input.h> | |
| 25 | + | |
| 26 | + adc-keys { | |
| 27 | + compatible = "adc-keys"; | |
| 28 | + io-channels = <&lradc 0>; | |
| 29 | + io-channel-names = "buttons"; | |
| 30 | + keyup-threshold-microvolt = <2000000>; | |
| 31 | + | |
| 32 | + button-up { | |
| 33 | + label = "Volume Up"; | |
| 34 | + linux,code = <KEY_VOLUMEUP>; | |
| 35 | + press-threshold-microvolt = <1500000>; | |
| 36 | + }; | |
| 37 | + | |
| 38 | + button-down { | |
| 39 | + label = "Volume Down"; | |
| 40 | + linux,code = <KEY_VOLUMEDOWN>; | |
| 41 | + press-threshold-microvolt = <1000000>; | |
| 42 | + }; | |
| 43 | + | |
| 44 | + button-enter { | |
| 45 | + label = "Enter"; | |
| 46 | + linux,code = <KEY_ENTER>; | |
| 47 | + press-threshold-microvolt = <500000>; | |
| 48 | + }; | |
| 49 | + }; | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +* GPIO Decoder DT bindings | |
| 2 | + | |
| 3 | +Required Properties: | |
| 4 | +- compatible: should be "gpio-decoder" | |
| 5 | +- gpios: a spec of gpios (at least two) to be decoded to a number with | |
| 6 | + first entry representing the MSB. | |
| 7 | + | |
| 8 | +Optional Properties: | |
| 9 | +- decoder-max-value: Maximum possible value that can be reported by | |
| 10 | + the gpios. | |
| 11 | +- linux,axis: the input subsystem axis to map to (ABS_X/ABS_Y). | |
| 12 | + Defaults to 0 (ABS_X). | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + gpio-decoder0 { | |
| 16 | + compatible = "gpio-decoder"; | |
| 17 | + gpios = <&pca9536 3 GPIO_ACTIVE_HIGH>, | |
| 18 | + <&pca9536 2 GPIO_ACTIVE_HIGH>, | |
| 19 | + <&pca9536 1 GPIO_ACTIVE_HIGH>, | |
| 20 | + <&pca9536 0 GPIO_ACTIVE_HIGH>; | |
| 21 | + linux,axis = <0>; /* ABS_X */ | |
| 22 | + decoder-max-value = <9>; | |
| 23 | + }; | |
| @@ -34,11 +34,10 @@ Example nodes: · 33 unmodified lines | ||
| 34 | 34 | |
| 35 | 35 | gpio_keys_polled { |
| 36 | 36 | compatible = "gpio-keys-polled"; |
| 37 | − #address-cells = <1>; | |
| 38 | − #size-cells = <0>; | |
| 39 | 37 | poll-interval = <100>; |
| 40 | 38 | autorepeat; |
| 41 | − button@21 { | |
| 39 | + | |
| 40 | + button21 { | |
| 42 | 41 | label = "GPIO Key UP"; |
| 43 | 42 | linux,code = <103>; |
| 44 | 43 | gpios = <&gpio1 0 1>; |
| @@ -19,6 +19,7 @@ Required properties: · 18 unmodified lines | ||
| 19 | 19 | or: "edt,edt-ft5306" |
| 20 | 20 | or: "edt,edt-ft5406" |
| 21 | 21 | or: "edt,edt-ft5506" |
| 22 | + or: "focaltech,ft6236" | |
| 22 | 23 | |
| 23 | 24 | - reg: I2C slave address of the chip (0x38) |
| 24 | 25 | - interrupt-parent: a phandle pointing to the interrupt controller |
| @@ -43,6 +44,13 @@ Optional properties: · 18 unmodified lines | ||
| 43 | 44 | |
| 44 | 45 | - offset: allows setting the edge compensation in the range from |
| 45 | 46 | 0 to 31. |
| 47 | + - touchscreen-size-x : See touchscreen.txt | |
| 48 | + - touchscreen-size-y : See touchscreen.txt | |
| 49 | + - touchscreen-fuzz-x : See touchscreen.txt | |
| 50 | + - touchscreen-fuzz-y : See touchscreen.txt | |
| 51 | + - touchscreen-inverted-x : See touchscreen.txt | |
| 52 | + - touchscreen-inverted-y : See touchscreen.txt | |
| 53 | + - touchscreen-swapped-x-y : See touchscreen.txt | |
| 46 | 54 | |
| 47 | 55 | Example: |
| 48 | 56 | polytouch: edt-ft5x06@38 { |
| @@ -0,0 +1,27 @@ | ||
| 1 | +* Elan eKTF2127 I2C touchscreen controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : "elan,ektf2127" | |
| 5 | + - reg : I2C slave address of the chip (0x40) | |
| 6 | + - interrupt-parent : a phandle pointing to the interrupt controller | |
| 7 | + serving the interrupt for this chip | |
| 8 | + - interrupts : interrupt specification for the ektf2127 interrupt | |
| 9 | + - power-gpios : GPIO specification for the pin connected to the | |
| 10 | + ektf2127's wake input. This needs to be driven high | |
| 11 | + to take ektf2127 out of it's low power state | |
| 12 | + | |
| 13 | +For additional optional properties see: touchscreen.txt | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | +i2c@00000000 { | |
| 18 | + ektf2127: touchscreen@15 { | |
| 19 | + compatible = "elan,ektf2127"; | |
| 20 | + reg = <0x15>; | |
| 21 | + interrupt-parent = <&pio>; | |
| 22 | + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING> | |
| 23 | + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; | |
| 24 | + touchscreen-inverted-x; | |
| 25 | + touchscreen-swapped-x-y; | |
| 26 | + }; | |
| 27 | +}; | |
| @@ -1,35 +0,0 @@ | ||
| 1 | −* FocalTech FT6236 I2C touchscreen controller | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | − - compatible : "focaltech,ft6236" | |
| 5 | − - reg : I2C slave address of the chip (0x38) | |
| 6 | − - interrupt-parent : a phandle pointing to the interrupt controller | |
| 7 | − serving the interrupt for this chip | |
| 8 | − - interrupts : interrupt specification for the touch controller | |
| 9 | − interrupt | |
| 10 | − - reset-gpios : GPIO specification for the RSTN input | |
| 11 | − - touchscreen-size-x : horizontal resolution of touchscreen (in pixels) | |
| 12 | − - touchscreen-size-y : vertical resolution of touchscreen (in pixels) | |
| 13 | − | |
| 14 | −Optional properties: | |
| 15 | − - touchscreen-fuzz-x : horizontal noise value of the absolute input | |
| 16 | − device (in pixels) | |
| 17 | − - touchscreen-fuzz-y : vertical noise value of the absolute input | |
| 18 | − device (in pixels) | |
| 19 | − - touchscreen-inverted-x : X axis is inverted (boolean) | |
| 20 | − - touchscreen-inverted-y : Y axis is inverted (boolean) | |
| 21 | − - touchscreen-swapped-x-y: X and Y axis are swapped (boolean) | |
| 22 | − Swapping is done after inverting the axis | |
| 23 | − | |
| 24 | −Example: | |
| 25 | − | |
| 26 | − ft6x06@38 { | |
| 27 | − compatible = "focaltech,ft6236"; | |
| 28 | − reg = <0x38>; | |
| 29 | − interrupt-parent = <&gpio>; | |
| 30 | − interrupts = <23 2>; | |
| 31 | − touchscreen-size-x = <320>; | |
| 32 | − touchscreen-size-y = <480>; | |
| 33 | − touchscreen-inverted-x; | |
| 34 | − touchscreen-swapped-x-y; | |
| 35 | − }; | |
| @@ -0,0 +1,21 @@ | ||
| 1 | +* MELFAS MIP4 Touchscreen | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: must be "melfas,mip4_ts" | |
| 5 | +- reg: I2C slave address of the chip (0x48 or 0x34) | |
| 6 | +- interrupt-parent: interrupt controller to which the chip is connected | |
| 7 | +- interrupts: interrupt to which the chip is connected | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | +- ce-gpios: GPIO connected to the CE (chip enable) pin of the chip | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + i2c@00000000 { | |
| 14 | + touchscreen: melfas_mip4@48 { | |
| 15 | + compatible = "melfas,mip4_ts"; | |
| 16 | + reg = <0x48>; | |
| 17 | + interrupt-parent = <&gpio>; | |
| 18 | + interrupts = <0 IRQ_TYPE_EDGE_FALLING>; | |
| 19 | + ce-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; | |
| 20 | + }; | |
| 21 | + }; | |
| @@ -13,6 +13,7 @@ Required properties: · 12 unmodified lines | ||
| 13 | 13 | - touchscreen-size-y : See touchscreen.txt |
| 14 | 14 | |
| 15 | 15 | Optional properties: |
| 16 | +- firmware-name : File basename (string) for board specific firmware | |
| 16 | 17 | - touchscreen-inverted-x : See touchscreen.txt |
| 17 | 18 | - touchscreen-inverted-y : See touchscreen.txt |
| 18 | 19 | - touchscreen-swapped-x-y : See touchscreen.txt |
| @@ -1,13 +1,24 @@ | ||
| 1 | −Texas Instruments TPS65218 power button | |
| 1 | +Texas Instruments TPS65217 and TPS65218 power button | |
| 2 | + | |
| 3 | +This module is part of the TPS65217/TPS65218. For more details about the whole | |
| 4 | +TPS65217 chip see Documentation/devicetree/bindings/regulator/tps65217.txt. | |
| 2 | 5 | |
| 3 | 6 | This driver provides a simple power button event via an Interrupt. |
| 4 | 7 | |
| 5 | 8 | Required properties: |
| 6 | −- compatible: should be "ti,tps65218-pwrbutton" | |
| 9 | +- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton" | |
| 10 | + | |
| 11 | +Required properties for TPS65218: | |
| 7 | 12 | - interrupts: should be one of the following |
| 8 | 13 | - <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218 |
| 9 | 14 | |
| 10 | −Example: | |
| 15 | +Examples: | |
| 16 | + | |
| 17 | +&tps { | |
| 18 | + tps65217-pwrbutton { | |
| 19 | + compatible = "ti,tps65217-pwrbutton"; | |
| 20 | + }; | |
| 21 | +}; | |
| 11 | 22 | |
| 12 | 23 | &tps { |
| 13 | 24 | power-button { |
| @@ -0,0 +1,26 @@ | ||
| 1 | +J-Core Advanced Interrupt Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: Should be "jcore,aic1" for the (obsolete) first-generation aic | |
| 6 | + with 8 interrupt lines with programmable priorities, or "jcore,aic2" for | |
| 7 | + the "aic2" core with 64 interrupts. | |
| 8 | + | |
| 9 | +- reg: Memory region(s) for configuration. For SMP, there should be one | |
| 10 | + region per cpu, indexed by the sequential, zero-based hardware cpu | |
| 11 | + number. | |
| 12 | + | |
| 13 | +- interrupt-controller: Identifies the node as an interrupt controller | |
| 14 | + | |
| 15 | +- #interrupt-cells: Specifies the number of cells needed to encode an | |
| 16 | + interrupt source. The value shall be 1. | |
| 17 | + | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + | |
| 21 | +aic: interrupt-controller@200 { | |
| 22 | + compatible = "jcore,aic2"; | |
| 23 | + reg = < 0x200 0x30 0x500 0x30 >; | |
| 24 | + interrupt-controller; | |
| 25 | + #interrupt-cells = <1>; | |
| 26 | +}; | |
| @@ -0,0 +1,25 @@ | ||
| 1 | +Marvell Armada 7K/8K PIC Interrupt controller | |
| 2 | +--------------------------------------------- | |
| 3 | + | |
| 4 | +This is the Device Tree binding for the PIC, a secondary interrupt | |
| 5 | +controller available on the Marvell Armada 7K/8K ARM64 SoCs, and | |
| 6 | +typically connected to the GIC as the primary interrupt controller. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: should be "marvell,armada-8k-pic" | |
| 10 | +- interrupt-controller: identifies the node as an interrupt controller | |
| 11 | +- #interrupt-cells: the number of cells to define interrupts on this | |
| 12 | + controller. Should be 1 | |
| 13 | +- reg: the register area for the PIC interrupt controller | |
| 14 | +- interrupts: the interrupt to the primary interrupt controller, | |
| 15 | + typically the GIC | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + pic: interrupt-controller@3f0100 { | |
| 20 | + compatible = "marvell,armada-8k-pic"; | |
| 21 | + reg = <0x3f0100 0x10>; | |
| 22 | + #interrupt-cells = <1>; | |
| 23 | + interrupt-controller; | |
| 24 | + interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>; | |
| 25 | + }; | |
| @@ -31,7 +31,7 @@ Required properties: · 30 unmodified lines | ||
| 31 | 31 | Example: |
| 32 | 32 | |
| 33 | 33 | odmi: odmi@300000 { |
| 34 | − compatible = "marvell,ap806-odm-controller", | |
| 34 | + compatible = "marvell,ap806-odmi-controller", | |
| 35 | 35 | "marvell,odmi-controller"; |
| 36 | 36 | interrupt-controller; |
| 37 | 37 | msi-controller; |
| @@ -1,10 +1,12 @@ | ||
| 1 | −DT bindings for the R-Mobile/R-Car interrupt controller | |
| 1 | +DT bindings for the R-Mobile/R-Car/RZ/G interrupt controller | |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | 5 | - compatible: has to be "renesas,irqc-<soctype>", "renesas,irqc" as fallback. |
| 6 | 6 | Examples with soctypes are: |
| 7 | 7 | - "renesas,irqc-r8a73a4" (R-Mobile APE6) |
| 8 | + - "renesas,irqc-r8a7743" (RZ/G1M) | |
| 9 | + - "renesas,irqc-r8a7745" (RZ/G1E) | |
| 8 | 10 | - "renesas,irqc-r8a7790" (R-Car H2) |
| 9 | 11 | - "renesas,irqc-r8a7791" (R-Car M2-W) |
| 10 | 12 | - "renesas,irqc-r8a7792" (R-Car V2H) |
| @@ -0,0 +1,20 @@ | ||
| 1 | +STM32 External Interrupt Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: Should be "st,stm32-exti" | |
| 6 | +- reg: Specifies base physical address and size of the registers | |
| 7 | +- interrupt-controller: Indentifies the node as an interrupt controller | |
| 8 | +- #interrupt-cells: Specifies the number of cells to encode an interrupt | |
| 9 | + specifier, shall be 2 | |
| 10 | +- interrupts: interrupts references to primary interrupt controller | |
| 11 | + | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +exti: interrupt-controller@40013c00 { | |
| 15 | + compatible = "st,stm32-exti"; | |
| 16 | + interrupt-controller; | |
| 17 | + #interrupt-cells = <2>; | |
| 18 | + reg = <0x40013C00 0x400>; | |
| 19 | + interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>; | |
| 20 | +}; | |
| @@ -27,6 +27,12 @@ the PCIe specification. · 26 unmodified lines | ||
| 27 | 27 | * "cmdq-sync" - CMD_SYNC complete |
| 28 | 28 | * "gerror" - Global Error activated |
| 29 | 29 | |
| 30 | +- #iommu-cells : See the generic IOMMU binding described in | |
| 31 | + devicetree/bindings/pci/pci-iommu.txt | |
| 32 | + for details. For SMMUv3, must be 1, with each cell | |
| 33 | + describing a single stream ID. All possible stream | |
| 34 | + IDs which a device may emit must be described. | |
| 35 | + | |
| 30 | 36 | ** SMMUv3 optional properties: |
| 31 | 37 | |
| 32 | 38 | - dma-coherent : Present if DMA operations made by the SMMU (page |
| @@ -54,6 +60,6 @@ the PCIe specification. · 21 unmodified lines | ||
| 54 | 60 | <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>; |
| 55 | 61 | interrupt-names = "eventq", "priq", "cmdq-sync", "gerror"; |
| 56 | 62 | dma-coherent; |
| 57 | − #iommu-cells = <0>; | |
| 63 | + #iommu-cells = <1>; | |
| 58 | 64 | msi-parent = <&its 0xff0000>; |
| 59 | 65 | }; |
| @@ -35,12 +35,16 @@ conditions. · 34 unmodified lines | ||
| 35 | 35 | interrupt per context bank. In the case of a single, |
| 36 | 36 | combined interrupt, it must be listed multiple times. |
| 37 | 37 | |
| 38 | −- mmu-masters : A list of phandles to device nodes representing bus | |
| 39 | − masters for which the SMMU can provide a translation | |
| 40 | − and their corresponding StreamIDs (see example below). | |
| 41 | − Each device node linked from this list must have a | |
| 42 | − "#stream-id-cells" property, indicating the number of | |
| 43 | − StreamIDs associated with it. | |
| 38 | +- #iommu-cells : See Documentation/devicetree/bindings/iommu/iommu.txt | |
| 39 | + for details. With a value of 1, each "iommus" entry | |
| 40 | + represents a distinct stream ID emitted by that device | |
| 41 | + into the relevant SMMU. | |
| 42 | + | |
| 43 | + SMMUs with stream matching support and complex masters | |
| 44 | + may use a value of 2, where the second cell represents | |
| 45 | + an SMR mask to combine with the ID in the first cell. | |
| 46 | + Care must be taken to ensure the set of matched IDs | |
| 47 | + does not result in conflicts. | |
| 44 | 48 | |
| 45 | 49 | ** System MMU optional properties: |
| 46 | 50 | |
| @@ -56,9 +60,20 @@ conditions. · 9 unmodified lines | ||
| 56 | 60 | aliases of secure registers have to be used during |
| 57 | 61 | SMMU configuration. |
| 58 | 62 | |
| 59 | −Example: | |
| 63 | +** Deprecated properties: | |
| 64 | + | |
| 65 | +- mmu-masters (deprecated in favour of the generic "iommus" binding) : | |
| 66 | + A list of phandles to device nodes representing bus | |
| 67 | + masters for which the SMMU can provide a translation | |
| 68 | + and their corresponding Stream IDs. Each device node | |
| 69 | + linked from this list must have a "#stream-id-cells" | |
| 70 | + property, indicating the number of Stream ID | |
| 71 | + arguments associated with its phandle. | |
| 60 | 72 | |
| 61 | − smmu { | |
| 73 | +** Examples: | |
| 74 | + | |
| 75 | + /* SMMU with stream matching or stream indexing */ | |
| 76 | + smmu1: iommu { | |
| 62 | 77 | compatible = "arm,smmu-v1"; |
| 63 | 78 | reg = <0xba5e0000 0x10000>; |
| 64 | 79 | #global-interrupts = <2>; |
| @@ -68,11 +83,29 @@ Example: · 3 unmodified lines | ||
| 68 | 83 | <0 35 4>, |
| 69 | 84 | <0 36 4>, |
| 70 | 85 | <0 37 4>; |
| 86 | + #iommu-cells = <1>; | |
| 87 | + }; | |
| 88 | + | |
| 89 | + /* device with two stream IDs, 0 and 7 */ | |
| 90 | + master1 { | |
| 91 | + iommus = <&smmu1 0>, | |
| 92 | + <&smmu1 7>; | |
| 93 | + }; | |
| 94 | + | |
| 95 | + | |
| 96 | + /* SMMU with stream matching */ | |
| 97 | + smmu2: iommu { | |
| 98 | + ... | |
| 99 | + #iommu-cells = <2>; | |
| 100 | + }; | |
| 101 | + | |
| 102 | + /* device with stream IDs 0 and 7 */ | |
| 103 | + master2 { | |
| 104 | + iommus = <&smmu2 0 0>, | |
| 105 | + <&smmu2 7 0>; | |
| 106 | + }; | |
| 71 | 107 | |
| 72 | − /* | |
| 73 | − * Two DMA controllers, the first with two StreamIDs (0xd01d | |
| 74 | − * and 0xd01e) and the second with only one (0xd11c). | |
| 75 | − */ | |
| 76 | − mmu-masters = <&dma0 0xd01d 0xd01e>, | |
| 77 | − <&dma1 0xd11c>; | |
| 108 | + /* device with stream IDs 1, 17, 33 and 49 */ | |
| 109 | + master3 { | |
| 110 | + iommus = <&smmu2 1 0x30>; | |
| 78 | 111 | }; |
| @@ -0,0 +1,23 @@ | ||
| 1 | +* Aspeed BT (Block Transfer) IPMI interface | |
| 2 | + | |
| 3 | +The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs | |
| 4 | +(BaseBoard Management Controllers) and the BT interface can be used to | |
| 5 | +perform in-band IPMI communication with their host. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | + | |
| 9 | +- compatible : should be "aspeed,ast2400-bt-bmc" | |
| 10 | +- reg: physical address and size of the registers | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | + | |
| 14 | +- interrupts: interrupt generated by the BT interface. without an | |
| 15 | + interrupt, the driver will operate in poll mode. | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + ibt@1e789140 { | |
| 20 | + compatible = "aspeed,ast2400-bt-bmc"; | |
| 21 | + reg = <0x1e789140 0x18>; | |
| 22 | + interrupts = <8>; | |
| 23 | + }; | |
File renamed without changes.
| @@ -19,6 +19,13 @@ Optional properties for child nodes: · 18 unmodified lines | ||
| 19 | 19 | a device, i.e. no other LED class device can be assigned the same |
| 20 | 20 | label. |
| 21 | 21 | |
| 22 | +- default-state : The initial state of the LED. Valid values are "on", "off", | |
| 23 | + and "keep". If the LED is already on or off and the default-state property is | |
| 24 | + set the to same value, then no glitch should be produced where the LED | |
| 25 | + momentarily turns off (or on). The "keep" setting will keep the LED at | |
| 26 | + whatever its current state is, without producing a glitch. The default is | |
| 27 | + off if this property is not present. | |
| 28 | + | |
| 22 | 29 | - linux,default-trigger : This parameter, if present, is a |
| 23 | 30 | string defining the trigger assigned to the LED. Current triggers are: |
| 24 | 31 | "backlight" - LED will act as a back-light, controlled by the framebuffer |
| @@ -49,7 +49,7 @@ LED sub-node optional properties: · 48 unmodified lines | ||
| 49 | 49 | - active-low : Boolean, makes LED active low. |
| 50 | 50 | Default : false |
| 51 | 51 | - default-state : see |
| 52 | − Documentation/devicetree/bindings/leds/leds-gpio.txt | |
| 52 | + Documentation/devicetree/bindings/leds/common.txt | |
| 53 | 53 | - linux,default-trigger : see |
| 54 | 54 | Documentation/devicetree/bindings/leds/common.txt |
| 55 | 55 | |
| @@ -28,7 +28,7 @@ LED sub-node optional properties: · 27 unmodified lines | ||
| 28 | 28 | - active-low : Boolean, makes LED active low. |
| 29 | 29 | Default : false |
| 30 | 30 | - default-state : see |
| 31 | − Documentation/devicetree/bindings/leds/leds-gpio.txt | |
| 31 | + Documentation/devicetree/bindings/leds/common.txt | |
| 32 | 32 | - linux,default-trigger : see |
| 33 | 33 | Documentation/devicetree/bindings/leds/common.txt |
| 34 | 34 | |
| @@ -14,13 +14,8 @@ LED sub-node properties: · 13 unmodified lines | ||
| 14 | 14 | see Documentation/devicetree/bindings/leds/common.txt |
| 15 | 15 | - linux,default-trigger : (optional) |
| 16 | 16 | see Documentation/devicetree/bindings/leds/common.txt |
| 17 | −- default-state: (optional) The initial state of the LED. Valid | |
| 18 | − values are "on", "off", and "keep". If the LED is already on or off | |
| 19 | − and the default-state property is set the to same value, then no | |
| 20 | − glitch should be produced where the LED momentarily turns off (or | |
| 21 | − on). The "keep" setting will keep the LED at whatever its current | |
| 22 | − state is, without producing a glitch. The default is off if this | |
| 23 | − property is not present. | |
| 17 | +- default-state: (optional) The initial state of the LED. | |
| 18 | + see Documentation/devicetree/bindings/leds/common.txt | |
| 24 | 19 | - retain-state-suspended: (optional) The suspend state can be retained.Such |
| 25 | 20 | as charge-led gpio. |
| 26 | 21 | - panic-indicator : (optional) |
| @@ -0,0 +1,59 @@ | ||
| 1 | +LEDs connected to is31fl319x LED controller chip | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : Should be any of | |
| 5 | + "issi,is31fl3190" | |
| 6 | + "issi,is31fl3191" | |
| 7 | + "issi,is31fl3193" | |
| 8 | + "issi,is31fl3196" | |
| 9 | + "issi,is31fl3199" | |
| 10 | + "si-en,sn3199". | |
| 11 | +- #address-cells: Must be 1. | |
| 12 | +- #size-cells: Must be 0. | |
| 13 | +- reg: 0x64, 0x65, 0x66, or 0x67. | |
| 14 | + | |
| 15 | +Optional properties: | |
| 16 | +- audio-gain-db : audio gain selection for external analog modulation input. | |
| 17 | + Valid values: 0 - 21, step by 3 (rounded down) | |
| 18 | + Default: 0 | |
| 19 | + | |
| 20 | +Each led is represented as a sub-node of the issi,is31fl319x device. | |
| 21 | +There can be less leds subnodes than the chip can support but not more. | |
| 22 | + | |
| 23 | +Required led sub-node properties: | |
| 24 | +- reg : number of LED line | |
| 25 | + Valid values: 1 - number of leds supported by the chip variant. | |
| 26 | + | |
| 27 | +Optional led sub-node properties: | |
| 28 | +- label : see Documentation/devicetree/bindings/leds/common.txt. | |
| 29 | +- linux,default-trigger : | |
| 30 | + see Documentation/devicetree/bindings/leds/common.txt. | |
| 31 | +- led-max-microamp : (optional) | |
| 32 | + Valid values: 5000 - 40000, step by 5000 (rounded down) | |
| 33 | + Default: 20000 (20 mA) | |
| 34 | + Note: a driver will take the lowest of all led limits since the | |
| 35 | + chip has a single global setting. The lowest value will be chosen | |
| 36 | + due to the PWM specificity, where lower brightness is achieved | |
| 37 | + by reducing the dury-cycle of pulses and not the current, which | |
| 38 | + will always have its peak value equal to led-max-microamp. | |
| 39 | + | |
| 40 | +Examples: | |
| 41 | + | |
| 42 | +fancy_leds: leds@65 { | |
| 43 | + compatible = "issi,is31fl3196"; | |
| 44 | + #address-cells = <1>; | |
| 45 | + #size-cells = <0>; | |
| 46 | + reg = <0x65>; | |
| 47 | + | |
| 48 | + red_aux: led@1 { | |
| 49 | + label = "red:aux"; | |
| 50 | + reg = <1>; | |
| 51 | + led-max-microamp = <10000>; | |
| 52 | + }; | |
| 53 | + | |
| 54 | + green_power: led@5 { | |
| 55 | + label = "green:power"; | |
| 56 | + reg = <5>; | |
| 57 | + linux,default-trigger = "default-on"; | |
| 58 | + }; | |
| 59 | +}; | |
| @@ -0,0 +1,67 @@ | ||
| 1 | +Qualcomm PM8058 LED driver | |
| 2 | + | |
| 3 | +The Qualcomm PM8058 is a multi-functional device which contains | |
| 4 | +an LED driver block for up to six LEDs: three normal LEDs, two | |
| 5 | +"flash" LEDs and one "keypad backlight" LED. The names are | |
| 6 | +quoted because sometimes these LED drivers are used for wildly | |
| 7 | +different things than flash or keypad backlight: their names | |
| 8 | +are more of a suggestion than a hard-wired usecase. | |
| 9 | + | |
| 10 | +Hardware-wise the different LEDs support slightly different | |
| 11 | +output currents. The "flash" LEDs do not need to charge nor | |
| 12 | +do they support external triggers. They are just powerful LED | |
| 13 | +drivers. | |
| 14 | + | |
| 15 | +The LEDs appear as children to the PM8058 device, with the | |
| 16 | +proper compatible string. For the PM8058 bindings see: | |
| 17 | +mfd/qcom-pm8xxx.txt. | |
| 18 | + | |
| 19 | +Each LED is represented as a sub-node of the syscon device. Each | |
| 20 | +node's name represents the name of the corresponding LED. | |
| 21 | + | |
| 22 | +LED sub-node properties: | |
| 23 | + | |
| 24 | +Required properties: | |
| 25 | +- compatible: one of | |
| 26 | + "qcom,pm8058-led" (for the normal LEDs at 0x131, 0x132 and 0x133) | |
| 27 | + "qcom,pm8058-keypad-led" (for the "keypad" LED at 0x48) | |
| 28 | + "qcom,pm8058-flash-led" (for the "flash" LEDs at 0x49 and 0xFB) | |
| 29 | + | |
| 30 | +Optional properties: | |
| 31 | +- label: see Documentation/devicetree/bindings/leds/common.txt | |
| 32 | +- default-state: see Documentation/devicetree/bindings/leds/common.txt | |
| 33 | +- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt | |
| 34 | + | |
| 35 | +Example: | |
| 36 | + | |
| 37 | +qcom,ssbi@500000 { | |
| 38 | + pmicintc: pmic@0 { | |
| 39 | + compatible = "qcom,pm8058"; | |
| 40 | + led@48 { | |
| 41 | + compatible = "qcom,pm8058-keypad-led"; | |
| 42 | + reg = <0x48>; | |
| 43 | + label = "pm8050:white:keypad"; | |
| 44 | + default-state = "off"; | |
| 45 | + }; | |
| 46 | + led@131 { | |
| 47 | + compatible = "qcom,pm8058-led"; | |
| 48 | + reg = <0x131>; | |
| 49 | + label = "pm8058:red"; | |
| 50 | + default-state = "off"; | |
| 51 | + }; | |
| 52 | + led@132 { | |
| 53 | + compatible = "qcom,pm8058-led"; | |
| 54 | + reg = <0x132>; | |
| 55 | + label = "pm8058:yellow"; | |
| 56 | + default-state = "off"; | |
| 57 | + linux,default-trigger = "mmc0"; | |
| 58 | + }; | |
| 59 | + led@133 { | |
| 60 | + compatible = "qcom,pm8058-led"; | |
| 61 | + reg = <0x133>; | |
| 62 | + label = "pm8058:green"; | |
| 63 | + default-state = "on"; | |
| 64 | + linux,default-trigger = "heartbeat"; | |
| 65 | + }; | |
| 66 | + }; | |
| 67 | +}; | |
| @@ -23,13 +23,8 @@ Optional properties: · 22 unmodified lines | ||
| 23 | 23 | see Documentation/devicetree/bindings/leds/common.txt |
| 24 | 24 | - linux,default-trigger : (optional) |
| 25 | 25 | see Documentation/devicetree/bindings/leds/common.txt |
| 26 | −- default-state: (optional) The initial state of the LED. Valid | |
| 27 | − values are "on", "off", and "keep". If the LED is already on or off | |
| 28 | − and the default-state property is set the to same value, then no | |
| 29 | − glitch should be produced where the LED momentarily turns off (or | |
| 30 | − on). The "keep" setting will keep the LED at whatever its current | |
| 31 | − state is, without producing a glitch. The default is off if this | |
| 32 | − property is not present. | |
| 26 | +- default-state: (optional) The initial state of the LED | |
| 27 | + see Documentation/devicetree/bindings/leds/common.txt | |
| 33 | 28 | |
| 34 | 29 | Example: |
| 35 | 30 | |
| @@ -0,0 +1,34 @@ | ||
| 1 | +Amlogic Meson MHU Mailbox Driver | |
| 2 | +================================ | |
| 3 | + | |
| 4 | +The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller | |
| 5 | +that has 3 independent channels/links to communicate with remote processor(s). | |
| 6 | +MHU links are hardwired on a platform. A link raises interrupt for any | |
| 7 | +received data. However, there is no specified way of knowing if the sent | |
| 8 | +data has been read by the remote. This driver assumes the sender polls | |
| 9 | +STAT register and the remote clears it after having read the data. | |
| 10 | + | |
| 11 | +Mailbox Device Node: | |
| 12 | +==================== | |
| 13 | + | |
| 14 | +Required properties: | |
| 15 | +-------------------- | |
| 16 | +- compatible: Shall be "amlogic,meson-gxbb-mhu" | |
| 17 | +- reg: Contains the mailbox register address range (base | |
| 18 | + address and length) | |
| 19 | +- #mbox-cells Shall be 1 - the index of the channel needed. | |
| 20 | +- interrupts: Contains the interrupt information corresponding to | |
| 21 | + each of the 2 links of MHU. | |
| 22 | + | |
| 23 | +Example: | |
| 24 | +-------- | |
| 25 | + | |
| 26 | + mailbox: mailbox@c883c404 { | |
| 27 | + #mbox-cells = <1>; | |
| 28 | + compatible = "amlogic,meson-gxbb-mhu"; | |
| 29 | + reg = <0 0xc883c404 0 0x4c>; | |
| 30 | + interrupts = <0 208 IRQ_TYPE_EDGE_RISING>, | |
| 31 | + <0 209 IRQ_TYPE_EDGE_RISING>, | |
| 32 | + <0 210 IRQ_TYPE_EDGE_RISING>; | |
| 33 | + #mbox-cells = <1>; | |
| 34 | + }; | |
| @@ -0,0 +1,65 @@ | ||
| 1 | +Atmel Image Sensor Controller (ISC) | |
| 2 | +---------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties for ISC: | |
| 5 | +- compatible | |
| 6 | + Must be "atmel,sama5d2-isc". | |
| 7 | +- reg | |
| 8 | + Physical base address and length of the registers set for the device. | |
| 9 | +- interrupts | |
| 10 | + Should contain IRQ line for the ISC. | |
| 11 | +- clocks | |
| 12 | + List of clock specifiers, corresponding to entries in | |
| 13 | + the clock-names property; | |
| 14 | + Please refer to clock-bindings.txt. | |
| 15 | +- clock-names | |
| 16 | + Required elements: "hclock", "iscck", "gck". | |
| 17 | +- #clock-cells | |
| 18 | + Should be 0. | |
| 19 | +- clock-output-names | |
| 20 | + Should be "isc-mck". | |
| 21 | +- pinctrl-names, pinctrl-0 | |
| 22 | + Please refer to pinctrl-bindings.txt. | |
| 23 | + | |
| 24 | +ISC supports a single port node with parallel bus. It should contain one | |
| 25 | +'port' child node with child 'endpoint' node. Please refer to the bindings | |
| 26 | +defined in Documentation/devicetree/bindings/media/video-interfaces.txt. | |
| 27 | + | |
| 28 | +Example: | |
| 29 | +isc: isc@f0008000 { | |
| 30 | + compatible = "atmel,sama5d2-isc"; | |
| 31 | + reg = <0xf0008000 0x4000>; | |
| 32 | + interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>; | |
| 33 | + clocks = <&isc_clk>, <&iscck>, <&isc_gclk>; | |
| 34 | + clock-names = "hclock", "iscck", "gck"; | |
| 35 | + #clock-cells = <0>; | |
| 36 | + clock-output-names = "isc-mck"; | |
| 37 | + pinctrl-names = "default"; | |
| 38 | + pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit &pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>; | |
| 39 | + | |
| 40 | + port { | |
| 41 | + isc_0: endpoint { | |
| 42 | + remote-endpoint = <&ov7740_0>; | |
| 43 | + hsync-active = <1>; | |
| 44 | + vsync-active = <0>; | |
| 45 | + pclk-sample = <1>; | |
| 46 | + }; | |
| 47 | + }; | |
| 48 | +}; | |
| 49 | + | |
| 50 | +i2c1: i2c@fc028000 { | |
| 51 | + ov7740: camera@21 { | |
| 52 | + compatible = "ovti,ov7740"; | |
| 53 | + reg = <0x21>; | |
| 54 | + clocks = <&isc>; | |
| 55 | + clock-names = "xvclk"; | |
| 56 | + assigned-clocks = <&isc>; | |
| 57 | + assigned-clock-rates = <24000000>; | |
| 58 | + | |
| 59 | + port { | |
| 60 | + ov7740_0: endpoint { | |
| 61 | + remote-endpoint = <&isc_0>; | |
| 62 | + }; | |
| 63 | + }; | |
| 64 | + }; | |
| 65 | +}; | |
| @@ -16,9 +16,10 @@ Required properties: · 15 unmodified lines | ||
| 16 | 16 | - clocks : list of clock specifiers, corresponding to entries in |
| 17 | 17 | clock-names property; |
| 18 | 18 | - clock-names : must contain "ppmuispx", "ppmuispx", "lite0", "lite1" |
| 19 | − "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "uart", | |
| 20 | − "ispdiv0", "ispdiv1", "mcuispdiv0", "mcuispdiv1", "aclk200", | |
| 21 | − "div_aclk200", "aclk400mcuisp", "div_aclk400mcuisp" entries, | |
| 19 | + "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "gicisp", | |
| 20 | + "pwm_isp", "mcuctl_isp", "uart", "ispdiv0", "ispdiv1", | |
| 21 | + "mcuispdiv0", "mcuispdiv1", "aclk200", "div_aclk200", | |
| 22 | + "aclk400mcuisp", "div_aclk400mcuisp" entries, | |
| 22 | 23 | matching entries in the clocks property. |
| 23 | 24 | pmu subnode |
| 24 | 25 | ----------- |
| @@ -0,0 +1,19 @@ | ||
| 1 | +* Analog Devices AD5820 autofocus coil | |
| 2 | + | |
| 3 | +Required Properties: | |
| 4 | + | |
| 5 | + - compatible: Must contain "adi,ad5820" | |
| 6 | + | |
| 7 | + - reg: I2C slave address | |
| 8 | + | |
| 9 | + - VANA-supply: supply of voltage for VANA pin | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | + ad5820: coil@c { | |
| 14 | + compatible = "adi,ad5820"; | |
| 15 | + reg = <0x0c>; | |
| 16 | + | |
| 17 | + VANA-supply = <&vaux4>; | |
| 18 | + }; | |
| 19 | + | |
| @@ -15,6 +15,11 @@ Required Properties : · 14 unmodified lines | ||
| 15 | 15 | "adi,adv7282" |
| 16 | 16 | "adi,adv7282-m" |
| 17 | 17 | |
| 18 | +Optional Properties : | |
| 19 | +- powerdown-gpios: reference to the GPIO connected to the powerdown pin, | |
| 20 | + if any. | |
| 21 | + | |
| 22 | + | |
| 18 | 23 | Example: |
| 19 | 24 | |
| 20 | 25 | i2c0@1c22000 { |
| @@ -1,7 +1,10 @@ | ||
| 1 | 1 | * Amlogic Meson IR remote control receiver |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | − - compatible : should be "amlogic,meson6-ir" | |
| 4 | + - compatible : depending on the platform this should be one of: | |
| 5 | + - "amlogic,meson6-ir" | |
| 6 | + - "amlogic,meson8b-ir" | |
| 7 | + - "amlogic,meson-gxbb-ir" | |
| 5 | 8 | - reg : physical base address and length of the device registers |
| 6 | 9 | - interrupts : a single specifier for the interrupt from the device |
| 7 | 10 | |
| @@ -7,12 +7,14 @@ conversion of AXI transactions in order to reduce the memory bandwidth. · 6 unmodified lines | ||
| 7 | 7 | |
| 8 | 8 | There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and FCP |
| 9 | 9 | for FDP (FCPF). Their configuration and behaviour depend on the module they |
| 10 | −are paired with. These DT bindings currently support the FCPV only. | |
| 10 | +are paired with. These DT bindings currently support the FCPV and FCPF. | |
| 11 | 11 | |
| 12 | 12 | - compatible: Must be one or more of the following |
| 13 | 13 | |
| 14 | 14 | - "renesas,r8a7795-fcpv" for R8A7795 (R-Car H3) compatible 'FCP for VSP' |
| 15 | + - "renesas,r8a7795-fcpf" for R8A7795 (R-Car H3) compatible 'FCP for FDP' | |
| 15 | 16 | - "renesas,fcpv" for generic compatible 'FCP for VSP' |
| 17 | + - "renesas,fcpf" for generic compatible 'FCP for FDP' | |
| 16 | 18 | |
| 17 | 19 | When compatible with the generic version, nodes must list the |
| 18 | 20 | SoC-specific version corresponding to the platform first, followed by the |
| @@ -21,6 +23,10 @@ are paired with. These DT bindings currently support the FCPV only. · 2 unmodified lines | ||
| 21 | 23 | - reg: the register base and size for the device registers |
| 22 | 24 | - clocks: Reference to the functional clock |
| 23 | 25 | |
| 26 | +Optional properties: | |
| 27 | + - power-domains : power-domain property defined with a power domain specifier | |
| 28 | + to respective power domain. | |
| 29 | + | |
| 24 | 30 | |
| 25 | 31 | Device node example |
| 26 | 32 | ------------------- |
| @@ -29,4 +35,5 @@ Device node example · 2 unmodified lines | ||
| 29 | 35 | compatible = "renesas,r8a7795-fcpv", "renesas,fcpv"; |
| 30 | 36 | reg = <0 0xfea2f000 0 0x200>; |
| 31 | 37 | clocks = <&cpg CPG_MOD 602>; |
| 38 | + power-domains = <&sysc R8A7795_PD_A3VP>; | |
| 32 | 39 | }; |
| @@ -0,0 +1,24 @@ | ||
| 1 | +st-hva: multi-format video encoder for STMicroelectronics SoC. | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "st,st-hva". | |
| 5 | +- reg: HVA physical address location and length, esram address location and | |
| 6 | + length. | |
| 7 | +- reg-names: names of the registers listed in registers property in the same | |
| 8 | + order. | |
| 9 | +- interrupts: HVA interrupt number. | |
| 10 | +- clocks: from common clock binding: handle hardware IP needed clocks, the | |
| 11 | + number of clocks may depend on the SoC type. | |
| 12 | + See ../clock/clock-bindings.txt for details. | |
| 13 | +- clock-names: names of the clocks listed in clocks property in the same order. | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + hva@8c85000{ | |
| 17 | + compatible = "st,st-hva"; | |
| 18 | + reg = <0x8c85000 0x400>, <0x6000000 0x40000>; | |
| 19 | + reg-names = "hva_registers", "hva_esram"; | |
| 20 | + interrupts = <GIC_SPI 58 IRQ_TYPE_NONE>, | |
| 21 | + <GIC_SPI 59 IRQ_TYPE_NONE>; | |
| 22 | + clock-names = "clk_hva"; | |
| 23 | + clocks = <&clk_s_c0_flexgen CLK_HVA>; | |
| 24 | + }; | |
| @@ -0,0 +1,25 @@ | ||
| 1 | +STMicroelectronics STIH4xx HDMI CEC driver | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible : value should be "st,stih-cec" | |
| 5 | + - reg : Physical base address of the IP registers and length of memory | |
| 6 | + mapped region. | |
| 7 | + - clocks : from common clock binding: handle to HDMI CEC clock | |
| 8 | + - interrupts : HDMI CEC interrupt number to the CPU. | |
| 9 | + - pinctrl-names: Contains only one value - "default" | |
| 10 | + - pinctrl-0: Specifies the pin control groups used for CEC hardware. | |
| 11 | + - resets: Reference to a reset controller | |
| 12 | + | |
| 13 | +Example for STIH407: | |
| 14 | + | |
| 15 | +sti-cec@094a087c { | |
| 16 | + compatible = "st,stih-cec"; | |
| 17 | + reg = <0x94a087c 0x64>; | |
| 18 | + clocks = <&clk_sysin>; | |
| 19 | + clock-names = "cec-clk"; | |
| 20 | + interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>; | |
| 21 | + interrupt-names = "cec-irq"; | |
| 22 | + pinctrl-names = "default"; | |
| 23 | + pinctrl-0 = <&pinctrl_cec0_default>; | |
| 24 | + resets = <&softreset STIH407_LPM_SOFTRESET>; | |
| 25 | +}; | |
| @@ -7,6 +7,8 @@ Properties: · 6 unmodified lines | ||
| 7 | 7 | "fsl,qoriq-memory-controller". |
| 8 | 8 | - reg : Address and size of DDR controller registers |
| 9 | 9 | - interrupts : Error interrupt of DDR controller |
| 10 | +- little-endian : Specifies little-endian access to registers | |
| 11 | + If omitted, big-endian will be used. | |
| 10 | 12 | |
| 11 | 13 | Example 1: |
| 12 | 14 | |
| @@ -0,0 +1,54 @@ | ||
| 1 | +X-Powers AC100 Codec/RTC IC Device Tree bindings | |
| 2 | + | |
| 3 | +AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are | |
| 4 | +separated, including power supplies and interrupt lines, but share | |
| 5 | +a common register address space and host interface. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: "x-powers,ac100" | |
| 9 | +- reg: The I2C slave address or RSB hardware address for the chip | |
| 10 | +- sub-nodes: | |
| 11 | + - codec | |
| 12 | + - compatible: "x-powers,ac100-codec" | |
| 13 | + - interrupt-parent: The parent interrupt controller | |
| 14 | + - interrupts: SoC NMI / GPIO interrupt connected to the | |
| 15 | + IRQ_AUDIO pin | |
| 16 | + - #clock-cells: Shall be 0 | |
| 17 | + - clock-output-names: "4M_adda" | |
| 18 | + | |
| 19 | + - see clock/clock-bindings.txt for common clock bindings | |
| 20 | + | |
| 21 | + - rtc | |
| 22 | + - compatible: "x-powers,ac100-rtc" | |
| 23 | + - interrupt-parent: The parent interrupt controller | |
| 24 | + - interrupts: SoC NMI / GPIO interrupt connected to the | |
| 25 | + IRQ_RTC pin | |
| 26 | + - clocks: A phandle to the codec's "4M_adda" clock | |
| 27 | + - #clock-cells: Shall be 1 | |
| 28 | + - clock-output-names: "cko1_rtc", "cko2_rtc", "cko3_rtc" | |
| 29 | + | |
| 30 | + - see clock/clock-bindings.txt for common clock bindings | |
| 31 | + | |
| 32 | +Example: | |
| 33 | + | |
| 34 | +ac100: codec@e89 { | |
| 35 | + compatible = "x-powers,ac100"; | |
| 36 | + reg = <0xe89>; | |
| 37 | + | |
| 38 | + ac100_codec: codec { | |
| 39 | + compatible = "x-powers,ac100-codec"; | |
| 40 | + interrupt-parent = <&r_pio>; | |
| 41 | + interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */ | |
| 42 | + #clock-cells = <0>; | |
| 43 | + clock-output-names = "4M_adda"; | |
| 44 | + }; | |
| 45 | + | |
| 46 | + ac100_rtc: rtc { | |
| 47 | + compatible = "x-powers,ac100-rtc"; | |
| 48 | + interrupt-parent = <&nmi_intc>; | |
| 49 | + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; | |
| 50 | + clocks = <&ac100_codec>; | |
| 51 | + #clock-cells = <1>; | |
| 52 | + clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc"; | |
| 53 | + }; | |
| 54 | +}; | |
| @@ -14,13 +14,6 @@ Example: · 13 unmodified lines | ||
| 14 | 14 | reg = <0x5b>; |
| 15 | 15 | status = "okay"; |
| 16 | 16 | |
| 17 | − pinctrl-names = "default"; | |
| 18 | − pinctrl-0 = <&pinctrl_charger_chglev>; | |
| 19 | − active-semi,chglev-gpio = <&pioA 12 GPIO_ACTIVE_HIGH>; | |
| 20 | − active-semi,input-voltage-threshold-microvolt = <6600>; | |
| 21 | − active-semi,precondition-timeout = <40>; | |
| 22 | − active-semi,total-timeout = <3>; | |
| 23 | − | |
| 24 | 17 | active-semi,vsel-high; |
| 25 | 18 | |
| 26 | 19 | regulators { |
| @@ -73,4 +66,19 @@ Example: · 46 unmodified lines | ||
| 73 | 66 | regulator-always-on; |
| 74 | 67 | }; |
| 75 | 68 | }; |
| 69 | + | |
| 70 | + charger { | |
| 71 | + compatible = "active-semi,act8945a-charger"; | |
| 72 | + pinctrl-names = "default"; | |
| 73 | + pinctrl-0 = <&pinctrl_charger_chglev &pinctrl_charger_lbo &pinctrl_charger_irq>; | |
| 74 | + interrupt-parent = <&pioA>; | |
| 75 | + interrupts = <45 GPIO_ACTIVE_LOW>; | |
| 76 | + | |
| 77 | + active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>; | |
| 78 | + active-semi,lbo-gpios = <&pioA 72 GPIO_ACTIVE_LOW>; | |
| 79 | + active-semi,input-voltage-threshold-microvolt = <6600>; | |
| 80 | + active-semi,precondition-timeout = <40>; | |
| 81 | + active-semi,total-timeout = <3>; | |
| 82 | + status = "okay"; | |
| 83 | + }; | |
| 76 | 84 | }; |
| @@ -85,6 +85,24 @@ Optional properties: · 84 unmodified lines | ||
| 85 | 85 | present, the number of values should be less than or equal to the |
| 86 | 86 | number of inputs, unspecified inputs will use the chip default. |
| 87 | 87 | |
| 88 | + - wlf,max-channels-clocked : The maximum number of channels to be clocked on | |
| 89 | + each AIF, useful for I2S systems with multiple data lines being mastered. | |
| 90 | + Specify one cell for each AIF to be configured, specify zero for AIFs that | |
| 91 | + should be handled normally. | |
| 92 | + If present, number of cells must be less than or equal to the number of | |
| 93 | + AIFs. If less than the number of AIFs, for cells that have not been | |
| 94 | + specified the corresponding AIFs will be treated as default setting. | |
| 95 | + | |
| 96 | + - wlf,spk-fmt : PDM speaker data format, must contain 2 cells (OUT5 and OUT6). | |
| 97 | + See the datasheet for values. | |
| 98 | + The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, | |
| 99 | + wm8998, wm1814) | |
| 100 | + | |
| 101 | + - wlf,spk-mute : PDM speaker mute setting, must contain 2 cells (OUT5 and OUT6). | |
| 102 | + See the datasheet for values. | |
| 103 | + The second cell is ignored for codecs that do not have OUT6 (wm5102, wm8997, | |
| 104 | + wm8998, wm1814) | |
| 105 | + | |
| 88 | 106 | - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if |
| 89 | 107 | they are being externally supplied. As covered in |
| 90 | 108 | Documentation/devicetree/bindings/regulator/regulator.txt |
| @@ -0,0 +1,18 @@ | ||
| 1 | +The Aspeed System Control Unit manages the global behaviour of the SoC, | |
| 2 | +configuring elements such as clocks, pinmux, and reset. | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- compatible: One of: | |
| 6 | + "aspeed,ast2400-scu", "syscon", "simple-mfd" | |
| 7 | + "aspeed,g4-scu", "syscon", "simple-mfd" | |
| 8 | + "aspeed,ast2500-scu", "syscon", "simple-mfd" | |
| 9 | + "aspeed,g5-scu", "syscon", "simple-mfd" | |
| 10 | + | |
| 11 | +- reg: contains the offset and length of the SCU memory region | |
| 12 | + | |
| 13 | +Example: | |
| 14 | + | |
| 15 | +syscon: syscon@1e6e2000 { | |
| 16 | + compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd"; | |
| 17 | + reg = <0x1e6e2000 0x1a8>; | |
| 18 | +}; | |
| @@ -10,7 +10,8 @@ axp809 (X-Powers) · 9 unmodified lines | ||
| 10 | 10 | |
| 11 | 11 | Required properties: |
| 12 | 12 | - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209", |
| 13 | − "x-powers,axp221", "x-powers,axp223", "x-powers,axp809" | |
| 13 | + "x-powers,axp221", "x-powers,axp223", "x-powers,axp806", | |
| 14 | + "x-powers,axp809" | |
| 14 | 15 | - reg: The I2C slave address or RSB hardware address for the AXP chip |
| 15 | 16 | - interrupt-parent: The parent interrupt controller |
| 16 | 17 | - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin |
| @@ -47,7 +48,6 @@ Optional properties for DCDC regulators: · 30 unmodified lines | ||
| 47 | 48 | probably makes sense for HiFi audio related |
| 48 | 49 | applications that aren't battery constrained. |
| 49 | 50 | |
| 50 | − | |
| 51 | 51 | AXP202/AXP209 regulators, type, and corresponding input supply names: |
| 52 | 52 | |
| 53 | 53 | Regulator Type Supply Name Notes |
| @@ -86,6 +86,30 @@ LDO_IO1 : LDO : ips-supply : GPIO 1 · 32 unmodified lines | ||
| 86 | 86 | RTC_LDO : LDO : ips-supply : always on |
| 87 | 87 | DRIVEVBUS : Enable output : drivevbus-supply : external regulator |
| 88 | 88 | |
| 89 | +AXP806 regulators, type, and corresponding input supply names: | |
| 90 | + | |
| 91 | +Regulator Type Supply Name Notes | |
| 92 | +--------- ---- ----------- ----- | |
| 93 | +DCDCA : DC-DC buck : vina-supply : poly-phase capable | |
| 94 | +DCDCB : DC-DC buck : vinb-supply : poly-phase capable | |
| 95 | +DCDCC : DC-DC buck : vinc-supply : poly-phase capable | |
| 96 | +DCDCD : DC-DC buck : vind-supply : poly-phase capable | |
| 97 | +DCDCE : DC-DC buck : vine-supply : poly-phase capable | |
| 98 | +ALDO1 : LDO : aldoin-supply : shared supply | |
| 99 | +ALDO2 : LDO : aldoin-supply : shared supply | |
| 100 | +ALDO3 : LDO : aldoin-supply : shared supply | |
| 101 | +BLDO1 : LDO : bldoin-supply : shared supply | |
| 102 | +BLDO2 : LDO : bldoin-supply : shared supply | |
| 103 | +BLDO3 : LDO : bldoin-supply : shared supply | |
| 104 | +BLDO4 : LDO : bldoin-supply : shared supply | |
| 105 | +CLDO1 : LDO : cldoin-supply : shared supply | |
| 106 | +CLDO2 : LDO : cldoin-supply : shared supply | |
| 107 | +CLDO3 : LDO : cldoin-supply : shared supply | |
| 108 | +SW : On/Off Switch : swin-supply | |
| 109 | + | |
| 110 | +Additionally, the AXP806 DC-DC regulators support poly-phase arrangements | |
| 111 | +for higher output current. The possible groupings are: A+B, A+B+C, D+E. | |
| 112 | + | |
| 89 | 113 | AXP809 regulators, type, and corresponding input supply names: |
| 90 | 114 | |
| 91 | 115 | Regulator Type Supply Name Notes |
| @@ -0,0 +1,59 @@ | ||
| 1 | +TI LP873X PMIC MFD driver | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: "ti,lp8732", "ti,lp8733" | |
| 5 | + - reg: I2C slave address. | |
| 6 | + - gpio-controller: Marks the device node as a GPIO Controller. | |
| 7 | + - #gpio-cells: Should be two. The first cell is the pin number and | |
| 8 | + the second cell is used to specify flags. | |
| 9 | + See ../gpio/gpio.txt for more information. | |
| 10 | + - regulators: List of child nodes that specify the regulator | |
| 11 | + initialization data. | |
| 12 | +Example: | |
| 13 | + | |
| 14 | +pmic: lp8733@60 { | |
| 15 | + compatible = "ti,lp8733"; | |
| 16 | + reg = <0x60>; | |
| 17 | + gpio-controller; | |
| 18 | + #gpio-cells = <2>; | |
| 19 | + | |
| 20 | + regulators { | |
| 21 | + lp8733_buck0: buck0 { | |
| 22 | + regulator-name = "lp8733-buck0"; | |
| 23 | + regulator-min-microvolt = <800000>; | |
| 24 | + regulator-max-microvolt = <1400000>; | |
| 25 | + regulator-min-microamp = <1500000>; | |
| 26 | + regulator-max-microamp = <4000000>; | |
| 27 | + regulator-ramp-delay = <10000>; | |
| 28 | + regulator-always-on; | |
| 29 | + regulator-boot-on; | |
| 30 | + }; | |
| 31 | + | |
| 32 | + lp8733_buck1: buck1 { | |
| 33 | + regulator-name = "lp8733-buck1"; | |
| 34 | + regulator-min-microvolt = <800000>; | |
| 35 | + regulator-max-microvolt = <1400000>; | |
| 36 | + regulator-min-microamp = <1500000>; | |
| 37 | + regulator-max-microamp = <4000000>; | |
| 38 | + regulator-ramp-delay = <10000>; | |
| 39 | + regulator-boot-on; | |
| 40 | + regulator-always-on; | |
| 41 | + }; | |
| 42 | + | |
| 43 | + lp8733_ldo0: ldo0 { | |
| 44 | + regulator-name = "lp8733-ldo0"; | |
| 45 | + regulator-min-microvolt = <800000>; | |
| 46 | + regulator-max-microvolt = <3000000>; | |
| 47 | + regulator-boot-on; | |
| 48 | + regulator-always-on; | |
| 49 | + }; | |
| 50 | + | |
| 51 | + lp8733_ldo1: ldo1 { | |
| 52 | + regulator-name = "lp8733-ldo1"; | |
| 53 | + regulator-min-microvolt = <800000>; | |
| 54 | + regulator-max-microvolt = <3000000>; | |
| 55 | + regulator-always-on; | |
| 56 | + regulator-boot-on; | |
| 57 | + }; | |
| 58 | + }; | |
| 59 | +}; | |
| @@ -17,28 +17,28 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | - interrupt-parent : The parent interrupt controller. |
| 18 | 18 | |
| 19 | 19 | Optional properties: |
| 20 | −- regulators : The regulators of max77693 have to be instantiated under subnod | |
| 20 | +- regulators : The regulators of max77693 have to be instantiated under subnode | |
| 21 | 21 | named "regulators" using the following format. |
| 22 | 22 | |
| 23 | 23 | regulators { |
| 24 | − regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER | |
| 25 | − standard regulator constratints[*]. | |
| 24 | + regulator-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER | |
| 25 | + standard regulator constraints[*]. | |
| 26 | 26 | }; |
| 27 | 27 | |
| 28 | 28 | [*] refer Documentation/devicetree/bindings/regulator/regulator.txt |
| 29 | 29 | |
| 30 | 30 | - haptic : The MAX77693 haptic device utilises a PWM controlled motor to provide |
| 31 | 31 | users with tactile feedback. PWM period and duty-cycle are varied in |
| 32 | − order to provide the approprite level of feedback. | |
| 32 | + order to provide the appropriate level of feedback. | |
| 33 | 33 | |
| 34 | 34 | Required properties: |
| 35 | − - compatible : Must be "maxim,max77693-hpatic" | |
| 35 | + - compatible : Must be "maxim,max77693-haptic" | |
| 36 | 36 | - haptic-supply : power supply for the haptic motor |
| 37 | 37 | [*] refer Documentation/devicetree/bindings/regulator/regulator.txt |
| 38 | 38 | - pwms : phandle to the physical PWM(Pulse Width Modulation) device. |
| 39 | 39 | PWM properties should be named "pwms". And number of cell is different |
| 40 | 40 | for each pwm device. |
| 41 | − To get more informations, please refer to documentaion. | |
| 41 | + To get more information, please refer to documentation. | |
| 42 | 42 | [*] refer Documentation/devicetree/bindings/pwm/pwm.txt |
| 43 | 43 | |
| 44 | 44 | - charger : Node configuring the charger driver. |
| @@ -62,6 +62,7 @@ The below bindings specify the set of valid subnodes. · 61 unmodified lines | ||
| 62 | 62 | "qcom,pm8058-rtc" |
| 63 | 63 | "qcom,pm8921-rtc" |
| 64 | 64 | "qcom,pm8941-rtc" |
| 65 | + "qcom,pm8018-rtc" | |
| 65 | 66 | |
| 66 | 67 | - reg: |
| 67 | 68 | Usage: required |
| @@ -13,6 +13,7 @@ frequencies. · 12 unmodified lines | ||
| 13 | 13 | "qcom,rpm-msm8660" |
| 14 | 14 | "qcom,rpm-msm8960" |
| 15 | 15 | "qcom,rpm-ipq8064" |
| 16 | + "qcom,rpm-mdm9615" | |
| 16 | 17 | |
| 17 | 18 | - reg: |
| 18 | 19 | Usage: required |
| @@ -59,6 +60,7 @@ Regulator nodes are identified by their compatible: · 40 unmodified lines | ||
| 59 | 60 | "qcom,rpm-pm8058-regulators" |
| 60 | 61 | "qcom,rpm-pm8901-regulators" |
| 61 | 62 | "qcom,rpm-pm8921-regulators" |
| 63 | + "qcom,rpm-pm8018-regulators" | |
| 62 | 64 | |
| 63 | 65 | - vdd_l0_l1_lvs-supply: |
| 64 | 66 | - vdd_l2_l11_l12-supply: |
| @@ -137,6 +139,15 @@ Regulator nodes are identified by their compatible: · 72 unmodified lines | ||
| 137 | 139 | Definition: reference to regulator supplying the input pin, as |
| 138 | 140 | described in the data sheet |
| 139 | 141 | |
| 142 | +- vin_lvs1-supply: | |
| 143 | +- vdd_l7-supply: | |
| 144 | +- vdd_l8-supply: | |
| 145 | +- vdd_l9_l10_l11_l12-supply: | |
| 146 | + Usage: optional (pm8018 only) | |
| 147 | + Value type: <phandle> | |
| 148 | + Definition: reference to regulator supplying the input pin, as | |
| 149 | + described in the data sheet | |
| 150 | + | |
| 140 | 151 | The regulator node houses sub-nodes for each regulator within the device. Each |
| 141 | 152 | sub-node is identified using the node's name, with valid values listed for each |
| 142 | 153 | of the pmics below. |
| @@ -156,6 +167,10 @@ pm8921: · 13 unmodified lines | ||
| 156 | 167 | l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch, |
| 157 | 168 | ncp |
| 158 | 169 | |
| 170 | +pm8018: | |
| 171 | + s1, s2, s3, s4, s5, , l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, | |
| 172 | + l12, l14, lvs1 | |
| 173 | + | |
| 159 | 174 | The content of each sub-node is defined by the standard binding for regulators - |
| 160 | 175 | see regulator.txt - with additional custom properties described below: |
| 161 | 176 | |
| @@ -1,7 +1,11 @@ | ||
| 1 | −RK808 Power Management Integrated Circuit | |
| 1 | +RK8XX Power Management Integrated Circuit | |
| 2 | + | |
| 3 | +The rk8xx family current members: | |
| 4 | +rk808 | |
| 5 | +rk818 | |
| 2 | 6 | |
| 3 | 7 | Required properties: |
| 4 | −- compatible: "rockchip,rk808" | |
| 8 | +- compatible: "rockchip,rk808", "rockchip,rk818" | |
| 5 | 9 | - reg: I2C slave address |
| 6 | 10 | - interrupt-parent: The parent interrupt controller. |
| 7 | 11 | - interrupts: the interrupt outputs of the controller. |
| @@ -13,6 +17,8 @@ Optional properties: · 5 unmodified lines | ||
| 13 | 17 | default output clock name |
| 14 | 18 | - rockchip,system-power-controller: Telling whether or not this pmic is controlling |
| 15 | 19 | the system power. |
| 20 | + | |
| 21 | +Optional RK808 properties: | |
| 16 | 22 | - vcc1-supply: The input supply for DCDC_REG1 |
| 17 | 23 | - vcc2-supply: The input supply for DCDC_REG2 |
| 18 | 24 | - vcc3-supply: The input supply for DCDC_REG3 |
| @@ -29,7 +35,20 @@ Optional properties: · 10 unmodified lines | ||
| 29 | 35 | the gpio controller. If DVS GPIOs aren't present, voltage changes will happen |
| 30 | 36 | very quickly with no slow ramp time. |
| 31 | 37 | |
| 32 | −Regulators: All the regulators of RK808 to be instantiated shall be | |
| 38 | +Optional RK818 properties: | |
| 39 | +- vcc1-supply: The input supply for DCDC_REG1 | |
| 40 | +- vcc2-supply: The input supply for DCDC_REG2 | |
| 41 | +- vcc3-supply: The input supply for DCDC_REG3 | |
| 42 | +- vcc4-supply: The input supply for DCDC_REG4 | |
| 43 | +- boost-supply: The input supply for DCDC_BOOST | |
| 44 | +- vcc6-supply: The input supply for LDO_REG1 and LDO_REG2 | |
| 45 | +- vcc7-supply: The input supply for LDO_REG3, LDO_REG5 and LDO_REG7 | |
| 46 | +- vcc8-supply: The input supply for LDO_REG4, LDO_REG6 and LDO_REG8 | |
| 47 | +- vcc9-supply: The input supply for LDO_REG9 and SWITCH_REG | |
| 48 | +- h_5v-supply: The input supply for HDMI_SWITCH | |
| 49 | +- usb-supply: The input supply for OTG_SWITCH | |
| 50 | + | |
| 51 | +Regulators: All the regulators of RK8XX to be instantiated shall be | |
| 33 | 52 | listed in a child node named 'regulators'. Each regulator is represented |
| 34 | 53 | by a child node of the 'regulators' node. |
| 35 | 54 | |
| @@ -48,6 +67,18 @@ number as described in RK808 datasheet. · 12 unmodified lines | ||
| 48 | 67 | - SWITCH_REGn |
| 49 | 68 | - valid values for n are 1 to 2 |
| 50 | 69 | |
| 70 | +Following regulators of the RK818 PMIC block are supported. Note that | |
| 71 | +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO | |
| 72 | +number as described in RK818 datasheet. | |
| 73 | + | |
| 74 | + - DCDC_REGn | |
| 75 | + - valid values for n are 1 to 4. | |
| 76 | + - LDO_REGn | |
| 77 | + - valid values for n are 1 to 9. | |
| 78 | + - SWITCH_REG | |
| 79 | + - HDMI_SWITCH | |
| 80 | + - OTG_SWITCH | |
| 81 | + | |
| 51 | 82 | Standard regulator bindings are used inside regulator subnodes. Check |
| 52 | 83 | Documentation/devicetree/bindings/regulator/regulator.txt |
| 53 | 84 | for more details |
| @@ -0,0 +1,70 @@ | ||
| 1 | +Samsung Exynos SoC Low Power Audio Subsystem (LPASS) | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | + - compatible : "samsung,exynos5433-lpass" | |
| 6 | + - reg : should contain the LPASS top SFR region location | |
| 7 | + and size | |
| 8 | + - samsung,pmu-syscon : the phandle to the Power Management Unit node | |
| 9 | + - #address-cells : should be 1 | |
| 10 | + - #size-cells : should be 1 | |
| 11 | + - ranges : must be present | |
| 12 | + | |
| 13 | +Each IP block of the Low Power Audio Subsystem should be specified as | |
| 14 | +an optional sub-node. For "samsung,exynos5433-lpass" compatible this includes: | |
| 15 | +UART, SLIMBUS, PCM, I2S, DMAC, Timers 0...4, VIC, WDT 0...1 devices. | |
| 16 | + | |
| 17 | +Bindings of the sub-nodes are described in: | |
| 18 | + ../serial/samsung_uart.txt | |
| 19 | + ../sound/samsung-i2s.txt | |
| 20 | + ../dma/arm-pl330.txt | |
| 21 | + | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + | |
| 25 | +audio-subsystem { | |
| 26 | + compatible = "samsung,exynos5433-lpass"; | |
| 27 | + reg = <0x11400000 0x100>, <0x11500000 0x08>; | |
| 28 | + samsung,pmu-syscon = <&pmu_system_controller>; | |
| 29 | + #address-cells = <1>; | |
| 30 | + #size-cells = <1>; | |
| 31 | + ranges; | |
| 32 | + | |
| 33 | + adma: adma@11420000 { | |
| 34 | + compatible = "arm,pl330", "arm,primecell"; | |
| 35 | + reg = <0x11420000 0x1000>; | |
| 36 | + interrupts = <0 73 0>; | |
| 37 | + clocks = <&cmu_aud CLK_ACLK_DMAC>; | |
| 38 | + clock-names = "apb_pclk"; | |
| 39 | + #dma-cells = <1>; | |
| 40 | + #dma-channels = <8>; | |
| 41 | + #dma-requests = <32>; | |
| 42 | + }; | |
| 43 | + | |
| 44 | + i2s0: i2s0@11440000 { | |
| 45 | + compatible = "samsung,exynos7-i2s"; | |
| 46 | + reg = <0x11440000 0x100>; | |
| 47 | + dmas = <&adma 0 &adma 2>; | |
| 48 | + dma-names = "tx", "rx"; | |
| 49 | + interrupts = <0 70 0>; | |
| 50 | + clocks = <&cmu_aud CLK_PCLK_AUD_I2S>, | |
| 51 | + <&cmu_aud CLK_SCLK_AUD_I2S>, | |
| 52 | + <&cmu_aud CLK_SCLK_I2S_BCLK>; | |
| 53 | + clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; | |
| 54 | + pinctrl-names = "default"; | |
| 55 | + pinctrl-0 = <&i2s0_bus>; | |
| 56 | + status = "disabled"; | |
| 57 | + }; | |
| 58 | + | |
| 59 | + serial_3: serial@11460000 { | |
| 60 | + compatible = "samsung,exynos5433-uart"; | |
| 61 | + reg = <0x11460000 0x100>; | |
| 62 | + interrupts = <0 67 0>; | |
| 63 | + clocks = <&cmu_aud CLK_PCLK_AUD_UART>, | |
| 64 | + <&cmu_aud CLK_SCLK_AUD_UART>; | |
| 65 | + clock-names = "uart", "clk_uart_baud0"; | |
| 66 | + pinctrl-names = "default"; | |
| 67 | + pinctrl-0 = <&uart_aud_bus>; | |
| 68 | + status = "disabled"; | |
| 69 | + }; | |
| 70 | + }; | |
| @@ -4,7 +4,7 @@ STMPE is an MFD device which may expose the following inbuilt devices: gpio, · 3 unmodified lines | ||
| 4 | 4 | keypad, touchscreen, adc, pwm, rotator. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | − - compatible : "st,stmpe[610|801|811|1601|2401|2403]" | |
| 7 | + - compatible : "st,stmpe[610|801|811|1600|1601|2401|2403]" | |
| 8 | 8 | - reg : I2C/SPI address of the device |
| 9 | 9 | |
| 10 | 10 | Optional properties: |
| @@ -12,6 +12,7 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | - interrupt-parent: The parent interrupt controller |
| 13 | 13 | - gpio-controller: |
| 14 | 14 | - #gpio-cells = <1>: twl6040 provides GPO lines. |
| 15 | +- #clock-cells = <0>; twl6040 is a provider of pdmclk which is used by McPDM | |
| 15 | 16 | - twl6040,audpwron-gpio: Power on GPIO line for the twl6040 |
| 16 | 17 | |
| 17 | 18 | - vio-supply: Regulator for the twl6040 VIO supply |
| @@ -2,9 +2,9 @@ · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | −- compatible: "brcm,bcm3384", "brcm,bcm33843" | |
| 5 | +- compatible: "brcm,bcm3368", "brcm,bcm3384", "brcm,bcm33843" | |
| 6 | 6 | "brcm,bcm3384-viper", "brcm,bcm33843-viper" |
| 7 | − "brcm,bcm6328", "brcm,bcm6358", "brcm,bcm6368", | |
| 7 | + "brcm,bcm6328", "brcm,bcm6358", "brcm,bcm6362", "brcm,bcm6368", | |
| 8 | 8 | "brcm,bcm63168", "brcm,bcm63268", |
| 9 | 9 | "brcm,bcm7125", "brcm,bcm7346", "brcm,bcm7358", "brcm,bcm7360", |
| 10 | 10 | "brcm,bcm7362", "brcm,bcm7420", "brcm,bcm7425" |
| @@ -36,6 +36,9 @@ Optional Properties: · 35 unmodified lines | ||
| 36 | 36 | - #clock-cells: If specified this should be the value <0>. With this property |
| 37 | 37 | in place we will export a clock representing the Card Clock. This clock |
| 38 | 38 | is expected to be consumed by our PHY. You must also specify |
| 39 | + - xlnx,fails-without-test-cd: when present, the controller doesn't work when | |
| 40 | + the CD line is not connected properly, and the line is not connected | |
| 41 | + properly. Test mode can be used to force the controller to function. | |
| 39 | 42 | |
| 40 | 43 | Example: |
| 41 | 44 | sdhci@e0100000 { |
| @@ -8,7 +8,9 @@ on Device Tree properties to enable them for SoC/Board combinations · 7 unmodified lines | ||
| 8 | 8 | that support them. |
| 9 | 9 | |
| 10 | 10 | Required properties: |
| 11 | −- compatible: "brcm,bcm7425-sdhci" | |
| 11 | +- compatible: should be one of the following | |
| 12 | + - "brcm,bcm7425-sdhci" | |
| 13 | + - "brcm,bcm7445-sdhci" | |
| 12 | 14 | |
| 13 | 15 | Refer to clocks/clock-bindings.txt for generic clock consumer properties. |
| 14 | 16 | |
| @@ -16,6 +16,8 @@ Optional properties: · 15 unmodified lines | ||
| 16 | 16 | See ../clocks/clock-bindings.txt for details. |
| 17 | 17 | - clock-names : Must include the following entry: |
| 18 | 18 | "ext_clock" (External clock provided to the card). |
| 19 | +- post-power-on-delay-ms : Delay in ms after powering the card and | |
| 20 | + de-asserting the reset-gpios (if any) | |
| 19 | 21 | |
| 20 | 22 | Example: |
| 21 | 23 | |
| @@ -75,6 +75,17 @@ Optional SDIO properties: · 74 unmodified lines | ||
| 75 | 75 | - wakeup-source: Enables wake up of host system on SDIO IRQ assertion |
| 76 | 76 | (Legacy property supported: "enable-sdio-wakeup") |
| 77 | 77 | |
| 78 | +MMC power | |
| 79 | +--------- | |
| 80 | + | |
| 81 | +Controllers may implement power control from both the connected cards and | |
| 82 | +the IO signaling (for example to change to high-speed 1.8V signalling). If | |
| 83 | +the system supports this, then the following two properties should point | |
| 84 | +to valid regulator nodes: | |
| 85 | + | |
| 86 | +- vqmmc-supply: supply node for IO line power | |
| 87 | +- vmmc-supply: supply node for card's power | |
| 88 | + | |
| 78 | 89 | |
| 79 | 90 | MMC power sequences: |
| 80 | 91 | -------------------- |
| @@ -102,11 +113,13 @@ Required host node properties when using function subnodes: · 21 unmodified lines | ||
| 102 | 113 | - #size-cells: should be zero. |
| 103 | 114 | |
| 104 | 115 | Required function subnode properties: |
| 105 | −- compatible: name of SDIO function following generic names recommended practice | |
| 106 | 116 | - reg: Must contain the SDIO function number of the function this subnode |
| 107 | 117 | describes. A value of 0 denotes the memory SD function, values from |
| 108 | 118 | 1 to 7 denote the SDIO functions. |
| 109 | 119 | |
| 120 | +Optional function subnode properties: | |
| 121 | +- compatible: name of SDIO function following generic names recommended practice | |
| 122 | + | |
| 110 | 123 | |
| 111 | 124 | Examples |
| 112 | 125 | -------- |
| @@ -10,7 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | subsystem (mmcss) inside the FlashSS (available in STiH407 SoC |
| 11 | 11 | family). |
| 12 | 12 | |
| 13 | −- clock-names: Should be "mmc". | |
| 13 | +- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory) | |
| 14 | 14 | See: Documentation/devicetree/bindings/resource-names.txt |
| 15 | 15 | - clocks: Phandle to the clock. |
| 16 | 16 | See: Documentation/devicetree/bindings/clock/clock-bindings.txt |
| @@ -8,7 +8,12 @@ as the speed of SD standard 3.0. · 7 unmodified lines | ||
| 8 | 8 | Absolute maximum transfer rate is 200MB/s |
| 9 | 9 | |
| 10 | 10 | Required properties: |
| 11 | − - compatible : "allwinner,sun4i-a10-mmc" or "allwinner,sun5i-a13-mmc" | |
| 11 | + - compatible : should be one of: | |
| 12 | + * "allwinner,sun4i-a10-mmc" | |
| 13 | + * "allwinner,sun5i-a13-mmc" | |
| 14 | + * "allwinner,sun7i-a20-mmc" | |
| 15 | + * "allwinner,sun9i-a80-mmc" | |
| 16 | + * "allwinner,sun50i-a64-mmc" | |
| 12 | 17 | - reg : mmc controller base registers |
| 13 | 18 | - clocks : a list with 4 phandle + clock specifier pairs |
| 14 | 19 | - clock-names : must contain "ahb", "mmc", "output" and "sample" |
| @@ -39,6 +39,10 @@ Required Properties: · 38 unmodified lines | ||
| 39 | 39 | |
| 40 | 40 | Optional properties: |
| 41 | 41 | |
| 42 | +* resets: phandle + reset specifier pair, intended to represent hardware | |
| 43 | + reset signal present internally in some host controller IC designs. | |
| 44 | + See Documentation/devicetree/bindings/reset/reset.txt for details. | |
| 45 | + | |
| 42 | 46 | * clocks: from common clock binding: handle to biu and ciu clocks for the |
| 43 | 47 | bus interface unit clock and the card interface unit clock. |
| 44 | 48 | |
| @@ -23,6 +23,7 @@ Required properties: · 22 unmodified lines | ||
| 23 | 23 | "renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC |
| 24 | 24 | "renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC |
| 25 | 25 | "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC |
| 26 | + "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC | |
| 26 | 27 | |
| 27 | 28 | Optional properties: |
| 28 | 29 | - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable |
| @@ -35,6 +35,15 @@ Optional NAND chip properties: · 34 unmodified lines | ||
| 35 | 35 | - nand-ecc-step-size: integer representing the number of data bytes |
| 36 | 36 | that are covered by a single ECC step. |
| 37 | 37 | |
| 38 | +- nand-ecc-maximize: boolean used to specify that you want to maximize ECC | |
| 39 | + strength. The maximum ECC strength is both controller and | |
| 40 | + chip dependent. The controller side has to select the ECC | |
| 41 | + config providing the best strength and taking the OOB area | |
| 42 | + size constraint into account. | |
| 43 | + This is particularly useful when only the in-band area is | |
| 44 | + used by the upper layers, and you want to make your NAND | |
| 45 | + as reliable as possible. | |
| 46 | + | |
| 38 | 47 | The ECC strength and ECC step size properties define the correction capability |
| 39 | 48 | of a controller. Together, they say a controller can correct "{strength} bit |
| 40 | 49 | errors per {size} bytes". |
| @@ -47,6 +47,9 @@ Optional properties: · 46 unmodified lines | ||
| 47 | 47 | Valid values are between 0 to 7, that maps to |
| 48 | 48 | 273, 589, 899, 1222, 1480, 1806, 2147, 2464 ps |
| 49 | 49 | Default value is 2, which corresponds to 899 ps |
| 50 | +- rxlos-gpios: Input gpio from SFP+ module to indicate availability of | |
| 51 | + incoming signal. | |
| 52 | + | |
| 50 | 53 | |
| 51 | 54 | Example: |
| 52 | 55 | menetclk: menetclk { |
| @@ -0,0 +1,24 @@ | ||
| 1 | +Broadcom AMAC Ethernet Controller Device Tree Bindings | |
| 2 | +------------------------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + - compatible: "brcm,amac" or "brcm,nsp-amac" | |
| 6 | + - reg: Address and length of the GMAC registers, | |
| 7 | + Address and length of the GMAC IDM registers | |
| 8 | + - reg-names: Names of the registers. Must have both "amac_base" and | |
| 9 | + "idm_base" | |
| 10 | + - interrupts: Interrupt number | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- mac-address: See ethernet.txt file in the same directory | |
| 14 | + | |
| 15 | +Examples: | |
| 16 | + | |
| 17 | +amac0: ethernet@18022000 { | |
| 18 | + compatible = "brcm,nsp-amac"; | |
| 19 | + reg = <0x18022000 0x1000>, | |
| 20 | + <0x18110000 0x1000>; | |
| 21 | + reg-names = "amac_base", "idm_base"; | |
| 22 | + interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>; | |
| 23 | + status = "disabled"; | |
| 24 | +}; | |
| @@ -6,9 +6,13 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - reg: addresses and length of the register sets for the device, must be 6 |
| 7 | 7 | pairs of register addresses and lengths |
| 8 | 8 | - interrupts: interrupts for the devices, must be two interrupts |
| 9 | +- #address-cells: must be 1, see dsa/dsa.txt | |
| 10 | +- #size-cells: must be 0, see dsa/dsa.txt | |
| 11 | + | |
| 12 | +Deprecated binding required properties: | |
| 13 | + | |
| 9 | 14 | - dsa,mii-bus: phandle to the MDIO bus controller, see dsa/dsa.txt |
| 10 | 15 | - dsa,ethernet: phandle to the CPU network interface controller, see dsa/dsa.txt |
| 11 | −- #size-cells: must be 0 | |
| 12 | 16 | - #address-cells: must be 2, see dsa/dsa.txt |
| 13 | 17 | |
| 14 | 18 | Subnodes: |
| @@ -39,6 +43,45 @@ Optional properties: · 24 unmodified lines | ||
| 39 | 43 | |
| 40 | 44 | Example: |
| 41 | 45 | |
| 46 | +switch_top@f0b00000 { | |
| 47 | + compatible = "simple-bus"; | |
| 48 | + #size-cells = <1>; | |
| 49 | + #address-cells = <1>; | |
| 50 | + ranges = <0 0xf0b00000 0x40804>; | |
| 51 | + | |
| 52 | + ethernet_switch@0 { | |
| 53 | + compatible = "brcm,bcm7445-switch-v4.0"; | |
| 54 | + #size-cells = <0>; | |
| 55 | + #address-cells = <1>; | |
| 56 | + reg = <0x0 0x40000 | |
| 57 | + 0x40000 0x110 | |
| 58 | + 0x40340 0x30 | |
| 59 | + 0x40380 0x30 | |
| 60 | + 0x40400 0x34 | |
| 61 | + 0x40600 0x208>; | |
| 62 | + reg-names = "core", "reg", intrl2_0", "intrl2_1", | |
| 63 | + "fcb, "acb"; | |
| 64 | + interrupts = <0 0x18 0 | |
| 65 | + 0 0x19 0>; | |
| 66 | + brcm,num-gphy = <1>; | |
| 67 | + brcm,num-rgmii-ports = <2>; | |
| 68 | + brcm,fcb-pause-override; | |
| 69 | + brcm,acb-packets-inflight; | |
| 70 | + | |
| 71 | + ports { | |
| 72 | + #address-cells = <1>; | |
| 73 | + #size-cells = <0>; | |
| 74 | + | |
| 75 | + port@0 { | |
| 76 | + label = "gphy"; | |
| 77 | + reg = <0>; | |
| 78 | + }; | |
| 79 | + }; | |
| 80 | + }; | |
| 81 | +}; | |
| 82 | + | |
| 83 | +Example using the old DSA DeviceTree binding: | |
| 84 | + | |
| 42 | 85 | switch_top@f0b00000 { |
| 43 | 86 | compatible = "simple-bus"; |
| 44 | 87 | #size-cells = <1>; |
| @@ -0,0 +1,24 @@ | ||
| 1 | +Broadcom GMAC Ethernet Controller Device Tree Bindings | |
| 2 | +------------------------------------------------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + - compatible: "brcm,bgmac-nsp" | |
| 6 | + - reg: Address and length of the GMAC registers, | |
| 7 | + Address and length of the GMAC IDM registers | |
| 8 | + - reg-names: Names of the registers. Must have both "gmac_base" and | |
| 9 | + "idm_base" | |
| 10 | + - interrupts: Interrupt number | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- mac-address: See ethernet.txt file in the same directory | |
| 14 | + | |
| 15 | +Examples: | |
| 16 | + | |
| 17 | +gmac0: ethernet@18022000 { | |
| 18 | + compatible = "brcm,bgmac-nsp"; | |
| 19 | + reg = <0x18022000 0x1000>, | |
| 20 | + <0x18110000 0x1000>; | |
| 21 | + reg-names = "gmac_base", "idm_base"; | |
| 22 | + interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>; | |
| 23 | + status = "disabled"; | |
| 24 | +}; | |
| @@ -0,0 +1,89 @@ | ||
| 1 | +* Qualcomm Atheros QCA8xxx switch family | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: should be "qca,qca8337" | |
| 6 | +- #size-cells: must be 0 | |
| 7 | +- #address-cells: must be 1 | |
| 8 | + | |
| 9 | +Subnodes: | |
| 10 | + | |
| 11 | +The integrated switch subnode should be specified according to the binding | |
| 12 | +described in dsa/dsa.txt. As the QCA8K switches do not have a N:N mapping of | |
| 13 | +port and PHY id, each subnode describing a port needs to have a valid phandle | |
| 14 | +referencing the internal PHY connected to it. The CPU port of this switch is | |
| 15 | +always port 0. | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + | |
| 20 | + &mdio0 { | |
| 21 | + phy_port1: phy@0 { | |
| 22 | + reg = <0>; | |
| 23 | + }; | |
| 24 | + | |
| 25 | + phy_port2: phy@1 { | |
| 26 | + reg = <1>; | |
| 27 | + }; | |
| 28 | + | |
| 29 | + phy_port3: phy@2 { | |
| 30 | + reg = <2>; | |
| 31 | + }; | |
| 32 | + | |
| 33 | + phy_port4: phy@3 { | |
| 34 | + reg = <3>; | |
| 35 | + }; | |
| 36 | + | |
| 37 | + phy_port5: phy@4 { | |
| 38 | + reg = <4>; | |
| 39 | + }; | |
| 40 | + | |
| 41 | + switch0@0 { | |
| 42 | + compatible = "qca,qca8337"; | |
| 43 | + #address-cells = <1>; | |
| 44 | + #size-cells = <0>; | |
| 45 | + | |
| 46 | + reg = <0>; | |
| 47 | + | |
| 48 | + ports { | |
| 49 | + #address-cells = <1>; | |
| 50 | + #size-cells = <0>; | |
| 51 | + port@0 { | |
| 52 | + reg = <0>; | |
| 53 | + label = "cpu"; | |
| 54 | + ethernet = <&gmac1>; | |
| 55 | + phy-mode = "rgmii"; | |
| 56 | + }; | |
| 57 | + | |
| 58 | + port@1 { | |
| 59 | + reg = <1>; | |
| 60 | + label = "lan1"; | |
| 61 | + phy-handle = <&phy_port1>; | |
| 62 | + }; | |
| 63 | + | |
| 64 | + port@2 { | |
| 65 | + reg = <2>; | |
| 66 | + label = "lan2"; | |
| 67 | + phy-handle = <&phy_port2>; | |
| 68 | + }; | |
| 69 | + | |
| 70 | + port@3 { | |
| 71 | + reg = <3>; | |
| 72 | + label = "lan3"; | |
| 73 | + phy-handle = <&phy_port3>; | |
| 74 | + }; | |
| 75 | + | |
| 76 | + port@4 { | |
| 77 | + reg = <4>; | |
| 78 | + label = "lan4"; | |
| 79 | + phy-handle = <&phy_port4>; | |
| 80 | + }; | |
| 81 | + | |
| 82 | + port@5 { | |
| 83 | + reg = <5>; | |
| 84 | + label = "wan"; | |
| 85 | + phy-handle = <&phy_port5>; | |
| 86 | + }; | |
| 87 | + }; | |
| 88 | + }; | |
| 89 | + }; | |
| @@ -11,8 +11,8 @@ The following properties are common to the Ethernet controllers: · 10 unmodified lines | ||
| 11 | 11 | the maximum frame size (there's contradiction in ePAPR). |
| 12 | 12 | - phy-mode: string, operation mode of the PHY interface; supported values are |
| 13 | 13 | "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", |
| 14 | − "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto | |
| 15 | − standard property; | |
| 14 | + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii", "trgmii"; this is now a | |
| 15 | + de-facto standard property; | |
| 16 | 16 | - phy-connection-type: the same as "phy-mode" property but described in ePAPR; |
| 17 | 17 | - phy-handle: phandle, specifies a reference to a node representing a PHY |
| 18 | 18 | device; this property is described in ePAPR and so preferred; |
| @@ -21,6 +21,7 @@ Required properties: · 20 unmodified lines | ||
| 21 | 21 | - clock-names: Tuple listing input clock names. |
| 22 | 22 | Required elements: 'pclk', 'hclk' |
| 23 | 23 | Optional elements: 'tx_clk' |
| 24 | + Optional elements: 'rx_clk' applies to cdns,zynqmp-gem | |
| 24 | 25 | - clocks: Phandles to input clocks. |
| 25 | 26 | |
| 26 | 27 | Optional properties for PHY child node: |
| @@ -25,13 +25,15 @@ Optional properties: · 24 unmodified lines | ||
| 25 | 25 | - interrupt-parent: Should be the phandle for the interrupt controller |
| 26 | 26 | that services interrupts for this device |
| 27 | 27 | |
| 28 | − | |
| 29 | 28 | * Ethernet MAC node |
| 30 | 29 | |
| 31 | 30 | Required properties: |
| 32 | 31 | - compatible: Should be "mediatek,eth-mac" |
| 33 | 32 | - reg: The number of the MAC |
| 34 | −- phy-handle: see ethernet.txt file in the same directory. | |
| 33 | +- phy-handle: see ethernet.txt file in the same directory and | |
| 34 | + the phy-mode "trgmii" required being provided when reg | |
| 35 | + is equal to 0 and the MAC uses fixed-link to connect | |
| 36 | + with internal switch such as MT7530. | |
| 35 | 37 | |
| 36 | 38 | Example: |
| 37 | 39 | |
| @@ -1,18 +1,32 @@ | ||
| 1 | 1 | * Amlogic Meson DWMAC Ethernet controller |
| 2 | 2 | |
| 3 | 3 | The device inherits all the properties of the dwmac/stmmac devices |
| 4 | −described in the file net/stmmac.txt with the following changes. | |
| 4 | +described in the file stmmac.txt in the current directory with the | |
| 5 | +following changes. | |
| 5 | 6 | |
| 6 | −Required properties: | |
| 7 | +Required properties on all platforms: | |
| 7 | 8 | |
| 8 | −- compatible: should be "amlogic,meson6-dwmac" along with "snps,dwmac" | |
| 9 | − and any applicable more detailed version number | |
| 10 | − described in net/stmmac.txt | |
| 9 | +- compatible: Depending on the platform this should be one of: | |
| 10 | + - "amlogic,meson6-dwmac" | |
| 11 | + - "amlogic,meson8b-dwmac" | |
| 12 | + - "amlogic,meson-gxbb-dwmac" | |
| 13 | + Additionally "snps,dwmac" and any applicable more | |
| 14 | + detailed version number described in net/stmmac.txt | |
| 15 | + should be used. | |
| 11 | 16 | |
| 12 | −- reg: should contain a register range for the dwmac controller and | |
| 13 | − another one for the Amlogic specific configuration | |
| 17 | +- reg: The first register range should be the one of the DWMAC | |
| 18 | + controller. The second range is is for the Amlogic specific | |
| 19 | + configuration (for example the PRG_ETHERNET register range | |
| 20 | + on Meson8b and newer) | |
| 14 | 21 | |
| 15 | −Example: | |
| 22 | +Required properties on Meson8b and newer: | |
| 23 | +- clock-names: Should contain the following: | |
| 24 | + - "stmmaceth" - see stmmac.txt | |
| 25 | + - "clkin0" - first parent clock of the internal mux | |
| 26 | + - "clkin1" - second parent clock of the internal mux | |
| 27 | + | |
| 28 | + | |
| 29 | +Example for Meson6: | |
| 16 | 30 | |
| 17 | 31 | ethmac: ethernet@c9410000 { |
| 18 | 32 | compatible = "amlogic,meson6-dwmac", "snps,dwmac"; |
| @@ -23,3 +37,18 @@ Example: · 4 unmodified lines | ||
| 23 | 37 | clocks = <&clk81>; |
| 24 | 38 | clock-names = "stmmaceth"; |
| 25 | 39 | } |
| 40 | + | |
| 41 | +Example for GXBB: | |
| 42 | + ethmac: ethernet@c9410000 { | |
| 43 | + compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac"; | |
| 44 | + reg = <0x0 0xc9410000 0x0 0x10000>, | |
| 45 | + <0x0 0xc8834540 0x0 0x8>; | |
| 46 | + interrupts = <0 8 1>; | |
| 47 | + interrupt-names = "macirq"; | |
| 48 | + clocks = <&clkc CLKID_ETH>, | |
| 49 | + <&clkc CLKID_FCLK_DIV2>, | |
| 50 | + <&clkc CLKID_MPLL2>; | |
| 51 | + clock-names = "stmmaceth", "clkin0", "clkin1"; | |
| 52 | + phy-mode = "rgmii"; | |
| 53 | + status = "disabled"; | |
| 54 | + }; | |
| @@ -34,16 +34,17 @@ KSZ9031: · 33 unmodified lines | ||
| 34 | 34 | |
| 35 | 35 | All skew control options are specified in picoseconds. The minimum |
| 36 | 36 | value is 0, and the maximum is property-dependent. The increment |
| 37 | − step is 60ps. | |
| 37 | + step is 60ps. The default value is the neutral setting, so setting | |
| 38 | + rxc-skew-ps=<0> actually results in -900 picoseconds adjustment. | |
| 38 | 39 | |
| 39 | 40 | Optional properties: |
| 40 | 41 | |
| 41 | − Maximum value of 1860: | |
| 42 | + Maximum value of 1860, default value 900: | |
| 42 | 43 | |
| 43 | 44 | - rxc-skew-ps : Skew control of RX clock pad |
| 44 | 45 | - txc-skew-ps : Skew control of TX clock pad |
| 45 | 46 | |
| 46 | − Maximum value of 900: | |
| 47 | + Maximum value of 900, default value 420: | |
| 47 | 48 | |
| 48 | 49 | - rxdv-skew-ps : Skew control of RX CTL pad |
| 49 | 50 | - txen-skew-ps : Skew control of TX CTL pad |
| @@ -0,0 +1,58 @@ | ||
| 1 | +* Microsemi - vsc8531 Giga bit ethernet phy | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : Should contain phy id as "ethernet-phy-idAAAA.BBBB" | |
| 5 | + The PHY device uses the binding described in | |
| 6 | + Documentation/devicetree/bindings/net/phy.txt | |
| 7 | + | |
| 8 | +Optional properties: | |
| 9 | +- vsc8531,vddmac : The vddmac in mV. | |
| 10 | +- vsc8531,edge-slowdown : % the edge should be slowed down relative to | |
| 11 | + the fastest possible edge time. Native sign | |
| 12 | + need not enter. | |
| 13 | + Edge rate sets the drive strength of the MAC | |
| 14 | + interface output signals. Changing the drive | |
| 15 | + strength will affect the edge rate of the output | |
| 16 | + signal. The goal of this setting is to help | |
| 17 | + reduce electrical emission (EMI) by being able | |
| 18 | + to reprogram drive strength and in effect slow | |
| 19 | + down the edge rate if desired. Table 1 shows the | |
| 20 | + impact to the edge rate per VDDMAC supply for each | |
| 21 | + drive strength setting. | |
| 22 | + Ref: Table:1 - Edge rate change below. | |
| 23 | + | |
| 24 | +Note: see dt-bindings/net/mscc-phy-vsc8531.h for applicable values | |
| 25 | + | |
| 26 | +Table: 1 - Edge rate change | |
| 27 | +----------------------------------------------------------------| | |
| 28 | +| Edge Rate Change (VDDMAC) | | |
| 29 | +| | | |
| 30 | +| 3300 mV 2500 mV 1800 mV 1500 mV | | |
| 31 | +|---------------------------------------------------------------| | |
| 32 | +| Default Deafult Default Default | | |
| 33 | +| (Fastest) (recommended) (recommended) | | |
| 34 | +|---------------------------------------------------------------| | |
| 35 | +| -2% -3% -5% -6% | | |
| 36 | +|---------------------------------------------------------------| | |
| 37 | +| -4% -6% -9% -14% | | |
| 38 | +|---------------------------------------------------------------| | |
| 39 | +| -7% -10% -16% -21% | | |
| 40 | +|(recommended) (recommended) | | |
| 41 | +|---------------------------------------------------------------| | |
| 42 | +| -10% -14% -23% -29% | | |
| 43 | +|---------------------------------------------------------------| | |
| 44 | +| -17% -23% -35% -42% | | |
| 45 | +|---------------------------------------------------------------| | |
| 46 | +| -29% -37% -52% -58% | | |
| 47 | +|---------------------------------------------------------------| | |
| 48 | +| -53% -63% -76% -77% | | |
| 49 | +| (slowest) | | |
| 50 | +|---------------------------------------------------------------| | |
| 51 | + | |
| 52 | +Example: | |
| 53 | + | |
| 54 | + vsc8531_0: ethernet-phy@0 { | |
| 55 | + compatible = "ethernet-phy-id0007.0570"; | |
| 56 | + vsc8531,vddmac = <3300>; | |
| 57 | + vsc8531,edge-slowdown = <21>; | |
| 58 | + }; | |
| @@ -0,0 +1,111 @@ | ||
| 1 | +Qualcomm Technologies EMAC Gigabit Ethernet Controller | |
| 2 | + | |
| 3 | +This network controller consists of two devices: a MAC and an SGMII | |
| 4 | +internal PHY. Each device is represented by a device tree node. A phandle | |
| 5 | +connects the MAC node to its corresponding internal phy node. Another | |
| 6 | +phandle points to the external PHY node. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | + | |
| 10 | +MAC node: | |
| 11 | +- compatible : Should be "qcom,fsm9900-emac". | |
| 12 | +- reg : Offset and length of the register regions for the device | |
| 13 | +- interrupts : Interrupt number used by this controller | |
| 14 | +- mac-address : The 6-byte MAC address. If present, it is the default | |
| 15 | + MAC address. | |
| 16 | +- internal-phy : phandle to the internal PHY node | |
| 17 | +- phy-handle : phandle the the external PHY node | |
| 18 | + | |
| 19 | +Internal PHY node: | |
| 20 | +- compatible : Should be "qcom,fsm9900-emac-sgmii" or "qcom,qdf2432-emac-sgmii". | |
| 21 | +- reg : Offset and length of the register region(s) for the device | |
| 22 | +- interrupts : Interrupt number used by this controller | |
| 23 | + | |
| 24 | +The external phy child node: | |
| 25 | +- reg : The phy address | |
| 26 | + | |
| 27 | +Example: | |
| 28 | + | |
| 29 | +FSM9900: | |
| 30 | + | |
| 31 | +soc { | |
| 32 | + #address-cells = <1>; | |
| 33 | + #size-cells = <1>; | |
| 34 | + | |
| 35 | + emac0: ethernet@feb20000 { | |
| 36 | + compatible = "qcom,fsm9900-emac"; | |
| 37 | + reg = <0xfeb20000 0x10000>, | |
| 38 | + <0xfeb36000 0x1000>; | |
| 39 | + interrupts = <76>; | |
| 40 | + | |
| 41 | + clocks = <&gcc 0>, <&gcc 1>, <&gcc 3>, <&gcc 4>, <&gcc 5>, | |
| 42 | + <&gcc 6>, <&gcc 7>; | |
| 43 | + clock-names = "axi_clk", "cfg_ahb_clk", "high_speed_clk", | |
| 44 | + "mdio_clk", "tx_clk", "rx_clk", "sys_clk"; | |
| 45 | + | |
| 46 | + internal-phy = <&emac_sgmii>; | |
| 47 | + | |
| 48 | + phy-handle = <&phy0>; | |
| 49 | + | |
| 50 | + #address-cells = <1>; | |
| 51 | + #size-cells = <0>; | |
| 52 | + phy0: ethernet-phy@0 { | |
| 53 | + reg = <0>; | |
| 54 | + }; | |
| 55 | + | |
| 56 | + pinctrl-names = "default"; | |
| 57 | + pinctrl-0 = <&mdio_pins_a>; | |
| 58 | + }; | |
| 59 | + | |
| 60 | + emac_sgmii: ethernet@feb38000 { | |
| 61 | + compatible = "qcom,fsm9900-emac-sgmii"; | |
| 62 | + reg = <0xfeb38000 0x1000>; | |
| 63 | + interrupts = <80>; | |
| 64 | + }; | |
| 65 | + | |
| 66 | + tlmm: pinctrl@fd510000 { | |
| 67 | + compatible = "qcom,fsm9900-pinctrl"; | |
| 68 | + | |
| 69 | + mdio_pins_a: mdio { | |
| 70 | + state { | |
| 71 | + pins = "gpio123", "gpio124"; | |
| 72 | + function = "mdio"; | |
| 73 | + }; | |
| 74 | + }; | |
| 75 | + }; | |
| 76 | + | |
| 77 | + | |
| 78 | +QDF2432: | |
| 79 | + | |
| 80 | +soc { | |
| 81 | + #address-cells = <2>; | |
| 82 | + #size-cells = <2>; | |
| 83 | + | |
| 84 | + emac0: ethernet@38800000 { | |
| 85 | + compatible = "qcom,fsm9900-emac"; | |
| 86 | + reg = <0x0 0x38800000 0x0 0x10000>, | |
| 87 | + <0x0 0x38816000 0x0 0x1000>; | |
| 88 | + interrupts = <0 256 4>; | |
| 89 | + | |
| 90 | + clocks = <&gcc 0>, <&gcc 1>, <&gcc 3>, <&gcc 4>, <&gcc 5>, | |
| 91 | + <&gcc 6>, <&gcc 7>; | |
| 92 | + clock-names = "axi_clk", "cfg_ahb_clk", "high_speed_clk", | |
| 93 | + "mdio_clk", "tx_clk", "rx_clk", "sys_clk"; | |
| 94 | + | |
| 95 | + internal-phy = <&emac_sgmii>; | |
| 96 | + | |
| 97 | + phy-handle = <&phy0>; | |
| 98 | + | |
| 99 | + #address-cells = <1>; | |
| 100 | + #size-cells = <0>; | |
| 101 | + phy0: ethernet-phy@4 { | |
| 102 | + reg = <4>; | |
| 103 | + }; | |
| 104 | + }; | |
| 105 | + | |
| 106 | + emac_sgmii: ethernet@410400 { | |
| 107 | + compatible = "qcom,qdf2432-emac-sgmii"; | |
| 108 | + reg = <0x0 0x00410400 0x0 0xc00>, /* Base address */ | |
| 109 | + <0x0 0x00410000 0x0 0x400>; /* Per-lane digital */ | |
| 110 | + interrupts = <0 254 1>; | |
| 111 | + }; | |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC. |
| 11 | 11 | "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC. |
| 12 | 12 | "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC. |
| 13 | + "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC. | |
| 13 | 14 | "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible interface. |
| 14 | 15 | "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible interface. |
| 15 | 16 | |
| @@ -33,7 +34,7 @@ Optional properties: · 17 unmodified lines | ||
| 33 | 34 | - interrupt-parent: the phandle for the interrupt controller that services |
| 34 | 35 | interrupts for this device. |
| 35 | 36 | - interrupt-names: A list of interrupt names. |
| 36 | − For the R8A7795 SoC this property is mandatory; | |
| 37 | + For the R8A779[56] SoCs this property is mandatory; | |
| 37 | 38 | it should include one entry per channel, named "ch%u", |
| 38 | 39 | where %u is the channel number ranging from 0 to 24. |
| 39 | 40 | For other SoCs this property is optional; if present |
| @@ -3,8 +3,12 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC) · 2 unmodified lines | ||
| 3 | 3 | The device node has following properties. |
| 4 | 4 | |
| 5 | 5 | Required properties: |
| 6 | − - compatible: Can be one of "rockchip,rk3228-gmac", "rockchip,rk3288-gmac", | |
| 7 | − "rockchip,rk3368-gmac" | |
| 6 | + - compatible: should be "rockchip,<name>-gamc" | |
| 7 | + "rockchip,rk3228-gmac": found on RK322x SoCs | |
| 8 | + "rockchip,rk3288-gmac": found on RK3288 SoCs | |
| 9 | + "rockchip,rk3366-gmac": found on RK3366 SoCs | |
| 10 | + "rockchip,rk3368-gmac": found on RK3368 SoCs | |
| 11 | + "rockchip,rk3399-gmac": found on RK3399 SoCs | |
| 8 | 12 | - reg: addresses and length of the register sets for the device. |
| 9 | 13 | - interrupts: Should contain the GMAC interrupts. |
| 10 | 14 | - interrupt-names: Should contain the interrupt names "macirq". |
| @@ -5,6 +5,8 @@ interface contains. · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC. |
| 8 | + "renesas,ether-r8a7743" if the device is a part of R8A7743 SoC. | |
| 9 | + "renesas,ether-r8a7745" if the device is a part of R8A7745 SoC. | |
| 8 | 10 | "renesas,ether-r8a7778" if the device is a part of R8A7778 SoC. |
| 9 | 11 | "renesas,ether-r8a7779" if the device is a part of R8A7779 SoC. |
| 10 | 12 | "renesas,ether-r8a7790" if the device is a part of R8A7790 SoC. |
| @@ -3,9 +3,11 @@ · 2 unmodified lines | ||
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible : Should be "smsc,lan<model>", "smsc,lan9115" |
| 5 | 5 | - reg : Address and length of the io space for SMSC LAN |
| 6 | −- interrupts : Should contain SMSC LAN interrupt line | |
| 7 | −- interrupt-parent : Should be the phandle for the interrupt controller | |
| 8 | − that services interrupts for this device | |
| 6 | +- interrupts : one or two interrupt specifiers | |
| 7 | + - The first interrupt is the SMSC LAN interrupt line | |
| 8 | + - The second interrupt (if present) is the PME (power | |
| 9 | + management event) interrupt that is able to wake up the host | |
| 10 | + system with a 50ms pulse on network activity | |
| 9 | 11 | - phy-mode : See ethernet.txt file in the same directory |
| 10 | 12 | |
| 11 | 13 | Optional properties: |
| @@ -21,6 +23,10 @@ Optional properties: · 9 unmodified lines | ||
| 21 | 23 | external PHY |
| 22 | 24 | - smsc,save-mac-address : Indicates that mac address needs to be saved |
| 23 | 25 | before resetting the controller |
| 26 | +- reset-gpios : a GPIO line connected to the RESET (active low) signal | |
| 27 | + of the device. On many systems this is wired high so the device goes | |
| 28 | + out of reset at power-on, but if it is under program control, this | |
| 29 | + optional GPIO can wake up in response to it. | |
| 24 | 30 | |
| 25 | 31 | Examples: |
| 26 | 32 | |
| @@ -29,7 +35,8 @@ lan9220@f4000000 { · 2 unmodified lines | ||
| 29 | 35 | reg = <0xf4000000 0x2000000>; |
| 30 | 36 | phy-mode = "mii"; |
| 31 | 37 | interrupt-parent = <&gpio1>; |
| 32 | − interrupts = <31>; | |
| 38 | + interrupts = <31>, <32>; | |
| 39 | + reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>; | |
| 33 | 40 | reg-io-width = <4>; |
| 34 | 41 | smsc,irq-push-pull; |
| 35 | 42 | }; |
| @@ -1,21 +1,111 @@ | ||
| 1 | 1 | * Synopsys DWC Ethernet QoS IP version 4.10 driver (GMAC) |
| 2 | 2 | |
| 3 | +This binding supports the Synopsys Designware Ethernet QoS (Quality Of Service) | |
| 4 | +IP block. The IP supports multiple options for bus type, clocking and reset | |
| 5 | +structure, and feature list. Consequently, a number of properties and list | |
| 6 | +entries in properties are marked as optional, or only required in specific HW | |
| 7 | +configurations. | |
| 3 | 8 | |
| 4 | 9 | Required properties: |
| 5 | −- compatible: Should be "snps,dwc-qos-ethernet-4.10" | |
| 10 | +- compatible: One of: | |
| 11 | + - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10" | |
| 12 | + Represents the IP core when integrated into the Axis ARTPEC-6 SoC. | |
| 13 | + - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10" | |
| 14 | + Represents the IP core when integrated into the NVIDIA Tegra186 SoC. | |
| 15 | + - "snps,dwc-qos-ethernet-4.10" | |
| 16 | + This combination is deprecated. It should be treated as equivalent to | |
| 17 | + "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10". It is supported to be | |
| 18 | + compatible with earlier revisions of this binding. | |
| 6 | 19 | - reg: Address and length of the register set for the device |
| 7 | −- clocks: Phandles to the reference clock and the bus clock | |
| 8 | −- clock-names: Should be "phy_ref_clk" for the reference clock and "apb_pclk" | |
| 9 | − for the bus clock. | |
| 20 | +- clocks: Phandle and clock specifiers for each entry in clock-names, in the | |
| 21 | + same order. See ../clock/clock-bindings.txt. | |
| 22 | +- clock-names: May contain any/all of the following depending on the IP | |
| 23 | + configuration, in any order: | |
| 24 | + - "tx" | |
| 25 | + The EQOS transmit path clock. The HW signal name is clk_tx_i. | |
| 26 | + In some configurations (e.g. GMII/RGMII), this clock also drives the PHY TX | |
| 27 | + path. In other configurations, other clocks (such as tx_125, rmii) may | |
| 28 | + drive the PHY TX path. | |
| 29 | + - "rx" | |
| 30 | + The EQOS receive path clock. The HW signal name is clk_rx_i. | |
| 31 | + In some configurations (e.g. GMII/RGMII), this clock is derived from the | |
| 32 | + PHY's RX clock output. In other configurations, other clocks (such as | |
| 33 | + rx_125, rmii) may drive the EQOS RX path. | |
| 34 | + In cases where the PHY clock is directly fed into the EQOS receive path | |
| 35 | + without intervening logic, the DT need not represent this clock, since it | |
| 36 | + is assumed to be fully under the control of the PHY device/driver. In | |
| 37 | + cases where SoC integration adds additional logic to this path, such as a | |
| 38 | + SW-controlled clock gate, this clock should be represented in DT. | |
| 39 | + - "slave_bus" | |
| 40 | + The CPU/slave-bus (CSR) interface clock. This applies to any bus type; | |
| 41 | + APB, AHB, AXI, etc. The HW signal name is hclk_i (AHB) or clk_csr_i (other | |
| 42 | + buses). | |
| 43 | + - "master_bus" | |
| 44 | + The master bus interface clock. Only required in configurations that use a | |
| 45 | + separate clock for the master and slave bus interfaces. The HW signal name | |
| 46 | + is hclk_i (AHB) or aclk_i (AXI). | |
| 47 | + - "ptp_ref" | |
| 48 | + The PTP reference clock. The HW signal name is clk_ptp_ref_i. | |
| 49 | + - "phy_ref_clk" | |
| 50 | + This clock is deprecated and should not be used by new compatible values. | |
| 51 | + It is equivalent to "tx". | |
| 52 | + - "apb_pclk" | |
| 53 | + This clock is deprecated and should not be used by new compatible values. | |
| 54 | + It is equivalent to "slave_bus". | |
| 55 | + | |
| 56 | + Note: Support for additional IP configurations may require adding the | |
| 57 | + following clocks to this list in the future: clk_rx_125_i, clk_tx_125_i, | |
| 58 | + clk_pmarx_0_i, clk_pmarx1_i, clk_rmii_i, clk_revmii_rx_i, clk_revmii_tx_i. | |
| 59 | + Configurations exist where multiple similar clocks are used at once, e.g. all | |
| 60 | + of clk_rx_125_i, clk_pmarx_0_i, clk_pmarx1_i. For this reason it is best to | |
| 61 | + extend the binding with a separate clock-names entry for each of those RX | |
| 62 | + clocks, rather than repurposing the existing "rx" clock-names entry as a | |
| 63 | + generic/logical clock in a similar fashion to "master_bus" and "slave_bus". | |
| 64 | + This will allow easy support for configurations that support multiple PHY | |
| 65 | + interfaces using a mux, and hence need to have explicit control over | |
| 66 | + specific RX clocks. | |
| 67 | + | |
| 68 | + The following compatible values require the following set of clocks: | |
| 69 | + - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10": | |
| 70 | + - "slave_bus" | |
| 71 | + - "master_bus" | |
| 72 | + - "rx" | |
| 73 | + - "tx" | |
| 74 | + - "ptp_ref" | |
| 75 | + - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10": | |
| 76 | + - "slave_bus" | |
| 77 | + - "master_bus" | |
| 78 | + - "tx" | |
| 79 | + - "ptp_ref" | |
| 80 | + - "snps,dwc-qos-ethernet-4.10" (deprecated): | |
| 81 | + - "phy_ref_clk" | |
| 82 | + - "apb_clk" | |
| 10 | 83 | - interrupt-parent: Should be the phandle for the interrupt controller |
| 11 | 84 | that services interrupts for this device |
| 12 | 85 | - interrupts: Should contain the core's combined interrupt signal |
| 13 | 86 | - phy-mode: See ethernet.txt file in the same directory |
| 87 | +- resets: Phandle and reset specifiers for each entry in reset-names, in the | |
| 88 | + same order. See ../reset/reset.txt. | |
| 89 | +- reset-names: May contain any/all of the following depending on the IP | |
| 90 | + configuration, in any order: | |
| 91 | + - "eqos". The reset to the entire module. The HW signal name is hreset_n | |
| 92 | + (AHB) or aresetn_i (AXI). | |
| 93 | + | |
| 94 | + The following compatible values require the following set of resets: | |
| 95 | + (the reset properties may be omitted if empty) | |
| 96 | + - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10": | |
| 97 | + - "eqos". | |
| 98 | + - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10": | |
| 99 | + - None. | |
| 100 | + - "snps,dwc-qos-ethernet-4.10" (deprecated): | |
| 101 | + - None. | |
| 14 | 102 | |
| 15 | 103 | Optional properties: |
| 16 | 104 | - dma-coherent: Present if dma operations are coherent |
| 17 | 105 | - mac-address: See ethernet.txt in the same directory |
| 18 | 106 | - local-mac-address: See ethernet.txt in the same directory |
| 107 | +- phy-reset-gpios: Phandle and specifier for any GPIO used to reset the PHY. | |
| 108 | + See ../gpio/gpio.txt. | |
| 19 | 109 | - snps,en-lpi: If present it enables use of the AXI low-power interface |
| 20 | 110 | - snps,write-requests: Number of write requests that the AXI port can issue. |
| 21 | 111 | It depends on the SoC configuration. |
| @@ -52,6 +142,7 @@ ethernet2@40010000 { · 30 unmodified lines | ||
| 52 | 142 | reg = <0x40010000 0x4000>; |
| 53 | 143 | phy-handle = <&phy2>; |
| 54 | 144 | phy-mode = "gmii"; |
| 145 | + phy-reset-gpios = <&gpioctlr 43 GPIO_ACTIVE_LOW>; | |
| 55 | 146 | |
| 56 | 147 | snps,en-tx-lpi-clockgating; |
| 57 | 148 | snps,en-lpi; |
| @@ -0,0 +1,32 @@ | ||
| 1 | +STMicroelectronics STM32 / MCU DWMAC glue layer controller | |
| 2 | + | |
| 3 | +This file documents platform glue layer for stmmac. | |
| 4 | +Please see stmmac.txt for the other unchanged properties. | |
| 5 | + | |
| 6 | +The device node has following properties. | |
| 7 | + | |
| 8 | +Required properties: | |
| 9 | +- compatible: Should be "st,stm32-dwmac" to select glue, and | |
| 10 | + "snps,dwmac-3.50a" to select IP version. | |
| 11 | +- clocks: Must contain a phandle for each entry in clock-names. | |
| 12 | +- clock-names: Should be "stmmaceth" for the host clock. | |
| 13 | + Should be "mac-clk-tx" for the MAC TX clock. | |
| 14 | + Should be "mac-clk-rx" for the MAC RX clock. | |
| 15 | +- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which | |
| 16 | + encompases the glue register, and the offset of the control register. | |
| 17 | +Example: | |
| 18 | + | |
| 19 | + ethernet@40028000 { | |
| 20 | + compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; | |
| 21 | + status = "disabled"; | |
| 22 | + reg = <0x40028000 0x8000>; | |
| 23 | + reg-names = "stmmaceth"; | |
| 24 | + interrupts = <0 61 0>, <0 62 0>; | |
| 25 | + interrupt-names = "macirq", "eth_wake_irq"; | |
| 26 | + clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx"; | |
| 27 | + clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>; | |
| 28 | + st,syscon = <&syscfg 0x4>; | |
| 29 | + snps,pbl = <8>; | |
| 30 | + snps,mixed-burst; | |
| 31 | + dma-ranges; | |
| 32 | + }; | |
| @@ -0,0 +1,31 @@ | ||
| 1 | +Espressif ESP8089 wireless SDIO devices | |
| 2 | + | |
| 3 | +This node provides properties for controlling the ESP8089 wireless device. | |
| 4 | +The node is expected to be specified as a child node to the SDIO controller | |
| 5 | +that connects the device to the system. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | + | |
| 9 | + - compatible : Should be "esp,esp8089". | |
| 10 | + | |
| 11 | +Optional properties: | |
| 12 | + - esp,crystal-26M-en: Integer value for the crystal_26M_en firmware parameter | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | +&mmc1 { | |
| 17 | + #address-cells = <1>; | |
| 18 | + #size-cells = <0>; | |
| 19 | + | |
| 20 | + vmmc-supply = <®_dldo1>; | |
| 21 | + mmc-pwrseq = <&wifi_pwrseq>; | |
| 22 | + bus-width = <4>; | |
| 23 | + non-removable; | |
| 24 | + status = "okay"; | |
| 25 | + | |
| 26 | + esp8089: sdio_wifi@1 { | |
| 27 | + compatible = "esp,esp8089"; | |
| 28 | + reg = <1>; | |
| 29 | + esp,crystal-26M-en = <2>; | |
| 30 | + }; | |
| 31 | +}; | |
| @@ -0,0 +1,35 @@ | ||
| 1 | +XILINX GMIITORGMII Converter Driver Device Tree Bindings | |
| 2 | +-------------------------------------------------------- | |
| 3 | + | |
| 4 | +The Gigabit Media Independent Interface (GMII) to Reduced Gigabit Media | |
| 5 | +Independent Interface (RGMII) core provides the RGMII between RGMII-compliant | |
| 6 | +Ethernet physical media devices (PHY) and the Gigabit Ethernet controller. | |
| 7 | +This core can be used in all three modes of operation(10/100/1000 Mb/s). | |
| 8 | +The Management Data Input/Output (MDIO) interface is used to configure the | |
| 9 | +Speed of operation. This core can switch dynamically between the three | |
| 10 | +Different speed modes by configuring the conveter register through mdio write. | |
| 11 | + | |
| 12 | +This converter sits between the ethernet MAC and the external phy. | |
| 13 | +MAC <==> GMII2RGMII <==> RGMII_PHY | |
| 14 | + | |
| 15 | +For more details about mdio please refer phy.txt file in the same directory. | |
| 16 | + | |
| 17 | +Required properties: | |
| 18 | +- compatible : Should be "xlnx,gmii-to-rgmii-1.0" | |
| 19 | +- reg : The ID number for the phy, usually a small integer | |
| 20 | +- phy-handle : Should point to the external phy device. | |
| 21 | + See ethernet.txt file in the same directory. | |
| 22 | + | |
| 23 | +Example: | |
| 24 | + mdio { | |
| 25 | + #address-cells = <1>; | |
| 26 | + #size-cells = <0>; | |
| 27 | + phy: ethernet-phy@0 { | |
| 28 | + ...... | |
| 29 | + }; | |
| 30 | + gmiitorgmii: gmiitorgmii@8 { | |
| 31 | + compatible = "xlnx,gmii-to-rgmii-1.0"; | |
| 32 | + reg = <8>; | |
| 33 | + phy-handle = <&phy>; | |
| 34 | + }; | |
| 35 | + }; | |
| @@ -0,0 +1,39 @@ | ||
| 1 | += Amlogic eFuse device tree bindings = | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should be "amlogic,meson-gxbb-efuse" | |
| 5 | + | |
| 6 | += Data cells = | |
| 7 | +Are child nodes of eFuse, bindings of which as described in | |
| 8 | +bindings/nvmem/nvmem.txt | |
| 9 | + | |
| 10 | +Example: | |
| 11 | + | |
| 12 | + efuse: efuse { | |
| 13 | + compatible = "amlogic,meson-gxbb-efuse"; | |
| 14 | + #address-cells = <1>; | |
| 15 | + #size-cells = <1>; | |
| 16 | + | |
| 17 | + sn: sn@14 { | |
| 18 | + reg = <0x14 0x10>; | |
| 19 | + }; | |
| 20 | + | |
| 21 | + eth_mac: eth_mac@34 { | |
| 22 | + reg = <0x34 0x10>; | |
| 23 | + }; | |
| 24 | + | |
| 25 | + bid: bid@46 { | |
| 26 | + reg = <0x46 0x30>; | |
| 27 | + }; | |
| 28 | + }; | |
| 29 | + | |
| 30 | += Data consumers = | |
| 31 | +Are device nodes which consume nvmem data cells. | |
| 32 | + | |
| 33 | +For example: | |
| 34 | + | |
| 35 | + eth_mac { | |
| 36 | + ... | |
| 37 | + nvmem-cells = <ð_mac>; | |
| 38 | + nvmem-cell-names = "eth_mac"; | |
| 39 | + }; | |
| @@ -1,11 +1,20 @@ | ||
| 1 | 1 | = Rockchip eFuse device tree bindings = |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- compatible: Should be "rockchip,rockchip-efuse" | |
| 4 | +- compatible: Should be one of the following. | |
| 5 | + - "rockchip,rk3066a-efuse" - for RK3066a SoCs. | |
| 6 | + - "rockchip,rk3188-efuse" - for RK3188 SoCs. | |
| 7 | + - "rockchip,rk3288-efuse" - for RK3288 SoCs. | |
| 8 | + - "rockchip,rk3399-efuse" - for RK3399 SoCs. | |
| 5 | 9 | - reg: Should contain the registers location and exact eFuse size |
| 6 | 10 | - clocks: Should be the clock id of eFuse |
| 7 | 11 | - clock-names: Should be "pclk_efuse" |
| 8 | 12 | |
| 13 | +Deprecated properties: | |
| 14 | +- compatible: "rockchip,rockchip-efuse" | |
| 15 | + Old efuse compatible value compatible to rk3066a, rk3188 and rk3288 | |
| 16 | + efuses | |
| 17 | + | |
| 9 | 18 | = Data cells = |
| 10 | 19 | Are child nodes of eFuse, bindings of which as described in |
| 11 | 20 | bindings/nvmem/nvmem.txt |
| @@ -13,7 +22,7 @@ bindings/nvmem/nvmem.txt · 1 unmodified line | ||
| 13 | 22 | Example: |
| 14 | 23 | |
| 15 | 24 | efuse: efuse@ffb40000 { |
| 16 | − compatible = "rockchip,rockchip-efuse"; | |
| 25 | + compatible = "rockchip,rk3288-efuse"; | |
| 17 | 26 | reg = <0xffb40000 0x20>; |
| 18 | 27 | #address-cells = <1>; |
| 19 | 28 | #size-cells = <1>; |
| @@ -24,16 +24,17 @@ Example: · 23 unmodified lines | ||
| 24 | 24 | compatible = "axis,artpec6-pcie", "snps,dw-pcie"; |
| 25 | 25 | reg = <0xf8050000 0x2000 |
| 26 | 26 | 0xf8040000 0x1000 |
| 27 | − 0xc0000000 0x1000>; | |
| 27 | + 0xc0000000 0x2000>; | |
| 28 | 28 | reg-names = "dbi", "phy", "config"; |
| 29 | 29 | #address-cells = <3>; |
| 30 | 30 | #size-cells = <2>; |
| 31 | 31 | device_type = "pci"; |
| 32 | 32 | /* downstream I/O */ |
| 33 | − ranges = <0x81000000 0 0x00010000 0xc0010000 0 0x00010000 | |
| 33 | + ranges = <0x81000000 0 0 0xc0002000 0 0x00010000 | |
| 34 | 34 | /* non-prefetchable memory */ |
| 35 | − 0x82000000 0 0xc0020000 0xc0020000 0 0x1ffe0000>; | |
| 35 | + 0x82000000 0 0xc0012000 0xc0012000 0 0x1ffee000>; | |
| 36 | 36 | num-lanes = <2>; |
| 37 | + bus-range = <0x00 0xff>; | |
| 37 | 38 | interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; |
| 38 | 39 | interrupt-names = "msi"; |
| 39 | 40 | #interrupt-cells = <1>; |
| @@ -17,6 +17,8 @@ Required properties: · 16 unmodified lines | ||
| 17 | 17 | - num-lanes: number of lanes to use |
| 18 | 18 | |
| 19 | 19 | Optional properties: |
| 20 | +- num-viewport: number of view ports configured in hardware. If a platform | |
| 21 | + does not specify it, the driver assumes 2. | |
| 20 | 22 | - num-lanes: number of lanes to use (this property should be specified unless |
| 21 | 23 | the link is brought already up in BIOS) |
| 22 | 24 | - reset-gpio: gpio pin number of power good signal |
| @@ -44,4 +46,5 @@ Example configuration: · 21 unmodified lines | ||
| 44 | 46 | interrupts = <25>, <24>; |
| 45 | 47 | #interrupt-cells = <1>; |
| 46 | 48 | num-lanes = <1>; |
| 49 | + num-viewport = <3>; | |
| 47 | 50 | }; |
| @@ -0,0 +1,171 @@ | ||
| 1 | +This document describes the generic device tree binding for describing the | |
| 2 | +relationship between PCI(e) devices and IOMMU(s). | |
| 3 | + | |
| 4 | +Each PCI(e) device under a root complex is uniquely identified by its Requester | |
| 5 | +ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and | |
| 6 | +Function number. | |
| 7 | + | |
| 8 | +For the purpose of this document, when treated as a numeric value, a RID is | |
| 9 | +formatted such that: | |
| 10 | + | |
| 11 | +* Bits [15:8] are the Bus number. | |
| 12 | +* Bits [7:3] are the Device number. | |
| 13 | +* Bits [2:0] are the Function number. | |
| 14 | +* Any other bits required for padding must be zero. | |
| 15 | + | |
| 16 | +IOMMUs may distinguish PCI devices through sideband data derived from the | |
| 17 | +Requester ID. While a given PCI device can only master through one IOMMU, a | |
| 18 | +root complex may split masters across a set of IOMMUs (e.g. with one IOMMU per | |
| 19 | +bus). | |
| 20 | + | |
| 21 | +The generic 'iommus' property is insufficient to describe this relationship, | |
| 22 | +and a mechanism is required to map from a PCI device to its IOMMU and sideband | |
| 23 | +data. | |
| 24 | + | |
| 25 | +For generic IOMMU bindings, see | |
| 26 | +Documentation/devicetree/bindings/iommu/iommu.txt. | |
| 27 | + | |
| 28 | + | |
| 29 | +PCI root complex | |
| 30 | +================ | |
| 31 | + | |
| 32 | +Optional properties | |
| 33 | +------------------- | |
| 34 | + | |
| 35 | +- iommu-map: Maps a Requester ID to an IOMMU and associated iommu-specifier | |
| 36 | + data. | |
| 37 | + | |
| 38 | + The property is an arbitrary number of tuples of | |
| 39 | + (rid-base,iommu,iommu-base,length). | |
| 40 | + | |
| 41 | + Any RID r in the interval [rid-base, rid-base + length) is associated with | |
| 42 | + the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base). | |
| 43 | + | |
| 44 | +- iommu-map-mask: A mask to be applied to each Requester ID prior to being | |
| 45 | + mapped to an iommu-specifier per the iommu-map property. | |
| 46 | + | |
| 47 | + | |
| 48 | +Example (1) | |
| 49 | +=========== | |
| 50 | + | |
| 51 | +/ { | |
| 52 | + #address-cells = <1>; | |
| 53 | + #size-cells = <1>; | |
| 54 | + | |
| 55 | + iommu: iommu@a { | |
| 56 | + reg = <0xa 0x1>; | |
| 57 | + compatible = "vendor,some-iommu"; | |
| 58 | + #iommu-cells = <1>; | |
| 59 | + }; | |
| 60 | + | |
| 61 | + pci: pci@f { | |
| 62 | + reg = <0xf 0x1>; | |
| 63 | + compatible = "vendor,pcie-root-complex"; | |
| 64 | + device_type = "pci"; | |
| 65 | + | |
| 66 | + /* | |
| 67 | + * The sideband data provided to the IOMMU is the RID, | |
| 68 | + * identity-mapped. | |
| 69 | + */ | |
| 70 | + iommu-map = <0x0 &iommu 0x0 0x10000>; | |
| 71 | + }; | |
| 72 | +}; | |
| 73 | + | |
| 74 | + | |
| 75 | +Example (2) | |
| 76 | +=========== | |
| 77 | + | |
| 78 | +/ { | |
| 79 | + #address-cells = <1>; | |
| 80 | + #size-cells = <1>; | |
| 81 | + | |
| 82 | + iommu: iommu@a { | |
| 83 | + reg = <0xa 0x1>; | |
| 84 | + compatible = "vendor,some-iommu"; | |
| 85 | + #iommu-cells = <1>; | |
| 86 | + }; | |
| 87 | + | |
| 88 | + pci: pci@f { | |
| 89 | + reg = <0xf 0x1>; | |
| 90 | + compatible = "vendor,pcie-root-complex"; | |
| 91 | + device_type = "pci"; | |
| 92 | + | |
| 93 | + /* | |
| 94 | + * The sideband data provided to the IOMMU is the RID with the | |
| 95 | + * function bits masked out. | |
| 96 | + */ | |
| 97 | + iommu-map = <0x0 &iommu 0x0 0x10000>; | |
| 98 | + iommu-map-mask = <0xfff8>; | |
| 99 | + }; | |
| 100 | +}; | |
| 101 | + | |
| 102 | + | |
| 103 | +Example (3) | |
| 104 | +=========== | |
| 105 | + | |
| 106 | +/ { | |
| 107 | + #address-cells = <1>; | |
| 108 | + #size-cells = <1>; | |
| 109 | + | |
| 110 | + iommu: iommu@a { | |
| 111 | + reg = <0xa 0x1>; | |
| 112 | + compatible = "vendor,some-iommu"; | |
| 113 | + #iommu-cells = <1>; | |
| 114 | + }; | |
| 115 | + | |
| 116 | + pci: pci@f { | |
| 117 | + reg = <0xf 0x1>; | |
| 118 | + compatible = "vendor,pcie-root-complex"; | |
| 119 | + device_type = "pci"; | |
| 120 | + | |
| 121 | + /* | |
| 122 | + * The sideband data provided to the IOMMU is the RID, | |
| 123 | + * but the high bits of the bus number are flipped. | |
| 124 | + */ | |
| 125 | + iommu-map = <0x0000 &iommu 0x8000 0x8000>, | |
| 126 | + <0x8000 &iommu 0x0000 0x8000>; | |
| 127 | + }; | |
| 128 | +}; | |
| 129 | + | |
| 130 | + | |
| 131 | +Example (4) | |
| 132 | +=========== | |
| 133 | + | |
| 134 | +/ { | |
| 135 | + #address-cells = <1>; | |
| 136 | + #size-cells = <1>; | |
| 137 | + | |
| 138 | + iommu_a: iommu@a { | |
| 139 | + reg = <0xa 0x1>; | |
| 140 | + compatible = "vendor,some-iommu"; | |
| 141 | + #iommu-cells = <1>; | |
| 142 | + }; | |
| 143 | + | |
| 144 | + iommu_b: iommu@b { | |
| 145 | + reg = <0xb 0x1>; | |
| 146 | + compatible = "vendor,some-iommu"; | |
| 147 | + #iommu-cells = <1>; | |
| 148 | + }; | |
| 149 | + | |
| 150 | + iommu_c: iommu@c { | |
| 151 | + reg = <0xc 0x1>; | |
| 152 | + compatible = "vendor,some-iommu"; | |
| 153 | + #iommu-cells = <1>; | |
| 154 | + }; | |
| 155 | + | |
| 156 | + pci: pci@f { | |
| 157 | + reg = <0xf 0x1>; | |
| 158 | + compatible = "vendor,pcie-root-complex"; | |
| 159 | + device_type = "pci"; | |
| 160 | + | |
| 161 | + /* | |
| 162 | + * Devices with bus number 0-127 are mastered via IOMMU | |
| 163 | + * a, with sideband data being RID[14:0]. | |
| 164 | + * Devices with bus number 128-255 are mastered via | |
| 165 | + * IOMMU b, with sideband data being RID[14:0]. | |
| 166 | + * No devices master via IOMMU c. | |
| 167 | + */ | |
| 168 | + iommu-map = <0x0000 &iommu_a 0x0000 0x8000>, | |
| 169 | + <0x8000 &iommu_b 0x0000 0x8000>; | |
| 170 | + }; | |
| 171 | +}; | |
| @@ -0,0 +1,106 @@ | ||
| 1 | +* Rockchip AXI PCIe Root Port Bridge DT description | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- #address-cells: Address representation for root ports, set to <3> | |
| 5 | +- #size-cells: Size representation for root ports, set to <2> | |
| 6 | +- #interrupt-cells: specifies the number of cells needed to encode an | |
| 7 | + interrupt source. The value must be 1. | |
| 8 | +- compatible: Should contain "rockchip,rk3399-pcie" | |
| 9 | +- reg: Two register ranges as listed in the reg-names property | |
| 10 | +- reg-names: Must include the following names | |
| 11 | + - "axi-base" | |
| 12 | + - "apb-base" | |
| 13 | +- clocks: Must contain an entry for each entry in clock-names. | |
| 14 | + See ../clocks/clock-bindings.txt for details. | |
| 15 | +- clock-names: Must include the following entries: | |
| 16 | + - "aclk" | |
| 17 | + - "aclk-perf" | |
| 18 | + - "hclk" | |
| 19 | + - "pm" | |
| 20 | +- msi-map: Maps a Requester ID to an MSI controller and associated | |
| 21 | + msi-specifier data. See ./pci-msi.txt | |
| 22 | +- phys: From PHY bindings: Phandle for the Generic PHY for PCIe. | |
| 23 | +- phy-names: MUST be "pcie-phy". | |
| 24 | +- interrupts: Three interrupt entries must be specified. | |
| 25 | +- interrupt-names: Must include the following names | |
| 26 | + - "sys" | |
| 27 | + - "legacy" | |
| 28 | + - "client" | |
| 29 | +- resets: Must contain five entries for each entry in reset-names. | |
| 30 | + See ../reset/reset.txt for details. | |
| 31 | +- reset-names: Must include the following names | |
| 32 | + - "core" | |
| 33 | + - "mgmt" | |
| 34 | + - "mgmt-sticky" | |
| 35 | + - "pipe" | |
| 36 | +- pinctrl-names : The pin control state names | |
| 37 | +- pinctrl-0: The "default" pinctrl state | |
| 38 | +- #interrupt-cells: specifies the number of cells needed to encode an | |
| 39 | + interrupt source. The value must be 1. | |
| 40 | +- interrupt-map-mask and interrupt-map: standard PCI properties | |
| 41 | + | |
| 42 | +Optional Property: | |
| 43 | +- ep-gpios: contain the entry for pre-reset gpio | |
| 44 | +- num-lanes: number of lanes to use | |
| 45 | +- vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe. | |
| 46 | +- vpcie1v8-supply: The phandle to the 1.8v regulator to use for PCIe. | |
| 47 | +- vpcie0v9-supply: The phandle to the 0.9v regulator to use for PCIe. | |
| 48 | + | |
| 49 | +*Interrupt controller child node* | |
| 50 | +The core controller provides a single interrupt for legacy INTx. The PCIe node | |
| 51 | +should contain an interrupt controller node as a target for the PCI | |
| 52 | +'interrupt-map' property. This node represents the domain at which the four | |
| 53 | +INTx interrupts are decoded and routed. | |
| 54 | + | |
| 55 | + | |
| 56 | +Required properties for Interrupt controller child node: | |
| 57 | +- interrupt-controller: identifies the node as an interrupt controller | |
| 58 | +- #address-cells: specifies the number of cells needed to encode an | |
| 59 | + address. The value must be 0. | |
| 60 | +- #interrupt-cells: specifies the number of cells needed to encode an | |
| 61 | + interrupt source. The value must be 1. | |
| 62 | + | |
| 63 | +Example: | |
| 64 | + | |
| 65 | +pcie0: pcie@f8000000 { | |
| 66 | + compatible = "rockchip,rk3399-pcie"; | |
| 67 | + #address-cells = <3>; | |
| 68 | + #size-cells = <2>; | |
| 69 | + clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>, | |
| 70 | + <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>; | |
| 71 | + clock-names = "aclk", "aclk-perf", | |
| 72 | + "hclk", "pm"; | |
| 73 | + bus-range = <0x0 0x1>; | |
| 74 | + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>, | |
| 75 | + <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>, | |
| 76 | + <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>; | |
| 77 | + interrupt-names = "sys", "legacy", "client"; | |
| 78 | + assigned-clocks = <&cru SCLK_PCIEPHY_REF>; | |
| 79 | + assigned-clock-parents = <&cru SCLK_PCIEPHY_REF100M>; | |
| 80 | + assigned-clock-rates = <100000000>; | |
| 81 | + ep-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>; | |
| 82 | + ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000 | |
| 83 | + 0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>; | |
| 84 | + num-lanes = <4>; | |
| 85 | + msi-map = <0x0 &its 0x0 0x1000>; | |
| 86 | + reg = <0x0 0xf8000000 0x0 0x2000000>, <0x0 0xfd000000 0x0 0x1000000>; | |
| 87 | + reg-names = "axi-base", "apb-base"; | |
| 88 | + resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>, | |
| 89 | + <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>; | |
| 90 | + reset-names = "core", "mgmt", "mgmt-sticky", "pipe"; | |
| 91 | + phys = <&pcie_phy>; | |
| 92 | + phy-names = "pcie-phy"; | |
| 93 | + pinctrl-names = "default"; | |
| 94 | + pinctrl-0 = <&pcie_clkreq>; | |
| 95 | + #interrupt-cells = <1>; | |
| 96 | + interrupt-map-mask = <0 0 0 7>; | |
| 97 | + interrupt-map = <0 0 0 1 &pcie0_intc 0>, | |
| 98 | + <0 0 0 2 &pcie0_intc 1>, | |
| 99 | + <0 0 0 3 &pcie0_intc 2>, | |
| 100 | + <0 0 0 4 &pcie0_intc 3>; | |
| 101 | + pcie0_intc: interrupt-controller { | |
| 102 | + interrupt-controller; | |
| 103 | + #address-cells = <0>; | |
| 104 | + #interrupt-cells = <1>; | |
| 105 | + }; | |
| 106 | +}; | |
| @@ -55,9 +55,10 @@ nwl_pcie: pcie@fd0e0000 { · 54 unmodified lines | ||
| 55 | 55 | msi-parent = <&nwl_pcie>; |
| 56 | 56 | reg = <0x0 0xfd0e0000 0x0 0x1000>, |
| 57 | 57 | <0x0 0xfd480000 0x0 0x1000>, |
| 58 | − <0x0 0xe0000000 0x0 0x1000000>; | |
| 58 | + <0x80 0x00000000 0x0 0x1000000>; | |
| 59 | 59 | reg-names = "breg", "pcireg", "cfg"; |
| 60 | − ranges = <0x02000000 0x00000000 0xe1000000 0x00000000 0xe1000000 0 0x0f000000>; | |
| 60 | + ranges = <0x02000000 0x00000000 0xe0000000 0x00000000 0xe0000000 0x00000000 0x10000000 /* non-prefetchable memory */ | |
| 61 | + 0x43000000 0x00000006 0x00000000 0x00000006 0x00000000 0x00000002 0x00000000>;/* prefetchable memory */ | |
| 61 | 62 | |
| 62 | 63 | pcie_intc: legacy-interrupt-controller { |
| 63 | 64 | interrupt-controller; |
| @@ -0,0 +1,112 @@ | ||
| 1 | +* APM X-Gene SoC PMU bindings | |
| 2 | + | |
| 3 | +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module. | |
| 4 | +The following PMU devices are supported: | |
| 5 | + | |
| 6 | + L3C - L3 cache controller | |
| 7 | + IOB - IO bridge | |
| 8 | + MCB - Memory controller bridge | |
| 9 | + MC - Memory controller | |
| 10 | + | |
| 11 | +The following section describes the SoC PMU DT node binding. | |
| 12 | + | |
| 13 | +Required properties: | |
| 14 | +- compatible : Shall be "apm,xgene-pmu" for revision 1 or | |
| 15 | + "apm,xgene-pmu-v2" for revision 2. | |
| 16 | +- regmap-csw : Regmap of the CPU switch fabric (CSW) resource. | |
| 17 | +- regmap-mcba : Regmap of the MCB-A (memory bridge) resource. | |
| 18 | +- regmap-mcbb : Regmap of the MCB-B (memory bridge) resource. | |
| 19 | +- reg : First resource shall be the CPU bus PMU resource. | |
| 20 | +- interrupts : Interrupt-specifier for PMU IRQ. | |
| 21 | + | |
| 22 | +Required properties for L3C subnode: | |
| 23 | +- compatible : Shall be "apm,xgene-pmu-l3c". | |
| 24 | +- reg : First resource shall be the L3C PMU resource. | |
| 25 | + | |
| 26 | +Required properties for IOB subnode: | |
| 27 | +- compatible : Shall be "apm,xgene-pmu-iob". | |
| 28 | +- reg : First resource shall be the IOB PMU resource. | |
| 29 | + | |
| 30 | +Required properties for MCB subnode: | |
| 31 | +- compatible : Shall be "apm,xgene-pmu-mcb". | |
| 32 | +- reg : First resource shall be the MCB PMU resource. | |
| 33 | +- enable-bit-index : The bit indicates if the according MCB is enabled. | |
| 34 | + | |
| 35 | +Required properties for MC subnode: | |
| 36 | +- compatible : Shall be "apm,xgene-pmu-mc". | |
| 37 | +- reg : First resource shall be the MC PMU resource. | |
| 38 | +- enable-bit-index : The bit indicates if the according MC is enabled. | |
| 39 | + | |
| 40 | +Example: | |
| 41 | + csw: csw@7e200000 { | |
| 42 | + compatible = "apm,xgene-csw", "syscon"; | |
| 43 | + reg = <0x0 0x7e200000 0x0 0x1000>; | |
| 44 | + }; | |
| 45 | + | |
| 46 | + mcba: mcba@7e700000 { | |
| 47 | + compatible = "apm,xgene-mcb", "syscon"; | |
| 48 | + reg = <0x0 0x7e700000 0x0 0x1000>; | |
| 49 | + }; | |
| 50 | + | |
| 51 | + mcbb: mcbb@7e720000 { | |
| 52 | + compatible = "apm,xgene-mcb", "syscon"; | |
| 53 | + reg = <0x0 0x7e720000 0x0 0x1000>; | |
| 54 | + }; | |
| 55 | + | |
| 56 | + pmu: pmu@78810000 { | |
| 57 | + compatible = "apm,xgene-pmu-v2"; | |
| 58 | + #address-cells = <2>; | |
| 59 | + #size-cells = <2>; | |
| 60 | + ranges; | |
| 61 | + regmap-csw = <&csw>; | |
| 62 | + regmap-mcba = <&mcba>; | |
| 63 | + regmap-mcbb = <&mcbb>; | |
| 64 | + reg = <0x0 0x78810000 0x0 0x1000>; | |
| 65 | + interrupts = <0x0 0x22 0x4>; | |
| 66 | + | |
| 67 | + pmul3c@7e610000 { | |
| 68 | + compatible = "apm,xgene-pmu-l3c"; | |
| 69 | + reg = <0x0 0x7e610000 0x0 0x1000>; | |
| 70 | + }; | |
| 71 | + | |
| 72 | + pmuiob@7e940000 { | |
| 73 | + compatible = "apm,xgene-pmu-iob"; | |
| 74 | + reg = <0x0 0x7e940000 0x0 0x1000>; | |
| 75 | + }; | |
| 76 | + | |
| 77 | + pmucmcb@7e710000 { | |
| 78 | + compatible = "apm,xgene-pmu-mcb"; | |
| 79 | + reg = <0x0 0x7e710000 0x0 0x1000>; | |
| 80 | + enable-bit-index = <0>; | |
| 81 | + }; | |
| 82 | + | |
| 83 | + pmucmcb@7e730000 { | |
| 84 | + compatible = "apm,xgene-pmu-mcb"; | |
| 85 | + reg = <0x0 0x7e730000 0x0 0x1000>; | |
| 86 | + enable-bit-index = <1>; | |
| 87 | + }; | |
| 88 | + | |
| 89 | + pmucmc@7e810000 { | |
| 90 | + compatible = "apm,xgene-pmu-mc"; | |
| 91 | + reg = <0x0 0x7e810000 0x0 0x1000>; | |
| 92 | + enable-bit-index = <0>; | |
| 93 | + }; | |
| 94 | + | |
| 95 | + pmucmc@7e850000 { | |
| 96 | + compatible = "apm,xgene-pmu-mc"; | |
| 97 | + reg = <0x0 0x7e850000 0x0 0x1000>; | |
| 98 | + enable-bit-index = <1>; | |
| 99 | + }; | |
| 100 | + | |
| 101 | + pmucmc@7e890000 { | |
| 102 | + compatible = "apm,xgene-pmu-mc"; | |
| 103 | + reg = <0x0 0x7e890000 0x0 0x1000>; | |
| 104 | + enable-bit-index = <2>; | |
| 105 | + }; | |
| 106 | + | |
| 107 | + pmucmc@7e8d0000 { | |
| 108 | + compatible = "apm,xgene-pmu-mc"; | |
| 109 | + reg = <0x0 0x7e8d0000 0x0 0x1000>; | |
| 110 | + enable-bit-index = <3>; | |
| 111 | + }; | |
| 112 | + }; | |
| @@ -0,0 +1,23 @@ | ||
| 1 | +Driver for Broadcom Northstar USB 3.0 PHY | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy". | |
| 6 | +- reg: register mappings for DMP (Device Management Plugin) and ChipCommon B | |
| 7 | + MMI. | |
| 8 | +- reg-names: "dmp" and "ccb-mii" | |
| 9 | + | |
| 10 | +Initialization of USB 3.0 PHY depends on Northstar version. There are currently | |
| 11 | +three known series: Ax, Bx and Cx. | |
| 12 | +Known A0: BCM4707 rev 0 | |
| 13 | +Known B0: BCM4707 rev 4, BCM53573 rev 2 | |
| 14 | +Known B1: BCM4707 rev 6 | |
| 15 | +Known C0: BCM47094 rev 0 | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + usb3-phy { | |
| 19 | + compatible = "brcm,ns-ax-usb3-phy"; | |
| 20 | + reg = <0x18105000 0x1000>, <0x18003000 0x1000>; | |
| 21 | + reg-names = "dmp", "ccb-mii"; | |
| 22 | + #phy-cells = <0>; | |
| 23 | + }; | |
| @@ -0,0 +1,27 @@ | ||
| 1 | +* Amlogic USB2 PHY | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Depending on the platform this should be one of: | |
| 5 | + "amlogic,meson8b-usb2-phy" | |
| 6 | + "amlogic,meson-gxbb-usb2-phy" | |
| 7 | +- reg: The base address and length of the registers | |
| 8 | +- #phys-cells: should be 0 (see phy-bindings.txt in this directory) | |
| 9 | +- clocks: phandle and clock identifier for the phy clocks | |
| 10 | +- clock-names: "usb_general" and "usb" | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- resets: reference to the reset controller | |
| 14 | +- phy-supply: see phy-bindings.txt in this directory | |
| 15 | + | |
| 16 | + | |
| 17 | +Example: | |
| 18 | + | |
| 19 | +usb0_phy: usb_phy@0 { | |
| 20 | + compatible = "amlogic,meson-gxbb-usb2-phy"; | |
| 21 | + #phy-cells = <0>; | |
| 22 | + reg = <0x0 0x0 0x0 0x20>; | |
| 23 | + resets = <&reset RESET_USB_OTG>; | |
| 24 | + clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>; | |
| 25 | + clock-names = "usb_general", "usb"; | |
| 26 | + phy-supply = <&usb_vbus>; | |
| 27 | +}; | |
| @@ -12,6 +12,16 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | - interrupts: Should contain phy interrupt |
| 13 | 13 | - fsl,anatop: phandle for anatop register, it is only for imx6 SoC series |
| 14 | 14 | |
| 15 | +Optional properties: | |
| 16 | +- fsl,tx-cal-45-dn-ohms: Integer [30-55]. Resistance (in ohms) of switchable | |
| 17 | + high-speed trimming resistor connected in parallel with the 45 ohm resistor | |
| 18 | + that terminates the DN output signal. Default: 45 | |
| 19 | +- fsl,tx-cal-45-dp-ohms: Integer [30-55]. Resistance (in ohms) of switchable | |
| 20 | + high-speed trimming resistor connected in parallel with the 45 ohm resistor | |
| 21 | + that terminates the DP output signal. Default: 45 | |
| 22 | +- fsl,tx-d-cal: Integer [79-119]. Current trimming value (as a percentage) of | |
| 23 | + the 17.78mA TX reference current. Default: 100 | |
| 24 | + | |
| 15 | 25 | Example: |
| 16 | 26 | usbphy1: usbphy@020c9000 { |
| 17 | 27 | compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; |
| @@ -0,0 +1,64 @@ | ||
| 1 | +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK | |
| 2 | + | |
| 3 | +Required properties (phy (parent) node): | |
| 4 | + - compatible : should be one of the listed compatibles: | |
| 5 | + * "rockchip,rk3366-usb2phy" | |
| 6 | + * "rockchip,rk3399-usb2phy" | |
| 7 | + - reg : the address offset of grf for usb-phy configuration. | |
| 8 | + - #clock-cells : should be 0. | |
| 9 | + - clock-output-names : specify the 480m output clock name. | |
| 10 | + | |
| 11 | +Optional properties: | |
| 12 | + - clocks : phandle + phy specifier pair, for the input clock of phy. | |
| 13 | + - clock-names : input clock name of phy, must be "phyclk". | |
| 14 | + | |
| 15 | +Required nodes : a sub-node is required for each port the phy provides. | |
| 16 | + The sub-node name is used to identify host or otg port, | |
| 17 | + and shall be the following entries: | |
| 18 | + * "otg-port" : the name of otg port. | |
| 19 | + * "host-port" : the name of host port. | |
| 20 | + | |
| 21 | +Required properties (port (child) node): | |
| 22 | + - #phy-cells : must be 0. See ./phy-bindings.txt for details. | |
| 23 | + - interrupts : specify an interrupt for each entry in interrupt-names. | |
| 24 | + - interrupt-names : a list which shall be the following entries: | |
| 25 | + * "otg-id" : for the otg id interrupt. | |
| 26 | + * "otg-bvalid" : for the otg vbus interrupt. | |
| 27 | + * "linestate" : for the host/otg linestate interrupt. | |
| 28 | + | |
| 29 | +Optional properties: | |
| 30 | + - phy-supply : phandle to a regulator that provides power to VBUS. | |
| 31 | + See ./phy-bindings.txt for details. | |
| 32 | + | |
| 33 | +Example: | |
| 34 | + | |
| 35 | +grf: syscon@ff770000 { | |
| 36 | + compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd"; | |
| 37 | + #address-cells = <1>; | |
| 38 | + #size-cells = <1>; | |
| 39 | + | |
| 40 | +... | |
| 41 | + | |
| 42 | + u2phy: usb2-phy@700 { | |
| 43 | + compatible = "rockchip,rk3366-usb2phy"; | |
| 44 | + reg = <0x700 0x2c>; | |
| 45 | + #clock-cells = <0>; | |
| 46 | + clock-output-names = "sclk_otgphy0_480m"; | |
| 47 | + | |
| 48 | + u2phy_otg: otg-port { | |
| 49 | + #phy-cells = <0>; | |
| 50 | + interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>, | |
| 51 | + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, | |
| 52 | + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; | |
| 53 | + interrupt-names = "otg-id", "otg-bvalid", "linestate"; | |
| 54 | + status = "okay"; | |
| 55 | + }; | |
| 56 | + | |
| 57 | + u2phy_host: host-port { | |
| 58 | + #phy-cells = <0>; | |
| 59 | + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; | |
| 60 | + interrupt-names = "linestate"; | |
| 61 | + status = "okay"; | |
| 62 | + }; | |
| 63 | + }; | |
| 64 | +}; | |
| @@ -0,0 +1,101 @@ | ||
| 1 | +* ROCKCHIP type-c PHY | |
| 2 | +--------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + - compatible : must be "rockchip,rk3399-typec-phy" | |
| 6 | + - reg: Address and length of the usb phy control register set | |
| 7 | + - rockchip,grf : phandle to the syscon managing the "general | |
| 8 | + register files" | |
| 9 | + - clocks : phandle + clock specifier for the phy clocks | |
| 10 | + - clock-names : string, clock name, must be "tcpdcore", "tcpdphy-ref"; | |
| 11 | + - assigned-clocks: main clock, should be <&cru SCLK_UPHY0_TCPDCORE> or | |
| 12 | + <&cru SCLK_UPHY1_TCPDCORE>; | |
| 13 | + - assigned-clock-rates : the phy core clk frequency, shall be: 50000000 | |
| 14 | + - resets : a list of phandle + reset specifier pairs | |
| 15 | + - reset-names : string reset name, must be: | |
| 16 | + "uphy", "uphy-pipe", "uphy-tcphy" | |
| 17 | + - extcon : extcon specifier for the Power Delivery | |
| 18 | + | |
| 19 | +Note, there are 2 type-c phys for RK3399, and they are almost identical, except | |
| 20 | +these registers(description below), every register node contains 3 sections: | |
| 21 | +offset, enable bit, write mask bit. | |
| 22 | + - rockchip,typec-conn-dir : the register of type-c connector direction, | |
| 23 | + for type-c phy0, it must be <0xe580 0 16>; | |
| 24 | + for type-c phy1, it must be <0xe58c 0 16>; | |
| 25 | + - rockchip,usb3tousb2-en : the register of type-c force usb3 to usb2 enable | |
| 26 | + control. | |
| 27 | + for type-c phy0, it must be <0xe580 3 19>; | |
| 28 | + for type-c phy1, it must be <0xe58c 3 19>; | |
| 29 | + - rockchip,external-psm : the register of type-c phy external psm clock | |
| 30 | + selection. | |
| 31 | + for type-c phy0, it must be <0xe588 14 30>; | |
| 32 | + for type-c phy1, it must be <0xe594 14 30>; | |
| 33 | + - rockchip,pipe-status : the register of type-c phy pipe status. | |
| 34 | + for type-c phy0, it must be <0xe5c0 0 0>; | |
| 35 | + for type-c phy1, it must be <0xe5c0 16 16>; | |
| 36 | + | |
| 37 | +Required nodes : a sub-node is required for each port the phy provides. | |
| 38 | + The sub-node name is used to identify dp or usb3 port, | |
| 39 | + and shall be the following entries: | |
| 40 | + * "dp-port" : the name of DP port. | |
| 41 | + * "usb3-port" : the name of USB3 port. | |
| 42 | + | |
| 43 | +Required properties (port (child) node): | |
| 44 | +- #phy-cells : must be 0, See ./phy-bindings.txt for details. | |
| 45 | + | |
| 46 | +Example: | |
| 47 | + tcphy0: phy@ff7c0000 { | |
| 48 | + compatible = "rockchip,rk3399-typec-phy"; | |
| 49 | + reg = <0x0 0xff7c0000 0x0 0x40000>; | |
| 50 | + rockchip,grf = <&grf>; | |
| 51 | + extcon = <&fusb0>; | |
| 52 | + clocks = <&cru SCLK_UPHY0_TCPDCORE>, | |
| 53 | + <&cru SCLK_UPHY0_TCPDPHY_REF>; | |
| 54 | + clock-names = "tcpdcore", "tcpdphy-ref"; | |
| 55 | + assigned-clocks = <&cru SCLK_UPHY0_TCPDCORE>; | |
| 56 | + assigned-clock-rates = <50000000>; | |
| 57 | + resets = <&cru SRST_UPHY0>, | |
| 58 | + <&cru SRST_UPHY0_PIPE_L00>, | |
| 59 | + <&cru SRST_P_UPHY0_TCPHY>; | |
| 60 | + reset-names = "uphy", "uphy-pipe", "uphy-tcphy"; | |
| 61 | + rockchip,typec-conn-dir = <0xe580 0 16>; | |
| 62 | + rockchip,usb3tousb2-en = <0xe580 3 19>; | |
| 63 | + rockchip,external-psm = <0xe588 14 30>; | |
| 64 | + rockchip,pipe-status = <0xe5c0 0 0>; | |
| 65 | + | |
| 66 | + tcphy0_dp: dp-port { | |
| 67 | + #phy-cells = <0>; | |
| 68 | + }; | |
| 69 | + | |
| 70 | + tcphy0_usb3: usb3-port { | |
| 71 | + #phy-cells = <0>; | |
| 72 | + }; | |
| 73 | + }; | |
| 74 | + | |
| 75 | + tcphy1: phy@ff800000 { | |
| 76 | + compatible = "rockchip,rk3399-typec-phy"; | |
| 77 | + reg = <0x0 0xff800000 0x0 0x40000>; | |
| 78 | + rockchip,grf = <&grf>; | |
| 79 | + extcon = <&fusb1>; | |
| 80 | + clocks = <&cru SCLK_UPHY1_TCPDCORE>, | |
| 81 | + <&cru SCLK_UPHY1_TCPDPHY_REF>; | |
| 82 | + clock-names = "tcpdcore", "tcpdphy-ref"; | |
| 83 | + assigned-clocks = <&cru SCLK_UPHY1_TCPDCORE>; | |
| 84 | + assigned-clock-rates = <50000000>; | |
| 85 | + resets = <&cru SRST_UPHY1>, | |
| 86 | + <&cru SRST_UPHY1_PIPE_L00>, | |
| 87 | + <&cru SRST_P_UPHY1_TCPHY>; | |
| 88 | + reset-names = "uphy", "uphy-pipe", "uphy-tcphy"; | |
| 89 | + rockchip,typec-conn-dir = <0xe58c 0 16>; | |
| 90 | + rockchip,usb3tousb2-en = <0xe58c 3 19>; | |
| 91 | + rockchip,external-psm = <0xe594 14 30>; | |
| 92 | + rockchip,pipe-status = <0xe5c0 16 16>; | |
| 93 | + | |
| 94 | + tcphy1_dp: dp-port { | |
| 95 | + #phy-cells = <0>; | |
| 96 | + }; | |
| 97 | + | |
| 98 | + tcphy1_usb3: usb3-port { | |
| 99 | + #phy-cells = <0>; | |
| 100 | + }; | |
| 101 | + }; | |
| @@ -5,6 +5,8 @@ This file provides information on what the device node for the R-Car generation · 4 unmodified lines | ||
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | 7 | - compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an R8A7795 |
| 8 | + SoC. | |
| 9 | + "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796 | |
| 8 | 10 | SoC. |
| 9 | 11 | "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible device. |
| 10 | 12 | |
| @@ -30,11 +32,11 @@ Example (R-Car H3): · 19 unmodified lines | ||
| 30 | 32 | compatible = "renesas,usb2-phy-r8a7795", "renesas,rcar-gen3-usb2-phy"; |
| 31 | 33 | reg = <0 0xee080200 0 0x700>; |
| 32 | 34 | interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; |
| 33 | − clocks = <&mstp7_clks R8A7795_CLK_EHCI0>; | |
| 35 | + clocks = <&cpg CPG_MOD 703>; | |
| 34 | 36 | }; |
| 35 | 37 | |
| 36 | 38 | usb-phy@ee0a0200 { |
| 37 | 39 | compatible = "renesas,usb2-phy-r8a7795", "renesas,rcar-gen3-usb2-phy"; |
| 38 | 40 | reg = <0 0xee0a0200 0 0x700>; |
| 39 | − clocks = <&mstp7_clks R8A7795_CLK_EHCI0>; | |
| 41 | + clocks = <&cpg CPG_MOD 702>; | |
| 40 | 42 | }; |
| @@ -0,0 +1,31 @@ | ||
| 1 | +Rockchip PCIE PHY | |
| 2 | +----------------------- | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | + - compatible: rockchip,rk3399-pcie-phy | |
| 6 | + - #phy-cells: must be 0 | |
| 7 | + - clocks: Must contain an entry in clock-names. | |
| 8 | + See ../clocks/clock-bindings.txt for details. | |
| 9 | + - clock-names: Must be "refclk" | |
| 10 | + - resets: Must contain an entry in reset-names. | |
| 11 | + See ../reset/reset.txt for details. | |
| 12 | + - reset-names: Must be "phy" | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | +grf: syscon@ff770000 { | |
| 17 | + compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd"; | |
| 18 | + #address-cells = <1>; | |
| 19 | + #size-cells = <1>; | |
| 20 | + | |
| 21 | + ... | |
| 22 | + | |
| 23 | + pcie_phy: pcie-phy { | |
| 24 | + compatible = "rockchip,rk3399-pcie-phy"; | |
| 25 | + #phy-cells = <0>; | |
| 26 | + clocks = <&cru SCLK_PCIEPHY_REF>; | |
| 27 | + clock-names = "refclk"; | |
| 28 | + resets = <&cru SRST_PCIEPHY>; | |
| 29 | + reset-names = "phy"; | |
| 30 | + }; | |
| 31 | +}; | |
| @@ -27,6 +27,9 @@ Optional Properties: · 26 unmodified lines | ||
| 27 | 27 | - clocks : phandle + clock specifier for the phy clocks |
| 28 | 28 | - clock-names: string, clock name, must be "phyclk" |
| 29 | 29 | - #clock-cells: for users of the phy-pll, should be 0 |
| 30 | +- reset-names: Only allow the following entries: | |
| 31 | + - phy-reset | |
| 32 | +- resets: Must contain an entry for each entry in reset-names. | |
| 30 | 33 | |
| 31 | 34 | Example: |
| 32 | 35 | |
| @@ -10,6 +10,7 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | * allwinner,sun8i-a23-usb-phy |
| 11 | 11 | * allwinner,sun8i-a33-usb-phy |
| 12 | 12 | * allwinner,sun8i-h3-usb-phy |
| 13 | + * allwinner,sun50i-a64-usb-phy | |
| 13 | 14 | - reg : a list of offset + length pairs |
| 14 | 15 | - reg-names : |
| 15 | 16 | * "phy_ctrl" |
| @@ -31,6 +31,8 @@ OMAP USB2 PHY · 30 unmodified lines | ||
| 31 | 31 | |
| 32 | 32 | Required properties: |
| 33 | 33 | - compatible: Should be "ti,omap-usb2" |
| 34 | + Should be "ti,dra7x-usb2" for the 1st instance of USB2 PHY on | |
| 35 | + DRA7x | |
| 34 | 36 | Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY |
| 35 | 37 | in DRA7x |
| 36 | 38 | - reg : Address and length of the register set for the device. |
| @@ -23,6 +23,7 @@ Required properties: · 22 unmodified lines | ||
| 23 | 23 | "allwinner,sun8i-h3-pinctrl" |
| 24 | 24 | "allwinner,sun8i-h3-r-pinctrl" |
| 25 | 25 | "allwinner,sun50i-a64-pinctrl" |
| 26 | + "nextthing,gr8-pinctrl" | |
| 26 | 27 | |
| 27 | 28 | - reg: Should contain the register physical address and length for the |
| 28 | 29 | pin controller. |
| @@ -4,7 +4,9 @@ Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding · 3 unmodified lines | ||
| 4 | 4 | part and usage. |
| 5 | 5 | |
| 6 | 6 | Required properties: |
| 7 | −- compatible: "marvell,88f5181l-pinctrl", "marvell,88f5182-pinctrl", | |
| 7 | +- compatible: "marvell,88f5181-pinctrl", | |
| 8 | + "marvell,88f5181l-pinctrl", | |
| 9 | + "marvell,88f5182-pinctrl", | |
| 8 | 10 | "marvell,88f5281-pinctrl" |
| 9 | 11 | |
| 10 | 12 | - reg: two register areas, the first one describing the first two |
| @@ -0,0 +1,67 @@ | ||
| 1 | +Aspeed Pin Controllers | |
| 2 | +---------------------- | |
| 3 | + | |
| 4 | +The Aspeed SoCs vary in functionality inside a generation but have a common mux | |
| 5 | +device register layout. | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible : Should be any one of the following: | |
| 9 | + "aspeed,ast2400-pinctrl" | |
| 10 | + "aspeed,g4-pinctrl" | |
| 11 | + "aspeed,ast2500-pinctrl" | |
| 12 | + "aspeed,g5-pinctrl" | |
| 13 | + | |
| 14 | +The pin controller node should be a child of a syscon node with the required | |
| 15 | +property: | |
| 16 | +- compatible: "syscon", "simple-mfd" | |
| 17 | + | |
| 18 | +Refer to the the bindings described in | |
| 19 | +Documentation/devicetree/bindings/mfd/syscon.txt | |
| 20 | + | |
| 21 | +Subnode Format | |
| 22 | +-------------- | |
| 23 | + | |
| 24 | +The required properties of child nodes are (as defined in pinctrl-bindings): | |
| 25 | +- function | |
| 26 | +- groups | |
| 27 | + | |
| 28 | +Each function has only one associated pin group. Each group is named by its | |
| 29 | +function. The following values for the function and groups properties are | |
| 30 | +supported: | |
| 31 | + | |
| 32 | +aspeed,ast2400-pinctrl, aspeed,g4-pinctrl: | |
| 33 | + | |
| 34 | +ACPI BMCINT DDCCLK DDCDAT FLACK FLBUSY FLWP GPID0 GPIE0 GPIE2 GPIE4 GPIE6 I2C10 | |
| 35 | +I2C11 I2C12 I2C13 I2C3 I2C4 I2C5 I2C6 I2C7 I2C8 I2C9 LPCPD LPCPME LPCSMI MDIO1 | |
| 36 | +MDIO2 NCTS1 NCTS3 NCTS4 NDCD1 NDCD3 NDCD4 NDSR1 NDSR3 NDTR1 NDTR3 NRI1 NRI3 | |
| 37 | +NRI4 NRTS1 NRTS3 PWM0 PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 RGMII1 RMII1 ROM16 | |
| 38 | +ROM8 ROMCS1 ROMCS2 ROMCS3 ROMCS4 RXD1 RXD3 RXD4 SD1 SGPMI SIOPBI SIOPBO TIMER3 | |
| 39 | +TIMER5 TIMER6 TIMER7 TIMER8 TXD1 TXD3 TXD4 UART6 VGAHS VGAVS VPI18 VPI24 VPI30 | |
| 40 | +VPO12 VPO24 | |
| 41 | + | |
| 42 | +aspeed,ast2500-pinctrl, aspeed,g5-pinctrl: | |
| 43 | + | |
| 44 | +GPID0 GPID2 GPIE0 I2C10 I2C11 I2C12 I2C13 I2C14 I2C3 I2C4 I2C5 I2C6 I2C7 I2C8 | |
| 45 | +I2C9 MAC1LINK MDIO1 MDIO2 OSCCLK PEWAKE PWM0 PWM1 PWM2 PWM3 PWM4 PWM5 PWM6 PWM7 | |
| 46 | +RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6 | |
| 47 | +TIMER7 TIMER8 VGABIOSROM | |
| 48 | + | |
| 49 | + | |
| 50 | +Examples: | |
| 51 | + | |
| 52 | +syscon: scu@1e6e2000 { | |
| 53 | + compatible = "syscon", "simple-mfd"; | |
| 54 | + reg = <0x1e6e2000 0x1a8>; | |
| 55 | + | |
| 56 | + pinctrl: pinctrl { | |
| 57 | + compatible = "aspeed,g4-pinctrl"; | |
| 58 | + | |
| 59 | + pinctrl_i2c3_default: i2c3_default { | |
| 60 | + function = "I2C3"; | |
| 61 | + groups = "I2C3"; | |
| 62 | + }; | |
| 63 | + }; | |
| 64 | +}; | |
| 65 | + | |
| 66 | +Please refer to pinctrl-bindings.txt in this directory for details of the | |
| 67 | +common pinctrl bindings used by client devices. | |
| @@ -30,8 +30,7 @@ Second type has a dedicated interrupt per gpio bank. · 29 unmodified lines | ||
| 30 | 30 | |
| 31 | 31 | Pin controller node: |
| 32 | 32 | Required properties: |
| 33 | −- compatible : should be "st,<SOC>-<pio-block>-pinctrl" | |
| 34 | − like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on. | |
| 33 | +- compatible : should be "st,stih407-<pio-block>-pinctrl" | |
| 35 | 34 | - st,syscfg : Should be a phandle of the syscfg node. |
| 36 | 35 | - st,retime-pin-mask : Should be mask to specify which pins can be retimed. |
| 37 | 36 | If the property is not present, it is assumed that all the pins in the |
| @@ -50,7 +49,11 @@ Optional properties: · 12 unmodified lines | ||
| 50 | 49 | GPIO controller/bank node. |
| 51 | 50 | Required properties: |
| 52 | 51 | - gpio-controller : Indicates this device is a GPIO controller |
| 53 | −- #gpio-cells : Should be one. The first cell is the pin number. | |
| 52 | +- #gpio-cells : Must be two. | |
| 53 | + - First cell: specifies the pin number inside the controller | |
| 54 | + - Second cell: specifies whether the pin is logically inverted. | |
| 55 | + - 0 = active high | |
| 56 | + - 1 = active low | |
| 54 | 57 | - st,bank-name : Should be a name string for this bank as specified in |
| 55 | 58 | datasheet. |
| 56 | 59 | |
| @@ -76,23 +79,23 @@ include/dt-bindings/interrupt-controller/irq.h · 19 unmodified lines | ||
| 76 | 79 | |
| 77 | 80 | Example: |
| 78 | 81 | pin-controller-sbc { |
| 79 | − #address-cells = <1>; | |
| 80 | − #size-cells = <1>; | |
| 81 | − compatible = "st,stih415-sbc-pinctrl"; | |
| 82 | − st,syscfg = <&syscfg_sbc>; | |
| 83 | − reg = <0xfe61f080 0x4>; | |
| 84 | − reg-names = "irqmux"; | |
| 85 | − interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>; | |
| 86 | − interrupt-names = "irqmux"; | |
| 87 | − ranges = <0 0xfe610000 0x5000>; | |
| 88 | − | |
| 89 | − PIO0: gpio@fe610000 { | |
| 82 | + #address-cells = <1>; | |
| 83 | + #size-cells = <1>; | |
| 84 | + compatible = "st,stih407-sbc-pinctrl"; | |
| 85 | + st,syscfg = <&syscfg_sbc>; | |
| 86 | + reg = <0x0961f080 0x4>; | |
| 87 | + reg-names = "irqmux"; | |
| 88 | + interrupts = <GIC_SPI 188 IRQ_TYPE_NONE>; | |
| 89 | + interrupt-names = "irqmux"; | |
| 90 | + ranges = <0 0x09610000 0x6000>; | |
| 91 | + | |
| 92 | + pio0: gpio@09610000 { | |
| 90 | 93 | gpio-controller; |
| 91 | − #gpio-cells = <1>; | |
| 94 | + #gpio-cells = <2>; | |
| 92 | 95 | interrupt-controller; |
| 93 | 96 | #interrupt-cells = <2>; |
| 94 | − reg = <0 0x100>; | |
| 95 | − st,bank-name = "PIO0"; | |
| 97 | + reg = <0x0 0x100>; | |
| 98 | + st,bank-name = "PIO0"; | |
| 96 | 99 | }; |
| 97 | 100 | ... |
| 98 | 101 | pin-functions nodes follow... |
| @@ -162,7 +165,7 @@ pin-controller { · 63 unmodified lines | ||
| 162 | 165 | |
| 163 | 166 | sdhci0:sdhci@fe810000{ |
| 164 | 167 | ... |
| 165 | − interrupt-parent = <&PIO3>; | |
| 168 | + interrupt-parent = <&pio3>; | |
| 166 | 169 | #interrupt-cells = <2>; |
| 167 | 170 | interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; /* Interrupt line via PIO3-3 */ |
| 168 | 171 | interrupt-names = "card-detect"; |
| @@ -17,6 +17,9 @@ PMIC's from Qualcomm. · 16 unmodified lines | ||
| 17 | 17 | "qcom,pm8994-gpio" |
| 18 | 18 | "qcom,pma8084-gpio" |
| 19 | 19 | |
| 20 | + And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" | |
| 21 | + if the device is on an spmi bus or an ssbi bus respectively | |
| 22 | + | |
| 20 | 23 | - reg: |
| 21 | 24 | Usage: required |
| 22 | 25 | Value type: <prop-encoded-array> |
| @@ -183,7 +186,7 @@ to specify in a pin configuration subnode: · 160 unmodified lines | ||
| 183 | 186 | Example: |
| 184 | 187 | |
| 185 | 188 | pm8921_gpio: gpio@150 { |
| 186 | − compatible = "qcom,pm8921-gpio"; | |
| 189 | + compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio"; | |
| 187 | 190 | reg = <0x150 0x160>; |
| 188 | 191 | interrupts = <192 1>, <193 1>, <194 1>, |
| 189 | 192 | <195 1>, <196 1>, <197 1>, |
| @@ -19,6 +19,9 @@ of PMIC's from Qualcomm. · 18 unmodified lines | ||
| 19 | 19 | "qcom,pm8994-mpp", |
| 20 | 20 | "qcom,pma8084-mpp", |
| 21 | 21 | |
| 22 | + And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp" | |
| 23 | + if the device is on an spmi bus or an ssbi bus respectively. | |
| 24 | + | |
| 22 | 25 | - reg: |
| 23 | 26 | Usage: required |
| 24 | 27 | Value type: <prop-encoded-array> |
| @@ -158,7 +161,7 @@ to specify in a pin configuration subnode: · 133 unmodified lines | ||
| 158 | 161 | Example: |
| 159 | 162 | |
| 160 | 163 | mpps@a000 { |
| 161 | − compatible = "qcom,pm8841-mpp"; | |
| 164 | + compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp"; | |
| 162 | 165 | reg = <0xa000>; |
| 163 | 166 | gpio-controller; |
| 164 | 167 | #gpio-cells = <2>; |
| @@ -17,9 +17,11 @@ Required Properties: · 16 unmodified lines | ||
| 17 | 17 | - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller. |
| 18 | 18 | - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller. |
| 19 | 19 | - "renesas,pfc-r8a7791": for R8A7791 (R-Car M2-W) compatible pin-controller. |
| 20 | + - "renesas,pfc-r8a7792": for R8A7792 (R-Car V2H) compatible pin-controller. | |
| 20 | 21 | - "renesas,pfc-r8a7793": for R8A7793 (R-Car M2-N) compatible pin-controller. |
| 21 | 22 | - "renesas,pfc-r8a7794": for R8A7794 (R-Car E2) compatible pin-controller. |
| 22 | 23 | - "renesas,pfc-r8a7795": for R8A7795 (R-Car H3) compatible pin-controller. |
| 24 | + - "renesas,pfc-r8a7796": for R8A7796 (R-Car M3-W) compatible pin-controller. | |
| 23 | 25 | - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. |
| 24 | 26 | |
| 25 | 27 | - reg: Base address and length of each memory resource used by the pin |
| @@ -229,6 +229,8 @@ Example: A pin-controller node with pin banks: · 228 unmodified lines | ||
| 229 | 229 | |
| 230 | 230 | Example 1: A pin-controller node with pin groups. |
| 231 | 231 | |
| 232 | + #include <dt-bindings/pinctrl/samsung.h> | |
| 233 | + | |
| 232 | 234 | pinctrl_0: pinctrl@11400000 { |
| 233 | 235 | compatible = "samsung,exynos4210-pinctrl"; |
| 234 | 236 | reg = <0x11400000 0x1000>; |
| @@ -238,53 +240,53 @@ Example 1: A pin-controller node with pin groups. · 3 unmodified lines | ||
| 238 | 240 | |
| 239 | 241 | uart0_data: uart0-data { |
| 240 | 242 | samsung,pins = "gpa0-0", "gpa0-1"; |
| 241 | − samsung,pin-function = <2>; | |
| 242 | − samsung,pin-pud = <0>; | |
| 243 | − samsung,pin-drv = <0>; | |
| 243 | + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; | |
| 244 | + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; | |
| 245 | + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; | |
| 244 | 246 | }; |
| 245 | 247 | |
| 246 | 248 | uart0_fctl: uart0-fctl { |
| 247 | 249 | samsung,pins = "gpa0-2", "gpa0-3"; |
| 248 | − samsung,pin-function = <2>; | |
| 249 | − samsung,pin-pud = <0>; | |
| 250 | − samsung,pin-drv = <0>; | |
| 250 | + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; | |
| 251 | + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; | |
| 252 | + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; | |
| 251 | 253 | }; |
| 252 | 254 | |
| 253 | 255 | uart1_data: uart1-data { |
| 254 | 256 | samsung,pins = "gpa0-4", "gpa0-5"; |
| 255 | − samsung,pin-function = <2>; | |
| 256 | − samsung,pin-pud = <0>; | |
| 257 | − samsung,pin-drv = <0>; | |
| 257 | + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; | |
| 258 | + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; | |
| 259 | + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; | |
| 258 | 260 | }; |
| 259 | 261 | |
| 260 | 262 | uart1_fctl: uart1-fctl { |
| 261 | 263 | samsung,pins = "gpa0-6", "gpa0-7"; |
| 262 | − samsung,pin-function = <2>; | |
| 263 | − samsung,pin-pud = <0>; | |
| 264 | − samsung,pin-drv = <0>; | |
| 264 | + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; | |
| 265 | + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; | |
| 266 | + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; | |
| 265 | 267 | }; |
| 266 | 268 | |
| 267 | 269 | i2c2_bus: i2c2-bus { |
| 268 | 270 | samsung,pins = "gpa0-6", "gpa0-7"; |
| 269 | − samsung,pin-function = <3>; | |
| 270 | − samsung,pin-pud = <3>; | |
| 271 | − samsung,pin-drv = <0>; | |
| 271 | + samsung,pin-function = <EXYNOS_PIN_FUNC_3>; | |
| 272 | + samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; | |
| 273 | + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; | |
| 272 | 274 | }; |
| 273 | 275 | |
| 274 | 276 | sd4_bus8: sd4-bus-width8 { |
| 275 | 277 | part-1 { |
| 276 | 278 | samsung,pins = "gpk0-3", "gpk0-4", |
| 277 | 279 | "gpk0-5", "gpk0-6"; |
| 278 | − samsung,pin-function = <3>; | |
| 279 | − samsung,pin-pud = <3>; | |
| 280 | − samsung,pin-drv = <3>; | |
| 280 | + samsung,pin-function = <EXYNOS_PIN_FUNC_3>; | |
| 281 | + samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; | |
| 282 | + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>; | |
| 281 | 283 | }; |
| 282 | 284 | part-2 { |
| 283 | 285 | samsung,pins = "gpk1-3", "gpk1-4", |
| 284 | 286 | "gpk1-5", "gpk1-6"; |
| 285 | − samsung,pin-function = <4>; | |
| 286 | − samsung,pin-pud = <4>; | |
| 287 | − samsung,pin-drv = <3>; | |
| 287 | + samsung,pin-function = <EXYNOS_PIN_FUNC_4>; | |
| 288 | + samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; | |
| 289 | + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>; | |
| 288 | 290 | }; |
| 289 | 291 | }; |
| 290 | 292 | }; |
| @@ -14,6 +14,11 @@ Required properies: · 13 unmodified lines | ||
| 14 | 14 | - #size-cells : The value of this property must be 1 |
| 15 | 15 | - ranges : defines mapping between pin controller node (parent) to |
| 16 | 16 | gpio-bank node (children). |
| 17 | + - interrupt-parent: phandle of the interrupt parent to which the external | |
| 18 | + GPIO interrupts are forwarded to. | |
| 19 | + - st,syscfg: Should be phandle/offset pair. The phandle to the syscon node | |
| 20 | + which includes IRQ mux selection register, and the offset of the IRQ mux | |
| 21 | + selection register. | |
| 17 | 22 | - pins-are-numbered: Specify the subnodes are using numbered pinmux to |
| 18 | 23 | specify pins. |
| 19 | 24 | |
| @@ -1,35 +0,0 @@ | ||
| 1 | −Device-Tree bindings for charger of Active-semi ACT8945A Multi-Function Device | |
| 2 | − | |
| 3 | −Required properties: | |
| 4 | − - compatible: "active-semi,act8945a", please refer to ../mfd/act8945a.txt. | |
| 5 | − - active-semi,chglev-gpios: charge current level phandle with args | |
| 6 | − as described in ../gpio/gpio.txt. | |
| 7 | − | |
| 8 | −Optional properties: | |
| 9 | − - active-semi,check-battery-temperature: boolean to check the battery | |
| 10 | − temperature or not. | |
| 11 | − - active-semi,input-voltage-threshold-microvolt: unit: mV; | |
| 12 | − Specifies the charger's input over-voltage threshold value; | |
| 13 | − The value can be: 6600, 7000, 7500, 8000; default: 6600 | |
| 14 | − - active-semi,precondition-timeout: unit: minutes; | |
| 15 | − Specifies the charger's PRECONDITION safety timer setting value; | |
| 16 | − The value can be: 40, 60, 80, 0; If 0, it means to disable this timer; | |
| 17 | − default: 40. | |
| 18 | − - active-semi,total-timeout: unit: hours; | |
| 19 | − Specifies the charger's total safety timer setting value; | |
| 20 | − The value can be: 3, 4, 5, 0; If 0, it means to disable this timer; | |
| 21 | − default: 3. | |
| 22 | − | |
| 23 | −Example: | |
| 24 | − pmic@5b { | |
| 25 | − compatible = "active-semi,act8945a"; | |
| 26 | − reg = <0x5b>; | |
| 27 | − status = "okay"; | |
| 28 | − | |
| 29 | − pinctrl-names = "default"; | |
| 30 | − pinctrl-0 = <&pinctrl_charger_chglev>; | |
| 31 | − active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>; | |
| 32 | − active-semi,input-voltage-threshold-microvolt = <6600>; | |
| 33 | − active-semi,precondition-timeout = <40>; | |
| 34 | − active-semi,total-timeout = <3>; | |
| 35 | − }; | |
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
| @@ -1,11 +1,12 @@ | ||
| 1 | 1 | *Device-Tree bindings for ST SW reset functionality |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- compatible: should be "st,<chip>-restart". | |
| 4 | +- compatible: should be "stih407-restart". | |
| 5 | 5 | - st,syscfg: should be a phandle of the syscfg node. |
| 6 | 6 | |
| 7 | 7 | Example node: |
| 8 | 8 | restart { |
| 9 | − compatible = "st,stih416-restart"; | |
| 10 | − st,syscfg = <&syscfg_sbc>; | |
| 9 | + compatible = "st,stih407-restart"; | |
| 10 | + st,syscfg = <&syscfg_sbc_reg>; | |
| 11 | + status = "okay"; | |
| 11 | 12 | }; |
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
| @@ -0,0 +1,48 @@ | ||
| 1 | +Device-Tree bindings for charger of Active-semi ACT8945A Multi-Function Device | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + - compatible: "active-semi,act8945a-charger". | |
| 5 | + - active-semi,chglev-gpios: charge current level phandle with args | |
| 6 | + as described in ../gpio/gpio.txt. | |
| 7 | + - active-semi,lbo-gpios: specify the low battery voltage detect phandle | |
| 8 | + with args as as described in ../gpio/gpio.txt. | |
| 9 | + - interrupts: <a b> where a is the interrupt number and b is a | |
| 10 | + field that represents an encoding of the sense and level | |
| 11 | + information for the interrupt. | |
| 12 | + - interrupt-parent: the phandle for the interrupt controller that | |
| 13 | + services interrupts for this device. | |
| 14 | + | |
| 15 | +Optional properties: | |
| 16 | + - active-semi,input-voltage-threshold-microvolt: unit: mV; | |
| 17 | + Specifies the charger's input over-voltage threshold value; | |
| 18 | + The value can be: 6600, 7000, 7500, 8000; default: 6600 | |
| 19 | + - active-semi,precondition-timeout: unit: minutes; | |
| 20 | + Specifies the charger's PRECONDITION safety timer setting value; | |
| 21 | + The value can be: 40, 60, 80, 0; If 0, it means to disable this timer; | |
| 22 | + default: 40. | |
| 23 | + - active-semi,total-timeout: unit: hours; | |
| 24 | + Specifies the charger's total safety timer setting value; | |
| 25 | + The value can be: 3, 4, 5, 0; If 0, it means to disable this timer; | |
| 26 | + default: 3. | |
| 27 | + | |
| 28 | +Example: | |
| 29 | + pmic@5b { | |
| 30 | + compatible = "active-semi,act8945a"; | |
| 31 | + reg = <0x5b>; | |
| 32 | + status = "okay"; | |
| 33 | + | |
| 34 | + charger { | |
| 35 | + compatible = "active-semi,act8945a-charger"; | |
| 36 | + pinctrl-names = "default"; | |
| 37 | + pinctrl-0 = <&pinctrl_charger_chglev &pinctrl_charger_lbo &pinctrl_charger_irq>; | |
| 38 | + interrupt-parent = <&pioA>; | |
| 39 | + interrupts = <45 GPIO_ACTIVE_LOW>; | |
| 40 | + | |
| 41 | + active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>; | |
| 42 | + active-semi,lbo-gpios = <&pioA 72 GPIO_ACTIVE_LOW>; | |
| 43 | + active-semi,input-voltage-threshold-microvolt = <6600>; | |
| 44 | + active-semi,precondition-timeout = <40>; | |
| 45 | + active-semi,total-timeout = <3>; | |
| 46 | + status = "okay"; | |
| 47 | + }; | |
| 48 | + }; | |
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
| @@ -0,0 +1,23 @@ | ||
| 1 | +Amlogic Meson PWM Controller | |
| 2 | +============================ | |
| 3 | + | |
| 4 | +Required properties: | |
| 5 | +- compatible: Shall contain "amlogic,meson8b-pwm" or "amlogic,meson-gxbb-pwm". | |
| 6 | +- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of | |
| 7 | + the cells format. | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | +- clocks: Could contain one or two parents clocks phandle for each of the two | |
| 11 | + PWM channels. | |
| 12 | +- clock-names: Could contain at least the "clkin0" and/or "clkin1" names. | |
| 13 | + | |
| 14 | +Example: | |
| 15 | + | |
| 16 | + pwm_ab: pwm@8550 { | |
| 17 | + compatible = "amlogic,meson-gxbb-pwm"; | |
| 18 | + reg = <0x0 0x08550 0x0 0x10>; | |
| 19 | + #pwm-cells = <3>; | |
| 20 | + status = "disabled"; | |
| 21 | + clocks = <&xtal>, <&xtal>; | |
| 22 | + clock-names = "clkin0", "clkin1"; | |
| 23 | + } | |
| @@ -2,8 +2,9 @@ MediaTek display PWM controller · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | - compatible: should be "mediatek,<name>-disp-pwm": |
| 5 | − - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. | |
| 5 | + - "mediatek,mt2701-disp-pwm": found on mt2701 SoC. | |
| 6 | 6 | - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. |
| 7 | + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. | |
| 7 | 8 | - reg: physical base address and length of the controller's registers. |
| 8 | 9 | - #pwm-cells: must be 2. See pwm.txt in this directory for a description of |
| 9 | 10 | the cell format. |
| @@ -13,13 +13,14 @@ Required parameters: · 12 unmodified lines | ||
| 13 | 13 | - pinctrl-0: List of phandles pointing to pin configuration nodes |
| 14 | 14 | for PWM module. |
| 15 | 15 | For Pinctrl properties, please refer to [1]. |
| 16 | −- clock-names: Set to "pwm". | |
| 16 | +- clock-names: Valid entries are "pwm" and/or "capture". | |
| 17 | 17 | - clocks: phandle of the clock used by the PWM module. |
| 18 | 18 | For Clk properties, please refer to [2]. |
| 19 | +- interrupts: IRQ for the Capture device | |
| 19 | 20 | |
| 20 | 21 | Optional properties: |
| 21 | −- st,pwm-num-chan: Number of available channels. If not passed, the driver | |
| 22 | − will consider single channel by default. | |
| 22 | +- st,pwm-num-chan: Number of available PWM channels. Default is 0. | |
| 23 | +- st,capture-num-chan: Number of available Capture channels. Default is 0. | |
| 23 | 24 | |
| 24 | 25 | [1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt |
| 25 | 26 | [2] Documentation/devicetree/bindings/clock/clock-bindings.txt |
| @@ -38,4 +39,5 @@ pwm1: pwm@fe510000 { · 12 unmodified lines | ||
| 38 | 39 | clocks = <&clk_sysin>; |
| 39 | 40 | clock-names = "pwm"; |
| 40 | 41 | st,pwm-num-chan = <4>; |
| 42 | + st,capture-num-chan = <2>; | |
| 41 | 43 | }; |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | - "allwinner,sun5i-a10s-pwm" |
| 7 | 7 | - "allwinner,sun5i-a13-pwm" |
| 8 | 8 | - "allwinner,sun7i-a20-pwm" |
| 9 | + - "allwinner,sun8i-h3-pwm" | |
| 9 | 10 | - reg: physical base address and length of the controller's registers |
| 10 | 11 | - #pwm-cells: should be 3. See pwm.txt in this directory for a description of |
| 11 | 12 | the cells format. |
| @@ -0,0 +1,94 @@ | ||
| 1 | +Linear Technology LTC3676 8-output regulators | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: "lltc,ltc3676" | |
| 5 | +- reg: I2C slave address | |
| 6 | + | |
| 7 | +Required child node: | |
| 8 | +- regulators: Contains eight regulator child nodes sw1, sw2, sw3, sw4, | |
| 9 | + ldo1, ldo2, ldo3, and ldo4, specifying the initialization data as | |
| 10 | + documented in Documentation/devicetree/bindings/regulator/regulator.txt. | |
| 11 | + | |
| 12 | +Each regulator is defined using the standard binding for regulators. The | |
| 13 | +nodes for sw1, sw2, sw3, sw4, ldo1, ldo2 and ldo4 additionally need to specify | |
| 14 | +the resistor values of their external feedback voltage dividers: | |
| 15 | + | |
| 16 | +Required properties (not on ldo3): | |
| 17 | +- lltc,fb-voltage-divider: An array of two integers containing the resistor | |
| 18 | + values R1 and R2 of the feedback voltage divider in ohms. | |
| 19 | + | |
| 20 | +Regulators sw1, sw2, sw3, sw4 can regulate the feedback reference from: | |
| 21 | +412.5mV to 800mV in 12.5 mV steps. The output voltage thus ranges between | |
| 22 | +0.4125 * (1 + R1/R2) V and 0.8 * (1 + R1/R2) V. | |
| 23 | + | |
| 24 | +Regulators ldo1, ldo2, and ldo4 have a fixed 0.725 V reference and thus output | |
| 25 | +0.725 * (1 + R1/R2) V. The ldo3 regulator is fixed to 1.8 V. The ldo1 standby | |
| 26 | +regulator can not be disabled and thus should have the regulator-always-on | |
| 27 | +property set. | |
| 28 | + | |
| 29 | +Example: | |
| 30 | + | |
| 31 | + ltc3676: pmic@3c { | |
| 32 | + compatible = "lltc,ltc3676"; | |
| 33 | + reg = <0x3c>; | |
| 34 | + | |
| 35 | + regulators { | |
| 36 | + sw1_reg: sw1 { | |
| 37 | + regulator-min-microvolt = <674400>; | |
| 38 | + regulator-max-microvolt = <1308000>; | |
| 39 | + lltc,fb-voltage-divider = <127000 200000>; | |
| 40 | + regulator-ramp-delay = <7000>; | |
| 41 | + regulator-boot-on; | |
| 42 | + regulator-always-on; | |
| 43 | + }; | |
| 44 | + | |
| 45 | + sw2_reg: sw2 { | |
| 46 | + regulator-min-microvolt = <1033310>; | |
| 47 | + regulator-max-microvolt = <200400>; | |
| 48 | + lltc,fb-voltage-divider = <301000 200000>; | |
| 49 | + regulator-ramp-delay = <7000>; | |
| 50 | + regulator-boot-on; | |
| 51 | + regulator-always-on; | |
| 52 | + }; | |
| 53 | + | |
| 54 | + sw3_reg: sw3 { | |
| 55 | + regulator-min-microvolt = <674400>; | |
| 56 | + regulator-max-microvolt = <130800>; | |
| 57 | + lltc,fb-voltage-divider = <127000 200000>; | |
| 58 | + regulator-ramp-delay = <7000>; | |
| 59 | + regulator-boot-on; | |
| 60 | + regulator-always-on; | |
| 61 | + }; | |
| 62 | + | |
| 63 | + sw4_reg: sw4 { | |
| 64 | + regulator-min-microvolt = <868310>; | |
| 65 | + regulator-max-microvolt = <168400>; | |
| 66 | + lltc,fb-voltage-divider = <221000 200000>; | |
| 67 | + regulator-ramp-delay = <7000>; | |
| 68 | + regulator-boot-on; | |
| 69 | + regulator-always-on; | |
| 70 | + }; | |
| 71 | + | |
| 72 | + ldo2_reg: ldo2 { | |
| 73 | + regulator-min-microvolt = <2490375>; | |
| 74 | + regulator-max-microvolt = <2490375>; | |
| 75 | + lltc,fb-voltage-divider = <487000 200000>; | |
| 76 | + regulator-boot-on; | |
| 77 | + regulator-always-on; | |
| 78 | + }; | |
| 79 | + | |
| 80 | + ldo3_reg: ldo3 { | |
| 81 | + regulator-min-microvolt = <1800000>; | |
| 82 | + regulator-max-microvolt = <1800000>; | |
| 83 | + regulator-boot-on; | |
| 84 | + }; | |
| 85 | + | |
| 86 | + ldo4_reg: ldo4 { | |
| 87 | + regulator-min-microvolt = <3023250>; | |
| 88 | + regulator-max-microvolt = <3023250>; | |
| 89 | + lltc,fb-voltage-divider = <634000 200000>; | |
| 90 | + regulator-boot-on; | |
| 91 | + regulator-always-on; | |
| 92 | + }; | |
| 93 | + }; | |
| 94 | + }; | |
| @@ -1,22 +1,28 @@ | ||
| 1 | 1 | * Powerventure Semiconductor PV88080 Voltage Regulator |
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | −- compatible: "pvs,pv88080". | |
| 5 | −- reg: I2C slave address, usually 0x49. | |
| 4 | +- compatible: Must be one of the following, depending on the | |
| 5 | + silicon version: | |
| 6 | + - "pvs,pv88080" (DEPRECATED) | |
| 7 | + | |
| 8 | + - "pvs,pv88080-aa" for PV88080 AA or AB silicon | |
| 9 | + - "pvs,pv88080-ba" for PV88080 BA or BB silicon | |
| 10 | + NOTE: The use of the compatibles with no silicon version is deprecated. | |
| 11 | +- reg: I2C slave address, usually 0x49 | |
| 6 | 12 | - interrupts: the interrupt outputs of the controller |
| 7 | 13 | - regulators: A node that houses a sub-node for each regulator within the |
| 8 | 14 | device. Each sub-node is identified using the node's name, with valid |
| 9 | 15 | values listed below. The content of each sub-node is defined by the |
| 10 | 16 | standard binding for regulators; see regulator.txt. |
| 11 | − BUCK1, BUCK2, and BUCK3. | |
| 17 | + BUCK1, BUCK2, BUCK3 and HVBUCK. | |
| 12 | 18 | |
| 13 | 19 | Optional properties: |
| 14 | 20 | - Any optional property defined in regulator.txt |
| 15 | 21 | |
| 16 | −Example | |
| 22 | +Example: | |
| 17 | 23 | |
| 18 | 24 | pmic: pv88080@49 { |
| 19 | − compatible = "pvs,pv88080"; | |
| 25 | + compatible = "pvs,pv88080-ba"; | |
| 20 | 26 | reg = <0x49>; |
| 21 | 27 | interrupt-parent = <&gpio>; |
| 22 | 28 | interrupts = <24 24>; |
| @@ -45,5 +51,12 @@ Example · 22 unmodified lines | ||
| 45 | 51 | regulator-min-microamp = <1496000>; |
| 46 | 52 | regulator-max-microamp = <4189000>; |
| 47 | 53 | }; |
| 54 | + | |
| 55 | + HVBUCK { | |
| 56 | + regulator-name = "hvbuck"; | |
| 57 | + regulator-min-microvolt = < 5000>; | |
| 58 | + regulator-max-microvolt = <1275000>; | |
| 59 | + }; | |
| 48 | 60 | }; |
| 49 | 61 | }; |
| 62 | + | |
| @@ -13,7 +13,7 @@ Optional properties: · 12 unmodified lines | ||
| 13 | 13 | - regulator-allow-bypass: allow the regulator to go into bypass mode |
| 14 | 14 | - regulator-allow-set-load: allow the regulator performance level to be configured |
| 15 | 15 | - <name>-supply: phandle to the parent supply/regulator node |
| 16 | −- regulator-ramp-delay: ramp delay for regulator(in uV/uS) | |
| 16 | +- regulator-ramp-delay: ramp delay for regulator(in uV/us) | |
| 17 | 17 | For hardware which supports disabling ramp rate, it should be explicitly |
| 18 | 18 | initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. |
| 19 | 19 | - regulator-enable-ramp-delay: The time taken, in microseconds, for the supply |
| @@ -0,0 +1,132 @@ | ||
| 1 | +Qualcomm WCNSS Peripheral Image Loader | |
| 2 | + | |
| 3 | +This document defines the binding for a component that loads and boots firmware | |
| 4 | +on the Qualcomm WCNSS core. | |
| 5 | + | |
| 6 | +- compatible: | |
| 7 | + Usage: required | |
| 8 | + Value type: <string> | |
| 9 | + Definition: must be one of: | |
| 10 | + "qcom,riva-pil", | |
| 11 | + "qcom,pronto-v1-pil", | |
| 12 | + "qcom,pronto-v2-pil" | |
| 13 | + | |
| 14 | +- reg: | |
| 15 | + Usage: required | |
| 16 | + Value type: <prop-encoded-array> | |
| 17 | + Definition: must specify the base address and size of the CCU, DXE and | |
| 18 | + PMU register blocks | |
| 19 | + | |
| 20 | +- reg-names: | |
| 21 | + Usage: required | |
| 22 | + Value type: <stringlist> | |
| 23 | + Definition: must be "ccu", "dxe", "pmu" | |
| 24 | + | |
| 25 | +- interrupts-extended: | |
| 26 | + Usage: required | |
| 27 | + Value type: <prop-encoded-array> | |
| 28 | + Definition: must list the watchdog and fatal IRQs and may specify the | |
| 29 | + ready, handover and stop-ack IRQs | |
| 30 | + | |
| 31 | +- interrupt-names: | |
| 32 | + Usage: required | |
| 33 | + Value type: <stringlist> | |
| 34 | + Definition: should be "wdog", "fatal", optionally followed by "ready", | |
| 35 | + "handover", "stop-ack" | |
| 36 | + | |
| 37 | +- vddmx-supply: | |
| 38 | +- vddcx-supply: | |
| 39 | +- vddpx-supply: | |
| 40 | + Usage: required | |
| 41 | + Value type: <phandle> | |
| 42 | + Definition: reference to the regulators to be held on behalf of the | |
| 43 | + booting of the WCNSS core | |
| 44 | + | |
| 45 | +- qcom,smem-states: | |
| 46 | + Usage: optional | |
| 47 | + Value type: <prop-encoded-array> | |
| 48 | + Definition: reference to the SMEM state used to indicate to WCNSS that | |
| 49 | + it should shut down | |
| 50 | + | |
| 51 | +- qcom,smem-state-names: | |
| 52 | + Usage: optional | |
| 53 | + Value type: <stringlist> | |
| 54 | + Definition: should be "stop" | |
| 55 | + | |
| 56 | +- memory-region: | |
| 57 | + Usage: required | |
| 58 | + Value type: <prop-encoded-array> | |
| 59 | + Definition: reference to reserved-memory node for the remote processor | |
| 60 | + see ../reserved-memory/reserved-memory.txt | |
| 61 | + | |
| 62 | += SUBNODES | |
| 63 | +A single subnode of the WCNSS PIL describes the attached rf module and its | |
| 64 | +resource dependencies. | |
| 65 | + | |
| 66 | +- compatible: | |
| 67 | + Usage: required | |
| 68 | + Value type: <string> | |
| 69 | + Definition: must be one of: | |
| 70 | + "qcom,wcn3620", | |
| 71 | + "qcom,wcn3660", | |
| 72 | + "qcom,wcn3680" | |
| 73 | + | |
| 74 | +- clocks: | |
| 75 | + Usage: required | |
| 76 | + Value type: <prop-encoded-array> | |
| 77 | + Definition: should specify the xo clock and optionally the rf clock | |
| 78 | + | |
| 79 | +- clock-names: | |
| 80 | + Usage: required | |
| 81 | + Value type: <stringlist> | |
| 82 | + Definition: should be "xo", optionally followed by "rf" | |
| 83 | + | |
| 84 | +- vddxo-supply: | |
| 85 | +- vddrfa-supply: | |
| 86 | +- vddpa-supply: | |
| 87 | +- vdddig-supply: | |
| 88 | + Usage: required | |
| 89 | + Value type: <phandle> | |
| 90 | + Definition: reference to the regulators to be held on behalf of the | |
| 91 | + booting of the WCNSS core | |
| 92 | + | |
| 93 | += EXAMPLE | |
| 94 | +The following example describes the resources needed to boot control the WCNSS, | |
| 95 | +with attached WCN3680, as it is commonly found on MSM8974 boards. | |
| 96 | + | |
| 97 | +pronto@fb204000 { | |
| 98 | + compatible = "qcom,pronto-v2-pil"; | |
| 99 | + reg = <0xfb204000 0x2000>, <0xfb202000 0x1000>, <0xfb21b000 0x3000>; | |
| 100 | + reg-names = "ccu", "dxe", "pmu"; | |
| 101 | + | |
| 102 | + interrupts-extended = <&intc 0 149 1>, | |
| 103 | + <&wcnss_smp2p_slave 0 0>, | |
| 104 | + <&wcnss_smp2p_slave 1 0>, | |
| 105 | + <&wcnss_smp2p_slave 2 0>, | |
| 106 | + <&wcnss_smp2p_slave 3 0>; | |
| 107 | + interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; | |
| 108 | + | |
| 109 | + vddmx-supply = <&pm8841_s1>; | |
| 110 | + vddcx-supply = <&pm8841_s2>; | |
| 111 | + vddpx-supply = <&pm8941_s3>; | |
| 112 | + | |
| 113 | + qcom,smem-states = <&wcnss_smp2p_out 0>; | |
| 114 | + qcom,smem-state-names = "stop"; | |
| 115 | + | |
| 116 | + memory-region = <&wcnss_region>; | |
| 117 | + | |
| 118 | + pinctrl-names = "default"; | |
| 119 | + pinctrl-0 = <&wcnss_pin_a>; | |
| 120 | + | |
| 121 | + iris { | |
| 122 | + compatible = "qcom,wcn3680"; | |
| 123 | + | |
| 124 | + clocks = <&rpmcc RPM_CXO_CLK_SRC>, <&rpmcc RPM_CXO_A2>; | |
| 125 | + clock-names = "xo", "rf"; | |
| 126 | + | |
| 127 | + vddxo-supply = <&pm8941_l6>; | |
| 128 | + vddrfa-supply = <&pm8941_l11>; | |
| 129 | + vddpa-supply = <&pm8941_l19>; | |
| 130 | + vdddig-supply = <&pm8941_s3>; | |
| 131 | + }; | |
| 132 | +}; | |
| @@ -0,0 +1,6 @@ | ||
| 1 | +STMicroelectronics STM32 Peripheral Reset Controller | |
| 2 | +==================================================== | |
| 3 | + | |
| 4 | +The RCC IP is both a reset and a clock controller. | |
| 5 | + | |
| 6 | +Please see Documentation/devicetree/bindings/clock/st,stm32-rcc.txt | |
| @@ -0,0 +1,93 @@ | ||
| 1 | +UniPhier reset controller | |
| 2 | + | |
| 3 | + | |
| 4 | +System reset | |
| 5 | +------------ | |
| 6 | + | |
| 7 | +Required properties: | |
| 8 | +- compatible: should be one of the following: | |
| 9 | + "socionext,uniphier-sld3-reset" - for PH1-sLD3 SoC. | |
| 10 | + "socionext,uniphier-ld4-reset" - for PH1-LD4 SoC. | |
| 11 | + "socionext,uniphier-pro4-reset" - for PH1-Pro4 SoC. | |
| 12 | + "socionext,uniphier-sld8-reset" - for PH1-sLD8 SoC. | |
| 13 | + "socionext,uniphier-pro5-reset" - for PH1-Pro5 SoC. | |
| 14 | + "socionext,uniphier-pxs2-reset" - for ProXstream2/PH1-LD6b SoC. | |
| 15 | + "socionext,uniphier-ld11-reset" - for PH1-LD11 SoC. | |
| 16 | + "socionext,uniphier-ld20-reset" - for PH1-LD20 SoC. | |
| 17 | +- #reset-cells: should be 1. | |
| 18 | + | |
| 19 | +Example: | |
| 20 | + | |
| 21 | + sysctrl@61840000 { | |
| 22 | + compatible = "socionext,uniphier-ld20-sysctrl", | |
| 23 | + "simple-mfd", "syscon"; | |
| 24 | + reg = <0x61840000 0x4000>; | |
| 25 | + | |
| 26 | + reset { | |
| 27 | + compatible = "socionext,uniphier-ld20-reset"; | |
| 28 | + #reset-cells = <1>; | |
| 29 | + }; | |
| 30 | + | |
| 31 | + other nodes ... | |
| 32 | + }; | |
| 33 | + | |
| 34 | + | |
| 35 | +Media I/O (MIO) reset | |
| 36 | +--------------------- | |
| 37 | + | |
| 38 | +Required properties: | |
| 39 | +- compatible: should be one of the following: | |
| 40 | + "socionext,uniphier-sld3-mio-reset" - for PH1-sLD3 SoC. | |
| 41 | + "socionext,uniphier-ld4-mio-reset" - for PH1-LD4 SoC. | |
| 42 | + "socionext,uniphier-pro4-mio-reset" - for PH1-Pro4 SoC. | |
| 43 | + "socionext,uniphier-sld8-mio-reset" - for PH1-sLD8 SoC. | |
| 44 | + "socionext,uniphier-pro5-mio-reset" - for PH1-Pro5 SoC. | |
| 45 | + "socionext,uniphier-pxs2-mio-reset" - for ProXstream2/PH1-LD6b SoC. | |
| 46 | + "socionext,uniphier-ld11-mio-reset" - for PH1-LD11 SoC. | |
| 47 | + "socionext,uniphier-ld20-mio-reset" - for PH1-LD20 SoC. | |
| 48 | +- #reset-cells: should be 1. | |
| 49 | + | |
| 50 | +Example: | |
| 51 | + | |
| 52 | + mioctrl@59810000 { | |
| 53 | + compatible = "socionext,uniphier-ld20-mioctrl", | |
| 54 | + "simple-mfd", "syscon"; | |
| 55 | + reg = <0x59810000 0x800>; | |
| 56 | + | |
| 57 | + reset { | |
| 58 | + compatible = "socionext,uniphier-ld20-mio-reset"; | |
| 59 | + #reset-cells = <1>; | |
| 60 | + }; | |
| 61 | + | |
| 62 | + other nodes ... | |
| 63 | + }; | |
| 64 | + | |
| 65 | + | |
| 66 | +Peripheral reset | |
| 67 | +---------------- | |
| 68 | + | |
| 69 | +Required properties: | |
| 70 | +- compatible: should be one of the following: | |
| 71 | + "socionext,uniphier-ld4-peri-reset" - for PH1-LD4 SoC. | |
| 72 | + "socionext,uniphier-pro4-peri-reset" - for PH1-Pro4 SoC. | |
| 73 | + "socionext,uniphier-sld8-peri-reset" - for PH1-sLD8 SoC. | |
| 74 | + "socionext,uniphier-pro5-peri-reset" - for PH1-Pro5 SoC. | |
| 75 | + "socionext,uniphier-pxs2-peri-reset" - for ProXstream2/PH1-LD6b SoC. | |
| 76 | + "socionext,uniphier-ld11-peri-reset" - for PH1-LD11 SoC. | |
| 77 | + "socionext,uniphier-ld20-peri-reset" - for PH1-LD20 SoC. | |
| 78 | +- #reset-cells: should be 1. | |
| 79 | + | |
| 80 | +Example: | |
| 81 | + | |
| 82 | + perictrl@59820000 { | |
| 83 | + compatible = "socionext,uniphier-ld20-perictrl", | |
| 84 | + "simple-mfd", "syscon"; | |
| 85 | + reg = <0x59820000 0x200>; | |
| 86 | + | |
| 87 | + reset { | |
| 88 | + compatible = "socionext,uniphier-ld20-peri-reset"; | |
| 89 | + #reset-cells = <1>; | |
| 90 | + }; | |
| 91 | + | |
| 92 | + other nodes ... | |
| 93 | + }; | |
| @@ -11,7 +11,7 @@ Optional properties: · 10 unmodified lines | ||
| 11 | 11 | - trickle-diode-disable : Do not use internal trickle charger diode |
| 12 | 12 | Should be given if internal trickle charger diode should be disabled |
| 13 | 13 | Example: |
| 14 | − ds1390: rtc@68 { | |
| 14 | + ds1390: rtc@0 { | |
| 15 | 15 | compatible = "dallas,ds1390"; |
| 16 | 16 | trickle-resistor-ohms = <250>; |
| 17 | 17 | reg = <0>; |
| @@ -0,0 +1,22 @@ | ||
| 1 | +Real Time Clock driver for: | |
| 2 | + - Epson RX8900 | |
| 3 | + - Micro Crystal rv8803 | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | +- compatible: should be: "microcrystal,rv8803" or "epson,rx8900" | |
| 7 | +- reg : the I2C address of the device for I2C | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | +- epson,vdet-disable : boolean, if present will disable voltage detector. | |
| 11 | + Should be set if no backup battery is used. | |
| 12 | +- trickle-diode-disable : boolean, if present will disable internal trickle | |
| 13 | + charger diode | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | + rtc: rtc@32 { | |
| 18 | + compatible = "epson,rx8900" | |
| 19 | + reg = <0x32>; | |
| 20 | + epson,vdet-disable; | |
| 21 | + trickle-diode-disable; | |
| 22 | + }; | |
| @@ -18,6 +18,18 @@ Optional properties: · 17 unmodified lines | ||
| 18 | 18 | through pmic_power_en |
| 19 | 19 | - clocks: Any internal or external clocks feeding in to rtc |
| 20 | 20 | - clock-names: Corresponding names of the clocks |
| 21 | +- pinctrl-0: a phandle pointing to the pin settings for the device | |
| 22 | +- pinctrl-names: should be "default" | |
| 23 | + | |
| 24 | +Optional subnodes: | |
| 25 | +- generic pinctrl node | |
| 26 | + | |
| 27 | +Required pinctrl subnodes properties: | |
| 28 | +- pins - Names of ext_wakeup pins to configure | |
| 29 | + | |
| 30 | +Optional pinctrl subnodes properties: | |
| 31 | +- input-enable - Enables ext_wakeup | |
| 32 | +- ti,active-high - Set input active high (by default active low) | |
| 21 | 33 | |
| 22 | 34 | Example: |
| 23 | 35 | |
| @@ -30,4 +42,13 @@ rtc@1c23000 { · 6 unmodified lines | ||
| 30 | 42 | system-power-controller; |
| 31 | 43 | clocks = <&clk_32k_rtc>, <&clk_32768_ck>; |
| 32 | 44 | clock-names = "ext-clk", "int-clk"; |
| 45 | + | |
| 46 | + pinctrl-0 = <&ext_wakeup>; | |
| 47 | + pinctrl-names = "default"; | |
| 48 | + | |
| 49 | + ext_wakeup: ext-wakeup { | |
| 50 | + pins = "ext_wakeup0"; | |
| 51 | + input-enable; | |
| 52 | + ti,active-high; | |
| 53 | + }; | |
| 33 | 54 | }; |
| @@ -42,6 +42,8 @@ Optional properties: · 41 unmodified lines | ||
| 42 | 42 | - auto-flow-control: one way to enable automatic flow control support. The |
| 43 | 43 | driver is allowed to detect support for the capability even without this |
| 44 | 44 | property. |
| 45 | +- tx-threshold: Specify the TX FIFO low water indication for parts with | |
| 46 | + programmable TX FIFO thresholds. | |
| 45 | 47 | |
| 46 | 48 | Note: |
| 47 | 49 | * fsl,ns16550: |
| @@ -0,0 +1,46 @@ | ||
| 1 | +* STMicroelectronics STM32 USART | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Can be either "st,stm32-usart", "st,stm32-uart", | |
| 5 | +"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether | |
| 6 | +the device supports synchronous mode and is compatible with | |
| 7 | +stm32(f4) or stm32f7. | |
| 8 | +- reg: The address and length of the peripheral registers space | |
| 9 | +- interrupts: The interrupt line of the USART instance | |
| 10 | +- clocks: The input clock of the USART instance | |
| 11 | + | |
| 12 | +Optional properties: | |
| 13 | +- pinctrl: The reference on the pins configuration | |
| 14 | +- st,hw-flow-ctrl: bool flag to enable hardware flow control. | |
| 15 | +- dmas: phandle(s) to DMA controller node(s). Refer to stm32-dma.txt | |
| 16 | +- dma-names: "rx" and/or "tx" | |
| 17 | + | |
| 18 | +Examples: | |
| 19 | +usart4: serial@40004c00 { | |
| 20 | + compatible = "st,stm32-uart"; | |
| 21 | + reg = <0x40004c00 0x400>; | |
| 22 | + interrupts = <52>; | |
| 23 | + clocks = <&clk_pclk1>; | |
| 24 | + pinctrl-names = "default"; | |
| 25 | + pinctrl-0 = <&pinctrl_usart4>; | |
| 26 | +}; | |
| 27 | + | |
| 28 | +usart2: serial@40004400 { | |
| 29 | + compatible = "st,stm32-usart", "st,stm32-uart"; | |
| 30 | + reg = <0x40004400 0x400>; | |
| 31 | + interrupts = <38>; | |
| 32 | + clocks = <&clk_pclk1>; | |
| 33 | + st,hw-flow-ctrl; | |
| 34 | + pinctrl-names = "default"; | |
| 35 | + pinctrl-0 = <&pinctrl_usart2 &pinctrl_usart2_rtscts>; | |
| 36 | +}; | |
| 37 | + | |
| 38 | +usart1: serial@40011000 { | |
| 39 | + compatible = "st,stm32-usart", "st,stm32-uart"; | |
| 40 | + reg = <0x40011000 0x400>; | |
| 41 | + interrupts = <37>; | |
| 42 | + clocks = <&rcc 0 164>; | |
| 43 | + dmas = <&dma2 2 4 0x414 0x0>, | |
| 44 | + <&dma2 7 4 0x414 0x0>; | |
| 45 | + dma-names = "rx", "tx"; | |
| 46 | +}; | |
| @@ -1,21 +0,0 @@ | ||
| 1 | −MediaTek AUXADC | |
| 2 | −=============== | |
| 3 | − | |
| 4 | −The Auxiliary Analog/Digital Converter (AUXADC) is an ADC found | |
| 5 | −in some Mediatek SoCs which among other things measures the temperatures | |
| 6 | −in the SoC. It can be used directly with register accesses, but it is also | |
| 7 | −used by thermal controller which reads the temperatures from the AUXADC | |
| 8 | −directly via its own bus interface. See | |
| 9 | −Documentation/devicetree/bindings/thermal/mediatek-thermal.txt | |
| 10 | −for the Thermal Controller which holds a phandle to the AUXADC. | |
| 11 | − | |
| 12 | −Required properties: | |
| 13 | −- compatible: Must be "mediatek,mt8173-auxadc" | |
| 14 | −- reg: Address range of the AUXADC unit | |
| 15 | − | |
| 16 | −Example: | |
| 17 | − | |
| 18 | −auxadc: auxadc@11001000 { | |
| 19 | − compatible = "mediatek,mt8173-auxadc"; | |
| 20 | − reg = <0 0x11001000 0 0x1000>; | |
| 21 | −}; | |
| @@ -0,0 +1,16 @@ | ||
| 1 | +NAU8810 audio CODEC | |
| 2 | + | |
| 3 | +This device supports I2C only. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | + - compatible : "nuvoton,nau8810" | |
| 8 | + | |
| 9 | + - reg : the I2C address of the device. | |
| 10 | + | |
| 11 | +Example: | |
| 12 | + | |
| 13 | +codec: nau8810@1a { | |
| 14 | + compatible = "nuvoton,nau8810"; | |
| 15 | + reg = <0x1a>; | |
| 16 | +}; | |
| @@ -0,0 +1,42 @@ | ||
| 1 | +NVIDIA Tegra audio complex, with SGTL5000 CODEC | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : "nvidia,tegra-audio-sgtl5000" | |
| 5 | +- clocks : Must contain an entry for each entry in clock-names. | |
| 6 | + See ../clocks/clock-bindings.txt for details. | |
| 7 | +- clock-names : Must include the following entries: | |
| 8 | + - pll_a | |
| 9 | + - pll_a_out0 | |
| 10 | + - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) | |
| 11 | +- nvidia,model : The user-visible name of this sound complex. | |
| 12 | +- nvidia,audio-routing : A list of the connections between audio components. | |
| 13 | + Each entry is a pair of strings, the first being the connection's sink, | |
| 14 | + the second being the connection's source. Valid names for sources and | |
| 15 | + sinks are the SGTL5000's pins (as documented in its binding), and the jacks | |
| 16 | + on the board: | |
| 17 | + | |
| 18 | + * Headphone Jack | |
| 19 | + * Line In Jack | |
| 20 | + * Mic Jack | |
| 21 | + | |
| 22 | +- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's | |
| 23 | + connected to the CODEC. | |
| 24 | +- nvidia,audio-codec : The phandle of the SGTL5000 audio codec. | |
| 25 | + | |
| 26 | +Example: | |
| 27 | + | |
| 28 | +sound { | |
| 29 | + compatible = "toradex,tegra-audio-sgtl5000-apalis_t30", | |
| 30 | + "nvidia,tegra-audio-sgtl5000"; | |
| 31 | + nvidia,model = "Toradex Apalis T30"; | |
| 32 | + nvidia,audio-routing = | |
| 33 | + "Headphone Jack", "HP_OUT", | |
| 34 | + "LINE_IN", "Line In Jack", | |
| 35 | + "MIC_IN", "Mic Jack"; | |
| 36 | + nvidia,i2s-controller = <&tegra_i2s2>; | |
| 37 | + nvidia,audio-codec = <&sgtl5000>; | |
| 38 | + clocks = <&tegra_car TEGRA30_CLK_PLL_A>, | |
| 39 | + <&tegra_car TEGRA30_CLK_PLL_A_OUT0>, | |
| 40 | + <&tegra_car TEGRA30_CLK_EXTERN1>; | |
| 41 | + clock-names = "pll_a", "pll_a_out0", "mclk"; | |
| 42 | +}; | |
| @@ -16,6 +16,24 @@ Required properties: · 15 unmodified lines | ||
| 16 | 16 | * "spkr-iomux" |
| 17 | 17 | - qcom,model : Name of the sound card. |
| 18 | 18 | |
| 19 | +- qcom,audio-routing : A list of the connections between audio components. | |
| 20 | + Each entry is a pair of strings, the first being the | |
| 21 | + connection's sink, the second being the connection's | |
| 22 | + source. Valid names could be power supplies, MicBias | |
| 23 | + of msm8x16_wcd codec and the jacks on the board: | |
| 24 | + | |
| 25 | + Power supplies: | |
| 26 | + * MIC BIAS External1 | |
| 27 | + * MIC BIAS External2 | |
| 28 | + * MIC BIAS Internal1 | |
| 29 | + * MIC BIAS Internal2 | |
| 30 | + | |
| 31 | + Board connectors: | |
| 32 | + * Headset Mic | |
| 33 | + * Secondary Mic", | |
| 34 | + * DMIC | |
| 35 | + * Ext Spk | |
| 36 | + | |
| 19 | 37 | Dai-link subnode properties and subnodes: |
| 20 | 38 | |
| 21 | 39 | Required dai-link subnodes: |
| @@ -37,6 +55,18 @@ sound: sound { · 15 unmodified lines | ||
| 37 | 55 | reg-names = "mic-iomux", "spkr-iomux"; |
| 38 | 56 | qcom,model = "DB410c"; |
| 39 | 57 | |
| 58 | + qcom,audio-routing = | |
| 59 | + "MIC BIAS External1", "Handset Mic", | |
| 60 | + "MIC BIAS Internal2", "Headset Mic", | |
| 61 | + "MIC BIAS External1", "Secondary Mic", | |
| 62 | + "AMIC1", "MIC BIAS External1", | |
| 63 | + "AMIC2", "MIC BIAS Internal2", | |
| 64 | + "AMIC3", "MIC BIAS External1", | |
| 65 | + "DMIC1", "MIC BIAS Internal1", | |
| 66 | + "MIC BIAS Internal1", "Digital Mic1", | |
| 67 | + "DMIC2", "MIC BIAS Internal1", | |
| 68 | + "MIC BIAS Internal1", "Digital Mic2"; | |
| 69 | + | |
| 40 | 70 | /* I2S - Internal codec */ |
| 41 | 71 | internal-dai-link@0 { |
| 42 | 72 | cpu { /* PRIMARY */ |
| @@ -1,75 +0,0 @@ | ||
| 1 | −Renesas Sampling Rate Convert Sound Card: | |
| 2 | − | |
| 3 | −Renesas Sampling Rate Convert Sound Card specifies audio DAI connections of SoC <-> codec. | |
| 4 | − | |
| 5 | −Required properties: | |
| 6 | − | |
| 7 | −- compatible : "renesas,rsrc-card{,<board>}" | |
| 8 | − Examples with boards are: | |
| 9 | − - "renesas,rsrc-card" | |
| 10 | − - "renesas,rsrc-card,lager" | |
| 11 | − - "renesas,rsrc-card,koelsch" | |
| 12 | −Optional properties: | |
| 13 | − | |
| 14 | −- card_name : User specified audio sound card name, one string | |
| 15 | − property. | |
| 16 | −- cpu : CPU sub-node | |
| 17 | −- codec : CODEC sub-node | |
| 18 | − | |
| 19 | −Optional subnode properties: | |
| 20 | − | |
| 21 | −- format : CPU/CODEC common audio format. | |
| 22 | − "i2s", "right_j", "left_j" , "dsp_a" | |
| 23 | − "dsp_b", "ac97", "pdm", "msb", "lsb" | |
| 24 | −- frame-master : Indicates dai-link frame master. | |
| 25 | − phandle to a cpu or codec subnode. | |
| 26 | −- bitclock-master : Indicates dai-link bit clock master. | |
| 27 | − phandle to a cpu or codec subnode. | |
| 28 | −- bitclock-inversion : bool property. Add this if the | |
| 29 | − dai-link uses bit clock inversion. | |
| 30 | −- frame-inversion : bool property. Add this if the | |
| 31 | − dai-link uses frame clock inversion. | |
| 32 | −- convert-rate : platform specified sampling rate convert | |
| 33 | −- convert-channels : platform specified converted channel size (2 - 8 ch) | |
| 34 | −- audio-prefix : see audio-routing | |
| 35 | −- audio-routing : A list of the connections between audio components. | |
| 36 | − Each entry is a pair of strings, the first being the connection's sink, | |
| 37 | − the second being the connection's source. Valid names for sources. | |
| 38 | − use audio-prefix if some components is using same sink/sources naming. | |
| 39 | − it can be used if compatible was "renesas,rsrc-card"; | |
| 40 | − | |
| 41 | −Required CPU/CODEC subnodes properties: | |
| 42 | − | |
| 43 | −- sound-dai : phandle and port of CPU/CODEC | |
| 44 | − | |
| 45 | −Optional CPU/CODEC subnodes properties: | |
| 46 | − | |
| 47 | −- clocks / system-clock-frequency : specify subnode's clock if needed. | |
| 48 | − it can be specified via "clocks" if system has | |
| 49 | − clock node (= common clock), or "system-clock-frequency" | |
| 50 | − (if system doens't support common clock) | |
| 51 | − If a clock is specified, it is | |
| 52 | − enabled with clk_prepare_enable() | |
| 53 | − in dai startup() and disabled with | |
| 54 | − clk_disable_unprepare() in dai | |
| 55 | − shutdown(). | |
| 56 | − | |
| 57 | −Example | |
| 58 | − | |
| 59 | −sound { | |
| 60 | − compatible = "renesas,rsrc-card,lager"; | |
| 61 | − | |
| 62 | − card-name = "rsnd-ak4643"; | |
| 63 | − format = "left_j"; | |
| 64 | − bitclock-master = <&sndcodec>; | |
| 65 | − frame-master = <&sndcodec>; | |
| 66 | − | |
| 67 | − sndcpu: cpu { | |
| 68 | − sound-dai = <&rcar_sound>; | |
| 69 | − }; | |
| 70 | − | |
| 71 | − sndcodec: codec { | |
| 72 | − sound-dai = <&ak4643>; | |
| 73 | − system-clock-frequency = <11289600>; | |
| 74 | − }; | |
| 75 | −}; | |
| @@ -0,0 +1,22 @@ | ||
| 1 | +ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: "rockchip,rk3399-gru-sound" | |
| 5 | +- rockchip,cpu: The phandle of the Rockchip I2S controller that's | |
| 6 | + connected to the codecs | |
| 7 | +- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs | |
| 8 | + | |
| 9 | +Optional properties: | |
| 10 | +- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready. | |
| 11 | + If this option is specified, which means it's required dmic need | |
| 12 | + delay for DMIC to ready so that rt5514 can avoid recording before | |
| 13 | + DMIC send valid data | |
| 14 | + | |
| 15 | +Example: | |
| 16 | + | |
| 17 | +sound { | |
| 18 | + compatible = "rockchip,rk3399-gru-sound"; | |
| 19 | + rockchip,cpu = <&i2s0>; | |
| 20 | + rockchip,codec = <&max98357a &rt5514 &da7219>; | |
| 21 | + dmic-wakeup-delay-ms = <20>; | |
| 22 | +}; | |
| @@ -12,6 +12,9 @@ Required properties: · 11 unmodified lines | ||
| 12 | 12 | |
| 13 | 13 | Optional properties: |
| 14 | 14 | |
| 15 | +- clocks: The phandle of the master clock to the CODEC | |
| 16 | +- clock-names: Should be "mclk" | |
| 17 | + | |
| 15 | 18 | - realtek,in1-differential |
| 16 | 19 | - realtek,in3-differential |
| 17 | 20 | - realtek,in4-differential |
| @@ -0,0 +1,47 @@ | ||
| 1 | +RT5660 audio CODEC | |
| 2 | + | |
| 3 | +This device supports I2C only. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : "realtek,rt5660". | |
| 8 | + | |
| 9 | +- reg : The I2C address of the device. | |
| 10 | + | |
| 11 | +Optional properties: | |
| 12 | + | |
| 13 | +- clocks: The phandle of the master clock to the CODEC | |
| 14 | +- clock-names: Should be "mclk" | |
| 15 | + | |
| 16 | +- realtek,in1-differential | |
| 17 | +- realtek,in3-differential | |
| 18 | + Boolean. Indicate MIC1/3 input are differential, rather than single-ended. | |
| 19 | + | |
| 20 | +- realtek,poweroff-in-suspend | |
| 21 | + Boolean. If the codec will be powered off in suspend, the resume should be | |
| 22 | + added delay time for waiting codec power ready. | |
| 23 | + | |
| 24 | +- realtek,dmic1-data-pin | |
| 25 | + 0: dmic1 is not used | |
| 26 | + 1: using GPIO2 pin as dmic1 data pin | |
| 27 | + 2: using IN1P pin as dmic1 data pin | |
| 28 | + | |
| 29 | +Pins on the device (for linking into audio routes) for RT5660: | |
| 30 | + | |
| 31 | + * DMIC L1 | |
| 32 | + * DMIC R1 | |
| 33 | + * IN1P | |
| 34 | + * IN1N | |
| 35 | + * IN2P | |
| 36 | + * IN3P | |
| 37 | + * IN3N | |
| 38 | + * SPO | |
| 39 | + * LOUTL | |
| 40 | + * LOUTR | |
| 41 | + | |
| 42 | +Example: | |
| 43 | + | |
| 44 | +rt5660 { | |
| 45 | + compatible = "realtek,rt5660"; | |
| 46 | + reg = <0x1c>; | |
| 47 | +}; | |
| @@ -0,0 +1,30 @@ | ||
| 1 | +RT5663/RT5668 audio CODEC | |
| 2 | + | |
| 3 | +This device supports I2C only. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : One of "realtek,rt5663" or "realtek,rt5668". | |
| 8 | + | |
| 9 | +- reg : The I2C address of the device. | |
| 10 | + | |
| 11 | +- interrupts : The CODEC's interrupt output. | |
| 12 | + | |
| 13 | +Optional properties: | |
| 14 | + | |
| 15 | +Pins on the device (for linking into audio routes) for RT5663/RT5668: | |
| 16 | + | |
| 17 | + * IN1P | |
| 18 | + * IN1N | |
| 19 | + * IN2P | |
| 20 | + * IN2N | |
| 21 | + * HPOL | |
| 22 | + * HPOR | |
| 23 | + | |
| 24 | +Example: | |
| 25 | + | |
| 26 | +codec: rt5663@12 { | |
| 27 | + compatible = "realtek,rt5663"; | |
| 28 | + reg = <0x12>; | |
| 29 | + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; | |
| 30 | +}; | |
| @@ -22,6 +22,8 @@ Optional properties: · 21 unmodified lines | ||
| 22 | 22 | headphones are attached. |
| 23 | 23 | - simple-audio-card,mic-det-gpio : Reference to GPIO that signals when |
| 24 | 24 | a microphone is attached. |
| 25 | +- simple-audio-card,aux-devs : List of phandles pointing to auxiliary devices, such | |
| 26 | + as amplifiers, to be added to the sound card. | |
| 25 | 27 | |
| 26 | 28 | Optional subnodes: |
| 27 | 29 | |
| @@ -162,3 +164,38 @@ sound { · 134 unmodified lines | ||
| 162 | 164 | }; |
| 163 | 165 | }; |
| 164 | 166 | }; |
| 167 | + | |
| 168 | +Example 3 - route audio from IMX6 SSI2 through TLV320DAC3100 codec | |
| 169 | +through TPA6130A2 amplifier to headphones: | |
| 170 | + | |
| 171 | +&i2c0 { | |
| 172 | + codec: tlv320dac3100@18 { | |
| 173 | + compatible = "ti,tlv320dac3100"; | |
| 174 | + ... | |
| 175 | + } | |
| 176 | + | |
| 177 | + amp: tpa6130a2@60 { | |
| 178 | + compatible = "ti,tpa6130a2"; | |
| 179 | + ... | |
| 180 | + } | |
| 181 | +} | |
| 182 | + | |
| 183 | +sound { | |
| 184 | + compatible = "simple-audio-card"; | |
| 185 | + ... | |
| 186 | + simple-audio-card,widgets = | |
| 187 | + "Headphone", "Headphone Jack"; | |
| 188 | + simple-audio-card,routing = | |
| 189 | + "Headphone Jack", "HPLEFT", | |
| 190 | + "Headphone Jack", "HPRIGHT", | |
| 191 | + "LEFTIN", "HPL", | |
| 192 | + "RIGHTIN", "HPR"; | |
| 193 | + simple-audio-card,aux-devs = <&>; | |
| 194 | + simple-audio-card,cpu { | |
| 195 | + sound-dai = <&ssi2>; | |
| 196 | + }; | |
| 197 | + simple-audio-card,codec { | |
| 198 | + sound-dai = <&codec>; | |
| 199 | + clocks = ... | |
| 200 | + }; | |
| 201 | +}; | |
| @@ -0,0 +1,110 @@ | ||
| 1 | +ASoC simple SCU Sound Card | |
| 2 | + | |
| 3 | +Simple-Card specifies audio DAI connections of SoC <-> codec. | |
| 4 | + | |
| 5 | +Required properties: | |
| 6 | + | |
| 7 | +- compatible : "simple-scu-audio-card" | |
| 8 | + "renesas,rsrc-card" | |
| 9 | + | |
| 10 | +Optional properties: | |
| 11 | + | |
| 12 | +- simple-audio-card,name : User specified audio sound card name, one string | |
| 13 | + property. | |
| 14 | +- simple-audio-card,cpu : CPU sub-node | |
| 15 | +- simple-audio-card,codec : CODEC sub-node | |
| 16 | + | |
| 17 | +Optional subnode properties: | |
| 18 | + | |
| 19 | +- simple-audio-card,format : CPU/CODEC common audio format. | |
| 20 | + "i2s", "right_j", "left_j" , "dsp_a" | |
| 21 | + "dsp_b", "ac97", "pdm", "msb", "lsb" | |
| 22 | +- simple-audio-card,frame-master : Indicates dai-link frame master. | |
| 23 | + phandle to a cpu or codec subnode. | |
| 24 | +- simple-audio-card,bitclock-master : Indicates dai-link bit clock master. | |
| 25 | + phandle to a cpu or codec subnode. | |
| 26 | +- simple-audio-card,bitclock-inversion : bool property. Add this if the | |
| 27 | + dai-link uses bit clock inversion. | |
| 28 | +- simple-audio-card,frame-inversion : bool property. Add this if the | |
| 29 | + dai-link uses frame clock inversion. | |
| 30 | +- simple-audio-card,convert-rate : platform specified sampling rate convert | |
| 31 | +- simple-audio-card,convert-channels : platform specified converted channel size (2 - 8 ch) | |
| 32 | +- simple-audio-card,prefix : see audio-routing | |
| 33 | +- simple-audio-card,routing : A list of the connections between audio components. | |
| 34 | + Each entry is a pair of strings, the first being the connection's sink, | |
| 35 | + the second being the connection's source. Valid names for sources. | |
| 36 | + use audio-prefix if some components is using same sink/sources naming. | |
| 37 | + it can be used if compatible was "renesas,rsrc-card"; | |
| 38 | + | |
| 39 | +Required CPU/CODEC subnodes properties: | |
| 40 | + | |
| 41 | +- sound-dai : phandle and port of CPU/CODEC | |
| 42 | + | |
| 43 | +Optional CPU/CODEC subnodes properties: | |
| 44 | + | |
| 45 | +- clocks / system-clock-frequency : specify subnode's clock if needed. | |
| 46 | + it can be specified via "clocks" if system has | |
| 47 | + clock node (= common clock), or "system-clock-frequency" | |
| 48 | + (if system doens't support common clock) | |
| 49 | + If a clock is specified, it is | |
| 50 | + enabled with clk_prepare_enable() | |
| 51 | + in dai startup() and disabled with | |
| 52 | + clk_disable_unprepare() in dai | |
| 53 | + shutdown(). | |
| 54 | + | |
| 55 | +Example 1. Sampling Rate Covert | |
| 56 | + | |
| 57 | +sound { | |
| 58 | + compatible = "simple-scu-audio-card"; | |
| 59 | + | |
| 60 | + simple-audio-card,name = "rsnd-ak4643"; | |
| 61 | + simple-audio-card,format = "left_j"; | |
| 62 | + simple-audio-card,format = "left_j"; | |
| 63 | + simple-audio-card,bitclock-master = <&sndcodec>; | |
| 64 | + simple-audio-card,frame-master = <&sndcodec>; | |
| 65 | + | |
| 66 | + simple-audio-card,convert-rate = <48000>; /* see audio_clk_a */ | |
| 67 | + | |
| 68 | + simple-audio-card,prefix = "ak4642"; | |
| 69 | + simple-audio-card,routing = "ak4642 Playback", "DAI0 Playback", | |
| 70 | + "DAI0 Capture", "ak4642 Capture"; | |
| 71 | + | |
| 72 | + sndcpu: simple-audio-card,cpu { | |
| 73 | + sound-dai = <&rcar_sound>; | |
| 74 | + }; | |
| 75 | + | |
| 76 | + sndcodec: simple-audio-card,codec { | |
| 77 | + sound-dai = <&ak4643>; | |
| 78 | + system-clock-frequency = <11289600>; | |
| 79 | + }; | |
| 80 | +}; | |
| 81 | + | |
| 82 | +Example 2. 2 CPU 1 Codec | |
| 83 | + | |
| 84 | +sound { | |
| 85 | + compatible = "renesas,rsrc-card"; | |
| 86 | + | |
| 87 | + card-name = "rsnd-ak4643"; | |
| 88 | + format = "left_j"; | |
| 89 | + bitclock-master = <&dpcmcpu>; | |
| 90 | + frame-master = <&dpcmcpu>; | |
| 91 | + | |
| 92 | + convert-rate = <48000>; /* see audio_clk_a */ | |
| 93 | + | |
| 94 | + audio-prefix = "ak4642"; | |
| 95 | + audio-routing = "ak4642 Playback", "DAI0 Playback", | |
| 96 | + "ak4642 Playback", "DAI1 Playback"; | |
| 97 | + | |
| 98 | + dpcmcpu: cpu@0 { | |
| 99 | + sound-dai = <&rcar_sound 0>; | |
| 100 | + }; | |
| 101 | + | |
| 102 | + cpu@1 { | |
| 103 | + sound-dai = <&rcar_sound 1>; | |
| 104 | + }; | |
| 105 | + | |
| 106 | + codec { | |
| 107 | + sound-dai = <&ak4643>; | |
| 108 | + clocks = <&audio_clock>; | |
| 109 | + }; | |
| 110 | +}; | |
| @@ -11,7 +11,9 @@ Documentation/devicetree/bindings/sound/simple-card.txt. · 10 unmodified lines | ||
| 11 | 11 | --------------------------------------- |
| 12 | 12 | |
| 13 | 13 | Required properties: |
| 14 | − - compatible: "st,sti-uni-player" or "st,sti-uni-reader" | |
| 14 | + - compatible: "st,stih407-uni-player-hdmi", "st,stih407-uni-player-pcm-out", | |
| 15 | + "st,stih407-uni-player-dac", "st,stih407-uni-player-spdif", | |
| 16 | + "st,stih407-uni-reader-pcm_in", "st,stih407-uni-reader-hdmi", | |
| 15 | 17 | |
| 16 | 18 | - st,syscfg: phandle to boot-device system configuration registers |
| 17 | 19 | |
| @@ -33,32 +35,24 @@ Required properties: · 15 unmodified lines | ||
| 33 | 35 | "tx" for "st,sti-uni-player" compatibility |
| 34 | 36 | "rx" for "st,sti-uni-reader" compatibility |
| 35 | 37 | |
| 36 | − - st,version: IP version integrated in SOC. | |
| 37 | − | |
| 38 | − - dai-name: DAI name that describes the IP. | |
| 39 | − | |
| 40 | − - st,mode: IP working mode depending on associated codec. | |
| 41 | − "HDMI" connected to HDMI codec and support IEC HDMI formats (player only). | |
| 42 | − "SPDIF" connected to SPDIF codec and support SPDIF formats (player only). | |
| 43 | − "PCM" PCM standard mode for I2S or TDM bus. | |
| 44 | − "TDM" TDM mode for TDM bus. | |
| 45 | − | |
| 46 | 38 | Required properties ("st,sti-uni-player" compatibility only): |
| 47 | 39 | - clocks: CPU_DAI IP clock source, listed in the same order than the |
| 48 | 40 | CPU_DAI properties. |
| 49 | 41 | |
| 50 | − - st,uniperiph-id: internal SOC IP instance ID. | |
| 51 | − | |
| 52 | 42 | Optional properties: |
| 53 | 43 | - pinctrl-0: defined for CPU_DAI@1 and CPU_DAI@4 to describe I2S PIOs for |
| 54 | 44 | external codecs connection. |
| 55 | 45 | |
| 56 | 46 | - pinctrl-names: should contain only one value - "default". |
| 57 | 47 | |
| 48 | + - st,tdm-mode: to declare to set TDM mode for unireader and uniplayer IPs. | |
| 49 | + Only compartible with IPs in charge of the external I2S/TDM bus. | |
| 50 | + Should be declared depending on associated codec. | |
| 51 | + | |
| 58 | 52 | Example: |
| 59 | 53 | |
| 60 | − sti_uni_player1: sti-uni-player@1 { | |
| 61 | − compatible = "st,sti-uni-player"; | |
| 54 | + sti_uni_player1: sti-uni-player@0x8D81000 { | |
| 55 | + compatible = "st,stih407-uni-player-hdmi"; | |
| 62 | 56 | status = "okay"; |
| 63 | 57 | #sound-dai-cells = <0>; |
| 64 | 58 | st,syscfg = <&syscfg_core>; |
| @@ -66,15 +60,12 @@ Example: · 1 unmodified line | ||
| 66 | 60 | reg = <0x8D81000 0x158>; |
| 67 | 61 | interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>; |
| 68 | 62 | dmas = <&fdma0 3 0 1>; |
| 69 | − st,dai-name = "Uni Player #1 (I2S)"; | |
| 70 | 63 | dma-names = "tx"; |
| 71 | − st,uniperiph-id = <1>; | |
| 72 | − st,version = <5>; | |
| 73 | − st,mode = "TDM"; | |
| 64 | + st,tdm-mode = <1>; | |
| 74 | 65 | }; |
| 75 | 66 | |
| 76 | − sti_uni_player2: sti-uni-player@2 { | |
| 77 | − compatible = "st,sti-uni-player"; | |
| 67 | + sti_uni_player2: sti-uni-player@0x8D82000 { | |
| 68 | + compatible = "st,stih407-uni-player-pcm-out"; | |
| 78 | 69 | status = "okay"; |
| 79 | 70 | #sound-dai-cells = <0>; |
| 80 | 71 | st,syscfg = <&syscfg_core>; |
| @@ -82,15 +73,11 @@ Example: · 1 unmodified line | ||
| 82 | 73 | reg = <0x8D82000 0x158>; |
| 83 | 74 | interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>; |
| 84 | 75 | dmas = <&fdma0 4 0 1>; |
| 85 | − dai-name = "Uni Player #2 (DAC)"; | |
| 86 | 76 | dma-names = "tx"; |
| 87 | − st,uniperiph-id = <2>; | |
| 88 | − st,version = <5>; | |
| 89 | − st,mode = "PCM"; | |
| 90 | 77 | }; |
| 91 | 78 | |
| 92 | − sti_uni_player3: sti-uni-player@3 { | |
| 93 | − compatible = "st,sti-uni-player"; | |
| 79 | + sti_uni_player3: sti-uni-player@0x8D85000 { | |
| 80 | + compatible = "st,stih407-uni-player-spdif"; | |
| 94 | 81 | status = "okay"; |
| 95 | 82 | #sound-dai-cells = <0>; |
| 96 | 83 | st,syscfg = <&syscfg_core>; |
| @@ -99,14 +86,10 @@ Example: · 2 unmodified lines | ||
| 99 | 86 | interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>; |
| 100 | 87 | dmas = <&fdma0 7 0 1>; |
| 101 | 88 | dma-names = "tx"; |
| 102 | − dai-name = "Uni Player #3 (SPDIF)"; | |
| 103 | − st,uniperiph-id = <3>; | |
| 104 | − st,version = <5>; | |
| 105 | − st,mode = "SPDIF"; | |
| 106 | 89 | }; |
| 107 | 90 | |
| 108 | − sti_uni_reader1: sti-uni-reader@1 { | |
| 109 | − compatible = "st,sti-uni-reader"; | |
| 91 | + sti_uni_reader1: sti-uni-reader@0x8D84000 { | |
| 92 | + compatible = "st,stih407-uni-reader-hdmi"; | |
| 110 | 93 | status = "disabled"; |
| 111 | 94 | #sound-dai-cells = <0>; |
| 112 | 95 | st,syscfg = <&syscfg_core>; |
| @@ -114,9 +97,6 @@ Example: · 1 unmodified line | ||
| 114 | 97 | interrupts = <GIC_SPI 88 IRQ_TYPE_NONE>; |
| 115 | 98 | dmas = <&fdma0 6 0 1>; |
| 116 | 99 | dma-names = "rx"; |
| 117 | − dai-name = "Uni Reader #1 (HDMI RX)"; | |
| 118 | − st,version = <3>; | |
| 119 | − st,mode = "PCM"; | |
| 120 | 100 | }; |
| 121 | 101 | |
| 122 | 102 | 2) sti-sas-codec: internal audio codec IPs driver |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | |
| 10 | 10 | - compatible : should be one of the following: |
| 11 | 11 | - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC |
| 12 | + - "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC | |
| 12 | 13 | |
| 13 | 14 | - reg : Offset and length of the register set for the device. |
| 14 | 15 | |
| @@ -25,6 +26,8 @@ Required properties: · 10 unmodified lines | ||
| 25 | 26 | "apb" clock for the spdif bus. |
| 26 | 27 | "spdif" clock for spdif controller. |
| 27 | 28 | |
| 29 | + - resets : reset specifier for the ahb reset (A31 and newer only) | |
| 30 | + | |
| 28 | 31 | Example: |
| 29 | 32 | |
| 30 | 33 | spdif: spdif@01c21000 { |
| @@ -11,6 +11,7 @@ Required properties: · 10 unmodified lines | ||
| 11 | 11 | "ti,tlv320aic3110" - TLV320AIC3110 (stereo speaker amp, no MiniDSP) |
| 12 | 12 | "ti,tlv320aic3120" - TLV320AIC3120 (mono speaker amp, MiniDSP) |
| 13 | 13 | "ti,tlv320aic3111" - TLV320AIC3111 (stereo speaker amp, MiniDSP) |
| 14 | + "ti,tlv320dac3100" - TLV320DAC3100 (no ADC, mono speaker amp, no MiniDSP) | |
| 14 | 15 | |
| 15 | 16 | - reg - <int> - I2C slave address |
| 16 | 17 | - HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply, |
| @@ -37,9 +38,11 @@ CODEC output pins: · 20 unmodified lines | ||
| 37 | 38 | * MICBIAS |
| 38 | 39 | |
| 39 | 40 | CODEC input pins: |
| 40 | − * MIC1LP | |
| 41 | − * MIC1RP | |
| 42 | − * MIC1LM | |
| 41 | + * MIC1LP, devices with ADC | |
| 42 | + * MIC1RP, devices with ADC | |
| 43 | + * MIC1LM, devices with ADC | |
| 44 | + * AIN1, devices without ADC | |
| 45 | + * AIN2, devices without ADC | |
| 43 | 46 | |
| 44 | 47 | The pins can be used in referring sound node's audio-routing property. |
| 45 | 48 | |
| @@ -0,0 +1,233 @@ | ||
| 1 | +Broadcom SPI controller | |
| 2 | + | |
| 3 | +The Broadcom SPI controller is a SPI master found on various SOCs, including | |
| 4 | +BRCMSTB (BCM7XXX), Cygnus, NSP and NS2. The Broadcom Master SPI hw IP consits | |
| 5 | +of : | |
| 6 | + MSPI : SPI master controller can read and write to a SPI slave device | |
| 7 | + BSPI : Broadcom SPI in combination with the MSPI hw IP provides acceleration | |
| 8 | + for flash reads and be configured to do single, double, quad lane | |
| 9 | + io with 3-byte and 4-byte addressing support. | |
| 10 | + | |
| 11 | + Supported Broadcom SoCs have one instance of MSPI+BSPI controller IP. | |
| 12 | + MSPI master can be used wihout BSPI. BRCMSTB SoCs have an additional instance | |
| 13 | + of a MSPI master without the BSPI to use with non flash slave devices that | |
| 14 | + use SPI protocol. | |
| 15 | + | |
| 16 | +Required properties: | |
| 17 | + | |
| 18 | +- #address-cells: | |
| 19 | + Must be <1>, as required by generic SPI binding. | |
| 20 | + | |
| 21 | +- #size-cells: | |
| 22 | + Must be <0>, also as required by generic SPI binding. | |
| 23 | + | |
| 24 | +- compatible: | |
| 25 | + Must be one of : | |
| 26 | + "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-qspi" : MSPI+BSPI on BRCMSTB SoCs | |
| 27 | + "brcm,spi-bcm-qspi", "brcm,spi-brcmstb-mspi" : Second Instance of MSPI | |
| 28 | + BRCMSTB SoCs | |
| 29 | + "brcm,spi-bcm-qspi", "brcm,spi-nsp-qspi" : MSPI+BSPI on Cygnus, NSP | |
| 30 | + "brcm,spi-bcm-qspi", "brcm,spi-ns2-qspi" : NS2 SoCs | |
| 31 | + | |
| 32 | +- reg: | |
| 33 | + Define the bases and ranges of the associated I/O address spaces. | |
| 34 | + The required range is MSPI controller registers. | |
| 35 | + | |
| 36 | +- reg-names: | |
| 37 | + First name does not matter, but must be reserved for the MSPI controller | |
| 38 | + register range as mentioned in 'reg' above, and will typically contain | |
| 39 | + - "bspi_regs": BSPI register range, not required with compatible | |
| 40 | + "spi-brcmstb-mspi" | |
| 41 | + - "mspi_regs": MSPI register range is required for compatible strings | |
| 42 | + - "intr_regs", "intr_status_reg" : Interrupt and status register for | |
| 43 | + NSP, NS2, Cygnus SoC | |
| 44 | + | |
| 45 | +- interrupts | |
| 46 | + The interrupts used by the MSPI and/or BSPI controller. | |
| 47 | + | |
| 48 | +- interrupt-names: | |
| 49 | + Names of interrupts associated with MSPI | |
| 50 | + - "mspi_halted" : | |
| 51 | + - "mspi_done": Indicates that the requested SPI operation is complete. | |
| 52 | + - "spi_lr_fullness_reached" : Linear read BSPI pipe full | |
| 53 | + - "spi_lr_session_aborted" : Linear read BSPI pipe aborted | |
| 54 | + - "spi_lr_impatient" : Linear read BSPI requested when pipe empty | |
| 55 | + - "spi_lr_session_done" : Linear read BSPI session done | |
| 56 | + | |
| 57 | +- clocks: | |
| 58 | + A phandle to the reference clock for this block. | |
| 59 | + | |
| 60 | +Optional properties: | |
| 61 | + | |
| 62 | + | |
| 63 | +- native-endian | |
| 64 | + Defined when using BE SoC and device uses BE register read/write | |
| 65 | + | |
| 66 | +Recommended optional m25p80 properties: | |
| 67 | +- spi-rx-bus-width: Definition as per | |
| 68 | + Documentation/devicetree/bindings/spi/spi-bus.txt | |
| 69 | + | |
| 70 | +Examples: | |
| 71 | + | |
| 72 | +BRCMSTB SoC Example: | |
| 73 | + | |
| 74 | + SPI Master (MSPI+BSPI) for SPI-NOR access: | |
| 75 | + | |
| 76 | + spi@f03e3400 { | |
| 77 | + #address-cells = <0x1>; | |
| 78 | + #size-cells = <0x0>; | |
| 79 | + compatible = "brcm,spi-brcmstb-qspi", "brcm,spi-brcmstb-qspi"; | |
| 80 | + reg = <0xf03e0920 0x4 0xf03e3400 0x188 0xf03e3200 0x50>; | |
| 81 | + reg-names = "cs_reg", "mspi", "bspi"; | |
| 82 | + interrupts = <0x6 0x5 0x4 0x3 0x2 0x1 0x0>; | |
| 83 | + interrupt-parent = <0x1c>; | |
| 84 | + interrupt-names = "mspi_halted", | |
| 85 | + "mspi_done", | |
| 86 | + "spi_lr_overread", | |
| 87 | + "spi_lr_session_done", | |
| 88 | + "spi_lr_impatient", | |
| 89 | + "spi_lr_session_aborted", | |
| 90 | + "spi_lr_fullness_reached"; | |
| 91 | + | |
| 92 | + clocks = <&hif_spi>; | |
| 93 | + clock-names = "sw_spi"; | |
| 94 | + | |
| 95 | + m25p80@0 { | |
| 96 | + #size-cells = <0x2>; | |
| 97 | + #address-cells = <0x2>; | |
| 98 | + compatible = "m25p80"; | |
| 99 | + reg = <0x0>; | |
| 100 | + spi-max-frequency = <0x2625a00>; | |
| 101 | + spi-cpol; | |
| 102 | + spi-cpha; | |
| 103 | + m25p,fast-read; | |
| 104 | + | |
| 105 | + flash0.bolt@0 { | |
| 106 | + reg = <0x0 0x0 0x0 0x100000>; | |
| 107 | + }; | |
| 108 | + | |
| 109 | + flash0.macadr@100000 { | |
| 110 | + reg = <0x0 0x100000 0x0 0x10000>; | |
| 111 | + }; | |
| 112 | + | |
| 113 | + flash0.nvram@110000 { | |
| 114 | + reg = <0x0 0x110000 0x0 0x10000>; | |
| 115 | + }; | |
| 116 | + | |
| 117 | + flash0.kernel@120000 { | |
| 118 | + reg = <0x0 0x120000 0x0 0x400000>; | |
| 119 | + }; | |
| 120 | + | |
| 121 | + flash0.devtree@520000 { | |
| 122 | + reg = <0x0 0x520000 0x0 0x10000>; | |
| 123 | + }; | |
| 124 | + | |
| 125 | + flash0.splash@530000 { | |
| 126 | + reg = <0x0 0x530000 0x0 0x80000>; | |
| 127 | + }; | |
| 128 | + | |
| 129 | + flash0@0 { | |
| 130 | + reg = <0x0 0x0 0x0 0x4000000>; | |
| 131 | + }; | |
| 132 | + }; | |
| 133 | + }; | |
| 134 | + | |
| 135 | + | |
| 136 | + MSPI master for any SPI device : | |
| 137 | + | |
| 138 | + spi@f0416000 { | |
| 139 | + #address-cells = <1>; | |
| 140 | + #size-cells = <0>; | |
| 141 | + clocks = <&upg_fixed>; | |
| 142 | + compatible = "brcm,spi-brcmstb-qspi", "brcm,spi-brcmstb-mspi"; | |
| 143 | + reg = <0xf0416000 0x180>; | |
| 144 | + reg-names = "mspi"; | |
| 145 | + interrupts = <0x14>; | |
| 146 | + interrupt-parent = <&irq0_aon_intc>; | |
| 147 | + interrupt-names = "mspi_done"; | |
| 148 | + }; | |
| 149 | + | |
| 150 | +iProc SoC Example: | |
| 151 | + | |
| 152 | + qspi: spi@18027200 { | |
| 153 | + compatible = "brcm,spi-bcm-qspi", "brcm,spi-nsp-qspi"; | |
| 154 | + reg = <0x18027200 0x184>, | |
| 155 | + <0x18027000 0x124>, | |
| 156 | + <0x1811c408 0x004>, | |
| 157 | + <0x180273a0 0x01c>; | |
| 158 | + reg-names = "mspi_regs", "bspi_regs", "intr_regs", "intr_status_reg"; | |
| 159 | + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, | |
| 160 | + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>, | |
| 161 | + <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>, | |
| 162 | + <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>, | |
| 163 | + <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>, | |
| 164 | + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>, | |
| 165 | + <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; | |
| 166 | + interrupt-names = | |
| 167 | + "spi_lr_fullness_reached", | |
| 168 | + "spi_lr_session_aborted", | |
| 169 | + "spi_lr_impatient", | |
| 170 | + "spi_lr_session_done", | |
| 171 | + "mspi_done", | |
| 172 | + "mspi_halted"; | |
| 173 | + clocks = <&iprocmed>; | |
| 174 | + clock-names = "iprocmed"; | |
| 175 | + num-cs = <2>; | |
| 176 | + #address-cells = <1>; | |
| 177 | + #size-cells = <0>; | |
| 178 | + }; | |
| 179 | + | |
| 180 | + | |
| 181 | + NS2 SoC Example: | |
| 182 | + | |
| 183 | + qspi: spi@66470200 { | |
| 184 | + compatible = "brcm,spi-bcm-qspi", "brcm,spi-ns2-qspi"; | |
| 185 | + reg = <0x66470200 0x184>, | |
| 186 | + <0x66470000 0x124>, | |
| 187 | + <0x67017408 0x004>, | |
| 188 | + <0x664703a0 0x01c>; | |
| 189 | + reg-names = "mspi", "bspi", "intr_regs", | |
| 190 | + "intr_status_reg"; | |
| 191 | + interrupts = <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>; | |
| 192 | + interrupt-names = "spi_l1_intr"; | |
| 193 | + clocks = <&iprocmed>; | |
| 194 | + clock-names = "iprocmed"; | |
| 195 | + num-cs = <2>; | |
| 196 | + #address-cells = <1>; | |
| 197 | + #size-cells = <0>; | |
| 198 | + }; | |
| 199 | + | |
| 200 | + | |
| 201 | + m25p80 node for NSP, NS2 | |
| 202 | + | |
| 203 | + &qspi { | |
| 204 | + flash: m25p80@0 { | |
| 205 | + #address-cells = <1>; | |
| 206 | + #size-cells = <1>; | |
| 207 | + compatible = "m25p80"; | |
| 208 | + reg = <0x0>; | |
| 209 | + spi-max-frequency = <12500000>; | |
| 210 | + m25p,fast-read; | |
| 211 | + spi-cpol; | |
| 212 | + spi-cpha; | |
| 213 | + | |
| 214 | + partition@0 { | |
| 215 | + label = "boot"; | |
| 216 | + reg = <0x00000000 0x000a0000>; | |
| 217 | + }; | |
| 218 | + | |
| 219 | + partition@a0000 { | |
| 220 | + label = "env"; | |
| 221 | + reg = <0x000a0000 0x00060000>; | |
| 222 | + }; | |
| 223 | + | |
| 224 | + partition@100000 { | |
| 225 | + label = "system"; | |
| 226 | + reg = <0x00100000 0x00600000>; | |
| 227 | + }; | |
| 228 | + | |
| 229 | + partition@700000 { | |
| 230 | + label = "rootfs"; | |
| 231 | + reg = <0x00700000 0x01900000>; | |
| 232 | + }; | |
| 233 | + }; | |
| @@ -0,0 +1,34 @@ | ||
| 1 | +J-Core SPI master | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: Must be "jcore,spi2". | |
| 6 | + | |
| 7 | +- reg: Memory region for registers. | |
| 8 | + | |
| 9 | +- #address-cells: Must be 1. | |
| 10 | + | |
| 11 | +- #size-cells: Must be 0. | |
| 12 | + | |
| 13 | +Optional properties: | |
| 14 | + | |
| 15 | +- clocks: If a phandle named "ref_clk" is present, SPI clock speed | |
| 16 | + programming is relative to the frequency of the indicated clock. | |
| 17 | + Necessary only if the input clock rate is something other than a | |
| 18 | + fixed 50 MHz. | |
| 19 | + | |
| 20 | +- clock-names: Clock names, one for each phandle in clocks. | |
| 21 | + | |
| 22 | +See spi-bus.txt for additional properties not specific to this device. | |
| 23 | + | |
| 24 | +Example: | |
| 25 | + | |
| 26 | +spi@40 { | |
| 27 | + compatible = "jcore,spi2"; | |
| 28 | + #address-cells = <1>; | |
| 29 | + #size-cells = <0>; | |
| 30 | + reg = <0x40 0x8>; | |
| 31 | + spi-max-frequency = <25000000>; | |
| 32 | + clocks = <&bus_clk>; | |
| 33 | + clock-names = "ref_clk"; | |
| 34 | +} | |
| @@ -31,7 +31,7 @@ with max(cs-gpios > hw cs). · 30 unmodified lines | ||
| 31 | 31 | So if for example the controller has 2 CS lines, and the cs-gpios |
| 32 | 32 | property looks like this: |
| 33 | 33 | |
| 34 | −cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>; | |
| 34 | +cs-gpios = <&gpio1 0 0>, <0>, <&gpio1 1 0>, <&gpio1 2 0>; | |
| 35 | 35 | |
| 36 | 36 | Then it should be configured so that num_chipselect = 4 with the |
| 37 | 37 | following mapping: |
| @@ -7,7 +7,7 @@ NOR memories, without DMA support and a 64-byte unified transmit / · 6 unmodified lines | ||
| 7 | 7 | receive buffer. |
| 8 | 8 | |
| 9 | 9 | Required properties: |
| 10 | − - compatible: should be "amlogic,meson6-spifc" | |
| 10 | + - compatible: should be "amlogic,meson6-spifc" or "amlogic,meson-gxbb-spifc" | |
| 11 | 11 | - reg: physical base address and length of the controller registers |
| 12 | 12 | - clocks: phandle of the input clock for the baud rate generator |
| 13 | 13 | - #address-cells: should be 1 |
| @@ -0,0 +1,70 @@ | ||
| 1 | +Thermal driver for MAX77620 Power management IC from Maxim Semiconductor. | |
| 2 | + | |
| 3 | +Maxim Semiconductor MAX77620 supports alarm interrupts when its | |
| 4 | +die temperature crosses 120C and 140C. These threshold temperatures | |
| 5 | +are not configurable. Device does not provide the real temperature | |
| 6 | +of die other than just indicating whether temperature is above or | |
| 7 | +below threshold level. | |
| 8 | + | |
| 9 | +Required properties: | |
| 10 | +------------------- | |
| 11 | +#thermal-sensor-cells: Please refer <devicetree/bindings/thermal/thermal.txt> | |
| 12 | + for more details. | |
| 13 | + The value must be 0. | |
| 14 | + | |
| 15 | +For more details, please refer generic thermal DT binding document | |
| 16 | +<devicetree/bindings/thermal/thermal.txt>. | |
| 17 | + | |
| 18 | +Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding | |
| 19 | +document for the MAX77620. | |
| 20 | + | |
| 21 | +Example: | |
| 22 | +-------- | |
| 23 | +#include <dt-bindings/mfd/max77620.h> | |
| 24 | +#include <dt-bindings/thermal/thermal.h> | |
| 25 | +... | |
| 26 | + | |
| 27 | +i2c@7000d000 { | |
| 28 | + spmic: max77620@3c { | |
| 29 | + compatible = "maxim,max77620"; | |
| 30 | + ::::: | |
| 31 | + #thermal-sensor-cells = <0>; | |
| 32 | + ::: | |
| 33 | + }; | |
| 34 | +}; | |
| 35 | + | |
| 36 | +cool_dev: cool-dev { | |
| 37 | + compatible = "cooling-dev"; | |
| 38 | + #cooling-cells = <2>; | |
| 39 | +}; | |
| 40 | + | |
| 41 | +thermal-zones { | |
| 42 | + PMIC-Die { | |
| 43 | + polling-delay = <0>; | |
| 44 | + polling-delay-passive = <0>; | |
| 45 | + thermal-sensors = <&spmic>; | |
| 46 | + | |
| 47 | + trips { | |
| 48 | + pmic_die_warn_temp_thresh: hot-die { | |
| 49 | + temperature = <120000>; | |
| 50 | + type = "hot"; | |
| 51 | + hysteresis = <0>; | |
| 52 | + }; | |
| 53 | + | |
| 54 | + pmic_die_cirt_temp_thresh: cirtical-die { | |
| 55 | + temperature = <140000>; | |
| 56 | + type = "critical"; | |
| 57 | + hysteresis = <0>; | |
| 58 | + }; | |
| 59 | + }; | |
| 60 | + | |
| 61 | + cooling-maps { | |
| 62 | + map0 { | |
| 63 | + trip = <&pmic_die_warn_temp_thresh>; | |
| 64 | + cooling-device = <&cool_dev THERMAL_NO_LIMIT | |
| 65 | + THERMAL_NO_LIMIT>; | |
| 66 | + contribution = <100>; | |
| 67 | + }; | |
| 68 | + }; | |
| 69 | + }; | |
| 70 | +}; | |
| @@ -8,7 +8,9 @@ apmixedsys register space via AHB bus accesses, so a phandle to the APMIXEDSYS · 7 unmodified lines | ||
| 8 | 8 | is also needed. |
| 9 | 9 | |
| 10 | 10 | Required properties: |
| 11 | −- compatible: "mediatek,mt8173-thermal" | |
| 11 | +- compatible: | |
| 12 | + - "mediatek,mt8173-thermal" : For MT8173 family of SoCs | |
| 13 | + - "mediatek,mt2701-thermal" : For MT2701 family of SoCs | |
| 12 | 14 | - reg: Address range of the thermal controller |
| 13 | 15 | - interrupts: IRQ for the thermal controller |
| 14 | 16 | - clocks, clock-names: Clocks needed for the thermal controller. required |
| @@ -10,8 +10,14 @@ Required properties : · 9 unmodified lines | ||
| 10 | 10 | - compatible : For Tegra124, must contain "nvidia,tegra124-soctherm". |
| 11 | 11 | For Tegra132, must contain "nvidia,tegra132-soctherm". |
| 12 | 12 | For Tegra210, must contain "nvidia,tegra210-soctherm". |
| 13 | −- reg : Should contain 1 entry: | |
| 13 | +- reg : Should contain at least 2 entries for each entry in reg-names: | |
| 14 | 14 | - SOCTHERM register set |
| 15 | + - Tegra CAR register set: Required for Tegra124 and Tegra210. | |
| 16 | + - CCROC register set: Required for Tegra132. | |
| 17 | +- reg-names : Should contain at least 2 entries: | |
| 18 | + - soctherm-reg | |
| 19 | + - car-reg | |
| 20 | + - ccroc-reg | |
| 15 | 21 | - interrupts : Defines the interrupt used by SOCTHERM |
| 16 | 22 | - clocks : Must contain an entry for each entry in clock-names. |
| 17 | 23 | See ../clocks/clock-bindings.txt for details. |
| @@ -25,17 +31,45 @@ Required properties : · 7 unmodified lines | ||
| 25 | 31 | - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description |
| 26 | 32 | of this property. See <dt-bindings/thermal/tegra124-soctherm.h> for a |
| 27 | 33 | list of valid values when referring to thermal sensors. |
| 34 | +- throttle-cfgs: A sub-node which is a container of configuration for each | |
| 35 | + hardware throttle events. These events can be set as cooling devices. | |
| 36 | + * throttle events: Sub-nodes must be named as "light" or "heavy". | |
| 37 | + Properties: | |
| 38 | + - nvidia,priority: Each throttles has its own throttle settings, so the | |
| 39 | + SW need to set priorities for various throttle, the HW arbiter can select | |
| 40 | + the final throttle settings. | |
| 41 | + Bigger value indicates higher priority, In general, higher priority | |
| 42 | + translates to lower target frequency. SW needs to ensure that critical | |
| 43 | + thermal alarms are given higher priority, and ensure that there is | |
| 44 | + no race if priority of two vectors is set to the same value. | |
| 45 | + The range of this value is 1~100. | |
| 46 | + - nvidia,cpu-throt-percent: This property is for Tegra124 and Tegra210. | |
| 47 | + It is the throttling depth of pulse skippers, it's the percentage | |
| 48 | + throttling. | |
| 49 | + - nvidia,cpu-throt-level: This property is only for Tegra132, it is the | |
| 50 | + level of pulse skippers, which used to throttle clock frequencies. It | |
| 51 | + indicates cpu clock throttling depth, and the depth can be programmed. | |
| 52 | + Must set as following values: | |
| 53 | + TEGRA_SOCTHERM_THROT_LEVEL_LOW, TEGRA_SOCTHERM_THROT_LEVEL_MED | |
| 54 | + TEGRA_SOCTHERM_THROT_LEVEL_HIGH, TEGRA_SOCTHERM_THROT_LEVEL_NONE | |
| 55 | + - #cooling-cells: Should be 1. This cooling device only support on/off state. | |
| 56 | + See ./thermal.txt for a description of this property. | |
| 28 | 57 | |
| 29 | 58 | Note: |
| 30 | 59 | - the "critical" type trip points will be set to SOC_THERM hardware as the |
| 31 | 60 | shut down temperature. Once the temperature of this thermal zone is higher |
| 32 | 61 | than it, the system will be shutdown or reset by hardware. |
| 62 | +- the "hot" type trip points will be set to SOC_THERM hardware as the throttle | |
| 63 | +temperature. Once the the temperature of this thermal zone is higher | |
| 64 | +than it, it will trigger the HW throttle event. | |
| 33 | 65 | |
| 34 | 66 | Example : |
| 35 | 67 | |
| 36 | 68 | soctherm@700e2000 { |
| 37 | 69 | compatible = "nvidia,tegra124-soctherm"; |
| 38 | − reg = <0x0 0x700e2000 0x0 0x1000>; | |
| 70 | + reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */ | |
| 71 | + 0x0 0x60006000 0x0 0x400 /* CAR reg_base */ | |
| 72 | + reg-names = "soctherm-reg", "car-reg"; | |
| 39 | 73 | interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; |
| 40 | 74 | clocks = <&tegra_car TEGRA124_CLK_TSENSOR>, |
| 41 | 75 | <&tegra_car TEGRA124_CLK_SOC_THERM>; |
| @@ -44,6 +78,76 @@ Example : · 2 unmodified lines | ||
| 44 | 78 | reset-names = "soctherm"; |
| 45 | 79 | |
| 46 | 80 | #thermal-sensor-cells = <1>; |
| 81 | + | |
| 82 | + throttle-cfgs { | |
| 83 | + /* | |
| 84 | + * When the "heavy" cooling device triggered, | |
| 85 | + * the HW will skip cpu clock's pulse in 85% depth | |
| 86 | + */ | |
| 87 | + throttle_heavy: heavy { | |
| 88 | + nvidia,priority = <100>; | |
| 89 | + nvidia,cpu-throt-percent = <85>; | |
| 90 | + | |
| 91 | + #cooling-cells = <1>; | |
| 92 | + }; | |
| 93 | + | |
| 94 | + /* | |
| 95 | + * When the "light" cooling device triggered, | |
| 96 | + * the HW will skip cpu clock's pulse in 50% depth | |
| 97 | + */ | |
| 98 | + throttle_light: light { | |
| 99 | + nvidia,priority = <80>; | |
| 100 | + nvidia,cpu-throt-percent = <50>; | |
| 101 | + | |
| 102 | + #cooling-cells = <1>; | |
| 103 | + }; | |
| 104 | + | |
| 105 | + /* | |
| 106 | + * If these two devices are triggered in same time, the HW throttle | |
| 107 | + * arbiter will select the highest priority as the final throttle | |
| 108 | + * settings to skip cpu pulse. | |
| 109 | + */ | |
| 110 | + }; | |
| 111 | + }; | |
| 112 | + | |
| 113 | +Example: referring to Tegra132's "reg", "reg-names" and "throttle-cfgs" : | |
| 114 | + | |
| 115 | + soctherm@700e2000 { | |
| 116 | + compatible = "nvidia,tegra132-soctherm"; | |
| 117 | + reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */ | |
| 118 | + 0x0 0x70040000 0x0 0x200>; /* CCROC reg_base */; | |
| 119 | + reg-names = "soctherm-reg", "ccroc-reg"; | |
| 120 | + | |
| 121 | + throttle-cfgs { | |
| 122 | + /* | |
| 123 | + * When the "heavy" cooling device triggered, | |
| 124 | + * the HW will skip cpu clock's pulse in HIGH level | |
| 125 | + */ | |
| 126 | + throttle_heavy: heavy { | |
| 127 | + nvidia,priority = <100>; | |
| 128 | + nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_HIGH>; | |
| 129 | + | |
| 130 | + #cooling-cells = <1>; | |
| 131 | + }; | |
| 132 | + | |
| 133 | + /* | |
| 134 | + * When the "light" cooling device triggered, | |
| 135 | + * the HW will skip cpu clock's pulse in MED level | |
| 136 | + */ | |
| 137 | + throttle_light: light { | |
| 138 | + nvidia,priority = <80>; | |
| 139 | + nvidia,cpu-throt-level = <TEGRA_SOCTHERM_THROT_LEVEL_MED>; | |
| 140 | + | |
| 141 | + #cooling-cells = <1>; | |
| 142 | + }; | |
| 143 | + | |
| 144 | + /* | |
| 145 | + * If these two devices are triggered in same time, the HW throttle | |
| 146 | + * arbiter will select the highest priority as the final throttle | |
| 147 | + * settings to skip cpu pulse. | |
| 148 | + */ | |
| 149 | + | |
| 150 | + }; | |
| 47 | 151 | }; |
| 48 | 152 | |
| 49 | 153 | Example: referring to thermal sensors : |
| @@ -62,6 +166,19 @@ Example: referring to thermal sensors : · 12 unmodified lines | ||
| 62 | 166 | hysteresis = <1000>; |
| 63 | 167 | type = "critical"; |
| 64 | 168 | }; |
| 169 | + | |
| 170 | + cpu_throttle_trip: throttle-trip { | |
| 171 | + temperature = <100000>; | |
| 172 | + hysteresis = <1000>; | |
| 173 | + type = "hot"; | |
| 174 | + }; | |
| 175 | + }; | |
| 176 | + | |
| 177 | + cooling-maps { | |
| 178 | + map0 { | |
| 179 | + trip = <&cpu_throttle_trip>; | |
| 180 | + cooling-device = <&throttle_heavy 1 1>; | |
| 181 | + }; | |
| 65 | 182 | }; |
| 66 | 183 | }; |
| 67 | 184 | }; |
| @@ -0,0 +1,21 @@ | ||
| 1 | +* QCOM SoC Temperature Sensor (TSENS) | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible : | |
| 5 | + - "qcom,msm8916-tsens" : For 8916 Family of SoCs | |
| 6 | + - "qcom,msm8974-tsens" : For 8974 Family of SoCs | |
| 7 | + - "qcom,msm8996-tsens" : For 8996 Family of SoCs | |
| 8 | + | |
| 9 | +- reg: Address range of the thermal registers | |
| 10 | +- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description. | |
| 11 | +- Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how to specify | |
| 12 | +nvmem cells | |
| 13 | + | |
| 14 | +Example: | |
| 15 | +tsens: thermal-sensor@900000 { | |
| 16 | + compatible = "qcom,msm8916-tsens"; | |
| 17 | + reg = <0x4a8000 0x2000>; | |
| 18 | + nvmem-cells = <&tsens_caldata>, <&tsens_calsel>; | |
| 19 | + nvmem-cell-names = "caldata", "calsel"; | |
| 20 | + #thermal-sensor-cells = <1>; | |
| 21 | + }; | |
| @@ -0,0 +1,24 @@ | ||
| 1 | +J-Core Programmable Interval Timer and Clocksource | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | + | |
| 5 | +- compatible: Must be "jcore,pit". | |
| 6 | + | |
| 7 | +- reg: Memory region(s) for timer/clocksource registers. For SMP, | |
| 8 | + there should be one region per cpu, indexed by the sequential, | |
| 9 | + zero-based hardware cpu number. | |
| 10 | + | |
| 11 | +- interrupts: An interrupt to assign for the timer. The actual pit | |
| 12 | + core is integrated with the aic and allows the timer interrupt | |
| 13 | + assignment to be programmed by software, but this property is | |
| 14 | + required in order to reserve an interrupt number that doesn't | |
| 15 | + conflict with other devices. | |
| 16 | + | |
| 17 | + | |
| 18 | +Example: | |
| 19 | + | |
| 20 | +timer@200 { | |
| 21 | + compatible = "jcore,pit"; | |
| 22 | + reg = < 0x200 0x30 0x500 0x30 >; | |
| 23 | + interrupts = < 0x48 >; | |
| 24 | +}; | |
| @@ -2,7 +2,9 @@ MOXA ART timer · 1 unmodified line | ||
| 2 | 2 | |
| 3 | 3 | Required properties: |
| 4 | 4 | |
| 5 | −- compatible : Must be "moxa,moxart-timer" | |
| 5 | +- compatible : Must be one of: | |
| 6 | + - "moxa,moxart-timer" | |
| 7 | + - "aspeed,ast2400-timer" | |
| 6 | 8 | - reg : Should contain registers location and length |
| 7 | 9 | - interrupts : Should contain the timer interrupt number |
| 8 | 10 | - clocks : Should contain phandle for the clock that drives the counter |
| @@ -2,7 +2,7 @@ Oxford Semiconductor OXNAS SoCs Family RPS Timer · 1 unmodified line | ||
| 2 | 2 | ================================================ |
| 3 | 3 | |
| 4 | 4 | Required properties: |
| 5 | −- compatible: Should be "oxsemi,ox810se-rps-timer" | |
| 5 | +- compatible: Should be "oxsemi,ox810se-rps-timer" or "oxsemi,ox820-rps-timer" | |
| 6 | 6 | - reg : Specifies base physical address and size of the registers. |
| 7 | 7 | - interrupts : The interrupts of the two timers |
| 8 | 8 | - clocks : The phandle of the timer clock source |
| @@ -81,6 +81,8 @@ i.mx specific properties · 80 unmodified lines | ||
| 81 | 81 | - fsl,usbmisc: phandler of non-core register device, with one |
| 82 | 82 | argument that indicate usb controller index |
| 83 | 83 | - disable-over-current: disable over current detect |
| 84 | +- over-current-active-high: over current signal polarity is high active, | |
| 85 | + typically over current signal polarity is low active. | |
| 84 | 86 | - external-vbus-divider: enables off-chip resistor divider for Vbus |
| 85 | 87 | |
| 86 | 88 | Example: |
| @@ -10,6 +10,8 @@ Required properties: · 9 unmodified lines | ||
| 10 | 10 | - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc; |
| 11 | 11 | - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs; |
| 12 | 12 | - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs; |
| 13 | + - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs; | |
| 14 | + - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs; | |
| 13 | 15 | - snps,dwc2: A generic DWC2 USB controller with default parameters. |
| 14 | 16 | - reg : Should contain 1 register range (address and length) |
| 15 | 17 | - interrupts : Should contain 1 interrupt |
| @@ -26,7 +28,10 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties · 10 unmodified lines | ||
| 26 | 28 | - g-use-dma: enable dma usage in gadget driver. |
| 27 | 29 | - g-rx-fifo-size: size of rx fifo size in gadget mode. |
| 28 | 30 | - g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode. |
| 29 | −- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode. | |
| 31 | + | |
| 32 | +Deprecated properties: | |
| 33 | +- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) | |
| 34 | + in gadget mode. | |
| 30 | 35 | |
| 31 | 36 | Example: |
| 32 | 37 | |
| @@ -0,0 +1,28 @@ | ||
| 1 | +Cavium SuperSpeed DWC3 USB SoC controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should contain "cavium,octeon-7130-usb-uctl" | |
| 5 | + | |
| 6 | +Required child node: | |
| 7 | +A child node must exist to represent the core DWC3 IP block. The name of | |
| 8 | +the node is not important. The content of the node is defined in dwc3.txt. | |
| 9 | + | |
| 10 | +Example device node: | |
| 11 | + | |
| 12 | + uctl@1180069000000 { | |
| 13 | + compatible = "cavium,octeon-7130-usb-uctl"; | |
| 14 | + reg = <0x00011800 0x69000000 0x00000000 0x00000100>; | |
| 15 | + ranges; | |
| 16 | + #address-cells = <0x00000002>; | |
| 17 | + #size-cells = <0x00000002>; | |
| 18 | + refclk-frequency = <0x05f5e100>; | |
| 19 | + refclk-type-ss = "dlmc_ref_clk0"; | |
| 20 | + refclk-type-hs = "dlmc_ref_clk0"; | |
| 21 | + power = <0x00000002 0x00000002 0x00000001>; | |
| 22 | + xhci@1690000000000 { | |
| 23 | + compatible = "cavium,octeon-7130-xhci", "synopsys,dwc3"; | |
| 24 | + reg = <0x00016900 0x00000000 0x00000010 0x00000000>; | |
| 25 | + interrupt-parent = <0x00000010>; | |
| 26 | + interrupts = <0x00000009 0x00000004>; | |
| 27 | + }; | |
| 28 | + }; | |
| @@ -13,7 +13,8 @@ Optional properties: · 12 unmodified lines | ||
| 13 | 13 | in the array is expected to be a handle to the USB2/HS PHY and |
| 14 | 14 | the second element is expected to be a handle to the USB3/SS PHY |
| 15 | 15 | - phys: from the *Generic PHY* bindings |
| 16 | − - phy-names: from the *Generic PHY* bindings | |
| 16 | + - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy" | |
| 17 | + or "usb3-phy". | |
| 17 | 18 | - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable |
| 18 | 19 | - snps,disable_scramble_quirk: true when SW should disable data scrambling. |
| 19 | 20 | Only really useful for FPGA builds. |
| @@ -39,6 +40,11 @@ Optional properties: · 19 unmodified lines | ||
| 39 | 40 | disabling the suspend signal to the PHY. |
| 40 | 41 | - snps,dis_rxdet_inp3_quirk: when set core will disable receiver detection |
| 41 | 42 | in PHY P3 power state. |
| 43 | + - snps,dis-u2-freeclk-exists-quirk: when set, clear the u2_freeclk_exists | |
| 44 | + in GUSB2PHYCFG, specify that USB2 PHY doesn't provide | |
| 45 | + a free-running PHY clock. | |
| 46 | + - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power | |
| 47 | + from P0 to P1/P2/P3 without delay. | |
| 42 | 48 | - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal |
| 43 | 49 | utmi_l1_suspend_n, false when asserts utmi_sleep_n |
| 44 | 50 | - snps,hird-threshold: HIRD threshold |
| @@ -11,6 +11,11 @@ Optional properties: · 10 unmodified lines | ||
| 11 | 11 | "peripheral" and "otg". In case this attribute isn't |
| 12 | 12 | passed via DT, USB DRD controllers should default to |
| 13 | 13 | OTG. |
| 14 | + - phy_type: tells USB controllers that we want to configure the core to support | |
| 15 | + a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is | |
| 16 | + selected. Valid arguments are "utmi" and "utmi_wide". | |
| 17 | + In case this isn't passed via DT, USB controllers should | |
| 18 | + default to HW capability. | |
| 14 | 19 | - otg-rev: tells usb driver the release number of the OTG and EH supplement |
| 15 | 20 | with which the device and its descriptors are compliant, |
| 16 | 21 | in binary-coded decimal (i.e. 2.0 is 0200H). This |
| @@ -34,6 +39,7 @@ dwc3@4a030000 { · 17 unmodified lines | ||
| 34 | 39 | usb-phy = <&usb2_phy>, <&usb3,phy>; |
| 35 | 40 | maximum-speed = "super-speed"; |
| 36 | 41 | dr_mode = "otg"; |
| 42 | + phy_type = "utmi_wide"; | |
| 37 | 43 | otg-rev = <0x0200>; |
| 38 | 44 | adp-disable; |
| 39 | 45 | }; |
| @@ -9,6 +9,7 @@ Required properties: · 8 unmodified lines | ||
| 9 | 9 | - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device |
| 10 | 10 | - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device |
| 11 | 11 | - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device |
| 12 | + - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device | |
| 12 | 13 | - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device |
| 13 | 14 | - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device |
| 14 | 15 | |
| @@ -0,0 +1,59 @@ | ||
| 1 | +Rockchip SuperSpeed DWC3 USB SoC controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: should contain "rockchip,rk3399-dwc3" for rk3399 SoC | |
| 5 | +- clocks: A list of phandle + clock-specifier pairs for the | |
| 6 | + clocks listed in clock-names | |
| 7 | +- clock-names: Should contain the following: | |
| 8 | + "ref_clk" Controller reference clk, have to be 24 MHz | |
| 9 | + "suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz | |
| 10 | + "bus_clk" Master/Core clock, have to be >= 62.5 MHz for SS | |
| 11 | + operation and >= 30MHz for HS operation | |
| 12 | + "grf_clk" Controller grf clk | |
| 13 | + | |
| 14 | +Required child node: | |
| 15 | +A child node must exist to represent the core DWC3 IP block. The name of | |
| 16 | +the node is not important. The content of the node is defined in dwc3.txt. | |
| 17 | + | |
| 18 | +Phy documentation is provided in the following places: | |
| 19 | +Documentation/devicetree/bindings/phy/rockchip,dwc3-usb-phy.txt | |
| 20 | + | |
| 21 | +Example device nodes: | |
| 22 | + | |
| 23 | + usbdrd3_0: usb@fe800000 { | |
| 24 | + compatible = "rockchip,rk3399-dwc3"; | |
| 25 | + clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>, | |
| 26 | + <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>; | |
| 27 | + clock-names = "ref_clk", "suspend_clk", | |
| 28 | + "bus_clk", "grf_clk"; | |
| 29 | + #address-cells = <2>; | |
| 30 | + #size-cells = <2>; | |
| 31 | + ranges; | |
| 32 | + status = "disabled"; | |
| 33 | + usbdrd_dwc3_0: dwc3@fe800000 { | |
| 34 | + compatible = "snps,dwc3"; | |
| 35 | + reg = <0x0 0xfe800000 0x0 0x100000>; | |
| 36 | + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; | |
| 37 | + dr_mode = "otg"; | |
| 38 | + status = "disabled"; | |
| 39 | + }; | |
| 40 | + }; | |
| 41 | + | |
| 42 | + usbdrd3_1: usb@fe900000 { | |
| 43 | + compatible = "rockchip,rk3399-dwc3"; | |
| 44 | + clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>, | |
| 45 | + <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>; | |
| 46 | + clock-names = "ref_clk", "suspend_clk", | |
| 47 | + "bus_clk", "grf_clk"; | |
| 48 | + #address-cells = <2>; | |
| 49 | + #size-cells = <2>; | |
| 50 | + ranges; | |
| 51 | + status = "disabled"; | |
| 52 | + usbdrd_dwc3_1: dwc3@fe900000 { | |
| 53 | + compatible = "snps,dwc3"; | |
| 54 | + reg = <0x0 0xfe900000 0x0 0x100000>; | |
| 55 | + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; | |
| 56 | + dr_mode = "otg"; | |
| 57 | + status = "disabled"; | |
| 58 | + }; | |
| 59 | + }; | |
| @@ -0,0 +1,19 @@ | ||
| 1 | +SMSC USB4604 High-Speed Hub Controller | |
| 2 | + | |
| 3 | +Required properties: | |
| 4 | +- compatible: Should be "smsc,usb4604" | |
| 5 | + | |
| 6 | +Optional properties: | |
| 7 | +- reg: Specifies the i2c slave address, it is required and should be 0x2d | |
| 8 | + if I2C is used. | |
| 9 | +- reset-gpios: Should specify GPIO for reset. | |
| 10 | +- initial-mode: Should specify initial mode. | |
| 11 | + (1 for HUB mode, 2 for STANDBY mode) | |
| 12 | + | |
| 13 | +Examples: | |
| 14 | + usb-hub@2d { | |
| 15 | + compatible = "smsc,usb4604"; | |
| 16 | + reg = <0x2d>; | |
| 17 | + reset-gpios = <&gpx3 5 1>; | |
| 18 | + initial-mode = <1>; | |
| 19 | + }; | |
| @@ -6,6 +6,7 @@ Required properties: · 5 unmodified lines | ||
| 6 | 6 | "fsl,imx6q-usbmisc" for imx6q |
| 7 | 7 | "fsl,vf610-usbmisc" for Vybrid vf610 |
| 8 | 8 | "fsl,imx6sx-usbmisc" for imx6sx |
| 9 | + "fsl,imx7d-usbmisc" for imx7d | |
| 9 | 10 | - reg: Should contain registers location and length |
| 10 | 11 | |
| 11 | 12 | Examples: |
| @@ -3,8 +3,8 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order. · 2 unmodified lines | ||
| 3 | 3 | This isn't an exhaustive list, but you should add new prefixes to it before |
| 4 | 4 | using them to avoid name-space collisions. |
| 5 | 5 | |
| 6 | −abilis Abilis Systems | |
| 7 | 6 | abcn Abracon Corporation |
| 7 | +abilis Abilis Systems | |
| 8 | 8 | active-semi Active-Semi International Inc |
| 9 | 9 | ad Avionic Design GmbH |
| 10 | 10 | adapteva Adapteva, Inc. |
| @@ -36,6 +36,7 @@ aspeed ASPEED Technology Inc. · 25 unmodified lines | ||
| 36 | 36 | atlas Atlas Scientific LLC |
| 37 | 37 | atmel Atmel Corporation |
| 38 | 38 | auo AU Optronics Corporation |
| 39 | +auvidea Auvidea GmbH | |
| 39 | 40 | avago Avago Technologies |
| 40 | 41 | avic Shanghai AVIC Optoelectronics Co., Ltd. |
| 41 | 42 | axis Axis Communications AB |
| @@ -75,6 +76,7 @@ digilent Diglent, Inc. · 33 unmodified lines | ||
| 75 | 76 | dlg Dialog Semiconductor |
| 76 | 77 | dlink D-Link Corporation |
| 77 | 78 | dmo Data Modul AG |
| 79 | +domintech Domintech Co., Ltd. | |
| 78 | 80 | dptechnics DPTechnics |
| 79 | 81 | dragino Dragino Technology Co., Limited |
| 80 | 82 | ea Embedded Artists AB |
| @@ -85,6 +87,7 @@ elan Elan Microelectronic Corp. · 4 unmodified lines | ||
| 85 | 87 | embest Shenzhen Embest Technology Co., Ltd. |
| 86 | 88 | emmicro EM Microelectronic |
| 87 | 89 | energymicro Silicon Laboratories (formerly Energy Micro AS) |
| 90 | +engicam Engicam S.r.l. | |
| 88 | 91 | epcos EPCOS AG |
| 89 | 92 | epfl Ecole Polytechnique Fédérale de Lausanne |
| 90 | 93 | epson Seiko Epson Corp. |
| @@ -98,11 +101,12 @@ ezchip EZchip Semiconductor · 7 unmodified lines | ||
| 98 | 101 | fcs Fairchild Semiconductor |
| 99 | 102 | firefly Firefly |
| 100 | 103 | focaltech FocalTech Systems Co.,Ltd |
| 104 | +friendlyarm Guangzhou FriendlyARM Computer Tech Co., Ltd | |
| 101 | 105 | fsl Freescale Semiconductor |
| 102 | 106 | ge General Electric Company |
| 103 | 107 | geekbuying GeekBuying |
| 104 | −GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. | |
| 105 | 108 | gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. |
| 109 | +GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. | |
| 106 | 110 | geniatech Geniatech, Inc. |
| 107 | 111 | giantplus Giantplus Technology Co., Ltd. |
| 108 | 112 | globalscale Globalscale Technologies, Inc. |
| @@ -126,7 +130,6 @@ i2se I2SE GmbH · 17 unmodified lines | ||
| 126 | 130 | ibm International Business Machines (IBM) |
| 127 | 131 | idt Integrated Device Technologies, Inc. |
| 128 | 132 | ifi Ingenieurburo Fur Ic-Technologie (I/F/I) |
| 129 | −iom Iomega Corporation | |
| 130 | 133 | img Imagination Technologies Ltd. |
| 131 | 134 | infineon Infineon Technologies |
| 132 | 135 | inforce Inforce Computing |
| @@ -135,11 +138,15 @@ innolux Innolux Corporation · 2 unmodified lines | ||
| 135 | 138 | intel Intel Corporation |
| 136 | 139 | intercontrol Inter Control Group |
| 137 | 140 | invensense InvenSense Inc. |
| 141 | +inversepath Inverse Path | |
| 142 | +iom Iomega Corporation | |
| 138 | 143 | isee ISEE 2007 S.L. |
| 139 | 144 | isil Intersil |
| 140 | 145 | issi Integrated Silicon Solutions Inc. |
| 146 | +jdi Japan Display Inc. | |
| 141 | 147 | jedec JEDEC Solid State Technology Association |
| 142 | 148 | karo Ka-Ro electronics GmbH |
| 149 | +keithkoep Keith & Koep GmbH | |
| 143 | 150 | keymile Keymile GmbH |
| 144 | 151 | kinetic Kinetic Technologies |
| 145 | 152 | kosagi Sutajio Ko-Usagi PTE Ltd. |
| @@ -149,16 +156,18 @@ lantiq Lantiq Semiconductor · 3 unmodified lines | ||
| 149 | 156 | lenovo Lenovo Group Ltd. |
| 150 | 157 | lg LG Corporation |
| 151 | 158 | linux Linux-specific binding |
| 152 | −lsi LSI Corp. (LSI Logic) | |
| 153 | 159 | lltc Linear Technology Corporation |
| 160 | +lsi LSI Corp. (LSI Logic) | |
| 154 | 161 | marvell Marvell Technology Group Ltd. |
| 155 | 162 | maxim Maxim Integrated Products |
| 156 | 163 | meas Measurement Specialties |
| 157 | 164 | mediatek MediaTek Inc. |
| 158 | 165 | melexis Melexis N.V. |
| 166 | +melfas MELFAS Inc. | |
| 159 | 167 | merrii Merrii Technology Co., Ltd. |
| 160 | 168 | micrel Micrel Inc. |
| 161 | 169 | microchip Microchip Technology Inc. |
| 170 | +microcrystal Micro Crystal AG | |
| 162 | 171 | micron Micron Technology Inc. |
| 163 | 172 | minix MINIX Technology Ltd. |
| 164 | 173 | mitsubishi Mitsubishi Electric Corporation |
| @@ -190,20 +199,20 @@ onnn ON Semiconductor Corp. · 25 unmodified lines | ||
| 190 | 199 | ontat On Tat Industrial Company |
| 191 | 200 | opencores OpenCores.org |
| 192 | 201 | option Option NV |
| 202 | +ORCL Oracle Corporation | |
| 193 | 203 | ortustech Ortus Technology Co., Ltd. |
| 194 | 204 | ovti OmniVision Technologies |
| 195 | −ORCL Oracle Corporation | |
| 196 | 205 | oxsemi Oxford Semiconductor, Ltd. |
| 197 | 206 | panasonic Panasonic Corporation |
| 198 | 207 | parade Parade Technologies Inc. |
| 199 | 208 | pericom Pericom Technology Inc. |
| 200 | 209 | phytec PHYTEC Messtechnik GmbH |
| 201 | 210 | picochip Picochip Ltd |
| 211 | +pixcir PIXCIR MICROELECTRONICS Co., Ltd | |
| 202 | 212 | plathome Plat'Home Co., Ltd. |
| 203 | 213 | plda PLDA |
| 204 | −pixcir PIXCIR MICROELECTRONICS Co., Ltd | |
| 205 | −pulsedlight PulsedLight, Inc | |
| 206 | 214 | powervr PowerVR (deprecated, use img) |
| 215 | +pulsedlight PulsedLight, Inc | |
| 207 | 216 | qca Qualcomm Atheros, Inc. |
| 208 | 217 | qcom Qualcomm Technologies, Inc |
| 209 | 218 | qemu QEMU, a generic and open source machine emulator and virtualizer |
| @@ -231,12 +240,13 @@ sgx SGX Sensortech · 21 unmodified lines | ||
| 231 | 240 | sharp Sharp Corporation |
| 232 | 241 | si-en Si-En Technology Ltd. |
| 233 | 242 | sigma Sigma Designs, Inc. |
| 243 | +sii Seiko Instruments, Inc. | |
| 234 | 244 | sil Silicon Image |
| 235 | 245 | silabs Silicon Laboratories |
| 246 | +silead Silead Inc. | |
| 247 | +silergy Silergy Corp. | |
| 236 | 248 | siliconmitus Silicon Mitus, Inc. |
| 237 | 249 | simtek |
| 238 | −sii Seiko Instruments, Inc. | |
| 239 | −silergy Silergy Corp. | |
| 240 | 250 | sirf SiRF Technology, Inc. |
| 241 | 251 | sis Silicon Integrated Systems Corp. |
| 242 | 252 | sitronix Sitronix Technology Corporation |
| @@ -254,9 +264,12 @@ starry Starry Electronic Technology (ShenZhen) Co., LTD · 11 unmodified lines | ||
| 254 | 264 | startek Startek |
| 255 | 265 | ste ST-Ericsson |
| 256 | 266 | stericsson ST-Ericsson |
| 267 | +summit Summit microelectronics | |
| 268 | +sunchip Shenzhen Sunchip Technology Co., Ltd | |
| 269 | +SUNW Sun Microsystems, Inc | |
| 270 | +swir Sierra Wireless | |
| 257 | 271 | syna Synaptics Inc. |
| 258 | 272 | synology Synology, Inc. |
| 259 | −SUNW Sun Microsystems, Inc | |
| 260 | 273 | tbs TBS Technologies |
| 261 | 274 | tcg Trusted Computing Group |
| 262 | 275 | tcl Toby Churchill Ltd. |
| @@ -265,17 +278,19 @@ technologic Technologic Systems · 2 unmodified lines | ||
| 265 | 278 | thine THine Electronics, Inc. |
| 266 | 279 | ti Texas Instruments |
| 267 | 280 | tlm Trusted Logic Mobility |
| 281 | +topeet Topeet | |
| 268 | 282 | toradex Toradex AG |
| 269 | 283 | toshiba Toshiba Corporation |
| 270 | 284 | toumaz Toumaz |
| 271 | −tplink TP-LINK Technologies Co., Ltd. | |
| 272 | 285 | tpk TPK U.S.A. LLC |
| 286 | +tplink TP-LINK Technologies Co., Ltd. | |
| 287 | +tpo TPO | |
| 273 | 288 | tronfy Tronfy |
| 274 | 289 | tronsmart Tronsmart |
| 275 | 290 | truly Truly Semiconductors Limited |
| 276 | 291 | tyan Tyan Computer Corporation |
| 277 | −upisemi uPI Semiconductor Corp. | |
| 278 | 292 | uniwest United Western Technologies Corp (UniWest) |
| 293 | +upisemi uPI Semiconductor Corp. | |
| 279 | 294 | urt United Radiant Technology Corporation |
| 280 | 295 | usi Universal Scientific Industrial Co., Ltd. |
| 281 | 296 | v3 V3 Semiconductor |
| @@ -293,7 +308,7 @@ x-powers X-Powers · 11 unmodified lines | ||
| 293 | 308 | xes Extreme Engineering Solutions (X-ES) |
| 294 | 309 | xillybus Xillybus Ltd. |
| 295 | 310 | xlnx Xilinx |
| 296 | −zyxel ZyXEL Communications Corp. | |
| 297 | 311 | zarlink Zarlink Semiconductor |
| 298 | 312 | zii Zodiac Inflight Innovations |
| 299 | 313 | zte ZTE Corp. |
| 314 | +zyxel ZyXEL Communications Corp. | |
| @@ -7,6 +7,8 @@ Required properties: · 6 unmodified lines | ||
| 7 | 7 | - reg : Physical base address and size |
| 8 | 8 | |
| 9 | 9 | Optional properties: |
| 10 | +- clocks : Input clock specifier. Refer to common clock | |
| 11 | + bindings. | |
| 10 | 12 | - clock-frequency : Frequency of clock in Hz |
| 11 | 13 | - xlnx,wdt-enable-once : 0 - Watchdog can be restarted |
| 12 | 14 | 1 - Watchdog can be enabled just once |
| @@ -17,6 +19,7 @@ Example: · 4 unmodified lines | ||
| 17 | 19 | axi-timebase-wdt@40100000 { |
| 18 | 20 | clock-frequency = <50000000>; |
| 19 | 21 | compatible = "xlnx,xps-timebase-wdt-1.00.a"; |
| 22 | + clocks = <&clkc 15>; | |
| 20 | 23 | reg = <0x40100000 0x10000>; |
| 21 | 24 | xlnx,wdt-enable-once = <0x0>; |
| 22 | 25 | xlnx,wdt-interval = <0x1b>; |
| @@ -9,8 +9,7 @@ functionality. · 8 unmodified lines | ||
| 9 | 9 | |
| 10 | 10 | Required properties |
| 11 | 11 | |
| 12 | −- compatible : Must be one of: "st,stih407-lpc" "st,stih416-lpc" | |
| 13 | − "st,stih415-lpc" "st,stid127-lpc" | |
| 12 | +- compatible : Should be: "st,stih407-lpc" | |
| 14 | 13 | - reg : LPC registers base address + size |
| 15 | 14 | - interrupts : LPC interrupt line number and associated flags |
| 16 | 15 | - clocks : Clock used by LPC device (See: ../clock/clock-bindings.txt) |
| @@ -21,20 +21,11 @@ a set of changes. No changes to the active tree are made at this point. · 20 unmodified lines | ||
| 21 | 21 | All the change operations are recorded in the of_changeset 'entries' |
| 22 | 22 | list. |
| 23 | 23 | |
| 24 | −3. mutex_lock(of_mutex) - starts a changeset; The global of_mutex | |
| 25 | −ensures there can only be one editor at a time. | |
| 26 | − | |
| 27 | −4. of_changeset_apply() - Apply the changes to the tree. Either the | |
| 24 | +3. of_changeset_apply() - Apply the changes to the tree. Either the | |
| 28 | 25 | entire changeset will get applied, or if there is an error the tree will |
| 29 | −be restored to the previous state | |
| 30 | − | |
| 31 | −5. mutex_unlock(of_mutex) - All operations complete, release the mutex | |
| 26 | +be restored to the previous state. The core ensures proper serialization | |
| 27 | +through locking. An unlocked version __of_changeset_apply is available, | |
| 28 | +if needed. | |
| 32 | 29 | |
| 33 | 30 | If a successfully applied changeset needs to be removed, it can be done |
| 34 | −with the following sequence. | |
| 35 | − | |
| 36 | −1. mutex_lock(of_mutex) | |
| 37 | − | |
| 38 | −2. of_changeset_revert() | |
| 39 | − | |
| 40 | −3. mutex_unlock(of_mutex) | |
| 31 | +with of_changeset_revert(). | |
| @@ -282,6 +282,17 @@ supported. · 281 unmodified lines | ||
| 282 | 282 | that is supposed to push the current |
| 283 | 283 | transaction descriptor to a pending queue, waiting |
| 284 | 284 | for issue_pending to be called. |
| 285 | + - In this structure the function pointer callback_result can be | |
| 286 | + initialized in order for the submitter to be notified that a | |
| 287 | + transaction has completed. In the earlier code the function pointer | |
| 288 | + callback has been used. However it does not provide any status to the | |
| 289 | + transaction and will be deprecated. The result structure defined as | |
| 290 | + dmaengine_result that is passed in to callback_result has two fields: | |
| 291 | + + result: This provides the transfer result defined by | |
| 292 | + dmaengine_tx_result. Either success or some error | |
| 293 | + condition. | |
| 294 | + + residue: Provides the residue bytes of the transfer for those that | |
| 295 | + support residue. | |
| 285 | 296 | |
| 286 | 297 | * device_issue_pending |
| 287 | 298 | - Takes the first transaction descriptor in the pending queue, |
| @@ -0,0 +1,7 @@ | ||
| 1 | +# -*- coding: utf-8 mode: conf-colon -*- | |
| 2 | +# | |
| 3 | +# docutils configuration file | |
| 4 | +# http://docutils.sourceforge.net/docs/user/config.html | |
| 5 | + | |
| 6 | +[general] | |
| 7 | +halt_level: severe | |
| @@ -0,0 +1,120 @@ | ||
| 1 | +Driver Basics | |
| 2 | +============= | |
| 3 | + | |
| 4 | +Driver Entry and Exit points | |
| 5 | +---------------------------- | |
| 6 | + | |
| 7 | +.. kernel-doc:: include/linux/init.h | |
| 8 | + :internal: | |
| 9 | + | |
| 10 | +Atomic and pointer manipulation | |
| 11 | +------------------------------- | |
| 12 | + | |
| 13 | +.. kernel-doc:: arch/x86/include/asm/atomic.h | |
| 14 | + :internal: | |
| 15 | + | |
| 16 | +Delaying, scheduling, and timer routines | |
| 17 | +---------------------------------------- | |
| 18 | + | |
| 19 | +.. kernel-doc:: include/linux/sched.h | |
| 20 | + :internal: | |
| 21 | + | |
| 22 | +.. kernel-doc:: kernel/sched/core.c | |
| 23 | + :export: | |
| 24 | + | |
| 25 | +.. kernel-doc:: kernel/sched/cpupri.c | |
| 26 | + :internal: | |
| 27 | + | |
| 28 | +.. kernel-doc:: kernel/sched/fair.c | |
| 29 | + :internal: | |
| 30 | + | |
| 31 | +.. kernel-doc:: include/linux/completion.h | |
| 32 | + :internal: | |
| 33 | + | |
| 34 | +.. kernel-doc:: kernel/time/timer.c | |
| 35 | + :export: | |
| 36 | + | |
| 37 | +Wait queues and Wake events | |
| 38 | +--------------------------- | |
| 39 | + | |
| 40 | +.. kernel-doc:: include/linux/wait.h | |
| 41 | + :internal: | |
| 42 | + | |
| 43 | +.. kernel-doc:: kernel/sched/wait.c | |
| 44 | + :export: | |
| 45 | + | |
| 46 | +High-resolution timers | |
| 47 | +---------------------- | |
| 48 | + | |
| 49 | +.. kernel-doc:: include/linux/ktime.h | |
| 50 | + :internal: | |
| 51 | + | |
| 52 | +.. kernel-doc:: include/linux/hrtimer.h | |
| 53 | + :internal: | |
| 54 | + | |
| 55 | +.. kernel-doc:: kernel/time/hrtimer.c | |
| 56 | + :export: | |
| 57 | + | |
| 58 | +Workqueues and Kevents | |
| 59 | +---------------------- | |
| 60 | + | |
| 61 | +.. kernel-doc:: include/linux/workqueue.h | |
| 62 | + :internal: | |
| 63 | + | |
| 64 | +.. kernel-doc:: kernel/workqueue.c | |
| 65 | + :export: | |
| 66 | + | |
| 67 | +Internal Functions | |
| 68 | +------------------ | |
| 69 | + | |
| 70 | +.. kernel-doc:: kernel/exit.c | |
| 71 | + :internal: | |
| 72 | + | |
| 73 | +.. kernel-doc:: kernel/signal.c | |
| 74 | + :internal: | |
| 75 | + | |
| 76 | +.. kernel-doc:: include/linux/kthread.h | |
| 77 | + :internal: | |
| 78 | + | |
| 79 | +.. kernel-doc:: kernel/kthread.c | |
| 80 | + :export: | |
| 81 | + | |
| 82 | +Kernel objects manipulation | |
| 83 | +--------------------------- | |
| 84 | + | |
| 85 | +.. kernel-doc:: lib/kobject.c | |
| 86 | + :export: | |
| 87 | + | |
| 88 | +Kernel utility functions | |
| 89 | +------------------------ | |
| 90 | + | |
| 91 | +.. kernel-doc:: include/linux/kernel.h | |
| 92 | + :internal: | |
| 93 | + | |
| 94 | +.. kernel-doc:: kernel/printk/printk.c | |
| 95 | + :export: | |
| 96 | + | |
| 97 | +.. kernel-doc:: kernel/panic.c | |
| 98 | + :export: | |
| 99 | + | |
| 100 | +.. kernel-doc:: kernel/sys.c | |
| 101 | + :export: | |
| 102 | + | |
| 103 | +.. kernel-doc:: kernel/rcu/srcu.c | |
| 104 | + :export: | |
| 105 | + | |
| 106 | +.. kernel-doc:: kernel/rcu/tree.c | |
| 107 | + :export: | |
| 108 | + | |
| 109 | +.. kernel-doc:: kernel/rcu/tree_plugin.h | |
| 110 | + :export: | |
| 111 | + | |
| 112 | +.. kernel-doc:: kernel/rcu/update.c | |
| 113 | + :export: | |
| 114 | + | |
| 115 | +Device Resource Management | |
| 116 | +-------------------------- | |
| 117 | + | |
| 118 | +.. kernel-doc:: drivers/base/devres.c | |
| 119 | + :export: | |
| 120 | + | |
| @@ -0,0 +1,62 @@ | ||
| 1 | +Frame Buffer Library | |
| 2 | +==================== | |
| 3 | + | |
| 4 | +The frame buffer drivers depend heavily on four data structures. These | |
| 5 | +structures are declared in include/linux/fb.h. They are fb_info, | |
| 6 | +fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. The last | |
| 7 | +three can be made available to and from userland. | |
| 8 | + | |
| 9 | +fb_info defines the current state of a particular video card. Inside | |
| 10 | +fb_info, there exists a fb_ops structure which is a collection of | |
| 11 | +needed functions to make fbdev and fbcon work. fb_info is only visible | |
| 12 | +to the kernel. | |
| 13 | + | |
| 14 | +fb_var_screeninfo is used to describe the features of a video card | |
| 15 | +that are user defined. With fb_var_screeninfo, things such as depth | |
| 16 | +and the resolution may be defined. | |
| 17 | + | |
| 18 | +The next structure is fb_fix_screeninfo. This defines the properties | |
| 19 | +of a card that are created when a mode is set and can't be changed | |
| 20 | +otherwise. A good example of this is the start of the frame buffer | |
| 21 | +memory. This "locks" the address of the frame buffer memory, so that it | |
| 22 | +cannot be changed or moved. | |
| 23 | + | |
| 24 | +The last structure is fb_monospecs. In the old API, there was little | |
| 25 | +importance for fb_monospecs. This allowed for forbidden things such as | |
| 26 | +setting a mode of 800x600 on a fix frequency monitor. With the new API, | |
| 27 | +fb_monospecs prevents such things, and if used correctly, can prevent a | |
| 28 | +monitor from being cooked. fb_monospecs will not be useful until | |
| 29 | +kernels 2.5.x. | |
| 30 | + | |
| 31 | +Frame Buffer Memory | |
| 32 | +------------------- | |
| 33 | + | |
| 34 | +.. kernel-doc:: drivers/video/fbdev/core/fbmem.c | |
| 35 | + :export: | |
| 36 | + | |
| 37 | +Frame Buffer Colormap | |
| 38 | +--------------------- | |
| 39 | + | |
| 40 | +.. kernel-doc:: drivers/video/fbdev/core/fbcmap.c | |
| 41 | + :export: | |
| 42 | + | |
| 43 | +Frame Buffer Video Mode Database | |
| 44 | +-------------------------------- | |
| 45 | + | |
| 46 | +.. kernel-doc:: drivers/video/fbdev/core/modedb.c | |
| 47 | + :internal: | |
| 48 | + | |
| 49 | +.. kernel-doc:: drivers/video/fbdev/core/modedb.c | |
| 50 | + :export: | |
| 51 | + | |
| 52 | +Frame Buffer Macintosh Video Mode Database | |
| 53 | +------------------------------------------ | |
| 54 | + | |
| 55 | +.. kernel-doc:: drivers/video/fbdev/macmodes.c | |
| 56 | + :export: | |
| 57 | + | |
| 58 | +Frame Buffer Fonts | |
| 59 | +------------------ | |
| 60 | + | |
| 61 | +Refer to the file lib/fonts/fonts.c for more information. | |
| 62 | + | |
| @@ -0,0 +1,88 @@ | ||
| 1 | +High Speed Synchronous Serial Interface (HSI) | |
| 2 | +============================================= | |
| 3 | + | |
| 4 | +Introduction | |
| 5 | +--------------- | |
| 6 | + | |
| 7 | +High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol, | |
| 8 | +that is optimized for die-level interconnect between an Application Processor | |
| 9 | +and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and | |
| 10 | +implemented by multiple vendors since then. | |
| 11 | + | |
| 12 | +The HSI interface supports full duplex communication over multiple channels | |
| 13 | +(typically 8) and is capable of reaching speeds up to 200 Mbit/s. | |
| 14 | + | |
| 15 | +The serial protocol uses two signals, DATA and FLAG as combined data and clock | |
| 16 | +signals and an additional READY signal for flow control. An additional WAKE | |
| 17 | +signal can be used to wakeup the chips from standby modes. The signals are | |
| 18 | +commonly prefixed by AC for signals going from the application die to the | |
| 19 | +cellular die and CA for signals going the other way around. | |
| 20 | + | |
| 21 | +:: | |
| 22 | + | |
| 23 | + +------------+ +---------------+ | |
| 24 | + | Cellular | | Application | | |
| 25 | + | Die | | Die | | |
| 26 | + | | - - - - - - CAWAKE - - - - - - >| | | |
| 27 | + | T|------------ CADATA ------------>|R | | |
| 28 | + | X|------------ CAFLAG ------------>|X | | |
| 29 | + | |<----------- ACREADY ------------| | | |
| 30 | + | | | | | |
| 31 | + | | | | | |
| 32 | + | |< - - - - - ACWAKE - - - - - - -| | | |
| 33 | + | R|<----------- ACDATA -------------|T | | |
| 34 | + | X|<----------- ACFLAG -------------|X | | |
| 35 | + | |------------ CAREADY ----------->| | | |
| 36 | + | | | | | |
| 37 | + | | | | | |
| 38 | + +------------+ +---------------+ | |
| 39 | + | |
| 40 | +HSI Subsystem in Linux | |
| 41 | +------------------------- | |
| 42 | + | |
| 43 | +In the Linux kernel the hsi subsystem is supposed to be used for HSI devices. | |
| 44 | +The hsi subsystem contains drivers for hsi controllers including support for | |
| 45 | +multi-port controllers and provides a generic API for using the HSI ports. | |
| 46 | + | |
| 47 | +It also contains HSI client drivers, which make use of the generic API to | |
| 48 | +implement a protocol used on the HSI interface. These client drivers can | |
| 49 | +use an arbitrary number of channels. | |
| 50 | + | |
| 51 | +hsi-char Device | |
| 52 | +------------------ | |
| 53 | + | |
| 54 | +Each port automatically registers a generic client driver called hsi_char, | |
| 55 | +which provides a charecter device for userspace representing the HSI port. | |
| 56 | +It can be used to communicate via HSI from userspace. Userspace may | |
| 57 | +configure the hsi_char device using the following ioctl commands: | |
| 58 | + | |
| 59 | +HSC_RESET | |
| 60 | + flush the HSI port | |
| 61 | + | |
| 62 | +HSC_SET_PM | |
26 more lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 376 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 258 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 289 lines aren’t shown here.
This diff is large: its 567 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 237 lines aren’t shown here.
This diff is large: its 455 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 252 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 1380 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 261 lines aren’t shown here.
This diff is large: its 755 lines aren’t shown here.
This diff is large: its 3136 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 167 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 267 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
Binary file not shown.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 301 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 1505 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 312 lines aren’t shown here.
Binary file not shown.
Binary file not shown.
This diff is large: its 277 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 941 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 983 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 4136 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 767 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 314 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 387 lines aren’t shown here.
This diff is large: its 1063 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 275 lines aren’t shown here.
This diff is large: its 274 lines aren’t shown here.
This diff is large: its 277 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
This diff is large: its 347 lines aren’t shown here.
This diff is large: its 352 lines aren’t shown here.
This diff is large: its 203 lines aren’t shown here.
This diff is large: its 2227 lines aren’t shown here.
This diff is large: its 485 lines aren’t shown here.
This diff is large: its 565 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 253 lines aren’t shown here.
This diff is large: its 253 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 145 lines aren’t shown here.
This diff is large: its 361 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 253 lines aren’t shown here.
This diff is large: its 255 lines aren’t shown here.
This diff is large: its 298 lines aren’t shown here.
This diff is large: its 308 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 293 lines aren’t shown here.
This diff is large: its 323 lines aren’t shown here.
This diff is large: its 263 lines aren’t shown here.
This diff is large: its 253 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17975 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 190 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 364 lines aren’t shown here.
This diff is large: its 820 lines aren’t shown here.
This diff is large: its 321 lines aren’t shown here.
This diff is large: its 205 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 212 lines aren’t shown here.
This diff is large: its 262 lines aren’t shown here.
This diff is large: its 306 lines aren’t shown here.
This diff is large: its 242 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 500 lines aren’t shown here.
This diff is large: its 284 lines aren’t shown here.
This diff is large: its 395 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 182 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 549 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 238 lines aren’t shown here.
This diff is large: its 674 lines aren’t shown here.
This diff is large: its 679 lines aren’t shown here.
This diff is large: its 205 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 197 lines aren’t shown here.
This diff is large: its 334 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 479 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 180 lines aren’t shown here.
This diff is large: its 381 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 1021 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 623 lines aren’t shown here.
This diff is large: its 1086 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 178 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 310 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 306 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 203 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 268 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 191 lines aren’t shown here.
This diff is large: its 1613 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 293 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 234 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 597 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 830 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
File renamed without changes.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 179 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 222 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 550 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 795 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 512 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 899 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 704 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 482 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 312 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 254 lines aren’t shown here.
This diff is large: its 621 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 254 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 225 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 434 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 482 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 362 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 447 lines aren’t shown here.
This diff is large: its 501 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 343 lines aren’t shown here.
This diff is large: its 1088 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 252 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 227 lines aren’t shown here.
This diff is large: its 117 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 263 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 289 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 636 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 356 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 383 lines aren’t shown here.
This diff is large: its 311 lines aren’t shown here.
This diff is large: its 404 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 735 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 815 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 244 lines aren’t shown here.
This diff is large: its 368 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 301 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 173 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 728 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 194 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 472 lines aren’t shown here.
This diff is large: its 223 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 227 lines aren’t shown here.
This diff is large: its 271 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 179 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 180 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 125 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 168 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 744 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 209 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 306 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
Empty file deleted.
This diff is large: its 276 lines aren’t shown here.
This diff is large: its 148 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 189 lines aren’t shown here.
This diff is large: its 374 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 114 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 173 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 431 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 1313 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 406 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 248 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 493 lines aren’t shown here.
This diff is large: its 396 lines aren’t shown here.
This diff is large: its 386 lines aren’t shown here.
This diff is large: its 308 lines aren’t shown here.
This diff is large: its 403 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 210 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 585 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 454 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 217 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 387 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 120 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 439 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 226 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 379 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 250 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 119 lines aren’t shown here.
This diff is large: its 140 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 359 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 329 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 333 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 383 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 125 lines aren’t shown here.
This diff is large: its 992 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 339 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 221 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 313 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 293 lines aren’t shown here.
This diff is large: its 169 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 172 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 125 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 371 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 408 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 226 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 199 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 166 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 160 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 82 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 126 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 250 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 106 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 104 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 207 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 102 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 135 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 254 lines aren’t shown here.
This diff is large: its 386 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 3 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 377 lines aren’t shown here.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 507 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 88 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 319 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 137 lines aren’t shown here.
This diff is large: its 101 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 143 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 253 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 173 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 153 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 224 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 320 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 254 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 237 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 163 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 205 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 79 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 134 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 316 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 394 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 130 lines aren’t shown here.
This diff is large: its 193 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 2305 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 243 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 391 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 749 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 399 lines aren’t shown here.
This diff is large: its 548 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 297 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 770 lines aren’t shown here.
This diff is large: its 167 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 321 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 196 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 417 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 65 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 80 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 262 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 74 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 83 lines aren’t shown here.
This diff is large: its 865 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 561 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 203 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 349 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 297 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 363 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 182 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 131 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 146 lines aren’t shown here.
This diff is large: its 214 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 395 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 116 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 175 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 109 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 122 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 93 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 252 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 230 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 247 lines aren’t shown here.
This diff is large: its 133 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 192 lines aren’t shown here.
This diff is large: its 132 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 732 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 188 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 155 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 181 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 201 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 319 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 43 lines aren’t shown here.
This diff is large: its 307 lines aren’t shown here.
This diff is large: its 202 lines aren’t shown here.
This diff is large: its 390 lines aren’t shown here.
This diff is large: its 410 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 338 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 30 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 115 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 81 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 180 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 61 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 576 lines aren’t shown here.
This diff is large: its 457 lines aren’t shown here.
This diff is large: its 323 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 6 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 45 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 185 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 318 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 174 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 267 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 405 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 141 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 280 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 154 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 657 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 761 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 161 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 118 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 301 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 337 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 576 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 108 lines aren’t shown here.
This diff is large: its 723 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 814 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 144 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 355 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 171 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 32 lines aren’t shown here.
This diff is large: its 71 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 124 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 96 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 69 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 150 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 78 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 261 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 75 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 199 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 91 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 190 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 94 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 156 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 368 lines aren’t shown here.
This diff is large: its 55 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 177 lines aren’t shown here.
This diff is large: its 349 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 7 lines aren’t shown here.
This diff is large: its 2 lines aren’t shown here.
This diff is large: its 369 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 121 lines aren’t shown here.
This diff is large: its 976 lines aren’t shown here.
This diff is large: its 657 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 105 lines aren’t shown here.
This diff is large: its 514 lines aren’t shown here.
This diff is large: its 48 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 241 lines aren’t shown here.
This diff is large: its 142 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 157 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 200 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 187 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 72 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 380 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 50 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 444 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 15 lines aren’t shown here.
This diff is large: its 53 lines aren’t shown here.
This diff is large: its 735 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 21 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 19 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 14 lines aren’t shown here.
This diff is large: its 37 lines aren’t shown here.
This diff is large: its 138 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 41 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 756 lines aren’t shown here.
This diff is large: its 184 lines aren’t shown here.
This diff is large: its 2223 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 35 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 183 lines aren’t shown here.
This diff is large: its 169 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 272 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 70 lines aren’t shown here.
This diff is large: its 388 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 90 lines aren’t shown here.
This diff is large: its 382 lines aren’t shown here.
This diff is large: its 128 lines aren’t shown here.
This diff is large: its 409 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 211 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 87 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 67 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 5 lines aren’t shown here.
This diff is large: its 506 lines aren’t shown here.
This diff is large: its 31 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 215 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 129 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 151 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 60 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 73 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 261 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 66 lines aren’t shown here.
This diff is large: its 274 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 42 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 68 lines aren’t shown here.
This diff is large: its 26 lines aren’t shown here.
This diff is large: its 232 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 112 lines aren’t shown here.
This diff is large: its 64 lines aren’t shown here.
This diff is large: its 59 lines aren’t shown here.
This diff is large: its 63 lines aren’t shown here.
This diff is large: its 431 lines aren’t shown here.
This diff is large: its 57 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 170 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 479 lines aren’t shown here.
This diff is large: its 23 lines aren’t shown here.
This diff is large: its 11 lines aren’t shown here.
This diff is large: its 38 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 331 lines aren’t shown here.
This diff is large: its 149 lines aren’t shown here.
This diff is large: its 164 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 52 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 18 lines aren’t shown here.
This diff is large: its 25 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 226 lines aren’t shown here.
This diff is large: its 95 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 28 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 85 lines aren’t shown here.
This diff is large: its 103 lines aren’t shown here.
This diff is large: its 127 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 107 lines aren’t shown here.
This diff is large: its 111 lines aren’t shown here.
This diff is large: its 100 lines aren’t shown here.
This diff is large: its 162 lines aren’t shown here.
This diff is large: its 195 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 303 lines aren’t shown here.
This diff is large: its 97 lines aren’t shown here.
This diff is large: its 49 lines aren’t shown here.
This diff is large: its 58 lines aren’t shown here.
This diff is large: its 47 lines aren’t shown here.
This diff is large: its 51 lines aren’t shown here.
This diff is large: its 24 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 89 lines aren’t shown here.
This diff is large: its 99 lines aren’t shown here.
This diff is large: its 27 lines aren’t shown here.
This diff is large: its 176 lines aren’t shown here.
This diff is large: its 36 lines aren’t shown here.
This diff is large: its 139 lines aren’t shown here.
This diff is large: its 56 lines aren’t shown here.
This diff is large: its 39 lines aren’t shown here.
This diff is large: its 235 lines aren’t shown here.
This diff is large: its 110 lines aren’t shown here.
This diff is large: its 29 lines aren’t shown here.
This diff is large: its 33 lines aren’t shown here.
This diff is large: its 62 lines aren’t shown here.
This diff is large: its 46 lines aren’t shown here.
This diff is large: its 34 lines aren’t shown here.
This diff is large: its 86 lines aren’t shown here.
This diff is large: its 320 lines aren’t shown here.
This diff is large: its 16 lines aren’t shown here.
This diff is large: its 4 lines aren’t shown here.
This diff is large: its 123 lines aren’t shown here.
This diff is large: its 98 lines aren’t shown here.
This diff is large: its 44 lines aren’t shown here.
This diff is large: its 20 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 12 lines aren’t shown here.
This diff is large: its 54 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 192 lines aren’t shown here.
This diff is large: its 205 lines aren’t shown here.
This diff is large: its 84 lines aren’t shown here.
This diff is large: its 415 lines aren’t shown here.
This diff is large: its 152 lines aren’t shown here.
This diff is large: its 13 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 448 lines aren’t shown here.
This diff is large: its 159 lines aren’t shown here.
This diff is large: its 92 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 76 lines aren’t shown here.
This diff is large: its 77 lines aren’t shown here.
This diff is large: its 10 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 40 lines aren’t shown here.
This diff is large: its 22 lines aren’t shown here.
This diff is large: its 17 lines aren’t shown here.
This diff is large: its 9 lines aren’t shown here.
This diff is large: its 113 lines aren’t shown here.
This diff is large: its 8 lines aren’t shown here.
This diff is large: its 1728 lines aren’t shown here.
This diff is larger than a page shows: the files after these aren’t listed. Clone the repository to see all of it.
