[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091120131855.7f8f8722@hyperion.delvare>
Date: Fri, 20 Nov 2009 13:18:55 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Clemens Ladisch <clemens@...isch.de>
Cc: Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, lm-sensors@...sensors.org
Subject: Re: [PATCH v2] k10temp: temperature sensor for AMD Family 10h/11h
CPUs
On Fri, 20 Nov 2009 12:56:50 +0100, Clemens Ladisch wrote:
> Jean Delvare wrote:
> > On Fri, 20 Nov 2009 11:47:51 +0100, Clemens Ladisch wrote:
> > > v2: Erratum 319 now results in a warning, not an error, because it cannot
> > > be reliably detected; Serge Belyshev reports that his CPU sensor works.
> >
> > Nack. Unreliable sensors -> the default must be to NOT bind to these
> > CPUs. ... Otherwise your driver will _never_ make it into the
> > kernel tree.
>
> Then how did the k8temp driver make it into the kernel tree? :-)
For the K8 family, the history is the other way around: early models
worked fine, while later models did not. So there was no objection to
the k8temp driver initially, there really was no reason for it.
It is much harder to remove a driver from the kernel tree than to add
it. Likewise, it is much harder to reject specific models if you have
been supporting them before, because some users may see it as a
regression. This is the reason why I would like us to be much more
cautious with the family 10h CPU support than we have been for the K8
family. Let us learn from our past errors.
> > Feel free to provide a way to force the bind to happen (and still
> > print a big fat warning that this is a very bad idea), but do NOT make
> > it the default.
>
> Okay, I'll add a force parameter.
> I'd guess k8temp should get the same?
It would make sense, yes, even though you will get complaints from some
users.
--
Jean Delvare
--
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