linux-kernel - Re: [PATCH v3 2/6] Add the main bulk of core driver for SI476x code

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: <20121027213108.GD4564@opensource.wolfsonmicro.com>
Date:	Sat, 27 Oct 2012 22:31:12 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Andrey Smirnov <andrey.smirnov@...vergeddevices.net>
Cc:	hverkuil@...all.nl, mchehab@...hat.com, sameo@...ux.intel.com,
	perex@...ex.cz, tiwai@...e.de, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/6] Add the main bulk of core driver for SI476x code

On Thu, Oct 25, 2012 at 03:26:02PM -0700, Andrey Smirnov wrote:
> On 10/25/2012 12:45 PM, Mark Brown wrote:

> > This really makes little sense to me, why are you doing this?  Does the
> > device *really* layer a byte stream on top of I2C for sending messages
> > that look like marshalled register reads and writes?

> The SI476x chips has a concept of a "property". Each property having
> 16-bit address and 16-bit value. At least a portion of a chip
> configuration is done by modifying those properties. In order to

Right, that's what I remembered from previous code.  There's no way this
should be a regmap bus - a bus is something that gets data serialised by
the core into a byte stream, having the data rendered down into a byte
stream and then reparsing it is a bit silly.  The device should be
hooking in before the data gets marshalled which we can't currently do
but it shouldn't be too hard to make it so that we can have register
read and write functions supplied in the regmap config.

> Also due to the way the driver uses the chip it is only powered up when
> the corresponding file in devfs(e.g. /dev/radio0) is opened at least by
> one user which means that unless there is a user who opened the file all
> the SET/GET_PROPERTY commands sent to it will be lost. The codec driver
> for that chip does not have any say in the power management policy(while
> all the audio configuration is done via "properties") if the chip is not
> powered up the driver has to cache the configuration values it has so
> that they can be applied later.

This is very normal, indeed modern CODEC drivers can leave the chip
powered down whenever it's not performing some function.

> So, since I have to implement a caching functionality in the driver, in
> order to avoid reinventing the wheel I opted for using 'regmap' API for
> this.

> Of course, It is possible that I misunderstood the purpose and
> capabilities of the 'regmap' framework, which would make my code look
> very silly indeed. If that is the case I'll just re-implement it using
> some sort of ad-hoc version of caching.

No, what you're doing is totally sensible.  It needs a bit of extension
to the framework before you can do it though.

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