linux-kernel - Re: [PATCH 03/31] AsoC: intel/atom: 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z__PozpN0dOH0JWh@smile.fi.intel.com>
Date: Wed, 16 Apr 2025 18:41:23 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Philipp Stanner <phasta@...nel.org>
Cc: 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 03/31] AsoC: intel/atom: Use pure devres PCI

On Wed, Apr 16, 2025 at 03:12:13PM +0200, Philipp Stanner wrote:
> pci_request_regions() is a hybrid function which becomes managed if
> pcim_enable_device() was called before. This hybrid nature is deprecated
> and should not be used anymore.
> 
> Replace pci_request_regions() with the always-managed function
> pcim_request_all_regions().
> 
> Remove the call to pci_release_regions(), since pcim_ functions do
> cleanup automatically.
> 
> Pass 0 as length parameter to pcim_iomap(), which is the standard way
> for ioremapping an entire BAR.

...

>  sound/soc/intel/atom/sst/sst_pci.c | 56 ++++++++++++------------------
>  1 file changed, 23 insertions(+), 33 deletions(-)

Cool cleanup!

...

>  	/* DRAM */
>  	ctx->dram_end = pci_resource_end(pci, 4);
>  	ctx->dram_base = pci_resource_start(pci, 4);
> +	ctx->dram = pcim_iomap(pci, 4, 0);
> +	if (!ctx->dram)
> +		return -EINVAL;

Why EINVAL and not ENOMEM? mapping is about memory, no?

> +
>  	dev_dbg(ctx->dev, "DRAM Ptr %p\n", ctx->dram);
> -do_release_regions:
> -	pci_release_regions(pci);
>  	return ret;

Now it seems

	return 0;

should suffice here.

-- 
With Best Regards,
Andy Shevchenko