linux-kernel - Re: [PATCH v3 02/11] clk: davinci

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]

Date:	Mon, 25 Mar 2013 12:20:49 +0530
From:	Sekhar Nori <nsekhar@...com>
To:	Mike Turquette <mturquette@...aro.org>
CC:	<davinci-linux-open-source@...ux.davincidsp.com>,
	<linux@....linux.org.uk>, <sshtylyov@...sta.com>, <arnd@...db.de>,
	Kevin Hilman <khilman@...prootsystems.com>,
	<linus.walleij@...aro.org>, <linux-kernel@...r.kernel.org>,
	<rob.herring@...xeda.com>, <linux-keystone@...t.ti.com>,
	<viresh.linux@...il.com>, <akpm@...ux-foundation.org>,
	<shawn.guo@...aro.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 02/11] clk: davinci - add PSC clock driver

Hi Mike,

On 3/23/2013 2:07 AM, Mike Turquette wrote:
> Quoting Sekhar Nori (2013-03-22 04:20:28)
>> Mike,
>>
>> On 11/28/2012 6:52 PM, Sekhar Nori wrote:
>>> On 11/27/2012 10:59 PM, Mike Turquette wrote:
>>
>>>> Also have you looked into regmap?  Since you are defining your own clock
>>>> type that might be something nice for you.
>>>
>>> No, haven't looked at regmap yet. Will look at that.
>>
>> I could get to this only now. regmap needs a valid struct device. We
>> aren't modelling psc clocks as device so regmap cannot be used here.
>>
> 
> According to Murali's reply back in November it was still not known if
> the PTCMD register was going to be concurrently accessed by sources
> outside the clock framework.  If this is so then neither the existing

I can confirm that PTCMD is a PSC specific register and it is not
accessed outside of clock framework.

> framework-level lock (e.g. enable_lock) nor the shared clock driver lock
> (e.g. spinlock in struct clk_psc) are adequate.  You may need a device
> driver which represents the PSC and use accessor functions to write to
> those register which provide coordination.

Well the only reason to access *any* PSC register outside of clock
framework would be to handle the corner case where DSP needs to be reset
using its PSC.

In this case, there needs to be an access to MDCTL register specific to
that module (ie the DSP). Right now this functionality is implemented
using the function davinci_psc_reset().

When moving to common clock framework, I think this can be moved to
drivers/clk/davinci/clk-psc.c (it will be similar to the way
tegra_periph_reset() is handled in drivers/clk/tegra/clk-periph-gate.c).

And in this case I do agree we need a spinlock local to clk-psc.c (like
the periph_ref_lock spinlock used in tegra implementation). That said,
the current series only enables DM644x and does not really implement the
reset stuff needed for DA850. So we can either add the spinlock now, or
defer it to later when DA850 get supported (so there is a clear history
trace of why it was added).

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/