All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.