mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "André Draszik" <andre.draszik@linaro.org>
To: Amit Sunil Dhamne <amitsd@google.com>,
	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 13:47:12 +0000	[thread overview]
Message-ID: <2869d309358f27652289c40810ca36b2ec155d1d.camel@linaro.org> (raw)
In-Reply-To: <255d7726-6758-43ed-b35f-db14726bcc9b@google.com>

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.

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?

Cheers,
Andre


  reply	other threads:[~2026-01-12 13:46 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 " 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 [this message]
2026-01-12 19:37           ` Amit Sunil Dhamne
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=2869d309358f27652289c40810ca36b2ec155d1d.camel@linaro.org \
    --to=andre.draszik@linaro.org \
    --cc=alim.akhtar@samsung.com \
    --cc=amitsd@google.com \
    --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

all inboxes | Powered by JetHome®