linux-kernel - Re: broken subject?

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]

Date:   Sat, 11 Mar 2023 18:57:18 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Sergey Lisov <sleirsgoevy@...il.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jaehoon Chung <jh80.chung@...sung.com>
Cc:     linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: broken subject?

On 11/03/2023 18:40, Sergey Lisov wrote:
>>> ---
>>>  .../devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml    | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>

Why did you remove the subject? Please keep the mailing process matching
mailing lists. It messes with mailboxes, filters and reading process.

>>> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> index 8dfad89c7..2bc5ac528 100644
>>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> @@ -57,6 +57,12 @@ properties:
>>>        force fifo watermark setting accordingly.
>>>      $ref: /schemas/types.yaml#/definitions/flag
>>>  
>>> +  fifo-access-32bit:
>>
>> Missing type boolean.
> 
> Thanks, will add the same $ref as for the entry above.
> 
>>> +    description:
>>> +      Specifies that this device requires accesses to its 64-bit registers
>>> +      to be done as pairs of 32-bit accesses, even on architectures where
>>> +      readq is available.
>>
>> And why the device would require this? If it has 64-bit registers in the
>> first place, they can be accessed in 64-bit. Otherwise these are not
>> 64-bit registers, but just lower/upper 32-bit, right?
>>
>> Also, why this cannot be implied from compatible? Why different boards
>> with same SoC should have different FIFO access?
> 
> It probably can be implied, but I am not exactly sure on which boards it
> affects, so I decided to go for a new devicetree option. Anyway, the same
> argument applies to the "data-addr" property, which is already in the
> spec, so I supposed that adding such knobs is fine.

Yeah, Rob acked it so I will let him to judge this. To me it looks like
unnecessary fragmentation - this looks like compatible specific, not
board. Anyway you need to resend to fix all the mailing mess.

Best regards,
Krzysztof