On 4/10/24 08:42, Johannes Berg wrote:
On Wed, 2024-04-10 at 07:37 -0700, Ben Greear wrote:
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?
Correct.
For dual and tri-concurrent radios, I think we will need them to look like 3 individual radios for non-MLO use
cases
No, I don't see why, and if you want that we wouldn't support it anyway,
you'd have to have a module option or something to decide which way to
go.
But it really ought to not be needed - the point of these patches is to
give userspace enough information to know how to (and where) to create
separate BSSes, with or without MLO between them.
If phy0 told user-space that phy1 and phy2 were 'mlo peers', and phy1 and phy2
gave similar mapping, couldn't user-space just notice the peer group and then
have all the info it needed without the bulk of the patch set in question?
So then if hostapd wants to have 3 radios in an mlo grouping, it can do so.
And if instead it wants three old-style wifi-6 AP interfaces, it could do that
as well. I don't see why it would need any module option, and I also do not
see why it could not do both behaviours concurrently (one BSSID being MLO, second one
being non MLO, for instance).
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
Yes.
(while also concurrently being able to act as individual
wiphys so that one can do a mix of MLO and non MLO sta/AP.)
No.
How will you allow all three bands/phys to host bssids that can talk to
wifi-6 and earlier stations if there is only a single phy seen by hostapd?
I definitely want to put STA vdevs on the three individual 7996 phys and have them
be able to talk to non MLO APs. This currently works.
I suspect other use cases, such as meshing with non MLO APs may also want
this sort of ability.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
