[i2c] [PATCH 3/5] powerpc: Document device nodes for I2C devices.

[David Brownell]

On Friday 18 May 2007, Scott Wood wrote:
> David Brownell wrote:
> > On Friday 18 May 2007, Scott Wood wrote:
> >>It's not, unless you want the kernel to keep a table to map OF types to 
> >>Linux drivers.
> > 
> > 
> > I don't follow your argument here.  There *IS* no OF type
> > model for I2C at this time.
> 
> No, but there is a general model for matching devices to drivers, and it 
> is based on compatibility with a device type, not by knowing what driver 
> drives it.

Depends on what you mean by "type".  Since C doesn't have them,
I'll use C++ as an example:  each class is a type, but there
are also "virtual" classes.  There are contexts where virtual
classes are appropriate as type specifiers ... and many where
they aren't.

You seem to want a type model which insists on some kind of
identifier for a virtual class, and precludes the more concrete
class identifier which a driver name specifies.  (Yes, that
could be made into a more precise example, but this seems to
capture the essence without bringing in factory idioms...)

Me, I've always found that object oriented notions of type are
rarely a good model for the "code half" of objects where the
"data" (or in this case, "chip") half is externally specified.

The "type" of an RTC driver is "rtc", no matter what hardware
it hooks up to...


> Sure.  The problem is that the code doesn't match by type IDs; it 
> matches by driver name.  While we could map the model property to the 
> type and the compatible model to the driver name, that's only palatable 
> if it's truly compatible and the model only specifies extra features. 
> As I understand it, that isn't true for things like the ds1337.

Well, there are multiple kinds of "type" here, including:

 * Drop-in replacement, e.g. ds1337 and pt7c4337 (a clone
   that I found with a couple seconds' work on Google);

 * Package options, e.g. SOIC8 vs DIP8 ... drop-in at the
   schematic level, not for board layout or manufactury;

 * Almost-identical; an example would be ds1307 and ds1338
   RTCs, differing (at a quick glance) by one bit in the
   control register, if you use the 8-pin package;

 * Drop-in replacement with superset capabilities.  One
   example could be an RTC that adds *ONLY* alarm capability
   to an existing design ... no repurposing of pins, changing
   undefined registe bits, etc

 * Almost-identical plus supserset capabilities common with RTCs
   RTCs including the ds1307 and ds1337 case (core time + date
   registers are identical, control registers differ, and
   the '37 has two alarms);

Now, the pure drop-in doesn't really matter to an OS, and may
not be worth representing in the type system except to avoid
potential confusion.  But in practice the "second source" types
of design seem less common than the almost-identical; there's
always something that could usefully be improved.

The last case is more common, in my observation, than a strict
superset ... suggesting that the OF type "compatibility" model
you mentioned is insufficient for use in this context.

I think you'd be best off defining an attribute specifically
to match the i2c_board_info.type field ... and not expecting
the OF "compatible" mechanism to address notions of what chips
a given device is how compatible with.


> >>It's not *internal*, but there can still be published bindings for a 
> >>given device tree scheme that standardize names.
> > 
> > 
> > Which you haven't proposed -- either the standardized names or
> > how to publish those bindings.  Right?
> 
> There has been discussion on the ePAPR committee about how to maintain a 
> registry for specific device bindings; hopefully something useful comes 
> out of that.

Google tells me this is a very new power.org effort.


> In the meantime, we'd be using Linux-defined names, but of  
> chips (or compatible chip families), not drivers.

Leading back to my observations that the $SUBJECT patch isn't
a sufficient initial proposal ...


> > That all suggests, much to the contrary, that it's easier to let
> > other people pioneer a working framework, and only then start to
> > make concrete suggestions.
> 
> Actually, I had patches to do very similar things as far as device 
> binding goes, and you beat me with your patches by a day or so.  Yours 
> appeared to be broader in scope, so I rebased the remaining bits of my 
> patches onto yours.  The discussion ended up getting bogged down in 
> other aspects of your patch than what I was working on, and I didn't 
> have time to follow it all.

Too bad.  It would have helped if you had helped out earlier.


> > ... however, your suggestions here haven't yet risen to the
> > level of being concrete suggestsions, much less patches which
> > demonstrate this idea.
> 
> OK, I'll make a patch.

It'd be good to see a concrete proposal first; please cc me.

 
> >>The main problem would be conflicts where the same name means different 
> >>things in different bindings, but that seems much less likely than the 
> >>same thing having different names in different bindings.
> > 
> > 
> > Presumably you're aware that in this case there are trivial
> > disambiguation schemes available, such as a "Linux-" prefix.
> 
> Sure; they just need to be used. :-)

:)


 
> > So where is the definition of those "match strings"?  Remembering
> > that the strings are not provided by chip vendors, and that the
> > only currently meaningful strings are those defined by Linux.
> > I'd say that there's nothing for Linux to care about in terms of
> > compatibility.
> 
> Even within Linux, I'd rather be able to just say that I have a ds1337 
> and not have to worry about which driver happens to handle that chip.

I wouldn't object to that, as an additional feature.  Bonus points
if it doesn't need module-init-tools upgrades, so that deployment
isn't held back by the lag in userspace updates...

 
> > Of those fields, you described how to set up only "irq" and "addr".
> > And not "flags", which is needed to distinguish e.g. 7 vs 10 bit
> > addressing and say if SMBus PEC is required.  And it's not at all
> > clear how the other fields would be set up.
> 
> OK, how about "ten-bit" and "packet-error-checking" properties?  Or can 
> the former be determined by whether the address is big enough to need it 
> (i.e. would one ever need to set the ten-bit flag on a device with an 
> address < 0x7f)?

Jean is the best person to answer those questions.  ISTR he was
about to drop support for 10-bit devices but then some users for
that mechanism appeared.


> > I believe "platform_data" would never come from OF, but the
> > board init logic might want to use OF to cross-check its own
> > records.
>
> It wouldn't come from the generic OF code, but it's possible that 
> platform or other glue code could use custom properties to construct 
> platform data.

That should certainly work in some cases.  Thing is, platform_data is
pretty much an agreement between platform and driver, so whatever
builds it would have to know what driver will interpret the data.

 
> >>If such a change to the i2c layer is deemed unacceptable, then we can do 
> >>some sort of table-driven fixup in arch/powerpc -- but that'd be much 
> >>uglier, and I'd prefer that we didn't have to go down that route.
> > 
> > 
> > I too would rather not see powerpc "do its own thing" here; though
> > it's worth noting that the OF glue doesn't seem to be generic yet,
> > despite multiple platforms using OF.
>
> There have been patches aiming for unification of sparc and powerpc OF.

Permit me to be greedy enough to want it all yesterday?  :)

- Dave