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

[Thorsten Leemhuis]

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.

>> On 23.05.24 12:44, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> On 17.05.24 08:27, Frank Wunderlich wrote:
>>>> Am 17. Mai 2024 04:17:47 MESZ schrieb "Arınç ÜNAL"
>>>> <arinc.unal at arinc9.com>:
>>>>> On 16/05/2024 23:48, Frank Wunderlich wrote:
>>>>>> From: Frank Wunderlich <frank-w at public-files.de>
>>>>>>
>>>>>> After commit 868ff5f4944a
>>>>>> ("net: dsa: mt7530-mdio: read PHY address of switch from device
>>>>>> tree")
>>>>>> the mt7531 switch on Bananapi-R64 was not detected.
>>>>>>
>>>>>> mt7530-mdio mdio-bus:00: reset timeout
>>>>>> mt7530-mdio mdio-bus:00: probe with driver mt7530-mdio failed with
>>>>>> error -110
>>>>>>
>>>>>> Fix this by adding phy address in devicetree.
>>
>> Frank, am I right assuming the regression is still present in mainline?
>> As from here it looks like for two weeks now there was no progress at
>> all to fix this (or I missed it, which is quite possible).
>>
>> Makes me wonder if the maintainers should revert the culprit or if the
>> arm64 dts folks should accept your fix despite Arınç ÜNAL's (who from a
>> quick look on lore hasn't posted anything for two weeks now) comment.
> 
> I'm not against the patch. I'm against the logic it entails on the patch
> log.

In that case: can you maybe help Frank with writing something better or
submit something based on this patch to resolve this and make everyone
happy?

> I had already submitted a patch series that would've prevented this
> issue back in 14 March 2024 [1]. I've asked numerous times for the patch
> series to be applied [2][3][4][5].
>> Eventually Daniel asked for some changes [6]. But I won't have time to do
> that anytime soon and I think the patch series is good enough to be applied
> as is.

Then I guess we need some other way to resolve this in mainline to unfix
Frank's device. The two obvious options are afaics:

* revert the culprit (868ff5f4944aa9 ("net: dsa: mt7530-mdio: read PHY
address of switch from device tree")) and reapply it in a later cycle
* apply Frank's patch (or an improved one) in this thread (and if needed
revert it when some better changes emerge.

Arınç ÜNAL, could you please comment on that and ideally handle the
necessary tasks, as it's your patch that causes the regression.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

> [1]
> https://lore.kernel.org/all/20240314-for-mediatek-mt7531-phy-address-v1-0-52f58db01acd@arinc9.com/
> [2]
> https://lore.kernel.org/all/ff196055-ecd8-4563-bc01-ff2533a07109@arinc9.com/
> [3]
> https://lore.kernel.org/all/a60fc16d-4236-427c-b4a8-ec6fdf62d9f0@arinc9.com/
> [4]
> https://lore.kernel.org/all/facb8204-c2b3-4084-a2e3-4fbf3a3fdc9d@arinc9.com/
> [5]
> https://lore.kernel.org/all/44e366ea-964a-4515-9027-2a2edfe12512@arinc9.com/
> [6] https://lore.kernel.org/all/ZixU287DdhvRyZBe@makrotopia.org/
> 
> Arınç
> 
>