I think I like this approach.
But I'm unclear on how/where the i2c-SMBus device's property-list gets
set in the first place.
For modular drivers loaded from the file-system after the system is up
and running, there is a module prop-list, but I don't think it gets
"hooked in" to the device's prop-list.
For non-modular (built-in) drivers on fdt-based platforms, I suppose
that the fdt stuff could provide the prop-list. (Does it?) But on
non-fdt systems the prop-list would have to be specified somehow,
presumably at "build" time, which to me implies something in the
config language?
Or maybe there's some other mechanism(s) of which I'm not aware?
Or maybe I'm just blind (or more likely, clueless)!
On Mon, 4 Jun 2018, Jason Thorpe wrote:
On Jun 4, 2018, at 2:47 PM, Jason Thorpe <thor...@me.com> wrote:
On Jun 3, 2018, at 7:44 AM, Jason Thorpe <thor...@me.com> 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!
+------------------+--------------------------+----------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+
