netdev - Re: [PATCH] wifi: wilc1000: Rework bus locking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3b2e85a2-5dd2-4368-9f94-422b7766297a@denx.de>
Date: Wed, 23 Oct 2024 16:26:54 +0200
From: Marek Vasut <marex@...x.de>
To: Alexis Lothoré <alexis.lothore@...tlin.com>,
 linux-wireless@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
 Adham Abozaeid <adham.abozaeid@...rochip.com>,
 Ajay Singh <ajay.kathat@...rochip.com>,
 Claudiu Beznea <claudiu.beznea@...on.dev>, Conor Dooley
 <conor+dt@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Kalle Valo <kvalo@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
 netdev@...r.kernel.org
Subject: Re: [PATCH] wifi: wilc1000: Rework bus locking

On 10/23/24 9:54 AM, Alexis Lothoré wrote:

Hello Alexis,

>>                                   ksdioirqd() { // option 2
>>                                     claim_bus
>>                                     CMD52 0x0f, lets read SDIO_CCCR_INTx
>>                                     release_bus
>>                                   }
>>
>> That's what this patch implements, to avoid the interference.
>>
>> Maybe I should include the infographics? Or reword this somehow?
> 
> What I may have misunderstood is your first sentence ("sdio_claim_host() cannot
> be done per command, but has to be done per register/data IO which consists of
> multiple commands", especially command VS reg/data io), but your graph clarified
> it for me, thanks, so in the end we agree on this :) That may just be me having
> poorly interpreted, so no need to add the graphs to the commit

You're welcome. As long as we can understand each other with one extra 
round trip, all is good :)

> [...]
> 
>>>>    static int wilc_wlan_cfg_commit(struct wilc_vif *vif, int type,
>>>> diff --git a/drivers/net/wireless/microchip/wilc1000/wlan.h b/drivers/net/
>>>> wireless/microchip/wilc1000/wlan.h
>>>> index b9e7f9222eadd..ade2db95e8a0f 100644
>>>> --- a/drivers/net/wireless/microchip/wilc1000/wlan.h
>>>> +++ b/drivers/net/wireless/microchip/wilc1000/wlan.h
>>>> @@ -403,6 +403,8 @@ struct wilc_hif_func {
>>>>        void (*disable_interrupt)(struct wilc *nic);
>>>>        int (*hif_reset)(struct wilc *wilc);
>>>>        bool (*hif_is_init)(struct wilc *wilc);
>>>> +    void (*hif_claim)(struct wilc *wilc);
>>>> +    void (*hif_release)(struct wilc *wilc);
>>>
>>> So IIUC, your series push the hif_cs lock into each bus layer of the driver,
>>> remove any explicit call to bus-specific locking mechanism from those layers,
>>> and makes the upper layer control the locking. As mentioned above, I don't
>>> understand why those layers can not manage the bus-specific locking by
>>> themselves (which would be a big win for the upper layer).
>>
>> Because of acquire_bus()/release_bus() which I think is an attempt to serialize
>> bus access across multiple complex operations (=commands sent to the card), see
>> above.
> 
> Taking a further look at some examples in the driver, I see that indeed the
> "scope" of acquire_bus/release_bus is larger than simple bus operations. So I
> withdraw my proposal which was wrong.
All right.