linux-kernel - Re: [PATCH] mfd: axp20x: Add supplied-from property to axp288_fuel

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]

Date:   Sun, 18 Jul 2021 11:51:07 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Lee Jones <lee.jones@...aro.org>, "C++ / GCC" <cpp@....lt>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mfd: axp20x: Add supplied-from property to
 axp288_fuel_gauge cell

On Sun, Jul 18, 2021 at 12:25 AM Hans de Goede <hdegoede@...hat.com> wrote:
>
> The power-supply framework has the notion of one power-supply device
> being supplied by another. A typical example of this is a charger
> charging a battery.
>
> A tablet getting plugged in to charge (or plugged out) only results in
> events seen by the axp288_charger device / MFD cell. Which means that
> a change udev-event only gets send for the charger power-supply class
> device, not for the battery (the axp288_fuel_gauge device).
>
> The axp288_fuel_gauge does have an external_power_change'd callback
> which will generate a change udev-event when called. But before this
> commit this never got called because the power-supply core only calls
> this when a power-supply class device's supplier changes and the
> supplier link from axp288_charger to axp288_fuel_gauge was missing.
>
> Add a "supplied-from" property to axp288_fuel_gauge cell, pointing
> to the "axp288_charger" power-supply class device, so that the
> axp288_fuel_gauge's external_power_change'd callback gets called on
> axp288_charger state changes.
>
> Signed-off-by: Hans de Goede <hdegoede@...hat.com>

Makes sense to me.

Reviewed-by: Chen-Yu Tsai <wens@...e.org>