linux-kernel - Re: [PATCH 2/6] regmap: Add a magic bus type to handle quirks of analog devices ADIS sensors.

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: <20110907183230.GA4423@opensource.wolfsonmicro.com>
Date:	Wed, 7 Sep 2011 11:32:31 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	linux-kernel@...r.kernel.org, Michael.Hennerich@...log.com,
	linux-iio@...r.kernel.org
Subject: Re: [PATCH 2/6] regmap: Add a magic bus type to handle quirks of
 analog devices ADIS sensors.

On Wed, Sep 07, 2011 at 07:26:10PM +0100, Jonathan Cameron wrote:
> On 09/07/11 18:47, Mark Brown wrote:
> > On Wed, Sep 07, 2011 at 05:19:43PM +0100, Jonathan Cameron wrote:

> > To be honest I'm not terribly happy about
> > pushing this into the regmap core code; if we start needing to do stuff
> > like this we should expose the bus interface.

> That's certainly an option, but I'd really like to use the regmap caching
> stuff in here.  These things can have quite a few registers that other than
> their weird read / write quirks look much like any other register based
> device. (particularly ignoring the burst reads but they tend to apply
> to volatile registers only so caching is probably irrelevant).

> At the moment, the only hooks AFAIKS to allow this are at the bus level.
> I'm not sure where else they could go. (I haven't actually looked much
> at the cache code yet though).

Well, if there's not hooks they could be added if it's not too painful.
However I'm not convinced that's sane.

> Actually I may have misunderstood, do you mean expose the bus interface
> within regmap or just not use regmap at all?

Either.  Or either expose marshalling or add configuration for the
marshalling depending on what's being done, I'm not convinced you need
to be working at SPI level at all.

> >> +static struct regmap_bus regmap_spi_adi = {
> >> +	.write = regmap_spi_write,
> >> +	.read = regmap_spi_read,
> >> +};

> > You want to implement the gather write too if you can.

> Doesn't really exist other than by linearising them into a series
> of calls to the write function. (assuming I understand what those
> functions are doing right!)

If you build up a series of SPI transfers you just need to control when
/CS gets bounced appropriately.
--
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/