In D21660#472250, @sef wrote:

That's why you can request different numbers. If you want.

So, maybe you'd better debug and fix that problem.
Or add a sleep instead of additional sync-s. And how do you know that 3 will always be enough?
Or maybe the problem was with concurrent writes somewhere else and in some cases even a million sync-s would not be enough...

In D21660#472237, @sef wrote:

Because I was making changes that happened in zfs on sync 8-). I was using multiple syncs to ensure everything did get synced out, and then examining status and structures. (And depending on timing, not everything did get synced out on the first one.)

I think that a need for sync ; sync ; sync is greatly exaggerated.
If you think that it's useful and sync 3 would be an improvement, then could you please explain why?
And without referring to "old wives' tales" :-)

Looks good to me.

A couple more nits.

If this driver just provides a single sysctl, then I think that it would be simpler to add that sysctl to acpi_wmi.
Do you plan to have any other functionality in acpi_wmi_bmof?

At least userland builds (not sure about kernels yet) on 32-bit platforms are broken because of missing atomic_swap_64.

In D21236#461601, @jhb wrote:

I think you did an svn merge or the like that set a crap ton of properties on lots of subdirectories? The affected files list from the original e-mail seemed to start off by listing every single directory in the source tree.

I am not sure what happened. Looks like arc or phabricator went a little bit nuts.

I agree.
Thank you!

I did not add the default case, because I wanted a compiler to let me know when I forget to add a new type to that switch.
It sucks that the gcc does not realize that the code after the switch is not reachable.
But I guess that we have to please it.

oops, forgot to update the header file

clean up

• add "gpio" child type
• add Nuvoton devices that are supported by nctgpio driver
• change how Nuvoton device IDs are matched as for some higher bits of revision ID register are actually a part of a device ID
• account for the fact that Nuvoton SuperIOs use multiple bits in the Device Enable register
• change how known devices are defined
• move child's "type" from the location string to the pnp string, suggested by jhb

rebase

In D8175#449725, @jhb wrote:

So I looked this over and I think the general approach is ok. I would probably prefer either 2) or 3) as I think that is simpler than 1). acpi_perf for 1) ends up being problematic. My only question about 3) is what kind of ivars would you provide that other drivers would bid on? If there aren't good ones, then named drivers ala 2) is probably simpler to work with. If the layout is fixed for each chip you could perhaps have an ivar that is an enum of functions (GPIO, watchdog, etc.) and use that for 3) instead of names I guess. If there is some kind of decent ivar that makes sense for differentiating devices, then I'd be fine with 3) over 2) I think.

That's a good point, Warner.
Thanks!

In D20458#447325, @cem wrote:

We could create a _systm.h which can be included from bus.h without quite as much as pollution as all of systm.h. It's still some pollution but not as severe. I've wanted systm.h stuff in headers before.

We could instead just require systm.h be included at the top, like param.h. This option is not super appealing to me.

Whatever is needed from systm.h could be moved to another header? This probably breaks some consumers, but not all.