From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Igor Russkikh <Igor.Russkikh@aquantia.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Pavel Belous <Pavel.Belous@aquantia.com>
Subject: Re: [dpdk-dev] [PATCH v4 20/22] net/atlantic: LED control DPDK and private APIs
Date: Wed, 10 Oct 2018 11:32:19 +0100 [thread overview]
Message-ID: <1bb197a4-2bc2-1dc6-1ca9-f57d39d5b27d@intel.com> (raw)
In-Reply-To: <a3903743df60693a271a7e0d4f7690f2160dd079.1539075891.git.igor.russkikh@aquantia.com>
On 10/9/2018 10:32 AM, Igor Russkikh wrote:
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> Signed-off-by: Pavel Belous <Pavel.Belous@aquantia.com>
<...>
> +/**
> + * This is a custom API for adapter's LED controls.
> + *
> + * @param dev
> + * Ethernet device to apply control to
> + * @param control
> + * 6 bit value (3 leds each 2bit):
> + * - bits 0-1: LED0 control
> + * - bits 2-3: LED1 control
> + * - bits 4-5: LED2 control
> + * Each two bit control value is:
> + * - 0: Firmware manages this LED activity
> + * - 1: Permanent ON
> + * - 2: Blinking
> + * - 3: Permanent OFF
> + *
> + * @return
> + * - (0) if successful.
> + * - (-ENOTSUP) if hardware doesn't support.
> + */
> +int rte_pmd_atl_dev_led_control(int port, int control);
What is the intention here, making PMD specific public API?
If so .map file is missing but we discourage using PMD specific APIs,
can't it be possible to extend exiting led related dev_ops in a generic way to
cover your use case?
next prev parent reply other threads:[~2018-10-10 10:32 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-09 9:31 [dpdk-dev] [PATCH v4 00/22] net/atlantic: Aquantia aQtion 10G NIC Family DPDK PMD driver Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 01/22] net/atlantic: atlantic PMD driver skeleton Igor Russkikh
2018-10-10 10:30 ` Ferruh Yigit
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 02/22] net/atlantic: logging macroes and some typedefs Igor Russkikh
2018-10-10 10:24 ` Ferruh Yigit
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 03/22] net/atlantic: hardware register access routines Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 04/22] net/atlantic: hw_atl register declarations Igor Russkikh
2018-10-10 10:31 ` Ferruh Yigit
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 05/22] net/atlantic: firmware operations layer Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 06/22] net/atlantic: b0 hardware layer main logic Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 07/22] net/atlantic: rte device start, stop, initial configuration Igor Russkikh
2018-10-10 10:26 ` Ferruh Yigit
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 08/22] net/atlantic: TX/RX function prototypes Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 09/22] net/atlantic: RX side structures and implementation Igor Russkikh
2018-10-10 10:29 ` Ferruh Yigit
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 10/22] net/atlantic: TX " Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 11/22] net/atlantic: link status and interrupt management Igor Russkikh
2018-10-10 10:27 ` Ferruh Yigit
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 12/22] net/atlantic: device statistics, xstats Igor Russkikh
2018-10-10 10:27 ` Ferruh Yigit
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 13/22] net/atlantic: support for RX/TX descriptors information Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 14/22] net/atlantic: promisc and allmulti configuration Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 15/22] net/atlantic: RSS and RETA manipulation API Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 16/22] net/atlantic: flow control configuration Igor Russkikh
2018-10-09 9:31 ` [dpdk-dev] [PATCH v4 17/22] net/atlantic: MAC address manipulations Igor Russkikh
2018-10-10 10:28 ` Ferruh Yigit
2018-10-09 9:32 ` [dpdk-dev] [PATCH v4 18/22] net/atlantic: VLAN filters and offloads Igor Russkikh
2018-10-09 9:32 ` [dpdk-dev] [PATCH v4 19/22] net/atlantic: eeprom and register manipulation routines Igor Russkikh
2018-10-09 9:32 ` [dpdk-dev] [PATCH v4 20/22] net/atlantic: LED control DPDK and private APIs Igor Russkikh
2018-10-10 10:32 ` Ferruh Yigit [this message]
2018-10-10 13:35 ` Igor Russkikh
2018-10-10 13:54 ` Ferruh Yigit
2018-10-09 9:32 ` [dpdk-dev] [PATCH v4 21/22] net/atlantic: support for read MAC registers for debug purposes Igor Russkikh
2018-10-09 9:32 ` [dpdk-dev] [PATCH v4 22/22] net/atlantic: documentation and rel notes Igor Russkikh
2018-10-10 10:29 ` Ferruh Yigit
2018-10-10 10:32 ` [dpdk-dev] [PATCH v4 00/22] net/atlantic: Aquantia aQtion 10G NIC Family DPDK PMD driver Ferruh Yigit
2018-10-10 13:21 ` Igor Russkikh
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=1bb197a4-2bc2-1dc6-1ca9-f57d39d5b27d@intel.com \
--to=ferruh.yigit@intel.com \
--cc=Igor.Russkikh@aquantia.com \
--cc=Pavel.Belous@aquantia.com \
--cc=dev@dpdk.org \
/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).