linux-kernel - Re: [PATCH 2/2] clkdev: Implement managed clk

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, 2 Apr 2012 19:05:47 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Mike Turquette <mturquette@...com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] clkdev: Implement managed clk_get()

On Mon, Apr 02, 2012 at 06:34:12PM +0100, Mark Brown wrote:
> On Mon, Apr 02, 2012 at 06:04:43PM +0100, Russell King - ARM Linux wrote:
> > On Sun, Apr 01, 2012 at 12:32:40PM +0100, Mark Brown wrote:
> > > Allow clk API users to simplify their cleanup paths by providing a
> > > managed version of clk_get().
> 
> > > Due to the lack of a standard struct clk to look up the device from a
> > > managed clk_put() is not provided, it would be very unusual to use this
> > > function so it's not a big loss.
> 
> > Err, why?  The contents of struct clk has nothing to do with clk_put().
> > You're doing something really wrong here.
> 
> It does for a devm_clk_put().  Normally this would end up being:
> 
> 	void devm_clk_put(struct clk *clk);
> 
> but the devres stuff needs us to have a struct device to get the
> underlying allocation/mapping and undo it.

So why can't we do:

	void devm_clk_put(struct device *, struct clk *);

just like other interfaces which free up devres stuff take a struct device.

> Probably what would actually end up
> happening is that we'd instead have a signature like:
> 
> 	devm_clk_put(struct device *dev, struct clk *clk);
> 
> but I didn't particularly feel like making that decision right now,
> especially if we do end up going with per user allocations and can use
> the more idiomatic signature.

Well that's what other subsystems do, so I see no reason to be different.
To be different would make us intentionally different from other
implementations which would be bad - and means that we're more reliant
on the underlying clk implementation.

That's bad news, especially for something that's going to end up being
used in multiple drivers (in terms of fixing the API if the underlying
implementation changes.)

Given that we're at this cross-roads already, just pass the struct device
and be done with it.
--
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/