Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

[Alan Cox]

> Further, it is critical to enable hardware vendors to avoid writing
> any code for which there are existing drivers.

Which is why you don't want to create a new bus type for it.

> Capebus seems to me to provide this solution fairly well. I don't
> believe the SFI approach covers the most critical aspects of hotplug
> behaviour.

I think you missed the point - it just an example of doing this not one
I'd suggest using directly.

> >> > your ->detect() method should take care of that.
> >>
> >> There isn't some magical serial number in IÂC devices that a
> >> ->detect() method can read and the implementation of IÂC is somewhat
> >
> > It doesn't matter.
> >
> > What you are basically talking about is
> >
> >
> >         cape layer
> >                 - wtf is this
> >                 - how do I plumb it
> >
> >                 - create device nodes with correct name for
> >                   binding, address etc on the right bus
> >
> >
> >         i2c layer
> >                 - ooh a new i2c device
> >                 - probe as indicated by device name
> >                 - attach correct driver
> 
> Many of the devices cannot be probed.

Look more closely at the code I pointed you at. I wonder if have a
differing understanding of the word "probe" in this situation. In the
Linux space the driver bindings call the matching probe function based
upon the device structure.

In Linux the probe method does not mean "scan the bus and enumerate/detect
the devices"

If an iÂc bus is thrown a device which has an address and a matching name
the only thing it will attempt to do is to call the probe method of the
device driver matching that name on the given iÂc address. In other words
its a "probe" in the sense of "I've been told there is one of your
widgets here, please take a look" not a "probe" in the sense of "scan 255
iÂc addresses and poke randomly at them"

SFI for example creates entries for things like

	"type foo pressure sensor at 0x68 on bus 3"

and the core kernel iÂc code will only call the "foo" drivers probe method
and only on bus 3 and only for address 0x68.

In your case you want to use your DT fragments or any other descriptor
format to do exactly the same. Not create a new bus but add a bunch of
devices to the existing busses.

It's like hot plugging a PCI card - you don't create a new PCI bus, you
add a device to the existing bus. In the PCI case the device has
properties that uniquely identify it from hardware level. In the iÂc case
the properties come from your DT fragment or similar. The rest is the
same.

> I know I *am* the slow person in the room, but doesn't this approach
> require the code to be compiled into the kernel to support the devices
> ahead of time? While I think it might be reasonable to have hardware

The specific implementation in SFI does but thats a property of SFI. I'm
not trying to push SFI itself anywhere except over the edge of a very tall
cliff.

The point is that you can take a description of things like iÂc devices
and have then properly identified on the existing busses using the
existing bus architecture just fine.

> developers provide DT fragments in their EEPROMs, there's no way to
> get them to submit code patches in order to get their hardware to
> work. They need to ship hardware that works with pre-existing
> software, since there will be hundreds of boards created by people
> with little to no previous Linux experience (akin to Arduino). I seem
> to be missing how that approach would get us there.

That is what I assume and what I believe can be provided without
inventing imaginary bus types.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/