On 14 February 2018 at 15:53, Cunningham, Joel <Joel.Cunningham@xxxxxxxxxx> wrote: >> -----Original Message----- >> From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Ulf Hansson >> Sent: Wednesday, February 14, 2018 4:06 AM >> To: Cunningham, Joel <Joel.Cunningham@xxxxxxxxxx> >> Cc: linux-mmc@xxxxxxxxxxxxxxx >> Subject: Re: [PATCH] mmc: update sdio_claim_irq documentation >> >> On 24 January 2018 at 23:57, Cunningham, Joel >> <Joel.Cunningham@xxxxxxxxxx> wrote: >> > I have a 3rd party driver which calls sdio_claim_host (and >> sdio_release_host) in its IRQ handler, the comment documentation for >> sdio_claim_irq() caused confusion about whether this was allowed, even >> though the implementation supports recursive claims and the driver is >> functioning without issue. >> > >> > If the intention is that recursive claims are supported, the below patch >> (based on mmc-next) updates the documentation to demote the "must not" >> to a "does not need to" >> >> Recursive claims are supported, however internally in the mmc core we have >> moved towards of removing all occurrences of them (to make the locking >> more slim). >> >> Therefore, I wouldn't mind keeping the doc as is, even if isn't a problem in >> practice to have nested claim/release of the sdio host. > > Thanks for the explanation and that's good to get some clarity that recursive claims are supported. > > Thinking about the wording of the documentation more, 'must not' really means to me that one is never allowed to perform the recursive claim. My understanding comes from typical usage of 'MUST NOT' in RFCs (see RFC 2119). Would you be open to using 'should not' to indicate doing a recursive claim is not recommended as a best practice, but is supported in some circumstances? Apologize for the delay! Yeah, I am fine changing the wording to "should not".... > > I'm not intending to be pedantic, this wording really did cause a back-and-forth discussion between developers as to 1) If we correctly understood the SDIO API implementation and 2) Whether the driver is wrong/broken. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
