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

[Jared McNeill <jmcneill%invisible.ca@localhost>]

On Apr 30, 2018, at 4:51 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> 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.

I thought we had some drivers that relied on this but when I went to look I couldn’t find any..

> 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?)

Completely agree that it’s a bug. Thanks for working on this.

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

I’m not really concerned with preventing access to the I2C bus. I just want to make sure that we don’t accidentally break things for GENERIC and GENERIC-like kernel configs. As long as we disallow wildcard locators for indirect config on these busses, I think we will be ok. Maybe I’m just being paranoid.

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

Cheers,
Jared