On Mon, Nov 23, 2020 at 03:42:25PM +0200, Andy Shevchenko wrote: > On Mon, Nov 23, 2020 at 01:41:29PM +0100, Krzysztof Kozlowski wrote: > > On Mon, Nov 23, 2020 at 12:37:31PM +0000, Mark Brown wrote: > > > On Mon, Nov 23, 2020 at 12:48:32PM +0200, Andy Shevchenko wrote: > > > > On Sun, Nov 22, 2020 at 11:59:20AM +0100, Krzysztof Kozlowski wrote: > > > > > On Fri, Nov 20, 2020 at 08:04:29PM +0000, Mark Brown wrote: > > > > > > > > > Surely if that's the desired outcome the fix is to change the definition > > > > > > of of_match_ptr() such that it leaves the reference with CONFIG_ACPI, > > > > > > perhaps hidden behind a config option for PRP0001? That seems better > > > > > > than going through the entire tree like this. > > > > > > > > That could be indeed an easier way to achieve this. > > > > > > > ...easier and wrong in my opinion. Not all drivers need that. > > > > What the point to touch it in the driver which is OF-only? > > > > (For IP which will quite unlikely to be present in ACPI world) > > > > Or if the device will get the correct ACPI ID? > > > > > > That feels like something that should be done with Kconfig dependencies > > > like a direct OF dependency (possibly a !PRP0001 dependency?) for the > > > driver or possibly with having a variant of_match_ptr() for things that > > > really don't want to support PRP0001. Just removing all the use of > > > of_match_ptr() is both noisy and confusing in that it looks like it's > > > creating issues to fix, it makes it hard to understand when and why one > > > should use the macro. > > > > For the OF-only drivers (without other ID table), there is no point to > > use the macro. Driver can bind only with DT, so what is the point of > > of_match_ptr? To skip the OF table when building without OF? Driver > > won't be usable at all in such case. So maybe for compile testing? > > There is no need to remove OF table for simple build tests. > > I'm on the same page here. I should have elaborated that under OF only I meant rather !ACPI. So, when it has no ID tables, I agree that macro is not needed. But, for instance, I²C device drivers tend to have table even for ->probe_new() callback to be able to instantiate them via user space. -- With Best Regards, Andy Shevchenko
