I'd kinda hoped this would have had the timestamp issues I raised before the commit taken care of.
It's likely best resolved at this point with a sysctl that just sets the time, at a minimum to cover the gap.

ah ok it's for lining up logs between host and target. Sounds good.

nice catch! thanks!

This is pure hack, imho. The ACPI mux, buses and their devices must be enumerated in exactly the same way as in the FDT case.

@mmel and @wulf hey, this stack looks .. interesting to go and dig into as part of some other upcoming work. Would you mind taking a quick look at it and see what you think?
Thanks!

Reworked along the lines @bz asked for, and split into a stack so each piece can
be read on its own. This revision is now only the consumer -- the SIOCGI2C
handler -- and the tunables are gone.

In D59997#1377731, @adrian wrote:

Does the specification actually talk about what it uses it for? And can you change it during normal operation?

eg, what if the time it got was plainly wrong (not that there's no RTC, but the RTC is very very wrong) and it takes an ntpdate/ntpd trip to get it up to date.
What should the driver / controller do in this instance?

Does the specification actually talk about what it uses it for? And can you change it during normal operation?

In D59631#1377509, @ngie wrote:

@seuros : I won't be able to provide a ship-it this weekend, but could you please provide the spec link for this and other related items in the future so @adrian and I can help provide you quicker ship-its?

(to be fair I have the attention span of Doug from Up and the short-term memory of a Dory from Finding Nemo: having the info helps future me track down what I was thinking if I need to look it up later :)..)

Do we support (or have plans to support) NVMe over thunderbolt or lower bandwidth USB? If so, I can see that being a future potential problem (even for platforms that lack PCI support).

@seuros : I won't be able to provide a ship-it this weekend, but could you please provide the spec link for this and other related items in the future so @adrian and I can help provide you quicker ship-its?

One quick ask: please allow this support to be disabled via a kernel sysctl/tunable. While I don't suspect this will be the bulk majority of hosts/users, having something to turn off if it turns out is completely broken on a platform would be helpful to avoid the case mentioned by @imp on non-supporting platforms. Even having this compilable out (but enabled by default) might be a good idea (hint to @seuros, just in case: this requires adding some build glue to sys/conf to use opt_ headers).

In D59997#1377348, @imp wrote:

In D59997#1377343, @seuros wrote:

In D59997#1377152, @imp wrote:

This looks good, but wondering how well we know time at mountroot(). For most platforms likely "pretty good" but there's some w/o rtc that could support nvme drives that might end up setting the wrong time. Is that acceptable here?

I tested this on AMD64 only for now, i will try this weekend on ARM(apple), then on RPI5.

Right now i'm just trying to understand the NVME v2.4 and implement what i can test here.
risky changes are postponed and Edge cases are welcome to know.

Are you aware of any platform without RTC ?

IIRC, some RPi models, though I don't know if it's the PCI-capable ones or not. Some of the rockchip boards. At least some of these don't have ToD RTC that survive reboot and/or power cycle.

In D59997#1377349, @seuros wrote:

IIRC, some RPi models, though I don't know if it's the PCI-capable ones or not. Some of the rockchip boards. At least some of these don't have ToD RTC that survive reboot and/or power cycle.

i will check with @martinfilla_post.cz and @adrian before landing this one.

IIRC, some RPi models, though I don't know if it's the PCI-capable ones or not. Some of the rockchip boards. At least some of these don't have ToD RTC that survive reboot and/or power cycle.

In D59997#1377343, @seuros wrote:

In D59997#1377152, @imp wrote:

This looks good, but wondering how well we know time at mountroot(). For most platforms likely "pretty good" but there's some w/o rtc that could support nvme drives that might end up setting the wrong time. Is that acceptable here?

I tested this on AMD64 only for now, i will try this weekend on ARM(apple), then on RPI5.

Right now i'm just trying to understand the NVME v2.4 and implement what i can test here.
risky changes are postponed and Edge cases are welcome to know.

Are you aware of any platform without RTC ?

In D59997#1377152, @imp wrote:

This looks good, but wondering how well we know time at mountroot(). For most platforms likely "pretty good" but there's some w/o rtc that could support nvme drives that might end up setting the wrong time. Is that acceptable here?

This is OK, but contingent on the followup.

In D59596#1377096, @olce wrote:

Ping? If you need more info or more generally some help from me, don't hesitate to say so.

This looks good, but wondering how well we know time at mountroot(). For most platforms likely "pretty good" but there's some w/o rtc that could support nvme drives that might end up setting the wrong time. Is that acceptable here?

Ping? If you need more info or more generally some help from me, don't hesitate to say so.

This diff implement it , the watchdog change is already here.