Searched hist:4 (Results 201 - 225 of 14306) sorted by relevance
/freebsd-9.3-release/sbin/mdconfig/ | ||
H A D | Makefile | diff 157160 Sun Mar 26 21:21:11 MST 2006 wkoszek Teach md(4) and mdconfig(8) how to understand XML. Right now there won't be a problem with listing large number of md(4) devices. Either 'list' or 'query' mode uses XML. Additionally, new functionality was introduced. It's possible to pass multiple devices to -u: # ./mdconfig -l -u md0,md1 Approved by: cognet (mentor) diff 157160 Sun Mar 26 21:21:11 MST 2006 wkoszek Teach md(4) and mdconfig(8) how to understand XML. Right now there won't be a problem with listing large number of md(4) devices. Either 'list' or 'query' mode uses XML. Additionally, new functionality was introduced. It's possible to pass multiple devices to -u: # ./mdconfig -l -u md0,md1 Approved by: cognet (mentor) diff 135340 Thu Sep 16 19:32:13 MDT 2004 pjd - Make md(4) 64-bit clean. After this change it should be possible to use very big md(4) devices. - Clean up and simplify the code a bit. - Use humanize_number(3) to print size of md(4) devices. - Add 't' suffix which stands for terabyte. - Make '-S' to really work with all types of devices. - Other minor changes. diff 135340 Thu Sep 16 19:32:13 MDT 2004 pjd - Make md(4) 64-bit clean. After this change it should be possible to use very big md(4) devices. - Clean up and simplify the code a bit. - Use humanize_number(3) to print size of md(4) devices. - Add 't' suffix which stands for terabyte. - Make '-S' to really work with all types of devices. - Other minor changes. diff 135340 Thu Sep 16 19:32:13 MDT 2004 pjd - Make md(4) 64-bit clean. After this change it should be possible to use very big md(4) devices. - Clean up and simplify the code a bit. - Use humanize_number(3) to print size of md(4) devices. - Add 't' suffix which stands for terabyte. - Make '-S' to really work with all types of devices. - Other minor changes. diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. diff 74047 Fri Mar 09 18:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. 70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. 70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. 70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. 70448 Thu Dec 28 18:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. |
/freebsd-9.3-release/sys/dev/nvme/ | ||
H A D | nvme_ns_cmd.c | diff 253630 Wed Jul 24 20:50:51 MDT 2013 jimharris MFC r253474: Fix nvme(4) and nvd(4) to support non 512-byte sector sizes. Recent testing with QEMU that has variable sector size support for NVMe uncovered some of these issues. Chatham prototype boards supported only 512 byte sectors. Approved by: re (kib) Sponsored by: Intel diff 253630 Wed Jul 24 20:50:51 MDT 2013 jimharris MFC r253474: Fix nvme(4) and nvd(4) to support non 512-byte sector sizes. Recent testing with QEMU that has variable sector size support for NVMe uncovered some of these issues. Chatham prototype boards supported only 512 byte sectors. Approved by: re (kib) Sponsored by: Intel diff 252221 Tue Jun 25 21:32:37 MDT 2013 jimharris MFC r240616, r240619, r240620: Merge initial NVM Express (NVMe) commits to stable/9. This only pulls the nvme(4), nvd(4) and nvmecontrol(8) code into stable/9. A follow-up commit will link it into the build and merge all of the additional commits made for NVMe over the last few months. Sponsored by: Intel diff 252221 Tue Jun 25 21:32:37 MDT 2013 jimharris MFC r240616, r240619, r240620: Merge initial NVM Express (NVMe) commits to stable/9. This only pulls the nvme(4), nvd(4) and nvmecontrol(8) code into stable/9. A follow-up commit will link it into the build and merge all of the additional commits made for NVMe over the last few months. Sponsored by: Intel 240616 Mon Sep 17 17: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 17: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 17: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 17: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 17: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 17: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 17: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 17: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 17: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-9.3-release/share/man/man4/ | ||
H A D | bce.4 | diff 236722 Thu Jun 07 17:26:21 MDT 2012 sbruno MFC r236412,236418,236420,236591,236624 Doc updates for bce(4) tuneables Note that for 7/8/9 the strict_rx_mtu variable is named loose_rx_mtu. diff 197835 Wed Oct 07 11: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 20: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 20:54:46 MST 2009 delphij Reflect newly added PCI IDs to bce(4). MFC after: 2 months diff 185574 Tue Dec 02 23: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 16: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 17:29:31 MST 2007 brueffer Xref altq(4). diff 164819 Sat Dec 02 07:03:06 MST 2006 brueffer bce(4) does not work correctly in polling(4) mode for now. diff 164819 Sat Dec 02 07:03:06 MST 2006 brueffer bce(4) does not work correctly in polling(4) mode for now. |
H A D | hme.4 | diff 204605 Tue Mar 02 20:14:14 MST 2010 joel The NetBSD Foundation has granted permission to remove clause 3 and 4 from their software. Obtained from: NetBSD diff 194193 Sun Jun 14 12:46:25 MDT 2009 marius Improve the description a bit and add a reference to vlan(4). diff 187316 Thu Jan 15 20:08:17 MST 2009 marius Don't cross-reference gem(4) and hme(4); maybe this made some sense back when these two were the only two NIC drivers working on sparc64 but it no longer does nowadays. MFC after: 3 days diff 187316 Thu Jan 15 20:08:17 MST 2009 marius Don't cross-reference gem(4) and hme(4); maybe this made some sense back when these two were the only two NIC drivers working on sparc64 but it no longer does nowadays. MFC after: 3 days diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 148145 Mon Jul 18 22:26:30 MDT 2005 trhodes Add a "Load module on start up" comment, similar to mac_*.4 pages[1]. Quote .Cd and .Nd text. Bump doc date. Requested by: some user through ru Supported by: ru, dwmalone, brueffer diff 133729 Sat Aug 14 19:44:35 MDT 2004 marius - Capitalize Ethernet and Fast Ethernet. - Add a NOTES section with information regarding the "local-mac-address?" system configuration variable on sparc64 and add a reference to eeprom(8) for using it. Dump document date for this. - In dc.4, add the on-board DM9102A on Sun Netra X1 and Sun Fire V100 to the list of known working devices. 116166 Tue Jun 10 16:53:15 MDT 2003 tmm - Add manpages for the gem and hme ethernet drivers. These were obtained from NetBSD, and changed slightly to account for FreeBSD specifics. - Hook them up to the build. - Add them to the list of miibus-using drivers in miibus(4). |
H A D | amdpm.4 | diff 153942 Sat Dec 31 14:32:27 MST 2005 brueffer Update for new devices, including the AMD 8111. Also mention amdsmb(4) for SMBus 2.0 functionality of the AMD 8111. 83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4), amdpm(4) and smb(4). This device can be used with userland programs such as sysutils/lmmon to retrieve sensor information from the motherboard. PR: kern/23989 Obtained from: Matthew C. Forman <mcf@dmu.ac.uk> Based on: alpm(4) 83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4), amdpm(4) and smb(4). This device can be used with userland programs such as sysutils/lmmon to retrieve sensor information from the motherboard. PR: kern/23989 Obtained from: Matthew C. Forman <mcf@dmu.ac.uk> Based on: alpm(4) 83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4), amdpm(4) and smb(4). This device can be used with userland programs such as sysutils/lmmon to retrieve sensor information from the motherboard. PR: kern/23989 Obtained from: Matthew C. Forman <mcf@dmu.ac.uk> Based on: alpm(4) 83553 Sun Sep 16 20:35:07 MDT 2001 murray SMBus support for the AMD 756 power management unit. See smbus(4), amdpm(4) and smb(4). This device can be used with userland programs such as sysutils/lmmon to retrieve sensor information from the motherboard. PR: kern/23989 Obtained from: Matthew C. Forman <mcf@dmu.ac.uk> Based on: alpm(4) |
H A D | sge.4 | diff 217468 Sun Jan 16 02:17:13 MST 2011 marius Reference rgephy.4 in man pages of additional MAC drivers also known to come in combination with these PHYs. Submitted by: yongari MFC after: 3 days diff 207853 Mon May 10 15:48:50 MDT 2010 yongari Now sge(4) supports TCP segmentation offload (TSO). diff 207381 Thu Apr 29 16:27:37 MDT 2010 yongari Now sge(4) supports hardware VLAN tag insertion/stripping. 206631 Wed Apr 14 19:38:23 MDT 2010 yongari Add sge(4) man page and hook up sge(4) to the build. Also add Xr to appropriate man pages. 206631 Wed Apr 14 19:38:23 MDT 2010 yongari Add sge(4) man page and hook up sge(4) to the build. Also add Xr to appropriate man pages. |
H A D | stge.4 | diff 204605 Tue Mar 02 20:14:14 MST 2010 joel The NetBSD Foundation has granted permission to remove clause 3 and 4 from their software. Obtained from: NetBSD diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 166346 Tue Jan 30 06:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 160800 Fri Jul 28 18:14:43 MDT 2006 simon Add missing .El to close list. This confused the manual page -> hardware notes perl script somewhat and resulted in part of the output for the stge(4) entry not to be present in the hardware notes. Noticed by: brueffer 160643 Mon Jul 24 22:51:38 MDT 2006 yongari Add a man page for stge(4). |
H A D | urtw.4 | diff 198195 Sat Oct 17 22:55:12 MDT 2009 weongyo adds devices supportted by urtw(4) and bumps date. diff 197724 Sat Oct 03 00:39:23 MDT 2009 weongyo TRENDnet TEW-424UB has multiple revisions so clarify zyd(4) man page and adds a device to urtw(4). The revision informations are as follows: rev A ZD1211 V2 SiS163U V2.1R SiS163U V3.xR RTL8187B and bump date. Obtained from: OpenBSD Reported by: Albert Shih <Albert.Shih at obspm.fr> diff 197724 Sat Oct 03 00:39:23 MDT 2009 weongyo TRENDnet TEW-424UB has multiple revisions so clarify zyd(4) man page and adds a device to urtw(4). The revision informations are as follows: rev A ZD1211 V2 SiS163U V2.1R SiS163U V3.xR RTL8187B and bump date. Obtained from: OpenBSD Reported by: Albert Shih <Albert.Shih at obspm.fr> diff 195915 Mon Jul 27 16:19:01 MDT 2009 weongyo urtw(4) supports RTL8187B chipset now. Approved by: re (kib) 187610 Fri Jan 23 03:19:57 MST 2009 weongyo Add a new USB wireless driver, urtw(4) for supporting Realtek's 8187L chipset. |
/freebsd-9.3-release/sys/dev/fdt/ | ||
H A D | fdtbus.c | diff 209127 Sun Jun 13 11:02:11 MDT 2010 raj Provide identify method for the fdtbus(4). Reviewed by: imp Sponsored by: The FreeBSD Foundation 208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure. o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This is a direct replacement for the many incompatible bus drivers grouping integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.) o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which is an umbrella device for most of the integrated peripherals on a typical system-on-chip device. o Other components (common routines library, PCI node processing helper functions) Reviewed by: imp Sponsored by: The FreeBSD Foundation 208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure. o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This is a direct replacement for the many incompatible bus drivers grouping integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.) o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which is an umbrella device for most of the integrated peripherals on a typical system-on-chip device. o Other components (common routines library, PCI node processing helper functions) Reviewed by: imp Sponsored by: The FreeBSD Foundation 208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure. o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This is a direct replacement for the many incompatible bus drivers grouping integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.) o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which is an umbrella device for most of the integrated peripherals on a typical system-on-chip device. o Other components (common routines library, PCI node processing helper functions) Reviewed by: imp Sponsored by: The FreeBSD Foundation 208747 Wed Jun 02 15:21:59 MDT 2010 raj Import the common Flattened Device Tree infrastructure. o fdtbus(4) - the main abstract bus driver for all FDT-compliant systems. This is a direct replacement for the many incompatible bus drivers grouping integrated peripherals on embedded platforms (like obio(4), ocpbus(4) etc.) o simplebus(4) - bus driver representing ePAPR style 'simple-bus' node, which is an umbrella device for most of the integrated peripherals on a typical system-on-chip device. o Other components (common routines library, PCI node processing helper functions) Reviewed by: imp Sponsored by: The FreeBSD Foundation |
/freebsd-9.3-release/sys/dev/glxsb/ | ||
H A D | glxsb.c | diff 185021 Mon Nov 17 05:18:22 MST 2008 philip Fix two possible (but unlikely) NULL-pointer dereferences in glxsb(4). Spotted by: Coverity MFC after: 1 week 181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as found in Soekris hardware, for instance). The hardware supports acceleration of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4). TODO: o Implement rndtest(4) support o Performance enhancements Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org> Reviewed by: jhb, sam MFC after: 1 week 181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as found in Soekris hardware, for instance). The hardware supports acceleration of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4). TODO: o Implement rndtest(4) support o Performance enhancements Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org> Reviewed by: jhb, sam MFC after: 1 week 181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as found in Soekris hardware, for instance). The hardware supports acceleration of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4). TODO: o Implement rndtest(4) support o Performance enhancements Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org> Reviewed by: jhb, sam MFC after: 1 week 181467 Sat Aug 09 13:05:26 MDT 2008 philip Add glxsb(4) driver for the Security Block in AMD Geode LX processors (as found in Soekris hardware, for instance). The hardware supports acceleration of AES-128-CBC accessible through crypto(4) and supplies entropy to random(4). TODO: o Implement rndtest(4) support o Performance enhancements Submitted by: Patrick Lamaizière <patfbsd -at- davenulle.org> Reviewed by: jhb, sam MFC after: 1 week |
/freebsd-9.3-release/sys/dev/scc/ | ||
H A D | scc_if.m | 157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. 157299 Thu Mar 30 16:33:22 MST 2006 marcel Add scc(4), a driver for serial communications controllers. These controllers typically have multiple channels and support a number of serial communications protocols. The scc(4) driver is itself an umbrella driver that delegates the control over each channel and mode to a subordinate driver (like uart(4)). The scc(4) driver supports the Siemens SAB 82532 and the Zilog Z8530 and replaces puc(4) for these devices. |
/freebsd-9.3-release/sys/modules/cpuctl/ | ||
H A D | Makefile | 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month |
/freebsd-9.3-release/usr.sbin/cpucontrol/ | ||
H A D | amd.h | 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month |
H A D | cpucontrol.h | 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month |
H A D | intel.h | 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 14:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month |
/freebsd-9.3-release/etc/etc.sparc64/ | ||
H A D | ttys | diff 203068 Wed Jan 27 10:01:18 MST 2010 ed Remove pseudo-terminals from ttys(5). When we had utmp(5), we had to list all the psuedo-terminals in ttys(5) to make ttyslot(3) function properly. Now that pututxline(3) deals with slot allocation internally (not based on TTY names), we don't need to list all the TTYs on the system in ttys(5) to make user accounting work properly. This patch removes all the entries from the /etc/ttys files, but also the pts(4) entries that were appended implicitly, which was added in r154838. diff 199243 Fri Nov 13 04:06:38 MST 2009 ed Switch the default terminal emulation style to xterm for most platforms. Right now syscons(4) uses a cons25-style terminal emulator. The disadvantages of that are: - Little compatibility with embedded devices with serial interfaces. - Bad bandwidth efficiency, mainly because of the lack of scrolling regions. - A very hard transition path to support for modern character sets like UTF-8. Our terminal emulation library, libteken, has been supporting xterm-style terminal emulation for months, so flip the switch and make everyone use an xterm-style console driver. I still have to enable this on i386. Right now pc98 and i386 share the same /etc/ttys file. I'm not going to switch pc98, because it uses its own Kanji-capable cons25 emulator. IMPORTANT: What to do if things go wrong (i.e. graphical artifacts): - Run the application inside script(1), try to reduce the problem and send me the log file. - In the mean time, you can run `vidcontrol -T cons25' and `export TERM=cons25' so you can run applications the same way you did before. You can also build your kernel with `options TEKEN_CONS25' to make all virtual terminals use the cons25 emulator by default. Discussed on: current@ diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson |
/freebsd-9.3-release/sys/dev/stge/ | ||
H A D | if_stge.c | diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) |
/freebsd-9.3-release/sys/dev/iicbus/ | ||
H A D | iicsmb.c | diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 19:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. |
/freebsd-9.3-release/sys/dev/vge/ | ||
H A D | if_vgereg.h | diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt whenever the link state is changed. Using software based polling for media status tracking is known to cause MII access failure under certain conditions once link is established so vge(4) used to rely on link status change interrupt. However DEVICE_POLLING completely disables generation of all kind of interrupts on vge(4) such that this resulted in not detecting link state change event. This means vge(4) does not correctly detect established/lost link with DEVICE_POLLING. Losing the interrupt made vge(4) not to send any packets to peer since vge(4) does not try to send any packets when there is no established link. Work around the issue by generating link state change interrupt with DEVICE_POLLING. PR: kern/160442 Approved by: re (kib) diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt whenever the link state is changed. Using software based polling for media status tracking is known to cause MII access failure under certain conditions once link is established so vge(4) used to rely on link status change interrupt. However DEVICE_POLLING completely disables generation of all kind of interrupts on vge(4) such that this resulted in not detecting link state change event. This means vge(4) does not correctly detect established/lost link with DEVICE_POLLING. Losing the interrupt made vge(4) not to send any packets to peer since vge(4) does not try to send any packets when there is no established link. Work around the issue by generating link state change interrupt with DEVICE_POLLING. PR: kern/160442 Approved by: re (kib) diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt whenever the link state is changed. Using software based polling for media status tracking is known to cause MII access failure under certain conditions once link is established so vge(4) used to rely on link status change interrupt. However DEVICE_POLLING completely disables generation of all kind of interrupts on vge(4) such that this resulted in not detecting link state change event. This means vge(4) does not correctly detect established/lost link with DEVICE_POLLING. Losing the interrupt made vge(4) not to send any packets to peer since vge(4) does not try to send any packets when there is no established link. Work around the issue by generating link state change interrupt with DEVICE_POLLING. PR: kern/160442 Approved by: re (kib) diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt whenever the link state is changed. Using software based polling for media status tracking is known to cause MII access failure under certain conditions once link is established so vge(4) used to rely on link status change interrupt. However DEVICE_POLLING completely disables generation of all kind of interrupts on vge(4) such that this resulted in not detecting link state change event. This means vge(4) does not correctly detect established/lost link with DEVICE_POLLING. Losing the interrupt made vge(4) not to send any packets to peer since vge(4) does not try to send any packets when there is no established link. Work around the issue by generating link state change interrupt with DEVICE_POLLING. PR: kern/160442 Approved by: re (kib) diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt whenever the link state is changed. Using software based polling for media status tracking is known to cause MII access failure under certain conditions once link is established so vge(4) used to rely on link status change interrupt. However DEVICE_POLLING completely disables generation of all kind of interrupts on vge(4) such that this resulted in not detecting link state change event. This means vge(4) does not correctly detect established/lost link with DEVICE_POLLING. Losing the interrupt made vge(4) not to send any packets to peer since vge(4) does not try to send any packets when there is no established link. Work around the issue by generating link state change interrupt with DEVICE_POLLING. PR: kern/160442 Approved by: re (kib) diff 225440 Wed Sep 07 15:12:16 MDT 2011 yongari vge(4) hardwares poll media status and generates an interrupt whenever the link state is changed. Using software based polling for media status tracking is known to cause MII access failure under certain conditions once link is established so vge(4) used to rely on link status change interrupt. However DEVICE_POLLING completely disables generation of all kind of interrupts on vge(4) such that this resulted in not detecting link state change event. This means vge(4) does not correctly detect established/lost link with DEVICE_POLLING. Losing the interrupt made vge(4) not to send any packets to peer since vge(4) does not try to send any packets when there is no established link. Work around the issue by generating link state change interrupt with DEVICE_POLLING. PR: kern/160442 Approved by: re (kib) diff 200638 Thu Dec 17 16: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 16: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 16: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 16: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-9.3-release/etc/etc.ia64/ | ||
H A D | ttys | diff 203068 Wed Jan 27 10:01:18 MST 2010 ed Remove pseudo-terminals from ttys(5). When we had utmp(5), we had to list all the psuedo-terminals in ttys(5) to make ttyslot(3) function properly. Now that pututxline(3) deals with slot allocation internally (not based on TTY names), we don't need to list all the TTYs on the system in ttys(5) to make user accounting work properly. This patch removes all the entries from the /etc/ttys files, but also the pts(4) entries that were appended implicitly, which was added in r154838. diff 199243 Fri Nov 13 04:06:38 MST 2009 ed Switch the default terminal emulation style to xterm for most platforms. Right now syscons(4) uses a cons25-style terminal emulator. The disadvantages of that are: - Little compatibility with embedded devices with serial interfaces. - Bad bandwidth efficiency, mainly because of the lack of scrolling regions. - A very hard transition path to support for modern character sets like UTF-8. Our terminal emulation library, libteken, has been supporting xterm-style terminal emulation for months, so flip the switch and make everyone use an xterm-style console driver. I still have to enable this on i386. Right now pc98 and i386 share the same /etc/ttys file. I'm not going to switch pc98, because it uses its own Kanji-capable cons25 emulator. IMPORTANT: What to do if things go wrong (i.e. graphical artifacts): - Run the application inside script(1), try to reduce the problem and send me the log file. - In the mean time, you can run `vidcontrol -T cons25' and `export TERM=cons25' so you can run applications the same way you did before. You can also build your kernel with `options TEKEN_CONS25' to make all virtual terminals use the cons25 emulator by default. Discussed on: current@ diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson |
/freebsd-9.3-release/etc/etc.powerpc/ | ||
H A D | ttys | diff 203068 Wed Jan 27 10:01:18 MST 2010 ed Remove pseudo-terminals from ttys(5). When we had utmp(5), we had to list all the psuedo-terminals in ttys(5) to make ttyslot(3) function properly. Now that pututxline(3) deals with slot allocation internally (not based on TTY names), we don't need to list all the TTYs on the system in ttys(5) to make user accounting work properly. This patch removes all the entries from the /etc/ttys files, but also the pts(4) entries that were appended implicitly, which was added in r154838. diff 199243 Fri Nov 13 04:06:38 MST 2009 ed Switch the default terminal emulation style to xterm for most platforms. Right now syscons(4) uses a cons25-style terminal emulator. The disadvantages of that are: - Little compatibility with embedded devices with serial interfaces. - Bad bandwidth efficiency, mainly because of the lack of scrolling regions. - A very hard transition path to support for modern character sets like UTF-8. Our terminal emulation library, libteken, has been supporting xterm-style terminal emulation for months, so flip the switch and make everyone use an xterm-style console driver. I still have to enable this on i386. Right now pc98 and i386 share the same /etc/ttys file. I'm not going to switch pc98, because it uses its own Kanji-capable cons25 emulator. IMPORTANT: What to do if things go wrong (i.e. graphical artifacts): - Run the application inside script(1), try to reduce the problem and send me the log file. - In the mean time, you can run `vidcontrol -T cons25' and `export TERM=cons25' so you can run applications the same way you did before. You can also build your kernel with `options TEKEN_CONS25' to make all virtual terminals use the cons25 emulator by default. Discussed on: current@ diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 17:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 06:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson |
/freebsd-9.3-release/sys/dev/pcf/ | ||
H A D | envctrl.c | diff 181332 Tue Aug 05 15:48:04 MDT 2008 jhb - Consolidate module version for the pcf module into just pcf.c instead of having duplicate versions in each bus attachment. - Add a DRIVER_MODULE() instance so that the iicbus(4) driver will actually attach to pcf(4) driver instances. - Fix compile of envctrl.c. Pointy hat: jhb (3) diff 181332 Tue Aug 05 15:48:04 MDT 2008 jhb - Consolidate module version for the pcf module into just pcf.c instead of having duplicate versions in each bus attachment. - Add a DRIVER_MODULE() instance so that the iicbus(4) driver will actually attach to pcf(4) driver instances. - Fix compile of envctrl.c. Pointy hat: jhb (3) diff 181303 Mon Aug 04 19: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 19: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 19: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 19: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 19: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 19: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 19: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 146966 Sat Jun 04 18:29:28 MDT 2005 marius Account for ebus(4) defaulting to SYS_RES_MEMORY for memory resources since ebus.c rev. 1.22. |
/freebsd-9.3-release/sys/dev/smc/ | ||
H A D | if_smc.c | diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) diff 227277 Sun Nov 06 19:17:04 MST 2011 marius MFC: r226995, r227042 - 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 8k. The only potential in-tree users left unconverted are ed(4) and xe(4). Xe(4) 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 it just for the MII bitbang'ing code. Ed(4) has some chip specific things interwinded with the MII bitbang'ing code and it's unclear whether it can be converted to common code, at least not without thorough testing of all the various chips supported by ed(4). 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) Approved by: re (kib) Obtained from: NetBSD (partially) |
/freebsd-9.3-release/lib/libz/contrib/ | ||
H A D | README.contrib | diff 205471 Mon Mar 22 19:22:48 MDT 2010 delphij Update to zlib 1.2.4 and add versioned symbols to the library. Sponsored by: iXsystems, Inc. diff 205305 Thu Mar 18 22:37:30 MDT 2010 delphij Merge changes from zlib 1.2.4. Bump shared library version number. 205194 Mon Mar 15 18:14:07 MDT 2010 delphij Vendor import of zlib 1.2.4 (trimmed). |
/freebsd-9.3-release/lib/libz/contrib/asm686/ | ||
H A D | README.686 | diff 205471 Mon Mar 22 19:22:48 MDT 2010 delphij Update to zlib 1.2.4 and add versioned symbols to the library. Sponsored by: iXsystems, Inc. diff 205305 Thu Mar 18 22:37:30 MDT 2010 delphij Merge changes from zlib 1.2.4. Bump shared library version number. 205194 Mon Mar 15 18:14:07 MDT 2010 delphij Vendor import of zlib 1.2.4 (trimmed). |
Completed in 524 milliseconds