On Tue, May 23, 2017 at 1:22 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > [...] > >>>>> +#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. >> >> The block layer cannot be a module, but the MMC layer can. >> >>> 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. >> >> I think CONFIG_MMC should remain tristate. However, we could >> consider making CONFIG_MMC_BLOCK a 'bool' symbol and >> linking it into the mmc-core module when enabled. > > That is a good idea, no matter what. We should do the same thing for > CONFIG_MMC_TEST. There are really no need to have to separate modules, > one is more than enough.
I think for the test module it conceptually makes more sense to be separate, though I can see that this requires to be careful with the debugfs file lifetime rules. >>>> 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. >>> >>> The card status however we need to keep if people want it. >>> >>> We *COULD* consider just thrashing these debugfs files. It is not >>> technically ABI and I wonder who is actually using them. >> >> I think the ext_csd is extremely useful on storage devices to have >> exposed to user space in some form. There is a comment saying >> that we don't store it in RAM at the moment as it is rarely used, >> but we could change that, as it's only 512 bytes per eMMC device >> and there is rarely more than one of them. IIRC, the ext_csd is >> entirely readonly and doesn't change during runtime, so we >> gain nothing by issuing the commands every time someone reads >> the debugfs file. > > First, we have mmc utils (going via mmc ioctl), which purpose are > exactly for these cases. As a matter of fact it does a better job, > since it even present the data in a more human readable format. > > Second, ext csd gets updated very often to control/change some > behavior of the device. You must be mixing this up with some of the > other card registers. Ok, it's been a while since I looked at the details, thanks for the clarification. Arnd