linux-kernel - Re: [PATCH 02/31] ASoC: intel/avs: Use pure devres PCI

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] [day] [month] [year] [list]

Message-ID: <Z__xD0WcujiT-12-@smile.fi.intel.com>
Date: Wed, 16 Apr 2025 21:03:59 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: phasta@...nel.org
Cc: Bjorn Helgaas <helgaas@...nel.org>,
	Krzysztof Wilczyński <kwilczynski@...nel.org>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Jaya Kumar <jayakumar.alsa@...il.com>,
	Clemens Ladisch <clemens@...isch.de>,
	Cezary Rojewski <cezary.rojewski@...el.com>,
	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
	Bard Liao <yung-chuan.liao@...ux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
	Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	Mark Brown <broonie@...nel.org>,
	Daniel Baluta <daniel.baluta@....com>,
	Colin Ian King <colin.i.king@...il.com>,
	David Rhodes <drhodes@...nsource.cirrus.com>,
	liujing <liujing@...s.chinamobile.com>,
	Jerome Brunet <jbrunet@...libre.com>,
	Andres Urian Florez <andres.emb.sys@...il.com>,
	Oswald Buddenhagen <oswald.buddenhagen@....de>,
	Thorsten Blum <thorsten.blum@...ux.dev>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	Amadeusz Sławiński <amadeuszx.slawinski@...ux.intel.com>,
	Charles Keepax <ckeepax@...nsource.cirrus.com>,
	linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
	sound-open-firmware@...a-project.org
Subject: Re: [PATCH 02/31] ASoC: intel/avs: Use pure devres PCI

On Wed, Apr 16, 2025 at 06:25:52PM +0200, Philipp Stanner wrote:
> On Wed, 2025-04-16 at 18:39 +0300, Andy Shevchenko wrote:
> > On Wed, Apr 16, 2025 at 03:12:12PM +0200, Philipp Stanner wrote:

...

> > >  	bus->remap_addr = pci_ioremap_bar(pci, 0);
> > >  	if (!bus->remap_addr) {
> > >  		dev_err(bus->dev, "ioremap error\n");
> > > -		ret = -ENXIO;
> > > -		goto err_remap_bar0;
> > > +		return -ENXIO;
> > 
> > Here and everywhere else these can now be converted to
> > dev_err_probe().
> > Are you planning to do so?
> 
> I want to do what's necessary to get PCI in better shape, since that's
> what the GPUs and accelerators we / I care about use :)
> 
> IOW, I want pci_request_regions() removed from here.

Okay!

...

> > >  err_remap_bar4:
> > >  	iounmap(bus->remap_addr);
> > 
> > This looks weird if the driver already is using pcim_enable_device().
> > Doesn't this look to you as an existing bug?
> 
> I looked briefly at it and it doesn't appear like an obvious bug to me
> because the drivers uses the (very old? deprecated?) pci_ioremap_bar().

> In any case the driver doesn't set up any devres callback, so has to
> iounmap() manually.

Okay, so they are using managed and non-managed APIs, but release / error path
ordering is fine. So, false alarm then.

> @Bjorn:
> Any comments on pci_ioremap_bar()? Should we mark that as deprecated?

> > > -err_remap_bar0:
> > > -	pci_release_regions(pci);
> > >  	return ret;

-- 
With Best Regards,
Andy Shevchenko