linux-kernel - Re: [PATCH v3 1/3] dt-bindings: pinctrl: Add support for Amlogic A4 SoCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <820705e4-d8bf-403a-9017-d20a028616ae@amlogic.com>
Date: Fri, 8 Nov 2024 14:18:38 +0800
From: Xianwei Zhao <xianwei.zhao@...ogic.com>
To: neil.armstrong@...aro.org, Krzysztof Kozlowski <krzk@...nel.org>,
 Jerome Brunet <jbrunet@...libre.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Kevin Hilman <khilman@...libre.com>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
 Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: pinctrl: Add support for Amlogic A4
 SoCs

Hi Neil,
    Thanks for your reply.

    I've already sent RFC v4 version to discuss the feasibility. 
https://lore.kernel.org/all/20241101-a4_pinctrl-v4-0-efd98edc3ad4@amlogic.com/

    The driver maintains the original framework, and is compatible with 
the previous, but adds a hook function(of_xlate), and each SoC driver 
implements its own of_xlate function.

    In this way, the binding header file needs to be increased once, and 
the subsequent chip driver no longer adds the header file, this way has 
acked by Rob.

    what do you think of the changes to the driver?

On 2024/10/28 18:44, neil.armstrong@...aro.org wrote:
> [ EXTERNAL EMAIL ]
> 
> On 28/10/2024 10:59, Xianwei Zhao wrote:
>>
>>
>> On 2024/10/28 17:46, neil.armstrong@...aro.org wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On 28/10/2024 10:36, Xianwei Zhao wrote:
>>>> Hi Neil,
>>>>     Thanks for your advice.
>>>>
>>>> On 2024/10/28 17:09, neil.armstrong@...aro.org wrote:
>>>>> [ EXTERNAL EMAIL ]
>>>>>
>>>>> On 28/10/2024 10:07, Xianwei Zhao wrote:
>>>>>> Hi Neil,
>>>>>>      Based on the current discussion results, GPIO index macro 
>>>>>> definition does not belong to bindings. If so, the pinctrl driver 
>>>>>> keeps the existing architecture, and use numbers instead in dts 
>>>>>> file. Or the pinctrl driver use bank mode acess, this may not be 
>>>>>> compatible with existing frameworks. This is done by adding 
>>>>>> of_xlate hook functions in pinctrl_chip struct.
>>>>>>
>>>>>> What is your advice that I can implement in the next version. Thanks!
>>>>>
>>>>> Keep the driver as-is, but move the header file into 
>>>>> arch/arm64/boot/dts/amlogic like it was done for the last reset 
>>>>> controller support:
>>>>> arch/arm64/boot/dts/amlogic/amlogic-t7-reset.h
>>>>>
>>>>
>>>> I don't see examples C file applies dts header file.
>>>> C file need to be defined once, and this needs to be defined again 
>>>> in dts header file.
>>>
>>> Sorry could you rephrase, the sentence isn't clear.
>>>
>>
>> I'm sorry I didn't describe it clearly.
>>
>> The pin index definition is used in driver C file and in DTS files.
>> It's not like reset definition only used in DTS files.
>> If the pin definition header file place arch/arm64/boot/dts/amlogic, 
>> so the driver C file needs to be defined again. I don't see examples 
>> of how a C file applies a DTS header file.
> 
> Good question, I still don't understand why the model we used so far is 
> suddenly bad.
> 
> Rob simply pointed for AOBUS:
> ==========><=====================
> I find defines with the value of the define in the name pretty
> pointless.
> ==========><=====================
> 
> Right but those are an exception because GPIO_TEST_N is the exception,
> 
> And of the periphs:
> ==========><=====================
> I'm not really much of a fan of using defines for GPIOs, but if you do,
> wouldn't be better to split banks and lines up rather than a global
> number space. See ASPEED_GPIO() or tegra header.
> ==========><=====================
> 
> This is exactly what was provided in v2, and mapped what was in 
> aspeed-gpio.h
> 
> I repeat:
> The GPIO names are not linear to a number, pointing to the first AOBUS 
> first is a nonsense since GPIO_TEST_N is the exception.
> 
> And the driver needs those numbers since they are bindings.
> 
> Neil
> 
>>
>>> Neil
>>>
>>>>
>>>>> Neil
>>>>>
>>>>>>
>>>>>> On 2024/10/21 23:27, Krzysztof Kozlowski wrote:
>>>>>>> [ EXTERNAL EMAIL ]
>>>>>>>
>>>>>>> On 21/10/2024 12:38, neil.armstrong@...aro.org wrote:
>>>>>>>>>> ====><=================
>>>>>>>>>> +/* Standard port */
>>>>>>>>>> +#define GPIOB_START        0
>>>>>>>>>> +#define GPIOB_NUM  14
>>>>>>>>>> +
>>>>>>>>>> +#define GPIOD_START        (GPIOB_START + GPIOB_NUM)
>>>>>>>>>> +#define GPIOD_NUM  16
>>>>>>>>>> +
>>>>>>>>>> +#define GPIOE_START        (GPIOD_START + GPIOD_NUM)
>>>>>>>>>> +#define GPIOE_NUM  2
>>>>>>>>>> +
>>>>>>>>>> +#define GPIOT_START        (GPIOE_START + GPIOE_NUM)
>>>>>>>>>> +#define GPIOT_NUM  23
>>>>>>>>>> +
>>>>>>>>>> +#define GPIOX_START        (GPIOT_START + GPIOT_NUM)
>>>>>>>>>> +#define GPIOX_NUM  18
>>>>>>>>>> +
>>>>>>>>>> +#define PERIPHS_PIN_NUM    (GPIOX_START + GPIOX_NUM)
>>>>>>>>>> +
>>>>>>>>>> +/* Aobus port */
>>>>>>>>>> +#define GPIOAO_START       0
>>>>>>>>>> +#define GPIOAO_NUM 7
>>>>>>>>>> +
>>>>>>>>>> +/* It's a special definition, put at the end, just 1 num */
>>>>>>>>>> +#define    GPIO_TEST_N     (GPIOAO_START +  GPIOAO_NUM)
>>>>>>>>>> +#define    AOBUS_PIN_NUM   (GPIO_TEST_N + 1)
>>>>>>>>>> +
>>>>>>>>>> +#define AMLOGIC_GPIO(port, offset) (port##_START + (offset))
>>>>>>>>>> ====><=================
>>>>>>>>>>
>>>>>>>>>> is exactly what rob asked for, and you nacked it.
>>>>>>>>>
>>>>>>>>> No, this is not what was asked, at least according to my 
>>>>>>>>> understanding.
>>>>>>>>> Number of GPIOs is not an ABI. Neither is their relationship, 
>>>>>>>>> where one
>>>>>>>>> starts and other ends.
>>>>>>>>
>>>>>>>> I confirm this need some work, but it moved the per-pin define 
>>>>>>>> to start
>>>>>>>> and ranges, so what did rob expect ?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Maybe I missed something, but I could not find any users of 
>>>>>>>>> these in the
>>>>>>>>> DTS. Look:
>>>>>>>>>
>>>>>>>>> https://lore.kernel.org/all/20241014-a4_pinctrl-v2-3-3e74a65c285e@amlogic.com/
>>>>>>>>
>>>>>>>> So you want consumers before the bindings ? strange argument
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Where is any of above defines?
>>>>>>>>>
>>>>>>>>> Maybe they will be visible in the consumer code, but I did not 
>>>>>>>>> imagine
>>>>>>>>> such use. You expect:
>>>>>>>>> reset-gpios = <&ctrl GPIOAO_START 1>???
>>>>>>>>
>>>>>>>> No I expect:
>>>>>>>> reset-gpios = <&ctrl AMLOGIC_GPIO(B, 0) 1>;
>>>>>>>>
>>>>>>>> but the macro should go along the dts like we did for the reset 
>>>>>>>> defines,
>>>>>>>> so perhaps this is the solution ?
>>>>>>>
>>>>>>> OK, so I said it was not a binding:
>>>>>>> https://lore.kernel.org/all/u4afxqc3ludsic4n3hs3r3drg3ftmsbcwfjltic2mb66foo47x@xe57gltl77hq/
>>>>>>>
>>>>>>> and you here confirm, if I understood you correctly, that it goes 
>>>>>>> with
>>>>>>> the DTS like reset defines (I assume non-ID like defines?), so 
>>>>>>> also not
>>>>>>> a binding?
>>>>>>>
>>>>>>> What are we disagreeing with?
>>>>>>>
>>>>>>> Just to recall, Jerome asked whether you have to now use arbitrary
>>>>>>> numbers in DTS and my answer was: not. It's still the same answer.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Krzysztof
>>>>>>>
>>>>>
>>>
>