linux-kernel - Re: [PATCH 1/2] arm64: dts: sun50i-a64-pinephone: Add AF8133J to PinePhone

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: <CAGb2v66-saec9RcQsCTNOz_Tz4+BSFPdDd6CEA+RrGcF6kCY=A@mail.gmail.com>
Date: Sat, 19 Oct 2024 10:04:06 +0800
From: Chen-Yu Tsai <wens@...e.org>
To: Andrey Skvortsov <andrej.skvortzov@...il.com>, Chen-Yu Tsai <wens@...e.org>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, 
	linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, Shoji Keita <awaittrot@...k.jp>, 
	Icenowy Zheng <icenowy@...c.io>, Andre Przywara <andre.przywara@....com>
Subject: Re: [PATCH 1/2] arm64: dts: sun50i-a64-pinephone: Add AF8133J to PinePhone

On Sun, Sep 15, 2024 at 6:12 PM Andrey Skvortsov
<andrej.skvortzov@...il.com> wrote:
>
> Hi Chen-Yu Tsai,
>
> On 24-09-09 16:08, Chen-Yu Tsai wrote:
> > On Mon, Sep 9, 2024 at 5:48 AM Andrey Skvortsov
> > <andrej.skvortzov@...il.com> wrote:
> > >
> > > From: Icenowy Zheng <icenowy@...c.io>
> > >
> > > New batches of PinePhones switched the magnetometer to AF8133J from
> > > LIS3MDL because lack of ST components.
> > >
> > > Both chips use the same PB1 pin, but in different modes.
> > > LIS3MDL uses it as an gpio input to handle interrupt.
> > > AF8133J uses it as an gpio output as a reset signal.
> > >
> > > It wasn't possible at runtime to enable both device tree nodes and
> > > detect supported sensor at probe time, because both drivers try to
> > > acquire the same gpio in different modes.
> > >
> > > Device tree fixup will be done in firmware without introducing new board
> > > revision and new dts.
> >
> > FYI I've been working on an in-kernel prober [1] for such alternative
> > components. This does not require firmware support.
> >
> > [1] https://lore.kernel.org/all/20240904090016.2841572-1-wenst@chromium.org/
>
> Thank you for the information.
>
> I've tried to use in-kernel prober from your v7 patchset [1] on top of
> -next and it worked without any changes to firmware.
>
> Since there is still on-going review of your patches it looks like
> it's to early to submit my changes for review. But I'm ready to test
> your new patches.

FYI I'm open to either approach. If the firmware can do it, that is also
fine. I don't know if it makes sense to have both disabled by default
though? That would break existing users, but so would the in-kernel
prober approach, which requires both components be marked as
"fail-needs-probe", and also requires that the kernel driver be enabled.

In other words, I think the firmware approach is friendlier for existing
users that have the original batches.


ChenYu


> [1] https://lore.kernel.org/all/20240911072751.365361-1-wenst@chromium.org/
>
> --
> Best regards,
> Andrey Skvortsov
>