Bug 254267 - muge(4) LEDs do not work on RPi 3B+ 13.0-RC2 image
Summary: muge(4) LEDs do not work on RPi 3B+ 13.0-RC2 image
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 13.0-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-14 03:18 UTC by Ed Maste
Modified: 2021-07-07 19:36 UTC (History)
1 user (show)

See Also:

Attachments
sysctl -b hw.fdt.dtb | dtc -I dtb -O dts (34.41 KB, text/plain)
2021-03-15 18:41 UTC, Ed Maste 		no flags Details
Excerpt of sdiff -w 166 bcm2710-rpi-3-b-plus.old.dts bcm2710-rpi-3-b-plus.new.dts (6.26 KB, text/plain)
2021-07-07 19:02 UTC, rz-rpi03 		no flags Details
Locate the LED-modes again. (873 bytes, patch)
2021-07-07 19:36 UTC, rz-rpi03 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer freebsd_triage 2021-03-14 03:18:51 UTC 
I tried 13.0-RC2 on a Raspberry Pi 3B+, and observe that the Ethernet LEDs are not functional. It looks like the issue originally addressed in PR237325 has returned.

if_muge.c is at 9dd3156e546b29b1e6c3047578e91b1d098af171 in releng/13.0.

More details to be added after further investigation.
Comment 1 Ed Maste freebsd_committer freebsd_triage 2021-03-14 03:25:02 UTC 
LEDs on external EVB_LAN7800 (w/ eeprom config) are functional.
Comment 2 Ed Maste freebsd_committer freebsd_triage 2021-03-14 17:10:33 UTC 
in muge_set_leds() we see the LED modes should be obtained from
OF_getencprop(node, "microchip,led-modes", modes, sizeof(modes))

I do not see "microchip,led-modes" in ofwdump -a.

Looks like this should come from sys/contrib/device-tree/src/arm/bcm283x-rpi-lan7515.dtsi
Comment 3 Ed Maste freebsd_committer freebsd_triage 2021-03-15 17:14:51 UTC 
Booting into Raspberry Pi OS (kernel 5.10.17-v7+ Mon Feb 22 11:29:51 GMT 2021) I see microchip,led-modes

(From `dtc -I fs -o dts /proc/device-tree/`. That command emitted many warnings though).
Comment 4 Ed Maste freebsd_committer freebsd_triage 2021-03-15 17:34:03 UTC 
microchip,led-modes does appear in `sysctl -b hw.fdt.dtb | dtc -I dtb -O dts` however.
Comment 5 Ed Maste freebsd_committer freebsd_triage 2021-03-15 18:41:27 UTC 
Created attachment 223302 [details]
sysctl -b hw.fdt.dtb | dtc -I dtb -O dts
Comment 6 Ed Maste freebsd_committer freebsd_triage 2021-03-15 18:41:38 UTC 
Setting `sysctl hw.usb.muge.debug=1` and then forcing it to reattach via `usbconfig reset` I see

muge0: debug: MAC assigned from FDT data
muge0: debug: setting mac address to XX:XX:XX:XX:XX:XX
muge0: Chip ID 0x7800 rev 0002
muge0: debug: Initializing PHY.

I would expect "LED modes set from FDT data" after the MAC info in the working case.
Comment 7 rz-rpi03 2021-07-07 19:02:55 UTC 
Created attachment 226287 [details]
Excerpt of sdiff -w 166 bcm2710-rpi-3-b-plus.old.dts bcm2710-rpi-3-b-plus.new.dts
Comment 8 rz-rpi03 2021-07-07 19:36:37 UTC 
Created attachment 226289 [details]
Locate the LED-modes again.

Some time in the past the device node in the dts got a child node and that
child node got a child node as well. See attachment #226287 [details].
The LED-modes property moved into the grandchild of the device node and
the driver was not prepared for this.

I thought about implementing a recursive search for the LED-modes property
but that seems to heavy for a almost static subtree with no peer nodes.
Finally I accessed the grandchild node directly.

This might not be the smartest solution but now the LEDs are working again.

Ralf