I'm hesitant to introduce more sysctls, especially given this is a quite niche thing. Is there a good reason to provide this?

If we keep this, it should be documented in sound(4)'s man page.

Why are we operating on uint64_ts when eventually we'll truncate to uint32_t? I have the same questions about the uint64_t casts below.

Why are we using CHN_2NDBUFMAXSIZE here and not maxsize?

Is there a reason you didn't redefine CHN_2NDBUFMAXSIZE and instead re-introduced a max-max variable?

How was this derived?

You are setting req_maxfrags = maxfrags and then maxfrags = req_maxfrags and req_maxfrags remains unused. Is there a reason we don't use maxfrags only?

I moved this into a helper, it's in the control path so it doesn't seem like something to micro-optimize. It prevents theoretical overflow before division at a high enough channel/bit/kHz.

Intentional, added a block comment to describe that those are hardware buffer sizes unrelated to this change for now. Future work to consider the impact and driver b->maxsize?

Yeah good point. I renamed these

The block comment above now attempts to explain it, to hopefully fit up to this target for the channel/bit/rate config but there are degenerate cases with high enough channel count and pro audio rates. By MADI-class I mean something like this https://www.ferrofish.com/a32pro-converter-multimode

the read size modified req_maxfrags, and the write side needed the original value. I cleaned this up with a helper.

It seems like we are always calling this with c locked. Is this a meaningful check?

Is there a rationale for preserving the historical cap for the primary buffer?

This comment could be removed, or incorporated into CHN_2NDBUFSIZE_MIN, as in, it could just explain why we set it to 131072. It doesn't make much sense anymore to include it like this.

We can simplify this. The check for max < 1 seems redundant. I don't think ch->bufsoft->bufsize can be less than 1.

These 2 ifs can be rewritten as:

RANGE(maxsize, CHN_2NDBUFSIZE_MIN, CHN_2NDBUFSIZE_MAX);

But it's fine if you find the macro ugly and prefer to write it explicitly. :-)

I don't see a scenario where lw is negative; the ioctls will set it to either arg_i if it's larger than 1, or 1 if not. It can also be set in chn_resizebuf() to bs->blksz, which has checks as well. I guess you have the check for robustness, hence why my recommendation used RANGE.