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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 1 Sep 2014 10:51:27 +0100 From: Lee Jones <lee.jones@...aro.org> To: Octavian Purdila <octavian.purdila@...el.com> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Linus Walleij <linus.walleij@...aro.org>, Alexandre Courbot <gnurou@...il.com>, wsa@...-dreams.de, Samuel Ortiz <sameo@...ux.intel.com>, Arnd Bergmann <arnd@...db.de>, Johan Hovold <johan@...nel.org>, linux-usb@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>, linux-gpio@...r.kernel.org, linux-i2c@...r.kernel.org, Daniel Baluta <daniel.baluta@...el.com>, Laurentiu Palcu <laurentiu.palcu@...el.com> Subject: Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices On Mon, 01 Sep 2014, Octavian Purdila wrote: > On Mon, Sep 1, 2014 at 11:37 AM, Lee Jones <lee.jones@...aro.org> wrote: > > On Sat, 30 Aug 2014, Octavian Purdila wrote: > > > >> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > >> Master Adapter DLN-2. Details about the device can be found here: > >> > >> https://www.diolan.com/i2c/i2c_interface.html. > >> > >> Information about the USB protocol can be found in the Programmer's > >> Reference Manual [1], see section 1.7. > >> > >> Because the hardware has a single transmit endpoint and a single > >> receive endpoint the communication between the various DLN2 drivers > >> and the hardware will be muxed/demuxed by this driver. > >> > >> Each DLN2 module will be identified by the handle field within the DLN2 > >> message header. If a DLN2 module issues multiple commands in parallel > >> they will be identified by the echo counter field in the message header. > >> > >> The DLN2 modules can use the dln2_transfer() function to issue a > >> command and wait for its response. They can also register a callback > >> that is going to be called when a specific event id is generated by > >> the device (e.g. GPIO interrupts). The device uses handle 0 for > >> sending events. > >> > >> [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > > > MFD is not a dumping ground for misfit h/w. Almost all of this code > > looks like it belongs in drivers/usb. Please move it there. > > > > We initially submitted this driver as a pure USB driver, with our own > module registration mechanism, but during the first round of reviews > people pointed out that a MFD driver is the better approach, and I > agree. I also see that there are already a couple of USB drivers > implemented as MFD drivers. Can you link me to your previous submission please? > Do you see a better approach? You should have a small MFD driver which controls resources and registers children. All other functionality should live in their respective drivers/X locations i.e. USB functionallity should normally live in drivers/usb. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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