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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux