Searched hist:4 (Results 401 - 425 of 17372) sorted by relevance
| /freebsd-10.2-release/share/man/man4/ | ||
| H A D | re.4 | diff 217870 Wed Jan 26 01:20:08 MST 2011 dougb Fix my fix to nfe.4, and also fix re.4 So just when I thought my pointy hat collection was going down ... diff 217870 Wed Jan 26 01:20:08 MST 2011 dougb Fix my fix to nfe.4, and also fix re.4 So just when I thought my pointy hat collection was going down ... diff 217464 Sat Jan 15 22:07:21 MST 2011 marius Add a manual page for rgephy(4) and reference it as appropriate. The motivation for having rgephy.4 is to document the special media option add in r217415. MFC after: 3 days diff 217464 Sat Jan 15 22:07:21 MST 2011 marius Add a manual page for rgephy(4) and reference it as appropriate. The motivation for having rgephy.4 is to document the special media option add in r217415. MFC after: 3 days diff 214432 Wed Oct 27 19:02:22 MDT 2010 yongari Use shorten model name and add RTL8168, RTL8111 to the list of supported device. re(4) had been supported all variants of RTL8168, RTL8111 and RTL810x. I think this change will cover all controllers supported by re(4). MFC after: 1 week diff 214432 Wed Oct 27 19:02:22 MDT 2010 yongari Use shorten model name and add RTL8168, RTL8111 to the list of supported device. re(4) had been supported all variants of RTL8168, RTL8111 and RTL810x. I think this change will cover all controllers supported by re(4). MFC after: 1 week diff 166346 Tue Jan 30 08:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 166346 Tue Jan 30 08:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 164532 Thu Nov 23 00:28:58 MST 2006 yongari Add USR997902 to the list of devices supported by re(4). diff 154362 Sat Jan 14 15:35:21 MST 2006 bz The LinkSys EG1032 is supported by re(4) not nge(4) [1]. I couldn't find the ID for the EG1064 anywhere in our sources so I removed the reference for now. Pointed out by: Robert Huff <roberthuffi at rcn dot com> [1] Reviewed by: simon diff 154362 Sat Jan 14 15:35:21 MST 2006 bz The LinkSys EG1032 is supported by re(4) not nge(4) [1]. I couldn't find the ID for the EG1064 anywhere in our sources so I removed the reference for now. Pointed out by: Robert Huff <roberthuffi at rcn dot com> [1] Reviewed by: simon |
| H A D | ed.4 | diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days diff 231244 Thu Feb 09 04:53:46 MST 2012 gjb Fix some Xr references: - ada(4): ad(4) - removed, ada(4) would be a self-referencing entry - cd(4): ad(4) -> ada(4) - da(4): ad(4) -> ada(4) - DEVICE_PROBE(9): ugen(5) -> ugen(4) - ed(4): dhclinet(8) -> dhclient(8) (typo) - lmc(4): Netgraph(4) -> netgraph(4) - security(7): rc.conf(8) -> rc.conf(5) - sfxge(4): cpuset(8) -> cpuset(1) - sbp(4): sysctl(1) -> sysctl(8) - portindex(5): build(1) -> build(7) - u3g(4): usbconfig(5) -> usbconfig(8) - usb_quirk(4): usbconfig(5) -> usbconfig(8) Found with: textproc/igor MFC after: 3 days |
| H A D | bce.4 | diff 236412 Fri Jun 01 18:07:19 MDT 2012 sbruno Add notes and information for exposed tuneables in bce(4). Add source of documentation for this driver. Thanks to Warren Block for the suggestions for readability. Note that strict_rx_mtu in inverted in stable/7/8/9 and is named loose_rx_mtu. Ensure that this is converted over when MFC'd hw.bce.rx_ticks hw.bce.rx_ticks_int hw.bce.rx_quick_cons_trip hw.bce.rx_quick_cons_trip_int hw.bce.tx_ticks hw.bce.tx_ticks_int hw.bce.tx_quick_cons_trip hw.bce.tx_quick_cons_trip_int hw.bce.strict_rx_mtu hw.bce.hdr_split hw.bce.tx_pages hw.bce.rx_pages hw.bce.tso_enable hw.bce.verbose Reviewed by: Warren Block <wblock@wonkity.com> MFC after: 3 days diff 197835 Wed Oct 07 13:46:10 MDT 2009 simon - Document that 'Dell PowerEdge R710' has bce(4) supported NIC. - Bump document date. MFC after: 3 days diff 190832 Tue Apr 07 22:32:15 MDT 2009 delphij Add the following media types as supported by bce(4): - 1000BaseSX - 2500BaseSX While I'm there, correct 1000BaseTX as more standard 1000BaseT. MFC after: 3 days diff 187318 Thu Jan 15 22:54:46 MST 2009 delphij Reflect newly added PCI IDs to bce(4). MFC after: 2 months diff 185574 Wed Dec 03 01:49:18 MST 2008 delphij Update bce(4)'s hardware list to reflect the recent update to driver. MFC after: 3 days diff 183648 Mon Oct 06 18:21:35 MDT 2008 simon Document that the bce(4) driver works with Dell PowerEdge 1950/2950 NIC's. MFC after: 3 days diff 166474 Sat Feb 03 19:29:31 MST 2007 brueffer Xref altq(4). diff 164819 Sat Dec 02 09:03:06 MST 2006 brueffer bce(4) does not work correctly in polling(4) mode for now. diff 164819 Sat Dec 02 09:03:06 MST 2006 brueffer bce(4) does not work correctly in polling(4) mode for now. |
| /freebsd-10.2-release/sys/pci/ | ||
| H A D | intpm.c | diff 189882 Mon Mar 16 16:20:24 MDT 2009 avg intpm: minor enhancements 1. fix nointr check in intsmb_start, matters only if ENABLE_ALART is defined (by default, it is not); 2. drop unnecessary inspection/reporting of power-management io registers base address; 3. in verbose mode report errors from SMBus host controller and their mapping to smbus(4) errors; Approved by: jhb (mentor) diff 168870 Thu Apr 19 17:14:06 MDT 2007 jhb Oops, fix intsmb(4) attach. Don't overwrite the 'value' holding the interrupt mode with the SMB revision before checking 'value' for a valid interrupt mode. Reported by: Ulrich Spoerlein <uspoerlein of gmail fame> diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. |
| /freebsd-10.2-release/sys/dev/vt/ | ||
| H A D | vt_core.c | diff 282823 Tue May 12 18:25:45 MDT 2015 emaste MFC r281944: vt(4): Simplify mouse area detection vt_is_cursor_in_area needs to return true if any part of the mouse cursor is visible in the rectangle area. Replace the existing test with a simpler version of a test for overlapping rectangles. Sponsored by: The FreeBSD Foundation diff 282749 Mon May 11 08:01:04 MDT 2015 avg MFC r277795,278849: vt(4): Use power_{suspend,resume} event handlers diff 274861 Sat Nov 22 17:11:08 MST 2014 dumbbell vt(4): Fix keyboard allocation when kbdmux(4) isn't used The problem was that only the kbdmux keyboard index was saved in vd->vd_keyboard. This index is -1 when kbdmux isn't used. In this case, the keyboard was correctly allocated, but the returned index was discarded. PR: 194718 MFC of: r273973 diff 274861 Sat Nov 22 17:11:08 MST 2014 dumbbell vt(4): Fix keyboard allocation when kbdmux(4) isn't used The problem was that only the kbdmux keyboard index was saved in vd->vd_keyboard. This index is -1 when kbdmux isn't used. In this case, the keyboard was correctly allocated, but the returned index was discarded. PR: 194718 MFC of: r273973 diff 274860 Sat Nov 22 17:03:22 MST 2014 dumbbell vt(4): Adjust the cursor position after changing the window size A new terminal_set_cursor() is added: it wraps the existing teken_set_cursor() function. In vtbuf_grow(), the cursor position is adjusted at the end of the function. In vt_change_font(), we call terminal_set_cursor() just after terminal_set_winsize_blank(), while the terminal is mute. This fixes a bug where, after loading a kernel video driver which increases the terminal window size, the cursor remains at its old position, in other words, in the middle of the display content. PR: 194421 MFC of: r273932 diff 273921 Fri Oct 31 23:13:17 MDT 2014 dumbbell vt(4): Add PIO_VFONT_DEFAULT ioctl to restore the default builtin font To restore the default font using vidcontrol(1), use the "-f" flag without an argument: vidcontrol -f < /dev/ttyv0 PR: 193910 Differential Revision: https://reviews.freebsd.org/D971 Submitted by: Marcin Cieslak <saper@saper.info> Reviewed by: ray@, emaste@ Approved by: ray@ MFC of: r273544 diff 273545 Thu Oct 23 13:37:58 MDT 2014 dumbbell vt(4): Refuse to load a font if hw.vga.textmode is selected Before, the font was loaded and the window size recalculated, giving an unusable terminal, even if the actual font didn't change. Reported by: beeessdee@ruggedinbox.com MFC of: r273330 diff 273037 Mon Oct 13 14:47:24 MDT 2014 dumbbell vt(4): Don't recalculate buffer size if we don't know screen size (MFC of r272537) When the screen size is unknown, it's set to 0x0. We can't use that as the buffer size, otherwise, functions such as vtbuf_fill() will fail. This fixes a panic on RaspberryPi, where there's no vt(4) backend configured early in boot. PR: 193981 Tested by: danilo@ diff 273037 Mon Oct 13 14:47:24 MDT 2014 dumbbell vt(4): Don't recalculate buffer size if we don't know screen size (MFC of r272537) When the screen size is unknown, it's set to 0x0. We can't use that as the buffer size, otherwise, functions such as vtbuf_fill() will fail. This fixes a panic on RaspberryPi, where there's no vt(4) backend configured early in boot. PR: 193981 Tested by: danilo@ diff 273036 Mon Oct 13 13:57:47 MDT 2014 dumbbell vt(4): Save/restore keyboard mode & LED states when switching window (MFC of r272416) Add new functions to manipulate these mode & state, instead of calling kbdd_ioctl() everyhere. This fixes at least two bugs: 1. The state of the Scroll Lock LED and the state of scroll mode could be out-of-sync. For instance, if one enables scroll mode on window #1 and switches to window #2, the LED would remain on, but the window wouldn't be in scroll mode. Similarily, when switching between a console and an X.Org session, the LED states could be inconsistent with the real state. 2. When exiting from an X.Org session, the user could be unable to type anything. The workaround was to switch to another console window and come back. Differential Revision: https://reviews.freebsd.org/D821 Reviewed by: ray@ Approved by: ray@ Tested by: kwm@ |
| /freebsd-10.2-release/sys/dev/vge/ | ||
| H A D | if_vgevar.h | diff 200759 Sun Dec 20 19:51:51 MST 2009 yongari Disable jumbo frame support for PCIe VT6130/VT6132 controllers. Quite contrary to VT6130 datasheet which says it supports up to 8K jumbo frame, VT6130 does not seem to send jumbo frame that is larger than 4K in length. Trying to send a frame that is larger than 4K cause TX MAC hang. Even though it's possible to allow 4K jumbo frame for VT6130, I think it's meaningless to allow 4K jumbo frame. I'm not sure VT6132 also has the same limitation but I guess it uses the same MAC of VT6130. diff 200759 Sun Dec 20 19:51:51 MST 2009 yongari Disable jumbo frame support for PCIe VT6130/VT6132 controllers. Quite contrary to VT6130 datasheet which says it supports up to 8K jumbo frame, VT6130 does not seem to send jumbo frame that is larger than 4K in length. Trying to send a frame that is larger than 4K cause TX MAC hang. Even though it's possible to allow 4K jumbo frame for VT6130, I think it's meaningless to allow 4K jumbo frame. I'm not sure VT6132 also has the same limitation but I guess it uses the same MAC of VT6130. diff 200759 Sun Dec 20 19:51:51 MST 2009 yongari Disable jumbo frame support for PCIe VT6130/VT6132 controllers. Quite contrary to VT6130 datasheet which says it supports up to 8K jumbo frame, VT6130 does not seem to send jumbo frame that is larger than 4K in length. Trying to send a frame that is larger than 4K cause TX MAC hang. Even though it's possible to allow 4K jumbo frame for VT6130, I think it's meaningless to allow 4K jumbo frame. I'm not sure VT6132 also has the same limitation but I guess it uses the same MAC of VT6130. diff 200759 Sun Dec 20 19:51:51 MST 2009 yongari Disable jumbo frame support for PCIe VT6130/VT6132 controllers. Quite contrary to VT6130 datasheet which says it supports up to 8K jumbo frame, VT6130 does not seem to send jumbo frame that is larger than 4K in length. Trying to send a frame that is larger than 4K cause TX MAC hang. Even though it's possible to allow 4K jumbo frame for VT6130, I think it's meaningless to allow 4K jumbo frame. I'm not sure VT6132 also has the same limitation but I guess it uses the same MAC of VT6130. diff 200758 Sun Dec 20 19:16:47 MST 2009 yongari VT6130 datasheet was wrong. If VT6130 receive a jumbo frame the controller will split the jumbo frame into multiple RX buffers. However it seems the hardware always dma the frame to 8 bytes boundary for the split frames. Only the first part of the fragment can have 4 byte alignment and subsequent buffers should be 8 bytes aligned. Change RX buffer the alignment requirement to 8 bytes from 4 bytes. diff 200758 Sun Dec 20 19:16:47 MST 2009 yongari VT6130 datasheet was wrong. If VT6130 receive a jumbo frame the controller will split the jumbo frame into multiple RX buffers. However it seems the hardware always dma the frame to 8 bytes boundary for the split frames. Only the first part of the fragment can have 4 byte alignment and subsequent buffers should be 8 bytes aligned. Change RX buffer the alignment requirement to 8 bytes from 4 bytes. diff 200638 Thu Dec 17 18:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx controllers. TX/RX interrupt mitigation is controlled by VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress generation of interrupts until the programmed frames counter equals to the registers. VT61xx also supports interrupt hold off timer register. If this interrupt hold off timer is active all interrupts would be disabled until the timer reaches to 0. The timer value is reloaded whenever VGE_ISR register written. The timer resolution is about 20us. Previously vge(4) used single shot timer to reduce Tx completion interrupts. This required VGE_CRS1 register access in Tx start/completion handler to rearm new timeout value and it did not show satisfactory result(more than 50k interrupts under load). Rx interrupts was not moderated at all such that vge(4) used to generate too many interrupts which in turn made polling(4) better approach under high network load. This change activates all interrupt moderation mechanism and initial values were tuned to generate interrupt less than 8k per second. That number of interrupts wouldn't add additional packet latencies compared to polling(4). These interrupt parameters could be changed with sysctl. dev.vge.%d.int_holdoff dev.vge.%d.rx_coal_pkt dev.vge.%d.tx_coal_pkt Interface has be brought down and up again before change take effect. With interrupt moderation there is no more need to loop in interrupt handler. This loop always added one more register access. While I'm here remove dead code which tried to implement subset of interrupt moderation. diff 200638 Thu Dec 17 18:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx controllers. TX/RX interrupt mitigation is controlled by VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress generation of interrupts until the programmed frames counter equals to the registers. VT61xx also supports interrupt hold off timer register. If this interrupt hold off timer is active all interrupts would be disabled until the timer reaches to 0. The timer value is reloaded whenever VGE_ISR register written. The timer resolution is about 20us. Previously vge(4) used single shot timer to reduce Tx completion interrupts. This required VGE_CRS1 register access in Tx start/completion handler to rearm new timeout value and it did not show satisfactory result(more than 50k interrupts under load). Rx interrupts was not moderated at all such that vge(4) used to generate too many interrupts which in turn made polling(4) better approach under high network load. This change activates all interrupt moderation mechanism and initial values were tuned to generate interrupt less than 8k per second. That number of interrupts wouldn't add additional packet latencies compared to polling(4). These interrupt parameters could be changed with sysctl. dev.vge.%d.int_holdoff dev.vge.%d.rx_coal_pkt dev.vge.%d.tx_coal_pkt Interface has be brought down and up again before change take effect. With interrupt moderation there is no more need to loop in interrupt handler. This loop always added one more register access. While I'm here remove dead code which tried to implement subset of interrupt moderation. diff 200638 Thu Dec 17 18:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx controllers. TX/RX interrupt mitigation is controlled by VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress generation of interrupts until the programmed frames counter equals to the registers. VT61xx also supports interrupt hold off timer register. If this interrupt hold off timer is active all interrupts would be disabled until the timer reaches to 0. The timer value is reloaded whenever VGE_ISR register written. The timer resolution is about 20us. Previously vge(4) used single shot timer to reduce Tx completion interrupts. This required VGE_CRS1 register access in Tx start/completion handler to rearm new timeout value and it did not show satisfactory result(more than 50k interrupts under load). Rx interrupts was not moderated at all such that vge(4) used to generate too many interrupts which in turn made polling(4) better approach under high network load. This change activates all interrupt moderation mechanism and initial values were tuned to generate interrupt less than 8k per second. That number of interrupts wouldn't add additional packet latencies compared to polling(4). These interrupt parameters could be changed with sysctl. dev.vge.%d.int_holdoff dev.vge.%d.rx_coal_pkt dev.vge.%d.tx_coal_pkt Interface has be brought down and up again before change take effect. With interrupt moderation there is no more need to loop in interrupt handler. This loop always added one more register access. While I'm here remove dead code which tried to implement subset of interrupt moderation. diff 200638 Thu Dec 17 18:07:36 MST 2009 yongari Implement interrupt moderation scheme supported by VT61xx controllers. TX/RX interrupt mitigation is controlled by VGE_TXSUPPTHR and VGE_RXSUPPTHR register. These registers suppress generation of interrupts until the programmed frames counter equals to the registers. VT61xx also supports interrupt hold off timer register. If this interrupt hold off timer is active all interrupts would be disabled until the timer reaches to 0. The timer value is reloaded whenever VGE_ISR register written. The timer resolution is about 20us. Previously vge(4) used single shot timer to reduce Tx completion interrupts. This required VGE_CRS1 register access in Tx start/completion handler to rearm new timeout value and it did not show satisfactory result(more than 50k interrupts under load). Rx interrupts was not moderated at all such that vge(4) used to generate too many interrupts which in turn made polling(4) better approach under high network load. This change activates all interrupt moderation mechanism and initial values were tuned to generate interrupt less than 8k per second. That number of interrupts wouldn't add additional packet latencies compared to polling(4). These interrupt parameters could be changed with sysctl. dev.vge.%d.int_holdoff dev.vge.%d.rx_coal_pkt dev.vge.%d.tx_coal_pkt Interface has be brought down and up again before change take effect. With interrupt moderation there is no more need to loop in interrupt handler. This loop always added one more register access. While I'm here remove dead code which tried to implement subset of interrupt moderation. |
| /freebsd-10.2-release/sys/dev/bktr/ | ||
| H A D | bktr_i2c.c | diff 181303 Mon Aug 04 21:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers: - Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425) diff 181303 Mon Aug 04 21:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers: - Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425) diff 181303 Mon Aug 04 21:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers: - Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425) diff 181303 Mon Aug 04 21:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers: - Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425) diff 181303 Mon Aug 04 21:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers: - Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425) diff 181303 Mon Aug 04 21:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers: - Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425) diff 181303 Mon Aug 04 21:02:46 MDT 2008 jhb Add locking to the various iicbus(4) bridge drivers: - Just grab Giant in the ixp425_iic(4) driver since this driver uses a shared address/data register window pair to access the actual I2C registers. None of the other ixp425 drivers lock access to these shared address/data registers yet and that would need to be done before this could use any meaningful locking. - Add locking to the interrupt handler and 'iicbus_reset' methods of the at91_twi(4) driver. - Add locking to the pcf(4) driver. Other pcf(4) fixes include: - Don't needlessly zero the softc. - Use bus_foo rather than bus_space_foo and remove bus space tag and handle from softc. - The lpbb(4) driver just grabs Giant for now. This will be refined later when ppbus(4) is locked. - As was done with smbus earlier, move the DRIVER_MODULE() lines to match the bus driver (either iicbus or iicbb) to the bridge driver into the bridge drivers. Tested by: sam (arm/ixp425) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) diff 162234 Mon Sep 11 20:52:41 MDT 2006 jhb Minor overhaul of SMBus support: - Change smbus_callback() to pass a void * rather than caddr_t. - Change smbus_bread() to pass a pointer to the count and have it be an in/out parameter. The input is the size of the buffer (same as before), but on return it will contain the actual amount of data read back from the bus. Note that this value may be larger than the input value. It is up to the caller to treat this as an error if desired. - Change the SMB_BREAD ioctl to write out the updated struct smbcmd which will contain the actual number of bytes read in the 'count' field. To preserve the previous ABI, the old ioctl value is mapped to SMB_OLD_BREAD which doesn't copy the updated smbcmd back out to userland. I doubt anyone actually used the old BREAD anyway as it was rediculous to do a bulk-read but not tell the using program how much data was actually read. - Make the smbus driver and devclass public in the smbus module and push all the DRIVER_MODULE()'s for attaching the smbus driver to various foosmb drivers out into the foosmb modules. This makes all the foosmb logic centralized and allows new foosmb modules to be self-contained w/o having to hack smbus.c everytime a new smbus driver is added. - Add a new SMB_EINVAL error bit and use it in place of EINVAL to return an error for bad arguments (such as invalid counts for bread and bwrite). - Map SMB bus error bits to EIO in smbus_error(). - Make the smbus driver call bus_generic_probe() and require child drivers such as smb(4) to create device_t's via identify routines. Previously, smbus just created one anonymous device during attach, and if you had multiple drivers that could attach it was just random chance as to which driver got to probe for the sole device_t first. - Add a mutex to the smbus(4) softc and use it in place of dummy splhigh() to protect the 'owner' field and perform necessary synchronization for smbus_request_bus() and smbus_release_bus(). - Change the bread() and bwrite() methods of alpm(4), amdpm(4), and viapm(4) to only perform a single transaction and not try to use a loop of multiple transactions for a large request. The framing and commands to use for a large transaction depend on the upper-layer protocol (such as SSIF for IPMI over SMBus) from what I can tell, and the smb(4) driver never allowed bulk read/writes of more than 32-bytes anyway. The other smb drivers only performed single transactions. - Fix buffer overflows in the bread() methods of ichsmb(4), alpm(4), amdpm(4), amdsmb(4), intpm(4), and nfsmb(4). - Use SMB_xxx errors in viapm(4). - Destroy ichsmb(4)'s mutex after bus_generic_detach() to avoid problems from child devices making smb upcalls that would use the mutex during their detach methods. MFC after: 1 week Reviewed by: jmg (mostly) |
| /freebsd-10.2-release/sys/dev/uart/ | ||
| H A D | uart_dev_sab82532.c | diff 248965 Mon Apr 01 00:54:44 MDT 2013 ian Fix low-level uart drivers that set their fifo sizes in the softc too late. uart(4) allocates send and receiver buffers in attach() before it calls the low-level driver's attach routine. Many low-level drivers set the fifo sizes in their attach routine, which is too late. Other drivers set them in the probe() routine, so that they're available when uart(4) allocates buffers. This fixes the ones that were setting the values too late by moving the code to probe(). diff 248965 Mon Apr 01 00:54:44 MDT 2013 ian Fix low-level uart drivers that set their fifo sizes in the softc too late. uart(4) allocates send and receiver buffers in attach() before it calls the low-level driver's attach routine. Many low-level drivers set the fifo sizes in their attach routine, which is too late. Other drivers set them in the probe() routine, so that they're available when uart(4) allocates buffers. This fixes the ones that were setting the values too late by moving the code to probe(). diff 166100 Thu Jan 18 22:01:19 MST 2007 marius - Add a uart_rxready() and corresponding device-specific implementations that can be used to check whether receive data is ready, i.e. whether the subsequent call of uart_poll() should return a char, and unlike uart_poll() doesn't actually receive data. - Remove the device-specific implementations of uart_poll() and implement uart_poll() in terms of uart_getc() and the newly added uart_rxready() in order to minimize code duplication. - In sunkbd(4) take advantage of uart_rxready() and use it to implement the polled mode part of sunkbd_check() so we don't need to buffer a potentially read char in the softc. - Fix some mis-indentation in sunkbd_read_char(). Discussed with: marcel diff 157300 Thu Mar 30 18:37:03 MST 2006 marcel Add support for scc(4). diff 120143 Wed Sep 17 01:41:21 MDT 2003 marcel Add locking to the hardware drivers. I intended to figure out more precisely where locking would be needed before adding it, but it seems uart(4) draws slightly too much attention to have it without locking for too long. The lock added is a spinlock that protects access to the underlying hardware. As a first and obvious stab at this, each method of the hardware interface grabs the lock. Roughly speaking this serializes the methods. Exceptions are the probe, attach and detach methods. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. |
| H A D | uart_bus_isa.c | 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. 119815 Sat Sep 06 23:13:47 MDT 2003 marcel The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten. |
| /freebsd-10.2-release/sys/dev/ofw/ | ||
| H A D | ofw_bus_if.m | diff 266128 Thu May 15 14:40:30 MDT 2014 ian MFC r261351, r261352, r261355, r261396, r261397, r261398, r261403, r261404, r261405 Open Firmware interrupt specifiers can consist of arbitrary-length byte strings and include arbitrary information (IRQ line/domain/sense). When the ofw_bus_map_intr() API was introduced, it assumed that, as on most systems, these were either 1 cell, containing an interrupt line, or 2, containing a line number plus a sense code. It turns out a non-negligible number of ARM systems use 3 (or even 4!) cells for interrupts, so make this more general. Provide a simpler and more standards-compliant simplebus implementation to get the Routerboard 800 up and running with the vendor device tree. This does not implement some BERI-specific features (which hopefully won't be necessary soon), so move the old code to mips/beri, with a higher attach priority when built, until MIPS interrupt domain support is rearranged. Allow nesting of simplebuses. Add a set of helpers (ofw_bus_get_status() and ofw_bus_status_okay()) to process "status" properties of OF nodes. Fix one remnant endian flaw in nexus. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. diff 266105 Thu May 15 01:44:32 MDT 2014 loos MFC r258046, r258047, r258050, r259035, r259036, r259037, r261842, r261843, r261844, r261845, r261846, r262194, r262522, r262559 r258046: Fix a typo on a comment in ofw_bus_if.m, the default method will return -1 when a node doesn't exist. r258047: Move the KASSERT() check to the point before the increase of number of pins. r258050: Fix gpiobus to return BUS_PROBE_GENERIC insted of BUS_PROBE_SPECIFIC (0) so it can be overriden by its OFW/FDT version. Give a chance for GPIO devices that implement the device_identify method to attach. r259035: Remove unnecessary includes and an unused softc variable. While here apply two minor style(9) fixes. r259036: Move the GPIOBUS_SET_PINFLAGS(..., ..., pin, GPIO_PIN_OUTPUT) to led(4) control callback function. This makes gpioled(4) works even if the pin is accidentally set to an input. r259037: Fix the pin value reading on AM335x. Because of the inverted logic it was always returning '0' for all the reads, even for the outputs. It is now known to work with gpioiic(4) and gpioled(4). r261842: Add an OFW GPIO compatible bus. This allows the use of the DTS files to describe GPIO bindings in the system. Move the GPIOBUS lock macros to gpiobusvar.h as they are now shared between the OFW and the non OFW versions of GPIO bus. Export gpiobus_print_pins() so it can also be used on the OFW GPIO bus. r261843: Add OFW support to the in tree gpio compatible devices: gpioiic(4) and gpioled(4). Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for the I2C tests). It was also verified for regressions on RSPRO (MIPS/ar71xx) used as reference for a non OFW-based system. Update the gpioled(4) and gpioiic(4) man pages with some details and examples about the FDT/OFW support. Some compatibility details pointed out by imp@ will follow in subsequent commits. r261844: Allow the use of OFW I2C bus together with iicbb(4) on OFW-based systems. This change makes ofw_iicbus attach to iicbb(4) controllers in addition to the already supported i2c host bridges (iichb). On iicbb(4) allow the direct access of the OFW parent node by its children, so they can be directly attached to iicbb(4) node on the DTS without the need of describing the i2c bus. r261845: Allow the use of the OFW GPIO bus for ti_gpio and bcm2835_gpio. With this change the gpio children can be described as directly connected to the GPIO controller without the need of describing the OFW GPIO bus itself on the DTS file. With this commit the OFW GPIO bus is fully functional on BBB and RPi. GPIO controllers which want to use the OFW GPIO bus will need similar changes. r261846: Make the gpioled(4) work out of the box on BBB. Add gpioled(4) to BEAGLEBONE kernel and add the description of the four on-board leds of beaglebone-black to its DTS file. r262194: Remove an unnecessary header. r262522: Fix make depend for iicbus. r262559: Inspired by r262522, fix make depend. This fixes the build of gpio modules. |
| /freebsd-10.2-release/sys/boot/forth/ | ||
| H A D | version.4th | diff 281843 Wed Apr 22 01:14:15 MDT 2015 dteske MFC revisions 277693,278335,280382-280385,280923-280926,280931, 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader diff 281843 Wed Apr 22 01:14:15 MDT 2015 dteske MFC revisions 277693,278335,280382-280385,280923-280926,280931, 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader diff 281843 Wed Apr 22 01:14:15 MDT 2015 dteske MFC revisions 277693,278335,280382-280385,280923-280926,280931, 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader diff 281843 Wed Apr 22 01:14:15 MDT 2015 dteske MFC revisions 277693,278335,280382-280385,280923-280926,280931, 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader diff 281843 Wed Apr 22 01:14:15 MDT 2015 dteske MFC revisions 277693,278335,280382-280385,280923-280926,280931, 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader diff 281843 Wed Apr 22 01:14:15 MDT 2015 dteske MFC revisions 277693,278335,280382-280385,280923-280926,280931, 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader diff 281843 Wed Apr 22 01:14:15 MDT 2015 dteske MFC revisions 277693,278335,280382-280385,280923-280926,280931, 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader diff 254942 Mon Aug 26 23:41:48 MDT 2013 dteske Building upon SVN r254237, disable automated activation of alternate layouts and add support for default underride to $loader_version, acting as a way to name a release. Release text is not displayed for the aforementioned feature of alternate display layout (introduced in r254237); however, for all other layouts (incl. default), the release name is displayed at lower-right. See version.4th(8) for additional information and/or historical details. NOTE: Also a minor edit to version.4th(8) while we're here. diff 254942 Mon Aug 26 23:41:48 MDT 2013 dteske Building upon SVN r254237, disable automated activation of alternate layouts and add support for default underride to $loader_version, acting as a way to name a release. Release text is not displayed for the aforementioned feature of alternate display layout (introduced in r254237); however, for all other layouts (incl. default), the release name is displayed at lower-right. See version.4th(8) for additional information and/or historical details. NOTE: Also a minor edit to version.4th(8) while we're here. |
| /freebsd-10.2-release/sys/dev/dcons/ | ||
| H A D | dcons_crom.c | diff 186876 Wed Jan 07 21:34:47 MST 2009 marius Check the return values of contigmalloc(9) as well as bus_dma(9) functions and stop attaching of dcons(4) and dcons_crom(4) if they indicate failure. This fixes a panic seen on sparc64 machines with no free physical memory in the requested 32-bit region but still doesn't make dcons(4)/dcons_crom(4) these work. I think the latter can be fixed by simply specifying ~0UL as the upper limit for contigmalloc(9) and letting the bounce pages and the IOMMU respectively handle limitations of the DMA engine. I didn't want to change that without the consensus of simokawa@ though, who unfortunately didn't reply so far. MFC after: 1 week diff 186876 Wed Jan 07 21:34:47 MST 2009 marius Check the return values of contigmalloc(9) as well as bus_dma(9) functions and stop attaching of dcons(4) and dcons_crom(4) if they indicate failure. This fixes a panic seen on sparc64 machines with no free physical memory in the requested 32-bit region but still doesn't make dcons(4)/dcons_crom(4) these work. I think the latter can be fixed by simply specifying ~0UL as the upper limit for contigmalloc(9) and letting the bounce pages and the IOMMU respectively handle limitations of the DMA engine. I didn't want to change that without the consensus of simokawa@ though, who unfortunately didn't reply so far. MFC after: 1 week diff 186876 Wed Jan 07 21:34:47 MST 2009 marius Check the return values of contigmalloc(9) as well as bus_dma(9) functions and stop attaching of dcons(4) and dcons_crom(4) if they indicate failure. This fixes a panic seen on sparc64 machines with no free physical memory in the requested 32-bit region but still doesn't make dcons(4)/dcons_crom(4) these work. I think the latter can be fixed by simply specifying ~0UL as the upper limit for contigmalloc(9) and letting the bounce pages and the IOMMU respectively handle limitations of the DMA engine. I didn't want to change that without the consensus of simokawa@ though, who unfortunately didn't reply so far. MFC after: 1 week diff 186876 Wed Jan 07 21:34:47 MST 2009 marius Check the return values of contigmalloc(9) as well as bus_dma(9) functions and stop attaching of dcons(4) and dcons_crom(4) if they indicate failure. This fixes a panic seen on sparc64 machines with no free physical memory in the requested 32-bit region but still doesn't make dcons(4)/dcons_crom(4) these work. I think the latter can be fixed by simply specifying ~0UL as the upper limit for contigmalloc(9) and letting the bounce pages and the IOMMU respectively handle limitations of the DMA engine. I didn't want to change that without the consensus of simokawa@ though, who unfortunately didn't reply so far. MFC after: 1 week diff 185108 Wed Nov 19 22:19:43 MST 2008 marius Given that the buffer dcons_crom(4) exposes is used for both input and output, set BUS_DMA_COHERENT when creating the DMA map used for loading the buffer. As a side-effect this solves locking issues on sparc64 when dcons(4) calls bus_dmamap_sync(9) while in an interrupt filter, which are executed in a critical section, and iommu(4) has to use a sleep lock when taking advantage of the streaming buffer. Reported and tested by: kensmith Approved by: simokawa diff 185108 Wed Nov 19 22:19:43 MST 2008 marius Given that the buffer dcons_crom(4) exposes is used for both input and output, set BUS_DMA_COHERENT when creating the DMA map used for loading the buffer. As a side-effect this solves locking issues on sparc64 when dcons(4) calls bus_dmamap_sync(9) while in an interrupt filter, which are executed in a critical section, and iommu(4) has to use a sleep lock when taking advantage of the streaming buffer. Reported and tested by: kensmith Approved by: simokawa diff 185108 Wed Nov 19 22:19:43 MST 2008 marius Given that the buffer dcons_crom(4) exposes is used for both input and output, set BUS_DMA_COHERENT when creating the DMA map used for loading the buffer. As a side-effect this solves locking issues on sparc64 when dcons(4) calls bus_dmamap_sync(9) while in an interrupt filter, which are executed in a critical section, and iommu(4) has to use a sleep lock when taking advantage of the streaming buffer. Reported and tested by: kensmith Approved by: simokawa 121468 Fri Oct 24 15:44:10 MDT 2003 simokawa Add dumb console driver and related bits. dcons(4): very simple console and gdb port driver dcons_crom(4): FireWire attachment dconschat(8): User interface to dcons Tested with: i386, i386-PAE, and sparc64. 121468 Fri Oct 24 15:44:10 MDT 2003 simokawa Add dumb console driver and related bits. dcons(4): very simple console and gdb port driver dcons_crom(4): FireWire attachment dconschat(8): User interface to dcons Tested with: i386, i386-PAE, and sparc64. |
| /freebsd-10.2-release/sys/dev/ichsmb/ | ||
| H A D | ichsmb.c | diff 188077 Tue Feb 03 16:18:04 MST 2009 jhb - Change ichsmb(4) to follow the format of all the other smbus controllers for slave addressing by using left-adjusted slave addresses (i.e. xxxxxxx0b). - Require the low bit of the slave address to always be zero in smb(4) to help catch broken applications. - Adjust some code in the IPMI driver to not convert the slave address for SSIF to a right-adjusted address. I (or possibly ambrisko@) added this in the past to (unknowingly) work around the bug in ichsmb(4). Submitted by: Andriy Gapon <avg of icyb.net.ua> (1,2) MFC after: 1 month diff 188077 Tue Feb 03 16:18:04 MST 2009 jhb - Change ichsmb(4) to follow the format of all the other smbus controllers for slave addressing by using left-adjusted slave addresses (i.e. xxxxxxx0b). - Require the low bit of the slave address to always be zero in smb(4) to help catch broken applications. - Adjust some code in the IPMI driver to not convert the slave address for SSIF to a right-adjusted address. I (or possibly ambrisko@) added this in the past to (unknowingly) work around the bug in ichsmb(4). Submitted by: Andriy Gapon <avg of icyb.net.ua> (1,2) MFC after: 1 month diff 188077 Tue Feb 03 16:18:04 MST 2009 jhb - Change ichsmb(4) to follow the format of all the other smbus controllers for slave addressing by using left-adjusted slave addresses (i.e. xxxxxxx0b). - Require the low bit of the slave address to always be zero in smb(4) to help catch broken applications. - Adjust some code in the IPMI driver to not convert the slave address for SSIF to a right-adjusted address. I (or possibly ambrisko@) added this in the past to (unknowingly) work around the bug in ichsmb(4). Submitted by: Andriy Gapon <avg of icyb.net.ua> (1,2) MFC after: 1 month diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. diff 165951 Thu Jan 11 19:56:24 MST 2007 jhb Various updates to most of the smbus(4) drivers: - Use printf() and device_printf() instead of log() in ichsmb(4). - Create the mutex sooner during ichsmb(4) attach. - Attach the interrupt handler later during ichsmb(4) attach to avoid races. - Don't try to set PCIM_CMD_PORTEN in ichsmb(4) attach as the PCI bus driver does this already. - Add locking to alpm(4), amdpm(4), amdsmb(4), intsmb(4), nfsmb(4), and viapm(4). - Axe ALPM_SMBIO_BASE_ADDR, it's not really safe to write arbitrary values into BARs, and the PCI bus layer will allocate resources now if needed. - Merge intpm(4) and intsmb(4) into just intsmb(4). Previously, intpm(4) attached to the PCI device and created an intsmb(4) child. Now, intsmb(4) just attaches to PCI directly. - Change several intsmb functions to take a softc instead of a device_t to make things simpler. |
| /freebsd-10.2-release/sys/geom/uncompress/ | ||
| H A D | g_uncompress.c | diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. diff 266220 Fri May 16 14:41:56 MDT 2014 loos MFC r260522, r260523, r261439, r261440, r261586, r264504, r264769, r265193, r265194, r265197 r260522: Add the manual page for geom_uncompress(4). r260523: Build the geom_uncompress(4) module by default. Fix geom_uncompress(4) module loading. Don't link zlib.c (which is a module itself) directly. r261439: Remove some unnecessary code. The offsets read from the first block are overwritten a few lines bellow. r261440: Fix a logic error. Because of this inflateReset() wasn't being called and the output buffer wasn't being cleared between the inflate() calls, producing zeroed output after the first inflate() call. This fixes the read of mkuzip(8) images with geom_uncompress(4). r261586: Fix the build with DEBUG enabled. Where possible, fix style(9) issues. r264504: Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause problems in our providers, such as a KASSERT in md(4). We can initiate I/O for more than MAXPHYS bytes if we've been given a BIO for MAXPHYS bytes, the blocks from which we're reading couldn't be compressed and we had compression in preceeding blocks resulting in misalignment of the blocks we're trying to read relative to the sector. We're forced to round up the I/O length to make it an multiple of the sector size. When we detect the condition, we'll reduce the block count and perform a "short" read. In g_uzip_done() we need to consider the original I/O length and stop early if we're about to deflate a block that we didn't read. By using bio_completed in the cloned BIO and not bio_length to check for this, we automatically and gracefully handle short reads that our providers may be doing on top of the short reads we may initiate ourselves. r264769: Keep geom_uncompress(4) in line with geom_uzip(4), bring in the r264504 fix. Make sure not to start I/O bigger than MAXPHYS bytes. r265193: Some style and whitespace fixes. Reduce the difference between geom_uzip(4) and geom_uncompress(4). Now, they produce an almost clean diff(1) output. Remove a duplicated variable from g_uncompress.c and an unnecessary header from g_uzip.c. r265194: Actually the FEATURE() macro is defined on sys/sysctl.h. r265197: Fix a leak in g_uzip_taste(). After retrieve all the block offsets from the uzip image, free the last data read. |
| /freebsd-10.2-release/sys/dev/nvme/ | ||
| H A D | nvme_sysctl.c | 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> |
| /freebsd-10.2-release/sys/mips/conf/ | ||
| H A D | RT305X | diff 253779 Mon Jul 29 20:29:16 MDT 2013 obrien Decouple yarrow from random(4) device. * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow. * random(4) device doesn't really depend on rijndael-*. Yarrow, however, does. * Add random_adaptors.[ch] which is basically a store of random_adaptor's. random_adaptor is basically an adapter that plugs in to random(4). random_adaptor can only be plugged in to random(4) very early in bootup. Unplugging random_adaptor from random(4) is not supported, and is probably a bad idea anyway, due to potential loss of entropy pools. We currently have 3 random_adaptors: + yarrow + rdrand (ivy.c) + nehemeiah * Remove platform dependent logic from probe.c, and move it into corresponding registration routines of each random_adaptor provider. probe.c doesn't do anything other than picking a specific random_adaptor from a list of registered ones. * If the kernel doesn't have any random_adaptor adapters present then the creation of /dev/random is postponed until next random_adaptor is kldload'ed. * Fix randomdev_soft.c to refer to its own random_adaptor, instead of a system wide one. Submitted by: arthurmesh@gmail.com, obrien Obtained from: Juniper Networks Reviewed by: obrien diff 253779 Mon Jul 29 20:29:16 MDT 2013 obrien Decouple yarrow from random(4) device. * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow. * random(4) device doesn't really depend on rijndael-*. Yarrow, however, does. * Add random_adaptors.[ch] which is basically a store of random_adaptor's. random_adaptor is basically an adapter that plugs in to random(4). random_adaptor can only be plugged in to random(4) very early in bootup. Unplugging random_adaptor from random(4) is not supported, and is probably a bad idea anyway, due to potential loss of entropy pools. We currently have 3 random_adaptors: + yarrow + rdrand (ivy.c) + nehemeiah * Remove platform dependent logic from probe.c, and move it into corresponding registration routines of each random_adaptor provider. probe.c doesn't do anything other than picking a specific random_adaptor from a list of registered ones. * If the kernel doesn't have any random_adaptor adapters present then the creation of /dev/random is postponed until next random_adaptor is kldload'ed. * Fix randomdev_soft.c to refer to its own random_adaptor, instead of a system wide one. Submitted by: arthurmesh@gmail.com, obrien Obtained from: Juniper Networks Reviewed by: obrien diff 253779 Mon Jul 29 20:29:16 MDT 2013 obrien Decouple yarrow from random(4) device. * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow. * random(4) device doesn't really depend on rijndael-*. Yarrow, however, does. * Add random_adaptors.[ch] which is basically a store of random_adaptor's. random_adaptor is basically an adapter that plugs in to random(4). random_adaptor can only be plugged in to random(4) very early in bootup. Unplugging random_adaptor from random(4) is not supported, and is probably a bad idea anyway, due to potential loss of entropy pools. We currently have 3 random_adaptors: + yarrow + rdrand (ivy.c) + nehemeiah * Remove platform dependent logic from probe.c, and move it into corresponding registration routines of each random_adaptor provider. probe.c doesn't do anything other than picking a specific random_adaptor from a list of registered ones. * If the kernel doesn't have any random_adaptor adapters present then the creation of /dev/random is postponed until next random_adaptor is kldload'ed. * Fix randomdev_soft.c to refer to its own random_adaptor, instead of a system wide one. Submitted by: arthurmesh@gmail.com, obrien Obtained from: Juniper Networks Reviewed by: obrien diff 253779 Mon Jul 29 20:29:16 MDT 2013 obrien Decouple yarrow from random(4) device. * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow. * random(4) device doesn't really depend on rijndael-*. Yarrow, however, does. * Add random_adaptors.[ch] which is basically a store of random_adaptor's. random_adaptor is basically an adapter that plugs in to random(4). random_adaptor can only be plugged in to random(4) very early in bootup. Unplugging random_adaptor from random(4) is not supported, and is probably a bad idea anyway, due to potential loss of entropy pools. We currently have 3 random_adaptors: + yarrow + rdrand (ivy.c) + nehemeiah * Remove platform dependent logic from probe.c, and move it into corresponding registration routines of each random_adaptor provider. probe.c doesn't do anything other than picking a specific random_adaptor from a list of registered ones. * If the kernel doesn't have any random_adaptor adapters present then the creation of /dev/random is postponed until next random_adaptor is kldload'ed. * Fix randomdev_soft.c to refer to its own random_adaptor, instead of a system wide one. Submitted by: arthurmesh@gmail.com, obrien Obtained from: Juniper Networks Reviewed by: obrien diff 253779 Mon Jul 29 20:29:16 MDT 2013 obrien Decouple yarrow from random(4) device. * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow. * random(4) device doesn't really depend on rijndael-*. Yarrow, however, does. * Add random_adaptors.[ch] which is basically a store of random_adaptor's. random_adaptor is basically an adapter that plugs in to random(4). random_adaptor can only be plugged in to random(4) very early in bootup. Unplugging random_adaptor from random(4) is not supported, and is probably a bad idea anyway, due to potential loss of entropy pools. We currently have 3 random_adaptors: + yarrow + rdrand (ivy.c) + nehemeiah * Remove platform dependent logic from probe.c, and move it into corresponding registration routines of each random_adaptor provider. probe.c doesn't do anything other than picking a specific random_adaptor from a list of registered ones. * If the kernel doesn't have any random_adaptor adapters present then the creation of /dev/random is postponed until next random_adaptor is kldload'ed. * Fix randomdev_soft.c to refer to its own random_adaptor, instead of a system wide one. Submitted by: arthurmesh@gmail.com, obrien Obtained from: Juniper Networks Reviewed by: obrien diff 233271 Wed Mar 21 08:50:31 MDT 2012 ed Remove pty(4) from our kernel configurations. As of FreeBSD 8, this driver should not be used. Applications that use posix_openpt(2) and openpty(3) use the pts(4) that is built into the kernel unconditionally. If it turns out high profile depend on the pty(4) module anyway, I'd rather get those fixed. So please report any issues to me. The pty(4) module is still available as a kernel module of course, so a simple `kldload pty' can be used to run old-style pseudo-terminals. diff 233271 Wed Mar 21 08:50:31 MDT 2012 ed Remove pty(4) from our kernel configurations. As of FreeBSD 8, this driver should not be used. Applications that use posix_openpt(2) and openpty(3) use the pts(4) that is built into the kernel unconditionally. If it turns out high profile depend on the pty(4) module anyway, I'd rather get those fixed. So please report any issues to me. The pty(4) module is still available as a kernel module of course, so a simple `kldload pty' can be used to run old-style pseudo-terminals. diff 233271 Wed Mar 21 08:50:31 MDT 2012 ed Remove pty(4) from our kernel configurations. As of FreeBSD 8, this driver should not be used. Applications that use posix_openpt(2) and openpty(3) use the pts(4) that is built into the kernel unconditionally. If it turns out high profile depend on the pty(4) module anyway, I'd rather get those fixed. So please report any issues to me. The pty(4) module is still available as a kernel module of course, so a simple `kldload pty' can be used to run old-style pseudo-terminals. diff 233271 Wed Mar 21 08:50:31 MDT 2012 ed Remove pty(4) from our kernel configurations. As of FreeBSD 8, this driver should not be used. Applications that use posix_openpt(2) and openpty(3) use the pts(4) that is built into the kernel unconditionally. If it turns out high profile depend on the pty(4) module anyway, I'd rather get those fixed. So please report any issues to me. The pty(4) module is still available as a kernel module of course, so a simple `kldload pty' can be used to run old-style pseudo-terminals. |
| /freebsd-10.2-release/sys/modules/dpms/ | ||
| H A D | Makefile | diff 198251 Mon Oct 19 21:04:20 MDT 2009 jkim Rewrite x86bios and update its dependent drivers. - Do not map entire real mode memory (1MB). Instead, we map IVT/BDA and ROM area separately. Most notably, ROM area is mapped as device memory (uncacheable) as it should be. User memory is dynamically allocated and free'ed with contigmalloc(9) and contigfree(9). Remove now redundant and potentially dangerous x86bios_alloc.c. If this emulator ever grows to support non-PC hardware, we may implement it with rman(9) later. - Move all host-specific initializations from x86emu_util.c to x86bios.c and remove now unnecessary x86emu_util.c. Currently, non-PC hardware is not supported. We may use bus_space(9) later when the KPI is fixed. - Replace all bzero() calls for emulated registers with more obviously named x86bios_init_regs(). This function also initializes DS and SS properly. - Add x86bios_get_intr(). This function checks if the interrupt vector is available for the platform. It is not necessary for PC-compatible hardware but it may be needed later. ;-) - Do not try turning off monitor if DPMS does not support the state. - Allocate stable memory for VESA OEM strings instead of just holding pointers to them. They may or may not be accessible always. Fix a memory leak of video mode table while I am here. - Add (experimental) BIOS POST call for vesa(4). This function calls VGA BIOS POST code from the current VGA option ROM. Some video controllers cannot save and restore the state properly even if it is claimed to be supported. Usually the symptom is blank display after resuming from suspend state. If the video mode does not match the previous mode after restoring, we try BIOS POST and force the known good initial state. Some magic was taken from NetBSD (and it was taken from vbetool, I believe.) - Add a loader tunable for vgapci(4) to give a hint to dpms(4) and vesa(4) to identify who owns the VESA BIOS. This is very useful for multi-display adapter setup. By default, the POST video controller is automatically probed and the tunable "hw.pci.default_vgapci_unit" is set to corresponding vgapci unit number. You may override it from loader but it is very unlikely to be necessary. Unfortunately only AGP/PCI/PCI-E controllers can be matched because ISA controller does not have necessary device IDs. - Fix a long standing bug in state save/restore function. The state buffer pointer should be ES:BX, not ES:DI according to VBE 3.0. If it ever worked, that's because BX was always zero. :-) - Clean up register initializations more clearer per VBE 3.0. - Fix a lot of style issues with vesa(4). diff 198251 Mon Oct 19 21:04:20 MDT 2009 jkim Rewrite x86bios and update its dependent drivers. - Do not map entire real mode memory (1MB). Instead, we map IVT/BDA and ROM area separately. Most notably, ROM area is mapped as device memory (uncacheable) as it should be. User memory is dynamically allocated and free'ed with contigmalloc(9) and contigfree(9). Remove now redundant and potentially dangerous x86bios_alloc.c. If this emulator ever grows to support non-PC hardware, we may implement it with rman(9) later. - Move all host-specific initializations from x86emu_util.c to x86bios.c and remove now unnecessary x86emu_util.c. Currently, non-PC hardware is not supported. We may use bus_space(9) later when the KPI is fixed. - Replace all bzero() calls for emulated registers with more obviously named x86bios_init_regs(). This function also initializes DS and SS properly. - Add x86bios_get_intr(). This function checks if the interrupt vector is available for the platform. It is not necessary for PC-compatible hardware but it may be needed later. ;-) - Do not try turning off monitor if DPMS does not support the state. - Allocate stable memory for VESA OEM strings instead of just holding pointers to them. They may or may not be accessible always. Fix a memory leak of video mode table while I am here. - Add (experimental) BIOS POST call for vesa(4). This function calls VGA BIOS POST code from the current VGA option ROM. Some video controllers cannot save and restore the state properly even if it is claimed to be supported. Usually the symptom is blank display after resuming from suspend state. If the video mode does not match the previous mode after restoring, we try BIOS POST and force the known good initial state. Some magic was taken from NetBSD (and it was taken from vbetool, I believe.) - Add a loader tunable for vgapci(4) to give a hint to dpms(4) and vesa(4) to identify who owns the VESA BIOS. This is very useful for multi-display adapter setup. By default, the POST video controller is automatically probed and the tunable "hw.pci.default_vgapci_unit" is set to corresponding vgapci unit number. You may override it from loader but it is very unlikely to be necessary. Unfortunately only AGP/PCI/PCI-E controllers can be matched because ISA controller does not have necessary device IDs. - Fix a long standing bug in state save/restore function. The state buffer pointer should be ES:BX, not ES:DI according to VBE 3.0. If it ever worked, that's because BX was always zero. :-) - Clean up register initializations more clearer per VBE 3.0. - Fix a lot of style issues with vesa(4). diff 198251 Mon Oct 19 21:04:20 MDT 2009 jkim Rewrite x86bios and update its dependent drivers. - Do not map entire real mode memory (1MB). Instead, we map IVT/BDA and ROM area separately. Most notably, ROM area is mapped as device memory (uncacheable) as it should be. User memory is dynamically allocated and free'ed with contigmalloc(9) and contigfree(9). Remove now redundant and potentially dangerous x86bios_alloc.c. If this emulator ever grows to support non-PC hardware, we may implement it with rman(9) later. - Move all host-specific initializations from x86emu_util.c to x86bios.c and remove now unnecessary x86emu_util.c. Currently, non-PC hardware is not supported. We may use bus_space(9) later when the KPI is fixed. - Replace all bzero() calls for emulated registers with more obviously named x86bios_init_regs(). This function also initializes DS and SS properly. - Add x86bios_get_intr(). This function checks if the interrupt vector is available for the platform. It is not necessary for PC-compatible hardware but it may be needed later. ;-) - Do not try turning off monitor if DPMS does not support the state. - Allocate stable memory for VESA OEM strings instead of just holding pointers to them. They may or may not be accessible always. Fix a memory leak of video mode table while I am here. - Add (experimental) BIOS POST call for vesa(4). This function calls VGA BIOS POST code from the current VGA option ROM. Some video controllers cannot save and restore the state properly even if it is claimed to be supported. Usually the symptom is blank display after resuming from suspend state. If the video mode does not match the previous mode after restoring, we try BIOS POST and force the known good initial state. Some magic was taken from NetBSD (and it was taken from vbetool, I believe.) - Add a loader tunable for vgapci(4) to give a hint to dpms(4) and vesa(4) to identify who owns the VESA BIOS. This is very useful for multi-display adapter setup. By default, the POST video controller is automatically probed and the tunable "hw.pci.default_vgapci_unit" is set to corresponding vgapci unit number. You may override it from loader but it is very unlikely to be necessary. Unfortunately only AGP/PCI/PCI-E controllers can be matched because ISA controller does not have necessary device IDs. - Fix a long standing bug in state save/restore function. The state buffer pointer should be ES:BX, not ES:DI according to VBE 3.0. If it ever worked, that's because BX was always zero. :-) - Clean up register initializations more clearer per VBE 3.0. - Fix a lot of style issues with vesa(4). diff 198251 Mon Oct 19 21:04:20 MDT 2009 jkim Rewrite x86bios and update its dependent drivers. - Do not map entire real mode memory (1MB). Instead, we map IVT/BDA and ROM area separately. Most notably, ROM area is mapped as device memory (uncacheable) as it should be. User memory is dynamically allocated and free'ed with contigmalloc(9) and contigfree(9). Remove now redundant and potentially dangerous x86bios_alloc.c. If this emulator ever grows to support non-PC hardware, we may implement it with rman(9) later. - Move all host-specific initializations from x86emu_util.c to x86bios.c and remove now unnecessary x86emu_util.c. Currently, non-PC hardware is not supported. We may use bus_space(9) later when the KPI is fixed. - Replace all bzero() calls for emulated registers with more obviously named x86bios_init_regs(). This function also initializes DS and SS properly. - Add x86bios_get_intr(). This function checks if the interrupt vector is available for the platform. It is not necessary for PC-compatible hardware but it may be needed later. ;-) - Do not try turning off monitor if DPMS does not support the state. - Allocate stable memory for VESA OEM strings instead of just holding pointers to them. They may or may not be accessible always. Fix a memory leak of video mode table while I am here. - Add (experimental) BIOS POST call for vesa(4). This function calls VGA BIOS POST code from the current VGA option ROM. Some video controllers cannot save and restore the state properly even if it is claimed to be supported. Usually the symptom is blank display after resuming from suspend state. If the video mode does not match the previous mode after restoring, we try BIOS POST and force the known good initial state. Some magic was taken from NetBSD (and it was taken from vbetool, I believe.) - Add a loader tunable for vgapci(4) to give a hint to dpms(4) and vesa(4) to identify who owns the VESA BIOS. This is very useful for multi-display adapter setup. By default, the POST video controller is automatically probed and the tunable "hw.pci.default_vgapci_unit" is set to corresponding vgapci unit number. You may override it from loader but it is very unlikely to be necessary. Unfortunately only AGP/PCI/PCI-E controllers can be matched because ISA controller does not have necessary device IDs. - Fix a long standing bug in state save/restore function. The state buffer pointer should be ES:BX, not ES:DI according to VBE 3.0. If it ever worked, that's because BX was always zero. :-) - Clean up register initializations more clearer per VBE 3.0. - Fix a lot of style issues with vesa(4). diff 198251 Mon Oct 19 21:04:20 MDT 2009 jkim Rewrite x86bios and update its dependent drivers. - Do not map entire real mode memory (1MB). Instead, we map IVT/BDA and ROM area separately. Most notably, ROM area is mapped as device memory (uncacheable) as it should be. User memory is dynamically allocated and free'ed with contigmalloc(9) and contigfree(9). Remove now redundant and potentially dangerous x86bios_alloc.c. If this emulator ever grows to support non-PC hardware, we may implement it with rman(9) later. - Move all host-specific initializations from x86emu_util.c to x86bios.c and remove now unnecessary x86emu_util.c. Currently, non-PC hardware is not supported. We may use bus_space(9) later when the KPI is fixed. - Replace all bzero() calls for emulated registers with more obviously named x86bios_init_regs(). This function also initializes DS and SS properly. - Add x86bios_get_intr(). This function checks if the interrupt vector is available for the platform. It is not necessary for PC-compatible hardware but it may be needed later. ;-) - Do not try turning off monitor if DPMS does not support the state. - Allocate stable memory for VESA OEM strings instead of just holding pointers to them. They may or may not be accessible always. Fix a memory leak of video mode table while I am here. - Add (experimental) BIOS POST call for vesa(4). This function calls VGA BIOS POST code from the current VGA option ROM. Some video controllers cannot save and restore the state properly even if it is claimed to be supported. Usually the symptom is blank display after resuming from suspend state. If the video mode does not match the previous mode after restoring, we try BIOS POST and force the known good initial state. Some magic was taken from NetBSD (and it was taken from vbetool, I believe.) - Add a loader tunable for vgapci(4) to give a hint to dpms(4) and vesa(4) to identify who owns the VESA BIOS. This is very useful for multi-display adapter setup. By default, the POST video controller is automatically probed and the tunable "hw.pci.default_vgapci_unit" is set to corresponding vgapci unit number. You may override it from loader but it is very unlikely to be necessary. Unfortunately only AGP/PCI/PCI-E controllers can be matched because ISA controller does not have necessary device IDs. - Fix a long standing bug in state save/restore function. The state buffer pointer should be ES:BX, not ES:DI according to VBE 3.0. If it ever worked, that's because BX was always zero. :-) - Clean up register initializations more clearer per VBE 3.0. - Fix a lot of style issues with vesa(4). diff 197025 Wed Sep 09 10:03:35 MDT 2009 delphij - Teach vesa(4) and dpms(4) about x86emu. [1] - Add vesa kernel options for amd64. - Connect libvgl library and splash kernel modules to amd64 build. - Connect manual page dpms(4) to amd64 build. - Remove old vesa/dpms files. Submitted by: paradox <ddkprog yahoo com> [1], swell k at gmail.com (with some minor tweaks) diff 197025 Wed Sep 09 10:03:35 MDT 2009 delphij - Teach vesa(4) and dpms(4) about x86emu. [1] - Add vesa kernel options for amd64. - Connect libvgl library and splash kernel modules to amd64 build. - Connect manual page dpms(4) to amd64 build. - Remove old vesa/dpms files. Submitted by: paradox <ddkprog yahoo com> [1], swell k at gmail.com (with some minor tweaks) diff 197025 Wed Sep 09 10:03:35 MDT 2009 delphij - Teach vesa(4) and dpms(4) about x86emu. [1] - Add vesa kernel options for amd64. - Connect libvgl library and splash kernel modules to amd64 build. - Connect manual page dpms(4) to amd64 build. - Remove old vesa/dpms files. Submitted by: paradox <ddkprog yahoo com> [1], swell k at gmail.com (with some minor tweaks) 182081 Sat Aug 23 21:01:18 MDT 2008 jhb Add a very simple dpms(4) driver that uses the VESA BIOS DPMS calls to turn off the external display during suspend and restore it to its original state on resume. MFC after: 2 weeks |
| /freebsd-10.2-release/sys/modules/if_gif/ | ||
| H A D | Makefile | diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. diff 284066 Sat Jun 06 12:59:17 MDT 2015 ae MFC r274246: Overhaul if_gre(4). Split it into two modules: if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * make implementation conform to the RFC 2784 and partially to RFC 2890; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove support of cached routes. This fixes problem, when gre(4) doesn't work at system startup. But this also removes support for having tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, that doesn't used in FreeBSD. Use our standard ioctls for tunnels. me(4): * implementation conform to RFC 2004; * use if_transmit; * use the same locking model as gre(4); PR: 164475 MFC r274289 (by bz): gcc requires variables to be initialised in two places. One of them is correctly used only under the same conditional though. For module builds properly check if the kernel supports INET or INET6, as otherwise various mips kernels without IPv6 support would fail to build. MFC r274964: Add ip_gre.h to ObsoleteFiles.inc. 79106 Mon Jul 02 21:02:09 MDT 2001 brooks gif(4) and stf(4) modernization: - Remove gif dependencies from stf. - Make gif and stf into modules - Make gif cloneable. PR: kern/27983 Reviewed by: ru, ume Obtained from: NetBSD MFC after: 1 week 79106 Mon Jul 02 21:02:09 MDT 2001 brooks gif(4) and stf(4) modernization: - Remove gif dependencies from stf. - Make gif and stf into modules - Make gif cloneable. PR: kern/27983 Reviewed by: ru, ume Obtained from: NetBSD MFC after: 1 week |
| /freebsd-10.2-release/sys/modules/mii/ | ||
| H A D | Makefile | diff 232016 Thu Feb 23 01:33:08 MST 2012 yongari Connect smcphy(4) to mii module build. diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) diff 226995 Tue Nov 01 16:22:50 MDT 2011 marius - Import the common MII bitbang'ing code from NetBSD and convert drivers to take advantage of it instead of duplicating it. This reduces the size of the i386 GENERIC kernel by about 4k. The only potential in-tree user left unconverted is xe(4), which generally should be changed to use miibus(4) instead of implementing PHY handling on its own, as otherwise it makes not much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just for the MII bitbang'ing code. The common MII bitbang'ing code also is useful in the embedded space for using GPIO pins to implement MII access. - Based on lessons learnt with dc(4) (see r185750), add bus barriers to the MII bitbang read and write functions of the other drivers converted in order to ensure the intended ordering. Given that register access via an index register as well as register bank/window switching is subject to the same problem, also add bus barriers to the respective functions of smc(4), tl(4) and xl(4). - Sprinkle some const. Thanks to the following testers: Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4)) Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4). Reviewed by: yongari (subset of drivers) Obtained from: NetBSD (partially) |
| /freebsd-10.2-release/sys/modules/uart/ | ||
| H A D | Makefile | diff 249636 Fri Apr 19 06:02:32 MDT 2013 jhibbits Fix the uart(4) module build. Without uart_dev_lpc the module cannot be loaded. diff 157301 Thu Mar 30 18:39:24 MST 2006 marcel o Add scc(4) to the build. o Add the scc(4) manpage to the build. o Update the uart(4) manpage to account for scc(4). o Update the uart(4) module build to include support for scc(4). diff 157301 Thu Mar 30 18:39:24 MST 2006 marcel o Add scc(4) to the build. o Add the scc(4) manpage to the build. o Update the uart(4) manpage to account for scc(4). o Update the uart(4) module build to include support for scc(4). diff 157301 Thu Mar 30 18:39:24 MST 2006 marcel o Add scc(4) to the build. o Add the scc(4) manpage to the build. o Update the uart(4) manpage to account for scc(4). o Update the uart(4) module build to include support for scc(4). diff 157301 Thu Mar 30 18:39:24 MST 2006 marcel o Add scc(4) to the build. o Add the scc(4) manpage to the build. o Update the uart(4) manpage to account for scc(4). o Update the uart(4) module build to include support for scc(4). diff 157301 Thu Mar 30 18:39:24 MST 2006 marcel o Add scc(4) to the build. o Add the scc(4) manpage to the build. o Update the uart(4) manpage to account for scc(4). o Update the uart(4) module build to include support for scc(4). diff 157301 Thu Mar 30 18:39:24 MST 2006 marcel o Add scc(4) to the build. o Add the scc(4) manpage to the build. o Update the uart(4) manpage to account for scc(4). o Update the uart(4) module build to include support for scc(4). diff 155966 Fri Feb 24 01:49:36 MST 2006 marcel Remove dev/uart/uart_if.m from the default MFILES (in kmod.mk) and instead define MFILES appropriately for the uart(4) module build. diff 137819 Wed Nov 17 14:44:10 MST 2004 marius o sparc64/isa/isa.c: - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2] diff 137819 Wed Nov 17 14:44:10 MST 2004 marius o sparc64/isa/isa.c: - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2] diff 137819 Wed Nov 17 14:44:10 MST 2004 marius o sparc64/isa/isa.c: - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2] diff 137819 Wed Nov 17 14:44:10 MST 2004 marius o sparc64/isa/isa.c: - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2] diff 137819 Wed Nov 17 14:44:10 MST 2004 marius o sparc64/isa/isa.c: - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2] diff 137819 Wed Nov 17 14:44:10 MST 2004 marius o sparc64/isa/isa.c: - The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2] |
| /freebsd-10.2-release/sys/x86/iommu/ | ||
| H A D | intel_gas.c | 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month |
| H A D | intel_reg.h | 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month 257251 Mon Oct 28 13:46:37 MDT 2013 kib Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month |
| /freebsd-10.2-release/sys/powerpc/psim/ | ||
| H A D | ata_iobus.c | diff 249213 Sat Apr 06 19:23:37 MDT 2013 marius - With the demise of !ATA_CAM, ATA_STATIC_ID is the only ata(4) related option left but actually consumed by ada(4), so move it to opt_ada.h and get rid of opt_ata.h. - Fix stand-alone build of atacore(4) by adding opt_cam.h. - Use __FBSDID. - Use DEVMETHOD_END. - Use NULL instead of 0 for pointers. diff 249213 Sat Apr 06 19:23:37 MDT 2013 marius - With the demise of !ATA_CAM, ATA_STATIC_ID is the only ata(4) related option left but actually consumed by ada(4), so move it to opt_ada.h and get rid of opt_ata.h. - Fix stand-alone build of atacore(4) by adding opt_cam.h. - Use __FBSDID. - Use DEVMETHOD_END. - Use NULL instead of 0 for pointers. diff 249213 Sat Apr 06 19:23:37 MDT 2013 marius - With the demise of !ATA_CAM, ATA_STATIC_ID is the only ata(4) related option left but actually consumed by ada(4), so move it to opt_ada.h and get rid of opt_ata.h. - Fix stand-alone build of atacore(4) by adding opt_cam.h. - Use __FBSDID. - Use DEVMETHOD_END. - Use NULL instead of 0 for pointers. diff 200171 Sun Dec 06 00:17:22 MST 2009 mav MFp4: Introduce ATA_CAM kernel option, turning ata(4) controller drivers into cam(4) interface modules. When enabled, this options deprecates all ata(4) peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers (ada, cd, ...) and interfaces to be natively used instead. As side effect of this, ata(4) mode setting code was completely rewritten to make controller API more strict and permit above change. While doing this, SATA revision was separated from PATA mode. It allows DMA-incapable SATA devices to operate and makes hw.ata.atapi_dma tunable work again. Also allow ata(4) controller drivers (except some specific or broken ones) to handle larger data transfers. Previous constraint of 64K was artificial and is not really required by PCI ATA BM specification or hardware. Submitted by: nwitehorn (powerpc part) diff 200171 Sun Dec 06 00:17:22 MST 2009 mav MFp4: Introduce ATA_CAM kernel option, turning ata(4) controller drivers into cam(4) interface modules. When enabled, this options deprecates all ata(4) peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers (ada, cd, ...) and interfaces to be natively used instead. As side effect of this, ata(4) mode setting code was completely rewritten to make controller API more strict and permit above change. While doing this, SATA revision was separated from PATA mode. It allows DMA-incapable SATA devices to operate and makes hw.ata.atapi_dma tunable work again. Also allow ata(4) controller drivers (except some specific or broken ones) to handle larger data transfers. Previous constraint of 64K was artificial and is not really required by PCI ATA BM specification or hardware. Submitted by: nwitehorn (powerpc part) diff 200171 Sun Dec 06 00:17:22 MST 2009 mav MFp4: Introduce ATA_CAM kernel option, turning ata(4) controller drivers into cam(4) interface modules. When enabled, this options deprecates all ata(4) peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers (ada, cd, ...) and interfaces to be natively used instead. As side effect of this, ata(4) mode setting code was completely rewritten to make controller API more strict and permit above change. While doing this, SATA revision was separated from PATA mode. It allows DMA-incapable SATA devices to operate and makes hw.ata.atapi_dma tunable work again. Also allow ata(4) controller drivers (except some specific or broken ones) to handle larger data transfers. Previous constraint of 64K was artificial and is not really required by PCI ATA BM specification or hardware. Submitted by: nwitehorn (powerpc part) diff 200171 Sun Dec 06 00:17:22 MST 2009 mav MFp4: Introduce ATA_CAM kernel option, turning ata(4) controller drivers into cam(4) interface modules. When enabled, this options deprecates all ata(4) peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers (ada, cd, ...) and interfaces to be natively used instead. As side effect of this, ata(4) mode setting code was completely rewritten to make controller API more strict and permit above change. While doing this, SATA revision was separated from PATA mode. It allows DMA-incapable SATA devices to operate and makes hw.ata.atapi_dma tunable work again. Also allow ata(4) controller drivers (except some specific or broken ones) to handle larger data transfers. Previous constraint of 64K was artificial and is not really required by PCI ATA BM specification or hardware. Submitted by: nwitehorn (powerpc part) diff 200171 Sun Dec 06 00:17:22 MST 2009 mav MFp4: Introduce ATA_CAM kernel option, turning ata(4) controller drivers into cam(4) interface modules. When enabled, this options deprecates all ata(4) peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers (ada, cd, ...) and interfaces to be natively used instead. As side effect of this, ata(4) mode setting code was completely rewritten to make controller API more strict and permit above change. While doing this, SATA revision was separated from PATA mode. It allows DMA-incapable SATA devices to operate and makes hw.ata.atapi_dma tunable work again. Also allow ata(4) controller drivers (except some specific or broken ones) to handle larger data transfers. Previous constraint of 64K was artificial and is not really required by PCI ATA BM specification or hardware. Submitted by: nwitehorn (powerpc part) diff 200171 Sun Dec 06 00:17:22 MST 2009 mav MFp4: Introduce ATA_CAM kernel option, turning ata(4) controller drivers into cam(4) interface modules. When enabled, this options deprecates all ata(4) peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers (ada, cd, ...) and interfaces to be natively used instead. As side effect of this, ata(4) mode setting code was completely rewritten to make controller API more strict and permit above change. While doing this, SATA revision was separated from PATA mode. It allows DMA-incapable SATA devices to operate and makes hw.ata.atapi_dma tunable work again. Also allow ata(4) controller drivers (except some specific or broken ones) to handle larger data transfers. Previous constraint of 64K was artificial and is not really required by PCI ATA BM specification or hardware. Submitted by: nwitehorn (powerpc part) |
| /freebsd-10.2-release/sys/dev/ppbus/ | ||
| H A D | ppbconf.h | diff 188093 Tue Feb 03 20:04:42 MST 2009 jhb Trim what we expose to userland in <dev/ppbus/ppbconf.h> to just the constants used for the ppi(4) ioctls for bits in the control and status registers. Reviewed by: db diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( |
| /freebsd-10.2-release/sys/dev/le/ | ||
| H A D | if_le_pci.c | diff 263687 Mon Mar 24 13:52:34 MDT 2014 emaste MFC r263289: Update NetBSD Foundation copyrights to 2-clause BSD The NetBSD Foundation states "Third parties are encouraged to change the license on any files which have a 4-clause license contributed to the NetBSD Foundation to a 2-clause license." This change removes clauses 3 and 4 from copyright / license blocks that list The NetBSD Foundation as the only copyright holder. Sponsored by: The FreeBSD Foundation diff 263687 Mon Mar 24 13:52:34 MDT 2014 emaste MFC r263289: Update NetBSD Foundation copyrights to 2-clause BSD The NetBSD Foundation states "Third parties are encouraged to change the license on any files which have a 4-clause license contributed to the NetBSD Foundation to a 2-clause license." This change removes clauses 3 and 4 from copyright / license blocks that list The NetBSD Foundation as the only copyright holder. Sponsored by: The FreeBSD Foundation diff 183337 Wed Sep 24 21:31:11 MDT 2008 marius - Use bus_{read,write}_*(9) instead of bus_space_{read,write}_*(9) etc and take advantage of rman_get_rid(9) in order to save some softc members. - Provide and consume module dependency information for lebuffer(4). diff 166138 Sat Jan 20 09:57:09 MST 2007 marius Use bus_get_dma_tag() to obtain the parent DMA tag so le(4) works on platforms requiring this. diff 158663 Tue May 16 21:04:01 MDT 2006 marius - Revert if_le_pci.c rev. 1.2; although lnc(4) is now gone, le_pci_probe() still should return BUS_PROBE_LOW_PRIORITY instead of BUS_PROBE_DEFAULT in order to give pcn(4) a chance to attach in case it probes after le(4). - Rearrange the code related to RX interrupt handling so that ownership of RX descriptors is immediately returned to the NIC after we have copied the data of the hardware, allowing the NIC to already reuse the descriptor while we are processing the data in ifp->if_input(). This results in a small but measurable increase in RX throughput. As a side-effect, this moves the workaround for the LANCE revision C bug to am7900.c (still off by default as I doubt we will actually encounter such an old chip in a machine running FreeBSD) and the workaround for the bug in the VMware PCnet-PCI emulation to am79000.c, which is now also only compiled on i386 (resulting in a small increase in RX throughput on the other platforms). - Change the RX interrupt handlers so that the descriptor error bits are only check once in case there was no error instead of twice (inspired by the NetBSD pcn(4), which additionally predicts the error branch as false). - Fix the debugging output of the RX and TX interrupt handlers; while looping through the descriptors print info about the currently processed one instead of always the previously last used one; remove pointless printing of info about the RX descriptor bits after their values were reset. - Create the DMA tags used to allocate the memory for the init block, descriptors and packet buffers with the alignment the respective NIC actually requires rather than using PAGE_SIZE unconditionally. This might as well fix the alignment of the memory as it seems we do not inherit the alignment constraint from the parent DMA tag. - For the PCI variants double the number of RX descriptors and buffers from 8 to 16 as this minimizes the number of RX overflows im seeing with one NIC-mainboard combination. Nevertheless move reporting of overflows under debugging as they seem unavoidable with some crappy hardware. - Set the software style of the PCI variants to ILACC rather than PCnet-PCI as the former is was am79000.c actually implements. Should not make a difference for this driver though. - Fix the driver name part in the MODULE_DEPEND of the PCI front-end for ether. - Use different device descriptions for PCnet-Home and PCnet-PCI. - Fix some 0/NULL confusion in lance_get(). - Use bus_addr_t for sc_addr and bus_size_t for sc_memsize as these are more appropriate than u_long for these. - Remove the unused LE_DRIVER_NAME macro. - Add a comment describing why we are taking the LE_HTOLE* etc approach instead of using byteorder(9) functions directly. - Improve some comments and fix some wording. MFC after: 2 weeks diff 158663 Tue May 16 21:04:01 MDT 2006 marius - Revert if_le_pci.c rev. 1.2; although lnc(4) is now gone, le_pci_probe() still should return BUS_PROBE_LOW_PRIORITY instead of BUS_PROBE_DEFAULT in order to give pcn(4) a chance to attach in case it probes after le(4). - Rearrange the code related to RX interrupt handling so that ownership of RX descriptors is immediately returned to the NIC after we have copied the data of the hardware, allowing the NIC to already reuse the descriptor while we are processing the data in ifp->if_input(). This results in a small but measurable increase in RX throughput. As a side-effect, this moves the workaround for the LANCE revision C bug to am7900.c (still off by default as I doubt we will actually encounter such an old chip in a machine running FreeBSD) and the workaround for the bug in the VMware PCnet-PCI emulation to am79000.c, which is now also only compiled on i386 (resulting in a small increase in RX throughput on the other platforms). - Change the RX interrupt handlers so that the descriptor error bits are only check once in case there was no error instead of twice (inspired by the NetBSD pcn(4), which additionally predicts the error branch as false). - Fix the debugging output of the RX and TX interrupt handlers; while looping through the descriptors print info about the currently processed one instead of always the previously last used one; remove pointless printing of info about the RX descriptor bits after their values were reset. - Create the DMA tags used to allocate the memory for the init block, descriptors and packet buffers with the alignment the respective NIC actually requires rather than using PAGE_SIZE unconditionally. This might as well fix the alignment of the memory as it seems we do not inherit the alignment constraint from the parent DMA tag. - For the PCI variants double the number of RX descriptors and buffers from 8 to 16 as this minimizes the number of RX overflows im seeing with one NIC-mainboard combination. Nevertheless move reporting of overflows under debugging as they seem unavoidable with some crappy hardware. - Set the software style of the PCI variants to ILACC rather than PCnet-PCI as the former is was am79000.c actually implements. Should not make a difference for this driver though. - Fix the driver name part in the MODULE_DEPEND of the PCI front-end for ether. - Use different device descriptions for PCnet-Home and PCnet-PCI. - Fix some 0/NULL confusion in lance_get(). - Use bus_addr_t for sc_addr and bus_size_t for sc_memsize as these are more appropriate than u_long for these. - Remove the unused LE_DRIVER_NAME macro. - Add a comment describing why we are taking the LE_HTOLE* etc approach instead of using byteorder(9) functions directly. - Improve some comments and fix some wording. MFC after: 2 weeks diff 158663 Tue May 16 21:04:01 MDT 2006 marius - Revert if_le_pci.c rev. 1.2; although lnc(4) is now gone, le_pci_probe() still should return BUS_PROBE_LOW_PRIORITY instead of BUS_PROBE_DEFAULT in order to give pcn(4) a chance to attach in case it probes after le(4). - Rearrange the code related to RX interrupt handling so that ownership of RX descriptors is immediately returned to the NIC after we have copied the data of the hardware, allowing the NIC to already reuse the descriptor while we are processing the data in ifp->if_input(). This results in a small but measurable increase in RX throughput. As a side-effect, this moves the workaround for the LANCE revision C bug to am7900.c (still off by default as I doubt we will actually encounter such an old chip in a machine running FreeBSD) and the workaround for the bug in the VMware PCnet-PCI emulation to am79000.c, which is now also only compiled on i386 (resulting in a small increase in RX throughput on the other platforms). - Change the RX interrupt handlers so that the descriptor error bits are only check once in case there was no error instead of twice (inspired by the NetBSD pcn(4), which additionally predicts the error branch as false). - Fix the debugging output of the RX and TX interrupt handlers; while looping through the descriptors print info about the currently processed one instead of always the previously last used one; remove pointless printing of info about the RX descriptor bits after their values were reset. - Create the DMA tags used to allocate the memory for the init block, descriptors and packet buffers with the alignment the respective NIC actually requires rather than using PAGE_SIZE unconditionally. This might as well fix the alignment of the memory as it seems we do not inherit the alignment constraint from the parent DMA tag. - For the PCI variants double the number of RX descriptors and buffers from 8 to 16 as this minimizes the number of RX overflows im seeing with one NIC-mainboard combination. Nevertheless move reporting of overflows under debugging as they seem unavoidable with some crappy hardware. - Set the software style of the PCI variants to ILACC rather than PCnet-PCI as the former is was am79000.c actually implements. Should not make a difference for this driver though. - Fix the driver name part in the MODULE_DEPEND of the PCI front-end for ether. - Use different device descriptions for PCnet-Home and PCnet-PCI. - Fix some 0/NULL confusion in lance_get(). - Use bus_addr_t for sc_addr and bus_size_t for sc_memsize as these are more appropriate than u_long for these. - Remove the unused LE_DRIVER_NAME macro. - Add a comment describing why we are taking the LE_HTOLE* etc approach instead of using byteorder(9) functions directly. - Improve some comments and fix some wording. MFC after: 2 weeks diff 158663 Tue May 16 21:04:01 MDT 2006 marius - Revert if_le_pci.c rev. 1.2; although lnc(4) is now gone, le_pci_probe() still should return BUS_PROBE_LOW_PRIORITY instead of BUS_PROBE_DEFAULT in order to give pcn(4) a chance to attach in case it probes after le(4). - Rearrange the code related to RX interrupt handling so that ownership of RX descriptors is immediately returned to the NIC after we have copied the data of the hardware, allowing the NIC to already reuse the descriptor while we are processing the data in ifp->if_input(). This results in a small but measurable increase in RX throughput. As a side-effect, this moves the workaround for the LANCE revision C bug to am7900.c (still off by default as I doubt we will actually encounter such an old chip in a machine running FreeBSD) and the workaround for the bug in the VMware PCnet-PCI emulation to am79000.c, which is now also only compiled on i386 (resulting in a small increase in RX throughput on the other platforms). - Change the RX interrupt handlers so that the descriptor error bits are only check once in case there was no error instead of twice (inspired by the NetBSD pcn(4), which additionally predicts the error branch as false). - Fix the debugging output of the RX and TX interrupt handlers; while looping through the descriptors print info about the currently processed one instead of always the previously last used one; remove pointless printing of info about the RX descriptor bits after their values were reset. - Create the DMA tags used to allocate the memory for the init block, descriptors and packet buffers with the alignment the respective NIC actually requires rather than using PAGE_SIZE unconditionally. This might as well fix the alignment of the memory as it seems we do not inherit the alignment constraint from the parent DMA tag. - For the PCI variants double the number of RX descriptors and buffers from 8 to 16 as this minimizes the number of RX overflows im seeing with one NIC-mainboard combination. Nevertheless move reporting of overflows under debugging as they seem unavoidable with some crappy hardware. - Set the software style of the PCI variants to ILACC rather than PCnet-PCI as the former is was am79000.c actually implements. Should not make a difference for this driver though. - Fix the driver name part in the MODULE_DEPEND of the PCI front-end for ether. - Use different device descriptions for PCnet-Home and PCnet-PCI. - Fix some 0/NULL confusion in lance_get(). - Use bus_addr_t for sc_addr and bus_size_t for sc_memsize as these are more appropriate than u_long for these. - Remove the unused LE_DRIVER_NAME macro. - Add a comment describing why we are taking the LE_HTOLE* etc approach instead of using byteorder(9) functions directly. - Improve some comments and fix some wording. MFC after: 2 weeks diff 158647 Tue May 16 12:15:39 MDT 2006 ru Kill more references to lnc(4). Submitted by: grep(1) 155093 Tue Jan 31 14:48:58 MST 2006 marius Add le(4), a driver for AMD Am7900 LANCE and Am79C9xx PCnet NICs ported from NetBSD. This driver actually can replace lnc(4). Advantages over lnc(4) are: - Cleaner and more flexible regarding MD needs. - Endian-clean and MPSAFE. - Supports ALTQ, VLAN_MTU, ifmedia. - Uses 32bit DMA for the PCI variants. This commit includes front-ends for the dma(4) pseudo-bus found on SBus- based sparc64 machines (thus supports the on-board LANCE in Sun Ultra 1) and PCI. In order to actually replace lnc(4), the front-ends for ISA and the PC98 CBUS would have to be added but for which I don't have hardware to test. Reviewed and some improvements by: yongari Tested on: i386, sparc64 155093 Tue Jan 31 14:48:58 MST 2006 marius Add le(4), a driver for AMD Am7900 LANCE and Am79C9xx PCnet NICs ported from NetBSD. This driver actually can replace lnc(4). Advantages over lnc(4) are: - Cleaner and more flexible regarding MD needs. - Endian-clean and MPSAFE. - Supports ALTQ, VLAN_MTU, ifmedia. - Uses 32bit DMA for the PCI variants. This commit includes front-ends for the dma(4) pseudo-bus found on SBus- based sparc64 machines (thus supports the on-board LANCE in Sun Ultra 1) and PCI. In order to actually replace lnc(4), the front-ends for ISA and the PC98 CBUS would have to be added but for which I don't have hardware to test. Reviewed and some improvements by: yongari Tested on: i386, sparc64 155093 Tue Jan 31 14:48:58 MST 2006 marius Add le(4), a driver for AMD Am7900 LANCE and Am79C9xx PCnet NICs ported from NetBSD. This driver actually can replace lnc(4). Advantages over lnc(4) are: - Cleaner and more flexible regarding MD needs. - Endian-clean and MPSAFE. - Supports ALTQ, VLAN_MTU, ifmedia. - Uses 32bit DMA for the PCI variants. This commit includes front-ends for the dma(4) pseudo-bus found on SBus- based sparc64 machines (thus supports the on-board LANCE in Sun Ultra 1) and PCI. In order to actually replace lnc(4), the front-ends for ISA and the PC98 CBUS would have to be added but for which I don't have hardware to test. Reviewed and some improvements by: yongari Tested on: i386, sparc64 155093 Tue Jan 31 14:48:58 MST 2006 marius Add le(4), a driver for AMD Am7900 LANCE and Am79C9xx PCnet NICs ported from NetBSD. This driver actually can replace lnc(4). Advantages over lnc(4) are: - Cleaner and more flexible regarding MD needs. - Endian-clean and MPSAFE. - Supports ALTQ, VLAN_MTU, ifmedia. - Uses 32bit DMA for the PCI variants. This commit includes front-ends for the dma(4) pseudo-bus found on SBus- based sparc64 machines (thus supports the on-board LANCE in Sun Ultra 1) and PCI. In order to actually replace lnc(4), the front-ends for ISA and the PC98 CBUS would have to be added but for which I don't have hardware to test. Reviewed and some improvements by: yongari Tested on: i386, sparc64 155093 Tue Jan 31 14:48:58 MST 2006 marius Add le(4), a driver for AMD Am7900 LANCE and Am79C9xx PCnet NICs ported from NetBSD. This driver actually can replace lnc(4). Advantages over lnc(4) are: - Cleaner and more flexible regarding MD needs. - Endian-clean and MPSAFE. - Supports ALTQ, VLAN_MTU, ifmedia. - Uses 32bit DMA for the PCI variants. This commit includes front-ends for the dma(4) pseudo-bus found on SBus- based sparc64 machines (thus supports the on-board LANCE in Sun Ultra 1) and PCI. In order to actually replace lnc(4), the front-ends for ISA and the PC98 CBUS would have to be added but for which I don't have hardware to test. Reviewed and some improvements by: yongari Tested on: i386, sparc64 |
Completed in 250 milliseconds