Multiple radios/single phy - should the wiphy struct radios[] be set?

[Adam Hill]

Thanks for the reply, Jeff. As it happens, I AM building a mobile
access point, but that's not really relevant. My assertion was simply
that since the WCN6856 et al do indeed have two radios ( they must, to
allow them to transmit on two frequencies simultaneously? ) but
presented on a single phy, then maybe they should populate the radios
array accordingly. However, if you're saying that the ONLY reason for
that array is WiFi 7 multilink then that's fine, I'll continue to use
the fact that num_channels is 2 on one of the presented combinations
to detect the additional radio - I now have my build supporting the
two radios of the WCN6856 and happily running an AP on two bands
simultaneously - it just seemed sensible to me that if there were two
radios then they should be presented in some sensible/consistent way
across devices and the radios array was it - but if you disagree then
that's fine... you know an order of magnitude more about this stuff
than I do!

As for the QCN9074, my requirement was for a DBDC capable AP card in
M2 E Key 2230 format - I'm not sure that chip suits the requirement?


On Mon, 27 Apr 2026 at 17:11, Adam Hill <sidepipeuk at gmail.com> wrote:
>
> Thanks for the reply, Jeff. As it happens, I AM building a mobile access point, but that's not really relevant. My assertion was simply that since the WCN6856 et al do indeed have two radios ( they must, to allow them to transmit on two frequencies simultaneously? ) but presented on a single phy, then maybe they should populate the radios array accordingly. However, if you're saying that the ONLY reason for that array is WiFi 7 multilink then that's fine, I'll continue to use the fact that num_channels is 2 on one of the presented combinations to detect the additional radio - I now have my build supporting the two radios of the WCN6856 and happily running an AP on two bands simultaneously - it just seemed sensible to me that if there were two radios then they should be presented in some sensible/consistent way across devices and the radios array was it - but if you disagree then that's fine... you know an order of magnitude more about this stuff than I do!
>
> As for the QCN9074, my requirement was for a DBDC capable AP card in M2 E Key 2230 format - I'm not sure that chip suits the requirement?
>
>
> On Mon, 27 Apr 2026 at 15:53, Jeff Johnson <jeff.johnson at oss.qualcomm.com> wrote:
>>
>> On 4/21/2026 6:35 AM, Adam Hill wrote:
>> > I've been trying to get a WCN6856 card working as an AP on OpenWrt (
>> > but using a custom kernel and build ) and was hitting a brick wall
>> > getting DBDC to work. I was starting from almost zero knowledge of
>> > Linux WiFi in general which made it harder ( and means I might be
>> > barking up the wrong tree ) - however, it seems that OpenWrt ( at
>> > least ) relies on netlink returning a radio array to detect devices
>> > that have multiple radios on a single phy, which doesn't seem
>> > unreasonable to me.
>> >
>> > I've hacked my OpenWrt build to assume that num_channels = 2 on a
>> > second interface combination is the same thing ( which is what ath11k
>> > seems to do when support_dual_stations is true) and confirmed that the
>> > DBDC setup works with this mod. Shouldn't the ath11k driver be changed
>> > to populate the radio list the same way ath12k does? What I've done
>> > with OpenWrt is a bit of a hack, and who knows what else relies on
>> > radios being defined!
>>
>> The radio array exists to support Wi-Fi 7 Multi-link operation, and since
>> ath11k doesn't support Wi-Fi 7, it should not populate the radio array.
>>
>> Also note the WCN series of devices are tailored for mobile station usage, and
>> the firmware and driver are designed to model the hardware as a single
>> multi-band radio that is capable of concurrent operation on multiple channels.
>>
>> If you want to work with OpenWrt then I suggest working with a chipset already
>> supported by it such as QCN9074.
>>
>> I'll let Baochen add any additional observations.
>>
>> /jeff