Re: [PATCH leds v2 05/50] leds: various: guard of_match_table member value with of_match_ptr

[Sakari Ailus]

Hi Lee,

On Mon, Sep 28, 2020 at 09:11:14AM +0100, Lee Jones wrote:
> 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.

There's really no reason having to enable the entire OF framework just to
allow compatible string matching.

> 
> 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.

That'd be one option, yes. But not all drivers that work on both OF and
ACPI rely on the compatible strings on ACPI.

Another option could be adding a new macro, to set that table on both OF
and ACPI when needed? It could be called e.g. of_acpi_match_ptr(), for
instance.

Cc also linux-acpi list and Rafael.

-- 
Regards,

Sakari Ailus