[...] >> Seems like a bit of re-factoring/cleanup could help here as >> preparation step. I just posted a patch [1] cleaning up how the mmc >> block layer fetches the card's status. >> >> Perhaps that could at least simplify a bit for $subject patch, >> especially since it also makes mmc_send_status() being exported. > > OK if you merge your stuff I can iterate my patches on top, > no problem. Done! > >>> +#if IS_ENABLED(CONFIG_MMC_BLOCK) >> >> What wrong with a regular ifdefs stubs? Why do you need IS_ENABLED()? > > This is because the entire block layer can be compiled as a > module. > > In that case CONFIG_MMC_BLOCK contains 'm' instead of 'y' > which confusingly does not evaluate to true in the preprocessor > (it assumes it is a misspelled 'n' I guess). > > And then the autobuilders wreak havoc. > > And that is why the IS_ENABLED() defines exist in the first > place IIUC. Thanks for explanation! It makes more sense to me now! > > I'm all for making CONFIG_MMC_BLOCK into a bool... but > don't know how people (Intel laptops) feel about that extra > code in their kernel at all times. > >>> void mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req); >> >> I don't get what mmc_blk_issue_rq() has to do with this change? Could >> you please explain? > > If we start doing stubs we should stub everything IMO, but if you > prefer I can make that a separate patch. Seems a bit overdone > though. > >> Hmm, this thing seems a bit upside-down. >> >> Currently it's possible to build the mmc block device driver as a >> module. In cases like this, accessing the card debugs node to request >> the card's status, would trigger a call to mmc_blk_card_status_get(). >> How would that work when the mmc block device driver isn't loaded and >> probed? > > Module symbol resolution and driver loading is always necessary, > it is no different for e.g. a wifi driver using the 802.11 library. > It is definately possible to shoot oneself in the foot, but I think > udev & friends usually load things in the right order? My my point is that *if* the card debugfs nodes shows up to the user - they should work (no matter if the mmc block device has been probed or not). Can we guarantee that, is this approach? > >> It seems like the life cycle of the card debugfs node is now being >> controlled as when the mmc block device driver has been successfully >> probed. We need to deal with that somehow. > > Only for these two files but yes. > > ext_csd is a bit dubious as it is only available on storage devices > (eMMC) that can not be SD, SDIO or combo cards, and we could make > it only appear if using the block layer. Yes, that's a nice option. > > The card status however we need to keep if people want it. Again, this is for debug purpose. I don't see an issue moving also this one within CONFIG_MMC_BLOCK. > > We *COULD* consider just thrashing these debugfs files. It is not > technically ABI and I wonder who is actually using them. Right. According to Avri, apparently some userspace tools measuring performance. I would be interested to know a bit more about those tools. Kind regards Uffe
