On Mon, 28 Sep 2020, Lee Jones wrote: > On Fri, 18 Sep 2020, Sakari Ailus wrote: > > > On Fri, Sep 18, 2020 at 11:20:58AM +0200, Marek Behun wrote: > > > On Fri, 18 Sep 2020 09:15:00 +0300 > > > Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> wrote: > > > > > > > Hi Marek, > > > > > > > > On Fri, Sep 18, 2020 at 12:32:53AM +0200, Marek Behún wrote: > > > > > Change > > > > > .of_match_table = xxx, > > > > > to > > > > > .of_match_table = of_match_ptr(xxx), > > > > > in various drivers. > > > > > > > > > > This should be standard even for drivers that depend on OF. > > > > > > > > After this patch, none of these drivers will work on ACPI systems anymore. > > > > ^ > > > > If CONFIG_OF is disabled, that is. > > What? of_match_ptr() is designed to change depending on OF or !OF. > > Are you confusing this with acpi_match_table()? Okay, I just grepped the kernel and found some OF matching in the ACPI bus code. This seems odd to be (at first sight at least). I'm not entirely sure how this is supposed to work, but when you disable OF, one could reasonably expect any matching utilising OF based tables to be disabled too. Not using of_match_ptr() on ACPI enabled platforms sounds batty to me. If this is valid, perhaps the of_match_ptr()semantics should be changed to include ACPI. > > > Hi Sakari, > > > > > > I don't understand. Why not? Does ACPI subsystem parse of_match_table > > > as well? > > > > It does. The compatible string is used the same way as in DT for matching > > devices with "PRP0001" _HID or _CID. > > > > Please read Documentation/firmware-guide/acpi/enumeration.rst . > > Could you allude to the specific line you are referencing please? > > > IOW, you can safely do the above only for drivers that depend on OF in > > Kconfig. Otherwise you'll probably break something. > -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
