Re: [PATCH 10/19] wifi: iwlwifi: limit EHT capabilities based on PCIe link speed

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2023-06-21 at 07:48 -0700, Ben Greear wrote:
> On 6/21/23 4:57 AM, Johannes Berg wrote:
> > On Tue, 2023-06-20 at 06:19 -0700, Ben Greear wrote:
> > > On 6/20/23 3:03 AM, gregory.greenman@intel.com wrote:
> > > > From: Johannes Berg <johannes.berg@intel.com>
> > > > 
> > > > If a discrete NIC is connected to a PCIe link hat isn't at least
> > > > Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
> > > > that from EHT capabilities in that case.
> > > > 
> > > > While at it, also move setting 320 MHz beamformee to the right
> > > > place in the code so it's not set while not supporting 320 MHz.
> > > 
> > > Is there not an advantage to allowing 320Mhz for longer distance connections
> > > where signal is relatively weak, so over-all tput would easily fit in lesser
> > > pcie bus?  Especially on 6E band where the US regdom allows more over-all power
> > > when using wider bandwidths?
> > > 
> > 
> > I actually don't know. This surely isn't ideal, but it's the only way to
> > really force the AP to not send too much than the NIC can pass out, and
> > it gets unhappy if it can't.
> 
> So this is to work around hardware/firmware bug in NIC?  If so, that should
> be mentioned.

I'm not sure that's really even a _bug_, it just doesn't have a lot of
buffer space inside of it; as far as I know, given how the HW
architecture works, the FW doesn't have a lot of options.

> I have heard in the past that higher bandwidth works better than higher NSS
> in a lot of cases, so if HW/FW can be made to deal with floods in unlikely
> case that the RF is perfect enough to saturate the PCI bus, then I think you
> should allow 320Mhz even on slower PCI bus configurations.

Right. I don't think it's likely that the firmware will do, but hey, I
can let them know :)

johannes