[PATCH v3 0/9] Armada8k enable per-port SATA interrupts and drop a hack in the IRQ subsystem
Marc Zyngier
maz at kernel.org
Fri Mar 19 09:33:47 GMT 2021
On Fri, 19 Mar 2021 08:08:34 +0000,
Marcin Wojtas <mw at semihalf.com> wrote:
>
> HI Gregory,
>
> pt., 19 mar 2021 o 08:35 Gregory CLEMENT <gregory.clement at bootlin.com>
> napisał(a):
> >
> > Hello Marcin,
> >
> > > [Resend in plain text]
> > >
> > > Hi,
> > >
> > > Just letting everyone know - merging only the DT part of this patchset
> > > broke AHCI on all Marvell Armada 7k8k / CN913x platforms in v5.11
> > > release.
> >
> > It's unfortunate that we didn't know this when v5.11-rc1 was
> > released. However it is still time for a fix, I will submit it.
> > As I explained in the other email when I applied this I really though
> > that the driver part will be applied, I don't know what happened here.
> >
>
> Sure, looking at the thread it looks more of a communication issue. I
> am also surprised the breakage went unnoticed for a while (unless
> everyone is using edk2, like myself :) ). I think it would be good to
> revert the change on top of v5.11.x. The drivers adoption would have to
> land before v5.12 though, so that not to repeat the problem during next release.
>
> Small rant:
> A general issue with the DT binding changes of this kind (previously
> clocks, ICU, etc.) that I have, is a side effect of incompatibility
> with older kernels/other OSs. The latter must follow the
> modifications, but you can forget of booting e.g. Debian Buster with
> the ToT device tree. Therefore in edk2 I do not update the device tree
> fork to often and need to tweak it in order to have the widest support
> coverage.
Unfortunately, this has been the case for this machine since it became
available. I can happily boot any kernel on other systems of the same
vintage without touching anything firmware related, which is crucial
to identify regressions.
The A8k requires instead a per-kernel DT, something that only works if
you treat it as an embedded system, and not a standard system (which
is why mine has been collecting dust for some time now). I don't think
the maintainers have ever been interested in solving this problem.
As for ACPI, that'd probably be the best thing that can happen to this
platform. Not sure that's remotely possible though, given how
"interesting" the HW is.
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list