| Message ID | 20220720203152.313400-2-tmn505@terefe.re |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [v2,1/3] ath79: mikrotik: stack ar9344 devices to single dtsi | expand |
From: Thibaut VARENE <hacks@slashdirt.org>
Please don't do this.
The rationale has been already explained here:
https://github.com/openwrt/openwrt/pull/10135#pullrequestreview-1020528516
The gist of it is: the power LED alone cannot disambiguate a powered-on
device from a properly operating one. It also breaks "established standard"
on all other mikrotik devices.
T.
W dniu 22.07.2022 o 11:31, Thibaut VARÈNE pisze: > From: Thibaut VARENE <hacks@slashdirt.org> > > Please don't do this. > The rationale has been already explained here: > https://github.com/openwrt/openwrt/pull/10135#pullrequestreview-1020528516 > > The gist of it is: the power LED alone cannot disambiguate a powered-on > device from a properly operating one. It also breaks "established standard" > on all other mikrotik devices. Thanks, for voicing Your opinion, this is exactly why I made it a separate commit. TBF the Power LED is also controlled by GPIO, so it should not be difficult to move the current state display to it and keep the User LED for users to decide what to do with it. But as You reasoned, it was like that from the "beginning" and I agree with it, it's not great to break something that users are used to. I'll drop the patch from patchwork queue. > > T. Regards, Tomek
> Le 25 juil. 2022 à 17:18, Tomasz Maciej Nowak <tmn505@gmail.com> a écrit : > > W dniu 22.07.2022 o 11:31, Thibaut VARÈNE pisze: >> From: Thibaut VARENE <hacks@slashdirt.org> >> >> Please don't do this. >> The rationale has been already explained here: >> https://github.com/openwrt/openwrt/pull/10135#pullrequestreview-1020528516 >> >> The gist of it is: the power LED alone cannot disambiguate a powered-on >> device from a properly operating one. It also breaks "established standard" >> on all other mikrotik devices. > > Thanks, for voicing Your opinion, this is exactly why I made it a separate > commit. TBF the Power LED is also controlled by GPIO, so it should not be > difficult to move the current state display to it and keep the User LED for > users to decide what to do with it. But as You reasoned, it was like that > from the "beginning" and I agree with it, it's not great to break something > that users are used to. I'll drop the patch from patchwork queue. Thanks. Purely FWIW users can still do whatever they want with the User LED once boot is complete. This DTS « led-running » definition does not preclude using the LED like any other LED after boot completes (as a matter of fact I do just that on some of my mikrotik devices :), it simply ensures it becomes solidly lit once the boot process completes providing feedback on the system’s operating state. Asserting the device’s status is unequivocal with this scheme (when used unmodified): - Two green LEDs (Power on + User on): powered and running - One green LED (Power on + User off): powered and not running - No green LED (Power off): not powered Using the Power LED as a replacement for the User LED does not provide unequivocal status report, because for instance to distinguish the first 2 states one would then need to *witness* the full boot sequence to tell apart a « powered » green (solid from power up with no change) from a « running » green (solid power up then boot sequence flashes then solid again). This is IMHO a solid rationale (on top of not breaking « de facto standard ») for this way of doing things. HTH, T.
diff --git a/target/linux/ath79/dts/ar9344_mikrotik_routerboard.dtsi b/target/linux/ath79/dts/ar9344_mikrotik_routerboard.dtsi index 10233e3d4eef..ccb3ea6b5d89 100644 --- a/target/linux/ath79/dts/ar9344_mikrotik_routerboard.dtsi +++ b/target/linux/ath79/dts/ar9344_mikrotik_routerboard.dtsi @@ -9,7 +9,6 @@ aliases { led-boot = &led_user; led-failsafe = &led_user; - led-running = &led_user; led-upgrade = &led_user; };