In D6896#144679, @adrian wrote:

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

Let's find out :-)

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?

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().

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?

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.