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]
Message-ID: <20170620084517.giq3zhvbmhpx7pge@flea.lan>
Date:   Tue, 20 Jun 2017 10:45:17 +0200
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Vinod Koul <vinod.koul@...el.com>
Cc:     Icenowy Zheng <icenowy@...c.io>,
        linux-arm-kernel@...ts.infradead.org, Chen-Yu Tsai <wens@...e.org>,
        linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com,
        Icenowy Zheng <icenowy@...c.xyz>, dmaengine@...r.kernel.org
Subject: Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in
 sun8i's DMA engines a common quirk

On Thu, Jun 15, 2017 at 09:24:08AM +0530, Vinod Koul wrote:
> On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
> > On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > > > SoC info is in compatible, so there's no reason to make it a property.
> > > 
> > > that's why it would need to be optional for the SoC's that needs these..
> > 
> > There's nothing optional about that behaviour, it's mandatory for the
> > SoC that need it, and useless on the SoC that don't.
> 
> And why should kernel put strings for each hw behaviour.

You will have strings in the kernel for each hw behaviour,
disregarding on whether you base the behaviour on the compatible or a
set of properties. In fact, you will have *much* more strings in the
kernel in the latter case.

> I am expecting DT to tell me if this SoC is a special case or not
> and kernel shall handle accordingly

How is this not the case here?

The DT tells you that this SoC is a special case through a compatible
already.

> > Plus, that would require changing the DT binding, which isn't
> > something we can do.
> 
> Any reason why bindings can't change..? I though this was support for new
> SoC...

No, this is a rework of an existing code to support a new SoC. The
code is already there, and the binding too. It has been for 3 years.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ