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] [thread-next>] [day] [month] [year] [list]
Message-ID: <888b8ab9-f8cb-2e1f-465c-3cb97187fce0@microchip.com>
Date:   Tue, 13 Sep 2022 09:19:31 +0000
From:   <Sergiu.Moga@...rochip.com>
To:     <krzysztof.kozlowski@...aro.org>, <robh@...nel.org>
CC:     <lee@...nel.org>, <krzysztof.kozlowski+dt@...aro.org>,
        <Nicolas.Ferre@...rochip.com>, <alexandre.belloni@...tlin.com>,
        <Claudiu.Beznea@...rochip.com>, <richard.genoud@...il.com>,
        <radu_nicolae.pirea@....ro>, <gregkh@...uxfoundation.org>,
        <broonie@...nel.org>, <mturquette@...libre.com>,
        <sboyd@...nel.org>, <jirislaby@...nel.org>, <admin@...iphile.com>,
        <Kavyasree.Kotagiri@...rochip.com>, <Tudor.Ambarus@...rochip.com>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <linux-spi@...r.kernel.org>,
        <linux-serial@...r.kernel.org>, <linux-clk@...r.kernel.org>
Subject: Re: [PATCH v2 06/13] dt-bindings: serial: atmel,at91-usart: Add
 SAM9260 compatibles to SAM9x60

On 13.09.2022 11:58, Krzysztof Kozlowski wrote:
> On 12/09/2022 15:09, Sergiu.Moga@...rochip.com wrote:
>> On 12.09.2022 13:44, Krzysztof Kozlowski wrote:
>>> On 12/09/2022 09:45, Sergiu.Moga@...rochip.com wrote:
>>>> On 09.09.2022 04:36, Rob Herring wrote:
>>>>> On Thu, Sep 08, 2022 at 03:15:44PM +0000, Sergiu.Moga@...rochip.com wrote:
>>>>>> On 08.09.2022 15:30, Krzysztof Kozlowski wrote:
>>>>>>> On 06/09/2022 15:55, Sergiu Moga wrote:
>>>>>>>> Add the AT91SAM9260 serial compatibles to the list of SAM9X60 compatibles
>>>>>>>> in order to highlight the incremental characteristics of the SAM9X60
>>>>>>>> serial IP.
>>>>>>>>
>>>>>>>> Signed-off-by: Sergiu Moga <sergiu.moga@...rochip.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>
>>>>>>>> v1 -> v2:
>>>>>>>> - Nothing, this patch was not here before
>>>>>>>>
>>>>>>>>
>>>>>>>>      Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml | 2 ++
>>>>>>>>      1 file changed, 2 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
>>>>>>>> index b25535b7a4d2..4d80006963c7 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/serial/atmel,at91-usart.yaml
>>>>>>>> @@ -26,6 +26,8 @@ properties:
>>>>>>>>            - items:
>>>>>>>>                - const: microchip,sam9x60-dbgu
>>>>>>>>                - const: microchip,sam9x60-usart
>>>>>>>> +          - const: atmel,at91sam9260-dbgu
>>>>>>>> +          - const: atmel,at91sam9260-usart
>>>>>>>
>>>>>>> This is weird. You say in commit msg to "highlight the incremental
>>>>>>> characteristics" but you basically change here existing compatibles.
>>>>>>
>>>>>>
>>>>>> Does "show that they are incremental IP's" sound better then?
>>>>>>
>>>>>>
>>>>>>> This is not enum, but a list.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> What do you mean by this? I know it is a list, I specified so in the
>>>>>> commit message.
>>>>>
>>>>> You are saying that compatible must be exactly the 4 strings above in
>>>>> the order listed. You need another entry with another 'items' list.
>>>>>
>>>>> Rob
>>>>
>>>>
>>>> That is what was intended though: a list of the 4 compatibles in that
>>>> exact order. The 4th patch of this series also ensures that all 9x60
>>>> nodes have that exact list of 4 compatibles.
>>>
>>> The commit msg suggest otherwise - two options, because it is
>>> incremental... But this one is not really incremental - you require this
>>> one, only one, configuration. It's in general fine, but commit msg
>>> should reflect what you are really intend to do here and why you are
>>> doing it.
>>>
>>>
>>> Best regards,
>>> Krzysztof
>>
>>
>> My apologies, I still do not understand what is wrong with the commit
>> message. My intention was to ensure that every 9x60 usart compatible is
>> followed by the 9260 compatibles because the 9x60 serial IP is an
>> improvement over the 9260 one. Would you prefer it to be just the first
>> part of the commit message: `Add the AT91SAM9260 serial compatibles to
>> the list of SAM9X60 compatibles`? That way it would really only be what
>> the commit does.
> 
> Let me rephrase it:
> 
> What your commit is doing is requiring additional fallback compatibles.
> Therefore the commit msg should answer - why do you require additional
> fallback compatibles?
> 


The additional fallback compatibles are required because the driver in 
question only knows about the atmel,at91sam9260-usart compatible. 
Furthermore, it is also a better representation of the fact that the 
serial IP of 9x60 is an improvement over the serial IP of 9260 (it 
contains more hardware features not yet implemented in the driver).


> Incremental characteristics sound to me optional. I can increment
> sam9x60 with something or I can skip it. But you are not doing it...
> sam9x60 was already there and now you require a fallback.
> 
> Best regards,
> Krzysztof

So, what is your opinion on the following commit message:

"Fix sam9x60 compatible list by adding the sam9260 compatibles as 
fallback, since the atmel_serial driver only knows of the latter's 
compatible. The atmel_serial driver only has knowledge of the sam9260 
compatible because it does not have the sam9x60's serial IP specific 
features implemented yet and adding an empty compatible without adding 
support specific to that compatible would be misleading. Thus prefer the 
fallback mechanism in the detriment of adding an empty compatible in the 
driver."

Thanks,
	Sergiu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ