Re: [PATCH v5 3/3] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
On Mon, Aug 19, 2019 at 2:17 PM Max Staudt wrote:
> Since the 2019 a1k.org community re-print of these PCBs sports an
> LTC2990 hwmon chip as an example use case, let this driver autoprobe
> for that as well. If it is present, modprobing ltc2990 is sufficient.
>
> The property_entry enables the three additional inputs available on
> this particular board:
>
> in1 will be the voltage of the 5V rail, divided by 2.
> in2 will be the voltage of the 12V rail, divided by 4.
> temp3 will be measured using a PCB loop next the chip.
>
> v5: Style
>
> v4: Style
> Added other possible addresses for LTC2990.
>
> v3: Merged with initial LTC2990 support on ICY.
> Moved defaults from platform_data to swnode.
> Added note to Kconfig.
>
> Signed-off-by: Max Staudt
Reviewed-by: Geert Uytterhoeven
One comment below...
> --- a/drivers/i2c/busses/i2c-icy.c
> +++ b/drivers/i2c/busses/i2c-icy.c
> @@ -141,6 +166,35 @@ static int icy_probe(struct zorro_dev *z,
> dev_info(>dev, "ICY I2C controller at %pa, IRQ not implemented\n",
> >resource.start);
>
> + /*
> +* The 2019 a1k.org PCBs have an LTC2990 at 0x4c, so start
> +* it automatically once ltc2990 is modprobed.
> +*
> +* in0 is the voltage of the internal 5V power supply.
> +* temp1 is the temperature inside the chip.
> +*
> +* See property_entry above for in1, in2, temp3.
> +*/
> + new_fwnode = fwnode_create_software_node(icy_ltc2990_props, NULL);
> + if (IS_ERR(new_fwnode)) {
> + dev_info(>dev, "Failed to create fwnode for LTC2990,
> error: %ld\n",
> +PTR_ERR(new_fwnode));
> + } else {
> + /*
> +* Store the fwnode so we can destroy it on .remove().
> +* Only store it on success, as fwnode_remove_software_node()
> +* is NULL safe, but not PTR_ERR safe.
> +*/
> + i2c->ltc2990_fwnode = new_fwnode;
> + ltc2990_info.fwnode = new_fwnode;
> +
> + i2c->ltc2990_client =
> + i2c_new_probed_device(>adapter,
> + _info,
> + icy_ltc2990_addresses,
> + NULL);
> + }
> +
> return 0;
> }
Since commit d3e1b617ae20c459 ("i2c: allow specify device properties in
i2c_board_info"), the properties could be provided by info->properties, too.
However, according to the comments for device_add_properties(), this is
valid only if there is a real firmware node present.
If that is true, Max' use is correct, while e.g. commit 6a7836ba7fb4abf6
("ARM: imx: pca100: use device properties for at24 eeprom") isn't?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 2/3] hwmon/ltc2990: Generalise DT to fwnode support
On Mon, Aug 19, 2019 at 2:17 PM Max Staudt wrote:
> ltc2990 will now use device_property_read_u32_array() instead of
> of_property_read_u32_array() - allowing the use of software nodes
> via fwnode_create_software_node().
>
> This allows code using i2c_new_device() to specify a default
> measurement mode for the LTC2990 via fwnode_create_software_node().
>
> Signed-off-by: Max Staudt
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5 1/3] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
On Mon, Aug 19, 2019 at 2:17 PM Max Staudt wrote:
> This is the i2c-icy driver for the ICY board for Amiga computers.
> It connects a PCF8584 I2C controller to the Zorro bus, providing I2C
> connectivity. The original documentation can be found on Aminet:
>
> https://aminet.net/package/docs/hard/icy
>
> IRQ support is currently not implemented, as i2c-algo-pcf is built for
> the ISA bus and a straight implementation of the same stack locks up a
> Zorro machine.
>
> v5: usleep_range() instead of udelay()
> Style
>
> v3: Fixed %pa format string
> Dropped adapter class.
> Clarified licence.
> Removed clock parameter.
>
> v2: Matched function names to callbacks from i2c-algo-pcf
> Used z_readb()/z_writeb()
> Removed BROKEN_ON_SMP in Kconfig
> Moved LTC2990 to a separate commit
>
> Signed-off-by: Max Staudt
Reviewed-by: Geert Uytterhoeven
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-icy.c
> +static int icy_pcf_getpcf(void *data, int ctl)
> +{
> + struct icy_i2c *i2c = (struct icy_i2c *)data;
> +
> + u8 __iomem *address = ctl ? i2c->reg_s1 : i2c->reg_s0;
> + int val = z_readb(address);
> +
> + return val;
return z_readb(address);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] hwmon/ltc2990: Generalise DT to fwnode support
Hi Max,
On Fri, Aug 16, 2019 at 2:25 PM Max Staudt wrote:
> On 08/16/2019 01:07 PM, Geert Uytterhoeven wrote:
> > One minor nit: as the driver no longer uses any of_*() symbols, you can
> > replace
> > #include by #include .
>
> I should have thought of that, sorry.
>
> Another patch, or will you do it?
As the patch won't go through my tree, I cannot, but the hwmon maintainer
might do.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] hwmon/ltc2990: Generalise DT to fwnode support
Hi Max,
On Fri, Aug 16, 2019 at 11:09 AM Max Staudt wrote:
> ltc2990 will now use device_property_read_u32_array() instead of
> of_property_read_u32_array() - allowing the use of software nodes
> via fwnode_create_software_node().
>
> This allows code using i2c_new_device() to specify a default
> measurement mode for the LTC2990 via fwnode_create_software_node().
>
> Signed-off-by: Max Staudt
Thanks for your patch!
Reviewed-by: Geert Uytterhoeven
One minor nit: as the driver no longer uses any of_*() symbols, you can replace
#include by #include .
> --- a/drivers/hwmon/ltc2990.c
> +++ b/drivers/hwmon/ltc2990.c
> @@ -206,7 +206,6 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
> int ret;
> struct device *hwmon_dev;
> struct ltc2990_data *data;
> - struct device_node *of_node = i2c->dev.of_node;
>
> if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA |
> I2C_FUNC_SMBUS_WORD_DATA))
> @@ -218,9 +217,10 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
>
> data->i2c = i2c;
>
> - if (of_node) {
> - ret = of_property_read_u32_array(of_node, "lltc,meas-mode",
> -data->mode, 2);
> + if (dev_fwnode(>dev)) {
> + ret = device_property_read_u32_array(>dev,
> +"lltc,meas-mode",
> +data->mode, 2);
> if (ret < 0)
> return ret;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 2/3] hwmon/ltc2990: Generalise DT to fwnode support
On Fri, Aug 16, 2019 at 1:50 AM Guenter Roeck wrote:
> On Fri, Aug 16, 2019 at 12:19:42AM +0200, Max Staudt wrote:
> > On 08/15/2019 02:58 PM, Max Staudt wrote:
> > > - if (of_node) {
> > > - ret = of_property_read_u32_array(of_node, "lltc,meas-mode",
> > > -data->mode, 2);
> > > + if (i2c->dev.of_node || i2c->dev.fwnode) {
I was just going to comment on this check...
> > One more idea, would it be better here to do the following?
> >
> > if (device_property_present(i2c->dev, "lltc,meas-mode")) {
> > ret = of_property_read_u32_array(of_node, "lltc,meas-mode",
> >data->mode, 2);
> > }
> >
> > I'm happy to prepare a patch if you wish to have this in - just let me know
> > whether it should be on top of the last one, or instead of it.
>
> That would be semantically different. The property is currently mandatory.
> The above code would make it optional. This might work:
>
> if (dev_fwnode(>dev)) {
> ret = device_property_read_u32_array(...);
> ...
> }
Much better, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
Hi Günter,
On Tue, Aug 13, 2019 at 3:27 PM Guenter Roeck wrote:
> On 8/13/19 1:27 AM, Geert Uytterhoeven wrote:
> > On Tue, Aug 13, 2019 at 10:02 AM Guenter Roeck wrote:
> >> On Tue, Aug 13, 2019 at 01:52:36AM +0200, Max Staudt wrote:
> >>> This allows code using i2c_new_device() to specify a measurement mode.
> >>>
> >>> Signed-off-by: Max Staudt
> >>> Reviewed-by: Geert Uytterhoeven
> >>> ---
> >>> drivers/hwmon/ltc2990.c | 9 +
> >>> include/linux/platform_data/ltc2990.h | 11 +++
> >>> 2 files changed, 20 insertions(+)
> >>> create mode 100644 include/linux/platform_data/ltc2990.h
> >>>
> >>> diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
> >>> index f9431ad43..f19b9c50c 100644
> >>> --- a/drivers/hwmon/ltc2990.c
> >>> +++ b/drivers/hwmon/ltc2990.c
> >>> @@ -14,6 +14,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>>
> >>> #define LTC2990_STATUS 0x00
> >>> #define LTC2990_CONTROL 0x01
> >>> @@ -206,6 +207,7 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
> >>>int ret;
> >>>struct device *hwmon_dev;
> >>>struct ltc2990_data *data;
> >>> + struct ltc2990_platform_data *pdata = dev_get_platdata(>dev);
> >>>struct device_node *of_node = i2c->dev.of_node;
> >>>
> >>>if (!i2c_check_functionality(i2c->adapter,
> >>> I2C_FUNC_SMBUS_BYTE_DATA |
> >>> @@ -227,6 +229,13 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
> >>>if (data->mode[0] & ~LTC2990_MODE0_MASK ||
> >>>data->mode[1] & ~LTC2990_MODE1_MASK)
> >>>return -EINVAL;
> >>> + } else if (pdata) {
> >>> + data->mode[0] = pdata->meas_mode[0];
> >>> + data->mode[1] = pdata->meas_mode[1];
> >>> +
> >>> + if (data->mode[0] & ~LTC2990_MODE0_MASK ||
> >>> + data->mode[1] & ~LTC2990_MODE1_MASK)
> >>> + return -EINVAL;
> >>
> >> I would prefer if the driver was modified to accept device
> >> properties, and if those were set using the appropriate
> >> fwnode function. Any reason for not doing that ?
> >
> > That was my first thought as well, but isn't that limited to DT and ACPI
> > properties (for now)?
>
> tcpm and, for example, the wcove driver don't seem to have a problem using
> it, I don't see acpi involved there. Also, the code resides in the core driver
Cool, just discovered that, following your other fwnode_create_software_node()
pointer...
> code and is always enabled unless I am missing something. What am I missing ?
You're missing that I'm not up-to-date w.r.t. the latest fwnode properties
development ;-)
Thanks a lot!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
Hi Günter,
On Tue, Aug 13, 2019 at 10:02 AM Guenter Roeck wrote:
> On Tue, Aug 13, 2019 at 01:52:36AM +0200, Max Staudt wrote:
> > This allows code using i2c_new_device() to specify a measurement mode.
> >
> > Signed-off-by: Max Staudt
> > Reviewed-by: Geert Uytterhoeven
> > ---
> > drivers/hwmon/ltc2990.c | 9 +
> > include/linux/platform_data/ltc2990.h | 11 +++
> > 2 files changed, 20 insertions(+)
> > create mode 100644 include/linux/platform_data/ltc2990.h
> >
> > diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
> > index f9431ad43..f19b9c50c 100644
> > --- a/drivers/hwmon/ltc2990.c
> > +++ b/drivers/hwmon/ltc2990.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define LTC2990_STATUS 0x00
> > #define LTC2990_CONTROL 0x01
> > @@ -206,6 +207,7 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
> > int ret;
> > struct device *hwmon_dev;
> > struct ltc2990_data *data;
> > + struct ltc2990_platform_data *pdata = dev_get_platdata(>dev);
> > struct device_node *of_node = i2c->dev.of_node;
> >
> > if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA |
> > @@ -227,6 +229,13 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
> > if (data->mode[0] & ~LTC2990_MODE0_MASK ||
> > data->mode[1] & ~LTC2990_MODE1_MASK)
> > return -EINVAL;
> > + } else if (pdata) {
> > + data->mode[0] = pdata->meas_mode[0];
> > + data->mode[1] = pdata->meas_mode[1];
> > +
> > + if (data->mode[0] & ~LTC2990_MODE0_MASK ||
> > + data->mode[1] & ~LTC2990_MODE1_MASK)
> > + return -EINVAL;
>
> I would prefer if the driver was modified to accept device
> properties, and if those were set using the appropriate
> fwnode function. Any reason for not doing that ?
That was my first thought as well, but isn't that limited to DT and ACPI
properties (for now)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
Hi Max,
On Tue, Aug 13, 2019 at 1:53 AM Max Staudt wrote:
> This is the i2c-icy driver for the ICY board for Amiga computers.
> It connects a PCF8584 I2C controller to the Zorro bus, providing I2C
> connectivity. The original documentation can be found on Aminet:
>
> https://aminet.net/package/docs/hard/icy
>
> IRQ support is currently not implemented, as i2c-algo-pcf is built for
> the ISA bus and a straight implementation of the same stack locks up a
> Zorro machine.
>
> v2: Matched function names to callbacks from i2c-algo-pcf
> Used z_readb()/z_writeb()
> Removed BROKEN_ON_SMP in Kconfig
> Moved LTC2990 to a separate commit
>
> Signed-off-by: Max Staudt
Thanks for the update!
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-icy.c
> @@ -0,0 +1,189 @@
> + dev_info(>dev, "ICY I2C controller at %#x, IRQ not implemented\n",
> +z->resource.start);
z->resource.start has type phys_addr_t, so you should pas a reference, and
use %pa to print it.
Alternatively, you can print the full resource using %pR.
See Documentation/core-api/printk-formats.rst
> +
> + return 0;
> +}
The rest looks fine to me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 4/4] i2c/busses/i2c-icy: Add platform_data for LTC2990
Hi Max,
On Tue, Aug 13, 2019 at 1:54 AM Max Staudt wrote:
> This enables the three additional inputs available on the 2019 a1k.org
> reprint of the ICY board:
>
> in1 will be the voltage of the 5V rail, divided by 2.
> in2 will be the voltage of the 12V rail, divided by 4.
> temp3 will be measured using a PCB loop next the chip.
>
> Signed-off-by: Max Staudt
Reviewed-by: Geert Uytterhoeven
However, I would merge patches 2/4 and 4/4, and move the result
after patch 3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
Hi Max,
On Tue, Aug 13, 2019 at 1:53 AM Max Staudt wrote:
> Since the 2019 a1k.org community re-print of these PCBs sports an
> LTC2990 hwmon chip as an example use case, let this driver autoprobe
> for that as well. If it is present, modprobing ltc2990 is sufficient.
>
> Signed-off-by: Max Staudt
Thanks for your patch!
> --- a/drivers/i2c/busses/i2c-icy.c
> +++ b/drivers/i2c/busses/i2c-icy.c
> @@ -160,6 +180,8 @@ static void icy_remove(struct zorro_dev *z)
> {
> struct icy_i2c *i2c = dev_get_drvdata(>dev);
>
> + i2c_unregister_device(i2c->client_ltc2990);
Is this needed?
In my understanding, i2c_del_adapter() below takes care of that.
Apart from that, this looks good to me.
> +
> i2c_del_adapter(>adapter);
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
On Tue, Aug 13, 2019 at 1:53 AM Max Staudt wrote:
> This allows code using i2c_new_device() to specify a measurement mode.
>
> Signed-off-by: Max Staudt
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH V3 3/6] thermal: Register hwmon in thermal_zone_of_sensor_register_param()
Hi all,
On Mon, Feb 11, 2019 at 9:43 PM Marek Vasut wrote:
> On 2/6/19 12:24 AM, Eduardo Valentin wrote:
> > On Mon, Jan 28, 2019 at 01:10:11PM +0100, Marek Vasut wrote:
> >> On 1/15/19 1:35 AM, Marek Vasut wrote:
> >>> On 12/22/18 3:19 AM, Marek Vasut wrote:
> >>>> On 12/18/2018 10:44 PM, Eduardo Valentin wrote:
> >>>>> On Mon, Dec 17, 2018 at 04:56:41PM +0100, marek.va...@gmail.com wrote:
> >>>>>> From: Marek Vasut
> >>>>>>
> >>>>>> Register hwmon sysfs interface in
> >>>>>> thermal_zone_of_sensor_register_param()
> >>>>>> in case thermal_zone_params->no_hwmon is set to false. This behavior is
> >>>>>> the same as thermal_zone_device_register().
> >>>>>>
> >>>>>> From: Marek Vasut
> >>>>>> Cc: Daniel Lezcano
> >>>>>> Cc: Eduardo Valentin
> >>>>>> Cc: Wolfram Sang
> >>>>>> Cc: Zhang Rui
> >>>>>> Cc: linux-renesas-...@vger.kernel.org
> >>>>>> To: linux...@vger.kernel.org
> >>>>>> Signed-off-by: Marek Vasut
> >>>>>> ---
> >>>>>> V2: No change
> >>>>>> V3: - Work around the From line and SoB line checkpatch warning
> >>>>>> - Reorder the SoB line at the end
> >>>>>> ---
> >>>>>> drivers/thermal/of-thermal.c | 12 +++-
> >>>>>> 1 file changed, 11 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/thermal/of-thermal.c
> >>>>>> b/drivers/thermal/of-thermal.c
> >>>>>> index e1a303a5698c..5ccff7b678de 100644
> >>>>>> --- a/drivers/thermal/of-thermal.c
> >>>>>> +++ b/drivers/thermal/of-thermal.c
> >>>>>> @@ -15,6 +15,7 @@
> >>>>>> #include
> >>>>>>
> >>>>>> #include "thermal_core.h"
> >>>>>> +#include "thermal_hwmon.h"
> >>>>>>
> >>>>>> /*** Private data structures to represent thermal device tree data
> >>>>>> ***/
> >>>>>>
> >>>>>> @@ -521,8 +522,15 @@ thermal_zone_of_sensor_register_params(struct
> >>>>>> device *dev, int sensor_id,
> >>>>>> if (sensor_specs.np == sensor_np && id == sensor_id) {
> >>>>>> tzd = thermal_zone_of_add_sensor(child,
> >>>>>> sensor_np,
> >>>>>> data, ops);
> >>>>>> -if (!IS_ERR(tzd))
> >>>>>> +if (!IS_ERR(tzd)) {
> >>>>>> +tzd->tzp = tzp;
> >>>>>
> >>>>> So, here you will overwrite what was done in of_parse_thermal_zones().
> >>>>> That means, after this point, property like sustainable power, slope and
> >>>>> offset are gone.
> >>>>
> >>>> Hm, that was rather inobvious, indeed.
> >>>>
> >>>> Do you have some suggestion how to pass in the no_hwmon = false then ?
> >>>> Since tzp->no_hwmon is set to true in of_parse_thermal_zones(), the
> >>>> three drivers (stm32, rcar, rcar_gen3) seem to hack around it. I'd like
> >>>> to clean that up.
> >>>
> >
> > Yeah, that is an issue.
> >
> >>> Bump ?
> >>
> >> Bump again, any suggestions ?
> >
> > Yeah, a couple of ideas have been proposed for this issue.
> >
> > First most tempting one is to have a DT property per thermal zone.
> > Making it linux specific, something prefixed by linux,. I
> > recall Amit Kutcheria trying something similar to this, but dont
> > remember where that went. Frankly, this is a Linux thing, I am not
> > convinced DT is really the right place to fix this.
>
> DT is not the right place for this, DT describes hardware and this is
> policy, so it shouldn't be in DT.
Indeed.
> > Another hack that could be written is a module parameter for of-thermal
> > that would reflect the no_hwmon value, globally. The down side here is
> > you have to make sure all drivers match that no_hwmon value, right?
>
> Indeed, it should be the driver which decides whether or not to register
> a HWMON interface for the thermal zone.
>
> I guess for now, I'll just discard this entire series and hack the data
> structure like other drivers do, since I don't see any reasonable solution.
Pardon my ignorance, but when would a thermal driver (not) want to register
a hwmon interface for the thermal zone?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] hwmon: (ibmpowernv) Remove bogus __init annotations
If gcc decides not to inline make_sensor_label():
WARNING: vmlinux.o(.text+0x4df549c): Section mismatch in reference from the
function .create_device_attrs() to the function .init.text:.make_sensor_label()
The function .create_device_attrs() references
the function __init .make_sensor_label().
This is often because .create_device_attrs lacks a __init
annotation or the annotation of .make_sensor_label is wrong.
As .probe() can be called after freeing of __init memory, all __init
annotiations in the driver are bogus, and should be removed.
Signed-off-by: Geert Uytterhoeven
---
Compile-tested only.
---
drivers/hwmon/ibmpowernv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 0ccca87f527191dc..293dd1c6c7b36ef2 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -181,7 +181,7 @@ static ssize_t show_label(struct device *dev, struct
device_attribute *devattr,
return sprintf(buf, "%s\n", sdata->label);
}
-static int __init get_logical_cpu(int hwcpu)
+static int get_logical_cpu(int hwcpu)
{
int cpu;
@@ -192,9 +192,8 @@ static int __init get_logical_cpu(int hwcpu)
return -ENOENT;
}
-static void __init make_sensor_label(struct device_node *np,
-struct sensor_data *sdata,
-const char *label)
+static void make_sensor_label(struct device_node *np,
+ struct sensor_data *sdata, const char *label)
{
u32 id;
size_t n;
--
2.17.1
Re: [PATCH] hwmon: Fix the 'No sensors found' error after replacing the parameter NULL by the actual device
CC Marc, Eduardo
On Tue, Oct 2, 2018 at 2:56 PM Guenter Roeck wrote:
>
> On 10/02/2018 02:06 AM, Cao Van Dong wrote:
> > Dear Geert-san,
> >
> > Thanks for your comment!
> >
> >>> In __hwmon_device_register() function of hwmon.c, we have assigned 'dev'
> >>> directly to 'hdev->parent'.
> >>> Formerly, when registering the hwmon device, we pass NULL as the device.
> >>> This is not affected.
> >>> Recently, the developer has replaced the parameter NULL as the device by
> >>> the actual device.
> >> Do you know the commit ID of this recent change?
> >> It's useful for review of your change, and to know to which versions your
> >> patch should be backported.
> >
> > The commit ID of this recent change is"f6b6b52 thermal_hwmon: Pass the
> > originating device down to hwmon_device_register_with_info".
> >
> If thermal doesn't want hwmon to use the thermal zone device, it should pass
> the parent of that device as parameter.
>
> >>> This causes the "No sensors found" error. This patch is to fix this error.
> >> On which platform do you see this failure?
> >> Thanks again!
> >
> > This error is found on Gen2 Lager board v4.19-rc2 by RVC team.
> >
>
> Some more details about the error would be useful.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] hwmon: Fix the 'No sensors found' error after replacing the parameter NULL by the actual device
CC Marc, Eduardo On Tue, Oct 2, 2018 at 2:50 PM Guenter Roeck wrote: > On 10/02/2018 01:35 AM, Cao Van Dong wrote: > > In __hwmon_device_register() function of hwmon.c, we have assigned 'dev' > > directly to 'hdev->parent'. > > Formerly, when registering the hwmon device, we pass NULL as the device. > > This is not affected. > > Recently, the developer has replaced the parameter NULL as the device by > > the actual device. > > This causes the "No sensors found" error. This patch is to fix this error. > > > > This patch is based on the v4.19-rc3 tag. > > > > NACK. > > This is wrong. The passed device is the hwmon driver's parent device. Using > that device's > parent would be wrong. Indeed, that device could be a platform device with no > parent. > The problem must be fixed in the calling code. > > Guenter > > > --- > > drivers/hwmon/hwmon.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c > > index 33d5128..7c8d3cb 100644 > > --- a/drivers/hwmon/hwmon.c > > +++ b/drivers/hwmon/hwmon.c > > @@ -610,7 +610,7 @@ __hwmon_device_register(struct device *dev, const char > > *name, void *drvdata, > > > > hwdev->name = name; > > hdev->class = _class; > > - hdev->parent = dev; > > + hdev->parent = dev->parent; > > hdev->of_node = dev ? dev->of_node : NULL; > > hwdev->chip = chip; > > dev_set_drvdata(hdev, drvdata);
Re: [PATCH] hwmon: Fix the 'No sensors found' error after replacing the parameter NULL by the actual device
Hi Cao,
Thanks for your patch!
On Tue, Oct 2, 2018 at 10:35 AM Cao Van Dong wrote:
> In __hwmon_device_register() function of hwmon.c, we have assigned 'dev'
> directly to 'hdev->parent'.
> Formerly, when registering the hwmon device, we pass NULL as the device. This
> is not affected.
> Recently, the developer has replaced the parameter NULL as the device by the
> actual device.
Do you know the commit ID of this recent change?
It's useful for review of your change, and to know to which versions your
patch should be backported.
> This causes the "No sensors found" error. This patch is to fix this error.
On which platform do you see this failure?
Thanks again!
> --- a/drivers/hwmon/hwmon.c
> +++ b/drivers/hwmon/hwmon.c
> @@ -610,7 +610,7 @@ __hwmon_device_register(struct device *dev, const char
> *name, void *drvdata,
>
> hwdev->name = name;
> hdev->class = _class;
> - hdev->parent = dev;
> + hdev->parent = dev->parent;
> hdev->of_node = dev ? dev->of_node : NULL;
> hwdev->chip = chip;
> dev_set_drvdata(hdev, drvdata);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
