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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
