FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F6.0.0_cvs 2005-11-03T00:35:26Z 2005-11-03T00:35:26Z cvs2svn cvs2svn@FreeBSD.org 2005-11-03T00:35:26Z urn:sha1:3640cb54210edbb7edbf1b12ef0127ecfcea967d 'RELENG_6_0_0_RELEASE'. This commit was manufactured to restore the state of the 6.0-RELEASE image. 2005-06-04T20:29:28Z Marius Strobl marius@FreeBSD.org 2005-06-04T20:29:28Z urn:sha1:fcff6919708c873df54baa527935a8ace0883c7a since ebus.c rev. 1.22. 2004-08-12T17:41:33Z Marius Strobl marius@FreeBSD.org 2004-08-12T17:41:33Z urn:sha1:26280d88d76716790cf28f23fdb0bda56533e9b6 subset ("compatible", "device_type", "model" and "name") of the standard properties in drivers for devices on Open Firmware supported busses. The standard properties "reg", "interrupts" und "address" are not covered by this interface because they are only of interest in the respective bridge code. There's a remaining standard property "status" which is unclear how to support properly but which also isn't used in FreeBSD at present. This ofw_bus kobj-interface allows to replace the various (ebus_get_node(), ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type() vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one. This in turn allows to simplify and remove code-duplication in drivers for devices that can hang off of more than one OFW supported bus. - Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the drivers for their children to use the ofw_bus kobj-interface. The IVAR- interfaces of the Central, EBus and FHC are entirely replaced by this. The PCI bus driver used its own kobj-interface and now also uses the ofw_bus one. The IVARs special to the SBus, e.g. for retrieving the burst size, remain. Beware: this causes an ABI-breakage for modules of drivers which used the IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be recompiled. The style-inconsistencies introduced in some of the bus drivers will be fixed by tmm@ in a generic clean-up of the respective drivers later (he requested to add the changes in the "new" style). - Convert the powerpc MacIO bus driver and the drivers for its children to use the ofw_bus kobj-interface. This invloves removing the IVARs related to the "reg" property which were unused and a leftover from the NetBSD origini of the code. There's no ABI-breakage caused by this because none of these driver are currently built as modules. There are other powerpc bus drivers which can be converted to the ofw_bus kobj-interface, e.g. the PCI bus driver, which should be done together with converting powerpc to use the OFW PCI code from sparc64. - Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take advantage of the ofw_bus kobj-interface and simplify them a bit. Reviewed by: grehan, tmm Approved by: re (scottl) Discussed with: tmm Tested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386 2004-08-11T21:19:31Z Marius Strobl marius@FreeBSD.org 2004-08-11T21:19:31Z urn:sha1:490a46bf68d240953b091232c755ed5526e931b9 Sun AXe board. 2004-07-04T16:11:03Z Stefan Farfeleder stefanf@FreeBSD.org 2004-07-04T16:11:03Z urn:sha1:5908d366fb365362004d549066a6225f0c46d3e6 in <sys/cdefs.h> for compilers without support for inline. 2004-06-10T21:56:52Z Marius Strobl marius@FreeBSD.org 2004-06-10T21:56:52Z urn:sha1:397f6b1e7fc1706fe731589a57d71ad6382f299c is the actual name here) on EBus and which are PCF8584 (on systems having a boot-bus controller the i2c are said to not be a PCF8584). Similar to the SUNW,envctrl devices, onboard slaves for monitoring fans, temperatures and such hang off of these i2c devices. But there's also stuff like EEPROMs housing the hostid of the system and the boards usally have a connector to add custom slave devices (on CP1500 there's actually a second PCF8584 with its own I2C bus for these). This driver already works fine but I'm not yet sure if access to the slave devices on CP1400/CP1500 marked as "reserved for factory use" in the docs should be blocked (most likely these are the voltage controllers wich aren't meant to be controller by software and even not by the firmware). Once the issues with polled mode are fixed in the common pcf(4) part in pcf.c, this front-end should probably honour the poll-mode property of the i2c devices. Tested on Ultra AXe and CP1500 (Netra t1 100). OK'ed by: joerg, nsouch 2004-06-10T21:53:04Z Marius Strobl marius@FreeBSD.org 2004-06-10T21:53:04Z urn:sha1:a9f012c75d5e7ce18cb7245baa5be731cdb29bac - Use "envctrl" as the name when registering this module rather than "pcf"; we can't have "pcf" as the name for all pcf(4) front-ends or we would get conflicts. OK'ed by: joerg 2004-06-10T21:51:39Z Marius Strobl marius@FreeBSD.org 2004-06-10T21:51:39Z urn:sha1:cdd89aebf5a7ea7b44309367ba6d008a2cd28794 - s,pcf_,pcf_isa, to better reflect the purpose of this front-end and to avoid conflicts. - Don't use this front-end for attaching to EBus, declaring it as an EBus driver was a cut&paste accident according to joerg. OK'ed by: joerg, nsouch 2004-06-10T21:48:51Z Marius Strobl marius@FreeBSD.org 2004-06-10T21:48:51Z urn:sha1:f2ce1eaef99063884a66832d171b50edf6045d4f - Remove two tabs from an otherwise empty line. OK'ed by: nsouch 2004-05-31T14:24:21Z Nicolas Souchu nsouch@FreeBSD.org 2004-05-31T14:24:21Z urn:sha1:4f16b8b19044c8de2cba8878969872c276d35af9 my Elektor card. Note that the hints are necessary to specify the IO base of the pcf chip. This enables to check the IO base when the probe routine is called during ISA enumeration. The interrupt driven code is mixed with polled mode, which is wrong and produces supposed spurious interrupts at each access. I still have to work on it.