Message-ID: <ZwktO8AUmFEakhVP@smile.fi.intel.com>
Date: Fri, 11 Oct 2024 16:50:51 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Philipp Stanner <pstanner@...hat.com>
Cc: Damien Le Moal <dlemoal@...nel.org>, Niklas Cassel <cassel@...nel.org>,
	Sergey Shtylyov <s.shtylyov@....ru>,
	Basavaraj Natikar <basavaraj.natikar@....com>,
	Jiri Kosina <jikos@...nel.org>,
	Benjamin Tissoires <bentiss@...nel.org>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alex Dubov <oakad@...oo.com>,
	Sudarsana Kalluru <skalluru@...vell.com>,
	Manish Chopra <manishc@...vell.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rasesh Mody <rmody@...vell.com>, GR-Linux-NIC-Dev@...vell.com,
	Igor Mitsyanko <imitsyanko@...ntenna.com>,
	Sergey Matyukevich <geomatsi@...il.com>,
	Kalle Valo <kvalo@...nel.org>, Sanjay R Mehta <sanju.mehta@....com>,
	Shyam Sundar S K <Shyam-sundar.S-k@....com>,
	Jon Mason <jdmason@...zu.us>, Dave Jiang <dave.jiang@...el.com>,
	Allen Hubbe <allenbh@...il.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Alex Williamson <alex.williamson@...hat.com>,
	Juergen Gross <jgross@...e.com>,
	Stefano Stabellini <sstabellini@...nel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	Mario Limonciello <mario.limonciello@....com>,
	Chen Ni <nichen@...as.ac.cn>, Ricky Wu <ricky_wu@...ltek.com>,
	Al Viro <viro@...iv.linux.org.uk>, Breno Leitao <leitao@...ian.org>,
	Kevin Tian <kevin.tian@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Mostafa Saleh <smostafa@...gle.com>, Hannes Reinecke <hare@...e.de>,
	John Garry <john.g.garry@...cle.com>,
	Soumya Negi <soumya.negi97@...il.com>,
	Jason Gunthorpe <jgg@...pe.ca>, Yi Liu <yi.l.liu@...el.com>,
	"Dr. David Alan Gilbert" <linux@...blig.org>,
	Christian Brauner <brauner@...nel.org>,
	Ankit Agrawal <ankita@...dia.com>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Eric Auger <eric.auger@...hat.com>, Ye Bin <yebin10@...wei.com>,
	Marek Marczykowski-Górecki <marmarek@...isiblethingslab.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
	Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
	Rui Salvaterra <rsalvaterra@...il.com>,
	Marc Zyngier <maz@...nel.org>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	ntb@...ts.linux.dev, linux-pci@...r.kernel.org,
	linux-staging@...ts.linux.dev, kvm@...r.kernel.org,
	xen-devel@...ts.xenproject.org, linux-sound@...r.kernel.org
Subject: Re: [RFC PATCH 01/13] PCI: Prepare removing devres from pci_intx()

On Fri, Oct 11, 2024 at 02:16:06PM +0200, Philipp Stanner wrote:
> On Thu, 2024-10-10 at 17:40 +0300, Andy Shevchenko wrote:
> > On Wed, Oct 09, 2024 at 10:35:07AM +0200, Philipp Stanner wrote:
> > > pci_intx() is a hybrid function which sometimes performs devres
> > > operations, depending on whether pcim_enable_device() has been used
> > > to
> > > enable the pci_dev. This sometimes-managed nature of the function
> > > is
> > > problematic. Notably, it causes the function to allocate under some
> > > circumstances which makes it unusable from interrupt context.
> > > 
> > > To, ultimately, remove the hybrid nature from pci_intx(), it is
> > > first
> > > necessary to provide an always-managed and a never-managed version
> > > of that function. Then, all callers of pci_intx() can be ported to
> > > the
> > > version they need, depending whether they use pci_enable_device()
> > > or
> > > pcim_enable_device().

> > > An always-managed function exists, namely pcim_intx(), for which
> > > __pcim_intx(), a never-managed version of pci_intx() had been
> > > implemented.
> > 
> > > Make __pcim_intx() a public function under the name
> > > pci_intx_unmanaged(). Make pcim_intx() a public function.

It seems I got confused by these two paragraphs. Why the double underscored
function is even mentioned here?

> > To avoid an additional churn we can make just completely new APIs,
> > namely:
> > pcim_int_x()
> > pci_int_x()
> > 
> > You won't need all dirty dances with double underscored function
> > naming and
> > renaming.
> 
> Ähm.. I can't follow. The new version doesn't use double underscores
> anymore. __pcim_intx() is being removed, effectively.
> After this series, we'd end up with a clean:
> 
> 	pci_intx() <-> pcim_intx()
> 
> just as in the other PCI APIs.

...

> > > +	pci_read_config_word(pdev, PCI_COMMAND, &pci_command);
> > > +
> > > +	if (enable)
> > > +		new = pci_command & ~PCI_COMMAND_INTX_DISABLE;
> > > +	else
> > > +		new = pci_command | PCI_COMMAND_INTX_DISABLE;
> > > +
> > > +	if (new != pci_command)
> > 
> > I would use positive conditionals as easy to read (yes, a couple of
> > lines
> > longer, but also a win is the indentation and avoiding an additional
> > churn in
> > the future in case we need to add something in this branch.
> 
> I can't follow. You mean:
> 
> if (new == pci_command)
>     return;
> 
> ?
> 
> That's exactly the same level of indentation.

No, the body gets one level off.

> Plus, I just copied the code.
> 
> > > +		pci_write_config_word(pdev, PCI_COMMAND, new);

	if (new == pci_command)
		return;

	pci_write_config_word(pdev, PCI_COMMAND, new);

See the difference?
Also, imaging adding a new code in your case:

	if (new != pci_command)
		pci_write_config_word(pdev, PCI_COMMAND, new);

==>

	if (new != pci_command) {
		...foo...
		pci_write_config_word(pdev, PCI_COMMAND, new);
		...bar...
	}

And in mine:

	if (new == pci_command)
		return;

	...foo...
	pci_write_config_word(pdev, PCI_COMMAND, new);
	...bar...

I hope it's clear now what I meant.

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists