> -----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? 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. Joel > > Kind regards > Uffe > > > > > Joel > > > > From: Joel Cunningham <joel.cunningham@xxxxxxxxxx> > > > > Update documentation for sdio_claim_irq to relax the wording which > > describes whether or not its safe to call sdio_claim/release_host in > > an IRQ handler registered via sdio_claim_irq. The sdio_claim_host > > implementation has support (via __mmc_claim_host) to be recursively > > claimed > > > > Signed-off-by: Joel Cunningham <joel.cunningham@xxxxxxxxxx> > > --- > > drivers/mmc/core/sdio_irq.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c > > index 7a2eaf8410a3..37a1a4bcb778 100644 > > --- a/drivers/mmc/core/sdio_irq.c > > +++ b/drivers/mmc/core/sdio_irq.c > > @@ -277,8 +277,8 @@ static void sdio_single_irq_set(struct mmc_card > *card) > > * > > * Claim and activate the IRQ for the given SDIO function. The provided > > * handler will be called when that IRQ is asserted. The host is always > > - * claimed already when the handler is called so the handler must not > > - * call sdio_claim_host() nor sdio_release_host(). > > + * claimed already when the handler is called so the handler does not > > + * need to call sdio_claim_host() or sdio_release_host(). > > */ > > int sdio_claim_irq(struct sdio_func *func, sdio_irq_handler_t > > *handler) { > > -- > > 2.14.1 > > > -- > 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 ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
