From: Darren Hart <dvhart@infradead.org>
To: Lubomir Rintel <lkundrak@v3.sk>
Cc: Mark Brown <broonie@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Andy Shevchenko <andy@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
James Cameron <quozl@laptop.org>,
Sebastian Reichel <sre@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Eric Miao <eric.y.miao@gmail.com>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Daniel Mack <daniel@zonque.org>,
Robert Jarzmik <robert.jarzmik@free.fr>,
linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
platform-driver-x86@vger.kernel.org, devel@driverdev.osuosl.org,
linux-pm@vger.kernel.org
Subject: Re: [PATCH v2 17/17] power: supply: olpc_battery: Add OLPC XO 1.75 support
Date: Sun, 2 Dec 2018 15:34:58 -0800 [thread overview]
Message-ID: <20181202233458.GE23087@wrath> (raw)
In-Reply-To: <20181116162403.49854-18-lkundrak@v3.sk>
On Fri, Nov 16, 2018 at 05:24:03PM +0100, Lubomir Rintel wrote:
> The battery and the protocol are essentially the same as OLPC XO 1.5,
> but the responses from the EC are LSB first.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Acked-by: Pavel Machek <pavel@ucw.cz>
>
> ---
> Changes since v1:
> - s/s16 ecword_to_cpu/u16 ecword_to_cpu/
> - s/u16 ec_byte/u16 ec_word/
>
> drivers/power/supply/olpc_battery.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/supply/olpc_battery.c b/drivers/power/supply/olpc_battery.c
...
> @@ -626,6 +635,10 @@ static int olpc_battery_probe(struct platform_device *pdev)
> if (ecver > 0x44) {
> /* XO 1 or 1.5 with a new EC firmware. */
> data->new_proto = 1;
> + } else if (of_find_compatible_node(NULL, NULL, "olpc,xo1.75-ec")) {
This if/else blocks concerns me a bit, but I might just be missing some
context.
This tests both ecver as well as the OF compatible string, is this reliable? Do
we know that for all xo1.75-ec compatible nodes the ecver will be <= 0x44? Or,
is ecver undefined? If the latter, then perhaps this test should be performed
first?
if (of_find_compatible_node....x01.75-ec...)
...
else if (ecver > 0x44)
...
else
...
And what happens when ecver == 0x44? We test for > and < but not ==, <=,
or >= in this block
> + /* XO 1.75 */
> + data->new_proto = 1;
> + data->little_endian = 1;
> } else if (ecver < 0x44) {
> /*
> * We've seen a number of EC protocol changes; this driver
> --
> 2.19.1
>
>
--
Darren Hart
VMware Open Source Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Darren Hart <dvhart@infradead.org>
To: Lubomir Rintel <lkundrak@v3.sk>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, devel@driverdev.osuosl.org,
Eric Miao <eric.y.miao@gmail.com>,
James Cameron <quozl@laptop.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
linux-pm@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
linux-spi@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Daniel Mack <daniel@zonque.org>,
platform-driver-x86@vger.kernel.org,
Robert Jarzmik <robert.jarzmik@free.fr>,
Andy Shevchenko <andy@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 17/17] power: supply: olpc_battery: Add OLPC XO 1.75 support
Date: Sun, 2 Dec 2018 15:34:58 -0800 [thread overview]
Message-ID: <20181202233458.GE23087@wrath> (raw)
In-Reply-To: <20181116162403.49854-18-lkundrak@v3.sk>
On Fri, Nov 16, 2018 at 05:24:03PM +0100, Lubomir Rintel wrote:
> The battery and the protocol are essentially the same as OLPC XO 1.5,
> but the responses from the EC are LSB first.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Acked-by: Pavel Machek <pavel@ucw.cz>
>
> ---
> Changes since v1:
> - s/s16 ecword_to_cpu/u16 ecword_to_cpu/
> - s/u16 ec_byte/u16 ec_word/
>
> drivers/power/supply/olpc_battery.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/supply/olpc_battery.c b/drivers/power/supply/olpc_battery.c
...
> @@ -626,6 +635,10 @@ static int olpc_battery_probe(struct platform_device *pdev)
> if (ecver > 0x44) {
> /* XO 1 or 1.5 with a new EC firmware. */
> data->new_proto = 1;
> + } else if (of_find_compatible_node(NULL, NULL, "olpc,xo1.75-ec")) {
This if/else blocks concerns me a bit, but I might just be missing some
context.
This tests both ecver as well as the OF compatible string, is this reliable? Do
we know that for all xo1.75-ec compatible nodes the ecver will be <= 0x44? Or,
is ecver undefined? If the latter, then perhaps this test should be performed
first?
if (of_find_compatible_node....x01.75-ec...)
...
else if (ecver > 0x44)
...
else
...
And what happens when ecver == 0x44? We test for > and < but not ==, <=,
or >= in this block
> + /* XO 1.75 */
> + data->new_proto = 1;
> + data->little_endian = 1;
> } else if (ecver < 0x44) {
> /*
> * We've seen a number of EC protocol changes; this driver
> --
> 2.19.1
>
>
--
Darren Hart
VMware Open Source Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Darren Hart <dvhart@infradead.org>
To: Lubomir Rintel <lkundrak@v3.sk>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, devel@driverdev.osuosl.org,
Eric Miao <eric.y.miao@gmail.com>,
James Cameron <quozl@laptop.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
linux-pm@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
linux-spi@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Daniel Mack <daniel@zonque.org>,
platform-driver-x86@vger.kernel.org,
Robert Jarzmik <robert.jarzmik@free.fr>,
Andy Shevchenko <andy@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 17/17] power: supply: olpc_battery: Add OLPC XO 1.75 support
Date: Sun, 2 Dec 2018 15:34:58 -0800 [thread overview]
Message-ID: <20181202233458.GE23087@wrath> (raw)
In-Reply-To: <20181116162403.49854-18-lkundrak@v3.sk>
On Fri, Nov 16, 2018 at 05:24:03PM +0100, Lubomir Rintel wrote:
> The battery and the protocol are essentially the same as OLPC XO 1.5,
> but the responses from the EC are LSB first.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Acked-by: Pavel Machek <pavel@ucw.cz>
>
> ---
> Changes since v1:
> - s/s16 ecword_to_cpu/u16 ecword_to_cpu/
> - s/u16 ec_byte/u16 ec_word/
>
> drivers/power/supply/olpc_battery.c | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/supply/olpc_battery.c b/drivers/power/supply/olpc_battery.c
...
> @@ -626,6 +635,10 @@ static int olpc_battery_probe(struct platform_device *pdev)
> if (ecver > 0x44) {
> /* XO 1 or 1.5 with a new EC firmware. */
> data->new_proto = 1;
> + } else if (of_find_compatible_node(NULL, NULL, "olpc,xo1.75-ec")) {
This if/else blocks concerns me a bit, but I might just be missing some
context.
This tests both ecver as well as the OF compatible string, is this reliable? Do
we know that for all xo1.75-ec compatible nodes the ecver will be <= 0x44? Or,
is ecver undefined? If the latter, then perhaps this test should be performed
first?
if (of_find_compatible_node....x01.75-ec...)
...
else if (ecver > 0x44)
...
else
...
And what happens when ecver == 0x44? We test for > and < but not ==, <=,
or >= in this block
> + /* XO 1.75 */
> + data->new_proto = 1;
> + data->little_endian = 1;
> } else if (ecver < 0x44) {
> /*
> * We've seen a number of EC protocol changes; this driver
> --
> 2.19.1
>
>
--
Darren Hart
VMware Open Source Technology Center
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2018-12-02 23:35 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 16:23 [PATCH v2 0/17] Add support for OLPC XO 1.75 Embedded Controller Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 01/17] power: supply: olpc_battery: correct the temperature units Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-12-05 21:05 ` Sebastian Reichel
2018-12-05 21:05 ` Sebastian Reichel
2018-11-16 16:23 ` [PATCH v2 02/17] dt-bindings: olpc,xo1.75-ec: Add OLPC XO-1.75 EC bindings Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 02/17] dt-bindings: olpc, xo1.75-ec: " Lubomir Rintel
2018-11-17 16:03 ` [PATCH v2 02/17] dt-bindings: olpc,xo1.75-ec: " Rob Herring
2018-11-17 16:03 ` Rob Herring
2018-11-17 16:03 ` Rob Herring
2018-11-16 16:23 ` [PATCH v2 03/17] Platform: OLPC: Remove an unused include Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 04/17] Revert "platform/olpc: Make ec explicitly non-modular" Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 05/17] Platform: OLPC: Move OLPC config symbol out of x86 tree Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 06/17] Platform: OLPC: Add XO-1.75 EC driver Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-12-02 23:13 ` Darren Hart
2018-12-02 23:13 ` Darren Hart
2018-12-02 23:13 ` Darren Hart
2018-12-03 7:54 ` Andy Shevchenko
2018-12-03 7:54 ` Andy Shevchenko
2018-12-03 7:54 ` Andy Shevchenko
2018-12-03 7:54 ` Andy Shevchenko
2018-11-16 16:23 ` [PATCH v2 07/17] Platform: OLPC: Avoid a warning if the EC didn't register yet Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-12-02 23:15 ` Darren Hart
2018-12-02 23:15 ` Darren Hart
2018-12-02 23:15 ` Darren Hart
2018-11-16 16:23 ` [PATCH v2 08/17] Platform: OLPC: Move EC-specific functionality out from x86 Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 09/17] Platform: OLPC: Use BIT() and GENMASK() for event masks Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 10/17] Platform: OLPC: add a regulator for the DCON Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 11/17] dt-bindings: olpc_battery: Add XO-1.5 battery Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-12-05 20:53 ` Sebastian Reichel
2018-12-05 20:53 ` Sebastian Reichel
2018-11-16 16:23 ` [PATCH v2 12/17] x86, olpc: Use a correct version when making up a battery node Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-11-16 16:23 ` [PATCH v2 13/17] power: supply: olpc_battery: Use DT to get battery version Lubomir Rintel
2018-11-16 16:23 ` Lubomir Rintel
2018-12-02 23:24 ` Darren Hart
2018-12-02 23:24 ` Darren Hart
2018-12-02 23:24 ` Darren Hart
2018-12-05 20:54 ` Sebastian Reichel
2018-12-05 20:54 ` Sebastian Reichel
2019-01-07 18:25 ` Lubomir Rintel
2019-01-07 18:25 ` Lubomir Rintel
2019-01-07 18:25 ` Lubomir Rintel
2018-11-16 16:24 ` [PATCH v2 14/17] power: supply: olpc_battery: Move priv data to a struct Lubomir Rintel
2018-11-16 16:24 ` Lubomir Rintel
2018-12-05 20:57 ` Sebastian Reichel
2018-12-05 20:57 ` Sebastian Reichel
2018-12-05 20:57 ` Sebastian Reichel
2018-11-16 16:24 ` [PATCH v2 15/17] power: supply: olpc_battery: Use devm_power_supply_register() Lubomir Rintel
2018-11-16 16:24 ` Lubomir Rintel
2018-12-05 20:58 ` Sebastian Reichel
2018-12-05 20:58 ` Sebastian Reichel
2018-12-05 20:58 ` Sebastian Reichel
2018-11-16 16:24 ` [PATCH v2 16/17] power: supply: olpc_battery: Avoid using platform_info Lubomir Rintel
2018-11-16 16:24 ` Lubomir Rintel
2018-12-05 20:59 ` Sebastian Reichel
2018-12-05 20:59 ` Sebastian Reichel
2018-11-16 16:24 ` [PATCH v2 17/17] power: supply: olpc_battery: Add OLPC XO 1.75 support Lubomir Rintel
2018-11-16 16:24 ` Lubomir Rintel
2018-11-16 16:24 ` Lubomir Rintel
2018-12-02 23:34 ` Darren Hart [this message]
2018-12-02 23:34 ` Darren Hart
2018-12-02 23:34 ` Darren Hart
2019-01-07 18:02 ` Lubomir Rintel
2019-01-07 18:02 ` Lubomir Rintel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181202233458.GE23087@wrath \
--to=dvhart@infradead.org \
--cc=andy@infradead.org \
--cc=broonie@kernel.org \
--cc=daniel@zonque.org \
--cc=devel@driverdev.osuosl.org \
--cc=devicetree@vger.kernel.org \
--cc=eric.y.miao@gmail.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=haojian.zhuang@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=lkundrak@v3.sk \
--cc=mark.rutland@arm.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=quozl@laptop.org \
--cc=robert.jarzmik@free.fr \
--cc=robh+dt@kernel.org \
--cc=sre@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.