From: Andrew Lunn <andrew@lunn.ch>
To: Marek Pazdan <mpazdan@arista.com>
Cc: aleksander.lobakin@intel.com, almasrymina@google.com,
andrew+netdev@lunn.ch, anthony.l.nguyen@intel.com,
daniel.zahka@gmail.com, davem@davemloft.net,
ecree.xilinx@gmail.com, edumazet@google.com, gal@nvidia.com,
horms@kernel.org, intel-wired-lan@lists.osuosl.org,
jianbol@nvidia.com, kory.maincent@bootlin.com, kuba@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
pabeni@redhat.com, przemyslaw.kitszel@intel.com,
willemb@google.com
Subject: Re: [Intel-wired-lan] [PATCH net-next v2 2/2] ice: add qsfp transceiver reset, interrupt and presence pin control
Date: Thu, 15 May 2025 03:23:39 +0200 [thread overview]
Message-ID: <200f7d11-50c2-4ee2-a80b-15341fbbd5f4@lunn.ch> (raw)
In-Reply-To: <20250513224017.202236-2-mpazdan@arista.com>
> + * ice_get_module_mgmt_signal - get module management signal status
> + * @dev: network interface device structure
> + * @params: ethtool module management signal params
> + * @extack: extended ACK from the Netlink message
> + *
> + * Returns -EIO if AQ command for GPIO get failed, otherwise
> + * returns 0 and current status of requested signal in params.
> + */
> +static int
> +ice_get_module_mgmt_signal(struct net_device *dev,
> + struct ethtool_module_mgmt_params *params,
> + struct netlink_ext_ack *extack)
> +{
> + struct ice_netdev_priv *np = netdev_priv(dev);
> + struct ice_pf *pf = np->vsi->back;
> + struct ice_hw *hw = &pf->hw;
> + u16 gpio_handle = 0; /* SOC/on-chip GPIO */
> + bool value;
> + int ret = 0;
> +
> + if (hw->has_module_mgmt_gpio) {
> + switch (params->type) {
> + case ETHTOOL_MODULE_MGMT_RESET:
> + ret = ice_aq_get_gpio(hw, gpio_handle,
> + ICE_MGMT_PIN_RESET, &value, NULL);
> + break;
Reset, i can kind of understand being used this way.
> + case ETHTOOL_MODULE_MGMT_INT:
> + ret = ice_aq_get_gpio(hw, gpio_handle,
> + ICE_MGMT_PIN_INT, &value, NULL);
> + break;
> + case ETHTOOL_MODULE_MGMT_PRESENT:
> + ret = ice_aq_get_gpio(hw, gpio_handle,
> + ICE_MGMT_PIN_PRESENT, &value, NULL);
> + break;
but not these two. These represent events. I've not looked at the
datasheet... Does the GPIO controller support interrupts? For PRESENT
you are interested in the edges, maybe with some debounce logic. For
INT, i _guess_ it is active low? But i've no idea what user space is
going to actually do on an interrupt, and how is it going to clear the
interrupt? This smells like a user space driver, which is not
something we want. Even if there is a legitimate use case, which there
might be for PRESENT, polling does not make much sense when the kernel
can broadcast a netlink message to user space if the GPIO controller
has interrupt support.
Andrew
---
pw-bot: cr
next prev parent reply other threads:[~2025-05-15 1:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 12:35 [PATCH 1/2] ethtool: transceiver reset and presence pin control Marek Pazdan
2025-04-07 12:35 ` [PATCH 2/2] ice: add qsfp " Marek Pazdan
2025-04-07 13:46 ` Kory Maincent
2025-04-07 20:30 ` Andrew Lunn
2025-04-08 14:22 ` [Intel-wired-lan] " Marek Pazdan
2025-04-08 15:23 ` Andrew Lunn
2025-04-07 13:32 ` [PATCH 1/2] ethtool: " Kory Maincent
2025-04-08 15:54 ` [Intel-wired-lan] " Marek Pazdan
2025-04-07 20:39 ` Andrew Lunn
2025-04-08 15:32 ` [Intel-wired-lan] " Marek Pazdan
2025-04-08 16:10 ` Andrew Lunn
2025-05-13 22:40 ` [PATCH net-next v2 1/2] ethtool: qsfp transceiver reset, interrupt " Marek Pazdan
2025-05-13 22:40 ` [Intel-wired-lan] [PATCH net-next v2 2/2] ice: add " Marek Pazdan
2025-05-15 1:23 ` Andrew Lunn [this message]
2025-05-14 0:26 ` [PATCH net-next v2 1/2] ethtool: " Jakub Kicinski
2025-05-15 1:10 ` Andrew Lunn
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=200f7d11-50c2-4ee2-a80b-15341fbbd5f4@lunn.ch \
--to=andrew@lunn.ch \
--cc=aleksander.lobakin@intel.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=daniel.zahka@gmail.com \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jianbol@nvidia.com \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpazdan@arista.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=willemb@google.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