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: <20220521092248.7i53lxf3gx26fmi5@mobilestation>
Date:   Sat, 21 May 2022 12:22:48 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Jens Axboe <axboe@...nel.dk>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop
 dma-coherent property declaration

On Tue, May 17, 2022 at 01:58:41PM -0500, Rob Herring wrote:
> On Thu, May 12, 2022 at 02:17:48AM +0300, Serge Semin wrote:
> > It's redundant to have the 'dma-coherent' property explicitly specified in
> > the DT schema because it's a generic property described in the core
> > DT-schema by which the property is always evaluated.
> 

> It is not redundant.
> 
> The core schema defines the property (as a boolean), but this schema 
> defines it being used in this binding. Otherwise, it won't be allowed.

I thought that the generic properties like ranges, dma-ranges, etc
including the dma-coherent one due to being defined in the dt-core
schema are always evaluated. As such seeing the unevaluatedProperties
property is set to false here, they can be used in the DT-nodes with
no need to be explicitly specified in the DT node bindings. In
addition to that I tested this assumption by dropping the dma-coherent
property definition from the AHCI-common schema and executed the
DT-bindings check procedure. No error has been spotted:

> [fancer@...ilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml | grep dma-coherent
>        dma-coherent;
> [fancer@...ilestation] kernel $ make -j8 DT_SCHEMA_FILES=Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml dt_binding_check
>   LINT    Documentation/devicetree/bindings
>   DTEX    Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts
>   CHKDT   Documentation/devicetree/bindings/processed-schema.json
>   SCHEMA  Documentation/devicetree/bindings/processed-schema.json
>   DTC     Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
>   CHECK   Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dtb
> [fancer@...ilestation] kernel $ cat Documentation/devicetree/bindings/ata/snps,dwc-ahci.example.dts | grep dma-coherent
>           dma-coherent;
> [fancer@...ilestation] kernel $ echo $?
> 0

Due to that here are a few backward questions:
1) Am I doing something wrong in the framework of the DT-bindings
evaluation? Really I even tried to specify unknown property in the
DT-bindings example like "bla-bla-bla;" and no evaluation error was
printed. Anyway If what you are saying was correct I would have got an
error during the DT-bindings evaluation, but as you can see there was
none.
2) Am I wrong in thinking that the unevaluatedProperties setting
concerns the generic properties defined in the DT-core schema? If it
doesn't concern the generic properties then does it work for the
$ref'ed schemas only? 


Getting back to the patch topic. We need to drop the dma-coherent
property from the schema anyway. AHCI-specification doesn't
regulate the DMA operations coherency. The dma-coherent property is
more specific to the particular controller implementation mainly
dependent on the platform settings. So I'll change the patch log, but
get to keep the patch in the series. What do you think?

-Sergey

> 
> Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ