Linux-Hwmon Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
@ 2019-08-12 23:52 Max Staudt
  2019-08-12 23:52 ` [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision Max Staudt
                   ` (4 more replies)
  0 siblings, 5 replies; 28+ messages in thread
From: Max Staudt @ 2019-08-12 23:52 UTC (permalink / raw)
  To: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, Guenter Roeck
  Cc: linux-m68k, linux-kernel, glaubitz, Max Staudt

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 <max@enpas.org>
---
 MAINTAINERS                  |   6 ++
 drivers/i2c/busses/Kconfig   |  11 +++
 drivers/i2c/busses/Makefile  |   1 +
 drivers/i2c/busses/i2c-icy.c | 189 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 207 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-icy.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1be025959..70336c083 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7705,6 +7705,12 @@ S:	Maintained
 F:	drivers/mfd/lpc_ich.c
 F:	drivers/gpio/gpio-ich.c
 
+ICY I2C DRIVER
+M:	Max Staudt <max@enpas.org>
+L:	linux-i2c@vger.kernel.org
+S:	Maintained
+F:	drivers/i2c/busses/i2c-icy.c
+
 IDE SUBSYSTEM
 M:	"David S. Miller" <davem@davemloft.net>
 L:	linux-ide@vger.kernel.org
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index ee5dfb5ae..9e57e1101 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1300,6 +1300,17 @@ config I2C_ELEKTOR
 	  This support is also available as a module.  If so, the module
 	  will be called i2c-elektor.
 
+config I2C_ICY
+	tristate "ICY Zorro card"
+	depends on ZORRO
+	select I2C_ALGOPCF
+	help
+	  This supports the PCF8584 Zorro bus I2C adapter, known as ICY.
+	  Say Y if you own such an adapter.
+
+	  This support is also available as a module.  If so, the module
+	  will be called i2c-icy.
+
 config I2C_MLXCPLD
 	tristate "Mellanox I2C driver"
 	depends on X86_64
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index a3245231b..d0e1c3d4e 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -139,6 +139,7 @@ obj-$(CONFIG_I2C_BCM_KONA)	+= i2c-bcm-kona.o
 obj-$(CONFIG_I2C_BRCMSTB)	+= i2c-brcmstb.o
 obj-$(CONFIG_I2C_CROS_EC_TUNNEL)	+= i2c-cros-ec-tunnel.o
 obj-$(CONFIG_I2C_ELEKTOR)	+= i2c-elektor.o
+obj-$(CONFIG_I2C_ICY)		+= i2c-icy.o
 obj-$(CONFIG_I2C_MLXCPLD)	+= i2c-mlxcpld.o
 obj-$(CONFIG_I2C_OPAL)		+= i2c-opal.o
 obj-$(CONFIG_I2C_PCA_ISA)	+= i2c-pca-isa.o
diff --git a/drivers/i2c/busses/i2c-icy.c b/drivers/i2c/busses/i2c-icy.c
new file mode 100644
index 000000000..7910f035b
--- /dev/null
+++ b/drivers/i2c/busses/i2c-icy.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * I2C driver for stand-alone PCF8584 style adapters on Zorro cards
+ *
+ * Original ICY documentation can be found on Aminet:
+ * https://aminet.net/package/docs/hard/icy
+ *
+ * There has been a modern community re-print of this design in 2019:
+ * https://www.a1k.org/forum/index.php?threads/70106/
+ *
+ * The card is basically a Philips PCF8584 connected straight to the
+ * beginning of the AutoConfig'd address space (register S1 on base+2),
+ * with /INT on /INT2 on the Zorro bus.
+ *
+ * Copyright (c) 2019 Max Staudt <max@enpas.org>
+ *
+ * This started as a fork of i2c-elektor.c and has evolved since.
+ * Thanks go to its authors for providing a base to grow on.
+ *
+ *
+ * IRQ support is currently not implemented.
+ *
+ * As it turns out, i2c-algo-pcf is really written with i2c-elektor's
+ * edge-triggered ISA interrupts in mind, while the Amiga's Zorro bus has
+ * level-triggered interrupts. This means that once an interrupt occurs, we
+ * have to tell the PCF8584 to shut up immediately, or it will keep the
+ * interrupt line busy and cause an IRQ storm.
+
+ * However, because of the PCF8584's host-side protocol, there is no good
+ * way to just quieten it without side effects. Rather, we have to perform
+ * the next read/write operation straight away, which will reset the /INT
+ * pin. This entails re-designing the core of i2c-algo-pcf in the future.
+ * For now, we never request an IRQ from the PCF8584, and poll it instead.
+ */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#include <linux/i2c.h>
+#include <linux/i2c-algo-pcf.h>
+
+#include <asm/amigaints.h>
+#include <linux/zorro.h>
+
+#include "../algos/i2c-algo-pcf.h"
+
+
+static int clock = 0x1c;
+module_param(clock, int, 0444);
+
+
+
+struct icy_i2c {
+	struct i2c_adapter adapter;
+
+	void __iomem *reg_s0;
+	void __iomem *reg_s1;
+};
+
+
+
+/*
+ * Functions called by i2c-algo-pcf
+ */
+static void icy_pcf_setpcf(void *data, int ctl, int val)
+{
+	struct icy_i2c *i2c = (struct icy_i2c *)data;
+
+	u8 __iomem *address = ctl ? i2c->reg_s1 : i2c->reg_s0;
+
+	z_writeb(val, address);
+}
+
+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;
+}
+
+static int icy_pcf_getown(void *data)
+{
+	return 0x55;
+}
+
+static int icy_pcf_getclock(void *data)
+{
+	return clock;
+}
+
+static void icy_pcf_waitforpin(void *data)
+{
+	udelay(100);
+}
+
+
+
+/*
+ * Main i2c-icy part
+ */
+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;
+
+
+	i2c = devm_kzalloc(&z->dev, sizeof(*i2c), GFP_KERNEL);
+	if (!i2c)
+		return -ENOMEM;
+
+	algo_data = devm_kzalloc(&z->dev, sizeof(*algo_data), GFP_KERNEL);
+	if (!algo_data)
+		return -ENOMEM;
+
+	dev_set_drvdata(&z->dev, i2c);
+	i2c->adapter.dev.parent = &z->dev;
+	i2c->adapter.owner = THIS_MODULE;
+	i2c->adapter.class = I2C_CLASS_DEPRECATED;
+	/* i2c->adapter.algo assigned by i2c_pcf_add_bus() */
+	i2c->adapter.algo_data = algo_data;
+	strlcpy(i2c->adapter.name, "ICY I2C Zorro adapter",
+		sizeof(i2c->adapter.name));
+
+	if (!devm_request_mem_region(&z->dev,
+				     z->resource.start,
+				     4, i2c->adapter.name))
+		return -ENXIO;
+
+	/* Driver private data */
+	i2c->reg_s0 = ZTWO_VADDR(z->resource.start);
+	i2c->reg_s1 = ZTWO_VADDR(z->resource.start + 2);
+
+	algo_data->data = (void *)i2c;
+	algo_data->setpcf     = icy_pcf_setpcf;
+	algo_data->getpcf     = icy_pcf_getpcf;
+	algo_data->getown     = icy_pcf_getown;
+	algo_data->getclock   = icy_pcf_getclock;
+	algo_data->waitforpin = icy_pcf_waitforpin;
+
+	if (i2c_pcf_add_bus(&i2c->adapter)) {
+		dev_err(&z->dev, "i2c_pcf_add_bus() failed\n");
+		return -ENXIO;
+	}
+
+	dev_info(&z->dev, "ICY I2C controller at %#x, IRQ not implemented\n",
+		 z->resource.start);
+
+	return 0;
+}
+
+static void icy_remove(struct zorro_dev *z)
+{
+	struct icy_i2c *i2c = dev_get_drvdata(&z->dev);
+
+	i2c_del_adapter(&i2c->adapter);
+}
+
+
+
+static const struct zorro_device_id icy_zorro_tbl[] = {
+	{ ZORRO_ID(VMC, 15, 0), },
+	{ 0 }
+};
+
+MODULE_DEVICE_TABLE(zorro, icy_zorro_tbl);
+
+static struct zorro_driver icy_driver = {
+	.name           = "i2c-icy",
+	.id_table       = icy_zorro_tbl,
+	.probe          = icy_probe,
+	.remove         = icy_remove,
+};
+
+module_driver(icy_driver,
+	      zorro_register_driver,
+	      zorro_unregister_driver);
+
+
+MODULE_AUTHOR("Max Staudt <max@enpas.org>");
+MODULE_DESCRIPTION("I2C bus via PCF8584 on ICY Zorro card");
+MODULE_LICENSE("GPL");
-- 
2.11.0


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
  2019-08-12 23:52 [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Max Staudt
@ 2019-08-12 23:52 ` Max Staudt
  2019-08-13  7:03   ` Geert Uytterhoeven
  2019-08-12 23:52 ` [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support Max Staudt
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 28+ messages in thread
From: Max Staudt @ 2019-08-12 23:52 UTC (permalink / raw)
  To: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, Guenter Roeck
  Cc: linux-m68k, linux-kernel, glaubitz, Max Staudt

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 <max@enpas.org>
---
 drivers/i2c/busses/i2c-icy.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/i2c/busses/i2c-icy.c b/drivers/i2c/busses/i2c-icy.c
index 7910f035b..8125683c5 100644
--- a/drivers/i2c/busses/i2c-icy.c
+++ b/drivers/i2c/busses/i2c-icy.c
@@ -59,6 +59,7 @@ struct icy_i2c {
 
 	void __iomem *reg_s0;
 	void __iomem *reg_s1;
+	struct i2c_client *client_ltc2990;
 };
 
 
@@ -105,6 +106,13 @@ static void icy_pcf_waitforpin(void *data)
 /*
  * Main i2c-icy part
  */
+static struct i2c_board_info icy_ltc2990_info = {
+	I2C_BOARD_INFO("ltc2990", 0x4c),
+};
+
+static unsigned short const icy_ltc2990_addresses[] = {0x4c, I2C_CLIENT_END};
+
+
 static int icy_probe(struct zorro_dev *z,
 			 const struct zorro_device_id *ent)
 {
@@ -153,6 +161,18 @@ static int icy_probe(struct zorro_dev *z,
 	dev_info(&z->dev, "ICY I2C controller at %#x, IRQ not implemented\n",
 		 z->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.
+	 */
+	i2c->client_ltc2990 = i2c_new_probed_device(&i2c->adapter,
+						    &icy_ltc2990_info,
+						    icy_ltc2990_addresses,
+						    NULL);
+
 	return 0;
 }
 
@@ -160,6 +180,8 @@ static void icy_remove(struct zorro_dev *z)
 {
 	struct icy_i2c *i2c = dev_get_drvdata(&z->dev);
 
+	i2c_unregister_device(i2c->client_ltc2990);
+
 	i2c_del_adapter(&i2c->adapter);
 }
 
-- 
2.11.0


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-12 23:52 [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Max Staudt
  2019-08-12 23:52 ` [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision Max Staudt
@ 2019-08-12 23:52 ` Max Staudt
  2019-08-13  6:59   ` Geert Uytterhoeven
  2019-08-13  8:02   ` Guenter Roeck
  2019-08-12 23:52 ` [PATCH v2 4/4] i2c/busses/i2c-icy: Add platform_data for LTC2990 Max Staudt
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 28+ messages in thread
From: Max Staudt @ 2019-08-12 23:52 UTC (permalink / raw)
  To: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, Guenter Roeck
  Cc: linux-m68k, linux-kernel, glaubitz, Max Staudt

This allows code using i2c_new_device() to specify a measurement mode.

Signed-off-by: Max Staudt <max@enpas.org>
---
 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 <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/platform_data/ltc2990.h>
 
 #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(&i2c->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;
 	} else {
 		ret = i2c_smbus_read_byte_data(i2c, LTC2990_CONTROL);
 		if (ret < 0)
diff --git a/include/linux/platform_data/ltc2990.h b/include/linux/platform_data/ltc2990.h
new file mode 100644
index 000000000..7ec89e784
--- /dev/null
+++ b/include/linux/platform_data/ltc2990.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef LTC2990_PDATA_H
+#define LTC2990_PDATA_H
+
+#include <linux/types.h>
+
+struct ltc2990_platform_data {
+	u8 meas_mode[2];
+};
+
+#endif /* LTC2990_PDATA_H */
-- 
2.11.0


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v2 4/4] i2c/busses/i2c-icy: Add platform_data for LTC2990
  2019-08-12 23:52 [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Max Staudt
  2019-08-12 23:52 ` [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision Max Staudt
  2019-08-12 23:52 ` [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support Max Staudt
@ 2019-08-12 23:52 ` Max Staudt
  2019-08-13  7:04   ` Geert Uytterhoeven
  2019-08-13  7:08 ` [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Geert Uytterhoeven
  2019-08-14 19:47 ` Wolfram Sang
  4 siblings, 1 reply; 28+ messages in thread
From: Max Staudt @ 2019-08-12 23:52 UTC (permalink / raw)
  To: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, Guenter Roeck
  Cc: linux-m68k, linux-kernel, glaubitz, Max Staudt

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 <max@enpas.org>
---
 drivers/i2c/busses/i2c-icy.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-icy.c b/drivers/i2c/busses/i2c-icy.c
index 8125683c5..6ad9910a0 100644
--- a/drivers/i2c/busses/i2c-icy.c
+++ b/drivers/i2c/busses/i2c-icy.c
@@ -42,6 +42,7 @@
 
 #include <linux/i2c.h>
 #include <linux/i2c-algo-pcf.h>
+#include <linux/platform_data/ltc2990.h>
 
 #include <asm/amigaints.h>
 #include <linux/zorro.h>
@@ -106,8 +107,21 @@ static void icy_pcf_waitforpin(void *data)
 /*
  * Main i2c-icy part
  */
+static struct ltc2990_platform_data icy_ltc2990_platform_data = {
+	/*
+	 * Additional sensors exposed by this platform data:
+	 *
+	 * 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.
+	 */
+	.meas_mode = {0, 3},
+};
+
 static struct i2c_board_info icy_ltc2990_info = {
-	I2C_BOARD_INFO("ltc2990", 0x4c),
+	.type		= "ltc2990",
+	.addr		= 0x4c,
+	.platform_data	= &icy_ltc2990_platform_data,
 };
 
 static unsigned short const icy_ltc2990_addresses[] = {0x4c, I2C_CLIENT_END};
@@ -167,6 +181,8 @@ static int icy_probe(struct zorro_dev *z,
 	 *
 	 * in0 is the voltage of the internal 5V power supply.
 	 * temp1 is the temperature inside the chip.
+	 *
+	 * See platform data above for in1, in2, temp3.
 	 */
 	i2c->client_ltc2990 = i2c_new_probed_device(&i2c->adapter,
 						    &icy_ltc2990_info,
-- 
2.11.0


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-12 23:52 ` [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support Max Staudt
@ 2019-08-13  6:59   ` Geert Uytterhoeven
  2019-08-13  8:02   ` Guenter Roeck
  1 sibling, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2019-08-13  6:59 UTC (permalink / raw)
  To: Max Staudt
  Cc: Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, Linux/m68k, Linux Kernel Mailing List,
	John Paul Adrian Glaubitz

On Tue, Aug 13, 2019 at 1:53 AM Max Staudt <max@enpas.org> wrote:
> This allows code using i2c_new_device() to specify a measurement mode.
>
> Signed-off-by: Max Staudt <max@enpas.org>

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
  2019-08-12 23:52 ` [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision Max Staudt
@ 2019-08-13  7:03   ` Geert Uytterhoeven
  2019-08-13  9:49     ` Max Staudt
  0 siblings, 1 reply; 28+ messages in thread
From: Geert Uytterhoeven @ 2019-08-13  7:03 UTC (permalink / raw)
  To: Max Staudt
  Cc: Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, Linux/m68k, Linux Kernel Mailing List,
	John Paul Adrian Glaubitz

Hi Max,

On Tue, Aug 13, 2019 at 1:53 AM Max Staudt <max@enpas.org> 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 <max@enpas.org>

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(&z->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(&i2c->adapter);
>  }

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 4/4] i2c/busses/i2c-icy: Add platform_data for LTC2990
  2019-08-12 23:52 ` [PATCH v2 4/4] i2c/busses/i2c-icy: Add platform_data for LTC2990 Max Staudt
@ 2019-08-13  7:04   ` Geert Uytterhoeven
  0 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2019-08-13  7:04 UTC (permalink / raw)
  To: Max Staudt
  Cc: Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, Linux/m68k, Linux Kernel Mailing List,
	John Paul Adrian Glaubitz

Hi Max,

On Tue, Aug 13, 2019 at 1:54 AM Max Staudt <max@enpas.org> 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 <max@enpas.org>

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>

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 -- geert@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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-12 23:52 [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Max Staudt
                   ` (2 preceding siblings ...)
  2019-08-12 23:52 ` [PATCH v2 4/4] i2c/busses/i2c-icy: Add platform_data for LTC2990 Max Staudt
@ 2019-08-13  7:08 ` Geert Uytterhoeven
  2019-08-13  9:50   ` Max Staudt
  2019-08-14 19:47 ` Wolfram Sang
  4 siblings, 1 reply; 28+ messages in thread
From: Geert Uytterhoeven @ 2019-08-13  7:08 UTC (permalink / raw)
  To: Max Staudt
  Cc: Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, Linux/m68k, Linux Kernel Mailing List,
	John Paul Adrian Glaubitz

Hi Max,

On Tue, Aug 13, 2019 at 1:53 AM Max Staudt <max@enpas.org> 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 <max@enpas.org>

Thanks for the update!

> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-icy.c
> @@ -0,0 +1,189 @@

> +       dev_info(&z->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 -- geert@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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-12 23:52 ` [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support Max Staudt
  2019-08-13  6:59   ` Geert Uytterhoeven
@ 2019-08-13  8:02   ` Guenter Roeck
  2019-08-13  8:27     ` Geert Uytterhoeven
  2019-08-13 10:10     ` Max Staudt
  1 sibling, 2 replies; 28+ messages in thread
From: Guenter Roeck @ 2019-08-13  8:02 UTC (permalink / raw)
  To: Max Staudt
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, linux-m68k,
	linux-kernel, glaubitz

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 <max@enpas.org>
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
>  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 <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
> +#include <linux/platform_data/ltc2990.h>
>  
>  #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(&i2c->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 ?

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-13  8:02   ` Guenter Roeck
@ 2019-08-13  8:27     ` Geert Uytterhoeven
  2019-08-13 13:27       ` Guenter Roeck
  2019-08-13 10:10     ` Max Staudt
  1 sibling, 1 reply; 28+ messages in thread
From: Geert Uytterhoeven @ 2019-08-13  8:27 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Max Staudt, Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Linux/m68k, Linux Kernel Mailing List, John Paul Adrian Glaubitz

Hi Günter,

On Tue, Aug 13, 2019 at 10:02 AM Guenter Roeck <linux@roeck-us.net> 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 <max@enpas.org>
> > Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> >  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 <linux/kernel.h>
> >  #include <linux/module.h>
> >  #include <linux/of.h>
> > +#include <linux/platform_data/ltc2990.h>
> >
> >  #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(&i2c->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 -- geert@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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
  2019-08-13  7:03   ` Geert Uytterhoeven
@ 2019-08-13  9:49     ` Max Staudt
  2019-08-14 19:52       ` Wolfram Sang
  0 siblings, 1 reply; 28+ messages in thread
From: Max Staudt @ 2019-08-13  9:49 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, Linux/m68k, Linux Kernel Mailing List,
	John Paul Adrian Glaubitz

On 08/13/2019 09:03 AM, Geert Uytterhoeven wrote:
> Hi Max,
> 
> On Tue, Aug 13, 2019 at 1:53 AM Max Staudt <max@enpas.org> 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 <max@enpas.org>
> 
> 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(&z->dev);
>>
>> +       i2c_unregister_device(i2c->client_ltc2990);
> 
> Is this needed?
> In my understanding, i2c_del_adapter() below takes care of that.
It seems to do that in i2c_del_adapter():

  device_for_each_child(&adap->dev, NULL, __unregister_dummy);


However, I'm not sure I'm supposed to do that. I went by Documentation/i2c/instantiating-devices, which in "Method 2" says:

  The driver which instantiated the I2C device is responsible for destroying
  it on cleanup. This is done by calling i2c_unregister_device() on the
  pointer that was earlier returned by i2c_new_device() or
  i2c_new_probed_device().


So, what is preferred and why?


Thanks!

Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-13  7:08 ` [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Geert Uytterhoeven
@ 2019-08-13  9:50   ` Max Staudt
  0 siblings, 0 replies; 28+ messages in thread
From: Max Staudt @ 2019-08-13  9:50 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, Linux/m68k, Linux Kernel Mailing List,
	John Paul Adrian Glaubitz

On 08/13/2019 09:08 AM, Geert Uytterhoeven wrote:
>> +       dev_info(&z->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

Ack, this snuck in from the early days. Thanks for pointing this out!


Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-13  8:02   ` Guenter Roeck
  2019-08-13  8:27     ` Geert Uytterhoeven
@ 2019-08-13 10:10     ` Max Staudt
  2019-08-13 13:24       ` Guenter Roeck
  1 sibling, 1 reply; 28+ messages in thread
From: Max Staudt @ 2019-08-13 10:10 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, linux-m68k,
	linux-kernel, glaubitz

On 08/13/2019 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 <max@enpas.org>
>> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> ---
>>  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 <linux/kernel.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>> +#include <linux/platform_data/ltc2990.h>
>>  
>>  #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(&i2c->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 ?

The driver does have DT support implemented right above my new platform_data code, and DT takes precedence. However, I can't set DT data programatically when instantiating the client using i2c_new_device() - hence the platform_data support.

Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-13 10:10     ` Max Staudt
@ 2019-08-13 13:24       ` Guenter Roeck
  2019-08-13 13:31         ` Max
  2019-08-14 18:11         ` Max Staudt
  0 siblings, 2 replies; 28+ messages in thread
From: Guenter Roeck @ 2019-08-13 13:24 UTC (permalink / raw)
  To: Max Staudt
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, linux-m68k,
	linux-kernel, glaubitz

On 8/13/19 3:10 AM, Max Staudt wrote:
> On 08/13/2019 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 <max@enpas.org>
>>> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>> ---
>>>   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 <linux/kernel.h>
>>>   #include <linux/module.h>
>>>   #include <linux/of.h>
>>> +#include <linux/platform_data/ltc2990.h>
>>>   
>>>   #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(&i2c->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 ?
> 
> The driver does have DT support implemented right above my new platform_data code, and DT takes precedence. However, I can't set DT data programatically when instantiating the client using i2c_new_device() - hence the platform_data support.
> 

Sorry, I don't understand. Why exactly can't you replace of_property_read_u32_array()
with device_property_read_u32_array() and use fwnode_create_software_node()
in the calling code to set the properties ?

Guenter

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-13  8:27     ` Geert Uytterhoeven
@ 2019-08-13 13:27       ` Guenter Roeck
  2019-08-13 13:32         ` Geert Uytterhoeven
  0 siblings, 1 reply; 28+ messages in thread
From: Guenter Roeck @ 2019-08-13 13:27 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Max Staudt, Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Linux/m68k, Linux Kernel Mailing List, John Paul Adrian Glaubitz

On 8/13/19 1:27 AM, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> On Tue, Aug 13, 2019 at 10:02 AM Guenter Roeck <linux@roeck-us.net> 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 <max@enpas.org>
>>> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>> ---
>>>   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 <linux/kernel.h>
>>>   #include <linux/module.h>
>>>   #include <linux/of.h>
>>> +#include <linux/platform_data/ltc2990.h>
>>>
>>>   #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(&i2c->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
code and is always enabled unless I am missing something. What am I missing ?

Guenter

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-13 13:24       ` Guenter Roeck
@ 2019-08-13 13:31         ` Max
  2019-08-14 18:11         ` Max Staudt
  1 sibling, 0 replies; 28+ messages in thread
From: Max @ 2019-08-13 13:31 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, linux-m68k,
	linux-kernel, glaubitz

On 08/13/2019 03:24 PM, Guenter Roeck wrote:
> Sorry, I don't understand. Why exactly can't you replace of_property_read_u32_array()
> with device_property_read_u32_array() and use fwnode_create_software_node()
> in the calling code to set the properties ?

Sorry, I was unaware of this option. This sounds good, I'll look into it.

Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-13 13:27       ` Guenter Roeck
@ 2019-08-13 13:32         ` Geert Uytterhoeven
  0 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2019-08-13 13:32 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Max Staudt, Linux I2C, linux-hwmon, Wolfram Sang, Jean Delvare,
	Linux/m68k, Linux Kernel Mailing List, John Paul Adrian Glaubitz

Hi Günter,

On Tue, Aug 13, 2019 at 3:27 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 8/13/19 1:27 AM, Geert Uytterhoeven wrote:
> > On Tue, Aug 13, 2019 at 10:02 AM Guenter Roeck <linux@roeck-us.net> 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 <max@enpas.org>
> >>> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >>> ---
> >>>   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 <linux/kernel.h>
> >>>   #include <linux/module.h>
> >>>   #include <linux/of.h>
> >>> +#include <linux/platform_data/ltc2990.h>
> >>>
> >>>   #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(&i2c->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 -- geert@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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support
  2019-08-13 13:24       ` Guenter Roeck
  2019-08-13 13:31         ` Max
@ 2019-08-14 18:11         ` Max Staudt
  1 sibling, 0 replies; 28+ messages in thread
From: Max Staudt @ 2019-08-14 18:11 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare, linux-m68k,
	linux-kernel, glaubitz

Hi Guenter,

Thanks for your feedback!
Reply below.


On 08/13/2019 03:24 PM, Guenter Roeck wrote:
> Sorry, I don't understand. Why exactly can't you replace of_property_read_u32_array()
> with device_property_read_u32_array() and use fwnode_create_software_node()
> in the calling code to set the properties ?

Thanks for this hint.

Turns out wcove is the only user of fwnode_create_software_node(), and intel_cht_int33fe is the only other driver to contain the string "software_node". Please bear with us if we didn't know about this handy trick yet. And handy it is!

device_property_read_*() is also really helpful to know about, as it covers both the DT case, as well as other firmware interfaces - thanks for the hint. Is there any reason to ever use of_property_read_*() anymore?

I've applied your suggested changes, and will send another patch round soon (I want to try one last thing). Please let me/us know what you think once it's on the list.


Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-12 23:52 [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Max Staudt
                   ` (3 preceding siblings ...)
  2019-08-13  7:08 ` [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Geert Uytterhoeven
@ 2019-08-14 19:47 ` Wolfram Sang
  2019-08-14 22:33   ` Max Staudt
  4 siblings, 1 reply; 28+ messages in thread
From: Wolfram Sang @ 2019-08-14 19:47 UTC (permalink / raw)
  To: Max Staudt
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

Hi,

Thanks for the patch. It looks mostly good.

> +static int clock = 0x1c;
> +module_param(clock, int, 0444);

'clock' determines the bus speed?

> +	i2c->adapter.class = I2C_CLASS_DEPRECATED;

This is only needed for drivers which used to have a class and decided
to drop it. You can leave it empty.

> +	algo_data->data = (void *)i2c;

You don't need the cast, do you?

> +MODULE_LICENSE("GPL");

Your SPDX header says GPL 2.0 only.

Kind regards,

   Wolfram

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision
  2019-08-13  9:49     ` Max Staudt
@ 2019-08-14 19:52       ` Wolfram Sang
  0 siblings, 0 replies; 28+ messages in thread
From: Wolfram Sang @ 2019-08-14 19:52 UTC (permalink / raw)
  To: Max Staudt
  Cc: Geert Uytterhoeven, Linux I2C, linux-hwmon, Wolfram Sang,
	Jean Delvare, Guenter Roeck, Linux/m68k,
	Linux Kernel Mailing List, John Paul Adrian Glaubitz

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

> However, I'm not sure I'm supposed to do that. I went by Documentation/i2c/instantiating-devices, which in "Method 2" says:
> 
>   The driver which instantiated the I2C device is responsible for destroying
>   it on cleanup. This is done by calling i2c_unregister_device() on the
>   pointer that was earlier returned by i2c_new_device() or
>   i2c_new_probed_device().
> 
> 
> So, what is preferred and why?

What the documentation says is preferred. For consistency and because of
the general "free what you allocated" rule. If we have arguments to
change that for i2c_unregister_device(), we would need to do this
tree-wide anyhow. Until then, the above is valid.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-14 19:47 ` Wolfram Sang
@ 2019-08-14 22:33   ` Max Staudt
  2019-08-15  7:12     ` Wolfram Sang
  0 siblings, 1 reply; 28+ messages in thread
From: Max Staudt @ 2019-08-14 22:33 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

Hi Wolfram,

Thanks for your input!
Replies below.


On 08/14/2019 09:47 PM, Wolfram Sang wrote:
>> +static int clock = 0x1c;
>> +module_param(clock, int, 0444);
> 
> 'clock' determines the bus speed?

Yes, but it also determines the frequency of the oscillator driving the PCF8584. It doesn't usually need to be touched, the current setting drives at the maximum I2C bus speed, with the maximum oscillator (12 MHz).
I kept it in because i2c-elektor also exposes it in the same way, and it seems useful.


>> +	i2c->adapter.class = I2C_CLASS_DEPRECATED;
> 
> This is only needed for drivers which used to have a class and decided
> to drop it. You can leave it empty.

Thanks, I'll drop it.


>> +	algo_data->data = (void *)i2c;
> 
> You don't need the cast, do you?

True. Dropped, thanks.


>> +MODULE_LICENSE("GPL");
> 
> Your SPDX header says GPL 2.0 only.

Thanks! I'll change it to "GPL v2", but unfortunately there is no option for "only" in include/linux/module.h.


Cheers

Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-14 22:33   ` Max Staudt
@ 2019-08-15  7:12     ` Wolfram Sang
  2019-08-15 10:00       ` Max Staudt
  0 siblings, 1 reply; 28+ messages in thread
From: Wolfram Sang @ 2019-08-15  7:12 UTC (permalink / raw)
  To: Max Staudt
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]


> I kept it in because i2c-elektor also exposes it in the same way, and
> it seems useful.

Yeah, I noticed. I don't know how useful it is in practice (same for the
getown callback) but I don't have better ideas, so let's just keep this
to be consistent.

> > Your SPDX header says GPL 2.0 only.
> 
> Thanks! I'll change it to "GPL v2", but unfortunately there is no
> option for "only" in include/linux/module.h.

That's the correct option.

Thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-15  7:12     ` Wolfram Sang
@ 2019-08-15 10:00       ` Max Staudt
  2019-08-15 11:48         ` Wolfram Sang
  0 siblings, 1 reply; 28+ messages in thread
From: Max Staudt @ 2019-08-15 10:00 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

On 08/15/2019 09:12 AM, Wolfram Sang wrote:
>> I kept it in because i2c-elektor also exposes it in the same way, and
>> it seems useful.
> 
> Yeah, I noticed. I don't know how useful it is in practice (same for the
> getown callback) but I don't have better ideas, so let's just keep this
> to be consistent.

Well, the other option is to remove it, and then add it back once somebody complains - which is unlikely to happen. The clock parameter is PCF8584 specific anyway, and  I think removing it is a good option, as I've done the same with getown() (where in i2c-elektor, 'own' sets the PCF8584's own address).

Question is, if I remove the parameter, I'd like it to be non-destructive. Do you know of anything that can go wrong if the I2C master is running the bus on a wrong clock?


Thanks

Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-15 10:00       ` Max Staudt
@ 2019-08-15 11:48         ` Wolfram Sang
  2019-08-15 11:52           ` Max
  0 siblings, 1 reply; 28+ messages in thread
From: Wolfram Sang @ 2019-08-15 11:48 UTC (permalink / raw)
  To: Max Staudt
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]


> Well, the other option is to remove it, and then add it back once
> somebody complains - which is unlikely to happen. The clock parameter
> is PCF8584 specific anyway, and  I think removing it is a good option,

My suggestion is to do that incrementally. First, get your driver
accepted. Second, do the cleanups which affect elektor as well later.

> as I've done the same with getown() (where in i2c-elektor, 'own' sets
> the PCF8584's own address).

I wondered about that. Can the PCF8584 really act as a slave, too?
Somewhen I need to check its datasheet.

> Question is, if I remove the parameter, I'd like it to be
> non-destructive. Do you know of anything that can go wrong if the I2C
> master is running the bus on a wrong clock?

Not sure if I understand you correctly, but if the bus freq is too fast
then devices won't respond. Too slow is not a problem.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-15 11:48         ` Wolfram Sang
@ 2019-08-15 11:52           ` Max
  2019-08-15 12:04             ` Wolfram Sang
  0 siblings, 1 reply; 28+ messages in thread
From: Max @ 2019-08-15 11:52 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

On 08/15/2019 01:48 PM, Wolfram Sang wrote:
>> Well, the other option is to remove it, and then add it back once
>> somebody complains - which is unlikely to happen. The clock parameter
>> is PCF8584 specific anyway, and  I think removing it is a good option,
> 
> My suggestion is to do that incrementally. First, get your driver
> accepted. Second, do the cleanups which affect elektor as well later.

My suggestion is to not touch i2c-elektor at all for now, and remove the 'clock' parameter from the first iteration of i2c-icy. It can be added back in case someone complains, which I deem unlikely.


>> as I've done the same with getown() (where in i2c-elektor, 'own' sets
>> the PCF8584's own address).
> 
> I wondered about that. Can the PCF8584 really act as a slave, too?
> Somewhen I need to check its datasheet.

Yes it can, but this driver does not implement this.

In fact, I just remembered that the own address, while set, is not used at all in master mode!

Quote from the datasheet:
https://www.nxp.com/docs/en/data-sheet/PCF8584.pdf

  6.4 Own address register S0'

  When the PCF8584 is addressed as slave, this register
  must be loaded with the 7-bit I 2 C-bus address to which the
  PCF8584 is to respond. During initialization, the own
  address register S0' must be written to, regardless
  whether it is later used.


>> Question is, if I remove the parameter, I'd like it to be
>> non-destructive. Do you know of anything that can go wrong if the I2C
>> master is running the bus on a wrong clock?
> 
> Not sure if I understand you correctly, but if the bus freq is too fast
> then devices won't respond. Too slow is not a problem.

Okay, so we don't care. Cool, then it's safe to kick the 'clock' parameter from i2c-icy. All 2019 boards (which should be the vast majority in existence) came with a 12 MHz oscillator AFAIK, so the default should be good.


Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-15 11:52           ` Max
@ 2019-08-15 12:04             ` Wolfram Sang
  2019-08-15 12:10               ` Max Staudt
  0 siblings, 1 reply; 28+ messages in thread
From: Wolfram Sang @ 2019-08-15 12:04 UTC (permalink / raw)
  To: Max
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]


> My suggestion is to not touch i2c-elektor at all for now, and remove
> the 'clock' parameter from the first iteration of i2c-icy. It can be
> added back in case someone complains, which I deem unlikely.

Full ack.

>   When the PCF8584 is addressed as slave, this register
>   must be loaded with the 7-bit I 2 C-bus address to which the
>   PCF8584 is to respond. During initialization, the own
>   address register S0' must be written to, regardless
>   whether it is later used.

I see. It must be written a non-zero value to leave the monitor mode.
But this really needs no callback, we can hardcode any non-zero value.
If slave support is (ever) to be implemented, the own address will come
from the I2C core.

> Okay, so we don't care. Cool, then it's safe to kick the 'clock'
> parameter from i2c-icy. All 2019 boards (which should be the vast
> majority in existence) came with a 12 MHz oscillator AFAIK, so the
> default should be good.

Most drivers don't allow users to change the bus speed, so I think it is
safe to remove.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-15 12:04             ` Wolfram Sang
@ 2019-08-15 12:10               ` Max Staudt
  2019-08-15 12:52                 ` Wolfram Sang
  0 siblings, 1 reply; 28+ messages in thread
From: Max Staudt @ 2019-08-15 12:10 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

On 08/15/2019 02:04 PM, Wolfram Sang wrote:
>>   When the PCF8584 is addressed as slave, this register
>>   must be loaded with the 7-bit I 2 C-bus address to which the
>>   PCF8584 is to respond. During initialization, the own
>>   address register S0' must be written to, regardless
>>   whether it is later used.
> 
> I see. It must be written a non-zero value to leave the monitor mode.
> But this really needs no callback, we can hardcode any non-zero value.
> If slave support is (ever) to be implemented, the own address will come
> from the I2C core.
The callback, just like getclock(), is from the existing i2c-algo-pcf, which I don't want to touch right now. So I'm afraid it has to stay, even if it returns a fixed number.

Touching or forking i2c-algo-pcf will be necessary in order to implement IRQ support, if I ever get around to it. I've wasted too much time on debugging IRQ support, and would rather do it another time, if ever ;)
I've left a comment block at the start of i2c-icy.c for anyone interested in the gory details.


If this is okay with you, I'll send another round of patches. :)


Thanks!

Max

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga
  2019-08-15 12:10               ` Max Staudt
@ 2019-08-15 12:52                 ` Wolfram Sang
  0 siblings, 0 replies; 28+ messages in thread
From: Wolfram Sang @ 2019-08-15 12:52 UTC (permalink / raw)
  To: Max Staudt
  Cc: linux-i2c, linux-hwmon, Wolfram Sang, Jean Delvare,
	Guenter Roeck, linux-m68k, linux-kernel, glaubitz

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]


> The callback, just like getclock(), is from the existing i2c-algo-pcf,
> which I don't want to touch right now. So I'm afraid it has to stay,
> even if it returns a fixed number.

Sure. I was just thinking loud and did not expect you to do it. Maybe I
will do it once your driver is upstream.

> Touching or forking i2c-algo-pcf will be necessary in order to
> implement IRQ support, if I ever get around to it. I've wasted too
> much time on debugging IRQ support, and would rather do it another
> time, if ever ;) I've left a comment block at the start of i2c-icy.c
> for anyone interested in the gory details.

Yeah, I read it. I like such documentation. Really helpful!

> If this is okay with you, I'll send another round of patches. :)

Perfect!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, back to index

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-12 23:52 [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Max Staudt
2019-08-12 23:52 ` [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision Max Staudt
2019-08-13  7:03   ` Geert Uytterhoeven
2019-08-13  9:49     ` Max Staudt
2019-08-14 19:52       ` Wolfram Sang
2019-08-12 23:52 ` [PATCH v2 3/4] hwmon/ltc2990: Add platform_data support Max Staudt
2019-08-13  6:59   ` Geert Uytterhoeven
2019-08-13  8:02   ` Guenter Roeck
2019-08-13  8:27     ` Geert Uytterhoeven
2019-08-13 13:27       ` Guenter Roeck
2019-08-13 13:32         ` Geert Uytterhoeven
2019-08-13 10:10     ` Max Staudt
2019-08-13 13:24       ` Guenter Roeck
2019-08-13 13:31         ` Max
2019-08-14 18:11         ` Max Staudt
2019-08-12 23:52 ` [PATCH v2 4/4] i2c/busses/i2c-icy: Add platform_data for LTC2990 Max Staudt
2019-08-13  7:04   ` Geert Uytterhoeven
2019-08-13  7:08 ` [PATCH v2 1/4] i2c/busses: Add i2c-icy for I2C on m68k/Amiga Geert Uytterhoeven
2019-08-13  9:50   ` Max Staudt
2019-08-14 19:47 ` Wolfram Sang
2019-08-14 22:33   ` Max Staudt
2019-08-15  7:12     ` Wolfram Sang
2019-08-15 10:00       ` Max Staudt
2019-08-15 11:48         ` Wolfram Sang
2019-08-15 11:52           ` Max
2019-08-15 12:04             ` Wolfram Sang
2019-08-15 12:10               ` Max Staudt
2019-08-15 12:52                 ` Wolfram Sang

Linux-Hwmon Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-hwmon/0 linux-hwmon/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-hwmon linux-hwmon/ https://lore.kernel.org/linux-hwmon \
		linux-hwmon@vger.kernel.org
	public-inbox-index linux-hwmon

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-hwmon


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git