[PATCH net-next v2 2/7] net: airoha: npu: Add NPU wlan memory initialization commands

[Krzysztof Kozlowski]

On 07/07/2025 17:24, Lorenzo Bianconi wrote:
>> On 07/07/2025 09:24, Lorenzo Bianconi wrote:
>>>> On Sat, Jul 05, 2025 at 11:09:46PM +0200, Lorenzo Bianconi wrote:
>>>>> +
>>>>>  struct airoha_npu *airoha_npu_get(struct device *dev, dma_addr_t *stats_addr)
>>>>>  {
>>>>>  	struct platform_device *pdev;
>>>>> @@ -493,6 +573,7 @@ static int airoha_npu_probe(struct platform_device *pdev)
>>>>>  	npu->ops.ppe_deinit = airoha_npu_ppe_deinit;
>>>>>  	npu->ops.ppe_flush_sram_entries = airoha_npu_ppe_flush_sram_entries;
>>>>>  	npu->ops.ppe_foe_commit_entry = airoha_npu_foe_commit_entry;
>>>>> +	npu->ops.wlan_init_reserved_memory = airoha_npu_wlan_init_memory;
>>>>
>>>> I cannot find in your code single place calling this (later you add a
>>>> wrapper... which is not called either).
>>>>
>>>> All this looks like dead code...
>>>
>>> As pointed out in the commit log, these callbacks will be used by MT76 driver
>>> to initialize the NPU reserved memory and registers during driver probe in
>>> order to initialize the WiFi offloading. Since MT76 patches are going via
>>> the wireless tree, I needed to add these callbacks first.
>>
>> Cover letter does not link to your NPU patchset. You cannot add dead
>> code to the kernel and now it is pure dead code. Post your user - in
>> this or separate patchset.
> 
> I guess you mean the related MT76 patches are not linked in the cover-letter,
> right? I have not posted them yet.
> 
>>
>> Your explanation of dependency is also confusing. If these are added to
>> wireless tree (considering last experience how they rebase and cannot
>> easily handle cross tree merges), how does it solve your problem? You
>> will have it in one tree but not in the other, so still nothing...
>> That's anyway separate problem, because main issue is you add code which
>> we cannot even verify how it is being used.
> 
> My main point here is wireless tree can't acutally merge the MT76 patches
> since, without the net-next ones (this series), it will not compile (so I

This does not explain hiding the other part. Again - there is nothing
weird in patchset dependencies. Weird is saying there is dependency, so
I will not post code.

> posted net-next patches as preliminary ones for MT76 changes).
> Moreover, this is the same approach we used when we added WED support to
> mtk_eth_soc driver and the related MT76 support.
> However, I am fine to post the MT76 changes as RFC and just refer to it in
> this series cover-letter. Agree? 
> 
>>
>> So far I see ABI break, but without user cannot judge. And that's the
>> hard reason this cannot be accepted.
> 
> if you mean the dts changes, I will fix them in v3.
> 
No, I mean driver.

Best regards,
Krzysztof