linux-kernel - Re: [PATCH v2] power: supply: bq27xxx: Divide the reg cache to each register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <379e258c-6ac1-ad6e-c0eb-bfdd86a2a3c6@axis.com>
Date: Tue, 2 Apr 2024 10:13:36 +0800
From: Hermes Zhang <chenhuiz@...s.com>
To: Sebastian Reichel <sebastian.reichel@...labora.com>,
 Hermes Zhang <Hermes.Zhang@...s.com>
Cc: kernel@...s.com, Pali Rohár <pali@...nel.org>,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 Andrew Davis <afd@...com>
Subject: Re: [PATCH v2] power: supply: bq27xxx: Divide the reg cache to each
 register

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