Any comments on this?

@emaste it seems most attributes in cdef.h have the __x__ instea dof just x. This seems to work with gcc as well for as much as I could test. It seems up-to gcc14-devel non of our gccs recognizes the counter_by in either spelling.

Does this give any information pciconf -l would not already give? I would rather we'd improve our tooling than use a sysctl for that? I'd almost want something like ifconfig -g bridge -l in devctl or somewhere appropriate?

@emaste is the logic correct now?

I will simply express that this will not only open a can of worms by mixing both but the original reasons not to include VRRPv2/3 and hence the "existence" of CARP is also ignored.
Should people think this can go in, I would highly advise to make it 100% compile time option and there's quite a few things to polish (including quoting from copyrighted material without reference).

add logic for counted_by and also add __nonstring

In D44306#1020417, @jhb wrote:

Oh, if it is just a global symbol that isn't a ton of work to handle. You just need to recognize that symbol name when resolving symbols and resolve the pointer to the right thing instead. Probably what we would want to do is having __this_module store the pointer to the current linker_file_t when you are resolving symbols and require it to be the same size as a pointer.

In D44306#1020400, @jhb wrote:

I do think that GCC and clang (and really ld.bfd and lld) will collapse duplicate copies of the same anonymous string down to the same storage.

However, is insmod equivalent to just kldload and is __this_module only valid during then? If so, you can hang a suitable pointer to the current struct linker_file off of struct thread that gets set during kldload(2) and cleared before it exits (probably a bit further down in linker_load_file or the like). Then you can #define __this_module to something like curthread->td_current_linker_file with a suitable wrapper cast or whatever.

THANK YOU!

At this point I will ask -- has anyone considered checking how much linker work would be needed for this?

@salvadore can I commit this? Anything further to do?

@salvadore can I commit this? Anything further to do?

Got imported along the whole file in https://cgit.FreeBSD.org/src/commit/?id=3208d4ad2b8320a24af4a8293f7fd3ef9c35caa6

In D44587#1018196, @emaste wrote:

From a textcase in the LLVM review that introduced it (https://reviews.llvm.org/D148381):

#if !__has_attribute(counted_by)
#error "has attribute broken"
#endif

#ifdef COUNTED_BY
#define __counted_by(member)    __attribute__((__counted_by__(member)))
#else
#define __counted_by(member)
#endif

In D44587#1016767, @emaste wrote:

In general __has_attribute(foo) to check
I think this is fine to get the driver compiling but ought to have a TODO comment

You made me have a look; grep -r HAVE_EXPLICIT_BZERO seems to be a pattern which reveals a few more implementations in the tree; we should probably make sure if we migrate this into more general code to make sure we set the appropriate #defines for the various kernel code bits to switch to the one common implementation then; I'll leave it for someone who can better drive this at this point.

In D44583#1017689, @emaste wrote:

I don't know if the code path in drm_encoder_slave.c actually uses this

I don't think the change in this review should have any effect - we just go from discarding the returned fileid to not requesting it at all.

I don't know if the code path in drm_encoder_slave.c actually uses this; I hit it in iwlwifi yesterday and still have to investigate but having this run from kldloading a module made the system hang in a way that ^T did not work anymore on the console.

Update with some more

Okay, let's see if it is correct now?

Fix logic from NOP to doing something.

Applied more changes

Address more review comments

Address review comments.

Update to mark the requested changes done.

Address review comments using markup for man pages.

Thank you!
Can we also adjust the comment above MPASS() in the header file?

In D44328#1011038, @adrian wrote:

oh, you have a jupiter card with eeprom, rather than just OTP? ooer. Good catch! I likely only have OTP AR9462s :(

In D44219#1008810, @kib wrote:

Otherwise looks good to me.

In D44020#1009470, @pldrouin_gmail.com wrote:

In D44020#1009469, @bz wrote:

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.

My assumption here is that it is the reset function is not called twice at the same time in parallel from the bus.

What you describe is what I do in the latest version, but it does not work, since without the lock, i2c_get_div_val gets executed before the attach function has the chance to set the variables that are used by i2c_get_div_val. So I need to delay the call to i2c_get_div_val until the attach function completes. Without that I end up with the wrong divider value. Note that this problem seems to only occur at boot time and not if I load the driver as a module after booting.

This may not be based on your latest version but the general idea is: call i2c_update_div_val() before taking the lock, get the div_reg value back (maybe you can avoid passing it as pointer and checking for error by simply checking for sc->freq == UINT32_MAX in the caller (reset function) afterwards to see if you should change anything or not (just came to my mind, haven't checked all code paths). Then do the register writes all together under lock.