tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: i2c and indirect vs. direct config




> On Jun 3, 2018, at 7:30 AM, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> 
> On Sat, Jun 02, 2018 at 03:51:07PM -0700, Jason Thorpe wrote:
>> 
>>> On Jun 2, 2018, at 2:07 PM, Paul Goyette <paul%whooppee.com@localhost> wrote:
>>> 
>>> There's the "minimal-functionality" controller that sits on the "system management PCI bus" and driven by the imc/imcsmb driver.
>> 
>> 
>> OMG, what a dumpster fire.  Geez, if they were going to to for minimal functionality, why even bother with dumb logic like that??  A pair of GPIO pins would have been better!
> 
> I have a dumb suggestion.
> 
> Would we avoid, in the end, pain and suffering if we didn't treat this
> controller (or controllers like it) as i2c controllers, and just provided
> alternate attachements for the leaf drivers?
> 
> Then we'd be free to use more sophisticated methods with "real" i2c
> controllers, and only do potentially invasive things when we found a
> nasty pseudo-i2c one.

Actually, I am thinking more of a set of properties that control the behavior of the generic i2c code:

— i2c-indirect-probe-strategy — We’ll let the i2c code default to “smbus_quick_write”, and this property can override with “smbus_receive_byte” or “none”.  If “none”, then we skip the probe entirely as we do now, but of course run the risk of device ghosting.

— i2c-indirect-device-whitelist — For a case like the Intel CPU imc, it can provide an array of device names that it can safely handle.  This seems reasonable considering it’s a specialized controller anyway that’s designed specifically to talk to memory SPD EEPROMs.  Think of this as almost a hybrid of direct and indirect … “this is what will be here, but we don’t know if it actually is”.  In this scenario, a driver like spdmem would have to do do the heavy lifting to do the actual presence-detect (which it already does, in fact).

Boy, I really would like a way to get access to the new device_t between config_found and when it calls ca_attach for the device… right now, device_register is the only hook we have for attaching properties to a new device.

-- thorpej



Home | Main Index | Thread Index | Old Index