On Mon, Jun 19, 2017 at 12:04 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > On 19 June 2017 at 11:25, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> 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. Aha, I see how you mean. > This is exactly what I was trying to say, we must not create a > circular dependency of the modules. I think modprobe resolves circular dependencies by inserting both modules at the same time, actually. insmod will not work. > 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(). Yes and this is done in patch 6/6. If you think it is dangerous to have this as an intermediary step, we can just squash the patches. Yours, Linus Walleij -- 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
