Re: [PATCH v3 0/9] Armada8k enable per-port SATA interrupts and drop a hack in the IRQ subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 19 Mar 2021 08:08:34 +0000,
Marcin Wojtas <mw@xxxxxxxxxxxx> wrote:
> 
> HI Gregory,
> 
> pt., 19 mar 2021 o 08:35 Gregory CLEMENT <gregory.clement@xxxxxxxxxxx>
> 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.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux