From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Andrey Smirnov <andrey.smirnov@convergeddevices.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] regmap: Add no-"bus" configuration possibility
Date: Tue, 20 Nov 2012 20:08:47 +0900 [thread overview]
Message-ID: <20121120110845.GI10560@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1351988297-16145-1-git-send-email-andrey.smirnov@convergeddevices.net>
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
On Sat, Nov 03, 2012 at 05:18:17PM -0700, Andrey Smirnov wrote:
Sorry about the delay - like I say the patch was unfortunately sent
during ELC-E.
> This patch adds two callbacks to the 'regmap' configuration which user
> is expected to set with their implementation of read and write
> functionality for the device.
So, this is where I think we want to end up but a couple of high level
issues I'm seeing, both fairly easy to deal with I suspect.
> + int (*nbstr_read)(void *context, unsigned int reg, unsigned int *val);
> + int (*nbstr_write)(void *context, unsigned int reg, unsigned int val);
One issue is that I find the 'nbstr' name totally unparasable. It looks
like some sort of string or something. Just call the ops reg_ and have
done with it I think...
The other is that rather than have special cases for this I think what
we should be doing is refactoring the code so that the existing bus
based I/O fills in these ops. That will keep the code more maintainable
in the long run since there won't be magic special cases that don't get
much testing or can be missed when doing updates.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-11-20 11:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-04 0:18 [PATCH] [RFC] regmap: Add no-"bus" configuration possibility Andrey Smirnov
2012-11-14 0:37 ` Andrey Smirnov
2012-11-14 2:19 ` Mark Brown
2012-11-20 11:08 ` Mark Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121120110845.GI10560@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=andrey.smirnov@convergeddevices.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.