From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Shay Drori <shayd@nvidia.com>
Cc: maciej.fijalkowski@intel.com, mateusz.polchlopek@intel.com,
netdev@vger.kernel.org, jiri@nvidia.com, michal.kubiak@intel.com,
intel-wired-lan@lists.osuosl.org, pio.raczynski@gmail.com,
sridhar.samudrala@intel.com, jacob.e.keller@intel.com,
wojciech.drewek@intel.com, przemyslaw.kitszel@intel.com
Subject: Re: [Intel-wired-lan] [iwl-next v4 8/8] ice: allow to activate and deactivate subfunction
Date: Thu, 18 Apr 2024 13:55:03 +0200 [thread overview]
Message-ID: <ZiEKF8Hm+ccuVedQ@mev-dev> (raw)
In-Reply-To: <1b678660-7ee7-44d0-91a7-14985d2c469e@nvidia.com>
On Thu, Apr 18, 2024 at 11:12:47AM +0300, Shay Drori wrote:
> resend as plain test
>
> On 18/04/2024 10:53, Shay Drori wrote:
> > On 17/04/2024 17:20, Michal Swiatkowski wrote:
> > > +/**
> > > + * ice_devlink_port_fn_state_get - devlink handler for port state get
> > > + * @port: pointer to devlink port
> > > + * @state: admin configured state of the port
> > > + * @opstate: current port operational state
> > > + * @extack: extack for reporting error messages
> > > + *
> > > + * Gets port state.
> > > + *
> > > + * Return: zero on success or an error code on failure.
> > > + */
> > > +static int
> > > +ice_devlink_port_fn_state_get(struct devlink_port *port,
> > > + enum devlink_port_fn_state *state,
> > > + enum devlink_port_fn_opstate *opstate,
> > > + struct netlink_ext_ack *extack)
> > > +{
> > > + struct ice_dynamic_port *dyn_port;
> > > +
> > > + dyn_port = ice_devlink_port_to_dyn(port);
> > > +
> > > + if (dyn_port->active) {
> > > + *state = DEVLINK_PORT_FN_STATE_ACTIVE;
> > > + *opstate = DEVLINK_PORT_FN_OPSTATE_ATTACHED;
> >
> >
> > DEVLINK_PORT_FN_OPSTATE_ATTACHED means the SF is up/bind[1].
> > ice is using auxiliary bus for SFs, which means user can unbind it
> > via the auxiliary sysfs (/sys/bus/auxiliary/drivers/ice_sf/unbind).
> > In this case[2], you need to return:
> > *state = DEVLINK_PORT_FN_STATE_ACTIVE;
> > *opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
> >
Thanks, I didn't think about unbinding/binding the aux driver via sysfs.
To be sure:
- user create the subfunction:
INACTIVE, DETACHED
- user activate it:
ACTIVE, ATTACHED
- user unbind driver:
ACTIVE, DETACHED
- user can bind it again as long as subfunction port is ACTIVE
is it right?
I will fix the comment from previous patch and add state tracking for
ATTACHED/DETACHED.
Thanks,
Michal
> >
> > [1]
> > Documentation from include/uapi/linux/devlink.h:
> >
> > * @DEVLINK_PORT_FN_OPSTATE_ATTACHED: Driver is attached to the function.
> > <...>
> > * @DEVLINK_PORT_FN_OPSTATE_DETACHED: Driver is detached from the function.
> >
> > > + } else {
> > > + *state = DEVLINK_PORT_FN_STATE_INACTIVE;
> > > + *opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
WARNING: multiple messages have this Message-ID (diff)
From: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
To: Shay Drori <shayd@nvidia.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, jiri@nvidia.com,
mateusz.polchlopek@intel.com
Subject: Re: [iwl-next v4 8/8] ice: allow to activate and deactivate subfunction
Date: Thu, 18 Apr 2024 13:55:03 +0200 [thread overview]
Message-ID: <ZiEKF8Hm+ccuVedQ@mev-dev> (raw)
In-Reply-To: <1b678660-7ee7-44d0-91a7-14985d2c469e@nvidia.com>
On Thu, Apr 18, 2024 at 11:12:47AM +0300, Shay Drori wrote:
> resend as plain test
>
> On 18/04/2024 10:53, Shay Drori wrote:
> > On 17/04/2024 17:20, Michal Swiatkowski wrote:
> > > +/**
> > > + * ice_devlink_port_fn_state_get - devlink handler for port state get
> > > + * @port: pointer to devlink port
> > > + * @state: admin configured state of the port
> > > + * @opstate: current port operational state
> > > + * @extack: extack for reporting error messages
> > > + *
> > > + * Gets port state.
> > > + *
> > > + * Return: zero on success or an error code on failure.
> > > + */
> > > +static int
> > > +ice_devlink_port_fn_state_get(struct devlink_port *port,
> > > + enum devlink_port_fn_state *state,
> > > + enum devlink_port_fn_opstate *opstate,
> > > + struct netlink_ext_ack *extack)
> > > +{
> > > + struct ice_dynamic_port *dyn_port;
> > > +
> > > + dyn_port = ice_devlink_port_to_dyn(port);
> > > +
> > > + if (dyn_port->active) {
> > > + *state = DEVLINK_PORT_FN_STATE_ACTIVE;
> > > + *opstate = DEVLINK_PORT_FN_OPSTATE_ATTACHED;
> >
> >
> > DEVLINK_PORT_FN_OPSTATE_ATTACHED means the SF is up/bind[1].
> > ice is using auxiliary bus for SFs, which means user can unbind it
> > via the auxiliary sysfs (/sys/bus/auxiliary/drivers/ice_sf/unbind).
> > In this case[2], you need to return:
> > *state = DEVLINK_PORT_FN_STATE_ACTIVE;
> > *opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
> >
Thanks, I didn't think about unbinding/binding the aux driver via sysfs.
To be sure:
- user create the subfunction:
INACTIVE, DETACHED
- user activate it:
ACTIVE, ATTACHED
- user unbind driver:
ACTIVE, DETACHED
- user can bind it again as long as subfunction port is ACTIVE
is it right?
I will fix the comment from previous patch and add state tracking for
ATTACHED/DETACHED.
Thanks,
Michal
> >
> > [1]
> > Documentation from include/uapi/linux/devlink.h:
> >
> > * @DEVLINK_PORT_FN_OPSTATE_ATTACHED: Driver is attached to the function.
> > <...>
> > * @DEVLINK_PORT_FN_OPSTATE_DETACHED: Driver is detached from the function.
> >
> > > + } else {
> > > + *state = DEVLINK_PORT_FN_STATE_INACTIVE;
> > > + *opstate = DEVLINK_PORT_FN_OPSTATE_DETACHED;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
next prev parent reply other threads:[~2024-04-18 11:55 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 14:20 [Intel-wired-lan] [iwl-next v4 0/8] ice: support devlink subfunction Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 1/8] ice: add new VSI type for subfunctions Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 2/8] ice: export ice ndo_ops functions Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 3/8] ice: add basic devlink subfunctions support Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 4/8] ice: treat subfunction VSI the same as PF VSI Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 5/8] ice: allocate devlink for subfunction Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-18 12:04 ` [Intel-wired-lan] " Jiri Pirko
2024-04-18 12:04 ` Jiri Pirko
2024-04-18 12:48 ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-18 12:48 ` Michal Swiatkowski
2024-04-18 13:02 ` [Intel-wired-lan] " Jiri Pirko
2024-04-18 13:02 ` Jiri Pirko
2024-04-18 14:46 ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-18 14:46 ` Michal Swiatkowski
2024-04-18 15:43 ` [Intel-wired-lan] " Jiri Pirko
2024-04-18 15:43 ` Jiri Pirko
2024-04-18 16:11 ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-18 16:11 ` Michal Swiatkowski
2024-04-18 17:25 ` [Intel-wired-lan] " Jiri Pirko
2024-04-18 17:25 ` Jiri Pirko
2024-04-19 17:22 ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-19 17:22 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 6/8] ice: base subfunction aux driver Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-18 7:57 ` [Intel-wired-lan] " Shay Drori
2024-04-18 7:57 ` Shay Drori
2024-04-18 14:47 ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-18 14:47 ` Michal Swiatkowski
2024-04-18 13:02 ` [Intel-wired-lan] " Jiri Pirko
2024-04-18 13:02 ` Jiri Pirko
2024-04-18 14:47 ` [Intel-wired-lan] " Michal Swiatkowski
2024-04-18 14:47 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 7/8] ice: implement netdev for subfunction Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-17 14:20 ` [Intel-wired-lan] [iwl-next v4 8/8] ice: allow to activate and deactivate subfunction Michal Swiatkowski
2024-04-17 14:20 ` Michal Swiatkowski
2024-04-18 7:53 ` [Intel-wired-lan] " Shay Drori
2024-04-18 8:12 ` Shay Drori
2024-04-18 8:12 ` Shay Drori
2024-04-18 11:55 ` Michal Swiatkowski [this message]
2024-04-18 11:55 ` Michal Swiatkowski
2024-04-18 12:20 ` [Intel-wired-lan] " Shay Drori
2024-04-18 12:20 ` Shay Drori
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=ZiEKF8Hm+ccuVedQ@mev-dev \
--to=michal.swiatkowski@linux.intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=jiri@nvidia.com \
--cc=maciej.fijalkowski@intel.com \
--cc=mateusz.polchlopek@intel.com \
--cc=michal.kubiak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pio.raczynski@gmail.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=shayd@nvidia.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 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.