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
next prev parent 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).