Fixed typo in comment.

Changed iiccopyinmsgs32 to iic_copyinmsgs32, per suggested comments

Addressed comments from jhb

Looks good, verified with the board where we had seen the issue.

Updated to current "main" branch and removed $FreeBSD$ lines

In D42025#967445, @kib wrote:

You also need to rename the vars in the summary.

Updated the review summary from the commit log

Updated environment variable to match the variables used internally.
Instead of OPTIONAL_STATIC_TLS, the name is now STATIC_TLS_EXTRA.
Updated the man page also.

Made changes per review comments.

I should also note that we currently have at least one case of this in our source tree currently, which is what prompted the change. It compiles fine with "c99", but does not with "gnu99".
It's going to take some time for the code to be able to be changed to address the issues.

In D42019#958440, @jrtc27 wrote:

In D42019#958439, @sjg wrote:

In D42019#958437, @jrtc27 wrote:

Given conf generates one big Makefile for the entire kernel, and thus CSTD is global for everything compiled into the kernel, I'm unsure how sensible this really is

As already noted, this makefile is used by kernel modules too.
The makefile generated by config(8) is not relevant.

Yes, but typically modules can also be compiled into the kernel, where you need to use -std= explicitly. I don't object to it going in, I just don't see it being all that useful.

In D42019#958400, @imp wrote:

I've been running with this set to c11....

What do you want to set higher? And what do people think about just inching this up across the board.

Looks good

In D41674#954474, @imp wrote:

This seems fine.

This was committed as rG332af8c25dfc9857e997817281d7b7fa406783ef

Updated to use SIZEOF_LONG check instead of LP64

Updated according to suggestions by Andrew

In D41429#944544, @andrew wrote:

It looks like IS_DMA_32B came from when the generic_xhci.c was added as a Marvell specific driver. It looks like it should only be 1 on 32-bit platforms.

Fix typo in the compatible string

In D41429#943512, @andrew wrote:

How does Linux handle this? I see the brcm,generic-xchi compat string in u-boot, but not Linux.

In D41207#938522, @kib wrote:

In D41207#938511, @mjg wrote:

is this really of practical usage today? i was considering removing these printfs to begin with

I agree, better to remove it.

In D39768#906366, @glebius wrote:

What's the point of so_checkfiballowed? Can't find it being called. If we bring the processing SO_SETFIB down to protocols, then all protocols that aren't inetsw, inet6sw or routesw will return error just automagically. Where can we need so_checkfiballowed?