linux-kernel - Re: [PATCH v3 01/23] dt-bindings: ata: ahci-platform: Drop dma-coherent property declaration

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, 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