[PATCH v4 2/3] hwmon/ltc2990: Generalise DT to fwnode support
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
---
drivers/hwmon/ltc2990.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
index f9431ad43..53ff50517 100644
--- a/drivers/hwmon/ltc2990.c
+++ b/drivers/hwmon/ltc2990.c
@@ -13,7 +13,7 @@
#include
#include
#include
-#include
+#include
#define LTC2990_STATUS 0x00
#define LTC2990_CONTROL0x01
@@ -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;
--
2.11.0
[PATCH v4 3/3] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
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.
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
---
drivers/i2c/busses/Kconfig | 3 +++
drivers/i2c/busses/i2c-icy.c | 58
2 files changed, 61 insertions(+)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 9e57e1101..a311d07f3 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1311,6 +1311,9 @@ config I2C_ICY
This support is also available as a module. If so, the module
will be called i2c-icy.
+ If you have a 2019 edition board with an LTC2990 sensor at address
+ 0x4c, loading the module 'ltc2990' is sufficient to enable it.
+
config I2C_MLXCPLD
tristate "Mellanox I2C driver"
depends on X86_64
diff --git a/drivers/i2c/busses/i2c-icy.c b/drivers/i2c/busses/i2c-icy.c
index edac515da..c30431653 100644
--- a/drivers/i2c/busses/i2c-icy.c
+++ b/drivers/i2c/busses/i2c-icy.c
@@ -54,6 +54,8 @@ struct icy_i2c {
void __iomem *reg_s0;
void __iomem *reg_s1;
+ struct fwnode_handle *ltc2990_fwnode;
+ struct i2c_client *ltc2990_client;
};
@@ -100,11 +102,35 @@ static void icy_pcf_waitforpin(void *data)
/*
* Main i2c-icy part
*/
+static unsigned short const icy_ltc2990_addresses[] = {
+ 0x4c, 0x4d, 0x4e, 0x4f, I2C_CLIENT_END
+};
+
+/*
+ * Additional sensors exposed once this property is applied:
+ *
+ * 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.
+ */
+static const u32 icy_ltc2990_meas_mode[] = {0, 3};
+
+static const struct property_entry icy_ltc2990_props[] = {
+ PROPERTY_ENTRY_U32_ARRAY("lltc,meas-mode", icy_ltc2990_meas_mode),
+ { }
+};
+
+
static int icy_probe(struct zorro_dev *z,
const struct zorro_device_id *ent)
{
struct icy_i2c *i2c;
struct i2c_algo_pcf_data *algo_data;
+ struct fwnode_handle *new_fwnode;
+ struct i2c_board_info ltc2990_info = {
+ .type = "ltc2990",
+ .addr = 0x4c,
+ };
i2c = devm_kzalloc(>dev, sizeof(*i2c), GFP_KERNEL);
@@ -147,6 +173,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;
}
@@ -154,6 +209,9 @@ static void icy_remove(struct zorro_dev *z)
{
struct icy_i2c *i2c = dev_get_drvdata(>dev);
+ i2c_unregister_device(i2c->ltc2990_client);
+ fwnode_remove_software_node(i2c->ltc2990_fwnode);
+
i2c_del_adapter(>adapter);
}
--
2.11.0
Re: [PATCH] hwmon/ltc2990: Generalise DT to fwnode support
On 8/16/19 5:43 AM, Max Staudt wrote: On 08/16/2019 02:36 PM, Geert Uytterhoeven wrote: 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. As I'll be fixing one of the I2C patches, I'll send an updated hwmon patch with it. Ok, I'll wait for that patch. Guenter
Re: [PATCH] hwmon/ltc2990: Generalise DT to fwnode support
On 08/16/2019 02:36 PM, Geert Uytterhoeven wrote: > 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. As I'll be fixing one of the I2C patches, I'll send an updated hwmon patch with it. Thanks! Max
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 v3 3/3] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
On 08/16/2019 01:51 PM, Wolfram Sang wrote:
>
>> +if (IS_ERR(new_fwnode))
>> +dev_info(>dev, "Failed to create fwnode for LTC2990, error:
>> %ld\n",
>> + PTR_ERR(new_fwnode));
>> +else {
>
> Braces for both blocks. Did you run checkpatch?
I did, and it didn't say anything.
Turns out I misremembered the CodingStyle as having a corner case where it
doesn't. I'll fix the style - I dislike the above, too ;)
>> +/*
>> + * 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);
>
> i2c_new_device (or better, the new i2c_new_client_device) should be
> sufficient, or? You only have one potential address.
Yes and no. Now that you mention it - the LTC2990 can be at four addresses
(0x4c - 0x4f), and there are jumpers (solder pads) on the PCB to select its
address. Shall I add all 4 addresses to the array?
It's also possible that there is no LTC2990 at all (because it's hard to solder
at home), and that's why we need to probe for it first. I believe
i2c_new[_client]_device doesn't do probing, but rather assumes the device to be
there. Correct?
Max
Re: [PATCH] hwmon/ltc2990: Generalise DT to fwnode support
On 08/16/2019 01:07 PM, Geert Uytterhoeven wrote: > Reviewed-by: Geert Uytterhoeven Thank you! > 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? Max
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
[PATCH] hwmon/ltc2990: Generalise DT to fwnode support
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
---
drivers/hwmon/ltc2990.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
index f9431ad43..ff11189ea 100644
--- 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;
--
2.11.0
Re: [PATCH v3 2/3] hwmon/ltc2990: Generalise DT to fwnode support
On 08/16/2019 12:43 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) {
>>
>> 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(...);
> ...
> }
Fair point. The semantic change was part of my question, but the more I think
about it, the less I want to open this can of worms. We can still make the
property optional later on, while it's not as easy to make it mandatory.
I'll send a patch with your suggestion.
Thanks!
Max
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
