From: Jiri Pirko <jiri@resnulli.us>
To: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
jacob.e.keller@intel.com, michal.kubiak@intel.com,
maciej.fijalkowski@intel.com, sridhar.samudrala@intel.com,
przemyslaw.kitszel@intel.com, wojciech.drewek@intel.com,
pio.raczynski@gmail.com,
Piotr Raczynski <piotr.raczynski@intel.com>
Subject: Re: [iwl-next v1 07/15] ice: add auxiliary device sfnum attribute
Date: Tue, 13 Feb 2024 12:29:40 +0100 [thread overview]
Message-ID: <ZctSpPamhrlF4ILg@nanopsycho> (raw)
In-Reply-To: <Zcs8LsRrbOfUdIL7@mev-dev>
Tue, Feb 13, 2024 at 10:53:50AM CET, michal.swiatkowski@linux.intel.com wrote:
>On Tue, Feb 13, 2024 at 09:59:14AM +0100, Jiri Pirko wrote:
>> Tue, Feb 13, 2024 at 08:27:16AM CET, michal.swiatkowski@linux.intel.com wrote:
>> >From: Piotr Raczynski <piotr.raczynski@intel.com>
>> >
>> >Add read only sysfs attribute for each auxiliary subfunction
>> >device. This attribute is needed for orchestration layer
>> >to distinguish SF devices from each other since there is no
>> >native devlink mechanism to represent the connection between
>> >devlink instance and the devlink port created for the port
>> >representor.
>> >
>> >Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
>> >Signed-off-by: Piotr Raczynski <piotr.raczynski@intel.com>
>> >Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
>> >---
>> > drivers/net/ethernet/intel/ice/ice_sf_eth.c | 31 +++++++++++++++++++++
>> > 1 file changed, 31 insertions(+)
>> >
>> >diff --git a/drivers/net/ethernet/intel/ice/ice_sf_eth.c b/drivers/net/ethernet/intel/ice/ice_sf_eth.c
>> >index ab90db52a8fc..abee733710a5 100644
>> >--- a/drivers/net/ethernet/intel/ice/ice_sf_eth.c
>> >+++ b/drivers/net/ethernet/intel/ice/ice_sf_eth.c
>> >@@ -224,6 +224,36 @@ static void ice_sf_dev_release(struct device *device)
>> > kfree(sf_dev);
>> > }
>> >
>> >+static ssize_t
>> >+sfnum_show(struct device *dev, struct device_attribute *attr, char *buf)
>> >+{
>> >+ struct devlink_port_attrs *attrs;
>> >+ struct auxiliary_device *adev;
>> >+ struct ice_sf_dev *sf_dev;
>> >+
>> >+ adev = to_auxiliary_dev(dev);
>> >+ sf_dev = ice_adev_to_sf_dev(adev);
>> >+ attrs = &sf_dev->dyn_port->devlink_port.attrs;
>> >+
>> >+ return sysfs_emit(buf, "%u\n", attrs->pci_sf.sf);
>> >+}
>> >+
>> >+static DEVICE_ATTR_RO(sfnum);
>> >+
>> >+static struct attribute *ice_sf_device_attrs[] = {
>> >+ &dev_attr_sfnum.attr,
>> >+ NULL,
>> >+};
>> >+
>> >+static const struct attribute_group ice_sf_attr_group = {
>> >+ .attrs = ice_sf_device_attrs,
>> >+};
>> >+
>> >+static const struct attribute_group *ice_sf_attr_groups[2] = {
>> >+ &ice_sf_attr_group,
>> >+ NULL
>> >+};
>> >+
>> > /**
>> > * ice_sf_eth_activate - Activate Ethernet subfunction port
>> > * @dyn_port: the dynamic port instance for this subfunction
>> >@@ -262,6 +292,7 @@ ice_sf_eth_activate(struct ice_dynamic_port *dyn_port,
>> > sf_dev->dyn_port = dyn_port;
>> > sf_dev->adev.id = id;
>> > sf_dev->adev.name = "sf";
>> >+ sf_dev->adev.dev.groups = ice_sf_attr_groups;
>>
>> Ugh. Custom driver sysfs files like this are always very questionable.
>> Don't do that please. If you need to expose sfnum, please think about
>> some common way. Why exactly you need to expose it?
>
>Uh, hard question. I will drop it and check if it still needed to expose
>the sfnum, probably no, as I have never used this sysfs during testing.
>
>Should devlink be used for it?
sfnum is exposed over devlink on the port representor. If you need to
expose it on the actual SF, we have to figure it out. But again, why?
>
>Thanks
>
>>
>> pw-bot: cr
>>
>>
>> > sf_dev->adev.dev.release = ice_sf_dev_release;
>> > sf_dev->adev.dev.parent = &pdev->dev;
>> >
>> >--
>> >2.42.0
>> >
>> >
next prev parent reply other threads:[~2024-02-13 11:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-13 7:27 [iwl-next v1 00/15] ice: support devlink subfunctions Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 01/15] ice: move devlink port code to a separate file Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 02/15] ice: add new VSI type for subfunctions Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 03/15] ice: export ice ndo_ops functions Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 04/15] ice: add basic devlink subfunctions support Michal Swiatkowski
2024-02-13 8:55 ` Jiri Pirko
2024-02-13 9:39 ` [Intel-wired-lan] " Michal Swiatkowski
2024-02-13 11:27 ` Jiri Pirko
2024-02-13 12:02 ` Michal Swiatkowski
2024-02-13 14:57 ` Jiri Pirko
2024-02-14 6:26 ` Michal Swiatkowski
2024-02-14 19:45 ` Jacob Keller
2024-02-13 7:27 ` [iwl-next v1 05/15] ice: add subfunctions ethtool ops Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 06/15] ice: add subfunction aux driver support Michal Swiatkowski
2024-02-13 8:57 ` Jiri Pirko
2024-02-13 9:43 ` Michal Swiatkowski
2024-02-13 11:28 ` Jiri Pirko
2024-02-13 12:03 ` Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 07/15] ice: add auxiliary device sfnum attribute Michal Swiatkowski
2024-02-13 8:59 ` Jiri Pirko
2024-02-13 9:53 ` Michal Swiatkowski
2024-02-13 11:29 ` Jiri Pirko [this message]
2024-02-13 11:55 ` Michal Swiatkowski
2024-02-13 22:04 ` Jacob Keller
2024-02-14 8:45 ` Jiri Pirko
2024-02-14 19:41 ` Keller, Jacob E
2024-02-13 7:27 ` [iwl-next v1 08/15] ice: store SF data in VSI struct Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 09/15] ice: store representor ID in bridge port Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 10/15] ice: create port representor for SF Michal Swiatkowski
2024-02-13 9:00 ` Jiri Pirko
2024-02-13 9:55 ` Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 11/15] ice: check if SF is ready in ethtool ops Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 12/15] ice: netdevice ops for SF representor Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 13/15] ice: support subfunction devlink Tx topology Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 14/15] ice: basic support for VLAN in subfunctions Michal Swiatkowski
2024-02-13 7:27 ` [iwl-next v1 15/15] ice: move ice_devlink.[ch] to devlink folder Michal Swiatkowski
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=ZctSpPamhrlF4ILg@nanopsycho \
--to=jiri@resnulli.us \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=maciej.fijalkowski@intel.com \
--cc=michal.kubiak@intel.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pio.raczynski@gmail.com \
--cc=piotr.raczynski@intel.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=sridhar.samudrala@intel.com \
--cc=wojciech.drewek@intel.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).