From: Thierry Reding <thierry.reding@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
x86@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linux-mips@vger.kernel.org,
loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
linux-sh@vger.kernel.org, linux-pci@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/7] clk: ingenic: tcu: Use contextual data instead of global variable
Date: Thu, 30 Oct 2025 13:28:04 +0100 [thread overview]
Message-ID: <5psq67p7ozmfz6mbi626q2uixqtbtfpejkhud5fv6wqr66xasz@ksiokkf5qsgr> (raw)
In-Reply-To: <20251029175647.GA1572736@bhelgaas>
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
On Wed, Oct 29, 2025 at 12:56:47PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 29, 2025 at 05:33:33PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Pass the driver-specific data via the syscore struct and use it in the
> > syscore ops.
>
> Some of these things in drivers/clk/ are also platform_device drivers
> (though not this one) and use generic power management, e.g.,
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/qcom/q6sstop-qcs404.c?id=v6.17#n209
>
> I have no idea if that's desirable or practical here, but using the
> platform_device model instead of syscore could have advantages in
> terms of modeling device dependencies and ordering.
Similar to the MIPS/Alchemy PCI driver, although there's no git log
reference in this case, I suspect this was not in driver PM on purpose.
The pattern I've seen quite often is very low-level device driver code
doing this using syscore_ops because they run very late/early during
suspend/resume, respectively, so the driver PM callbacks often aren't
sufficient.
In recent years, some of the issues have been alleviated by things such
as device links, so a conversion may work now.
However, often these are also exotic and/or old devices that are
difficult to find testers for, so I've been trying to keep the changes
in this series as minimal as possible, so that we can be reasonably sure
things will continue to work just by reviewing the code.
The most important bit in the series is patch 1, which lays the
groundwork for avoiding these global variables for new code. Also, in
particular I have a concrete case where the global variable approach
doesn't work because an IP block that used to be a guaranteed singleton
now no longer is.
I have looked at various drivers that I ended up not converting because
they use a global variable not only for syscore but also for other
things and fixing that up would've been way out of scope of this series.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-10-30 12:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 16:33 [PATCH v3 0/7] syscore: Pass context data to callbacks Thierry Reding
2025-10-29 16:33 ` [PATCH v3 1/7] " Thierry Reding
2025-11-03 16:18 ` Rafael J. Wysocki
2025-11-05 16:52 ` Thierry Reding
2025-11-13 18:32 ` Thierry Reding
2025-11-13 19:18 ` Rafael J. Wysocki
2025-10-29 16:33 ` [PATCH v3 2/7] MIPS: PCI: Use contextual data instead of global variable Thierry Reding
2025-10-29 17:46 ` Bjorn Helgaas
2025-10-30 12:16 ` Thierry Reding
2025-10-30 15:31 ` Bjorn Helgaas
2025-10-30 20:10 ` Maciej W. Rozycki
2025-10-29 16:33 ` [PATCH v3 3/7] bus: mvebu-mbus: " Thierry Reding
2025-10-29 16:33 ` [PATCH v3 4/7] clk: ingenic: tcu: " Thierry Reding
2025-10-29 17:56 ` Bjorn Helgaas
2025-10-30 12:28 ` Thierry Reding [this message]
2025-10-29 16:33 ` [PATCH v3 5/7] clk: mvebu: " Thierry Reding
2025-10-29 16:33 ` [PATCH v3 6/7] irqchip/irq-imx-gpcv2: " Thierry Reding
2025-10-29 16:33 ` [PATCH v3 7/7] soc/tegra: pmc: " Thierry Reding
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=5psq67p7ozmfz6mbi626q2uixqtbtfpejkhud5fv6wqr66xasz@ksiokkf5qsgr \
--to=thierry.reding@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=rafael@kernel.org \
--cc=x86@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).