bjonglez:

As far as I can tell, the MiWiFi Mini has a single LED with different colours, and the red colour is used as power indicator while the other colours are unused.

So, there's no LED to configure: what kind of configuration do you expect?

psyborg55:

i've opened and checked there are 3 LEDs. as far as i remember with some openwrt builds there was at least one status LED profile

mkresin:

I don't seen an issue here either.

The MiWiFi Mini has either one RGB LED or three different coloured status LEDs. The red status LED should blink during boot.

Hence the yellow and blue status LEDs do not have a default function, they are not listed at the mentioned LuCI page.

I wasn't able to find any kind of manual for the MiWiFi Mini to get an idea for which purpose the LEDs are used by the stock firmware.

mkresin:

Took me some time to get what psyborg55 is talking about.

According to [[https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ramips/base-files/etc/board.d/01_leds;hb=6e283cdc0da25928f8148805ebef7f8f2b769ee8#l249|01_leds]], the miwifi-mini:red:status should be added as default configured LED. It still doesn't make any sense to do so, but if it doesn't work there is something wrong.

So far I wasn't able to see why the LED isn't added.

psyborg55:

of course it makes sense. what would you do, set blue as default?!?

good you figured out finally there is something wrong

mkresin:

of course it makes sense.

No it doesn't. Please explain why it does make sense to you. I'm sick of crystalball reading. All the time you are claiming something without any prove or even an explanation.

The red LED is handled already by the diag script. As long as the polarity (ACTIVE_HIGH/ACTIVE_LOW) is correct, the LED is set to "on" if the boot finishes. Means, enabling the very same LED once more via 01_leds is a no op.

I rather suspect that the LED GPIOs are GPIO_ACTIVE_HIGH instead of GPIO_ACTIVE_LOW and the 01_leds config is meant to disable the LED after boot.

Personally I don't like such approach and would use the blue LED for boot status indication and as "boot finished" signal. But since I don't know how it is handled by the stock firmware (and maybe expected by people familiar with the stock firmware), I refrain from saying it is right/wrong the way it is done.

what would you do, set blue as default?!?

I do not intend to do anything. All I'm interested in is why the led isn't added to the default config as it should be. As I already said, I fail to see - just by looking at the code - why it doesn't happen and I do not have the hardware to do some runtime tests.

good you figured out finally there is something wrong

Being rude to someone and expecting that the same person fixes the bugs one does encounter might not work as expected...

psyborg55:

goddamnit kresin, if it's been added as a default config during porting deviced to openwrt it should've preserved that functionality, unless someone at LEDE team is sick of LEDs (that sounds too ironic to be true).

i've noticed this and reported, you really expect me to solve it too?

mkresin:

Please find someone who translates my comment into your native language, your reply seems to me complete out of sync to my comment.

• I've acknowledge that it is a bug and was not removed intentionally
• I've explained why adding the led config as default doesn't make much sense
• I've stated that I do not intend to change the LED used for diagnostic/boot status indication

Regardless of what I'm doing, you can add any LED config you like. I'm just talking about the default LED config.

i've noticed this and reported, you really expect me to solve it too?

Please read my comment again! I said that I had a look at the source, failed to see why it happens and I don't have a device to do further debugging. Nothing more than that.

You might have not noticed it, but neither the LEDE project nor OpenWrt pays any developers. All the work is done voluntary and offered for free. Most of the time we do not even have access to boards which are supported.

I'm sorry to say, but as long as you don't pay a developer, you are not in the position to demand anything. Only who pays is in a position to make rules.

psyborg55:

//neither the LEDE project nor OpenWrt pays any developers//

and when there is 3rd party service that would allow for at least some money compensation, LEDE/OpenWrt admins make sure it is nearly impossible to get that money by making up stories and problems that are hardly related to the original issue: https://www.bountysource.com/issues/32309542-no-connection-on-wlan-in-2-4g

//Most of the time we do not even have access to boards which are supported.//

so you're changing things blindly without verifying what you've done and when something goes wrong blame it on someone else. sorry but this is not how i get issues fixed.

//I'm sorry to say, but as long as you don't pay a developer, you are not in the position to demand anything//

i don't demand anything, i can handle bugs related to devices i use myself. but you are right, if i don't get paid i'm unable to get more devices required to complete support so others can't complain why iLNA or MT7620N chips support sucks when compared to MT7620A eLNA devices.

offtopic done. bye