On Tue, Oct 22, 2013 at 08:10:00PM -0700, Guenter Roeck wrote:
> On 10/22/2013 12:02 AM, Johannes Thumshirn wrote:
> >Hi List,
> >
> >I have a design question concerning a device driver. The device in question
> >is
> >somewhere in between drivers/mfd/timberdale and drivers/ssb. It is mapped
> >connected via PCI and on PCI Bar 0 there is a table describing which
> >"sub-devices" are contained in the FPGA as well as where their Memory and IRQ
> >resources are.
> >
> >Unlike the timberdale driver, there is no static configuration of the FPGA's
> >sub-devices, but their number and kind is variable. But luckily we have
> >unique
> >device-ids for every sub-device, so it is possible to do a PCI/USB like
> >enumeration.
> >
> >In my understanding the MFD API, which timberdale uses, isn't tailored to
> >this
> >Plug'n'Play like behavior. Whereas the I think (virtual) bus concept used by
>
> Not sure if that is true. There is no requirement to declare mfd cells
> statically. As long as the devices don't change after mfd probe, an mfd based
> solution would at least be implementable.
Yes it would be implementable, but would it be a good idea to do so?
>
> However, adding support for new sub-devices might be an issue, as you would
> have to update the mfd driver to add support for each new device (to create
> its
> mfd cell and platform data), in addition to writing the actual driver.
>
Adding sub-devices could probably be done without changing th mfd driver, as I
have a device-id, which is part o the article number, so I could generate the
string for the modalias in a generic way.
> >SSB is much more suited for this kind of devices. But would it be wise to
> >add a
> >bus only suited to devices manufactured by one vendor, when there is already
> >a
> >API for such kinds of multi function devices?
> >
> Assuming you refer to mfd, isn't that a contradiction ? You just stated that
> mfd
> doesn't exactly meet your requirements. There is also an API for adding a new
> bus,
> and it is used quite widely.
Well my requirements probably can be met using the mfd framework, but I'm not
shure if it would be a good design decission then. Or maybe adding a bus would
be a better decission. The thing is, I don't want to make me a maintainence
hell, but have something I ideally don't need to touch a 2nd time once it is
done right.
>
> Question for me would be if the additional overhead for adding a bus
> outweighs its
> benefits.
>
> >Long story short, which would be the preferred way to implement such a
> >driver? At
> >the point I currently reached I could go in both directions.
> >
> >I'd appreciate any advice I can get on this topic.
> >
>
> I'm adding Greg KH to the thread. Maybe he has some useful advice as the
> driver core
> maintainer. I have struggled with the question if to add a bus myself, so
> maybe I can
> get something useful out of it ;).
This really would be great. If you can get an answer as well, we'd have a win
win situation ;).
Thanks a lot for your comments.
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
