On 24 August 2017 at 08:53, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 23/08/17 15:48, Ulf Hansson wrote: >> On 23 August 2017 at 08:54, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >>> On 22/08/17 14:13, Ulf Hansson wrote: >>>> On 10 August 2017 at 14:08, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >>>>> + void (*cqe_recovery_notifier)(struct mmc_host *, >>>>> + struct mmc_request *); >>>> >>>> Normally we don't put callbacks in the struct mmc_host that someone >>>> else than the host driver should assign - so this feels a bit upside >>>> down. >>>> >>>> Is there any reason to why you didn't want to add a new API? Something >>>> like mmc_cqe_recover(), which the host driver could call. >>> >>> That would make the host driver dependent on the block driver. There needs >>> to be a function pointer, even if we wrap it in an API. >> >> Okay, I see. I guess we could put such pointer somewhere closer to the >> mmc request queue. > > Another possibility is to put in into struct mmc_request like the "done" > callback. Yes, I think like that. That would also solve the problem of having to protect the pointer as the request would then have a corresponding life cycle to the block device driver. > >> >> Anyway, I didn't find out how this pointer was being protected from >> concurrent access or perhaps that is managed via >> mmc_claim|release_host()? > > It is assumed CQE is only used by the card driver so the callback can be set > / reset in the card driver's probe / remove. > >> Moreover, I could find it ever it being >> reset to NULL. > > Yeah, doesn't look like it gets reset. 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
