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. > 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. johannes
