linux-kernel - Re: [PATCH v1] media: i2c: imx219: fix msr access command sequence

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] [day] [month] [year] [list]

Date: Tue, 11 Jun 2024 18:39:35 +0100
From: Dave Stevenson <dave.stevenson@...pberrypi.com>
To: Conor Dooley <conor.dooley@...rochip.com>
Cc: Conor Dooley <conor@...nel.org>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, 
	linux-media@...r.kernel.org, Sakari Ailus <sakari.ailus@...ux.intel.com>, 
	Mauro Carvalho Chehab <mchehab@...nel.org>, Adam Ford <aford173@...il.com>, 
	Andrey Konovalov <andrey.konovalov@...aro.org>, linux-kernel@...r.kernel.org, 
	Naushir Patuck <naush@...pberrypi.com>
Subject: Re: [PATCH v1] media: i2c: imx219: fix msr access command sequence

Hi Conor

On Mon, 10 Jun 2024 at 08:32, Conor Dooley <conor.dooley@...rochip.com> wrote:
>
> On Fri, Jun 07, 2024 at 06:55:01PM +0100, Conor Dooley wrote:
> > On Fri, Jun 07, 2024 at 06:29:49PM +0100, Dave Stevenson wrote:
> >
> > > > > ---
> > > > > I got the report of this third hand, I don't have a device and can't
> > > > > test this. I do wonder why the RPis get away with the sequence that
> > > > > seemingly doesn't work for the guy that reported this to me. My theory
> > > > > is either that they noticed the sequence was wrong while adding some
> > > > > other MSR access that is needed on this board while either cross
> > > > > checking the values written or because the other MSR accesses didn't
> > > > > take effect.
> > >
> > > Did the change fix it for the reporter? We're using the driver with no
> > > changes to the register settings cf mainline.
> > > Why it works on the Pi but not on a Microchip board is likely to be
> > > something quite subtle.
> >
> > I've asked, maybe it turns out to just be the first of my suggestions,
> > and they noticed it was not matching in passing.
>
> Apparently it was the latter & they did need to fix the sequence to be
> able to write the MSRs.

Fair enough.

> > They did introduce two
> > additional MSR accesses, both outside of the range documented in the
> > datasheets I could find online. They did have explanations for what those
> > undocumented MSRs did (0x5040 and 0x5041) in the mail I got, but given
> > it's third hand info to me, I dunno if we have the datasheet etc. I'll
> > try to find out some more next week.
>
> Seemingly what those two additional MSRs do is under NDA so I would have
> no way of justifying a patch to add them or the devicetree property
> required to know whether or not the additional MSR writes is needed. :)

NDAs can be a real pain sometimes.
I'm happy with the patch though, and it doesn't stop anything else
working on the Pi.

Reviewed-by: Dave Stevenson <dave.stevenson@...pberrypi.com>
Tested-by: Dave Stevenson <dave.stevenson@...pberrypi.com>