linux-kernel - Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn

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:	Wed, 21 Mar 2012 09:07:31 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	"Turquette, Mike" <mturquette@...com>
Cc:	Saravana Kannan <skannan@...eaurora.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Andrew Lunn <andrew@...n.ch>,
	Grant Likely <grant.likely@...retlab.ca>,
	Jamie Iles <jamie@...ieiles.com>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Magnus Damm <magnus.damm@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>,
	linux-arm-kernel@...ts.infradead.org,
	Arnd Bergman <arnd.bergmann@...aro.org>,
	linux-arm-msm@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Zhao <richard.zhao@...aro.org>,
	Shawn Guo <shawn.guo@...escale.com>,
	Paul Walmsley <paul@...an.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-kernel@...r.kernel.org,
	Amit Kucheria <amit.kucheria@...aro.org>
Subject: Re: [PATCH 1/2] clk: Fix error handling in fixed clock hardware
	type register fn

On Tue, Mar 20, 2012 at 10:45:36PM -0700, Turquette, Mike wrote:
> IIRC, that discussion was with respect to the .parent member of struct
> clk.  It was decided that having .parent = NULL does not imply that a
> clock is a root clock, but instead we rely on the CLK_IS_ROOT flag.  I
> can't think of any other instance where a NULL clk when returned from
> a registration function would be useful.

No.  What I've been saying is that in _drivers_ which use clk_get(),
the error range is defined by IS_ERR(clk).  Every other value of
clk must be assumed by the driver to be valid, no ifs or buts.

What the clk API assumes about struct clk is its own business.  If it
wishes to interpret the NULL clk in a specific way, that's its business
to do so.  But it's still not the drivers business to then go and
interpret NULL as being any different from any other valid clock.

This is part of the clk API contract, which is as I said in the first
paragraph, and I keep on saying.  I'm not sure what's so difficult
about this.
--
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/