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

[Scott Wood]

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.

> So in a trivial sense, it already has such a null table...
> 
> I honestly can't see anything particularly wrong with letting
> the first set of I2C type IDs be defined by Linux.  

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.

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

> You've had well over six months to make a proposal of that type,
> during which we *know* you've been aware enough of the pending
> Linux patches to make a concrete proposal.  (Your initial OF
> conversion was in November of last year, ISTR...)

I apologize for not following things more closely.

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

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

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

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

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

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

-Scott