linux-kernel - Re: [PATCH] perf/arm-cmn: don't claim resource during ioremap() for CMN700 with ACPI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cji4nqc6etzggg7hannvdg5jos4dr4mhujetviuhs3sl36bh6g@xde5izlywsei>
Date: Tue, 18 Feb 2025 18:35:29 +0800
From: YinFengwei <fengwei_yin@...ux.alibaba.com>
To: Robin Murphy <robin.murphy@....com>
Cc: will@...nel.org, mark.rutland@....com, 
	linux-arm-kernel@...ts.infradead.org, linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	jie.li.linux@...ux.alibaba.com
Subject: Re: [PATCH] perf/arm-cmn: don't claim resource during ioremap() for
 CMN700 with ACPI

On Tue, Feb 18, 2025 at 10:31:42AM +0800, Robin Murphy wrote:
> On 2025-02-18 1:21 am, Yin Fengwei wrote:
> > Currently, arm-cmn PMU driver assumes ACPI claim resource
> > for CMN600 + ACPI. But with CMN700 + ACPI, the device probe
> > failed because of resource claim failes when ioremap() is
> > called:
> > [   10.837300] arm-cmn ARMHC700:00: error -EBUSY: can't request region for resource [mem 0x40000000-0x4fffffff]
> > [   10.847310] arm-cmn ARMHC700:00: probe with driver arm-cmn failed with error -16
> > [   10.854726] arm-cmn ARMHC700:02: error -EBUSY: can't request region for resource [mem 0x40040000000-0x4004fffffff]
> > [   10.865085] arm-cmn ARMHC700:02: probe with driver arm-cmn failed with error -16
> > 
> > Let CMN700 + ACPI do same as CMN600 + ACPI to allow CMN700
> > work in ACPI env.
> 
> No, the CMN-600 routine is a special case for CMN-600 having two nested
> memory resources of its own. CMN-700 and everything else only have one
> memory resource, so that is not appropriate. What else is claiming the
> region to cause a conflict?
You are right. I just saw the discussion after I sent this patch. :(.
I proposed new fix in that thread which align with the spec.

Could you please take a look? Thanks.


Regards
Yin, Fengwei

> 
> Thanks,
> Robin.
> 
> > Signed-off-by: Yin Fengwei <fengwei_yin@...ux.alibaba.com>
> > ---
> > I am also wondering whether we could just drop the CMN600 part id
> > check here if ACPI companion device claimed the resource?
> > 
> >   drivers/perf/arm-cmn.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> > index ef959e66db7c..8b5322a2aa6e 100644
> > --- a/drivers/perf/arm-cmn.c
> > +++ b/drivers/perf/arm-cmn.c
> > @@ -2559,7 +2559,8 @@ static int arm_cmn_probe(struct platform_device *pdev)
> >   	cmn->part = (unsigned long)device_get_match_data(cmn->dev);
> >   	platform_set_drvdata(pdev, cmn);
> > -	if (cmn->part == PART_CMN600 && has_acpi_companion(cmn->dev)) {
> > +	if (((cmn->part == PART_CMN600) || (cmn->part == PART_CMN700)) &&
> > +			has_acpi_companion(cmn->dev)) {
> >   		rootnode = arm_cmn600_acpi_probe(pdev, cmn);
> >   	} else {
> >   		rootnode = 0;
> > @@ -2649,7 +2650,7 @@ MODULE_DEVICE_TABLE(of, arm_cmn_of_match);
> >   static const struct acpi_device_id arm_cmn_acpi_match[] = {
> >   	{ "ARMHC600", PART_CMN600 },
> >   	{ "ARMHC650" },
> > -	{ "ARMHC700" },
> > +	{ "ARMHC700", PART_CMN700 },
> >   	{}
> >   };
> >   MODULE_DEVICE_TABLE(acpi, arm_cmn_acpi_match);