Hi Arnd, Pierre, Thanks for looking at this. > >>> Thanks Arnd, do you mind sharing your config? > >> > >> https://pastebin.com/HRX5xi3R > > > > will give it a try, thanks! > > > >>> We noticed last week that > >>> there's a depend/select confusion might be simpler to fix, see > >>> https://github.com/thesofproject/linux/pull/2047/commits > >>> > >>> If I look at the first line I see a IMX_DSP=n which looks exactly like > >>> what we wanted to fix. > >> > >> Yes, I think that fix addresses the build warning as well, but looking > >> more closely I don't think it's what you want: If you do this on > >> a config that has the IMX_DSP disabled, it would appear to the > >> user that you have enabled the drivers, but the actual code is still > >> disabled. > > > > Are you sure? we added a select IMX_DSP, so not sure how it can be > > disabled? > > I just tested Arnd's config with the patch we came up with for SOF > (attached) and it makes the unmet dependency go away and builds fine. > the problem is really using select IMX_DSP if it can be disabled by > something else. My proposal looks simpler but I will agree it's not > necessarily super elegant to move the dependency on IMX_BOX into SOF, so > no sustained objection from me on Arnd's proposal. > > Daniel, this is your part of SOF, please chime in. I would go in favor of Arnd's patch as it gets rid of exposing IMX_MBOX into SOF. The code will be fine even IMX_DSP=n, because the exported functions used by SOF have dummy implementations in case IMX_DSP is not selected. One concern is that we could end up in a case where IMX_DSP={y|m} but IMX_MBOX=n. Technically this is not possible because IMX_DSP depends on IMX_MBOX. So, one cannot generate such a .config file from menuconfig interface. You can add my: Acked-by: Daniel Baluta <daniel.baluta@xxxxxxx>
