@wulf , I considered that well. But if we use a dedicate taskqueue then it means having a thread anyway. And I didnd't want to put potentially slow LED operations on one of the global taskqueues.

@adrian , in my opinion two things guarantee correct operation:

• the current element can never be removed (thanks to in_use)
• an iteration is always done with the lock held

So, whatever perturbations might happen while the lock is dropped, they should settle down before the next iteration.

@adrian , I thought that I took care of that via the in_use flag.
Could you please look again?

Yeah, me too... but doing it directly from a callout puts a lot of restrictions.
I considered creating and destroying the thread dynamically as "blinkers" are added and removed.
I can implement that if you think it would be better than having the thread permanently.

Tested this with D30787 where LEDs are controlled via I²C and had no issues with turning the LEDs on / off and making then blink in various combinations and sequences.
No crashes, no LORs, no WITNESS warnings.

I cannot think of any way.
rk_i2c needs to sleep to wait for an interrupt.
led(8) uses a non-sleepable mutex.

address reviews for rk805 poweroff support

The only reason is that I thought that I could do some things better but never got around to actually working on them.
Specifically, I don't like having so many walk+callback patterns. Especially for _DSD.
I hoped that I would be able to represent it as an nvlist or something similar.

@mm , do you have amdgpio driver? Has it attached?

@kibab , you still may want to fix this pseudo-loop: https://github.com/kibab/freebsd/blob/mmccam-current/sys/cam/mmc/mmc_da.c#L1638
Maybe the last 'else' was supposed to be 'else if' ?

I think that I needed that patch because earlier I had a lot of bits from https://github.com/kibab/freebsd/tree/mmccam-current in my tree and now I don't.
Specifically, @kibab's mmc_set_timing supports a lot more timings and so on.

And in fact, it seems that I do not need that change anymore.

In D29758#667600, @manu wrote:

For the 1.2V report it's probably the same problem as the one fixed by 1a96c1434f4b4487126f13ede29e67ad44a8776a

Yes, most likely.

Is this the information you asked for?

# camcontrol devlist -v       
scbus0 on aw_mmc_sim0 bus 0:
scbus1 on aw_mmc_sim1 bus 0:
<SDIO card>                        at scbus1 target 0 lun 0 (sdiob0,pass1)
scbus2 on aw_mmc_sim2 bus 0:
<MMCHC 8GME4R 0.1 SN 4DAD8E5D MFG 09/200>  at scbus2 target 0 lun 0 (sdda0,pass0)
scbus-1 on xpt0 bus 0:
<>                                 at scbus-1 target -1 lun ffffffff (xpt0)

LGTM. Thank you!

In D24077#530114, @takawata wrote:

fix man page.
Add files.x86 entry to static configuration.

LGTM. Thank you.

LGTM. Thank you!
I did not realize that hardware can be this quirky.

LGTM.

It's been a while since I touched that kind of code, but I think that this change is good.

rebase