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]
Message-ID: <CACxGe6uskWcBU0MhO=EupU=2VKmDhX01-_LDJ-n91XAnRYiqbw@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ