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:	Tue, 26 Apr 2016 18:49:13 +0100
From:	Peter Griffin <peter.griffin@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	srinivas.kandagatla@...il.com, maxime.coquelin@...com,
	patrice.chotard@...com, vinod.koul@...el.com, lee.jones@...aro.org,
	dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
	arnd@...db.de, ludovic.barre@...com, arnaud.pouliquen@...com
Subject: Re: [PATCH 10/18] ASoC: sti: Update example to include
 assigned-clocks and mclk-fs

Hi Mark,

On Tue, 26 Apr 2016, Mark Brown wrote:

> On Tue, Apr 26, 2016 at 05:14:32PM +0100, Peter Griffin wrote:
> > On Tue, 26 Apr 2016, Mark Brown wrote:
> 
> > > A lot of this is details of the system integration for this SoC, not
> > > actual errors.
> 
> > This particular clock patch yes, but the other ASoC dt doc update is fixing
> > bindings which haven't progressed in lockstep with the driver code. Presumably
> > this happened during the review process when they were changed to being st,
> > prefixed in the driver, but the doc wasn't also updated.
> 
> The bits where you are correcting the names of the properties are not
> details of the system integration and are therefore fine.  The bits
> where you're documenting the particular clocking arrangements for the
> SoC you happen to be using less so.

Ok sounds good. With that in mind I will drop this clocking patch in v4
and just leave the one which updates the ASoC bindings mismatch.

> 
> > > it's fairly routine
> > > to have to explain to people that just because some old driver did
> > > something that doesn't mean it's something we want in new drivers.
> 
> > I'm sure it is. Although I fail to see why leaving the documentation with
> > mistakes in is helpful to anybody.
> 
> Fixing actual mistakes is fine.

Peter.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ