mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Thompson <danielt@kernel.org>
To: david@ixit.cz
Cc: "Lee Jones" <lee@kernel.org>, "Jingoo Han" <jingoohan1@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	"Kiran Gunda" <quic_kgunda@quicinc.com>,
	"Marco Mattiolo" <marco.mattiolo@hotmail.it>,
	"Barnabás Czémán" <barnabas.czeman@mainlining.org>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	phone-devel@vger.kernel.org,
	"Konrad Dybcio" <konrad.dybcio@oss.qualcomm.com>,
	"Joel Selvaraj" <foss@joelselvaraj.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v4 3/4] backlight: qcom-wled: Fix unbalanced OVP IRQ enable at probe
Date: Tue, 6 Oct 2026 11:07:16 +0100	[thread overview]
Message-ID: <asTIVMnldeyS4T9p@aspen.lan> (raw)
In-Reply-To: <20260921-qcom-wled-backlight-v4-3-bab8c7ef73cb@ixit.cz>

On Mon, Sep 21, 2026 at 12:46:24PM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> wled_configure_ovp_irq() derives the initial state of the OVP interrupt
> from the hardware:
>
>         /* Keep OVP irq disabled until module is enabled */
>         if (!(val & WLED3_CTRL_REG_MOD_EN_MASK))
>                 disable_irq(wled->ovp_irq);
>
> but wled->brightness, which is what the rest of the driver uses to tell
> whether the module is on, is left at zero.
>
> On boards where the bootloader hands the kernel a lit backlight the two
> disagree. MOD_EN is already set, so the interrupt is left enabled, while
> wled_update_status() still believes the backlight is off and takes
>
>         if (!!brightness != !!wled->brightness)
>                 rc = wled_module_enable(wled, !!brightness);
>
> on the first backlight update. wled_module_enable() then schedules
> wled_ovp_work(), which calls enable_irq() on the already enabled
> interrupt:
>
>   Unbalanced enable for IRQ 176
>   WARNING: CPU: 0 PID: 160 at kernel/irq/manage.c:774 __enable_irq+0x50/0x80
>   Hardware name: Xiaomi Pocophone F1 (DT)
>   Workqueue: events wled_ovp_work
>   Call trace:
>    __enable_irq+0x50/0x80
>    enable_irq+0x48/0xa0
>    wled_ovp_work+0x18/0x24
>    process_one_work+0x1d0/0x350
>    worker_thread+0x13c/0x460
>    kthread+0x110/0x114
>    ret_from_fork+0x10/0x20
>
> The bootloader is not the only way to get there. The readback runs after
> wledN_setup(), and wled4_setup() sets MOD_EN itself on the path where the
> sink configuration does not already match, as does the tail of
> wled_auto_string_detection(), which all three setup paths can reach
> through wled_auto_detection_at_init(). A cold-booted board with a dark
> panel can therefore reach the same disagreement.
>
> Move the MOD_EN readback into wled_probe() and use it to seed
> wled->brightness, so the driver starts out agreeing with the hardware,
> and key the OVP interrupt off wled->brightness instead. The first
> backlight update then only reprograms the brightness registers and
> leaves both the module and the interrupt alone. The OVP interrupt also
> stays armed from probe whenever the module is already enabled, rather
> than being disabled at probe and only enabled once something writes
> brightness.
>
> Note that a backlight update requesting brightness 0 before any non-zero
> one now really does turn the module off wherever MOD_EN was already set,
> where before it was silently ignored.
>
> wled->brightness is seeded with default-brightness rather than the level
> the bootloader actually programmed, so the first update can still step
> the brightness. Reading that level back is version specific and is done
> in a follow-up, to keep this fix small enough to backport.
>
> Assisted-by: LLM
> Fixes: 8663c188beea ("backlight: qcom-wled: Add auto string detection logic")
> Cc: stable@vger.kernel.org
> Signed-off-by: David Heidelberg <david@ixit.cz>

Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>


Daniel.

  reply	other threads:[~2026-10-06 10:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 10:46 [PATCH v4 0/4] backlight: qcom-wled: Fix OVP IRQ imbalance and start from the hardware state David Heidelberg via B4 Relay
2026-09-21 10:46 ` [PATCH v4 1/4] backlight: qcom-wled: Fix NULL pointer dereference in wled_remove() David Heidelberg via B4 Relay
2026-09-21 11:06   ` Konrad Dybcio
2026-10-06  9:59   ` Daniel Thompson
2026-09-21 10:46 ` [PATCH v4 2/4] backlight: qcom-wled: Fix WLED3 brightness register stride David Heidelberg via B4 Relay
2026-09-21 11:08   ` Konrad Dybcio
2026-09-21 11:11     ` David Heidelberg
2026-10-06 10:03   ` Daniel Thompson
2026-09-21 10:46 ` [PATCH v4 3/4] backlight: qcom-wled: Fix unbalanced OVP IRQ enable at probe David Heidelberg via B4 Relay
2026-10-06 10:07   ` Daniel Thompson [this message]
2026-09-21 10:46 ` [PATCH v4 4/4] backlight: qcom-wled: Read back the programmed brightness " David Heidelberg via B4 Relay
2026-10-06 10:11   ` Daniel Thompson

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=asTIVMnldeyS4T9p@aspen.lan \
    --to=danielt@kernel.org \
    --cc=barnabas.czeman@mainlining.org \
    --cc=david@ixit.cz \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=foss@joelselvaraj.com \
    --cc=jingoohan1@gmail.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=lee@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marco.mattiolo@hotmail.it \
    --cc=phone-devel@vger.kernel.org \
    --cc=quic_kgunda@quicinc.com \
    --cc=stable@vger.kernel.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®