On 09/09/2022 02:25, David Collins wrote:
>>> diff --git a/include/dt-bindings/pinctrl/qcom,pmic-gpio.h b/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
>>> index e5df5ce45a0f..950be952ad3e 100644
>>> --- a/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
>>> +++ b/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
>>
>> You cannot mix bindings with driver. This is an ABI break.
>
> This could be split into two patches. However, both would need to make
> it into any given build to avoid runtime regressions when
> pinctrl-spmi-gpio.c rejects GPIO strength configurations larger than 1.
Which proves this is an ABI break. You need to gracefully handle in the
driver.
>
> I suppose that this kind of bi-directional dependency could be avoided
> by using one of these checks instead in the driver:
>
> if (arg > 3) {
>
> or
>
> if (arg > max(PMIC_GPIO_STRENGTH_LOW, PMIC_GPIO_STRENGTH_HIGH))
>
> Going this route would only require that the driver patch is picked up
> before the DT header patch.
You cannot change constants in the DT bindings header. Regardless
whether now or in the future - the constants are frozen. Otherwise it is
an ABI break. It would be acceptable only if existing feature was
completely broken and never worked.
>
>
>
>>> @@ -12,9 +12,14 @@
>>> #define PMIC_GPIO_PULL_UP_1P5_30 3
>>>
>>> #define PMIC_GPIO_STRENGTH_NO 0
>>> -#define PMIC_GPIO_STRENGTH_HIGH 1
>>> +#define PMIC_GPIO_STRENGTH_LOW 1
>>> #define PMIC_GPIO_STRENGTH_MED 2
>>> -#define PMIC_GPIO_STRENGTH_LOW 3
>>> +#define PMIC_GPIO_STRENGTH_HIGH 3
>>
>> Didn't you just break all DTSes in the world?
>
> Currently, all PMIC GPIO peripherals managed by the pinctrl-spmi-gpio
> driver are having their drive strength control register programmed
> incorrectly at runtime for the constant name used in DT (i.e.
> PMIC_GPIO_STRENGTH_LOW vs PMIC_GPIO_STRENGTH_HIGH). Changing the values
> of those constants as done in this patch fixes that incorrect behavior.
Wait. The values in the bindings should be only, *only* abstract ID
numbers. Not register values. How is it related to the value being
programmed in the driver? This is just an enum. If you have DTS with
PMIC_GPIO_STRENGTH_LOW you program 0xwhatever-you-wish. Not exactly
current value of "PMIC_GPIO_STRENGTH_LOW".
You need to fix the driver, not the bindings.
>
> The qcom,drive-strength DT property is taking a raw drive strength
> control register value instead of some logical strength abstraction.
> I'm not sure of a better way to handle the situation than fixing the
> incorrect drive strength constant to register value mapping as defined
> in qcom,pmic-gpio.h.
Bindings are not for defining register values, but to define the DTS.
Feel free to use binding constants for register values if they fit
you... but if they don't fit, fix the driver. Not the bindings.
>
> Changing the mapping in qcom,pmic-gpio.h without updating any dtsi files
> could cause a problem for very old targets that use SSBI instead of SPMI
> for PMIC communication. However, for there to actually be a problem,
> PMIC_GPIO_STRENGTH_LOW or PMIC_GPIO_STRENGTH_HIGH would need to be
> specified for the SSBI PMIC. That would be GPIO devices with compatible
> strings: "qcom,pm8018-gpio", "qcom,pm8038-gpio", "qcom,pm8058-gpio",
> "qcom,pm8917-gpio", or "qcom,pm8921-gpio". I could find no instances of
> this situation in the kernel source tree.
>
> The PMIC_GPIO_STRENGTH_LOW or PMIC_GPIO_STRENGTH_HIGH usage in dtsi
> files for SPMI PMICs does not need to be modified. The DT header patch
> fixes configurations that are currently broken for them.
>
> Note that the drive strength misconfiguration issue doesn't present a
> problem for commercial products as this patch has been cherry-picked
> downstream for several years.
It will affect several other out-of-tree users and other projects. Don't
think only about Qualcomm tree, but about entire Qualcomm ecosystem and
its users.
Best regards,
Krzysztof
