mbox series

[v6,00/12] wifi: ath12k: Add single wiphy suppor

Message ID 20240401190409.2461819-1-quic_ramess@quicinc.com (mailing list archive)
Headers show
Series wifi: ath12k: Add single wiphy suppor | expand

Message

Rameshkumar Sundaram April 1, 2024, 7:03 p.m. UTC
From: Sriram R <quic_srirrama@quicinc.com>

With the introduction of Multi Link Operation (MLO) support in
IEEE802.11be, each EHT AP/non AP interface is capable of
operating with multiple radio links.

cfg80211/mac80211 expects drivers to abstract the communication
between such Multi Link HW and mac80211/cfg80211 since it depends
on different driver/HW implementation. Hence the single wiphy
abstraction with changes in datastructures were introduced in
"wifi: ath12k: Introduce hw abstraction"

This patchset extends the implementation to allow combination
of multiple underlying radios into a single composite hw/wiphy
for registration. Since now multiple radios are represented by
a single wiphy, changes are required in various mac ops that the
driver supports since the driver now needs to learn on how to tunnel
various mac ops properly to a specific radio.

This patchset covers the basic mac80211 ops for an interface bring up
and operation.

Note:
Monitor and hw reconfig support for Single Wiphy will be done in future
patchsets.

---
 v6:
 - Fixed print message typo in PATCH 05/12
 - Modified ath12k_mac_assign_vif_to_vdev() of PATCH 05/12 to
   not have multiple jump statements.
 - Modified PATCH 07/12 to have whole cache allocated dynamically &
   fixed cache flush in case where we reuese vdev created on scan.

 v5:
 - Addressed Jeff's comments
 - Made arvif config cache to be dynamic in PATCH 07/12

 v4:
 - Updated missing Signed-off details for patches.

 v3:
  - Rebased on ToT (added additional ar check in PATCH 08/12 for p2p)
  - Introduced iterator to loop through ars in an ah(for_each_ar())
  - Addressed comments on reverse xmas tree declaration style.

 v2:
  - Rebased on ToT and dependent patchset

Karthikeyan Periyasamy (1):
  wifi: ath12k: add multiple radio support in a single MAC HW
    un/register

Sriram R (11):
  wifi: ath12k: Modify add and remove chanctx ops for single wiphy
    support
  wifi: ath12k: modify ath12k mac start/stop ops for single wiphy
  wifi: ath12k: vdev statemachine changes for single wiphy
  wifi: ath12k: scan statemachine changes for single wiphy
  wifi: ath12k: fetch correct radio based on vdev status
  wifi: ath12k: Cache vdev configs before vdev create
  wifi: ath12k: Add additional checks for vif and sta iterators
  wifi: ath12k: modify regulatory support for single wiphy architecture
  wifi: ath12k: Modify set and get antenna mac ops for single wiphy
  wifi: ath12k: Modify rts threshold mac op for single wiphy
  wifi: ath12k: support get_survey mac op for single wiphy

 drivers/net/wireless/ath/ath12k/core.h |  38 +-
 drivers/net/wireless/ath/ath12k/hw.h   |   1 +
 drivers/net/wireless/ath/ath12k/mac.c  | 940 +++++++++++++++++++------
 drivers/net/wireless/ath/ath12k/p2p.c  |   3 +-
 drivers/net/wireless/ath/ath12k/p2p.h  |   1 +
 drivers/net/wireless/ath/ath12k/reg.c  |  55 +-
 6 files changed, 810 insertions(+), 228 deletions(-)


base-commit: fe7e1b830cf3c0272aa4eaf367c4c7b29c169c3d

Comments

Jeff Johnson April 1, 2024, 7:34 p.m. UTC | #1
On 4/1/2024 12:03 PM, Rameshkumar Sundaram wrote:
> From: Sriram R <quic_srirrama@quicinc.com>
> 
> With the introduction of Multi Link Operation (MLO) support in
> IEEE802.11be, each EHT AP/non AP interface is capable of
> operating with multiple radio links.
> 
> cfg80211/mac80211 expects drivers to abstract the communication
> between such Multi Link HW and mac80211/cfg80211 since it depends
> on different driver/HW implementation. Hence the single wiphy
> abstraction with changes in datastructures were introduced in
> "wifi: ath12k: Introduce hw abstraction"
> 
> This patchset extends the implementation to allow combination
> of multiple underlying radios into a single composite hw/wiphy
> for registration. Since now multiple radios are represented by
> a single wiphy, changes are required in various mac ops that the
> driver supports since the driver now needs to learn on how to tunnel
> various mac ops properly to a specific radio.
> 
> This patchset covers the basic mac80211 ops for an interface bring up
> and operation.
> 
> Note:
> Monitor and hw reconfig support for Single Wiphy will be done in future
> patchsets.

thinking about this series in the context of some other patches I've been
reviewing recently, I don't think this series should be talking about
supporting multiple radios with a single wiphy, but instead about supporting
multiple devices with a single wiphy. After all, the existing logic already
supports a single device with multiple radios, so it isn't the multitude of
radios that is the issue, it is the multitude of devices.

this would have ramifications on many of the commit messages in this series.
Rameshkumar Sundaram April 2, 2024, 10:06 a.m. UTC | #2
On 4/2/2024 1:04 AM, Jeff Johnson wrote:
> On 4/1/2024 12:03 PM, Rameshkumar Sundaram wrote:
>> From: Sriram R <quic_srirrama@quicinc.com>
>>
>> With the introduction of Multi Link Operation (MLO) support in
>> IEEE802.11be, each EHT AP/non AP interface is capable of
>> operating with multiple radio links.
>>
>> cfg80211/mac80211 expects drivers to abstract the communication
>> between such Multi Link HW and mac80211/cfg80211 since it depends
>> on different driver/HW implementation. Hence the single wiphy
>> abstraction with changes in datastructures were introduced in
>> "wifi: ath12k: Introduce hw abstraction"
>>
>> This patchset extends the implementation to allow combination
>> of multiple underlying radios into a single composite hw/wiphy
>> for registration. Since now multiple radios are represented by
>> a single wiphy, changes are required in various mac ops that the
>> driver supports since the driver now needs to learn on how to tunnel
>> various mac ops properly to a specific radio.
>>
>> This patchset covers the basic mac80211 ops for an interface bring up
>> and operation.
>>
>> Note:
>> Monitor and hw reconfig support for Single Wiphy will be done in future
>> patchsets.
> 
> thinking about this series in the context of some other patches I've been
> reviewing recently, I don't think this series should be talking about
> supporting multiple radios with a single wiphy, but instead about supporting
> multiple devices with a single wiphy. After all, the existing logic already
> supports a single device with multiple radios, so it isn't the multitude of
> radios that is the issue, it is the multitude of devices.
So far we are only combining radios of a device (ab) and registering it 
as single HW(ah) to mac80211. Currently ah will only contain radios of 
one device. Combining multiple devices into a single HW is different 
series (where ag will be introduced).

Having said that, even if multiple devices are combined with ag, at hw 
(ah) level there are only radios of multiple devices (ab) and hence 
these patches stay generic and call them as radios.
> 
> this would have ramifications on many of the commit messages in this series.
>
Rameshkumar Sundaram April 5, 2024, 2:12 a.m. UTC | #3
On 4/2/2024 3:36 PM, Rameshkumar Sundaram wrote:
> 
> 
> On 4/2/2024 1:04 AM, Jeff Johnson wrote:
>> On 4/1/2024 12:03 PM, Rameshkumar Sundaram wrote:
>>> From: Sriram R <quic_srirrama@quicinc.com>
>>>
>>> With the introduction of Multi Link Operation (MLO) support in
>>> IEEE802.11be, each EHT AP/non AP interface is capable of
>>> operating with multiple radio links.
>>>
>>> cfg80211/mac80211 expects drivers to abstract the communication
>>> between such Multi Link HW and mac80211/cfg80211 since it depends
>>> on different driver/HW implementation. Hence the single wiphy
>>> abstraction with changes in datastructures were introduced in
>>> "wifi: ath12k: Introduce hw abstraction"
>>>
>>> This patchset extends the implementation to allow combination
>>> of multiple underlying radios into a single composite hw/wiphy
>>> for registration. Since now multiple radios are represented by
>>> a single wiphy, changes are required in various mac ops that the
>>> driver supports since the driver now needs to learn on how to tunnel
>>> various mac ops properly to a specific radio.
>>>
>>> This patchset covers the basic mac80211 ops for an interface bring up
>>> and operation.
>>>
>>> Note:
>>> Monitor and hw reconfig support for Single Wiphy will be done in future
>>> patchsets.
>>
>> thinking about this series in the context of some other patches I've been
>> reviewing recently, I don't think this series should be talking about
>> supporting multiple radios with a single wiphy, but instead about 
>> supporting
>> multiple devices with a single wiphy. After all, the existing logic 
>> already
>> supports a single device with multiple radios, so it isn't the 
>> multitude of
>> radios that is the issue, it is the multitude of devices.
> So far we are only combining radios of a device (ab) and registering it 
> as single HW(ah) to mac80211. Currently ah will only contain radios of 
> one device. Combining multiple devices into a single HW is different 
> series (where ag will be introduced).
> 
> Having said that, even if multiple devices are combined with ag, at hw 
> (ah) level there are only radios of multiple devices (ab) and hence 
> these patches stay generic and call them as radios.
>>
>> this would have ramifications on many of the commit messages in this 
>> series.
>>
> 
Hi Jeff,
Planning to re-spin v7 to address comments on PATCH 07/12, do you have 
anymore comments on the commit text or other patches ?
Jeff Johnson April 5, 2024, 3:36 p.m. UTC | #4
On 4/4/2024 7:12 PM, Rameshkumar Sundaram wrote:
> Hi Jeff,
> Planning to re-spin v7 to address comments on PATCH 07/12, do you have 
> anymore comments on the commit text or other patches ?

no, i don't have any additional comments, at least not at this time ;)