linux-kernel - Re: [PATCH 0/8] Generic I2C and SPI register map library

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: <20110622224828.GA2342@siel.b>
Date:	Thu, 23 Jun 2011 00:48:28 +0200
From:	torbenh <torbenh@....de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-kernel@...r.kernel.org,
	Dimitris Papastamos <dp@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...com>,
	Samuel Oritz <sameo@...ux.intel.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Graeme Gregory <gg@...mlogic.co.uk>
Subject: Re: [PATCH 0/8] Generic I2C and SPI register map library

On Wed, Jun 22, 2011 at 07:44:08PM +0100, Mark Brown wrote:
> [This reposting of the series should address all the review comments on
> the series so far.]
> 
> Many I2C and SPI based devices implement register maps on top of the raw
> wire interface.  This is generally done in a very standard fashion by
> devices, resulting in a lot of very similar code in drivers.  For some
> time now ASoC has factored this code out into the subsystem but that's
> only useful for audio devices.  The intention with this series is to
> generalise the concept so that it can be used throughout the kernel.
> 
> It's not intended that this be suitable for all devices - some devices
> have things that are hard to generalise like registers with variable
> size and paging which are hard to support genericly.  At the minute the
> code is focused on the common cases.  It is likely that the same code
> could be used with other buses with similar properties to I2C and SPI.

you should look at SMBus 
there seems to be quite some code to share.
in particular i2c rtc devices seem to be using SMBus functions
to get the exact same semantics you are providing here.

I just added support for such a device today, and it struck me, that
this API was necessary.

i did not look into it very deeply. and still dont really understand the
diff between SMBus and i2c...





> 
> Currently only physical I/O is handled, the intention is that once this
> support has been reviewed and merged the generic register cache code
> that ASoC includes will also be factored out too.  For devices with read
> heavy workloads (especially those that need a lot of read/modify/write
> cycles) or which don't support read at all this can provide a useful
> performance improvement and for sparse register maps there's a lot of
> benefit in relatively complex cache code.

hopefully, the caching can be selective.
keep rtcs in mind. huge potential for throwing code away there ;)


-- 
torben Hohn
--
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/