and resume methods so these events propagate through the device driver
hierarchy.
- In dma(4) enable the chaining of the DMA engine interrupt handler for
the LANCE devices via a dma_setup_intr(). This was commented out before
as I was unsure whether I'd use it but this is probably cleaner than
fiddling with the DMA engine interrupt in the LANCE driver directly.
- In ebus_setup_dinfo() free 'intrs' instead of 'reg' twice in case
setting up a child fails due to routing one of its interrupts fails. [1]
Found by: Coverity Prevent [1]
MFC after: 3 days
ofw_bus_gen_get_*() for providing the ofw_bus KOBJ interface in order
to reduce code duplication.
- While here sync the various sparc64 bus drivers a bit (handle failure
to attach a child gracefully instead of panicing, move the printing
of child resources common to bus_print_child() and bus_probe_nomatch()
implementations of a bus into a <bus>_print_res() function, ...) and
fix some minor bugs and nits (plug memory leaks present when attaching
a bus or child device fails, remove unused struct members, ...).
Additional testing by: kris (central(4) and fhc(4))
inevitable component in Sun Exx00 machines and provides serial ports,
NVRAM and TOD amongst others which are handled by uart(4) and eeprom(4)
respectively). This driver currently only prints out information about
the chassis on attach and allows to blink the 'Cycling' LED (which is
duplicated on the front panel) of the clock board just like fhc(4) does
for the other boards. The device name for the LED is /dev/led/clockboard.
Obtained from: OpenBSD
Tested by: joerg
bus_generic_rl_release_resource() for the bus_release_resource() method
instead of a local copy.
- Correctly handle pass-through allocations in fhc_alloc_resource().
- In case the board model can't be determined just print "unknown model"
so the physical slot number is reported in any case.
- Add support for blinking the 'Cycling' LED of boards on a fhc(4) hanging
of off the nexus (i.e. all boards except the clock board) via led(4).
All boards have at least 3 controllable status LEDs, 'Power', 'Failure'
and 'Cycling'. While the 'Cycling' LED is suitable for signaling from
the OS the others are better off being controlled by the firmware.
The device name for the 'Cycling' LED of each board is /dev/led/boardX
where X is the physical slot number of the board. [1]
Obtained from: OpenBSD [1]
Tested by: joerg [1]
Change fhc(4) to use IRQ numbers instead of RIDs for allocating the
IRQs of children. This works similar to e.g. sbus(4), i.e. add the
IRQ resources as fully specified to the resource lists of the children,
allocate them like normal. When establishing the interrupt search the
interrupt maps of the children for a matching INO to determine which
map we need to write the fully specified interrupt number to and to
enable the mapping (before the RID was used to indicate which interrupt
map to use).
- dev/puc/puc.c:
Revert rev. 1.38, with the above change fhc(4) no longer needs special
treatment for allocating IRQs.
Thanks to: joerg for providing access to an E3500
- Use FBSDID.
- Remove unused macro.
- Use auto-generated typedefs for the prototypes of the bus and device
interface functions.
- Terminate the output of device_printf(9) with a newline char.
- Honour the return values of malloc(), OF_getprop(), etc.
- Use __func__ instead of hardcoded function names.
- Print the physical slot number and the board model on attach.
MFC after: 1 month
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
group number properly based on the board id. Perform dummy reads of
registers after writing to flush the hardware write buffers.
This gets the soon to be committed zs attachment working.
UltraSPARCs, and an eeprom attachment for fhc, which allows the date
to be set properly on these machines. Central is a wierd bus which
seems to only ever have 1 fhc attached to it. FHC (FireHose Controller)
is another wierd bus with various things on it depending where its attached.
The fhc attached to central has eeprom and zs, and the fhcs which attach
directly to nexus have simm-status, environment and other nodes, none of
which I'll probably ever have documentation for.
Thanks to Ade Lovett for providing access to an 8 cpu e4500.
