From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Andreas Kemnade <andreas@kemnade.info>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Matti Vaittinen" <matti.vaittinen@linux.dev>,
"Matti Vaittinen" <matti.vaittinen@fi.rohmeurope.com>,
"Sebastian Reichel" <sre@kernel.org>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Kalle Niemi" <kaleposti@gmail.com>,
"Topi Sonkajärvi" <sonkajarvi@hotmail.com>,
"Mikko Mutanen" <mikko.mutanen@fi.rohmeurope.com>,
"Markus Laine" <markus.laine@fi.rohmeurope.com>
Subject: Re: [PATCH 2/5] power: supply: bd71828: Fix current direction
Date: Wed, 12 Aug 2026 12:40:47 +0300 [thread overview]
Message-ID: <1b08ee53-5adf-4de1-afdc-4419797142d8@gmail.com> (raw)
In-Reply-To: <20260812102536.63579b89@kemnade.info>
On 12/08/2026 11:25, Andreas Kemnade wrote:
> On Wed, 12 Aug 2026 11:17:36 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
>> On Wed, Aug 12, 2026 at 10:10:50AM +0200, Andreas Kemnade wrote:
>>> On Mon, 10 Aug 2026 13:09:07 +0300
>>> Matti Vaittinen <matti.vaittinen@linux.dev> wrote:
>>
>> ...
>>
>>> That code is complicated. What about a generic 16bit non_2complemented sign
>>> to 2-complemented sign function/macro. Such would have prevented the error
>>> in the first places. So &vals[i] = signbit_to_2complement(be16_to_cpu(tmp_curr), 15) * pwr->curr_factor
>>
>> Do you mean existing sign_extend32() from bitops.h?
>>
>
> I don't think it does what is needed. Here we have
>
> 0000 0000 0000 0001 -> 1
> Usually we have
>
> 1111 1111 1111 1111 -> -1
>
> but here
>
> 1000 0000 0000 0001 -> -1
>
> If I do understand things correctly. I not find something useful
> in bitops.h.
>
Thanks for the review and testing Andreas! We share the same
(mis?)understanding. ;)
I am not sure this is so widely used it'd warrant a generic macro. I am
afraid that if someone encountered similar design, he would not expect a
generic macro to exist. My gut feeling is that this is too marginal to
be widely useful. I am not against it though, if someone wants to
implement it.
What comes to complexity - I agree. The code is messy, but mostly
because of "clever hacks" done so values are in arrays indexed by loop.
I, however, would like to see a minimal backportable fix, and
potentially, larger clean-up which can then go in as a feature, without
any rush.
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
next prev parent reply other threads:[~2026-08-12 9:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 10:08 [PATCH 0/5] ROHM bd71828 power-supply fixes Matti Vaittinen
2026-08-10 10:08 ` [PATCH 1/5] power: supply: bd71815: Fix temperature reading Matti Vaittinen
2026-08-10 10:09 ` [PATCH 2/5] power: supply: bd71828: Fix current direction Matti Vaittinen
2026-08-10 17:18 ` Andy Shevchenko
2026-08-11 8:46 ` Matti Vaittinen
2026-08-11 10:04 ` Andy Shevchenko
2026-08-12 8:10 ` Andreas Kemnade
2026-08-12 8:17 ` Andy Shevchenko
2026-08-12 8:25 ` Andreas Kemnade
2026-08-12 9:30 ` Andy Shevchenko
2026-08-12 9:37 ` Matti Vaittinen
2026-08-12 9:55 ` Andy Shevchenko
2026-08-12 9:40 ` Matti Vaittinen [this message]
2026-08-12 11:32 ` Andreas Kemnade
2026-08-10 10:09 ` [PATCH 3/5] power: supply: bd71828: Drop duplicate power-supply property Matti Vaittinen
2026-08-10 18:01 ` Andy Shevchenko
2026-08-10 10:09 ` [PATCH 4/5] power: supply: bd71828: Do not hide errors Matti Vaittinen
2026-08-10 10:10 ` [PATCH 5/5] power: supply: bd99954: Drop bad register fields Matti Vaittinen
2026-08-10 18:03 ` Andy Shevchenko
2026-08-12 6:59 ` [PATCH 0/5] ROHM bd71828 power-supply fixes Kalle Niemi
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=1b08ee53-5adf-4de1-afdc-4419797142d8@gmail.com \
--to=mazziesaccount@gmail.com \
--cc=andreas@kemnade.info \
--cc=andriy.shevchenko@linux.intel.com \
--cc=kaleposti@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=markus.laine@fi.rohmeurope.com \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=matti.vaittinen@linux.dev \
--cc=mikko.mutanen@fi.rohmeurope.com \
--cc=sonkajarvi@hotmail.com \
--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.