Re: Arm drivers: are device tree descriptions required for every device?

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi,

[I realise that Jason has given a comprehensive reply, but just to expand
on this part:

> However Brad Spenser <brad%anduin.elder.org@localhost> who wrote the
> driver and has been very helpful suggested adding an overlay dtbo to
> list the devices explicitly:

> So that works now. Let's keep the same config but pull one of the
> chips:
> 
> [     1.000000] iic1 at bsciic1: I2C bus
> [     1.000000] bmx280thp0 at iic1 addr 0x76
> [     1.000000] bmx280thp0: Bosch Sensortec BME280, Chip ID: 0x60
> [     1.000000] bsciic2 at simplebus1: Broadcom Serial Controller
> [     1.000000] bsciic2: interrupting on icu irq 53
> [     1.000000] iic2 at bsciic2: I2C bus
> [     1.000000] bmx280thp1 at iic2 addr 0x76
> [     1.000000] bmx280thp1: autoconfiguration error: Failed to reset
> chip: 5
> [     1.000000] bmx280thp1: autoconfiguration error: Unable to setup
> device
> 
> Well I guess that's expected, but it's a bit noisy! Certainly if you
> used the module attach then there would be just one entry and no error
> message.

This is related to the way that the match routine, the configuration and
the attach routine interact.  In the configuration, we've explicitly said
that there is a device of this type at that address.  The device match
routine therefore doesn't probe various address (which is possible on some
buses like i2c).  We go straight to the attach routine to configure the
device.  In there, we discover that there's a problem.  The initial line:

  bmx280thp1 at iic2 addr 0x76

is output by the configuration code, so it's quite hard to avoid printing
that.  The attach routine then prints the error(s) when it discovers the
problem.  From a user point of view, it would be nice to not have any
messages at all, but I think for this corner case, then we can live with it.

Specifically for bmx280, we could fail earlier so that we only see one
error line, by adding "goto out" in the error checks, e.g.:

  https://nxr.netbsd.org/xref/src/sys/dev/ic/bmx280.c#424

This might be beneficial, because it looks to me that we set up the sysctl
tree even if there are errors communicating with the chip.

Regards,

Julian

PS.  I have the same on sparc64, where I extend the equivalent of FDT there,
but I don't know if all the hardware is present.  In the attach routine, I
can only check early on, print the error, and exit attach if a read fails.

--