> > > I did think about doing this but the problem is how do
> > > you know bus 2 is the bus you think it is?
> >
> > The numbering is board-specific, but in most cases
> > that can be simplified to being SOC-specific. ...
> >
> > Hotpluggable SPI controllers are not common, but
> > that's where that sysfs API to define new devices
> > would really hit the spot. ...
> >
> > (What I've seen a bit more often is that expansion
> > cards will be wired for SPI, so the thing that's
> > vaguely hotplug-ish is that once you know what
> > card's hooked up, you'll know the SPI devices it
> > has. Then the question is how to tell the kernel
> > about them ... same solution, which again must work
> > without hardware probing.)
>
> This is why I decided to pass the cs table as platform
> data when an adapter is registered. This way you don't
> have to try to find out an adapters bus number as the
> adapter has the cs table in it, but because it was
> passed in as platform data it still abstracts that
> from the adapter driver. Simple, yet effective :)
Except that it doesn't work in that primary case, where the SPI devices
are physically decoupled from any given SPI (master) controller.
One expansion card uses CS1 for a touchscreen; another uses CS3 for
SPI flash ... the same "cs table" can't handle both configurations.
It's got to be segmented, with devices separated from controllers.
Plus, that depends on standardizing platform_data between platforms.
That's really not the model for platform_data! And "struct clk" is
ARM-only for now, too ...
> Have you looked at the patch which I sent?
> http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0817.html
>
> I would appreciate any comments on this approach.
Yes, I plan to follow up to that with comments. As with Dmitry's
proposal, it's modeled closely on I2C, and is in consequence larger
than needed for what it does.
One reason I posted this driver-model-only patch was to highlight how
minimal an SPI core can be if it reuses the driver model core. I'm
not a fan of much "mid-layer" infrastructure in driver stacks.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |