On Mon, 18 Jun 2085 15:57:19 +, amy.s...@advantech.com.tw wrote:
> (...)
I suggest you fix your system clock ;-)
--
Jean Delvare
SUSE L3 Support
and
enable the feature unconditionally. It doesn't do anything until the
user explicitly starts twiddling with sysfs attributes anyway.
Signed-off-by: Jean Delvare
---
drivers/hwmon/Kconfig |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
--- linux-5.2.orig/drivers/hwmon/Kconfig
/hwmon/adm1029.c| 10 --
> drivers/hwmon/adt7411.c| 5 +
> drivers/hwmon/adt7475.c| 5 +
> drivers/hwmon/iio_hwmon.c | 5 +
> drivers/hwmon/max197.c | 5 +
> drivers/hwmon/scpi-hwmon.c | 10 +-
> 6 files changed, 5 insertions(+), 35 delet
piled and stored,
no, thank you. Another code checker could legitimately complain about
that actually.
IMHO if code checkers return false positives then they are not helping
us and should not be used in the first place.
--
Jean Delvare
SUSE L3 Support
ested-by: Jani Nikula
The line above appears to be truncated.
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/hwmon/index.rst | 316 +-
> 1 file changed, 158 insertions(+), 158 deletions(-)
--
Jean Delvare
SUSE L3 Support
On Wed, 10 Apr 2019 13:02:32 -0500, Eddie James wrote:
> On 4/10/19 5:47 AM, Jean Delvare wrote:
> > Instead of duplicating the common code into the 2 (binary) drivers,
> > move the common code to a separate module. This is cleaner.
> >
> > Signed-off-by: Jean Delvare
These drivers are for a BMC inside PowerPC servers. The BMC runs on
ARM hardware, so only propose the drivers on this architecture, unless
build-testing.
Signed-off-by: Jean Delvare
Cc: Eddie James
Cc: Guenter Roeck
---
If PowerPC BMCs are ever based on another architecture and these drivers
Instead of duplicating the common code into the 2 (binary) drivers,
move the common code to a separate module. This is cleaner.
Signed-off-by: Jean Delvare
Cc: Eddie James
Cc: Guenter Roeck
---
Eddie, can you please give it a try and confirm it works?
Note: I kept the module names
Don't propose PowerPC-only drivers on other architectures, unless
build-testing.
Also drop configuration symbol SENSORS_OCC which serves no purpose
that I can see.
Signed-off-by: Jean Delvare
Cc: Eddie James
Cc: Guenter Roeck
---
SENSORS_OCC *would* serve a purpose if the common code between
Hi Ondřej,
On Tue, 18 Dec 2018 18:06:00 +0100, Ondřej Lysoněk wrote:
> On 16. 12. 18 12:43, Jean Delvare wrote:
> > Would you consider quickly releasing lm-sensors 3.5.1 with the proper
> > library version number, to save all that work to all application
> > authors/maintai
with a patch
reverting the undue soname change. I used "4.5.0" instead. I intend to
carry this patch for as long as I have to. This goes against our policy
of sticking to upstream as much as possible, but in this specific case,
I consider it the least of 2 evils.
Thanks,
--
Jean Delvare
SUSE L3 Support
On Mon, 17 Dec 2018 10:46:43 +0100, Ondřej Lysoněk wrote:
> On 16. 12. 18 12:43, Jean Delvare wrote:
> > You have recently released lm-sensors 3.5.0 with a new soname for
> > libsensors:
> >
> > -LIBMAINVER := 4
> > -LIBMINORVER := 4.0
> > +
releasing lm-sensors 3.5.1 with the proper
library version number, to save all that work to all application
authors/maintainers and distribution package maintainers?
Thanks,
--
Jean Delvare
SUSE L3 Support
sensors
does not offer an API for it. I remember writing a libsensors-based
name look-up tool years ago. I'm a bit in a hurry but I have copied
what I have at:
http://jdelvare.nerim.net/devel/lm-sensors/patches/
Maybe we can revive the idea if there is a need.
--
Jean Delvare
SUSE L3 Support
pace at empty line).
>
> Signed-off-by: Guenter Roeck
> ---
> drivers/hwmon/lm92.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
> (...)
Reviewed-by: Jean Delvare
Thanks Guenter,
--
Jean Delvare
SUSE L3 Support
* intentional */
> + /* fall through */
Do you know which -Wimplicit-fallthrough level we will be using? Level
1 would be happy with the initial comment, no change would be needed.
If level 2-4 then yes the change is needed.
> default:
> reg = nct6775_read_va
t; - /* max6635 could be added here */
> + { "lm92", lm92 },
> + { "max6635", max6635 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, lm92_id);
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t;max6635", max6635 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, lm92_id);
As the driver doesn't treat the two devices differently, the enum isn't
really needed. I don't really mind though, just a notice.
Reviewed-by: Jean Delvare <jdelv...@suse.de>
Please also updat
o if register LM92_REG_MAN_ID does not contain
any useful value on the MAX6635, I would rather drop auto-detection of
these devices altogether, and only support them when explicitly
instantiated.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This tree has not been used for over a year, Guenter is taking all
the hwmon patches in practice.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Guenter Roeck <li...@roeck-us.net>
---
MAINTAINERS |1 -
1 file changed, 1 deletion(-)
--- linux-4.14.orig/MAINTAINERS 2017
le changed, 16 deletions(-)
> (...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
(and heartily approved - thanks for doing that)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
Mor
On Tue, 31 Oct 2017 16:21:46 +0200, Andy Shevchenko wrote:
> Since i2c_unregister_device() became NULL-aware we may remove duplicate
> NULL check.
>
> Cc: Rudolf Marek <r.ma...@assembler.cz>
> Cc: Jean Delvare <jdelv...@suse.com>
> Cc: Guenter Roeck <li..
On Tue, 31 Oct 2017 16:21:44 +0200, Andy Shevchenko wrote:
> Since i2c_unregister_device() became NULL-aware we may remove duplicate
> NULL check.
>
> Cc: Marc Hulsman <m.huls...@tudelft.nl>
> Cc: Jean Delvare <jdelv...@suse.com>
> Cc: Guenter Roeck <li..
On Tue, 31 Oct 2017 16:21:43 +0200, Andy Shevchenko wrote:
> Since i2c_unregister_device() became NULL-aware we may remove duplicate
> NULL check.
>
> Cc: Jean Delvare <jdelv...@suse.com>
> Cc: Guenter Roeck <li...@roeck-us.net>
> Cc: linux-hwmon@vger.kernel.org
&g
> - }
> + tmp102->ready_time = jiffies + msecs_to_jiffies(CONVERSION_TIME_MS);
>
> hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name,
> tmp102,
Thanks for the quick fix. The change itself looks good but why remove
the comment, which
Function snprintf already cares for the terminating NUL at the end of
the string, the caller doesn't need to do it.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Andrea Merello <andrea.mere...@gmail.com>
Cc: Guenter Roeck <li...@roeck-us.net>
---
drivers/hwmo
= { .attrs = in5_attrs };
> +static const struct attribute_group vid_attr_group = { .attrs = vid_attrs };
>
> static int adt7475_detect(struct i2c_client *client,
> struct i2c_board_info *info)
Looks good to me.
Reviewed-by: Jean Delvare <jdelv...@suse.de>
es. If you just do what libsensors does, you'll be
on the safe side.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 4 May 2017 11:35:06 +0200, Jean Delvare wrote:
> There is no reason to treat the IT8705F differently during device
> detection. If a single IT8705F chip indeed answers to both Super-IO
> addresses, we have code in place to detect the duplicate device
> address and skip th
straight: we will not take any patch from you. You are
an annoyance we don't need. Do not waste our time. Go away.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Guenter,
On Sun, 9 Apr 2017 08:24:07 -0700, Guenter Roeck wrote:
> On Sun, Apr 09, 2017 at 03:38:06PM +0200, Jean Delvare wrote:
> > On Tue, 21 Mar 2017 10:05:03 -0700, Guenter Roeck wrote:
> > > I'll submit the patch as-is upstream; at least it doesn't break anything.
>
to v.4.10,
shouldn't it go to stable@?
As a side note, I think the second half of the patch is redundant, it
only makes registration slightly faster on IT8705F, and could have bad
side effects at least in theory. The first half seems sufficient to
me...
--
Jean Delvare
SUSE L3 Support
--
To un
Jean, that was easy.
You're welcome, glad I could help :-)
> Looking forward to see it in some future kernel.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
final buffer.
>
> The idea was that the called code would return a pointer to a constant string,
> ie one that isn't changing from call to call.
In that case, what about the following change?
Subject: hwmon: Constify str parameter of hwmon_ops->read_string
The read_string callback is sup
u could give a try to this
standalone driver:
http://jdelvare.nerim.net/devel/lm-sensors/drivers/dell-smm-hwmon/
Instructions are at:
http://jdelvare.nerim.net/devel/lm-sensors/drivers/INSTALL
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-h
ame attribute\n",
> + name);
May I suggest adding ", please fix"?
>
> id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
> if (id < 0)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
Do I understand correctly that in the long run we will make
g
> - spaces nor dashes, representing the chip name. This is
> - the only mandatory attribute.
> + whitespace, dashes, or the wildcard character '*'.
> + This attribute represents the chip name. It is the only
> + mandatory attribute.
>
Please convert the
> driver to use hwmon_device_register_with_info().\n");
>
> - return hwmon_device_register_with_groups(dev, NULL, NULL, NULL);
> + return __hwmon_device_register(dev, NULL, NULL, NULL, NULL);
> }
> EXPORT_SYMBOL_GPL(hwmon_device_register);
>
Reviewed-b
dashes, or the wildcard characters '.' and '*'.
> + This attribute represents the chip name. It is the only
> + mandatory attribute.
> I2C devices get this attribute created automatically.
> RO
>
--
Jean Delvare
SUSE L3 Suppo
gt;info))
> return ERR_PTR(-EINVAL);
>
... this breaks hwmon_device_register(), which calls:
return hwmon_device_register_with_groups(dev, NULL, NULL, NULL);
name
So y
ffsets are in the range 0C <= x <= 7.5C in 0.5C increments.
> diff --git a/drivers/hwmon/lm93.c b/drivers/hwmon/lm93.c
> index 90bb04858117..7b3152368e3b 100644
> --- a/drivers/hwmon/lm93.c
> +++ b/drivers/hwmon/lm93.c
> (...)
Code changes all look good to me, good job. Hairy code
#define VDD_FROM_REG(val)(((val) * 95 + 2) / 4)
>
> #define DIV_FROM_REG(val)(1 << (val))
Code looks good. Alignment is a bit clumsy though. Also it feels
strange now that you are using DIV_ROUND_CLOSEST for VDD_TO_REG but not
VDD_FROM_REG.
Reviewed-by: Jean Delvare <jdelv.
On Mon, 12 Dec 2016 06:14:14 -0800, Guenter Roeck wrote:
> Hi Jean,
>
> On 12/12/2016 02:03 AM, Jean Delvare wrote:
> > On Fri, 9 Dec 2016 12:41:02 -0800, Guenter Roeck wrote:
> >> Fix overflows seen when writing voltage and temperature limit attributes.
&g
; #define INSEXT_FROM_REG(n, val, ext) \
> SCALE(((val) << 4) + (ext), 192 << 4, lm85_scaling[n])
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon"
On Fri, 9 Dec 2016 06:22:43 -0800, Guenter Roeck wrote:
> On 12/09/2016 01:49 AM, Jean Delvare wrote:
> > Looking at function nct7802_write_fan_min() I think an overflow can
> > happen here too, as DIV_ROUND_CLOSEST() is called before clamp_val().
> > Any reason why you
((val) * 192 + (scale) / 2) / (scale))
>
> #define TEMP_FROM_REG(reg) ((reg) * 1000)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a
(data->regmap, nr, val & 0xff);
> return err ? : count;
Looking at function nct7802_write_fan_min() I think an overflow can
happen here too, as DIV_ROUND_CLOSEST() is called before clamp_val().
Any reason why you did not fix that one?
--
Jean Delvare
SUSE L3 Support
--
To unsubscrib
Hi Guenter,
On Thu, 8 Dec 2016 07:34:35 -0800, Guenter Roeck wrote:
> On 12/08/2016 06:33 AM, Jean Delvare wrote:
> > On Sun, 4 Dec 2016 20:55:29 -0800, Guenter Roeck wrote:
> >> @@ -215,11 +216,11 @@ static int adm1026_scaling[] = { /* .001 Volts */
> >> #define DIV_
igned-off-by: Guenter Roeck <li...@roeck-us.net>
> ---
> v2: Simplified clamping
> Separate clamp_val() and DIV_ROUND_CLOSEST() into two lines.
>
> drivers/hwmon/adt7462.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
> (...)
Reviewed-by: J
++-
> 1 file changed, 17 insertions(+), 9 deletions(-)
> (...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.
pwm_tmin(struct device *dev,
> if (kstrtol(buf, 10, ))
> return -EINVAL;
>
> - temp = DIV_ROUND_CLOSEST(temp, 1000) + 64;
> - temp = clamp_val(temp, 0, 255);
> + temp = DIV_ROUND_CLOSEST(clamp_val(temp, -64000, 191000), 1000) + 64;
>
92 ? 255 : \
>((val) * 192 + (scale) / 2) / (scale))
>
> #define TEMP_FROM_REG(reg) ((reg) * 1000)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe lin
128C to +127C)
> * REG: 1C/bit, two's complement
> */
> -static inline s8 TEMP_TO_REG(int val)
> +static inline s8 TEMP_TO_REG(long val)
> {
> return SCALE(clamp_val(val, -128000, 127000), 1, 1000);
> }
Other than this:
Reviewed-by: Jean Delvare <j
625) * 8;
>
> mutex_lock(>update_lock);
> data->temp[attr->index] = val;
Reviewed-by: Jean Delvare <jdelv...@suse.de>
Fixes: 6099469805c2 ("hwmon: Support for Dallas Semiconductor DS620")
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this li
nctions:
/* temperature range: -40..125, 127 disables temperature alarm */
static inline s8 TEMP_TO_REG(long val)
{
val = clamp_val(val, -4, 127000);
return SCALE(val, 1, 1000);
}
/* analog out 0..1250mV */
static inline u8 AOUT_TO_REG(unsigned long val)
{
val = cla
Hi Guenter,
On Mon, 10 Oct 2016 16:48:22 -0700, Guenter Roeck wrote:
> On Fri, Oct 07, 2016 at 02:32:13PM +0200, Jean Delvare wrote:
> > On Tue, 4 Oct 2016 12:37:13 -0700, Guenter Roeck wrote:
> > > On Tue, Oct 04, 2016 at 10:45:59AM +0200, Jean Delvare wrote:
> > &g
Hi Guenter,
On Tue, 4 Oct 2016 12:37:13 -0700, Guenter Roeck wrote:
> On Tue, Oct 04, 2016 at 10:45:59AM +0200, Jean Delvare wrote:
> > I see this patch is upstream now, but I had started reviewing it and
> > maybe some of my comments are still relevant.
> >
>
will not be readable.
> + * Parameters are:
> + * @dev: Pointer to hardware monitoring device
> + * @type: Sensor type
> + * @attr: Sensor attribute
> + * @channel:
> + * Channel number
> + * @val:
ed-off-by: Guenter Roeck <li...@roeck-us.net>
> ---
> v3: No change
> v2: Added patch
>
> drivers/hwmon/hwmon.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
> (...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3
t;{stepping})\n";
+ } elsif (defined $cpu->{'cpu'}) { # ppc
+ print "# Processor: $cpu->{'cpu'}, revision
$cpu->{'revision'}\n";
+ }
}
# @i2c_adapters is a list of references to hashes, one hash per I2C/SMBus
--
Jean Delvare
SUSE L3 Su
top and the i2c device to be removed. In the intervening time
> a new fan-tray could have been installed.
Thanks for the clarification. An actual use case makes it easier to
think about solutions.
> On 09/01/2016 08:18 PM, Jean Delvare wrote:
> >
> > This change looks terribly costly
ng low power states at all, leading to an increased
system temperature and power consumption. Have you compared the output
of "powertop" (specifically the "Idle stats" section) before and after
your patch?
Is there no way to voluntarily interrupt this long msleep_interrupti
On Mon, 29 Aug 2016 07:46:36 -0700, Guenter Roeck wrote:
> On 08/29/2016 03:11 AM, Jean Delvare wrote:
> > On Mon, 29 Aug 2016 12:06:34 +0200, Jean Delvare wrote:
> >> I'm trying to find when the bug was introduced. I have a hard time
> >> believing it went unnoticed
ced for long. If it fixes your problem I'll
send a clean patch.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
d_action_or_reset(dev, lm90_remove_pec, dev);
> + if (err)
> + return err;
> }
>
> hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
I'm not yet familiar with that API but it looks like the right thing to
do.
Reviewed
1 file changed, 18 insertions(+), 2 deletions(-)
> (...)
Reviewed-by: Jean Delvare <jdelv...@suse.de>
I leave the final ack to Guenter.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord..
etemp.0/hwmon/hwmon1/temp2_input
> > /sys/devices/platform/coretemp.0/hwmon/hwmon1/temp2_label
>
> Unfortunately, that is a "feature". Numbering is determined by the module
> load order. hwmon0 is the first registered hwmon device, hwmon1 is the next,
> and so on. Since the module
_update = jiffies - msecs_to_jiffies(3000);
> data->client = client;
> crc8_populate_msb(sht3x_crc8_table, SHT3X_CRC8_POLYNOMIAL);
>
Reviewed-by: Jean Delvare <jdelv...@suse.de>
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Matt,
On Fri, 8 Jul 2016 17:22:10 -0700, Matt Ranostay wrote:
> On Fri, Jul 8, 2016 at 12:56 AM, Jean Delvare <jdelv...@suse.de> wrote:
> > On jeu., 2016-07-07 at 19:46 -0700, Matt Ranostay wrote:
> >> Handling the wraparound requires the data->last_update to be set
> is good to go for upstream, even without code review feedback. Otherwise
> I fear we'll never get there. Jean, any objections ?
I am sorry that I do not have the time to review this patch series. But
I trust your judgment and I have no objection, if you think the series
is good to g
70 matches
Mail list logo
