Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <53612acba151d031f636626db20c1c60db09fdd0.camel@sipsolutions.net>
Subject: Re: [PATCH 10/19] wifi: iwlwifi: limit EHT capabilities based on
 PCIe link speed
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Ben Greear <greearb@candelatech.com>, gregory.greenman@intel.com
Cc:     linux-wireless@vger.kernel.org
Date:   Wed, 21 Jun 2023 13:57:53 +0200
In-Reply-To: <d220c5b6-7c8f-19cd-12d0-ceb484e29e48@candelatech.com>
References: <20230620100405.45117-1-gregory.greenman@intel.com>
         <20230620125813.b77a1574a0a7.Id4120c161fb7df6dedc70d5f3e3829e9117b8cb1@changeid>
         <d220c5b6-7c8f-19cd-12d0-ceb484e29e48@candelatech.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.3 (3.48.3-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

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>
> >=20
> > 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.
> >=20
> > 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.
>=20
> Is there not an advantage to allowing 320Mhz for longer distance connecti=
ons
> where signal is relatively weak, so over-all tput would easily fit in les=
ser
> pcie bus?  Especially on 6E band where the US regdom allows more over-all=
 power
> when using wider bandwidths?
>=20

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.

johannes