linux-kernel - Re: [PATCH v2 2/4] gpio: add viperboard gpio driver

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: <20121025160651.GO18814@opensource.wolfsonmicro.com>
Date:	Thu, 25 Oct 2012 17:06:51 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Lars Poeschel <poeschel@...onage.de>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Lars Poeschel <larsi@....tu-dresden.de>, sameo@...ux.intel.com,
	linux-kernel@...r.kernel.org, jic23@....ac.uk, khali@...ux-fr.org,
	ben-linux@...ff.org, w.sang@...gutronix.de,
	grant.likely@...retlab.ca
Subject: Re: [PATCH v2 2/4] gpio: add viperboard gpio driver

On Thu, Oct 25, 2012 at 06:02:42PM +0200, Lars Poeschel wrote:

> On Thursday 25 October 2012 at 16:00:13, Mark Brown wrote:

> > Why would you want to implement this as a bus?  If you're not actually
> > rendering things down into a register and value on the bus then you
> > should be hooking in at the level before we do the marshalling since
> > that's totally irrelevant.  This should be done by making the
> > marashalling pluggable.

> Did you have a look at the code ? I want to render things down to registers 

No.

> and values on the bus! In the one and only case a pin is set to be an output 
> and someone reads it's value, I don't want the bus to become active and 
> instead read the value from the regmap cache.

Are you saying that whoever designed this USB device has done it so that
it takes a byte stream with something like RRVV where RR is the register
and VV is the value?  That's the marshalling, as you'll have seen that's
done before the buses see the data.

> > What do you actually need to read back here?

> Someone reads a gpio value register. To be able to decide if I really have to 
> do the read on the usb bus or if I can use a cached value, I have to know if 
> the pin in question is an output or an input. To get this information I have 
> to do another register read. If it's an output I give back the cached value, 
> if it's an input I do the register read.

Is the I/O selection per GPIO or per device?

> > So just invalidate the cache and it'll get restored next time we look at
> > the register.

> Yes, this is exactly what I gave as an alternative in my second to last mail. 
> But this invalidates the whole register map although I just want to update 
> one register value.

So add that functionality to the core if it's not there. 

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)