> Would some other piece of the stack could decide to use or not use aggregation for a given band/vif/sta? Maybe just semantics but my thought was the driver returning false makes it seem incapable of it. > I agree about not polluting the module parameters. I'll have a look at the out of tree stuff. Thoughts on debugfs knobs, not necessarily patch specific just in general? > On Sat, Feb 8, 2020, 2:09 AM Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: >> Brian Norris <briannorris@xxxxxxxxxxxx> writes: >>> On Fri, Feb 7, 2020 at 12:48 PM Justin Capella <justincapella@xxxxxxxxx> wrote: >>>> I understand, I'm suggesting disable by default but option to re-enable >>> >>> Ah, OK. Seems reasonable, I suppose, although I don't recall Kalle >>> having a particularly-high opinion of module parameters for tweaking >>> core 802.11 protocol behaviors. >> Yeah, exactly. And the number of module parameters a driver has should >> be minimised. I know out-of-tree vendor drivers have ini files with 100 >> different knobs, but I don't think module parameters should be >> equivalent to ini files. Module parameters are really good for me, too. But we've had discussion before with Kalle and Brian, they both were trying hard to avoid module parameters. So, I think Kalle and Brian don't recommend using module parameters. And I think just disable it on 2.4G is OK, there's no need to enable it for those supported 2x2 devices, unless we are going to support 3x3/4x4 devices. If that happens, we can add conditions for those 3x3/4x4. Yan-Hsuan
