Message ID | 20210610152823.1653-1-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers | show |
Series | [v1,1/1] pinctrl: intel: Check against matching data instead of ACPI companion | expand |
On Thu, Jun 10, 2021 at 06:28:23PM +0300, Andy Shevchenko wrote: > In some cases we may get a platform device that has ACPI companion > which is different to the pin control described in the ACPI tables. > This is primarily happens when device is instantiated by board file. Can you point which board file in the mainline kernel has this issue? If not then I don't think it makes sense to add code like this.
On Fri, Jun 11, 2021 at 10:53 AM Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > > On Thu, Jun 10, 2021 at 06:28:23PM +0300, Andy Shevchenko wrote: > > In some cases we may get a platform device that has ACPI companion > > which is different to the pin control described in the ACPI tables. > > This is primarily happens when device is instantiated by board file. > > Can you point which board file in the mainline kernel has this issue? If > not then I don't think it makes sense to add code like this. To my knowledge we don't have such enumeration in the upstream (but it may be done by third parties against any of our controllers enumerated by UID, like Broxton or Gemini Lake). That said, I still think that this is the right thing to do independently, because logic currently is broken (we have tons of the examples in the kernel where matching data is in use along with platform supplied variants and there we check for matching data first). Anyway, the proper use of this patch can be in the part of the series which actually enables that kind of enumeration in the upstream. In any case I suppose Henning can test this for his purposes.
On Fri, Jun 11, 2021 at 11:16:23AM +0300, Andy Shevchenko wrote: > On Fri, Jun 11, 2021 at 10:53 AM Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: > > > > On Thu, Jun 10, 2021 at 06:28:23PM +0300, Andy Shevchenko wrote: > > > In some cases we may get a platform device that has ACPI companion > > > which is different to the pin control described in the ACPI tables. > > > This is primarily happens when device is instantiated by board file. > > > > Can you point which board file in the mainline kernel has this issue? If > > not then I don't think it makes sense to add code like this. > > To my knowledge we don't have such enumeration in the upstream (but it > may be done by third parties against any of our controllers enumerated > by UID, like Broxton or Gemini Lake). So let's add it when we have such thing in the mainline. For the rest Intel drivers we always supply the SoC information so this is not a problem.
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c index 15581f3e08b9..83d5e0a553ab 100644 --- a/drivers/pinctrl/intel/pinctrl-intel.c +++ b/drivers/pinctrl/intel/pinctrl-intel.c @@ -1611,16 +1611,14 @@ EXPORT_SYMBOL_GPL(intel_pinctrl_probe_by_uid); const struct intel_pinctrl_soc_data *intel_pinctrl_get_soc_data(struct platform_device *pdev) { + const struct intel_pinctrl_soc_data * const *table; const struct intel_pinctrl_soc_data *data = NULL; - const struct intel_pinctrl_soc_data **table; - struct acpi_device *adev; - unsigned int i; - adev = ACPI_COMPANION(&pdev->dev); - if (adev) { - const void *match = device_get_match_data(&pdev->dev); + table = device_get_match_data(&pdev->dev); + if (table) { + struct acpi_device *adev = ACPI_COMPANION(&pdev->dev); + unsigned int i; - table = (const struct intel_pinctrl_soc_data **)match; for (i = 0; table[i]; i++) { if (!strcmp(adev->pnp.unique_id, table[i]->uid)) { data = table[i];
In some cases we may get a platform device that has ACPI companion which is different to the pin control described in the ACPI tables. This is primarily happens when device is instantiated by board file. In order to allow this device being enumerated, refactor intel_pinctrl_get_soc_data() to check the matching data instead of ACPI companion. Reported-by: Henning Schild <henning.schild@siemens.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/pinctrl/intel/pinctrl-intel.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)