Re: port-arm/53171 (Broadcom (and other ARM SoC i2c drivers) mis-handle indirect configuration of devices)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Apr 30, 2018, at 10:33 AM, Jared McNeill <jmcneill%invisible.ca@localhost> wrote:
> 
> Can this change be done in a way where we require explicit locators for attaching indirect child devices? I worry about driver probe functions sending crap over the i2c bus on boards where we've otherwise strictly defined devices in the DT.

Not sure what you mean —do  you mean “disallow wildcard locators for indirect config”?  That should be trivial.  I think just about all of the i2c drivers already specifically filter their own “valid addresses for this device” before even doing anything, though.

That said, the current behavior, is obviously a bug … probably introduced when FDT-ization of evbarm happened in the first place (I guess no one had devices that were commented out in the kernel config files to try?)

Anyway, if you want to prevent random devices from even trying known-to-DT-i2c-locations, we’ll have to separately record which i2c locations are reserved for direct-config-only, and only process indirect after we’ve finished enumeration of direct-config devices from the DT.

I’m not sure what all of this really buys you, though, because userland has access to i2c as well … so to keep that avenue from tripping things up, you want to separate filter “any address that is in use by the kernel for some reason”.  But that filter would add expense to each userland i2c command, since the address is specified in the i2c exec argument.  Seems like an orthogonal problem that warrants a separate change.

DT is nifty, but it’s leading to an annoying bifurcation of device configuration information.  The kernel config file was the traditional way to specify this stuff… but if we’re going to say “hey, the right thing to do on FDT platforms is to provide your own DT snippets for whatever hardware you’re adding to your prototyping platform”, then we need a way to make that easy (or discoverable, or maybe both).

-- thorpej