bhnd(4) chipc child enumeration using the chipc capabilities.

[landonf]

Summary

Replaces use of DEVICE_IDENTIFY with explicit enumeration of chipc
child devices using the chipc capability structure.

This is a precursor to PMU support, which requires more complex resource
assignment handling than achievable with the static device name-based
hints table.

Test Plan

Tested on:

• RT-N16
• RT-N53
• WGT634U
• BCM43225
• BCM4312

[adrian]

ok, this looks ok to me. what's michael think?

[landonf]

In D6896#144679, @adrian wrote:

ok, this looks ok to me. what's michael think?

Let's find out :-)

[mizhka]

Hi,

I've scan changes briefly:

• what is test strategy? is it just kernel loading or passing over rc to multiuser mode?
• changes are more than announced ;) for instance, flashmap is removed. What is new alternative to flashmap?

[landonf]

In D6896#144860, @mizhka_gmail.com wrote:

Hi,

I've scan changes briefly:

• what is test strategy? is it just kernel loading or passing over rc to multiuser mode?

I've only been testing up to (not including) root mount, pending working CFI on RT-N16 (D5674).
I just got an RT-N53, which uses SPI flash, I should be able to test beyond just flash probing there.

• changes are more than announced ;) for instance, flashmap is removed. What is new alternative to flashmap?

Thanks for catching that; I missed flash_register_slicer().

[mizhka]

I also want to solve CFI issue on RT-N16, hope Alex will look on it.
My laziness forced me to code following test for MIPS boards:

• CFE load kernel
• login as root
• call devinfo, uname, hostname, ifconfig

https://github.com/Cka3o4Huk/uart-mips-test/blob/master/src/main/java/com/github/Cka3o4Huk/CallUnixWrapper.java#L67

May be it worth to have 2 resources for PMU drivers to avoid significant change from DEVICE_IDENTIFY to old-style children creation code?

sys/dev/bhnd/cores/chipc/chipc.c

289–295 ↗

(On Diff #17703)

BTW, it may be more straigthforward to define 2 different resources (RID=0 / RID=1), isn't it?

[landonf]

In D6896#144912, @mizhka_gmail.com wrote:

May be it worth to have 2 resources for PMU drivers to avoid significant change from DEVICE_IDENTIFY to old-style children creation code?

In terms of being good newbus citizens, we're ultimately better off doing device identification at the bus level; the resource hint table mechanism really just gave us a way to perform bus-level resource enumeration while working around the inversion of control that DEVICE_IDENTIFY creates in the bus/driver relationship.

Quoth the DEVICE_IDENTIFY documentation:

The identify function for a device is only needed for devices on busses that cannot identify their children independently, e.g. the ISA bus.

[landonf]

Re-introduced missing chipc_slicer support.

Verified boot to multiuser on:

• RT-N16 (with D5674)
• RT-N52 (with ROOTDEVNAME=ufs:flash/spi0s.rootfs)

[mizhka]

This comment was removed by mizhka.