FDT on x86 and for non-fdtbus devices.

[Marcel Moolenaar]

On Feb 13, 2013, at 3:21 PM, Warner Losh <imp at bsdimp.com> wrote:

>> What we like to do is to use the FDT to define properties for
>> pretty much any kind of device. Examples are:
>> 1.  Allow the FDT to define the name by which an interface is
>>   to be created.
> 
> This might be hard...  Perhaps you could flesh out a bit how you'd propose to do this.

The thought so far is to use an "interface-name" property in
FDT node that provides the name to give to if_initname().

With a single function like if_initname(), you can actually
put the logic there, provided we then also pass the device_t
(or something similar) to if_initname().

>> 2.  Enumerate smb devices so that we can attach drivers for them
>>   under smbus when we don't need FDT to find ichsmb itself.
> 
> If there's a 1-1 correspondence in the the FDT between the smb bridge driver (ichsmb) and the sub devices, this could work.

Exactly: I'd like this to work for iicbus as well so that we
can actually describe the whole i2c bus hierarchy/hierarchies.

Using indirect I/O (i.e. always pass requests to the parent),
you can have drivers in arbitrarily complex hierarchies (i.e.
with i2c muxes) do I/O, and as such provide whatever interface
is beneficial, without having to expose H/W details to the
consumers.

> 
>> I think one way to state the problem in a generic way is: How
>> can we obtain the FDT pnode_t given an arbitrary device_t and
>> use the pnode_t to query for properties, etc.
> 
> Yes. What's the naming conventions we need to use here, especially since names in the FDT don't necessarily match our driver names. Crazy idea: define freebsd,driver-name properlty to make this association explicit.
> 
>> Are people already doing things like this?
> 
> only a little.
> 
>> Is there an interest in being able to do things like this?
> 
> Yes.
> 
>> Are changes to drivers to have them query FDT contributable at
>> all or do people think such would be "pollution"?
> 
> I like this idea, but others may not be so open to it.

While our aim is to build JUNOS on a pristine FreeBSD, we
will always have local changes. As long as the changes are
contained we're fine. So if we can't change a driver, but
we can contribute the infrastructure, we're very happy.


>> Thoughts?
>> Ideas?
> 
> "Go speed racer! Go!"

Roger that :-)

-- 
Marcel Moolenaar
marcel at xcllnt.net