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: <20131128223719.GG14689@mithrandir>
Date:	Thu, 28 Nov 2013 23:37:19 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Mike Turquette <mturquette@...aro.org>
Cc:	r65073@...escale.com, s.hauer@...gutronix.de,
	swarren@...dotorg.org, t.figa@...sung.com, grant.likely@...aro.org,
	linux@....linux.org.uk, rob@...dley.net, ian.campbell@...rix.com,
	mark.rutland@....com, pawel.moll@....com, rob.herring@...xeda.com,
	linux-arm-kernel@...ts.infradead.org, linux-pwm@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org, Alison Wang <b18965@...escale.com>,
	Jingchang Lu <b35083@...escale.com>,
	Xiubo Li <Li.Xiubo@...escale.com>
Subject: Re: [PATCHv6 1/4] pwm: Add Freescale FTM PWM driver support

On Thu, Nov 28, 2013 at 10:25:11PM +0100, Thierry Reding wrote:
> On Tue, Nov 12, 2013 at 09:36:55AM +0800, Xiubo Li wrote:
[...]
> > +static int fsl_pwm_parse_clk_ps(struct fsl_pwm_chip *fpc)
> > +{
> > +	int ret;
> > +	struct of_phandle_args clkspec;
> > +	struct device_node *np = fpc->chip.dev->of_node;
> > +
> > +	fpc->sys_clk = devm_clk_get(fpc->chip.dev, "ftm0");
> > +	if (IS_ERR(fpc->sys_clk)) {
> > +		ret = PTR_ERR(fpc->sys_clk);
> > +		dev_err(fpc->chip.dev,
> > +				"failed to get \"ftm0\" clock %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	fpc->counter_clk = devm_clk_get(fpc->chip.dev, "ftm0_counter");
> > +	if (IS_ERR(fpc->counter_clk)) {
> > +		ret = PTR_ERR(fpc->counter_clk);
> > +		dev_err(fpc->chip.dev,
> > +				"failed to get \"ftm0_counter\" clock %d\n",
> > +				ret);
> > +		return ret;
> > +	}
> > +
> > +	ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells", 1,
> > +					&clkspec);
> > +	if (ret)
> > +		return ret;
> > +
> > +	fpc->counter_clk_select = clkspec.args[0];
> 
> This isn't at all pretty. But given that once you have access to a
> struct clk there's no way to identify it, I don't know of a better
> alternative.

Hi Mike,

I've seen this crop up a number of times now, to varying degrees of
gravity. In this particular case, the driver needs to know the type of a
clock because it needs to program this hardware differently depending on
which clock feeds the counter. Since there is no way to obtain any kind
of identifying information from a struct clk, drivers need to rely on
hacks like this and manually reach into the device tree to obtain that
information.

I'm aware of similar cases which have been solved by using a mux clock
that takes a set of parents and the .set_parent() operation is then used
to program registers appropriately. However in all those cases, the mux
clock (and the parents) have all been part of a single driver, so I am
not sure if the same would be applicable here.

Do you have any other suggestions on how this could possibly be solved?

Thierry

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ