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:	Wed, 27 Apr 2016 14:00:56 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
Cc:	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Viresh Kumar <vireshk@...nel.org>,
	Vinod Koul <vinod.koul@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dmaengine <dmaengine@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Brown <broonie@...nel.org>,
	Vineet Gupta <vgupta@...opsys.com>, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH v6 2/4] dmaengine: dw: revisit data_width property

On 27-04-16, 11:25, Andy Shevchenko wrote:
> On Wed, Apr 27, 2016 at 9:43 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> > On 25-04-16, 15:35, Andy Shevchenko wrote:
> >> There are several changes are done here:
> >>
> >> - Convert the property to be in bytes
> >>
> >> Besides this is common practice for such property the use of a value in bytes
> >> much more convenient than handling the encoded value.
> >>
> >> - Rename data_width to data-width in the device tree bindings
> >>
> >> - While here, replace dwc_fast_ffs() by __ffs()
> >>
> >> The change leaves the support for old format as well just in case someone will
> >> use a newer kernel with an old device tree blob.
> >>
> >> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> >> ---
> >>  Documentation/devicetree/bindings/dma/snps-dma.txt |  6 ++--
> >>  arch/arc/boot/dts/abilis_tb10x.dtsi                |  2 +-
> >>  arch/arm/boot/dts/spear13xx.dtsi                   |  4 +--
> >>  drivers/dma/dw/core.c                              | 42 ++++++----------------
> >>  drivers/dma/dw/platform.c                          |  5 ++-
> >>  include/linux/platform_data/dma-dw.h               |  2 +-
> >>  6 files changed, 21 insertions(+), 40 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
> >> index c99c1ff..544b9b9 100644
> >> --- a/Documentation/devicetree/bindings/dma/snps-dma.txt
> >> +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
> >> @@ -13,8 +13,8 @@ Required properties:
> >>  - chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
> >>    increase from chan n->0
> >>  - block_size: Maximum block size supported by the controller
> >> -- data_width: Maximum data width supported by hardware per AHB master
> >> -  (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
> >> +- data-width: Maximum data width supported by hardware per AHB master
> >> +  (in bytes, power of 2)
> >>
> >>
> >>  Optional properties:
> >> @@ -38,7 +38,7 @@ Example:
> >>               chan_allocation_order = <1>;
> >>               chan_priority = <1>;
> >>               block_size = <0xfff>;
> >> -             data_width = <3 3>;
> >> +             data-width = <8 8>;
> >>       };
> >
> > You broke backward compatibility with earlier DTs.
> 
> How?
> 
> >
> > What's backward compatibility ?
> >
> > Consider that the DT from an earlier version of kernel is part of the bootrom of
> > a SoC. Now that bootrom should work just fine with any new kernel version. i.e.
> > old DT + new kernels should always work.
> 
> Yes, the property name is slightly different as meaning.
> 
> If we find data-width property driver will use it, otherwise it takes
> old name and converts variable to be in bytes in the driver.

Oh, I missed that you renamed the property and taking care of both the
properties now. Sorry about that. So, you didn't break them for sure :)

But, the DT documentation doesn't contain the old property now but the code
does. I think you are required to keep the bindings currently supported by the
kernel in there. You can mark them deprecated, but can't remove them.

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ