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.

Anyone interested?
Opinions, comments?

I encountered a technical problem trying to replace the printf with KASSERT.
bus.h does not include systm.h and there are multiple places where bus.h is included before systm.h (or systm.h not included at all).
I am not looking forward to hear from Bruce Evans about yet another namespace pollution, but I am not sure what would be the best here.
Some options:

rebase to the recent head

I would check the chunksize at the beginning of the function and pick a new random value if the current value is less than SPA_MINBLOCKSIZE * 2.
There could also be a comment explaining why that is done.
Adding four individual checks rather than a single one seems to be suboptimal.

Sorry, I myself went missing for a long while.
Yes, I can commit this change.