Message-ID: <20131023072901.GB24193@jtlinux>
Date:	Wed, 23 Oct 2013 09:29:01 +0200
From:	Johannes Thumshirn <johannes.thumshirn@....de>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	Johannes Thumshirn <johannes.thumshirn@....de>,
	<linux-kernel@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>, Michael Buesch <m@...s.ch>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Driver Design Question

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists