All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang7@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>, Arnd Bergmann <arnd@arndb.de>,
	Orson Zhai <orsonzhai@gmail.com>,
	Chunyan Zhang <zhang.lyra@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 2/3] regmap: Add reg_update_bits() support
Date: Fri, 10 Apr 2020 10:55:16 +0800	[thread overview]
Message-ID: <CADBw62oP-bJcjWaQiW1zAdix3c4=nfTkNTZZOti6bVtLJwp7+w@mail.gmail.com> (raw)
In-Reply-To: <20200409142620.GE5399@sirena.org.uk>

On Thu, Apr 9, 2020 at 10:26 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Apr 09, 2020 at 10:12:44PM +0800, Baolin Wang wrote:
> > On Thu, Apr 9, 2020 at 6:45 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > MMIO devices clearly don't physically have an update_bits() operation so
> > > this should be implemented further up the stack where it applies to all
> > > buses without physical support.
>
> > I understood your concern. But the syscon driver need use the MMIO
> > devices' resources (such as address mapping, clock management and so
> > on), if move this to further up stack, I am afraid the update_bits()
> > can not use the resources in 'struct regmap_mmio_context'. Do you have
> > any good suggestion? Thanks.
>
> If the syscon driver needs to be peering into the regmap implementation
> that seems like there's a serious abstraction problem - users of the
> regmap shouldn't be looking at the implmentation at all.  Why do you
> think this is needed?

Sorry for confusing, that's not what I mean. My point is the syscon
driver will call the regmap_init_mmio() to use the MMIO regmap_bus,
but as you said, MMIO bus should not a physical bus, so I suppose the
syscon driver should create a new phycical regmap bus for our special
case, but the problem is the phycical regmap bus implementation will
be similar with the MMIO bus except adding a reg_update_bits()
callback, which will introduce more duplicated code. What do you
think?

-- 
Baolin Wang

  reply	other threads:[~2020-04-10  2:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09  8:57 [RFC PATCH 0/3] Add new reg_update_bits() support Baolin Wang
2020-04-09  8:57 ` [RFC PATCH 1/3] mfd: syscon: Add reg_update_bits() callback support Baolin Wang
2020-04-09 10:48   ` Mark Brown
2020-04-09 14:13     ` Baolin Wang
2020-04-09 14:27       ` Mark Brown
2020-04-10  2:15         ` Baolin Wang
2020-04-09 19:23   ` kbuild test robot
2020-04-09  8:57 ` [RFC PATCH 2/3] regmap: Add reg_update_bits() support Baolin Wang
2020-04-09 10:45   ` Mark Brown
2020-04-09 14:12     ` Baolin Wang
2020-04-09 14:26       ` Mark Brown
2020-04-10  2:55         ` Baolin Wang [this message]
2020-04-09  8:57 ` [RFC PATCH 3/3] soc: sprd: Add Spreadtrum special bits updating support Baolin Wang
2020-04-09  9:15 ` [RFC PATCH 0/3] Add new reg_update_bits() support Arnd Bergmann
2020-04-09  9:40   ` Baolin Wang
2020-04-09  9:52     ` Arnd Bergmann
2020-04-09  9:56       ` Baolin Wang

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='CADBw62oP-bJcjWaQiW1zAdix3c4=nfTkNTZZOti6bVtLJwp7+w@mail.gmail.com' \
    --to=baolin.wang7@gmail.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=orsonzhai@gmail.com \
    --cc=zhang.lyra@gmail.com \
    /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.