[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1424695015.14897.5.camel@linux.intel.com>
Date: Mon, 23 Feb 2015 14:36:55 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Lee Jones <lee@...nel.org>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
linux-kernel@...r.kernel.org, Stephen Boyd <sboyd@...eaurora.org>,
Mike Turquette <mturquette@...aro.org>,
Bryan Huntsman <bryanh@...eaurora.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Ralf Baechle <ralf@...ux-mips.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>
Subject: Re: [PATCH v2 1/1] clkdev: change prototype of clk_register_clkdev()
On Mon, 2015-02-23 at 12:23 +0000, Lee Jones wrote:
> On Mon, 23 Feb 2015, Russell King - ARM Linux wrote:
>
> > On Mon, Feb 23, 2015 at 11:53:56AM +0000, Lee Jones wrote:
> > > On Mon, 23 Feb 2015, Andy Shevchenko wrote:
> > > > arch/arm/mach-msm/clock-pcom.c | 9 +++++----
> > > > arch/arm/mach-vexpress/spc.c | 5 ++++-
> > > > arch/mips/ath79/clock.c | 6 +++---
> > > > drivers/clk/clk-bcm2835.c | 12 +++++++-----
> > > > drivers/clk/clk-max-gen.c | 9 ++++-----
> > > > drivers/clk/clk-xgene.c | 6 +++---
> > > > drivers/clk/clkdev.c | 15 ++++++++++-----
> > > > drivers/clk/samsung/clk-pll.c | 13 ++++++++-----
> > > > drivers/clk/samsung/clk-s3c2410-dclk.c | 19 +++++++++---------
> > > > drivers/clk/samsung/clk.c | 35 +++++++++++++++++++---------------
> > > > include/linux/clkdev.h | 2 +-
> > > > 11 files changed, 75 insertions(+), 56 deletions(-)
> > >
> > > What's tying all of these changes together? It would be better
> > > (simpler for you) if you split them up by subsystem and resubmitted.
> >
> > I think maybe, just maybe, you might get the answer to that if you read
> > the patch.
> >
> > You can't change the function signature without creating lots of warnings
> > and causing regressions.
> >
> > Yes, the function could be renamed whilst doing this change, but that's
> > really quite sub-standard in an already busy namespace.
>
> Okay, I can go with that.
>
> If I'm reading this patch correctly, it doesn't actually fix
> anything.
Right. Consider this as a stage 1 that allows you to make a proper fix
on an actual use case.
> What's the thinking behind stopping short? Why don't you go
> the extra inch and free the resources at the appropriate times?
As far as I can see most of the cases are for whole OS time to live,
means no need to free resources. The really affected users should know
by themselves and I'm not going to brainlessly fix every usage of the
clkdev_register() (note most of them [> 90% use cases?] even didn't
check the return code).
--
Andy Shevchenko <andriy.shevchenko@...el.com>
Intel Finland Oy
--
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/
Powered by blists - more mailing lists