linux-kernel - Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29

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: <868qyiad9f.wl-maz@kernel.org>
Date: Wed, 03 Jul 2024 13:09:00 +0100
From: Marc Zyngier <maz@...nel.org>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: Rob Herring <robh@...nel.org>,
	Christian
 Zigotzky <chzigotzky@...osoft.de>,
	apatel@...tanamicro.com,
	DTML <devicetree@...r.kernel.org>,
	Linux Kernel
 Mailing List <linux-kernel@...r.kernel.org>,
	linuxppc-dev
 <linuxppc-dev@...ts.ozlabs.org>,
	mad skateman <madskateman@...il.com>,
	"R.T.Dickinson" <rtd2@...a.co.nz>,
	Matthew Leaman <matthew@...on.biz>,
	Darren Stevens <darren@...vens-zone.net>,
	Christian Zigotzky
 <info@...osoft.de>
Subject: Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29

Hi Michael,

On Wed, 03 Jul 2024 12:30:38 +0100,
Michael Ellerman <mpe@...erman.id.au> wrote:
> 
> Rob Herring <robh@...nel.org> writes:
> > On Tue, Jul 2, 2024 at 10:54 AM Marc Zyngier <maz@...nel.org> wrote:
> >>
> >> On Sun, 30 Jun 2024 11:21:55 +0100,
> >> Christian Zigotzky <chzigotzky@...osoft.de> wrote:
> >> >
> >> > Hello,
> >> >
> >> > There is an issue with the identification of ATA drives with our
> >> > P.A. Semi Nemo boards [1] after the
> >> > commit "of/irq: Factor out parsing of interrupt-map parent
> >> > phandle+args from of_irq_parse_raw()" [2].
> >>
> >> [snip]
> >>
> >> My earlier request for valuable debug information still stands. But
> >> while you're at it, can you please give the following hack a go?
> >>
> >>         M.
> >>
> >> --- a/drivers/of/irq.c
> >> +++ b/drivers/of/irq.c
> >> @@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
> >>
> >>                         oldimap = imap;
> >>                         imap = of_irq_parse_imap_parent(oldimap, imaplen, out_irq);
> >> -                       if (!imap)
> >> -                               goto fail;
> >> +                       if (!imap) {
> >> +                               match = 0;
> >> +                               break;
> >> +                       }
> >
> > AFAICT reading the DT, I don't think this would fix it. imap should
> > only be null if malformed. This case to me looks like interrupt-map
> > has the correct cell sizes, but just never matches to do the mapping.
> > So maybe imaplen is off and that causes us to end up here, but if
> > there's an error I don't see it. A boot with DEBUG enabled in
> > drivers/of/irq.c would help.
> >
> >>
> >>                         match &= of_device_is_available(out_irq->np);
> >>                         if (match)
> >>
> >> This may not be the final workaround even if it solves your boot
> >> problem, but will at least give us a hint at what is going wrong.
> >>
> >> I have the fuzzy feeling that we may be able to lob this broken system
> >> as part of the of_irq_imap_abusers[] array, which would solve things
> >> pretty "neatly".
> >
> > I think this would work and would consolidate the work-arounds. It
> > would need either "pasemi,rootbus" or "pa-pxp" added to the list.
> 
> Not sure if it helps, but there's already some code in arch/powerpc to
> "fixup" the nemo device tree at boot.
> 
> I'm not sure if it's actually the problem here, but it might be, it does
> renumber some interrupts. Or possibly it could be tweaked to fix
> whatever the issue is.
> 
> The code is in fixup_device_tree_pasemi():
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/prom_init.c?h=v6.10-rc5#n3114

Ah, that's quite interesting, thanks for the pointer.

I can see two possibilities here:

- either we remove the interrupt-map from the DT (no idea if that is
  possible)

- or we patch the interrupt-map to be slightly more useful and
  actually match its input

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.