On 19 June 2017 at 11:25, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Fri, Jun 16, 2017 at 11:32 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> On 8 June 2017 at 10:53, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > >>> +#else /* !IS_ENABLED(CONFIG_MMC_BLOCK) */ >>> + >>> +static int mmc_add_block_debugfs(struct mmc_card *card, struct dentry *root) >>> +{ >> >> So does this really work as expected? >> >> Currently one can build the mmc block as a separate module. If that >> module is inserted after the mmc core module attempts to register the >> debugfs nodes, we would end up in this stub function, right? > > Not really. IS_ENABLED() is a compile-time flag. The stub is not even > compiled in if the block layer is selected as module. > > I.e. if CONFIG_MMC_BLOCK is "y" or "m" then the real function gets > compiled in. If it is "n" the stub gets compiled in. Okay. > >> In other words, those system that for some odd reason decide to insmod >> the mmc block module at a later point, won't be given the debugfs >> nodes? > > This is not really related, since I have all the debugfs files for the > block layer as static functions in this patch, i.e. if the block layer > is inserted, the debugfs files come up. If that would be the case, the I am fine. But, I am not sure. See comment below. > > On a broader note, AFAIK it is already impossible to insert the block > module after the core module (if it was selected as "m" at compile time), > as the block module must be inserted first, or the core module cannot > resolve the symbols it needs from the block module. No, this is wrong. It's actually the opposite. Currently there are no dependency from the core module on the block module. However, the block module uses exported functions from the core module, so the dependency is the opposite. This is exactly what I was trying to say, we must not create a circular dependency of the modules. To solve this, you must move the entire creation of the debugfs nodes to be done when the block device driver probes, in other words from mmc_blk_probe(). > > insmod will fail, and modprobe will load the required modules first, > so it orders the block layer to load before the core so that the symbols > are resolved. > > Yours, > Linus Walleij 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