Received-SPF: pass (google.com: domain of linux-wireless+bounces-8350-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <29f1a482-2ead-474a-93a1-00616bcf06f8@quicinc.com>
Date: Fri, 31 May 2024 10:26:49 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 6/8] wifi: ath12k: support ARP and NS offload
Content-Language: en-US
To: Baochen Qiang <quic_bqiang@quicinc.com>, <ath12k@lists.infradead.org>
CC: <linux-wireless@vger.kernel.org>
References: <20240530072714.25671-1-quic_bqiang@quicinc.com>
 <20240530072714.25671-7-quic_bqiang@quicinc.com>
 <ccf9791b-e050-4844-8c37-35873fb3fcaf@quicinc.com>
 <17721436-19fb-4337-9058-b20f4df2792c@quicinc.com>
 <af326e49-df6e-4574-9562-44b6aee10abd@quicinc.com>
From: Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <af326e49-df6e-4574-9562-44b6aee10abd@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 5/30/2024 10:11 PM, Baochen Qiang wrote:
> 
> 
> On 5/31/2024 11:42 AM, Baochen Qiang wrote:
>>>> +static void ath12k_wow_prepare_ns_offload(struct ath12k_vif *arvif,
>>>> +					  struct wmi_arp_ns_offload_arg *offload)
>>>> +{
>>>> +	struct inet6_dev *idev = arvif->idev;
>>> as noted above does it make more sense to get the netdev associated with the
>>> arvif and then use in6_dev_get(net_device) to get the inet6_dev rather than
>>> caching the pointer from the ipv6_addr_changed() callback?
>> Ah.. I didn't note that we can get inet6_dev in such a way, just thought the only way is to cache it in ipv6_changed() callback.
>>
>> will get it using the following in next version:
>> 	struct ieee80211_vif *vif = container_of(arvif)
>> 	struct ieee80211_sub_if_data *sub_if_data = container_of(vif)
>> 	struct net_dev *ndev = sub_if_data->dev
>> 	struct inet6_dev *idev = in6_dev_get(ndev)
> Just found that ieee80211_sub_if_data is internal to mac80211, so not possible to get netdev in this way.
> 
> any other ideas on how to get netdev?

Thinking about this some more, it seems like you'd want to send these down to
firmware immediately so that they'd be available for NS offload. Does firmware
support NS offload even when host is awake (I think the downstream Android
driver supports that)?

So perhaps an alternative approach is to collect the information you need from
the notification and then schedule a workqueue to actually send the
information to firmware?