From: Armin Wolf <W_Armin@gmx.de>
To: Guenter Roeck <linux@roeck-us.net>, linux-hwmon@vger.kernel.org
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"René Rebe" <rene@exactcode.de>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Stephen Horvath" <s.horvath@outlook.com.au>,
"Paul Menzel" <pmenzel@molgen.mpg.de>,
"Sasha Kozachuk" <skozachuk@google.com>,
"John Hamrick" <johnham@google.com>
Subject: Re: [RFT PATCH] hwmon: (spd5118) Add support for Renesas/ITD SPD5118 hub controllers
Date: Mon, 17 Jun 2024 00:50:41 +0200 [thread overview]
Message-ID: <da7c9855-ff4b-4e80-99b8-b2fe24a9a9d9@gmx.de> (raw)
In-Reply-To: <d2ba6ed1-3a6a-4481-9f43-265eee78c0c1@roeck-us.net>
Am 16.06.24 um 22:26 schrieb Guenter Roeck:
> Hi Armin,
>
> On 6/16/24 11:09, Armin Wolf wrote:
>> Am 14.06.24 um 20:59 schrieb Guenter Roeck:
>>
>>> The SPD5118 specification says, in its documentation of the page bits
>>> in the MR11 register:
>>>
>>> "
>>> This register only applies to non-volatile memory (1024) Bytes)
>>> access of
>>> SPD5 Hub device.
>>> For volatile memory access, this register must be programmed to '000'.
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> "
>>>
>>> Renesas/ITD SPD5118 hub controllers take this literally and disable
>>> access
>>> to volatile memory if the page selected in MR11 is != 0. Since the
>>> BIOS or
>>> ROMMON will access the non-volatile memory and likely select a page
>>> != 0,
>>> this means that the driver will not instantiate since it can not
>>> identify
>>> the chip. Even if the driver instantiates, access to volatile registers
>>> is blocked after a nvram read operation which selects a page other
>>> than 0.
>>>
>>> To solve the problem, add initialization code to select page 0 during
>>> probe. Before doing that, use basic validation to ensure that this is
>>> really a SPD5118 device and not some random EEPROM. Explicitly select
>>> page 0 when accessing the volatile register space, and protect volatile
>>> register access against nvmem access using the device mutex.
>>
>> Hi,
>>
>> maybe we can use struct regmap_range_cfg so the paged register
>> accesses are being
>> done by the regmap code itself?
>>
>
> In theory that might work, but regmap does not permit a selector
> register to
> be part of another range. The first range would be the non-volatile
> registers,
> and the selector register is part of that for all ranges.
>
> I tried the following ranges configuration.
>
> static const struct regmap_range_cfg spd5118_regmap_range_cfg[] = {
> {
> .selector_reg = SPD5118_REG_I2C_LEGACY_MODE,
> .selector_mask = SPD5118_LEGACY_PAGE_MASK,
> .selector_shift = 0,
> .window_start = 0,
> .window_len = SPD5118_PAGE_SIZE,
> .range_min = 0,
> .range_max = SPD5118_PAGE_SIZE - 1,
> },
> {
> .selector_reg = SPD5118_REG_I2C_LEGACY_MODE,
> .selector_mask = SPD5118_LEGACY_PAGE_MASK,
> .selector_shift = 0,
> .window_start = SPD5118_PAGE_SIZE,
> .window_len = SPD5118_PAGE_SIZE,
> .range_min = SPD5118_PAGE_SIZE,
> .range_max = 9 * SPD5118_PAGE_SIZE - 1,
> },
> };
>
> This results in
>
> spd5118 0-0050: Range 0: selector for 1 in window
> spd5118 0-0050: error -EINVAL: regmap init failed
>
> If you have an idea how to configure the ranges differently,
> please let me know.
>
> Thanks,
> Guenter
>
Oh, i did not think of this. In this case we indeed cannot use regmap here. I will test the patch tomorrow.
Thanks,
Armin Wolf
next prev parent reply other threads:[~2024-06-16 22:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 18:59 [RFT PATCH] hwmon: (spd5118) Add support for Renesas/ITD SPD5118 hub controllers Guenter Roeck
2024-06-16 18:09 ` Armin Wolf
2024-06-16 20:26 ` Guenter Roeck
2024-06-16 22:50 ` Armin Wolf [this message]
2024-06-17 14:58 ` 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=da7c9855-ff4b-4e80-99b8-b2fe24a9a9d9@gmx.de \
--to=w_armin@gmx.de \
--cc=devicetree@vger.kernel.org \
--cc=johnham@google.com \
--cc=krzk+dt@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=linux@weissschuh.net \
--cc=pmenzel@molgen.mpg.de \
--cc=rene@exactcode.de \
--cc=s.horvath@outlook.com.au \
--cc=skozachuk@google.com \
--cc=wsa+renesas@sang-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox