On Jun 4, 2018, at 2:47 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
On Jun 3, 2018, at 7:44 AM, Jason Thorpe <thorpej%me.com@localhost> wrote:
Actually, I am thinking more of a set of properties that control the behavior of the generic i2c code:
To follow-up, I think I have this sorted out. There were a couple of other issues with how indirect-config was taking place on i2c bus instances, which I fixed as part of this.
I’ll post a more complete follow-up with the details tonight or tomorrow.
OK!
So, a couple of things:
— iic_search() was structured incorrectly, really. In indirect-config, the “search” routine is called one for each directive in the kernel config file that matches the pspec. If that directive has non-wildcarded locators, there is zero need to scan the address space of the bus. It wasn’t entirely wrong before (because of the “check for wildcard” in the loop), but it certainly wasted cycles.
— i2c really needs varying levels of matchy-ness, based on the quality of the match, which I have addressed in my proposed changes.
…which are thus:
— iic_search() chooses a “probe strategy” based on the "i2c-indirect-probe-strategy” property on the “iic” instance. Valid values are "smbus-quick-write”, "smbus-receive-byte”, and “none”. If no value is specified, the default is "smbus-quick-write”.
— If the "i2c-indirect-device-whitelist” exists on the “iic” instance, iic_search() will first check the driver name in the cfdata_t against this list, and only allow the match/probe to move forward if the cfdata_t driver name is in the list. This is primarily to accommodate the Intel integrated memory controller neutered-i2c-thing.
— If the cfdata_t specifies a wildcard address, each address of the i2c bus will be consulted. If the cfdata_t contains a nailed-down address, then we limit the bus scan to that specific address.
— We explicitly skip reserved / special i2c addresses, such as the All-Call address, etc.
— We introduce the notion of a “match quality” for i2c drivers. From lowest-quality to highest-quality: matched by plausible address only, matched by plausible address and poking at the bus to see if the device looks reasonable, matched by direct-config “compatible” string, matched by direct-config “driver name” string.
— If the “match quality” is merely “plausible address only”, then iic_search() will use the probe strategy selected above to see if a device responds to that address.
None of these things impact direct-config, at least not yet. Eventually I will change all drivers to use the match quality values in their various match routines, including those for direct-config.
I haven’t tested these on my RPI just yet — but I will try to do so tonight or tomorrow. But would like to solicit feedback on the approach now.
!DSPAM:5b160dd0170195038547222!