On 4/10/24 00:56, Johannes Berg wrote:
On Fri, 2024-03-29 at 07:47 -0700, Ben Greear wrote:
On 3/29/24 07:30, Johannes Berg wrote:
On Fri, 2024-03-29 at 19:41 +0530, Vasanthakumar Thiagarajan wrote:
+ * @hw_chans: list of the channels supported by every constituent underlying
+ * hardware. Drivers abstracting multiple discrete hardware (radio) under
+ * one wiphy can advertise the list of channels supported by each physical
+ * hardware in this list. Underlying hardware specific channel list can be
+ * used while describing interface combination for each of them.
I'd expect there to be a limit on channels being within a single band on
a single "hardware"?
There are ath12k hardware supporting multiple band which need to be
registered under one mac80211_hw/wiphy. This design is to support such
hardware.
Oh OK, that was something that I didn't have in mind any more, or never
knew or paid attention to.
Would it work to leave the phy reporting pretty much as it is now, but add
a 'associated_peer_radios' list section, so that each phy could report the phys
associated with it? Then user-space, driver, mac80211 etc could look up the
other phys as needed to get a full picture?
There's not really a good way to _do_ that short of creating multiple
wiphys, but that causes _massive_ complexity in the stack (both cfg80211
and mac80211) so we rejected it years ago.
I thought the problem ath12k is trying to fix is that there are currently multiple phys (radios) that needed to be made to
look like a single phy?
For dual and tri-concurrent radios, I think we will need them to look like 3 individual radios for non-MLO use
cases, but I guess there will be also some way to treat them as a single entity when using MLO.
For instance, mt7996 currently reports 3 single-band wiphys, and each can be used independently.
But assuming it starts supporting MLO, then those 3 single band wiphys will need to start acting
at least somewhat like a single entity (while also concurrently being able to act as individual
wiphys so that one can do a mix of MLO and non MLO sta/AP.)
Maybe I'm missing the entire point of the ath12k patches though...
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
