[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f15d3e1c-1b53-f390-78e2-6a88c77aed05@axentia.se>
Date: Wed, 21 Nov 2018 06:06:41 +0000
From: Peter Rosin <peda@...ntia.se>
To: Guenter Roeck <linux@...ck-us.net>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jean Delvare <jdelvare@...e.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
"linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/2] hwmon: (ntc_thermistor): add support for B57891S0103
from Epcos
On 2018-11-19 22:28, Guenter Roeck wrote:
> On Mon, Nov 19, 2018 at 09:16:12PM +0000, Peter Rosin wrote:
>>>
>>> Guess I deserve the non-alphabetic order as penalty for not enforcing it
>>> earlier. I'll accept the patch after DT approval and submit another one
>>> myself afterwards to restore alphabetic order.
>>
>> Right, I'm thinking another good change would be to introduce an enum
>> into the ntc_thermistor_id array, because the hard-coded numbering in
>
> Yes, sounds like a good idea.
>
>> the ntc_match variable is a bit fragile in my taste, and that list would
>> also benefit from being alphabetic. Currently there's simply no way to
>> add things in the middle without causing mayhem. I thought about doing
>> that, but didn't want to waste energy doing it up front without knowing
>> if it would be well received (the driver might have been superseded or
>
> It would.
Right, so I have some patches sorting things out... However, one question
before I send them: Is it ok to sort the enum ntc_thermistor_type in the
include/linux/platform_data/ntc_thermistor.h header or will that break
stuff?
Cheers,
Peter
> Guenter
>
>> something). I'm glad that you have volunteered to clean things up.
>> Ha! :-)
>>
>> Cheers,
>> Peter
>>
>>> Guenter
>>>
>>>> };
>>>>
>>>> struct ntc_thermistor_platform_data {
>>>> --
>>>> 2.11.0
>>>>
>>
Powered by blists - more mailing lists