netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Shay Drory <shayd@nvidia.com>,
	rafael@kernel.org, ira.weiny@intel.com, netdev@vger.kernel.org,
	linux-rdma@vger.kernel.org, leon@kernel.org, tariqt@nvidia.com,
	Parav Pandit <parav@nvidia.com>,
	pabeni@redhat.com, davem@davemloft.net, kuba@kernel.org,
	edumazet@google.com, david.m.ertman@intel.com
Subject: Re: [PATCH net-next v7 1/2] driver core: auxiliary bus: show auxiliary device IRQs
Date: Tue, 18 Jun 2024 18:08:06 +0200	[thread overview]
Message-ID: <2024061840-coping-rubbing-7af3@gregkh> (raw)
In-Reply-To: <ca97ec5b-9b46-4456-bf5b-37136aa7f1bf@intel.com>

On Tue, Jun 18, 2024 at 05:47:15PM +0200, Przemek Kitszel wrote:
> On 6/18/24 17:09, Shay Drory wrote:
> > PCI subfunctions (SF) are anchored on the auxiliary bus. PCI physical
> > and virtual functions are anchored on the PCI bus. The irq information
> > of each such function is visible to users via sysfs directory "msi_irqs"
> > containing files for each irq entry. However, for PCI SFs such
> > information is unavailable. Due to this users have no visibility on IRQs
> > used by the SFs.
> > Secondly, an SF can be multi function device supporting rdma, netdevice
> > and more. Without irq information at the bus level, the user is unable
> > to view or use the affinity of the SF IRQs.
> > 
> > Hence to match to the equivalent PCI PFs and VFs, add "irqs" directory,
> > for supporting auxiliary devices, containing file for each irq entry.
> > 
> > For example:
> > $ ls /sys/bus/auxiliary/devices/mlx5_core.sf.1/irqs/
> > 50  51  52  53  54  55  56  57  58
> > 
> > Reviewed-by: Parav Pandit <parav@nvidia.com>
> > Signed-off-by: Shay Drory <shayd@nvidia.com>
> > 
> > ---
> > v6-v7:
> > - dynamically creating irqs directory when first irq file created (Greg)
> > - removed irqs flag and simplified the dev_add() API (Greg)
> > - move sysfs related new code to a new auxiliary_sysfs.c file (Greg)
> 
> [...]
> 
> > +static int auxiliary_irq_dir_prepare(struct auxiliary_device *auxdev)
> > +{
> > +	int ret = 0;
> > +
> > +	mutex_lock(&auxdev->lock);
> > +	if (auxdev->dir_exists)
> > +		goto unlock;
> > +
> > +	xa_init(&auxdev->irqs);
> 
> due to below error handling you could end up with calling xa_init()
> twice (and this is a "library" code, so it does not matter how you
> handle this error in the current sole user ;))
> 
> > +	ret = devm_device_add_group(&auxdev->dev, &auxiliary_irqs_group);
> > +	if (!ret)
> > +		auxdev->dir_exists = 1;
> > +
> > +unlock:
> > +	mutex_unlock(&auxdev->lock);
> > +	return ret;
> > +}
> > +
> 
> [...]
> 
> > --- a/include/linux/auxiliary_bus.h
> > +++ b/include/linux/auxiliary_bus.h
> > @@ -58,6 +58,7 @@
> >    *       in
> >    * @name: Match name found by the auxiliary device driver,
> >    * @id: unique identitier if multiple devices of the same name are exported,
> > + * @irqs: irqs xarray contains irq indices which are used by the device,
> >    *
> >    * An auxiliary_device represents a part of its parent device's functionality.
> >    * It is given a name that, combined with the registering drivers
> > @@ -138,7 +139,10 @@
> >   struct auxiliary_device {
> >   	struct device dev;
> >   	const char *name;
> > +	struct xarray irqs;
> > +	struct mutex lock; /* Protects "irqs" directory creation */
> >   	u32 id;
> > +	u8 dir_exists:1;
> 
> nit: I would make it a bool, or `bool: 1` if you really want

Why is this even needed?  It should "know" if the directory is there or
not, it can always be looked up, right?

thanks,

greg k-h

  reply	other threads:[~2024-06-18 16:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18 15:09 [PATCH net-next v7 0/2] Introduce auxiliary bus IRQs sysfs Shay Drory
2024-06-18 15:09 ` [PATCH net-next v7 1/2] driver core: auxiliary bus: show auxiliary device IRQs Shay Drory
2024-06-18 15:47   ` Przemek Kitszel
2024-06-18 16:08     ` Greg KH [this message]
2024-06-18 16:13   ` Greg KH
2024-06-19  6:33     ` Shay Drori
2024-06-19  6:45       ` Greg KH
2024-06-20  5:47         ` Shay Drori
2024-06-25 17:41           ` Shay Drori
2024-06-20 19:48   ` Simon Horman
2024-06-18 15:09 ` [PATCH net-next v7 2/2] net/mlx5: Expose SFs IRQs Shay Drory

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=2024061840-coping-rubbing-7af3@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=david.m.ertman@intel.com \
    --cc=edumazet@google.com \
    --cc=ira.weiny@intel.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=parav@nvidia.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=rafael@kernel.org \
    --cc=shayd@nvidia.com \
    --cc=tariqt@nvidia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).