From: Guenter Roeck <linux@roeck-us.net>
To: Mark Brown <broonie@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, Armin Wolf <W_Armin@gmx.de>
Subject: Re: Page select register restrictions in regmap core
Date: Mon, 17 Jun 2024 16:15:33 -0700 [thread overview]
Message-ID: <e6733f56-014e-4ea0-aaf8-059334f2b27f@roeck-us.net> (raw)
In-Reply-To: <19893519-20a6-47cf-bb3b-c61dada627bc@sirena.org.uk>
On 6/17/24 15:47, Mark Brown wrote:
> On Mon, Jun 17, 2024 at 02:55:09PM -0700, Guenter Roeck wrote:
>> On 6/17/24 10:22, Mark Brown wrote:
>
>>> The range is *entirely* defined within the driver, it is 100% a software
>>> construct, the hardware only influences our choice of range in that we
>>> can't place it on top of hardware registers.
>
>> I _think_ what you are saying is that I'd have to model all registers
>> which are to be addressed through regmap as virtual registers with an offset
>> outside the range of real registers. Something like adding 0x100 to the
>
> No, only registers that are accessed through a window need to be
> mapped into a range. Any other registers can just be accessed.
>
See below.
>> each register address and then accessing, say, the revision register
>> not as register 0x02 but as register 0x102. I would then define the matching
>> range from 0x100 .. 0x17f and the window from 0x00..0x7f.
>
> That would make the range exactly the same size as the window so there'd
> be no paging going on and the registers could be accessed directly? I
> guess that's another check that should be added...
>
I tried to explain this before. The registers in address range 00..0x7f
are physical, but they are only accessible from page 0 with the exception
of the page select register. So, sure, the registers are not actually paged,
but page 0 must be selected to access them. That is the one and only reason
for specifying that first range and window. It ensures that page 0 is
selected when accessing the registers. If that wasn't the case, I could
define a single range for the actually paged addresses in the 0x80..0xff
window and be done with it.
>> Hmm, yes, I see that this should work. I don't think it is worth doing though
>> since I need to be able to access some registers outside regmap, and I'd have
>> to define two sets of addresses for all those registers. That would simplify
>> the code a bit but one would have to remember that register addresses through
>> regmap are different than register addresses when calling smbus functions
>> directly. I think we'll just stick with the current code and keep the paging
>> implementation in the driver.
>
> Mixing regmap and non-regmap access to the same registers seems like a
> bad idea in general, you will have locking issues (especially around the
> paging).
The non-regmap access all happens in the probe function before regmap is
initialized. It is needed for basic chip identification, to prevent someone
from instantiating the driver on a random nvram/eeprom and messing it up
with attempts to write the page select register. I would not want to be
held responsible for someone with, say, DDR4 DIMMs force-instantiating
the spd5118 driver and then complaining about bricked DIMMs.
Thanks,
Guenter
next prev parent reply other threads:[~2024-06-17 23:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 14:20 Page select register restrictions in regmap core Guenter Roeck
2024-06-17 15:08 ` Mark Brown
2024-06-17 16:59 ` Guenter Roeck
2024-06-17 17:22 ` Mark Brown
2024-06-17 21:55 ` Guenter Roeck
2024-06-17 22:47 ` Mark Brown
2024-06-17 23:15 ` Guenter Roeck [this message]
2024-06-18 11:35 ` Mark Brown
2024-06-18 16:14 ` Guenter Roeck
2024-06-18 17:01 ` Guenter Roeck
2024-06-18 17:45 ` Mark Brown
2024-06-18 18:10 ` Guenter Roeck
2024-06-18 19:33 ` Guenter Roeck
2024-06-18 20:46 ` Mark Brown
2024-06-18 21:23 ` Guenter Roeck
2024-06-19 3:11 ` Guenter Roeck
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=e6733f56-014e-4ea0-aaf8-059334f2b27f@roeck-us.net \
--to=linux@roeck-us.net \
--cc=W_Armin@gmx.de \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.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 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.