For making things build again:
Acked-by: Mike Looijmans
I'd be interested in use-cases for having nvmem as a module, I cannot think of
any.
I am working on splitting of_get_nvmem_mac_address(), by moving most of its
burden to the nvmem interface. Intend to create this "just give
For making things build again:
Acked-by: Mike Looijmans
I'd be interested in use-cases for having nvmem as a module, I cannot think of
any.
I am working on splitting of_get_nvmem_mac_address(), by moving most of its
burden to the nvmem interface. Intend to create this "just give
make much sense anyway, but that's not up to me.
Moving the code from of to nvmem seems weird, but would solve it.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: m
make much sense anyway, but that's not up to me.
Moving the code from of to nvmem seems weird, but would solve it.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: m
On 30-03-18 16:40, David Miller wrote:
From: Mike Looijmans <mike.looijm...@topic.nl>
Date: Thu, 29 Mar 2018 07:29:47 +0200
Posted this as a small set now, with an (optional) second patch that shows
how the changes work and what I've used to test the code on a Topic Miami board.
I've
On 30-03-18 16:40, David Miller wrote:
From: Mike Looijmans
Date: Thu, 29 Mar 2018 07:29:47 +0200
Posted this as a small set now, with an (optional) second patch that shows
how the changes work and what I've used to test the code on a Topic Miami board.
I've taken the liberty to add
On 25-03-18 10:17, Mike Looijmans wrote:
On 24-03-18 19:53, Andrew Lunn wrote:
A quick survey for the of_get_mac_address users learns that most of them do
a memcpy (or similar) right after it, so for these drivers the
"of_get_nvmem_mac_address" style signature that performs
On 25-03-18 10:17, Mike Looijmans wrote:
On 24-03-18 19:53, Andrew Lunn wrote:
A quick survey for the of_get_mac_address users learns that most of them do
a memcpy (or similar) right after it, so for these drivers the
"of_get_nvmem_mac_address" style signature that performs
On 28-03-18 00:50, Florian Fainelli wrote:
On 03/27/2018 02:52 AM, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address() for drivers
On 28-03-18 00:50, Florian Fainelli wrote:
On 03/27/2018 02:52 AM, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address() for drivers
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
Reviewed-by: Florian Fainelli <f.faine...@gmail.com>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
---
Documentation/devic
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Signed-off-by: Mike Looijmans
Reviewed-by: Florian Fainelli
Reviewed-by: Andrew Lunn
---
Documentation/devicetree/bindings/net/ethernet.txt | 2 ++
drivers/of/of_net.c
Call of_get_nvmem_mac_address() to fetch the MAC address from an nvmem
cell, if one is provided in the device tree. This allows the address to
be stored in an I2C EEPROM device for example.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
Acked-by: Nicolas Ferre <n
Call of_get_nvmem_mac_address() to fetch the MAC address from an nvmem
cell, if one is provided in the device tree. This allows the address to
be stored in an I2C EEPROM device for example.
Signed-off-by: Mike Looijmans
Acked-by: Nicolas Ferre
---
drivers/net/ethernet/cadence/macb_main.c | 12
Add patch that implements mac in nvmem for the Cadence MACB controller
Remove the integrated of_get_mac_address call
v2: Use of_nvmem_cell_get to avoid needing the assiciated device
Use void* instead of char*
Add devicetree binding doc
Mike Looijmans (2):
of_net: Implement of_get_nvmem_
Add patch that implements mac in nvmem for the Cadence MACB controller
Remove the integrated of_get_mac_address call
v2: Use of_nvmem_cell_get to avoid needing the assiciated device
Use void* instead of char*
Add devicetree binding doc
Mike Looijmans (2):
of_net: Implement of_get_nvmem_
of_nvmem_cell_get to avoid needing the assiciated device
Use void* instead of char*
Add devicetree binding doc
Mike Looijmans (2):
of_net: Implement of_get_nvmem_mac_address helper
net: macb: Try to retrieve MAC addess from nvmem provider
Documentation/devicetree/bindings/net/ethernet.txt
of_nvmem_cell_get to avoid needing the assiciated device
Use void* instead of char*
Add devicetree binding doc
Mike Looijmans (2):
of_net: Implement of_get_nvmem_mac_address helper
net: macb: Try to retrieve MAC addess from nvmem provider
Documentation/devicetree/bindings/net/ethernet.txt
Call of_get_nvmem_mac_address() to fetch the MAC address from an nvmem
cell, if one is provided in the device tree. This allows the address to
be stored in an I2C EEPROM device for example.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/net/ethernet/cadence/macb_main.
Call of_get_nvmem_mac_address() to fetch the MAC address from an nvmem
cell, if one is provided in the device tree. This allows the address to
be stored in an I2C EEPROM device for example.
Signed-off-by: Mike Looijmans
---
drivers/net/ethernet/cadence/macb_main.c | 12 +---
1 file
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Documentation/devicetree/bindings/net/ethernet.txt | 2 ++
drivers/of/of_net.c
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Signed-off-by: Mike Looijmans
---
Documentation/devicetree/bindings/net/ethernet.txt | 2 ++
drivers/of/of_net.c| 40 ++
include/linux/of_net.h
On 26-03-18 17:50, Andrew Lunn wrote:
On Mon, Mar 26, 2018 at 08:41:29AM +0200, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address
On 26-03-18 17:50, Andrew Lunn wrote:
On Mon, Mar 26, 2018 at 08:41:29AM +0200, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address
On 26-03-18 19:05, Florian Fainelli wrote:
On 03/26/2018 09:58 AM, David Miller wrote:
From: Mike Looijmans <mike.looijm...@topic.nl>
Date: Mon, 26 Mar 2018 08:41:29 +0200
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actua
On 26-03-18 19:05, Florian Fainelli wrote:
On 03/26/2018 09:58 AM, David Miller wrote:
From: Mike Looijmans
Date: Mon, 26 Mar 2018 08:41:29 +0200
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Tested by adapting the cadence macb driver to call this instead of
of_get_mac_address().
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Use of_nvmem_cell_get to avoid n
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Tested by adapting the cadence macb driver to call this instead of
of_get_mac_address().
Signed-off-by: Mike Looijmans
---
v2: Use of_nvmem_cell_get to avoid needing the assiciated device
Use
ootlin.com/linux/v4.16-rc6/ident/of_get_mac_address
I have no experience with Coccinelle though.
--
Mike Looijmans
ootlin.com/linux/v4.16-rc6/ident/of_get_mac_address
I have no experience with Coccinelle though.
--
Mike Looijmans
On 23-03-18 20:33, Florian Fainelli wrote:
On 03/23/2018 12:20 PM, Mike Looijmans wrote:
On 23-3-2018 16:11, Andrew Lunn wrote:
On Fri, Mar 23, 2018 at 03:24:34PM +0100, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However
On 23-03-18 20:33, Florian Fainelli wrote:
On 03/23/2018 12:20 PM, Mike Looijmans wrote:
On 23-3-2018 16:11, Andrew Lunn wrote:
On Fri, Mar 23, 2018 at 03:24:34PM +0100, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However
ell, while
of_get_mac_address() only gets passed the DT node.
Does of_nvmem_cell_get() help?
Yes, looking at the interface, it would.
--
Mike Looijmans
ell, while
of_get_mac_address() only gets passed the DT node.
Does of_nvmem_cell_get() help?
Yes, looking at the interface, it would.
--
Mike Looijmans
On 23-3-2018 16:11, Andrew Lunn wrote:
On Fri, Mar 23, 2018 at 03:24:34PM +0100, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address
On 23-3-2018 16:11, Andrew Lunn wrote:
On Fri, Mar 23, 2018 at 03:24:34PM +0100, Mike Looijmans wrote:
It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Tested by adapting the cadence macb driver to call this instead of
of_get_mac_address().
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/of/of_net.c
the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.
Tested by adapting the cadence macb driver to call this instead of
of_get_mac_address().
Signed-off-by: Mike Looijmans
---
drivers/of/of_net.c| 48
On 19-03-18 22:08, Stephen Boyd wrote:
Quoting Mike Looijmans (2018-03-19 08:04:15)
On 18-03-18 13:52, Rob Herring wrote:
On Thu, Mar 15, 2018 at 12:50:08PM +0100, Mike Looijmans wrote:
+Required properties:
+ - compatible: One of "silabs,si514a", "silabs,si514b" "
On 19-03-18 22:08, Stephen Boyd wrote:
Quoting Mike Looijmans (2018-03-19 08:04:15)
On 18-03-18 13:52, Rob Herring wrote:
On Thu, Mar 15, 2018 at 12:50:08PM +0100, Mike Looijmans wrote:
+Required properties:
+ - compatible: One of "silabs,si514a", "silabs,si514b" "
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from 200kHz
to 1500MHz.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Add u6
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from 200kHz
to 1500MHz.
Signed-off-by: Mike Looijmans
---
v2: Add u64 cast to ls_div_bits calculation loop
On 18-03-18 13:52, Rob Herring wrote:
On Thu, Mar 15, 2018 at 12:50:08PM +0100, Mike Looijmans wrote:
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from
On 18-03-18 13:52, Rob Herring wrote:
On Thu, Mar 15, 2018 at 12:50:08PM +0100, Mike Looijmans wrote:
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from
:
https://github.com/0day-ci/linux/commits/Mike-Looijmans/clk-Add-driver-for-the-si544-clock-generator-chip/20180314-122736
smatch warnings:
drivers/clk/clk-si544.c:188 si544_calc_muldiv() warn: impossible condition '((frequency
* tmp) >= 108) => (0-u32max >= 108)'
:
https://github.com/0day-ci/linux/commits/Mike-Looijmans/clk-Add-driver-for-the-si544-clock-generator-chip/20180314-122736
smatch warnings:
drivers/clk/clk-si544.c:188 si544_calc_muldiv() warn: impossible condition '((frequency
* tmp) >= 108) => (0-u32max >= 108)'
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from 200kHz
to 1500MHz.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Add u6
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from 200kHz
to 1500MHz.
Signed-off-by: Mike Looijmans
---
v2: Add u64 cast to ls_div_bits calculation loop
rning when the GPIO controller is an I2C expander
or something similar.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/clk/clk-gpio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 151513c
rning when the GPIO controller is an I2C expander
or something similar.
Signed-off-by: Mike Looijmans
---
drivers/clk/clk-gpio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 151513c..40af4fb 100644
--- a/drivers/clk/clk-gp
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from 200kHz
to 1500MHz.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
.../devicetree/bi
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from 200kHz
to 1500MHz.
Signed-off-by: Mike Looijmans
---
.../devicetree/bindings/clock/silabs,si544.txt
The nop_reset and shutdown methods are called in a context that can sleep,
so use gpiod_set_value_cansleep instead of gpiod_set_value.
If you've connected the reset line to a GPIO expander, you'd get a kernel
"slowpath" warning with gpiod_set_value.
Signed-off-by: Mike Looijmans &l
The nop_reset and shutdown methods are called in a context that can sleep,
so use gpiod_set_value_cansleep instead of gpiod_set_value.
If you've connected the reset line to a GPIO expander, you'd get a kernel
"slowpath" warning with gpiod_set_value.
Signed-off-by: Mike Looijmans
--
On 05-12-17 10:08, Ladislav Michl wrote:
On Tue, Dec 05, 2017 at 08:10:27AM +0100, Mike Looijmans wrote:
On 01-12-17 16:42, Sebastian Reichel wrote:
Hi,
On Thu, Nov 23, 2017 at 03:41:05PM +0100, Mike Looijmans wrote:
The driver sets the fuel gauge to continuous monitoring on startup
On 05-12-17 10:08, Ladislav Michl wrote:
On Tue, Dec 05, 2017 at 08:10:27AM +0100, Mike Looijmans wrote:
On 01-12-17 16:42, Sebastian Reichel wrote:
Hi,
On Thu, Nov 23, 2017 at 03:41:05PM +0100, Mike Looijmans wrote:
The driver sets the fuel gauge to continuous monitoring on startup
On 01-12-17 16:42, Sebastian Reichel wrote:
Hi,
On Thu, Nov 23, 2017 at 03:41:05PM +0100, Mike Looijmans wrote:
The driver sets the fuel gauge to continuous monitoring on startup, for
the models that support this. When the board shuts down, the chip remains
in that mode, causing a few mA
On 01-12-17 16:42, Sebastian Reichel wrote:
Hi,
On Thu, Nov 23, 2017 at 03:41:05PM +0100, Mike Looijmans wrote:
The driver sets the fuel gauge to continuous monitoring on startup, for
the models that support this. When the board shuts down, the chip remains
in that mode, causing a few mA
to
prevent this battery drain.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/power/supply/ltc2941-battery-gauge.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/power/supply/ltc2941-battery-gauge.c
b/drivers/power/supply/ltc2941-b
to
prevent this battery drain.
Signed-off-by: Mike Looijmans
---
drivers/power/supply/ltc2941-battery-gauge.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/power/supply/ltc2941-battery-gauge.c
b/drivers/power/supply/ltc2941-battery-gauge.c
index 08e4fd9
3: attempt power cycle
usb 1-1.3: new high-speed USB device number 21 using ci_hdrc
usb-storage 1-1.3:1.2: USB Mass Storage device detected
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: On feedback from Alan Stern:
No blank line changes
Don't further increase
3: attempt power cycle
usb 1-1.3: new high-speed USB device number 21 using ci_hdrc
usb-storage 1-1.3:1.2: USB Mass Storage device detected
Signed-off-by: Mike Looijmans
---
v2: On feedback from Alan Stern:
No blank line changes
Don't further increase the retry count
Delay 2x th
On 03-11-17 18:27, Alan Stern wrote:
On Fri, 3 Nov 2017, Mike Looijmans wrote:
Sometimes the USB device gets confused about the state of the initialization and
the connection fails. In particular, the device thinks that it's already set up
and running while the host thinks the device still
On 03-11-17 18:27, Alan Stern wrote:
On Fri, 3 Nov 2017, Mike Looijmans wrote:
Sometimes the USB device gets confused about the state of the initialization and
the connection fails. In particular, the device thinks that it's already set up
and running while the host thinks the device still
3: attempt power cycle
usb 1-1.3: new high-speed USB device number 21 using ci_hdrc
usb-storage 1-1.3:1.2: USB Mass Storage device detected
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
This is a fix I did for a customer which might be appropriate for upstream.
What do you thin
3: attempt power cycle
usb 1-1.3: new high-speed USB device number 21 using ci_hdrc
usb-storage 1-1.3:1.2: USB Mass Storage device detected
Signed-off-by: Mike Looijmans
---
This is a fix I did for a customer which might be appropriate for upstream.
What do you think?
drivers/usb/core/
a/Documentation/hwmon/ltc2990
+++ b/Documentation/hwmon/ltc2990
@@ -8,6 +8,7 @@ Supported chips:
Datasheet: http://www.linear.com/product/ltc2990
Author: Mike Looijmans <mike.looijm...@topic.nl>
+Tom Levens <tom.lev...@cern.ch>
Description
@@ -16,10 +17,8 @@ Desc
2990
+++ b/Documentation/hwmon/ltc2990
@@ -8,6 +8,7 @@ Supported chips:
Datasheet: http://www.linear.com/product/ltc2990
Author: Mike Looijmans
+Tom Levens
Description
@@ -16,10 +17,8 @@ Description
LTC2990 is a Quad I2C Voltage, Current and Temperature Monitor.
T
The LTC2741 and LTC2473 are single voltage ADC chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: (LC) Add empty line,
The LTC2741 and LTC2473 are single voltage ADC chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans
---
v2: (LC) Add empty line, remove i2c_set_clientdata
(PS
below
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
Enough here that I've dropped the patch for now and look forward
to a v2 incorporating both Peter and Lars' comments.
I'll create and send a v2 probably tomorrow.
://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans
Enough here that I've dropped the patch for now and look forward
to a v2 incorporating both Peter and Lars' comments.
I'll create and send a v2 probably tomorrow.
Kind regards,
Mike Looijmans
System Expert
TOPIC
The LTC2741 and LTC2473 are single voltage ADC chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Note: Moved from "hwmon
The LTC2741 and LTC2473 are single voltage ADC chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans
---
Note: Moved from "hwmon" subsystem to "iio"
On 29-06-17 15:40, Guenter Roeck wrote:
On 06/29/2017 05:30 AM, Lars-Peter Clausen wrote:
On 06/29/2017 02:13 PM, Mike Looijmans wrote:
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet
On 29-06-17 15:40, Guenter Roeck wrote:
On 06/29/2017 05:30 AM, Lars-Peter Clausen wrote:
On 06/29/2017 02:13 PM, Mike Looijmans wrote:
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet
On 29-06-17 14:30, Lars-Peter Clausen wrote:
On 06/29/2017 02:13 PM, Mike Looijmans wrote:
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet
On 29-06-17 14:30, Lars-Peter Clausen wrote:
On 06/29/2017 02:13 PM, Mike Looijmans wrote:
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet
On 29-06-17 13:38, Frans Klaver wrote:
On Thu, Jun 29, 2017 at 1:30 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:
On 29-06-17 13:18, Frans Klaver wrote:
On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:
The LTC2741 and LTC2473 are si
On 29-06-17 13:38, Frans Klaver wrote:
On Thu, Jun 29, 2017 at 1:30 PM, Mike Looijmans wrote:
On 29-06-17 13:18, Frans Klaver wrote:
On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans
wrote:
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Use sizeof(*data) i
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans
---
v2: Use sizeof(*data) instead of struct name
Use
On 29-06-17 13:18, Frans Klaver wrote:
On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
On 29-06-17 13:18, Frans Klaver wrote:
On Thu, Jun 29, 2017 at 12:45 PM, Mike Looijmans
wrote:
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
drivers/hwmon/Kconfig
The LTC2741 and LTC2473 are single voltage monitoring chips. The LTC2473
is similar to the LTC2471 but outputs a signed differential value.
Datasheet:
http://cds.linear.com/docs/en/datasheet/24713fb.pdf
Signed-off-by: Mike Looijmans
---
drivers/hwmon/Kconfig | 10
drivers/hwmon
emperature reading as well.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
emperature reading as well.
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
a
"safe" mode until the mode has been selected.
Mike, if you would like to test it, the latest version of my code is here:
https://github.com/levens/ltc2990/blob/dev/drivers/hwmon/ltc2990.c
Sure, I even have a board with 2 of these devices now :)
--
Mike Looijmans
Kind rega
a
"safe" mode until the mode has been selected.
Mike, if you would like to test it, the latest version of my code is here:
https://github.com/levens/ltc2990/blob/dev/drivers/hwmon/ltc2990.c
Sure, I even have a board with 2 of these devices now :)
--
Mike Looijmans
Kind rega
/product/ltc2990
Author: Mike Looijmans <mike.looijm...@topic.nl>
+Tom Levens <tom.lev...@cern.ch>
Description
@@ -16,10 +17,8 @@ Description
LTC2990 is a Quad I2C Voltage, Current and Temperature Monitor.
The chip's inputs can measure 4 voltages, or two inputs together (1
quot;Error: Failed to set control mode.\n");
return ret;
@@ -127,7 +244,7 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
hwmon_dev = devm_hwmon_device_register_with_groups(>dev,
i2c->name,
- i2c,
+
ns
thereof.
The device mode is configured by using the "mode" value as device name,
e.g. specifying compatible="lltc,ltc2990-6" in the devicetree will set it
to dual-current monitoring mode (6). For backward compatibility, the
default is mode 6.
Signed-off-by: Mike Looi
ns
thereof.
The device mode is configured by using the "mode" value as device name,
e.g. specifying compatible="lltc,ltc2990-6" in the devicetree will set it
to dual-current monitoring mode (6). For backward compatibility, the
default is mode 6.
Signed-off-by: Mike Looijma
On 08-05-17 19:12, Rob Herring wrote:
On Fri, May 05, 2017 at 08:38:35AM +0200, Mike Looijmans wrote:
This adds the devicetree bindings documentation for the LTC3651 battery charger.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
.../bindings/power/supply/ltc3651-charg
On 08-05-17 19:12, Rob Herring wrote:
On Fri, May 05, 2017 at 08:38:35AM +0200, Mike Looijmans wrote:
This adds the devicetree bindings documentation for the LTC3651 battery charger.
Signed-off-by: Mike Looijmans
---
.../bindings/power/supply/ltc3651-charger.txt | 26
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO configuration.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v3: Add "lltc" vendor pr
The LTC3651 reports its status via GPIO lines. This driver translates
the GPIO levels to battery charger status information via sysfs.
It relies on devicetree to supply the IO configuration.
Signed-off-by: Mike Looijmans
---
v3: Add "lltc" vendor prefix to DT gpios properties
v2: Rem
This adds the devicetree bindings documentation for the LTC3651 battery charger.
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Add "lltc," vendor prefix to gpios
Expand irq paragraph
.../bindings/power/supply/ltc3651-charger.txt | 27 ++
This adds the devicetree bindings documentation for the LTC3651 battery charger.
Signed-off-by: Mike Looijmans
---
v2: Add "lltc," vendor prefix to gpios
Expand irq paragraph
.../bindings/power/supply/ltc3651-charger.txt | 27 ++
1 file changed, 27
101 - 200 of 552 matches
Mail list logo
