linux-kernel - Re: [PATCH] USB: ftdi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 30 May 2015 21:29:20 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Sascha Silbe <x-linux@...ra-silbe.de>,
	Johan Hovold <jhovold@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] USB: ftdi_sio: add GPIO support

On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> 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@...uxfoundation.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/