linux-kernel - Re: [PATCH v3 1/1] regmap: Synchronize cache for the page selector

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6b4cba29-786c-4999-ac1d-27b3e4cea6f8@samsung.com>
Date: Tue, 28 Jan 2025 17:08:08 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org, Greg
	Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki"
	<rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>, Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>, DRI mailing list
	<dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v3 1/1] regmap: Synchronize cache for the page selector

Hi Andy,

On 21.01.2025 14:29, Andy Shevchenko wrote:
> On Tue, Jan 21, 2025 at 08:33:09AM +0100, Marek Szyprowski wrote:
>> On 17.01.2025 18:28, Andy Shevchenko wrote:
>>> On Fri, Jan 17, 2025 at 05:05:42PM +0100, Marek Szyprowski wrote:
>>>
>>> Does it fail in the same way?
>> Yes, the hw revision is reported as zero in this case: LT9611 revision:
>> 0x00.00.00
> Hmm... This is very interesting! It means that the page selector is a bit
> magical there. Dmitry, can you chime in and perhaps shed some light on this?
>
>>>> Does it mean that there is really a bug in the driver?
>>> Without looking at the datasheet it's hard to say. At least what I found so far
>>> is one page of the I²C traffic dump on Windows as an example how to use their
>>> evaluation board and software, but it doesn't unveil the bigger picture. At
>>> least what I think is going on here is that the programming is not so easy as
>>> just paging. Something is more complicated there.
>>>
>>> But at least (and as Mark said) the most of the regmap based drivers got
>>> the ranges wrong (so, at least there is one bug in the driver).
>> I can do more experiments if this helps. Do you need a dump of all
>> regmap accesses or i2c traffic from this driver?
> It would be helpful! Traces from the failed and non-failed cases
> till the firmware revision and chip ID reading would be enough to
> start with.

I'm sorry for the delay, I was a bit busy with other stuff.

Here are logs (all values are in hex):

next-20250128 (probe broken):
root@...get:~# dmesg | grep regmap
[   14.817604] regmap_write reg 80ee <- 1
[   14.823036] regmap_read reg 8100 -> 0
[   14.827631] regmap_read reg 8101 -> 0
[   14.832130] regmap_read reg 8102 -> 0
[   14.841477] regmap_write reg 80ee <- 0
[   14.901796] regmap_write reg 80ee <- 1
[   14.909895] regmap_read reg b021 -> 0
[   14.927409] regmap_write reg 80ee <- 0

next-20250128 + 1fd60ed1700c reverted (probe okay):
root@...get:~# dmesg | grep regmap
[   13.565920] regmap_write reg 80ee <- 1
[   13.567509] regmap_read reg 8100 -> 17
[   13.568219] regmap_read reg 8101 -> 4
[   13.568909] regmap_read reg 8102 -> 93
[   13.568927] regmap_write reg 80ee <- 0
[   13.625844] regmap_write reg 80ee <- 1
[   13.630963] regmap_read reg b021 -> 40
[   13.645522] regmap_write reg 80ee <- 0
[   13.880192] regmap_write reg 80ee <- 1
[   13.884921] regmap_read reg b023 -> 0
[   13.892159] regmap_write reg 80ee <- 0
[   13.954508] regmap_write reg 80ee <- 1
[   13.959441] regmap_read reg b023 -> 0
[   13.963269] regmap_write reg 80ee <- 0
[   14.029818] regmap_write reg 80ee <- 1
[   14.034644] regmap_read reg b023 -> 0
[   14.038491] regmap_write reg 80ee <- 0
[   16.278387] regmap_write reg 80ee <- 1
[   16.283902] regmap_read reg b023 -> 0
[   16.287944] regmap_write reg 80ee <- 0
[   16.347570] regmap_write reg 80ee <- 1
[   16.355894] regmap_read reg b023 -> 0
[   16.359748] regmap_write reg 80ee <- 0
[   16.452472] regmap_write reg 80ee <- 1
[   16.454387] regmap_write reg d00d <- 4
[   16.456228] regmap_write reg d00e <- 65
[   16.462096] regmap_write reg d00f <- 4
[   16.462971] regmap_write reg d010 <- 38
[   16.463741] regmap_write reg d011 <- 8
[   16.464741] regmap_write reg d012 <- 98
[   16.465250] regmap_write reg d013 <- 7
[   16.465764] regmap_write reg d014 <- 80
[   16.466481] regmap_write reg d015 <- 5
[   16.467156] regmap_update_bits reg d016 <- 0/f
[   16.467817] regmap_write reg d017 <- 2c
[   16.468325] regmap_update_bits reg d018 <- 0/f
[   16.469101] regmap_write reg d019 <- 4
[   16.469749] regmap_update_bits reg d01a <- 0/f
[   16.470509] regmap_write reg d01b <- 58
[   16.471041] regmap_write reg 80ee <- 0


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland