linux-kernel - Re: [RFC] Common clock framework for external clock generators

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:	Sun, 13 May 2012 18:30:55 +0200
From:	Sebastian Hesselbarh <sebastian.hesselbarth@...glemail.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	linux-kernel@...r.kernel.org, mturquette@...com
Subject: Re: [RFC] Common clock framework for external clock generators

On 05/13/2012 02:29 PM, Mark Brown wrote:
> Always CC maintainers on mails, things get lost on high volume lists.

Yeah, right after posting I thought of this but didn't want to bother
you again. I read a lot of kernel code since then and some things are
much more clearer to me now. Besides the driver is almost done now and
works as expected. Will have to clean up things and will post it as
a patch then.

> I'd suggest using regmap for the cache support (which helps with
> read/modify/write cycles) and because...

I will have a look at regmap before I post a new driver patch for
sure.

>> static const struct clk_ops si5351_xtal_ops = {
>> 	.enable = si5351_xtal_enable,
>> 	.disable = si5351_xtal_disable,
>
> These should be prepare() and unprepare() - enable() and disable() are
> called from atomic context so you can't do I2C I/O.

You are right. The kernel code states this correctly and I should have
read it more carefully.

>> static u8 si5351_clkout_get_parent(struct clk_hw *hw)
>> {
>> 	struct si5351_driver_data *sidata = si5351_clkout_get_data(hw);
>> 	return 0;
>> }
>
> If we need empty functions like this we should fix the framework.

Of course, this function is not empty at all but wasn't done at the
time I posted the RFC.

One question that remains from my original RFC is the missing
clk_unregister() as i2c can be removed there also should be an
function to unregister previously registered clocks?

Sebastian
--
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/