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:	Mon, 21 Mar 2016 17:44:37 +0000 (UTC)
From:	Paul Walmsley <paul@...an.com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>
cc:	tony@...mide.com, jarkko.nikula@...mer.com, t-kristo@...com,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 0/3] ARM: OMAP3: Fix McBSP2/3 hwmod setup for
 sidetone

Hi Péter,

On Mon, 21 Mar 2016, Peter Ujfalusi wrote:

> On 03/19/16 21:38, Paul Walmsley wrote:
> > On Fri, 18 Mar 2016, Peter Ujfalusi wrote:
> > 
> >> Hi,
> >>
> >> Chanes since v1:
> >> - removed the ASoC patch as Mark has applied it already
> >> - Added my signed-off to the hwmod patch
> >> - New patch to handle the case when the sidetone hwmod has been removed for
> >>   legacy boot.
> >>
> >> The series addresses a long standing issue with McBSP2/3 regarding to hwmod
> >> setup. When booting with DT a warning is printed that mcbsp2/3 is using two
> >> hwmod.
> >> The root of the issue is the way how the hwmod data was constructed in the first
> >> place for OMAP3 McBSP2/3.
> >> After re-reading the TRM it is clear that the sidetone should not have it's
> >> own hwmod data as it is not a separate IP, it is part of the McBSP module. It
> >> can not affect PRCM either since it's SYSCONFIG register's AUTOIDLE bit is only
> >> sets the autoidle from the internal McBSP_iclk clock to the sidetone block of
> >> the same McBSP.
> > 
> > NAK, at least without further discussion - see my comments on the v1 0/3 
> > introduction.
> 
> Yes, I could have sent the first series as RFC, but I believe(d) that this is
> the correct way to fix the McBSP sidetone integration.

Yep not a problem.  You're handling the process correctly.  There's no 
need to send things as an RFC unless you are unsure. 

What you and I are doing now is exactly how the discussion and review 
process is supposed to work.


- Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ