Re: [PATCH] USB: ftdi_sio: add GPIO support

[Grant Likely]

On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Jul 07, 2014 at 12:44:28PM +0200, Linus Walleij wrote:
>> On Fri, Jun 13, 2014 at 8:31 PM, Greg Kroah-Hartman
>> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> > On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
>>
>> >> But I also want to bring the device model into question: normally
>> >> when a mother device spawns children across different subsystems
>> >> we model them as MFD devices (drivers/mfd) that instantiate
>> >> children for the different subsystems. So you could spawn a
>> >> serial and a GPIO device from a USB-based hub device there.
>> >>
>> >> I do not know if that is really apropriate in this case. It seems the
>> >> device is first and foremost FTDI.
>> >>
>> >> But it could still spawn a child platform device for the GPIO stuff
>> >> so that this can live as a separate driver under drivers/gpio/gpio-ftdi.c
>> >> or similar.
>> >>
>> >> You could then use something like:
>> >>
>> >> struct platform_device *gdev;
>> >
>> > Ick, no, it's a USB device, do not abuse the platform_device code any
>> > more than it currently is (note, I HATE the platform device code,
>> > someday I'll delete it entirely...  Well, I can dream...)
>>
>> Haha yeah :-)
>>
>> However is the MFD cell approach acceptable?
>
> Yes it is.

Going back to this old conversation... Actually, I disagree. There is
absolutely no need to go the MFD approach for this driver. That just
adds layers of abstraction for no purpose. GPIOLIB is an interface,
and it is completely fine for a driver to hook up to the GPIOLIB
interface at the same time as exposing a serial port. MFD doesn't buy
the driver anything useful here.

g.
--
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/