From: Hermes Zhang <chenhuiz@axis.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>,
Hermes Zhang <Hermes.Zhang@axis.com>
Cc: kernel@axis.com, "Pali Rohár" <pali@kernel.org>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Andrew Davis" <afd@ti.com>
Subject: Re: [PATCH v2] power: supply: bq27xxx: Divide the reg cache to each register
Date: Tue, 2 Apr 2024 10:13:36 +0800 [thread overview]
Message-ID: <379e258c-6ac1-ad6e-c0eb-bfdd86a2a3c6@axis.com> (raw)
In-Reply-To: <c4u27576oazfrlcp5avy3ect3i4jlsmdvi7nlun5qvez3ipti2@ue5jxbydmevs>
On 2024/4/1 21:15, Sebastian Reichel wrote:
> [+cc Andrew Davis]
>
> Hello Hermes,
>
> Sorry for the delay. This arrived too close to the 6.9 merge window.
> I had a look now and while the patch looks fine to me on a conceptual
> level, it did not apply. It looks like you used a pre-2024 kernel tree
> to generate the patch against. Please always use something recent base
> tree (and ideally use git's --base option to document the used
> parent commit).
Ack.
> Other than that I just applied a series from Andrew, which cleans up
> the register caching in bq27xxx and removed most registers from the
> cache. That's something I did not consider earlier, since I thought
> the cache was introduced to fix a different issue. But that was
> apparently sbs-battery and not bq27xxx.
>
> Anyways, there is only two registers left in the cache now. I'm fine
> with having a per-register cache for them, if that is still needed
> to further reduce I2C traffic on your device.
>
> And... re-reading your problem description, I wonder if we need to
> reintroduce the caching for all registers (on a per register basis)
> to avoid userspace being able to do a denial of service by quickly
> polling the battery information.
>
> Any thoughts?
Great. Now I think I can drop my patch since the current code is almost
same as we expected and still keep simple. Thanks for the latest info.
Best Regards,
Hermes
prev parent reply other threads:[~2024-04-02 2:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 10:09 [PATCH v2] power: supply: bq27xxx: Divide the reg cache to each register Hermes Zhang
2024-04-01 13:15 ` Sebastian Reichel
2024-04-01 13:57 ` Andrew Davis
2024-04-02 2:04 ` Hermes Zhang
2024-04-10 8:08 ` Sebastian Reichel
2024-04-02 2:13 ` Hermes Zhang [this message]
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=379e258c-6ac1-ad6e-c0eb-bfdd86a2a3c6@axis.com \
--to=chenhuiz@axis.com \
--cc=Hermes.Zhang@axis.com \
--cc=afd@ti.com \
--cc=kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pali@kernel.org \
--cc=sebastian.reichel@collabora.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox