linux-kernel - Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

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: <alpine.DEB.2.02.1602181718560.4792@utopia.booyaka.com>
Date:	Thu, 18 Feb 2016 17:21:28 +0000 (UTC)
From:	Paul Walmsley <paul@...an.com>
To:	"Franklin S Cooper Jr." <fcooper@...com>
cc:	"R, Vignesh" <vigneshr@...com>, Tero Kristo <t-kristo@...com>,
	Thierry Reding <thierry.reding@...il.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Benoit Cousson <bcousson@...libre.com>,
	Tony Lindgren <tony@...mide.com>,
	Russell King <linux@....linux.org.uk>,
	Mike Turquette <mturquette@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>, linux-pwm@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-clk@...r.kernel.org
Subject: Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

Hi Franklin, 

On Thu, 18 Feb 2016, Franklin S Cooper Jr. wrote:

> On 02/18/2016 12:58 AM, Paul Walmsley wrote:
>
> > OK I'm not sure I understand what's going on, particularly the part about 
> > locking and unlocking.  Are you saying that the pwm_bl driver calls into 
> > the pwm_tiecap module to write to the PWMSS_CLKCONFIG registers to ungate 
> > the ECAP clock, and then the hardware silently ignores the write?  If 
> > that's the case, shouldn't we be seeing some warning messages from a 
> > failure to ungate the clock from a subsequent PWMSS_CLKSTATUS poll?  Or am 
> > I misunderstanding what's going on here?
> Pwm-tipwmss.c exports a function
> pwmss_submodule_state_change which interacts with
> PWMSS_CLKCONFIG and PWMSS_CLKSTATUS registers. Both
> pwm-tiehrpwm.c and pwm-tiecap.c calls this exported function
> to unlock the gate at probe time and lock the gate when the
> driver is removed.
> 
> So when the gate fails to be unlocked after it previously is
> locked there isn't a way to know this via the
> PWMSS_CLKSTATUS registers.

OK I understand now.  Sounds like the gating -> ungating transition is 
effectively a one-time operation, and once the ungating -> gating 
transition is done, there's no way to reverse it.  Please correct me if 
I've got it wrong.

>  So the driver "believes" that the gate is unlocked and when pwm_bl runs 
> it calls the set_polarity function. Set_polarity in the case of AM437x 
> gp evm maps to the ecap's ecap_pwm_set_polarity function call. This call 
> then attempts to write to the ecap registers which results in the 
> external abort since the clock to the ecap is still gated.
>
> When the ecap and tihrpwm driver request to unlock the clock
> gate it already checks the XXX_CLK_EN_ACK bitfields within
> CLKSTATUS and it shows that the clocks "should" be unlocked.
> So there is an issue with the IP.

OK

> Yes, I plan on addressing the change Vignesh acknowledged
> regarding changing RESETSTATUS to SOFTRESET. For your other
> comments I believe he already explained why it has to be set
> in that particular way. If there is anything that I missed
> or something that isn't clear please let me know.

Perfect, thanks for the good description and the followup.


- Paul