This is a showstopper for Snapdragon Elite support.

This is a showstopper for Snapdragon Elite support...

git diff -U999999

The loop needs about 1000 iterations before the screen is obviously slower.

I'm fine with this now.

As the original author of the watchdog interfaces, I have no objections to this change, but I have not reviewed the diff.

This works on my T14s G6 Snapdragon machine. (when used together with other necessary changes)

For reference: madt_data->dist->Version is 4

I'm fine with this.

and fdcontrol(1)

dont forget fdwrite(1)

I'm all for this, and yes, in 14 please.

IMO the current text does a really bad job at communicating that.

So if I understand your position, what we are trying to say is:

So which is it ?

I think this is OK.

I personally find cp(1) far too important to let it fail sporadically.

I'm not at all familiar with (g)vinum code, but I fear the message may be very spammy (once per drive?) where you put it.

In D36857#836796, @markmi_dsl-only.net wrote:

No protests from here.

I am not able to review this patch, sorry.

Re task queues: One of the ways to drive musicians right up the wall, is to have a LED flashing erratically, but not randomly. (See also: "Vetinari Clock") I think that counts against the task-queues here.

I think no matter what we agree here, people will probably take notice once the commit goes in, so it may be one of those cases where starting the party pre-commit in arch@ is warranted ?

I can see the point, but I cringe at the thought of adding a kthread to just to blink LEDs...

looks good to me

looks OK to me.

no comments from me.

no comments

I still think we should switch the profiled libraries to support gcov instead of statistical profiling, but I'm fine with not building them by default.

Ok with me.

I'm fine with the two new features proposed individually.

I agree that the resume behaviour should fix uptime rather than boottime. (S/R also broke on my T480 these days).

The reason I specifically said "set" or "stepped" instead of "adjusted" is that continous adjustments, ie: frequency changes, do not cause recalculation of the estimated boot time.

Is 'stepped' is a better word ?

I would go with:

Many years ago, we're talking 386BSD/FreeBSD1 days, I made a patch where you could set any damn rate you wanted, and the math would happen.

I would probably just have added the flags argument to disk_alloc()...