From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DEC1486B82 for ; Wed, 19 Aug 2026 16:46:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787157966; cv=none; b=Vqkco2+kPg3VJfhYfN54zA8U8HMqOXnx4IPRZf4AJA6dS7a0w+PRYwBPapb0ukEX9ipog2kvIIduu+IykCzYtCMcKrGP3HqTC8sfXXmF6Vc7wCXMAP6H133n43vYbYTTKE8F69Hyt/R6w36XhBlwAz5MjUX77ZdCXP6RcMiJPo0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787157966; c=relaxed/simple; bh=PDhxOqT/y5939ng/CB3Fbzc40lOB6wazyR26umXP14I=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=l38Vj0Y7jEXc83gvKHR2FUQ6Y1jFftGep8XApJJk5nySSBEehNj0Hu8ESqAAiBtNOaKYlcCeflJOvslDPdbTiMUunirNdtF4YE60ZCKBMG1zJdd0yeey/f3JNIHpqw6GUuxYXJbdQ0YMGHJArqqHg9Af3n1UKTo2bCh/P97UlJc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=e603eVw8; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="e603eVw8" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-38ec1402b05so1130454a91.2 for ; Wed, 19 Aug 2026 09:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1787157964; x=1787762764; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=j2QFmIqsPMjSEaMKX7xQH3oClX6HCcn2Fx3TkiBSFCE=; b=e603eVw8XQAXUE4Ewqs5rjmaBCTRQAJFyDHGWTpI7TAsvNcKKNsIozEpPOIBlqzOHH MaHao3MTSFPuwoYm48UBbQ2EDIODfsF8lhEncGD8uC/jumfeJUMl9f8a3JmZzMflheF1 wSdhFpmW2HSTQxEixxOCCR5BMNzqa2TrZbm45Yq8vx7CVC7lqXILmJpcN9HYImAtSK0e SdAh1Y+ZYEdaXPlFPUvlOIUEp/knPprHQdnCqpUepTInvHad6ttLZcGo7p+bWH1zRa/T pLVZ5ncIeb2LZXJZDT6IoO+nhHZXmi4EChGfF0DOfRUi0VPdPpoEVTZCVnGY8XZYRqs9 bYZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787157964; x=1787762764; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=j2QFmIqsPMjSEaMKX7xQH3oClX6HCcn2Fx3TkiBSFCE=; b=aMWTtTLBA1RSTW0Cc3tC/P3pjoWA3gBcuy47ORpfQfcMIuw3Nq2gBrKCQ7kElYm8Gk xRmGKJtZNwr7DTrvzAhAi8BgmvfuV3VEqkkfbZwPwjxiKqcmfKoDO22AAHe9uqBfivo7 sqCLvalsa8+EQAiWLSKWp5TfJR3zRT0BSGJMgzSiWsgDjZzriMcWWh16r20clsQ/QqD1 ZB9EgtENdipY6LruH+bLx+zPUVx6TRR7Bj5vIbhNHfE04h5RXD4gIU4s86yBRJanhddf P+mGnejn2sVM8s0nLGn/UKa36iv7/dJ1vDzc3hVTy8LLp4mRcWJZFeuc9A5YFeyxKyfs uN7A== X-Forwarded-Encrypted: i=1; AHgh+RoZmVDFHQuTzTc5PrbbmLWunIgStNRw937u5D5zdexhm8SzfivuEruFMYjQ56EyHIAgJXFzW0jBJX/EFRw=@vger.kernel.org X-Gm-Message-State: AFuF++lfxWQSJbdPr7nPpx7K6f9b27vrD8X2evhrsSF9do2fSzyR4llW CXDFG9eQ8l5yDQOQPSw/3NIE7u66EQHMEQnZ1VQcSXgTciREbgFLq5NN/2IdSF/1PeA= X-Gm-Gg: AR+sD10r/TptMyO6XkfDxT3HSR/ItwTrQ7NPaJIwl7AKquFv3735UolHJsgNjrhXVdU 8KPIGrV9GawLUfr93qIUK4dsnBzXS65avESefkRdfOmphKOxT3EExtDDPMUFOCpimggXSjd9DCa wx7bu9U8CZKiO7C2mBdnOka6u9Cv5Y2htQ8Ot+cDXrwowdzcTtHJEp25oggB6s00X/2PJKxb1ga YvdD9jmC/TSniF1MCNLBhigs1QknW+h0M0ZxeQD0OyttanMN4QJ+iCYjgDFSDeQOLuPwkEcUm+H JuR5QJbVKnvXbHFGAtzLuPUCqILeWOFo3Dtb/grLdTQXeNCR00xAog4RX2KWXSlrHpQgBhgK5Sp rKQVqIWrvQrtyphshjPJNuOD4xFjTzI/3M0DBO1W/QDJ1no+QVggFjEnjeQZj/+qNeTe4h7fzZp go+sca7SMqi9TVrXFTlHJtLMB+NbEkXGqx4NinGGZLY5yNwdZLQepnV6XVFZcE X-Received: by 2002:a17:90b:4a4b:b0:38f:240d:b857 with SMTP id 98e67ed59e1d1-39580a4d03cmr10751457a91.2.1787157964497; Wed, 19 Aug 2026 09:46:04 -0700 (PDT) Received: from localhost ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3957f7c962csm3180844a91.0.2026.08.19.09.46.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2026 09:46:03 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 19 Aug 2026 09:46:01 -0700 Message-Id: Cc: "Michal Simek" , "Andi Shyti" , , , Subject: Re: [PATCH v3] i2c: xiic: restore non-managed runtime PM to fix clk WARN flood From: "Abdurrahman Hussain" To: "Andy Shevchenko" , "Abdurrahman Hussain" X-Mailer: aerc 0.21.0 References: <20260818-i2c-xiic-restore-runtime-pm-teardown-v3-1-5fd315b078e1@nexthop.ai> In-Reply-To: On Tue Aug 18, 2026 at 11:48 PM PDT, Andy Shevchenko wrote: > On Wed, Aug 19, 2026 at 09:45:41AM +0300, Andy Shevchenko wrote: >> On Tue, Aug 18, 2026 at 08:35:10AM -0700, Abdurrahman Hussain wrote: > > ... > >> > pm_runtime_set_autosuspend_delay(dev, XIIC_PM_TIMEOUT); >> > pm_runtime_use_autosuspend(dev); >> > - ret =3D devm_pm_runtime_set_active_enabled(dev); >> > - if (ret) >> > - return ret; >> > + /* >> > + * Enable runtime PM by hand: devm_pm_runtime_set_active_enabled() >> > + * tears down in an order that races the devm-enabled clock release = and >> > + * makes clk_core_disable() WARN (see xiic_i2c_remove()). >> > + */ >> > + pm_runtime_set_active(dev); >> > + pm_runtime_enable(dev); >> > =20 >> > /* SCL frequency configuration */ >> > i2c->input_clk =3D clk_get_rate(i2c->clk); >>=20 >> > ret =3D devm_request_threaded_irq(dev, irq, NULL, xiic_process, >> > IRQF_ONESHOT, pdev->name, i2c); >> > if (ret) >> > - return ret; >> > + goto err_pm_disable; >>=20 >> This might be problematic now. You need to unwind the IRQ request in non= -devm >> manner as well. Scenario is that IRQ comes exactly after PM is disabled >> in the error path. Is it a problem today? What about tomorrow (assuming = some >> new chips / code is added)? > > (To be clear: I'm talking about next call(s) that may fail, like xiic_rei= nit() > later in the probe.) > >> The rule of thumb is that, no devm_*() call should be followed by a goto= . Makes sense. I haven't hit it on our hardware yet, but I understand the concern: once the probe unwinds runtime PM by hand via goto, the devm-registered handler stays live across that teardown (and across any future failing step added after it). I'll switch to request_threaded_irq()/free_irq() and free it explicitly in the probe error path and in remove() for v4. Thanks for careful review! Best regards, Abdurrahman