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

[Dave Tyson <dtyson%anduin.org.uk@localhost>]

On Wed, 2023-04-12 at 08:24 -0700, Jason Thorpe wrote:

snip..snip..snip

>
> Right, this is because when a platform uses Device Tree, the auto
> configuration pass at boot time considers the device tree to be
> authoritative.  The kernel config file in this case doesn’t specify
> “YO A DEVICE IS RIGHT HERE!”, instead it’s specifying the *matching
> criteria* for an instance of that driver.  Make sense?

> If you have a DT overlay, you can just have this in the kernel
> config:

> bmx280thp* at iic?

> What that says is “hey, include the bmx280thp driver in the kernel,
> and allow it to attach to any i2c bus at any address”, and the i2c
> bus will use the device tree information to enumerate the devices and
> there you go.

OK, that makes sense. I can understand why you would want to make the
dtc a definitive source of info. I guess you could replicate the kernel
config lines

xxxx at iic? 

multiple times for each possible device and only the ones decribed in
the dtc will be attached.

I guess a similar situation will occur with spi where devices don't
have a logical address and rely on a signal on a physical pin to select
them.
 
> I have a bunch of improvements to i2c and spi device
> autoconfiguration that I’ve been working on for some time, but
> haven’t pushed in yet.  I should find the time to resurrect them.
> 

That would be interesting - especially if it was well documented. I
think one of the main problems is that even the offical rpi
documentation is inconsistent in places. It would be useful to be able
to look at the device tree passed to the kernel after boot from
userland to help debug problems. I think this is possible in linux.

> one final thing to note is that i2cscan (which is the subject of at 
> least one PR) is still broken, reporting multiple non-existent
> devices!
>
> See my statement above.  i2c “scanning” is a crap shoot at best, and
> that’s basically because of how I2C works.

While I understand that probing for devices on an i2c bus is error
prone and can cause lockups, it does seem to work reasonably reliably
on linux for most of the sensors I have played with... The rpi code
seems to have more problems than that on clone devices like the banana
or orange pi's

Thanks for the clarification!

Dave