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

From: Marcin Wojtas <redacted>
Date: Fri, 19 Mar 2021 10:48:08 +0100

Hi Marc,

pt., 19 mar 2021 o 10:33 Marc Zyngier [off-list ref] napisał(a):

quoted

On Fri, 19 Mar 2021 08:08:34 +0000,
Marcin Wojtas [off-list ref] wrote:

quoted

HI Gregory,

pt., 19 mar 2021 o 08:35 Gregory CLEMENT [off-list ref]
napisał(a):

quoted

Hello Marcin,

quoted

[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.

ACPI has been up and running for this platform for a couple of years
now, on MacchiatoBin you get USB, SATA, network ports, PCIE and even
SD/MMC (the latter was merged in v5.11 kernel).

Unfortunately ACPI doesn't describe how the SFP cages are connected.

As soon as GPIOs and I2C busses are involved device trees are so much
better than ACPI, and I wouldn't really be interested in adding the
necessary OS support the network ports with ACPI in OpenBSD.

Cheers,

Mark

Unfortunately ACPI doesn't describe how the SFP cages are connected.

Nor MDIO busses and Ethernet PHYs.

ACPI is missing a lot of support for basic elements of networking. I
guess this is because it expects firmware in the NIC to be controlling
these parts, not Linux.

As soon as GPIOs and I2C busses are involved device trees are so much
better than ACPI

Yes, ACPI has along way to go before it is usable for SoCs with
integrated Ethernet.

	   Andrew

Hi Andrew,

pt., 19 mar 2021 o 21:53 Andrew Lunn [off-list ref] napisał(a):

quoted

Unfortunately ACPI doesn't describe how the SFP cages are connected.

Nor MDIO busses and Ethernet PHYs.

ACPI is missing a lot of support for basic elements of networking. I
guess this is because it expects firmware in the NIC to be controlling
these parts, not Linux.

quoted

As soon as GPIOs and I2C busses are involved device trees are so much
better than ACPI

Yes, ACPI has along way to go before it is usable for SoCs with
integrated Ethernet.

I agree, however hopefully the MDIO + ACPI patchset, that currently
seems to be pretty advanced on the lists, will land - it will be a big
step forward and open a path for full SFP support. However, my point
is, that in case of MacchiatoBin, I prefer to use a bit limited link
IRQs, just for having a guarantee to boot each Linux kernel with mvpp2
starting from v4.16 until today and being sure to install various
distros/OSs/ESXI. For DT one have to find a matching version, that
luckily won't break the boot.

Of course the DT is more flexible and offers huge possibilities (e.g.
DSA), but the way it's been done, inherited straight from armv7
embedded-hacking times is imo a burden. Unstable, constantly changing
ABI, extending drivers rather than describe HW is too often a problem.
This patchset is a bright example that there is a field for
improvement.

In my ideal world DT should be properly designed (vendors+community),
out of Linux tree, reviewed by maintainers from different projects,
backward compatible and ensuring proper information/heads-up when
planning to do a meaningful change. I know how it looks and I'm aware
it is hard, but we should at least try :)

Best regards,
Marcin

I agree, however hopefully the MDIO + ACPI patchset, that currently
seems to be pretty advanced on the lists, will land

Well, it has not yet addressed the standing NACK. Which is why no
networking people are reviewing it. We will have to wait and see if
they can do what it needed to clear the NACK.

     Andrew