linux-kernel - Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices

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:	Tue, 2 Sep 2014 17:07:33 +0200
From:	Johan Hovold <johan@...nel.org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Johan Hovold <johan@...nel.org>,
	Octavian Purdila <octavian.purdila@...el.com>,
	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>, 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 Tue, Sep 02, 2014 at 09:00:10AM +0100, Lee Jones wrote:
> On Mon, 01 Sep 2014, Johan Hovold wrote:

> > No, no. USB is not a function of the MFD device, it's the transport.
> > Thus there should be no USB MFD-cell. No subdriver can work without it.
> > 
> > And the USB id belongs in the MFD-driver in the same way that an
> > i2c id (address) does.
> > 
> > Just like an MFD device with i2c as a transport, this driver would
> > function as an arbiter to a shared resource (i.e. the register space).
> > The reason it seems much more USB-centric than an i2c-mfd driver is that
> > that transport API is simpler and some code have also already been
> > generalised (e.g. regmap), whereas we appear to have only two USB
> > mfd-drivers thus far.
> > 
> > The viperboard is perhaps a bad example in so far that it has pushed the
> > transport details down into the subdrivers (and thus into gpio, i2c and
> > iio subsystems) instead of handling it one place.
> 
> Thanks for your explanation.  I take your point about the USB ID and I
> did say I was guessing that the USB part should exist as a child
> device.
> 
> So after your comments I decided to do a little investigation.  It
> appears that this MFD driver is _just_ using the common API which all
> other devices utilising USB comms are forced to use.  Is that correct?

Yes, it's using the low-level USB API, but there's a lot of higher-level
interfaces in place for (fairly) standard things such as the USB class
drivers or the USB serial subsystem.

> If so, I have a question.  Is there no way to hide more of the USB
> specifics inside a better, simpler API?  It looks like the drivers
> which use USB are subjected to a lot (too much) of what might be
> considered internals.  Or is it just that the client has to tinker
> with too many dials to get anything sensible out? *shudders*

Unfortunately, anything that does not already have a driver is likely to
use some vendor-specific protocol and therefore must use the low-level
API.

> > I haven't looked at the details of the protocol for the device in
> > question, but it might even be possible to use regmap here (as I
> > mentioned in my comments on v1).
> 
> Obviously that would be preferred.

Simple register-based USB MFD devices (e.g. only using control
transfers) are conceivable though, and if we start seeing a lot of those
(which I doubt) perhaps that part could be refactored as a regmap bus.

Johan
--
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/