public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-acpi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 1/1] x86: Use resource_set_{range,size}() helpers
Date: Wed, 16 Apr 2025 18:25:32 +0300	[thread overview]
Message-ID: <Z__L7DHHvMdmH4bk@smile.fi.intel.com> (raw)
In-Reply-To: <7f0d376c-2d03-8e09-5d85-e53b0bce0cc5@linux.intel.com>

On Wed, Apr 16, 2025 at 03:18:56PM +0300, Ilpo Järvinen wrote:
> On Wed, 16 Apr 2025, Andy Shevchenko wrote:
> > On Wed, Apr 16, 2025 at 02:53:51PM +0300, Ilpo Järvinen wrote:
> > > On Wed, 16 Apr 2025, Andy Shevchenko wrote:
> > > > On Wed, Apr 16, 2025 at 01:13:18PM +0300, Ilpo Järvinen wrote:

...

> > > > > +			resource_set_range(res, 0xC0000, SZ_128K);
> > > > >  			res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
> > > > >  				     IORESOURCE_PCI_FIXED;
> > > > 
> > > > I'm wondering why not DEFINE_RES_MEM() in such cases?
> > > 
> > > I guess you meant DEFINE_RES() as that seems to allow giving custom flags.
> > > However, DEFINE_RES*() will overwrite ->name which seems something that 
> > > ought to not be done here.
> > 
> > Okay, I haven't checked the initial state of name field here, so then
> > DEFINE_RES_MEM_NAMED()?  Or don't we have one?
> 
> There's pre-existing res->name on it and your suggestion would have 
> resulted in overwriting it with NULL. res->name seems to be filled earlier 
> by PCI probe code.

Okay, then the resource_*() may make more sense, indeed.

> > In any case I would rather see a one assignment for these cases than something
> > hidden behind proposed conversions.
> 
> TBH, these DEFINE_RES*() helpers are doing hidden things such as 
> blantantly overwriting ->name which I only realized after I had already 
> converted to it as per your suggestion.

They are specifically named in  capital letters, so main use is in static
assignments, but they are made compound literals, so it's possible to
initialise the on-stack or on-heap at run-time with this be kept in mind.
That's why there is nothing hidden, it implies that the struct is fully
assigned (with the provided fields and some defaults).

> And yes, it is possible to pass the pre-existing res->name to 
> DEFINE_RES_NAMED() if that what you insist, though it seems doing it for 
> the sake of DEFINE_RES*() interface rather than this code wanting to 
> really define the resource from scratch.
> 
> Given the hidden overwriting, please be careful on suggesting 
> DEFINE_RES*() conversions as it's not as trivial as it seems.

Yeah, seems not everybody aware of the difference with
foo_init_something() vs. FOO_INIT_SOMETHING() :-)

> > > I found one other case from the same file though which is truly defines
> > > a resource from scratch.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2025-04-16 15:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16 10:13 [PATCH 1/1] x86: Use resource_set_{range,size}() helpers Ilpo Järvinen
2025-04-16 10:22 ` Andy Shevchenko
2025-04-16 10:23   ` Andy Shevchenko
2025-04-16 11:53   ` Ilpo Järvinen
2025-04-16 12:03     ` Andy Shevchenko
2025-04-16 12:18       ` Ilpo Järvinen
2025-04-16 15:25         ` Andy Shevchenko [this message]
2025-04-18  7:40     ` Ingo Molnar
2025-04-18 15:15       ` Ilpo Järvinen
2025-04-19 14:57         ` Ingo Molnar
2025-04-16 15:05 ` 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=Z__L7DHHvMdmH4bk@smile.fi.intel.com \
    --to=andy@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --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