linux-kernel - Re: [PATCH v6 1/9] dt-bindings: dma: dw: Convert DW DMAC to DT binding

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] [day] [month] [year] [list]

Date:   Fri, 19 Jun 2020 20:01:25 +0300
From:   Serge Semin <Sergey.Semin@...kalelectronics.ru>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Serge Semin <fancer.lancer@...il.com>,
        Vinod Koul <vkoul@...nel.org>,
        Viresh Kumar <vireshk@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rob Herring <robh@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Arnd Bergmann <arnd@...db.de>, <linux-mips@...r.kernel.org>,
        dmaengine <dmaengine@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 1/9] dt-bindings: dma: dw: Convert DW DMAC to DT
 binding

On Thu, Jun 18, 2020 at 11:21:53AM +0300, Andy Shevchenko wrote:
> On Thu, Jun 18, 2020 at 2:43 AM Serge Semin
> <Sergey.Semin@...kalelectronics.ru> wrote:
> >
> > Modern device tree bindings are supposed to be created as YAML-files
> > in accordance with dt-schema. This commit replaces the Synopsis
> > Designware DMA controller legacy bare text bindings with YAML file.
> > The only required prorties are "compatible", "reg", "#dma-cells" and
> > "interrupts", which will be used by the driver to correctly find the
> > controller memory region and handle its events. The rest of the properties
> > are optional, since in case if either "dma-channels" or "dma-masters" isn't
> > specified, the driver will attempt to auto-detect the IP core
> > configuration.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>
> > Reviewed-by: Rob Herring <robh@...nel.org>
> > Acked-by: Viresh Kumar <viresh.kumar@...aro.org>
> > Cc: Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
> > Cc: Arnd Bergmann <arnd@...db.de>
> > Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > Cc: linux-mips@...r.kernel.org
> 
> 

> Rob, here are questions to you.

Rob normally is very busy. So I hope you won't mind me answering in his stead.

> 
> > +  dma-channels:
> > +    description: |
> > +      Number of DMA channels supported by the controller. In case if
> > +      not specified the driver will try to auto-detect this and
> > +      the rest of the optional parameters.
> > +    minimum: 1
> > +    maximum: 8
> 
> ...
> 
> > +  multi-block:
> 
> > +      maxItems: 8
> 

> This maximum is defined by above dma-channels property. Is there any
> way to put it in the schema?

Neither Json nor Yaml schema support inter-properties values dependencies
out of box. If it's required, then a back-end must be properly tuned up.
In other words the dt-schema framework should be altered to parse the
"dma-channels" property and to apply the constraint to another property
in accordance with its value.

> 
> ...
> 
> > +  snps,dma-protection-control:
> > +    $ref: /schemas/types.yaml#definitions/uint32
> > +    description: |
> > +      Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting
> > +      indicates the following features: bit 0 - privileged mode,
> > +      bit 1 - DMA is bufferable, bit 2 - DMA is cacheable.
> > +    default: 0
> > +    minimum: 0
> > +    maximum: 7
> 

> AFAIR this is defined by bit flags, does schema have a mechanism to
> define flags-like entries?

Normally a thing like that could be done by means of enum constraints.
But it only works for cases with non-combinable bit-fields, for
instance if there were only either privileged or bufferable or cacheable
modes. Otherwise we would have to describe each combination of the bits
setting, which as you understand would be very clumsy. Seeing there might
be any combination of the HPROT bits setting here we have no choice but
to use the range constraint.

-Sergey

> 
> -- 
> With Best Regards,
> Andy Shevchenko