linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: 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 v2 0/7] syscore: Pass context data to callbacks
Date: Thu, 17 Jul 2025 14:11:41 +0200	[thread overview]
Message-ID: <2025071716-phoney-object-1648@gregkh> (raw)
In-Reply-To: <20250717103241.2806798-1-thierry.reding@gmail.com>

On Thu, Jul 17, 2025 at 12:32:34PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Hi,
> 
> Something that's been bugging me over the years is how some drivers have
> had to adopt file-scoped variables to pass data into something like the
> syscore operations. This is often harmless, but usually leads to drivers
> not being able to deal with multiple instances, or additional frameworks
> or data structures needing to be created to handle multiple instances.
> 
> This series proposes to "objectify" struct syscore_ops by passing a
> pointer to struct syscore_ops to the syscore callbacks. Implementations
> of these callbacks can then make use of container_of() to get access to
> contextual data that struct syscore_ops was embedded in. This elegantly
> avoids the need for file-scoped, singleton variables, by tying syscore
> to individual instances.
> 
> Patch 1 contains the bulk of these changes. It's fairly intrusive
> because it does the conversion of the function signature all in one
> patch. An alternative would've been to introduce new callbacks such that
> these changes could be staged in. However, the amount of changes here
> are not quite numerous enough to justify that, in my opinion, and
> syscore isn't very frequently used, so the risk of another user getting
> added while this is merged is rather small. All in all I think merging
> this in one go is the simplest way.

All at once is good, I like the idea, but:

> Patches 2-7 are conversions of some existing drivers to take advantage
> of this new parameter and tie the code to per-instance data.

That's great, but none of these conversions actually get rid of the
global structure, so what actually was helped here other than the churn
of this "potentially" allowing the global data variables from being
removed in the future?

So how does this actually help?

Also, small nit, make the function pointers const please :)

thanks,

greg k-h

  parent reply	other threads:[~2025-07-17 12:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-17 10:32 [PATCH v2 0/7] syscore: Pass context data to callbacks Thierry Reding
2025-07-17 10:32 ` [PATCH v2 1/7] " Thierry Reding
2025-07-17 10:32 ` [PATCH v2 2/7] MIPS: Embed syscore_ops in PCI context Thierry Reding
2025-07-17 10:32 ` [PATCH v2 3/7] bus: mvebu-mbus: Embed syscore_ops in mbus context Thierry Reding
2025-07-17 10:32 ` [PATCH v2 4/7] clk: ingenic: tcu: Embed syscore_ops in TCU context Thierry Reding
2025-07-17 10:32 ` [PATCH v2 5/7] clk: mvebu: Embed syscore_ops in clock context Thierry Reding
2025-07-17 10:32 ` [PATCH v2 6/7] irqchip/irq-imx-gpcv2: Embed syscore_ops in chip context Thierry Reding
2025-07-17 10:32 ` [PATCH v2 7/7] soc/tegra: pmc: Derive PMC context from syscore ops Thierry Reding
2025-07-17 12:11 ` Greg Kroah-Hartman [this message]
2025-07-18 13:49   ` [PATCH v2 0/7] syscore: Pass context data to callbacks Thierry Reding
2025-07-19  6:52     ` Greg Kroah-Hartman
2025-07-22 13:56       ` Thierry Reding
2025-07-22 14:08         ` Greg Kroah-Hartman
2025-07-23  9:01           ` Thierry Reding
2025-07-23 11:27             ` Rafael J. Wysocki

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=2025071716-phoney-object-1648@gregkh \
    --to=gregkh@linuxfoundation.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=thierry.reding@gmail.com \
    --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 NNTP newsgroup(s).