From: Amit Sunil Dhamne <amitsd@google.com>
To: "André Draszik" <andre.draszik@linaro.org>,
"Sebastian Reichel" <sre@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Lee Jones" <lee@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Badhri Jagan Sridharan" <badhri@google.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Peter Griffin" <peter.griffin@linaro.org>,
"Tudor Ambarus" <tudor.ambarus@linaro.org>,
"Alim Akhtar" <alim.akhtar@samsung.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
RD Babiera <rdbabiera@google.com>, Kyle Tso <kyletso@google.com>
Subject: Re: [PATCH v3 4/5] power: supply: max77759: add charger driver
Date: Mon, 12 Jan 2026 11:37:40 -0800 [thread overview]
Message-ID: <bb9b9afa-0bfa-428e-9372-549d9ba8603c@google.com> (raw)
In-Reply-To: <2869d309358f27652289c40810ca36b2ec155d1d.camel@linaro.org>
Hi Andre',
On 1/12/26 5:47 AM, André Draszik wrote:
> Hi Amit,
>
> On Tue, 2026-01-06 at 17:14 -0800, Amit Sunil Dhamne wrote:
>> On 1/6/26 3:41 PM, Amit Sunil Dhamne wrote:
>>> Hi Andre',
>>>
>>> On 1/5/26 9:32 AM, André Draszik wrote:
>>>> Hi Amit,
>>>>
>>>> I haven't done a full review, but a few things caught my eye.
>>>>
>>>> On Sat, 2025-12-27 at 00:04 +0000, Amit Sunil Dhamne via B4 Relay wrote:
>>>>> diff --git a/drivers/power/supply/Makefile
>>>>> b/drivers/power/supply/Makefile
>>>>> index 4b79d5abc49a..6af905875ad5 100644
>>>>> --- a/drivers/power/supply/Makefile
>>>>> +++ b/drivers/power/supply/Makefile
>>>>> [...]
>>>>> +
>>>>> +static irqreturn_t irq_handler(int irq, void *data)
>>>>> +{
>>>>> + struct max77759_charger *chg = data;
>>>>> + struct device *dev = chg->dev;
>>>>> + u32 chgint_ok;
>>>>> + int i;
>>>>> +
>>>>> + regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_INT_OK,
>>>>> &chgint_ok);
>>>> You might want to check the return value and return IRQ_NONE if it
>>>> didn't
>>>> work?
>>>>
>>>>> +
>>>>> + for (i = 0; i < ARRAY_SIZE(irqs); i++) {
>>>>> + if (irqs[i] == irq)
>>>>> + break;
>>>>> + }
>>>>> +
>>>>> + switch (i) {
>>>>> + case AICL:
>>>>> + dev_dbg(dev, "AICL mode: %s",
>>>>> + str_no_yes(chgint_ok & MAX77759_CHGR_REG_CHG_INT_AICL));
>>>>> + break;
>>>>> + case CHGIN:
>>>>> + dev_dbg(dev, "CHGIN input valid: %s",
>>>>> + str_yes_no(chgint_ok & MAX77759_CHGR_REG_CHG_INT_CHGIN));
>>>>> + break;
>>>>> + case CHG:
>>>>> + dev_dbg(dev, "CHG status okay/off: %s",
>>>>> + str_yes_no(chgint_ok & MAX77759_CHGR_REG_CHG_INT_CHG));
>>>>> + break;
>>>>> + case INLIM:
>>>>> + dev_dbg(dev, "Current Limit reached: %s",
>>>>> + str_no_yes(chgint_ok & MAX77759_CHGR_REG_CHG_INT_INLIM));
>>>>> + break;
>>>>> + case BAT_OILO:
>>>>> + dev_dbg(dev, "Battery over-current threshold crossed");
>>>>> + break;
>>>>> + case CHG_STA_CC:
>>>>> + dev_dbg(dev, "Charger reached CC stage");
>>>>> + break;
>>>>> + case CHG_STA_CV:
>>>>> + dev_dbg(dev, "Charger reached CV stage");
>>>>> + break;
>>>>> + case CHG_STA_TO:
>>>>> + dev_dbg(dev, "Charger reached TO stage");
>>>>> + break;
>>>>> + case CHG_STA_DONE:
>>>>> + dev_dbg(dev, "Charger reached TO stage");
>>>>> + break;
>>>> Are the above debug messages really all needed?
>> I forgot to respond to this comment in my previous email.
>>
>> I think we can keep AICL, BAT_OILO, INLIM. They're either special
>> conditions (AICL) or faulty conditions (like BAT_OILO) and we can in
>> fact keep them at dev_info level. Rest can be removed and a
>> power_supply_changed() is sufficient.
>>
>> Let me know what you think?
> I don't think dev_info() in an interrupt handler is appropriate. At
> least it should be ratelimited.
>
> If it's something special / unexpected that needs attention, having
> a dev_dbg() message only will usually not be visible to anybody.
I agree. I can change the prints to dev_info_ratelimited for the stuff
we care about.
>
> Also will the call to power_supply_changed() down below handle the
> special conditions (e.g. convey to upper levels)? If not, can it be
> made to do so?
Yes it does, as I can see a call to kobject_uevent() inside
power_supply_changed_work(). Also, power_supply_changed() also notifies
other subsystems that have registered their notifiers downstream of this
power_supply object. So I believe we're good there.
If all the above sounds good, I will proceed with sending the next
revision including the fixes :).
BR,
Amit
>
> Cheers,
> Andre
>
next prev parent reply other threads:[~2026-01-12 19:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-27 0:04 [PATCH v3 0/5] Introduce MAX77759 charger driver Amit Sunil Dhamne via B4 Relay
2025-12-27 0:04 ` [PATCH v3 1/5] dt-bindings: mfd: maxim,max77759: reference power-supply schema and add regulator property Amit Sunil Dhamne via B4 Relay
2025-12-29 8:50 ` Krzysztof Kozlowski
2026-01-05 16:35 ` André Draszik
2025-12-27 0:04 ` [PATCH v3 2/5] dt-bindings: usb: maxim,max33359: Add supply property for vbus Amit Sunil Dhamne via B4 Relay
2025-12-27 0:04 ` [PATCH v3 3/5] mfd: max77759: add register bitmasks and modify irq configs for charger Amit Sunil Dhamne via B4 Relay
2026-01-05 16:45 ` André Draszik
2026-01-05 19:58 ` Amit Sunil Dhamne
2025-12-27 0:04 ` [PATCH v3 4/5] power: supply: max77759: add charger driver Amit Sunil Dhamne via B4 Relay
2026-01-05 17:32 ` André Draszik
2026-01-06 23:41 ` Amit Sunil Dhamne
2026-01-07 1:14 ` Amit Sunil Dhamne
2026-01-12 13:47 ` André Draszik
2026-01-12 19:37 ` Amit Sunil Dhamne [this message]
2026-01-13 10:02 ` André Draszik
2026-01-14 0:47 ` Amit Sunil Dhamne
2026-01-14 10:20 ` André Draszik
2026-01-15 2:52 ` Amit Sunil Dhamne
2025-12-27 0:04 ` [PATCH v3 5/5] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode Amit Sunil Dhamne via B4 Relay
2026-01-05 16:10 ` Heikki Krogerus
2026-01-05 16:47 ` André Draszik
2026-01-09 13:14 ` Heikki Krogerus
2026-01-10 2:16 ` Amit Sunil Dhamne
2026-01-12 13:20 ` Heikki Krogerus
2026-01-15 2:58 ` Amit Sunil Dhamne
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=bb9b9afa-0bfa-428e-9372-549d9ba8603c@google.com \
--to=amitsd@google.com \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=badhri@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=krzk+dt@kernel.org \
--cc=kyletso@google.com \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=rdbabiera@google.com \
--cc=robh@kernel.org \
--cc=sre@kernel.org \
--cc=tudor.ambarus@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox