[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161122222712.GA53509@google.com>
Date: Tue, 22 Nov 2016 14:27:13 -0800
From: Brian Norris <briannorris@...omium.org>
To: Eduardo Valentin <edubezval@...il.com>
Cc: Zhang Rui <rui.zhang@...el.com>, Heiko Stuebner <heiko@...ech.de>,
linux-pm@...r.kernel.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org, Caesar Wang <wxt@...k-chips.com>,
Stephen Barber <smbarber@...omium.org>
Subject: Re: [PATCH 1/3] thermal: handle get_temp() errors properly
On Tue, Nov 22, 2016 at 03:00:47AM -0800, Eduardo Valentin wrote:
> On Tue, Nov 22, 2016 at 03:52:25PM +0800, Zhang Rui wrote:
> > On Fri, 2016-11-18 at 21:30 -0800, Brian Norris wrote:
> > > On Fri, Nov 18, 2016 at 07:41:59PM -0800, Eduardo Valentin wrote:
> > > > I would prefer we consider the patch I sent
> > > > some time ago:
> > > > https://patchwork.kernel.org/patch/7876381/
> > > Honestly I didn't look that deeply into the framework here (and I
> > > also
> > > don't use CONFIG_THERMAL_EMULATION), I was just fixing something that
> > > was obviously wrong.
>
> Yeah, but that is why we need people to look the code considering all
> features. :-)
Well, there are bugfixes and there are features. My patch fixed the bug
in the simplest way possible; it didn't break CONFIG_THERMAL_EMULATION
any further than it already was, and it'll still work if get_temp()
doesn't return an error.
I'd say your patch is essentially adding a feature, and IMO that's not
the best way to fix a bug. You can fix the bug and *then* add the
feature.
Anyway, I'm not going to tell you how to run your subsystem. If your
patch goes through, that's probably just as well.
[...]
> > hmmm, I forgot why I missed this one in the end.
> > Eduardo,
> > would you mind refresh and resend the patch?
>
> Yeah sure. I have at least three extra patch sets on thermal core on
> my queue. But I would like to get first the thermal sysfs reorg in
> first. This fix is one of the changes that will go on top of the thermal
> sysfs reorg.
So, the bugfix depends on feature work? I guess I'll check back in
another year to see what the status of the bugfix is :)
Brian
Powered by blists - more mailing lists