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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ