linux-kernel

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 09:40:37 -0800 (PST)
From:   Sergey Lisov <sleirsgoevy@...il.com>
To:     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

> > ---
> >  .../devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml    | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > 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.