From: Nishanth Menon <nm@ti.com>
To: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Lee Jones <lee@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <afd@ti.com>, <bb@ti.com>,
<d-gole@ti.com>,
Jan Dakinevich <jan.dakinevich@salutedevices.com>
Subject: Re: [PATCH] mfd: syscon: Set max_register_is_0 when syscon points to a single register
Date: Wed, 28 Aug 2024 09:44:34 -0500 [thread overview]
Message-ID: <20240828144434.oydsgflsqy5vibxe@sapling> (raw)
In-Reply-To: <ce44b268-d138-445d-a149-e5348897d3c5@sirena.org.uk>
Mark,
On 15:27-20240828, Mark Brown wrote:
> On Wed, Aug 28, 2024 at 08:32:29AM -0500, Nishanth Menon wrote:
> > On 13:57-20240828, Mark Brown wrote:
> > > On Wed, Aug 28, 2024 at 07:10:08AM -0500, Nishanth Menon wrote:
>
> > > > Fixes: 0ec74ad3c157 ("regmap: rework ->max_register handling")
>
> > > In what sense is this a fix?
>
> > The max_register was 0x0 was clearly a corner case. The fix done for
> > remap should have cleaned up the users of max_register to maintain the
> > behavior. That is just my opinion.
>
> No, apart from the fact that catching all possible regmap users would be
> rather hard it's entirely optional for regmaps to specify a maxium
> register.
Fair enough, I can drop the 'Fixes' tag.
[...]
> Like I say specifying a maximum register is entirely optional, not
I understand max_register is entirely optional as documented in
include/linux/regmap.h and I understand why max_register_is_0 exists -
the patch does NOT try to revert the valid feature in regmap.
> everyone wants that feature and if you don't use the debugfs interface
> or the flat cache it doesn't *super* matter. With 0 as default it's
> always going to be awkward to describe a maximum register of 0 while
> allowing that to be optional, fortunately very few devices have a single
> register.
yeah, unfortunately I have to deal with a few of them :(
This is a patch for syscon, not regmap. I am a bit confused as to what
objection beyond the "Fixes" usage (which I can drop
in a respin) you may have here, will appreciate if you are NAKing the
patch and on what rationale.
I understand that regmap considers the max_register usage entirely
optional, but syscon does already use it (my patch doesn't introduce
it). I am just getting syscon to catchup to what regmap already
provides.
Side effect of leaving the current syscon code as is creating bad
results that should can be trivially caught (and could have saved me
a couple of hours of early morning head scratching today[1]). I think
the regmap checks are valuable, and should be consistent in usage by
syscon. And I think the checks are valuable for programmers from
mistakenly introducing bad code.
[1] Already pointed out in diffstat https://lore.kernel.org/all/20240828131601.6sxvnwpcsb36tz4m@eloquent/
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
next prev parent reply other threads:[~2024-08-28 14:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 12:10 [PATCH] mfd: syscon: Set max_register_is_0 when syscon points to a single register Nishanth Menon
2024-08-28 12:57 ` Mark Brown
2024-08-28 13:32 ` Nishanth Menon
2024-08-28 14:27 ` Mark Brown
2024-08-28 14:44 ` Nishanth Menon [this message]
2024-08-28 20:26 ` Mark Brown
2024-08-29 5:04 ` Nishanth Menon
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=20240828144434.oydsgflsqy5vibxe@sapling \
--to=nm@ti.com \
--cc=afd@ti.com \
--cc=arnd@arndb.de \
--cc=bb@ti.com \
--cc=broonie@kernel.org \
--cc=d-gole@ti.com \
--cc=jan.dakinevich@salutedevices.com \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox