linux-kernel - Re: [resend rfc v3] pwm: add BCM2835 PWM driver

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]

Message-ID: <20140929053311.GA12506@ulmo>
Date:	Mon, 29 Sep 2014 07:33:13 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Bart Tanghe <bart.tanghe@...masmore.be>, tim.kryger@...aro.org,
	linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org,
	linux-rpi-kernel@...ts.infradead.org
Subject: Re: [resend rfc v3] pwm: add BCM2835 PWM driver

On Fri, Sep 26, 2014 at 08:45:57AM -0600, Stephen Warren wrote:
> On 09/26/2014 01:11 AM, Thierry Reding wrote:
> >On Thu, Sep 04, 2014 at 09:06:48AM -0600, Stephen Warren wrote:
[...]
> >>Oh dear. It sounds like we need at least some form of clock driver for the
> >>platform then. I still don't think there's complete documentation for the
> >>HW, even though a lot of register docs were published which presumably cover
> >>the clock HW? Equally, given that the VC firmware assumes it owns most of
> >>the HW, it seems best to manipulate the clocks through the firmware
> >>interface rather than directly touching the HW. Unfortunately, I don't
> >>believe there's any ABI guarantee on the firmware interface. Perhaps we can
> >>get one?
> >
> >Urgs... this VC firmware seems to be more of a headache that I thought
> >it was. How is this handled in other drivers? Surely PWM isn't the first
> >one that needs clocks?
> 
> For the other clocks, I've set up dummy fixed-rate clocks in the DT and/or
> "clock driver" code to satisfy references by phandle or clock name
> respectively. Since the other drivers don't actually manipulate the clock
> rates etc., this is enough for the drivers.

Given that this driver only queries the clock frequency adding a fixed-
rate clock to the device tree should work as well. Then the calls to
clk_prepare_enable() and clk_disable_unprepare() can still be added as
appropriate so that the driver doesn't need to change if a proper clock
driver ever gets added.

Or am I missing anything? Perhaps the issue is that the default clock
rate for the PWM clock isn't usable? That would still not prevent the
driver from being merged.

Thierry

Content of type "application/pgp-signature" skipped