On 4/10/2024 9:23 AM, Ben Greear wrote: > 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, the patches we have posted so far allow ath12k to either have each phy assigned to a separate wiphy (legacy operation) or have multiple phys assigned to a single wiphy (required for MLO operation). In an upcoming patch we'll introduce a DT-driven mechanism to perform the mapping of phys to wiphys. So the goal is to be able to support both modes of operation. /jeff /jeff
