All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Julien <julien82453@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-integrity@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH v2] ACPI: scan: Do not combine resources that overlap completely
Date: Tue, 1 Sep 2026 16:12:55 +0300	[thread overview]
Message-ID: <apbPV_tsyYVzvEVt@kernel.org> (raw)
In-Reply-To: <CAJOGg3x4nMtSJeiLa2nsBFFuG4GRyvj7MbErcdOgxyuXCkr_og@mail.gmail.com>

On Sat, Aug 29, 2026 at 12:43:30AM +0200, Julien wrote:
> On Thu, Aug 20, 2026 at 9:11 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> >
> > Commit f234fdaae1ca ("ACPI: scan: Avoid registering platform devices
> > with resource overlaps") attempted to avoid platform device registration
> > errors due to overlaps of resources of the same type returned by the
> > same _CRS object in the ACPI tables.  It did that by combining two or
> > more overlapping resources into one, but it went too far and also
> > caused resources that overlap completely to be combined which broke
> > the arm-cmn driver that expects two MMIO resources to be present for
> > each device it binds to and it expects those two resources to overlap
> > completely.
> >
> > Address this issue by adding checks for completely overlapping
> > resources to acpi_platform_adjust_resources() and add a comment
> > explaining what is done there.
> >
> > Fixes: f234fdaae1ca ("ACPI: scan: Avoid registering platform devices with resource overlaps")
> > Reported-by: Nathan Chancellor <nathan@kernel.org>
> > Tested-by: Nathan Chancellor <nathan@kernel.org>
> > Closes: https://lore.kernel.org/linux-acpi/20260819003752.GA3063251@ax162/
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >
> > v1 -> v2:
> >    * It is better to check for complete overlaps both ways as suggested
> >      by Sashiko.
> >
> > @Julien: I would appreciate testing this on the machine that needed
> > commit f234fdaae1ca.
> >
> > ---
> >  drivers/acpi/acpi_platform.c |    8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/acpi/acpi_platform.c
> > +++ b/drivers/acpi/acpi_platform.c
> > @@ -85,7 +85,13 @@ static unsigned int acpi_platform_adjust
> >         for (i = 0; i < count; ) {
> >                 struct resource *res = &resources[i];
> >
> > -               if (resource_type(new_res) != resource_type(res) ||
> > +               /*
> > +                * Look for overlaps of resources of the same type that would
> > +                * cause resource insertion to fail down the road.
> > +                */
> > +               if (__resource_contains_unbound(res, new_res) ||
> > +                   __resource_contains_unbound(new_res, res) ||
> > +                   resource_type(new_res) != resource_type(res) ||
> >                     !resource_union(new_res, res, new_res)) {
> >                         i++;
> >                         continue;
> >
> >
> >
> 
> I have tested this on commit 1b78070aaef6. It seems the patch is
> already included in it.
> 
> TPM device still works. Here are the logs.
> acpi MSFT0101:00: [mem 0xfed40000-0xfed4103f] expanded due to overlap
> tpm_crb_acpi MSFT0101:00: [Firmware Bug]: Bad ACPI memory layout
> 
> If in the future if I need to make tests again, should I do them on
> the Linus Torvalds' branch?

What was the hardware where this happens?

Sorry, if I've ignored it (if it was mentioned previously).

BR, Jarkko

  reply	other threads:[~2026-09-01 13:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 19:11 [PATCH v2] ACPI: scan: Do not combine resources that overlap completely Rafael J. Wysocki
2026-08-25 14:06 ` Jarkko Sakkinen
2026-08-28 22:43 ` Julien
2026-09-01 13:12   ` Jarkko Sakkinen [this message]
2026-09-06 18:31     ` Julien

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=apbPV_tsyYVzvEVt@kernel.org \
    --to=jarkko@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=julien82453@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=nathan@kernel.org \
    --cc=rafael@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.