>>>> +++ b/Documentation/driver-api/pin-control-acpi.rst
>>>
>>> We have Documentation/firmware-guide/acpi/, but I'm not sure
>>> which one suits better for this.
>>
>> I started with firmware-guide but then moved to driver-api as I
wanted to
>> cover driver related bits as well. Let me know if it is better at
>> firmware-guide.
>
> My point is that I don't know. If it's more about ACPI tables and
properties
> there, it's related to firmware-guide, if it's about Linux kernel pin
control
> subsystem (programming, etc) it's better to have it under its own
documentation
> subfolder.
In that case, we probably should also move existing
Documentation/driver-api/pin-control.rst to the new subfolder ?
...
+Pin control devices can add callbacks for following pinctrl_ops to handle ACPI
+pin resources.
Why? What use case requires this?
ACPI specification is more stricter in this than DT if I understand correctly
the state of affairs. So, can't we parse the tables in the same way for all?
...
+ case PINCTRL_ACPI_PIN_FUNCTION:
+ case PINCTRL_ACPI_PIN_CONFIG:
These are definitely what we do not want to see in the individual drivers.
(I understand that it might be that some OEMs will screw up and we would
need quirks, but not now)
Hm. Please correct me if I am wrong here. My understanding is that we need
to do few mapping which only pin controller drivers can do such as ACPI
function number to internal functional name or selector.
Not sure I understand the use case here. The PinFunction() selects the mode for
the pins in the list. But naming is hardware specific, indeed. And it seems
there is no name field for the PinFunction().
I could define
bindings to do those specific mappings rather than providing the current
general mapping interface. Would that be better ?
But that mapping can be provided by the driver at the initialization stage or
generated automatically.
For the first we already have pin control APIs. For the second one I don't
understand why driver should be involved.
Yes ACPI PinFunction() only contains a function number and it is
hardware specific.
AFAIA,the only way that would work without extra mapping is if drivers
could populate the pinctrl function tree with the index matching the
function number from ACPI table. I wasn't sure if that would work in all
cases. We can start with that if that would be good enough for now. Let
me know if there are other existing APIs that could help.
+ status = acpi_get_handle(NULL, pinctrl_acpi, &handle);
+ if (ACPI_FAILURE(status))
+ return NULL;
+
+ adev = acpi_get_acpi_dev(handle);
+ if (!adev)
+ return NULL;
+
+ dev_name = acpi_dev_name(adev);
+ if (!dev_name)
Resource leak is here (imbalanced reference counting).
+ return NULL;
+
+ return get_pinctrl_dev_from_devname(dev_name);
Are they all resource leakage-free?
I hope so. Do you see something odd ?
I recommend to read documentation on the above APIs.
Thanks. Got it
--
Niyas
