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
| ||
|
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
Powered by blists - more mailing lists