On 19 June 2017 at 13:14, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > 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. Yes, please do that! 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
