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