Re: [PATCH] arm64: dts: mt7622: fix switch probe on bananapi-r64

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

 



Il 11/06/24 14:56, Arınç ÜNAL ha scritto:
On 11/06/2024 15:28, AngeloGioacchino Del Regno wrote:
Il 11/06/24 13:38, Arınç ÜNAL ha scritto:
On 11/06/2024 14:30, Thorsten Leemhuis wrote:
On 07.06.24 16:15, Thorsten Leemhuis wrote:
On 07.06.24 16:03, Paolo Abeni wrote:
On Thu, 2024-06-06 at 10:26 +0200, Thorsten Leemhuis wrote:
On 31.05.24 08:10, Arınç ÜNAL wrote:
On 31/05/2024 08.40, Thorsten Leemhuis wrote:
[adding Paolo, who committed the culprit]

/me slowly wonders if the culprit should be reverted for now (see below)
and should be reapplied later together with the matching changes from
Arınç ÜNAL.

FWIS I think a revert should be avoided, given that a fix is available
and nicely small.

Yeah, on one hand I agree; but on the other it seems that the
maintainers that would have to take care of the dt changes to fix this
until now remained silent in this thread, apart from Rob who sent the
mail regarding the warnings.

I put those maintainers in the To: field of this mail, maybe that might
lead to some reaction.

Still no reply from the DRS folks or any other progress I noticed. Guess
that means I will soon have no other choice than to get Linus involved,
as this looks stuck. :-( #sigh

Does it have to be Linus that needs to apply "[PATCH 0/2] Set PHY address
of MT7531 switch to 0x1f on MediaTek arm64 boards"? Aren't there any other
ARM maintainers that can apply the fix to their tree?

Arınç

You have feedback from two people on the series that you mentioned, and noone
is going to apply something that needs to be fixed.

I'm giving you the possibility of addressing the comments in your patch, but
I don't want to see any mention of the driver previously ignoring this or that
as this is irrelevant for a hardware description. Devicetree only describes HW.

Adding up, in commit 868ff5f4944a ("net: dsa: mt7530-mdio: read PHY address of switch from device tree"),
you have created a regression.

Regressions should be fixed - as in - if the driver did work before with the old
devicetrees, it shall still work. You can't break ABI. Any changes that you do
to your driver must not break functionality with old devicetrees.

So...

------> Fix the driver that you broke <------

The device tree ABI before the change on the driver:

The reg value represents the PHY address of the switch.

The device tree ABI after the change on the driver:

The reg value represents the PHY address of the switch.

I see no device tree ABI breakage. What I see instead is the driver
starting enforcing the device tree ABI. No change had been made on the
device tree ABI so any non-Linux driver that controls this switch continues
to work.

These old device tree source files in question did not abide by the device
tree ABI in the first place, which is why they don't work anymore as the
Linux driver now enforces the ABI. Device tree source files not conforming
to the ABI is not something to maintain but to fix. The patch series that
fixes them are already submitted.

As I said, the devicetree MUST describe the hardware correctly, and on that I do
agree, and I, again, said that I want to take the devicetree fix.

However, the driver regressed, and this broke functionality with old device trees.
Old device trees might have been wrong (and they are, yes), but functionality was
there and the switch was working.

I repeat, driver changes MUST be retro-compatible with older device trees, and your
driver changes ARE NOT; otherwise, this wouldn't be called *regression*.

Again, please fix the driver to be retro-compatible with old device trees.

Regards,
Angelo





[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