ping

ping

Add #error if the compiler doesn't have the required builtin.

Only add the macros if the compiler have the builtin.
Old compiler aren't supported.

In D25015#550743, @hselasky wrote:

Should there be an ifdef for LINT builds?

In D24917#550057, @greg_unrelenting.technology wrote:

Looks like this needs to wait until there's some way to get the clock without devicetree (I guess Linux runs with fdt+acpi both to make it work..)

In D24962#549612, @cem wrote:

Hm, libc version is (or was) a separate file with a different copyright. Usual pattern in libkern is to just copy the libc files to libkern verbatim and only fixup as needed to compile. I don't know that we always have to do that, but we should at least confirm the arc4random_uniform copyright follows the code.

Just go with NXP_LS, if there is any problem later we'll handle it at this moment.

In D24352#549462, @mmel wrote:

The LS family has too many members and can share 99% of the code. It seems unnecessary for me to have the option for each individual variant. How about 'SOC_NXP_LS' ?

In D24798#547428, @hselasky wrote:

It is fine.

In D24859#547442, @hselasky wrote:

Don't forget to add LinuxKPI to the commit message and MFC after.

I think that the expedited funcs do more than a simple sync but I'm not able to tell what for now ...
What do you think about this @hselasky ?

LGTM

Would you mind moving this driver to a gpio subdirectory (sys/dev/iicbus/gpio) ?
We've been talking with @ian and @imp doing that for existing drivers.
Otherwise LGTM.

Would you mind moving the driver to a rtc subdirectory (sys/dev/iicbus/rtc/) ?
We've been talking with @ian and @imp about doing that for existing drivers.
Otherwise looks good to me.

You forgot to add it in sysutils/Makefie.
Otherwise it looks good.

In D24696#543761, @hselasky wrote:

Please also add "LinuxKPI" somewhere in the commit message.

In D24696#543758, @hselasky wrote:

Assuming the API is only used during PCI enumeration.

Don't forget to MFC!

Add free region

In D24653#543367, @avg wrote:

Yeah, I think that it is better to use _BQC whenever it is actually provided because there can be multiple ways to control the brightness.
The more I look into this the more quirks I discover.
Some systems handle brightness keys completely in firmware, some post ACPI events, some post custom events via WMI.
On some systems _BCM actually changes the brightness (it's handled by the firmware); on some systems _BCM is just another level of indirection -- it just posts more events to be handled elsewhere (e.g., via ATIF with AMD's video).
I think that Linux drifts towards converting brightness events to evdev brightness key events and then letting the userland handle those keys. The actual brightness controls are exposed as sysfs backlight nodes and they cab be hooked to ACPI video (_BCM) or directly to graphics drivers or something vendor specific, etc.

So, I wanted to be very conservative with my change and just let acpi_video work (as best as it can) on my system.

In D24653#542928, @manu wrote:

Maybe it would be more clean to request the current level with _BCQ at attach and never deal with the method after, only the cached value ?
I don't see why we would want to call this method over using the cache value after boot.
Otherwise looks good to me.
I think that the _DCS/_DGS fix could be done in another commit though.

Maybe it would be more clean to request the current level with _BCQ at attach and never deal with the method after, only the cached value ?
I don't see why we would want to call this method over using the cache value after boot.
Otherwise looks good to me.
I think that the _DCS/_DGS fix could be done in another commit though.

There is no clock enabling here but the dtsi have a clock property.

It's a bit hard to review without knowing the clock topology, is that something that you can share or can you describe it a bit ?
From what I understand of the code there is N pll based on the number of divider ?
Does all those PLLs really exists ?