linux-kernel - Re: [PATCH] power: supply: bq27xxx: Introduce parameter to config cache regs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <op5ovg3cv4raqy4zmol7wfy7hm72ptgxleh2ykoyg5qvnbhfcl@pxfzkij5xkkw>
Date: Sun, 25 Feb 2024 22:10:30 +0100
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Hermes Zhang <chenhuiz@...s.com>
Cc: Hermes Zhang <Hermes.Zhang@...s.com>, kernel@...s.com, 
	Pali Rohár <pali@...nel.org>, linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] power: supply: bq27xxx: Introduce parameter to config
 cache regs

Hi,

On Fri, Feb 23, 2024 at 04:40:18PM +0800, Hermes Zhang wrote:
> On 2024/2/22 7:03, Sebastian Reichel wrote:
> > On Mon, Feb 19, 2024 at 06:05:40PM +0800, Hermes Zhang wrote:
> > > Since all of the regs in the bq27xxx_reg_cache are now cached, a simple
> > > property read (such as temperature) will need nine I2C transmissions.
> > > Introduce a new module parameter to enable the reg cache to be configured,
> > > which decrease the amount of unnecessary I2C transmission and preventing
> > > the error -16 (EBUSY) happen when working on an I2C bus that is shared by
> > > many devices.
> > So the problem is not the caching, but the grouping. So instead
> > of adding this hack, please change the code to do the caching
> > per register. That way you can just keep the caching enabled and
> > don't need any custom module parameters.
> 
> Thanks for the reply. Yes, the key is the grouping. So do you suggest to
> drop the bq27xxx_reg_cache struct totally and handle the cache for each
> register in e.g. bq27xxx_battery_get_property()? Then it will require an
> extra time info for each register, will that be a big cost? Or am I
> misunderstanding?

Yes, this requires time info for each cached register. I don't think
the added memory is a big deal. There usually is only a single
battery and we are caching 10 timestamps. So that's 80 bytes.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)