from:"Scott Branden"

[PATCH v3 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

2017-12-12 Thread Scott Branden

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,ap,dedicated,all

Add -shared onto end of components to specified shared version.

Alternatively, you can specific component bitfield directly using
ethtool --reset DEVNAME flags %x

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
 ethtool.8.in |  67 ++-
 ethtool.c| 113 +++
 2 files changed, 179 insertions(+), 1 deletion(-)

diff --git a/ethtool.8.in b/ethtool.8.in
index 90ead41..7ca8bfe 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -354,6 +354,30 @@ ethtool \- query or control network driver and hardware 
settings
 .B ethtool \-\-get\-phy\-tunable
 .I devname
 .RB [ downshift ]
+.HP
+.B ethtool \-\-reset
+.I devname
+.BN flags
+.RB [ mgmt ]
+.RB [ mgmt-shared ]
+.RB [ irq ]
+.RB [ irq-shared ]
+.RB [ dma ]
+.RB [ dma-shared ]
+.RB [ filter ]
+.RB [ filter-shared ]
+.RB [ offload ]
+.RB [ offload-shared ]
+.RB [ mac ]
+.RB [ mac-shared ]
+.RB [ phy ]
+.RB [ phy-shared ]
+.RB [ ram ]
+.RB [ ram-shared ]
+.RB [ ap ]
+.RB [ ap-shared ]
+.RB [ dedicated ]
+.RB [ all ]
 .
 .\" Adjust lines (i.e. full justification) and hyphenate.
 .ad
@@ -1006,6 +1030,46 @@ Downshift is useful where cable does not have the 4 
pairs instance.
 
 Gets the PHY downshift count/status.
 .RE
+.TP
+.B \-\-reset
+Reset hardware components specified by flags and components listed below
+.RS 4
+.TP
+.BI flags \ N
+Resets the components based on direct flags mask
+.TP
+.B mgmt
+Management processor
+.TP
+.B irq
+Interrupt requester
+.TP
+.B dma
+DMA engine
+.TP
+.B filter
+Filtering/flow direction
+.TP
+.B offload
+Protocol offload
+.TP
+.B mac
+Media access controller
+.TP
+.B phy
+Transceiver/PHY
+.TP
+.B ram
+RAM shared between multiple components
+.B ap
+Application Processor
+.TP
+.B dedicated
+All components dedicated to this interface
+.TP
+.B all
+All components used by this interface, even if shared
+.RE
 .SH BUGS
 Not supported (in part or whole) on all network drivers.
 .SH AUTHOR
@@ -1023,7 +1087,8 @@ Andi Kleen,
 Alexander Duyck,
 Sucheta Chakraborty,
 Jesse Brandeburg,
-Ben Hutchings.
+Ben Hutchings,
+Scott Branden.
 .SH AVAILABILITY
 .B ethtool
 is available from
diff --git a/ethtool.c b/ethtool.c
index c89b660..09bcf91 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4636,6 +4636,97 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
return err;
 }
 
+static __u32 parse_reset(char *val, __u32 bitset, char *arg, __u32 *data)
+{
+   __u32 bitval = 0;
+   int i;
+
+   /* Check for component match */
+   for (i = 0; val[i] != '\0'; i++)
+   if (arg[i] != val[i])
+   return 0;
+
+   /* Check if component has -shared specified or not */
+   if (arg[i] == '\0')
+   bitval = bitset;
+   else if (!strcmp(arg+i, "-shared"))
+   bitval = bitset << ETH_RESET_SHARED_SHIFT;
+
+   if (bitval) {
+   *data |= bitval;
+   return 1;
+   }
+   return 0;
+}
+
+static int do_reset(struct cmd_context *ctx)
+{
+   struct ethtool_value resetinfo;
+   __u32 data;
+   int argc = ctx->argc;
+   char **argp = ctx->argp;
+   int i;
+
+   if (argc == 0)
+   exit_bad_args();
+
+   data = 0;
+
+   for (i = 0; i < argc; i++) {
+   if (!strcmp(argp[i], "flags")) {
+   __u32 flags;
+
+   i++;
+   if (i >= argc)
+   exit_bad_args();
+   flags = strtoul(argp[i], NULL, 0);
+   if (flags == 0)
+   exit_bad_args();
+   else
+   data |= flags;
+   } else if (parse_reset("mgmt", ETH_RESET_MGMT,
+ argp[i], )) {
+   } else if (parse_reset("irq",  ETH_RESET_IRQ,
+   argp[i], )) {
+   } else if (parse_reset("dma", ETH_RESET_DMA,
+   argp[i], )) {
+   } else if (parse_reset("filter", ETH_RESET_FILTER,
+   argp[i], )) {
+   } else if (parse_reset("offload", ETH_RESET_OFFLOAD,
+   argp[i], )) {
+   } else if (parse_reset("mac", ETH_RESET_MAC,
+   argp[i], )) {
+   } else if (parse_reset("phy", ETH_RESET_PHY,
+   argp[i], )) {
+   } else if (parse_reset("ram", ETH_RESET_RAM,
+   argp[i], )) {
+   } else if (p

[PATCH v3 2/3] ethtool-copy.h: sync with net-next

2017-12-12 Thread Scott Branden

This covers kernel changes up to:

commit 40e44a1e669d078946f46853808a60d29e6f0885
Author: Scott Branden <scott.bran...@broadcom.com>
Date:   Thu Nov 30 11:35:59 2017 -0800

net: ethtool: add support for reset of AP inside NIC interface.

Add ETH_RESET_AP to reset the application processor(s) inside the NIC
interface.

Current ETH_RESET_MGMT supports a management processor inside this NIC.
This is typically used for remote NIC management purposes.

Application processors exist inside some SmartNICs to run various
applications inside the NIC processor - be it a simple algorithm without
an OS to as complex as hosting multiple VMs.

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: David S. Miller <da...@davemloft.net>

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
 ethtool-copy.h | 66 +-
 1 file changed, 61 insertions(+), 5 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index 06fc04c..f4e7bb2 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
 /*
  * ethtool.h: Defines for Linux ethtool.
  *
@@ -1236,6 +1237,47 @@ struct ethtool_per_queue_op {
chardata[];
 };
 
+/**
+ * struct ethtool_fecparam - Ethernet forward error correction(fec) parameters
+ * @cmd: Command number = %ETHTOOL_GFECPARAM or %ETHTOOL_SFECPARAM
+ * @active_fec: FEC mode which is active on porte
+ * @fec: Bitmask of supported/configured FEC modes
+ * @rsvd: Reserved for future extensions. i.e FEC bypass feature.
+ *
+ * Drivers should reject a non-zero setting of @autoneg when
+ * autoneogotiation is disabled (or not supported) for the link.
+ *
+ */
+struct ethtool_fecparam {
+   __u32   cmd;
+   /* bitmask of FEC modes */
+   __u32   active_fec;
+   __u32   fec;
+   __u32   reserved;
+};
+
+/**
+ * enum ethtool_fec_config_bits - flags definition of ethtool_fec_configuration
+ * @ETHTOOL_FEC_NONE: FEC mode configuration is not supported
+ * @ETHTOOL_FEC_AUTO: Default/Best FEC mode provided by driver
+ * @ETHTOOL_FEC_OFF: No FEC Mode
+ * @ETHTOOL_FEC_RS: Reed-Solomon Forward Error Detection mode
+ * @ETHTOOL_FEC_BASER: Base-R/Reed-Solomon Forward Error Detection mode
+ */
+enum ethtool_fec_config_bits {
+   ETHTOOL_FEC_NONE_BIT,
+   ETHTOOL_FEC_AUTO_BIT,
+   ETHTOOL_FEC_OFF_BIT,
+   ETHTOOL_FEC_RS_BIT,
+   ETHTOOL_FEC_BASER_BIT,
+};
+
+#define ETHTOOL_FEC_NONE   (1 << ETHTOOL_FEC_NONE_BIT)
+#define ETHTOOL_FEC_AUTO   (1 << ETHTOOL_FEC_AUTO_BIT)
+#define ETHTOOL_FEC_OFF(1 << ETHTOOL_FEC_OFF_BIT)
+#define ETHTOOL_FEC_RS (1 << ETHTOOL_FEC_RS_BIT)
+#define ETHTOOL_FEC_BASER  (1 << ETHTOOL_FEC_BASER_BIT)
+
 /* CMDs currently supported */
 #define ETHTOOL_GSET   0x0001 /* DEPRECATED, Get settings.
* Please use ETHTOOL_GLINKSETTINGS
@@ -1328,6 +1370,8 @@ struct ethtool_per_queue_op {
 #define ETHTOOL_SLINKSETTINGS  0x004d /* Set ethtool_link_settings */
 #define ETHTOOL_PHY_GTUNABLE   0x004e /* Get PHY tunable configuration */
 #define ETHTOOL_PHY_STUNABLE   0x004f /* Set PHY tunable configuration */
+#define ETHTOOL_GFECPARAM  0x0050 /* Get FEC settings */
+#define ETHTOOL_SFECPARAM  0x0051 /* Set FEC settings */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET ETHTOOL_GSET
@@ -1382,9 +1426,12 @@ enum ethtool_link_mode_bit_indices {
ETHTOOL_LINK_MODE_1baseLR_Full_BIT  = 44,
ETHTOOL_LINK_MODE_1baseLRM_Full_BIT = 45,
ETHTOOL_LINK_MODE_1baseER_Full_BIT  = 46,
-   ETHTOOL_LINK_MODE_2500baseT_Full_BIT = 47,
-   ETHTOOL_LINK_MODE_5000baseT_Full_BIT = 48,
+   ETHTOOL_LINK_MODE_2500baseT_Full_BIT= 47,
+   ETHTOOL_LINK_MODE_5000baseT_Full_BIT= 48,
 
+   ETHTOOL_LINK_MODE_FEC_NONE_BIT  = 49,
+   ETHTOOL_LINK_MODE_FEC_RS_BIT= 50,
+   ETHTOOL_LINK_MODE_FEC_BASER_BIT = 51,
 
/* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
 * 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
@@ -1393,7 +1440,7 @@ enum ethtool_link_mode_bit_indices {
 */
 
__ETHTOOL_LINK_MODE_LAST
- = ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ = ETHTOOL_LINK_MODE_FEC_BASER_BIT,
 };
 
 #define __ETHTOOL_LINK_MODE_LEGACY_MASK(base_name) \
@@ -1484,13 +1531,17 @@ enum ethtool_link_mode_bit_indices {
  * it was forced up into this mode or autonegotiated.
  */
 
-/* The forced speed, in units of 1Mb. All values 0 to INT_MAX are legal. */
+/* The forced speed, in units of 1Mb. All values 0 to INT_MAX are legal.
+ * Update drivers/net/phy/phy.c:phy_speed_to_str() and
+ * drivers/net/bonding/bond_3a

[PATCH v3 1/3] Revert "ethtool: Add DMA Coalescing support"

2017-12-12 Thread Scott Branden

This reverts commit 5dd7bfbc5079cb375876e4e76191263fc28ae1a6.

As Stephen Hemminger mentioned
there is an ABI compatibility issue with this patch:

https://patchwork.ozlabs.org/patch/806049/#1757846
Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
 ethtool-copy.h | 2 --
 ethtool.8.in   | 1 -
 ethtool.c  | 8 +---
 3 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index 4bb91eb..06fc04c 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -400,7 +400,6 @@ struct ethtool_modinfo {
  * a TX interrupt, when the packet rate is above @pkt_rate_high.
  * @rate_sample_interval: How often to do adaptive coalescing packet rate
  * sampling, measured in seconds.  Must not be zero.
- * @dmac: How many usecs to store packets before moving to host memory.
  *
  * Each pair of (usecs, max_frames) fields specifies that interrupts
  * should be coalesced until
@@ -451,7 +450,6 @@ struct ethtool_coalesce {
__u32   tx_coalesce_usecs_high;
__u32   tx_max_coalesced_frames_high;
__u32   rate_sample_interval;
-   __u32   dmac;
 };
 
 /**
diff --git a/ethtool.8.in b/ethtool.8.in
index 6ad3065..90ead41 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -165,7 +165,6 @@ ethtool \- query or control network driver and hardware 
settings
 .BN tx\-usecs\-high
 .BN tx\-frames\-high
 .BN sample\-interval
-.BN dmac
 .HP
 .B ethtool \-g|\-\-show\-ring
 .I devname
diff --git a/ethtool.c b/ethtool.c
index 1a2b7cc..c89b660 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1337,7 +1337,6 @@ static int dump_coalesce(const struct ethtool_coalesce 
*ecoal)
"sample-interval: %u\n"
"pkt-rate-low: %u\n"
"pkt-rate-high: %u\n"
-   "dmac: %u\n"
"\n"
"rx-usecs: %u\n"
"rx-frames: %u\n"
@@ -1363,7 +1362,6 @@ static int dump_coalesce(const struct ethtool_coalesce 
*ecoal)
ecoal->rate_sample_interval,
ecoal->pkt_rate_low,
ecoal->pkt_rate_high,
-   ecoal->dmac,
 
ecoal->rx_coalesce_usecs,
ecoal->rx_max_coalesced_frames,
@@ -2071,7 +2069,6 @@ static int do_scoalesce(struct cmd_context *ctx)
int coal_adaptive_rx_wanted = -1;
int coal_adaptive_tx_wanted = -1;
s32 coal_sample_rate_wanted = -1;
-   s32 coal_dmac_wanted = -1;
s32 coal_pkt_rate_low_wanted = -1;
s32 coal_pkt_rate_high_wanted = -1;
s32 coal_rx_usec_wanted = -1;
@@ -2097,8 +2094,6 @@ static int do_scoalesce(struct cmd_context *ctx)
  _adaptive_tx_coalesce },
{ "sample-interval", CMDL_S32, _sample_rate_wanted,
  _sample_interval },
-   { "dmac", CMDL_S32, _dmac_wanted,
-  },
{ "stats-block-usecs", CMDL_S32, _stats_wanted,
  _block_coalesce_usecs },
{ "pkt-rate-low", CMDL_S32, _pkt_rate_low_wanted,
@@ -4794,8 +4789,7 @@ static const struct option {
  " [rx-frames-high N]\n"
  " [tx-usecs-high N]\n"
  " [tx-frames-high N]\n"
- " [sample-interval N]\n"
- " [dmac N]\n" },
+ " [sample-interval N]\n" },
{ "-g|--show-ring", 1, do_gring, "Query RX/TX ring parameters" },
{ "-G|--set-ring", 1, do_sring, "Set RX/TX ring parameters",
  " [ rx N ]\n"
-- 
2.5.0

[PATCH v3 0/3] ethtool: add ETHTOOL_RESET support via --reset command

2017-12-12 Thread Scott Branden

Patch series to add ETHTOOL_RESET support to ethtool userspace tool.
Include:
- revert custom change to ethtool-copy.h that is not in linux kernel
- sync ethtool-copy.h with ethtool.h in linux kernel net-next
- add ETHTOOL_RESET support with up to date ethtool.h reset defines

Changes from v2:
 - update commit message to indicate support for ap
 - add symbolic support for parsing of -shared added to each component specified
 - cleaned up reset print information to indicate which components have and 
have not been reset

Scott Branden (3):
  Revert "ethtool: Add DMA Coalescing support"
  ethtool-copy.h: sync with net-next
  ethtool: Add ETHTOOL_RESET support via --reset command

 ethtool-copy.h |  68 
 ethtool.8.in   |  68 +++-
 ethtool.c  | 121 +
 3 files changed, 241 insertions(+), 16 deletions(-)

-- 
2.5.0

Re: [PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

2017-12-05 Thread Scott Branden


Hi Michal,

Thanks - one question below hopefully someone can help with.


On 17-12-05 02:29 PM, Michal Kubecek wrote:

On Tue, Dec 05, 2017 at 02:06:09PM -0800, Scott Branden wrote:

On 17-12-05 01:30 PM, Michal Kubecek wrote:

On Tue, Dec 05, 2017 at 12:53:23PM -0800, Scott Branden wrote:

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,dedicated,all

Alternatively, you can specific component bitfield directly using
ethtool --reset DEVNAME flags %x

IMHO it would be more consistent with e.g. msglvl without the keyword
"flags".

I don't see the consistency in ethtool of specifying a number without a
keyword in front of it.
I can only find --set-dump specify a number?
Others have keyword and number.  msglvl is the keyword after specifying -s -
same as flags is the keyword I use after specifying --reset.

What I meant is that you can write

 ethtool -s eth0 msglvl drv on probe off
 ethtool -s eth0 msglvl 0x7

i.e. either number or names (with on/off in this case) while your patch
has

 ethtool --reset eth0 mgmg,irq
 ethtool --reset eth0 flags 0x3

i.e. an extra keyword if a number is used.

But it's not really important, it doesn't seem I would be able to share
a parser for this with any other subcommand or parameter anyway.


   It would be also nice to provide a symbolic way to specify the
shared flags.

I'll change to allow -shared to be added to the end of each component
specified to use the shared bit.
  IE. mgmt-shared, irq-shared, dma-shared ?

Sounds good to me.


+   resetinfo.cmd = ETHTOOL_RESET;
+
+   if (send_ioctl(ctx, )) {
+   perror("Cannot issue RESET");
+   return 1;
+   }
+   fprintf(stdout, "RESET 0x%x issued\n", resetinfo.data);

According to documentation, driver is supposed to clear the flags
corresponding to components which were reset so that what is left are
those which were _not_ reset.

I'll move the print above the send_ioctl.

It might be even more useful if ethtool informed user what actually
happened, i.e. either change the message to saying these are bits for
components not reset (if resetinfo.data is not zero) or save the
original value of resetinfo.data and show  saved_data & ~resetinfo.data

In making the improvement I found a bug in the bnxt_en kernel driver.
The bnxt_en driver currently doesn't clear any of the component flags on 
success so I need to send in a fix for that.


Although in one case (RESET_ALL) in the driver it doesn't actually 
execute the reset until all necessary drivers are unloaded to prevent 
the PCIe bus from hanging.
So question: should the flags be cleared if the reset is "pending" but 
hasn't actually happened yet, but will reset once all the drivers are 
all properly unloaded?


Michal Kubecek

Re: [PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

2017-12-05 Thread Scott Branden


Hi Andrew,


On 17-12-05 02:26 PM, Andrew Lunn wrote:

On Tue, Dec 05, 2017 at 12:53:23PM -0800, Scott Branden wrote:

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,dedicated,all

Yes, I missed adding ap to the commit message here.

[Snip]


+.B ethtool \-\-reset
+.I devname
+.BN flags
+.RB [ mgmt ]
+.RB [ irq ]
+.RB [ dma ]
+.RB [ filter ]
+.RB [ offload ]
+.RB [ mac ]
+.RB [ phy ]
+.RB [ ram ]
+.RB [ ap ]
+.RB [ dedicated ]
+.RB [ all ]

Hi Scott

Just a nick pick. You don't list ap above, which is kind of why you
are doing this, if i remember correctly.
Yes - I added ap to v2 of this patch but didn't add it to the commit 
message. Will update in v3.


 Andrew

Re: [PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

2017-12-05 Thread Scott Branden


Hi Michal,

thanks for review - see comments

On 17-12-05 01:30 PM, Michal Kubecek wrote:

On Tue, Dec 05, 2017 at 12:53:23PM -0800, Scott Branden wrote:

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,dedicated,all

Alternatively, you can specific component bitfield directly using
ethtool --reset DEVNAME flags %x

IMHO it would be more consistent with e.g. msglvl without the keyword
"flags".
I don't see the consistency in ethtool of specifying a number without a 
keyword in front of it.

I can only find --set-dump specify a number?
Others have keyword and number.  msglvl is the keyword after specifying 
-s - same as flags is the keyword I use after specifying --reset.
Whichever convention is decided for the --reset command I will change 
the patch to though.



  It would be also nice to provide a symbolic way to specify the
shared flags.
I'll change to allow -shared to be added to the end of each component 
specified to use the shared bit.

 IE. mgmt-shared, irq-shared, dma-shared ?



+static int do_reset(struct cmd_context *ctx)
+{
+   struct ethtool_value resetinfo;
+   int argc = ctx->argc;
+   char **argp = ctx->argp;
+   int i;
+
+   if (argc == 0)
+   exit_bad_args();
+
+   resetinfo.data = 0;
+
+   for (i = 0; i < argc; i++) {
+   if (!strcmp(argp[i], "flags")) {
+   __u32 flags;
+
+   i++;
+   if (i >= argc)
+   exit_bad_args();
+   flags = strtoul(argp[i], NULL, 0);
+   if (flags == 0)
+   exit_bad_args();
+   else
+   resetinfo.data |= flags;
+   } else if (!strcmp(argp[i], "mgmt")) {
+   resetinfo.data |= ETH_RESET_MGMT;
+   } else if (!strcmp(argp[i], "irq")) {
+   resetinfo.data |= ETH_RESET_IRQ;
+   } else if (!strcmp(argp[i], "dma")) {
+   resetinfo.data |= ETH_RESET_DMA;
+   } else if (!strcmp(argp[i], "filter")) {
+   resetinfo.data |= ETH_RESET_FILTER;
+   } else if (!strcmp(argp[i], "offload")) {
+   resetinfo.data |= ETH_RESET_OFFLOAD;
+   } else if (!strcmp(argp[i], "mac")) {
+   resetinfo.data |= ETH_RESET_MAC;
+   } else if (!strcmp(argp[i], "phy")) {
+   resetinfo.data |= ETH_RESET_PHY;
+   } else if (!strcmp(argp[i], "ram")) {
+   resetinfo.data |= ETH_RESET_RAM;
+   } else if (!strcmp(argp[i], "ap")) {
+   resetinfo.data |= ETH_RESET_AP;
+   } else if (!strcmp(argp[i], "dedicated")) {
+   resetinfo.data |= ETH_RESET_DEDICATED;
+   } else if (!strcmp(argp[i], "all")) {
+   resetinfo.data |= ETH_RESET_ALL;
+   } else {
+   exit_bad_args();
+   }
+   }
+
+   resetinfo.cmd = ETHTOOL_RESET;
+
+   if (send_ioctl(ctx, )) {
+   perror("Cannot issue RESET");
+   return 1;
+   }
+   fprintf(stdout, "RESET 0x%x issued\n", resetinfo.data);

According to documentation, driver is supposed to clear the flags
corresponding to components which were reset so that what is left are
those which were _not_ reset.

I'll move the print above the send_ioctl.

Michal Kubecek

[PATCH v2 0/3] ethtool: add ETHTOOL_RESET support via --reset command

2017-12-05 Thread Scott Branden

Patch series to add ETHTOOL_RESET support to ethtool userspace tool.
Include:
- revert custom change to ethtool-copy.h that is not in linux kernel
- sync ethtool-copy.h with ethtool.h in linux kernel net-next
- add ETHTOOL_RESET support with up to date ethtool.h reset defines

Scott Branden (3):
  Revert "ethtool: Add DMA Coalescing support"
  ethtool-copy.h: sync with net-next
  ethtool: Add ETHTOOL_RESET support via --reset command

 ethtool-copy.h | 68 ++-
 ethtool.8.in   | 59 +++--
 ethtool.c  | 83 +-
 3 files changed, 194 insertions(+), 16 deletions(-)

-- 
2.5.0

[PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

2017-12-05 Thread Scott Branden

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,dedicated,all

Alternatively, you can specific component bitfield directly using
ethtool --reset DEVNAME flags %x

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
 ethtool.8.in | 58 +-
 ethtool.c| 75 
 2 files changed, 132 insertions(+), 1 deletion(-)

diff --git a/ethtool.8.in b/ethtool.8.in
index 90ead41..e77ecd3 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -354,6 +354,21 @@ ethtool \- query or control network driver and hardware 
settings
 .B ethtool \-\-get\-phy\-tunable
 .I devname
 .RB [ downshift ]
+.HP
+.B ethtool \-\-reset
+.I devname
+.BN flags
+.RB [ mgmt ]
+.RB [ irq ]
+.RB [ dma ]
+.RB [ filter ]
+.RB [ offload ]
+.RB [ mac ]
+.RB [ phy ]
+.RB [ ram ]
+.RB [ ap ]
+.RB [ dedicated ]
+.RB [ all ]
 .
 .\" Adjust lines (i.e. full justification) and hyphenate.
 .ad
@@ -1006,6 +1021,46 @@ Downshift is useful where cable does not have the 4 
pairs instance.
 
 Gets the PHY downshift count/status.
 .RE
+.TP
+.B \-\-reset
+Reset hardware components specified by flags and components listed below
+.RS 4
+.TP
+.BI flags \ N
+Resets the components based on direct flags mask
+.TP
+.B mgmt
+Management processor
+.TP
+.B irq
+Interrupt requester
+.TP
+.B dma
+DMA engine
+.TP
+.B filter
+Filtering/flow direction
+.TP
+.B offload
+Protocol offload
+.TP
+.B mac
+Media access controller
+.TP
+.B phy
+Transceiver/PHY
+.TP
+.B ram
+RAM shared between multiple components
+.B ap
+Application Processor
+.TP
+.B dedicated
+All components dedicated to this interface
+.TP
+.B all
+All components used by this interface, even if shared
+.RE
 .SH BUGS
 Not supported (in part or whole) on all network drivers.
 .SH AUTHOR
@@ -1023,7 +1078,8 @@ Andi Kleen,
 Alexander Duyck,
 Sucheta Chakraborty,
 Jesse Brandeburg,
-Ben Hutchings.
+Ben Hutchings,
+Scott Branden.
 .SH AVAILABILITY
 .B ethtool
 is available from
diff --git a/ethtool.c b/ethtool.c
index c89b660..5bcf5d2 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4636,6 +4636,68 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
return err;
 }
 
+static int do_reset(struct cmd_context *ctx)
+{
+   struct ethtool_value resetinfo;
+   int argc = ctx->argc;
+   char **argp = ctx->argp;
+   int i;
+
+   if (argc == 0)
+   exit_bad_args();
+
+   resetinfo.data = 0;
+
+   for (i = 0; i < argc; i++) {
+   if (!strcmp(argp[i], "flags")) {
+   __u32 flags;
+
+   i++;
+   if (i >= argc)
+   exit_bad_args();
+   flags = strtoul(argp[i], NULL, 0);
+   if (flags == 0)
+   exit_bad_args();
+   else
+   resetinfo.data |= flags;
+   } else if (!strcmp(argp[i], "mgmt")) {
+   resetinfo.data |= ETH_RESET_MGMT;
+   } else if (!strcmp(argp[i], "irq")) {
+   resetinfo.data |= ETH_RESET_IRQ;
+   } else if (!strcmp(argp[i], "dma")) {
+   resetinfo.data |= ETH_RESET_DMA;
+   } else if (!strcmp(argp[i], "filter")) {
+   resetinfo.data |= ETH_RESET_FILTER;
+   } else if (!strcmp(argp[i], "offload")) {
+   resetinfo.data |= ETH_RESET_OFFLOAD;
+   } else if (!strcmp(argp[i], "mac")) {
+   resetinfo.data |= ETH_RESET_MAC;
+   } else if (!strcmp(argp[i], "phy")) {
+   resetinfo.data |= ETH_RESET_PHY;
+   } else if (!strcmp(argp[i], "ram")) {
+   resetinfo.data |= ETH_RESET_RAM;
+   } else if (!strcmp(argp[i], "ap")) {
+   resetinfo.data |= ETH_RESET_AP;
+   } else if (!strcmp(argp[i], "dedicated")) {
+   resetinfo.data |= ETH_RESET_DEDICATED;
+   } else if (!strcmp(argp[i], "all")) {
+   resetinfo.data |= ETH_RESET_ALL;
+   } else {
+   exit_bad_args();
+   }
+   }
+
+   resetinfo.cmd = ETHTOOL_RESET;
+
+   if (send_ioctl(ctx, )) {
+   perror("Cannot issue RESET");
+   return 1;
+   }
+   fprintf(stdout, "RESET 0x%x issued\n", resetinfo.data);
+
+   return 0;
+}
+
 static int parse_named_bool(struct cmd_context *ctx, const char *name, u8 *on)
 {
if (ctx->argc < 2)
@@ -4898,6 +4960,19 @@ static const struct option

[PATCH v2 2/3] ethtool-copy.h: sync with net-next

2017-12-05 Thread Scott Branden

This covers kernel changes up to:

commit 40e44a1e669d078946f46853808a60d29e6f0885
Author: Scott Branden <scott.bran...@broadcom.com>
Date:   Thu Nov 30 11:35:59 2017 -0800

net: ethtool: add support for reset of AP inside NIC interface.

Add ETH_RESET_AP to reset the application processor(s) inside the NIC
interface.

Current ETH_RESET_MGMT supports a management processor inside this NIC.
This is typically used for remote NIC management purposes.

Application processors exist inside some SmartNICs to run various
applications inside the NIC processor - be it a simple algorithm without
an OS to as complex as hosting multiple VMs.

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: David S. Miller <da...@davemloft.net>

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
 ethtool-copy.h | 66 +-
 1 file changed, 61 insertions(+), 5 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index 06fc04c..f4e7bb2 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
 /*
  * ethtool.h: Defines for Linux ethtool.
  *
@@ -1236,6 +1237,47 @@ struct ethtool_per_queue_op {
chardata[];
 };
 
+/**
+ * struct ethtool_fecparam - Ethernet forward error correction(fec) parameters
+ * @cmd: Command number = %ETHTOOL_GFECPARAM or %ETHTOOL_SFECPARAM
+ * @active_fec: FEC mode which is active on porte
+ * @fec: Bitmask of supported/configured FEC modes
+ * @rsvd: Reserved for future extensions. i.e FEC bypass feature.
+ *
+ * Drivers should reject a non-zero setting of @autoneg when
+ * autoneogotiation is disabled (or not supported) for the link.
+ *
+ */
+struct ethtool_fecparam {
+   __u32   cmd;
+   /* bitmask of FEC modes */
+   __u32   active_fec;
+   __u32   fec;
+   __u32   reserved;
+};
+
+/**
+ * enum ethtool_fec_config_bits - flags definition of ethtool_fec_configuration
+ * @ETHTOOL_FEC_NONE: FEC mode configuration is not supported
+ * @ETHTOOL_FEC_AUTO: Default/Best FEC mode provided by driver
+ * @ETHTOOL_FEC_OFF: No FEC Mode
+ * @ETHTOOL_FEC_RS: Reed-Solomon Forward Error Detection mode
+ * @ETHTOOL_FEC_BASER: Base-R/Reed-Solomon Forward Error Detection mode
+ */
+enum ethtool_fec_config_bits {
+   ETHTOOL_FEC_NONE_BIT,
+   ETHTOOL_FEC_AUTO_BIT,
+   ETHTOOL_FEC_OFF_BIT,
+   ETHTOOL_FEC_RS_BIT,
+   ETHTOOL_FEC_BASER_BIT,
+};
+
+#define ETHTOOL_FEC_NONE   (1 << ETHTOOL_FEC_NONE_BIT)
+#define ETHTOOL_FEC_AUTO   (1 << ETHTOOL_FEC_AUTO_BIT)
+#define ETHTOOL_FEC_OFF(1 << ETHTOOL_FEC_OFF_BIT)
+#define ETHTOOL_FEC_RS (1 << ETHTOOL_FEC_RS_BIT)
+#define ETHTOOL_FEC_BASER  (1 << ETHTOOL_FEC_BASER_BIT)
+
 /* CMDs currently supported */
 #define ETHTOOL_GSET   0x0001 /* DEPRECATED, Get settings.
* Please use ETHTOOL_GLINKSETTINGS
@@ -1328,6 +1370,8 @@ struct ethtool_per_queue_op {
 #define ETHTOOL_SLINKSETTINGS  0x004d /* Set ethtool_link_settings */
 #define ETHTOOL_PHY_GTUNABLE   0x004e /* Get PHY tunable configuration */
 #define ETHTOOL_PHY_STUNABLE   0x004f /* Set PHY tunable configuration */
+#define ETHTOOL_GFECPARAM  0x0050 /* Get FEC settings */
+#define ETHTOOL_SFECPARAM  0x0051 /* Set FEC settings */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET ETHTOOL_GSET
@@ -1382,9 +1426,12 @@ enum ethtool_link_mode_bit_indices {
ETHTOOL_LINK_MODE_1baseLR_Full_BIT  = 44,
ETHTOOL_LINK_MODE_1baseLRM_Full_BIT = 45,
ETHTOOL_LINK_MODE_1baseER_Full_BIT  = 46,
-   ETHTOOL_LINK_MODE_2500baseT_Full_BIT = 47,
-   ETHTOOL_LINK_MODE_5000baseT_Full_BIT = 48,
+   ETHTOOL_LINK_MODE_2500baseT_Full_BIT= 47,
+   ETHTOOL_LINK_MODE_5000baseT_Full_BIT= 48,
 
+   ETHTOOL_LINK_MODE_FEC_NONE_BIT  = 49,
+   ETHTOOL_LINK_MODE_FEC_RS_BIT= 50,
+   ETHTOOL_LINK_MODE_FEC_BASER_BIT = 51,
 
/* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
 * 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
@@ -1393,7 +1440,7 @@ enum ethtool_link_mode_bit_indices {
 */
 
__ETHTOOL_LINK_MODE_LAST
- = ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ = ETHTOOL_LINK_MODE_FEC_BASER_BIT,
 };
 
 #define __ETHTOOL_LINK_MODE_LEGACY_MASK(base_name) \
@@ -1484,13 +1531,17 @@ enum ethtool_link_mode_bit_indices {
  * it was forced up into this mode or autonegotiated.
  */
 
-/* The forced speed, in units of 1Mb. All values 0 to INT_MAX are legal. */
+/* The forced speed, in units of 1Mb. All values 0 to INT_MAX are legal.
+ * Update drivers/net/phy/phy.c:phy_speed_to_str() and
+ * drivers/net/bonding/bond_3a

Re: ethtool-copy.h out of sync with linux header file?

2017-12-05 Thread Scott Branden


Hi Paul,


On 17-12-04 01:00 PM, Greenwalt, Paul wrote:

John,

Can this patch be reverted? As Stephen Hemminger mentioned
there is an ABI compatibility issue with this patch:
I can add the revert into a patch series followed by the sync of 
ethtool-copy.h with net-netx ethtool.h


https://patchwork.ozlabs.org/patch/806049/#1757846

Thanks,
Paul


-Original Message-
From: Scott Branden [mailto:scott.bran...@broadcom.com]
Sent: Monday, December 4, 2017 12:07 PM
To: linvi...@tuxdriver.com; Greenwalt, Paul <paul.greenw...@intel.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: ethtool-copy.h out of sync with linux header file?

Hi Paul/John,

I see a commit "ethtool: Add DMA Coalescing support" was added to
ethtool-copy.h yet I cannot find the change in the ethtool.h in the
linux kernel.

As such, I am unable to commit a change to ethtool-copy.h to sync it
with net-next.  If I sync then ethtool will fail to compile.

Please advise.

Thanks,

   Scott

Re: [PATCH] ethtool: Add ETHTOOL_RESET support via --reset command

2017-12-05 Thread Scott Branden




On 17-12-05 12:21 AM, Gal Pressman wrote:

On 04-Dec-17 22:16, Scott Branden wrote:

Hi Gal,

I do not understand you're comment - questions inline


On 17-12-03 12:07 AM, Gal Pressman wrote:

On 30-Nov-17 21:24, Scott Branden wrote:

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,dedicated,all

Alternatively, you can specific component bitfield directly using
ethtool --reset DEVNAME flags %x

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
   ethtool.8.in | 55 -
   ethtool.c    | 73 

   2 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/ethtool.8.in b/ethtool.8.in
index 6ad3065..925cfe3 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -355,6 +355,20 @@ ethtool \- query or control network driver and hardware 
settings
   .B ethtool \-\-get\-phy\-tunable
   .I devname
   .RB [ downshift ]
+.HP
+.B ethtool \-\-reset
+.I devname
+.BN flags
+.B [mgmt]
+.B [irq]
+.B [dma]
+.B [filter]
+.B [offload]
+.B [mac]
+.B [phy]
+.B [ram]
+.B [dedicated]
+.B [all]
   .

Nit:
Usually, the brackets formatting is different than the keyword inside them.

Could you please explain what the formatting should be then?  Any of the 
options listed are possible components that can be selected.  At least one must 
be chosen.  Should the brackets be removed then?

The brackets are fine, IMO .B [mgmt] should be replaced with .RB [ mgmt ].
Looks better, and keeps us consistent with other flags (--get-phy-tunable for 
example).

OK - I'll update.  Thanks.

Re: [PATCH] ethtool: Add ETHTOOL_RESET support via --reset command

2017-12-04 Thread Scott Branden


Hi Gal,

I do not understand you're comment - questions inline


On 17-12-03 12:07 AM, Gal Pressman wrote:

On 30-Nov-17 21:24, Scott Branden wrote:

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,dedicated,all

Alternatively, you can specific component bitfield directly using
ethtool --reset DEVNAME flags %x

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
  ethtool.8.in | 55 -
  ethtool.c| 73 
  2 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/ethtool.8.in b/ethtool.8.in
index 6ad3065..925cfe3 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -355,6 +355,20 @@ ethtool \- query or control network driver and hardware 
settings
  .B ethtool \-\-get\-phy\-tunable
  .I devname
  .RB [ downshift ]
+.HP
+.B ethtool \-\-reset
+.I devname
+.BN flags
+.B [mgmt]
+.B [irq]
+.B [dma]
+.B [filter]
+.B [offload]
+.B [mac]
+.B [phy]
+.B [ram]
+.B [dedicated]
+.B [all]
  .

Nit:
Usually, the brackets formatting is different than the keyword inside them.
Could you please explain what the formatting should be then?  Any of the 
options listed are possible components that can be selected.  At least 
one must be chosen.  Should the brackets be removed then?


Gal

ethtool-copy.h out of sync with linux header file?

2017-12-04 Thread Scott Branden


Hi Paul/John,

I see a commit "ethtool: Add DMA Coalescing support" was added to 
ethtool-copy.h yet I cannot find the change in the ethtool.h in the 
linux kernel.


As such, I am unable to commit a change to ethtool-copy.h to sync it 
with net-next.  If I sync then ethtool will fail to compile.


Please advise.

Thanks,

 Scott

[PATCH 0/2] net: ethtool: add support for ETH_RESET_AP

2017-11-30 Thread Scott Branden

Add support to reset appplication processors inside SmartNICs by
defining new ETH_RESET_AP bit.

And use new ETH_RESET_AP bit in bnxt ethernet driver.

Scott Branden (2):
  net: ethtool: add support for reset of AP inside NIC interface.
  bnxt_en: Add ETH_RESET_AP support

 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 11 +++
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h |  1 +
 include/uapi/linux/ethtool.h  |  1 +
 3 files changed, 13 insertions(+)

-- 
2.5.0

[PATCH 1/2] net: ethtool: add support for reset of AP inside NIC interface.

2017-11-30 Thread Scott Branden

Add ETH_RESET_AP to reset the application processor(s) inside the NIC
interface.

Current ETH_RESET_MGMT supports a management processor inside this NIC.
This is typically used for remote NIC management purposes.

Application processors exist inside some SmartNICs to run various
applications inside the NIC processor - be it a simple algorithm without
an OS to as complex as hosting multiple VMs.

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
Reviewed-by: Andrew Lunn <and...@lunn.ch>
---
 include/uapi/linux/ethtool.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index ac71559..44a0b67 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1686,6 +1686,7 @@ enum ethtool_reset_flags {
ETH_RESET_PHY   = 1 << 6,   /* Transceiver/PHY */
ETH_RESET_RAM   = 1 << 7,   /* RAM shared between
 * multiple components */
+   ETH_RESET_AP= 1 << 8,   /* Application processor */
 
ETH_RESET_DEDICATED = 0x,   /* All components dedicated to
 * this interface */
-- 
2.5.0

[PATCH 2/2] bnxt_en: Add ETH_RESET_AP support

2017-11-30 Thread Scott Branden

Add ETH_RESET_AP support handling to reset the internal
Application Processor(s) of the SmartNIC card.

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 11 +++
 drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index 7ce1d4b..fc2c483 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -1376,6 +1376,9 @@ static int bnxt_firmware_reset(struct net_device *dev,
req.embedded_proc_type = FW_RESET_REQ_EMBEDDED_PROC_TYPE_CHIP;
req.selfrst_status = FW_RESET_REQ_SELFRST_STATUS_SELFRSTASAP;
break;
+   case BNXT_FW_RESET_AP:
+   req.embedded_proc_type = FW_RESET_REQ_EMBEDDED_PROC_TYPE_AP;
+   break;
default:
return -EINVAL;
}
@@ -2522,6 +2525,14 @@ static int bnxt_reset(struct net_device *dev, u32 *flags)
rc = bnxt_firmware_reset(dev, BNXT_FW_RESET_CHIP);
if (!rc)
netdev_info(dev, "Reset request successful. Reload 
driver to complete reset\n");
+   } else if (*flags == ETH_RESET_AP) {
+   /* This feature is not supported in older firmware versions */
+   if (bp->hwrm_spec_code < 0x10803)
+   return -EOPNOTSUPP;
+
+   rc = bnxt_firmware_reset(dev, BNXT_FW_RESET_AP);
+   if (!rc)
+   netdev_info(dev, "Reset Application Processor request 
successful.\n");
} else {
rc = -EINVAL;
}
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h 
b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h
index ff601b4..836ef68 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.h
@@ -34,6 +34,7 @@ struct bnxt_led_cfg {
 #define BNXT_LED_DFLT_ENABLES(x)   \
cpu_to_le32(BNXT_LED_DFLT_ENA << (BNXT_LED_DFLT_ENA_SHIFT * (x)))
 
+#define BNXT_FW_RESET_AP   0xfffe
 #define BNXT_FW_RESET_CHIP 0x
 
 extern const struct ethtool_ops bnxt_ethtool_ops;
-- 
2.5.0

[PATCH] ethtool: Add ETHTOOL_RESET support via --reset command

2017-11-30 Thread Scott Branden

Add ETHTOOL_RESET support via --reset command.

ie.  ethtool --reset DEVNAME <flagname(s)>

flagnames currently match the ETH_RESET_xxx names:
mgmt,irq,dma,filter,offload,mac,phy,ram,dedicated,all

Alternatively, you can specific component bitfield directly using
ethtool --reset DEVNAME flags %x

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
 ethtool.8.in | 55 -
 ethtool.c| 73 
 2 files changed, 127 insertions(+), 1 deletion(-)

diff --git a/ethtool.8.in b/ethtool.8.in
index 6ad3065..925cfe3 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -355,6 +355,20 @@ ethtool \- query or control network driver and hardware 
settings
 .B ethtool \-\-get\-phy\-tunable
 .I devname
 .RB [ downshift ]
+.HP
+.B ethtool \-\-reset
+.I devname
+.BN flags
+.B [mgmt]
+.B [irq]
+.B [dma]
+.B [filter]
+.B [offload]
+.B [mac]
+.B [phy]
+.B [ram]
+.B [dedicated]
+.B [all]
 .
 .\" Adjust lines (i.e. full justification) and hyphenate.
 .ad
@@ -1007,6 +1021,44 @@ Downshift is useful where cable does not have the 4 
pairs instance.
 
 Gets the PHY downshift count/status.
 .RE
+.TP
+.B \-\-reset
+Reset hardware components specified by flags and components listed below
+.RS 4
+.TP
+.BI flags \ N
+Resets the components based on direct flags mask
+.TP
+.B mgmt
+Management processor
+.TP
+.B irq
+Interrupt requester
+.TP
+.B dma
+DMA engine
+.TP
+.B filter
+Filtering/flow direction
+.TP
+.B offload
+Protocol offload
+.TP
+.B mac
+Media access controller
+.TP
+.B phy
+Transceiver/PHY
+.TP
+.B ram
+RAM shared between multiple components
+.TP
+.B dedicated
+All components dedicated to this interface
+.TP
+.B all
+All components used by this interface, even if shared
+.RE
 .SH BUGS
 Not supported (in part or whole) on all network drivers.
 .SH AUTHOR
@@ -1024,7 +1076,8 @@ Andi Kleen,
 Alexander Duyck,
 Sucheta Chakraborty,
 Jesse Brandeburg,
-Ben Hutchings.
+Ben Hutchings,
+Scott Branden.
 .SH AVAILABILITY
 .B ethtool
 is available from
diff --git a/ethtool.c b/ethtool.c
index 1a2b7cc..8c9d169 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4641,6 +4641,67 @@ static int do_get_phy_tunable(struct cmd_context *ctx)
return err;
 }
 
+static int do_reset(struct cmd_context *ctx)
+{
+   struct ethtool_value resetinfo;
+   int argc = ctx->argc;
+   char **argp = ctx->argp;
+   int i;
+
+   if (argc == 0)
+   exit_bad_args();
+
+   resetinfo.data = 0;
+
+   for (i = 0; i < argc; i++) {
+   if (!strcmp(argp[i], "flags")) {
+   __u32 flags;
+
+   i++;
+   if (i >= argc)
+   exit_bad_args();
+   flags = strtoul(argp[i], NULL, 0);
+   if (flags == 0)
+   exit_bad_args();
+   else
+   resetinfo.data |= flags;
+   } else if (!strcmp(argp[i], "mgmt")) {
+   resetinfo.data |= ETH_RESET_MGMT;
+   } else if (!strcmp(argp[i], "irq")) {
+   resetinfo.data |= ETH_RESET_IRQ;
+   } else if (!strcmp(argp[i], "dma")) {
+   resetinfo.data |= ETH_RESET_DMA;
+   } else if (!strcmp(argp[i], "filter")) {
+   resetinfo.data |= ETH_RESET_FILTER;
+   } else if (!strcmp(argp[i], "offload")) {
+   resetinfo.data |= ETH_RESET_OFFLOAD;
+   } else if (!strcmp(argp[i], "mac")) {
+   resetinfo.data |= ETH_RESET_MAC;
+   } else if (!strcmp(argp[i], "phy")) {
+   resetinfo.data |= ETH_RESET_PHY;
+   } else if (!strcmp(argp[i], "ram")) {
+   resetinfo.data |= ETH_RESET_RAM;
+   } else if (!strcmp(argp[i], "dedicated")) {
+   resetinfo.data |= ETH_RESET_DEDICATED;
+   } else if (!strcmp(argp[i], "all")) {
+   resetinfo.data |= ETH_RESET_ALL;
+   } else {
+   exit_bad_args();
+   }
+   }
+
+   resetinfo.cmd = ETHTOOL_RESET;
+
+   if (send_ioctl(ctx, )) {
+   perror("Cannot issue RESET");
+   return 1;
+   } else {
+   fprintf(stdout, "RESET 0x%x issued\n", resetinfo.data);
+   }
+
+   return 0;
+}
+
 static int parse_named_bool(struct cmd_context *ctx, const char *name, u8 *on)
 {
if (ctx->argc < 2)
@@ -4904,6 +4965,18 @@ static const struct option {
  " [ downshift on|off [count N] ]\n"},
{ "--get-phy-tunable", 1, do_get_phy_tunable, "Get PHY tunable",
  &

Re: [PATCH 1/1] net: ethtool: add support for reset of AP inside NIC interface.

2017-10-18 Thread Scott Branden


+netdev@vger.kernel.org


On 17-10-18 09:01 AM, Scott Branden wrote:

Add ETH_RESET_AP to reset the application processor inside the NIC
interface.

Signed-off-by: Scott Branden <scott.bran...@broadcom.com>
---
  include/uapi/linux/ethtool.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 5bd1b1d..f927ab7 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1685,6 +1685,7 @@ enum ethtool_reset_flags {
ETH_RESET_PHY   = 1 << 6, /* Transceiver/PHY */
ETH_RESET_RAM   = 1 << 7, /* RAM shared between
 * multiple components */
+   ETH_RESET_AP= 1 << 8, /* Application processor */
  
  	ETH_RESET_DEDICATED	= 0x,	/* All components dedicated to

 * this interface */

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

2017-10-18 Thread Scott Branden


+netdev@vger.kernel.org


On 17-10-18 02:30 PM, Andy Gospodarek wrote:

On Wed, Oct 18, 2017 at 12:31:28PM -0700, Scott Branden wrote:

Hi Andrew,


On 17-10-18 12:16 PM, Andrew Lunn wrote:

Yes, there is also a management processor.

O.K.

Maybe it would be nice to add some more text to the commit message to
make this clear. Define what an application processor is, and how it
differs from a management processor. But othersize:

OK -will add more description to differentiate management processor vs.
application processor(s).

Reviewed-by: Andrew Lunn <and...@lunn.ch>

I assume you have another kernel patch to actually make use of this?
It is normal to post the user of a new API in the same series as the
API.

I actually wanted to get agreement that the bit define could be added to
ethtool before implementing it in driver.
If this direction approved we'll implement in driver and submit with this
patch series.

I just noticed that you did not also post this to netdev@vger.kernel.org.  I
suspect you are more likely to get review and acceptance if that list is cc'd.

I'm not positive that Linus will take networking patches off this list.


  Andrew

Thanks,
  Scott

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

2017-06-29 Thread Scott Branden


Hi Rob,


On 17-06-29 03:40 PM, Rob Herring wrote:

On Tue, Jun 27, 2017 at 12:10 AM, Scott Branden
<scott.bran...@broadcom.com> wrote:

Hi Rob/Florian,

Thanks for input but still don't see any need for SoC specific
compatible stings.  IP revision specific yes.


On 17-06-22 06:04 PM, Florian Fainelli wrote:

On 06/22/2017 05:42 PM, Scott Branden wrote:


On 17-06-21 08:19 PM, Rob Herring wrote:

On Tue, Jun 20, 2017 at 3:48 PM, Scott Branden
<scott.bran...@broadcom.com> wrote:

Hi Rob,


On 17-06-18 07:04 AM, Rob Herring wrote:

On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:

Add device tree binding documentation for the Broadcom DTE
PTP clock driver.

Signed-off-by: Arun Parameswaran <arun.parameswa...@broadcom.com>
---
 Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt | 13
+
 1 file changed, 13 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt

diff --git a/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
new file mode 100644
index 000..07590bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
@@ -0,0 +1,13 @@
+* Broadcom Digital Timing Engine(DTE) based PTP clock driver

Bindings describe h/w, not drivers.


+
+Required properties:
+- compatible: should be "brcm,ptp-dte"

Looks too generic. You need SoC specific compatible strings.

Rob, could you please help me understand the use of adding SoC specific
compatible strings.
I still don't get it.

It's my understanding that the SoC compatibility string is to future
proof
against bugs/incompatibilities
between different versions of the hardware block due to integration
issues
or any other reason.
You can then compare in your driver because the strings were already
used in
the dtb.

That would make sense if you can't already differentiate what SoC you
are
running on.
But the SoC is already specified in the root of the device tree in the
compatible string?
Why can't you just use of_machine_is_compatible inside your driver when
needed?

Use of of_machine_is_compatible in drivers will result in the same
mess we had with machine_is_X defines pre-DT. It practically
guarantees that you must update the driver for a new SoC (with
fallback compatibles you don't). Plus the matching logic for
of_machine_is_compatible is open coded logic in every driver which is
worse IMO than having a standard match table.

I don't understand what you mean by fallback compatible then.

Let's say I have 3 SoCs that each contain the same ip block.
You want us to add a fallback compatibility per SoC, is that correct?

I think Rob meant a fallback compatibility for the particular block.
E.g: brcm,iproc-ptp is the fallback compatible string, but in your
SoC-specific DTS, you would have at least:

compatible = "brcm,cygnus-ptp", "brcm,iproc-ptp";

Where cygnus-ptp is more specific than iproc-ptp

Then, if there is a workaround discovered in a particular SoC the driver
can be updated in the future without changing the dtb.

Then, the block gets added to a 4th SoC.
You want us to another new compatibility string for the new SoC?
If the new SoC has a bug then the driver has to be updated whether it is
in uses the fallback compatible or machine_is_compatible string.

There is no difference in amount of code added to a driver when a new
SoC is introduced into the system that has bugs that need to be handled
by the driver.

The difference is in your recommendation we need to go through all the
drivers used by the new SoC and add fallback compatibility strings.

Not really, the fallback is what the driver should be matching by
default (hence the name fallback) and if and only if you need to have a
SoC-specific behavior in your driver (because of bugs, or slight
differences) would you be matching this SoC-specific compatible string
to capture that and key the driver behavior based off that.


Then, we have to modify all the devicetree documentation for all the
drivers.  Then, we have to ensure that all dts files populate this new
fallback string (even if it is unused).  We don't see the benefit in
doing any of that.  Using machine_is_compatible and having less
compatibility strings to deal appears much cleaner and more foolproof
for all situations.

When you introduce a new SoC, you would update all the bindings for the
devices (not drivers) that are susceptible to be used by this SoC. If
all goes well, your SoC has little bugs, and your drivers don't even
need to see an update because they are already matching the fallback
compatible string.

That's what I understand from the suggestion but I may be totally off
rails here.

In this particular case, the IP is integrated within and outside a family of
SoCs
(the exact same block is in Capri for example).
The only fallback compatablity string that makes sense is "brcm,
dte-ptp-v1".
When we integrate a new versi

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

2017-06-26 Thread Scott Branden


Hi Rob/Florian,

Thanks for input but still don't see any need for SoC specific
compatible stings.  IP revision specific yes.

On 17-06-22 06:04 PM, Florian Fainelli wrote:

On 06/22/2017 05:42 PM, Scott Branden wrote:


On 17-06-21 08:19 PM, Rob Herring wrote:

On Tue, Jun 20, 2017 at 3:48 PM, Scott Branden
<scott.bran...@broadcom.com> wrote:

Hi Rob,


On 17-06-18 07:04 AM, Rob Herring wrote:

On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:

Add device tree binding documentation for the Broadcom DTE
PTP clock driver.

Signed-off-by: Arun Parameswaran <arun.parameswa...@broadcom.com>
---
Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt | 13
+
1 file changed, 13 insertions(+)
create mode 100644
Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt

diff --git a/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
new file mode 100644
index 000..07590bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
@@ -0,0 +1,13 @@
+* Broadcom Digital Timing Engine(DTE) based PTP clock driver

Bindings describe h/w, not drivers.


+
+Required properties:
+- compatible: should be "brcm,ptp-dte"

Looks too generic. You need SoC specific compatible strings.

Rob, could you please help me understand the use of adding SoC specific
compatible strings.
I still don't get it.

It's my understanding that the SoC compatibility string is to future
proof
against bugs/incompatibilities
between different versions of the hardware block due to integration
issues
or any other reason.
You can then compare in your driver because the strings were already
used in
the dtb.

That would make sense if you can't already differentiate what SoC you
are
running on.
But the SoC is already specified in the root of the device tree in the
compatible string?
Why can't you just use of_machine_is_compatible inside your driver when
needed?

Use of of_machine_is_compatible in drivers will result in the same
mess we had with machine_is_X defines pre-DT. It practically
guarantees that you must update the driver for a new SoC (with
fallback compatibles you don't). Plus the matching logic for
of_machine_is_compatible is open coded logic in every driver which is
worse IMO than having a standard match table.

I don't understand what you mean by fallback compatible then.

Let's say I have 3 SoCs that each contain the same ip block.
You want us to add a fallback compatibility per SoC, is that correct?

I think Rob meant a fallback compatibility for the particular block.
E.g: brcm,iproc-ptp is the fallback compatible string, but in your
SoC-specific DTS, you would have at least:

compatible = "brcm,cygnus-ptp", "brcm,iproc-ptp";

Where cygnus-ptp is more specific than iproc-ptp

Then, if there is a workaround discovered in a particular SoC the driver
can be updated in the future without changing the dtb.

Then, the block gets added to a 4th SoC.
You want us to another new compatibility string for the new SoC?
If the new SoC has a bug then the driver has to be updated whether it is
in uses the fallback compatible or machine_is_compatible string.

There is no difference in amount of code added to a driver when a new
SoC is introduced into the system that has bugs that need to be handled
by the driver.

The difference is in your recommendation we need to go through all the
drivers used by the new SoC and add fallback compatibility strings.

Not really, the fallback is what the driver should be matching by
default (hence the name fallback) and if and only if you need to have a
SoC-specific behavior in your driver (because of bugs, or slight
differences) would you be matching this SoC-specific compatible string
to capture that and key the driver behavior based off that.


Then, we have to modify all the devicetree documentation for all the
drivers.  Then, we have to ensure that all dts files populate this new
fallback string (even if it is unused).  We don't see the benefit in
doing any of that.  Using machine_is_compatible and having less
compatibility strings to deal appears much cleaner and more foolproof
for all situations.

When you introduce a new SoC, you would update all the bindings for the
devices (not drivers) that are susceptible to be used by this SoC. If
all goes well, your SoC has little bugs, and your drivers don't even
need to see an update because they are already matching the fallback
compatible string.

That's what I understand from the suggestion but I may be totally off
rails here.
In this particular case, the IP is integrated within and outside a 
family of SoCs

(the exact same block is in Capri for example).
The only fallback compatablity string that makes sense is "brcm, 
dte-ptp-v1".

When we integrate a new version of this IP we would add "brcm, dte-ptp-v2".

Rob, I still see no need to define any other compatablity strings.

Everything else

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

2017-06-22 Thread Scott Branden




On 17-06-21 08:19 PM, Rob Herring wrote:

On Tue, Jun 20, 2017 at 3:48 PM, Scott Branden
<scott.bran...@broadcom.com> wrote:

Hi Rob,


On 17-06-18 07:04 AM, Rob Herring wrote:

On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:

Add device tree binding documentation for the Broadcom DTE
PTP clock driver.

Signed-off-by: Arun Parameswaran <arun.parameswa...@broadcom.com>
---
   Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt | 13
+
   1 file changed, 13 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt

diff --git a/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
new file mode 100644
index 000..07590bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
@@ -0,0 +1,13 @@
+* Broadcom Digital Timing Engine(DTE) based PTP clock driver

Bindings describe h/w, not drivers.


+
+Required properties:
+- compatible: should be "brcm,ptp-dte"

Looks too generic. You need SoC specific compatible strings.


Rob, could you please help me understand the use of adding SoC specific
compatible strings.
I still don't get it.

It's my understanding that the SoC compatibility string is to future proof
against bugs/incompatibilities
between different versions of the hardware block due to integration issues
or any other reason.
You can then compare in your driver because the strings were already used in
the dtb.

That would make sense if you can't already differentiate what SoC you are
running on.
But the SoC is already specified in the root of the device tree in the
compatible string?
Why can't you just use of_machine_is_compatible inside your driver when
needed?

Use of of_machine_is_compatible in drivers will result in the same
mess we had with machine_is_X defines pre-DT. It practically
guarantees that you must update the driver for a new SoC (with
fallback compatibles you don't). Plus the matching logic for
of_machine_is_compatible is open coded logic in every driver which is
worse IMO than having a standard match table.

I don't understand what you mean by fallback compatible then.

Let's say I have 3 SoCs that each contain the same ip block.
You want us to add a fallback compatibility per SoC, is that correct?

Then, if there is a workaround discovered in a particular SoC the driver 
can be updated in the future without changing the dtb.


Then, the block gets added to a 4th SoC.
You want us to another new compatibility string for the new SoC?
If the new SoC has a bug then the driver has to be updated whether it is 
in uses the fallback compatible or machine_is_compatible string.


There is no difference in amount of code added to a driver when a new 
SoC is introduced into the system that has bugs that need to be handled 
by the driver.


The difference is in your recommendation we need to go through all the 
drivers used by the new SoC and add fallback compatibility strings.
Then, we have to modify all the devicetree documentation for all the 
drivers.  Then, we have to ensure that all dts files populate this new 
fallback string (even if it is unused).  We don't see the benefit in 
doing any of that.  Using machine_is_compatible and having less 
compatibility strings to deal appears much cleaner and more foolproof 
for all situations.

Please explain what I'm missing.  I see other drivers already following the
of_machine_is_compatible
approach and it makes more sense to me than adding SoC specific compatible
strings into every
driver.

If the IP blocks are all the same, you don't have to add them to any
drivers, just add fallback compatibles.



Rob

Regards,
Scott

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

2017-06-20 Thread Scott Branden


Hi Rob,


On 17-06-18 07:04 AM, Rob Herring wrote:

On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:

Add device tree binding documentation for the Broadcom DTE
PTP clock driver.

Signed-off-by: Arun Parameswaran 
---
  Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt | 13 +
  1 file changed, 13 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt

diff --git a/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt 
b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
new file mode 100644
index 000..07590bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
@@ -0,0 +1,13 @@
+* Broadcom Digital Timing Engine(DTE) based PTP clock driver

Bindings describe h/w, not drivers.


+
+Required properties:
+- compatible: should be "brcm,ptp-dte"

Looks too generic. You need SoC specific compatible strings.


Rob, could you please help me understand the use of adding SoC specific 
compatible strings.

I still don't get it.

It's my understanding that the SoC compatibility string is to future 
proof against bugs/incompatibilities
between different versions of the hardware block due to integration 
issues or any other reason.
You can then compare in your driver because the strings were already 
used in the dtb.


That would make sense if you can't already differentiate what SoC you 
are running on.
But the SoC is already specified in the root of the device tree in the 
compatible string?
Why can't you just use of_machine_is_compatible inside your driver when 
needed?


Please explain what I'm missing.  I see other drivers already following 
the of_machine_is_compatible
approach and it makes more sense to me than adding SoC specific 
compatible strings into every

driver.

Regards,
 Scott

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

2017-04-24 Thread Scott Branden




On 17-04-24 04:54 PM, Eric Anholt wrote:

Scott Branden <scott.bran...@broadcom.com> writes:


Minor comment in line

On 17-04-24 02:50 PM, Eric Anholt wrote:

Cygnus is a small family of SoCs, of which we currently have
devicetree for BCM11360 and BCM58300.  The 11360's B53 is mostly the
same as 58xx, just requiring a tiny bit of setup that was previously
missing.

Signed-off-by: Eric Anholt <e...@anholt.net>
---
 Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
 drivers/net/dsa/b53/b53_srab.c| 2 ++
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt 
b/Documentation/devicetree/bindings/net/dsa/b53.txt
index d6c6e41648d4..49c93d3c0839 100644
--- a/Documentation/devicetree/bindings/net/dsa/b53.txt
+++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
@@ -29,6 +29,9 @@ Required properties:
   "brcm,bcm58625-srab"
   "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string

+  For the BCM11360 SoC, must be:
+  "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
+

place in alphabetical order in the doc?


Moved it above BCM5310x now.  I hope that's what you meant.


Yes, sorry for not being more clear.

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

2017-04-24 Thread Scott Branden


Minor comment in line

On 17-04-24 02:50 PM, Eric Anholt wrote:

Cygnus is a small family of SoCs, of which we currently have
devicetree for BCM11360 and BCM58300.  The 11360's B53 is mostly the
same as 58xx, just requiring a tiny bit of setup that was previously
missing.

Signed-off-by: Eric Anholt 
---
 Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
 drivers/net/dsa/b53/b53_srab.c| 2 ++
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt 
b/Documentation/devicetree/bindings/net/dsa/b53.txt
index d6c6e41648d4..49c93d3c0839 100644
--- a/Documentation/devicetree/bindings/net/dsa/b53.txt
+++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
@@ -29,6 +29,9 @@ Required properties:
   "brcm,bcm58625-srab"
   "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string

+  For the BCM11360 SoC, must be:
+  "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
+

place in alphabetical order in the doc?


   For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
   "brcm,bcm3384-switch"
   "brcm,bcm6328-switch"
diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
index 8a62b6a69703..c37ffd1b6833 100644
--- a/drivers/net/dsa/b53/b53_srab.c
+++ b/drivers/net/dsa/b53/b53_srab.c
@@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm53018-srab" },
{ .compatible = "brcm,bcm53019-srab" },
{ .compatible = "brcm,bcm5301x-srab" },
+   { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
@@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
{ .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
+   { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ /* sentinel */ },
 };

Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC

2016-11-09 Thread Scott Branden


One change

On 16-11-09 01:33 AM, Yendapally Reddy Dhananjaya Reddy wrote:

Add documentation for mdio mux available in Broadcom NSP SoC

Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
---
 .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt  | 57 ++
 1 file changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt

diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt 
b/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
new file mode 100644
index 000..b749a2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
@@ -0,0 +1,57 @@
+Properties for an MDIO bus multiplexer available in Broadcom NSP SoC.
+
+This MDIO bus multiplexer defines buses that could access the internal
+phys as well as external to SoCs. When child bus is selected, one needs
+to select the below properties to generate desired MDIO transaction on
+appropriate bus.
+
+Required properties in addition to the generic multiplexer properties:
+
+MDIO multiplexer node:
+- compatible: brcm,mdio-mux-iproc.

This should be brcm,mdio-mux-nsp


+- reg: Should contain registers location and length.
+- reg-names: Should contain the resource reg names.
+   - bus-ctrl: mdio bus control register address space required to
+ select the bus master. This property is not required for SoC's
+ that doesn't provide master selection.
+   - mgmt-ctrl: mdio management control register address space
+
+Sub-nodes:
+   Each bus master should be represented as a sub-node.
+
+Sub-nodes required properties:
+- reg: Bus master number. Should be 0x10 to access the external mdio devices.
+- address-cells: should be 1
+- size-cells: should be 0
+
+Every non-ethernet PHY requires a compatible property so that it could be
+probed based on this compatible string.
+
+Additional information regarding generic multiplexer properties can be found
+at- Documentation/devicetree/bindings/net/mdio-mux.txt
+
+example:
+
+   mdio_mux: mdio-mux@3f190 {
+   compatible = "brcm,mdio-mux-nsp";
+   reg = <0x3f190 0x4>,
+ <0x32000 0x4>;
+   reg-names = "bus-ctrl", "mgmt-ctrl";
+   mdio-parent-bus = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio@0 {
+   reg = <0x0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb3_phy: usb3-phy@10 {
+   compatible = "brcm,nsp-usb3-phy";
+   reg = <0x10>;
+   usb3-ctrl-syscon = <_ctrl>;
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+   };
+   };

Re: [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding

2016-11-01 Thread Scott Branden




On 16-11-01 01:59 PM, Jon Mason wrote:

On Tue, Nov 01, 2016 at 09:48:26PM +0100, Andrew Lunn wrote:

+- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
+  TX/RX lanes to function properly.


Is 'requires' the right word here? The PHY performs the actual swap of
the Tx/Rx lanes.


What I'm trying to say here is that without the lane swapping, the PHY
will not function properly.  Thus, those PHYs require this parameter
to work.  I am open to suggestions to reword the sentence to make it
clearer.
If set, indicates the PHY will swap the TX/RX lanes to compensate for 
the board being designed with the lanes swapped.


Thanks,
Jon



Andrew

Re: [PATCH v4 6/7] net: ethernet: bgmac: add NS2 support

2016-11-01 Thread Scott Branden


One change in this patch

On 16-11-01 01:04 PM, Jon Mason wrote:

Add support for the variant of amac hardware present in the Broadcom
Northstar2 based SoCs.  Northstar2 requires an additional register to be
configured with the port speed/duplexity (NICPM).  This can be added to
the link callback to hide it from the instances that do not use this.
Also, clearing of the pending interrupts on init is required due to
observed issues on some platforms.

Signed-off-by: Jon Mason 
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +-
 drivers/net/ethernet/broadcom/bgmac.c  |  3 ++
 drivers/net/ethernet/broadcom/bgmac.h  |  1 +
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index aed5dc5..f6d48c7 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -14,12 +14,21 @@
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt

 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include "bgmac.h"

+#define NICPM_IOMUX_CTRL   0x0008
+
+#define NICPM_IOMUX_CTRL_INIT_VAL  0x3196e000
+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
+#define NICPM_IOMUX_CTRL_SPD_10M   0
+#define NICPM_IOMUX_CTRL_SPD_100M  1
+#define NICPM_IOMUX_CTRL_SPD_1000M 2
+
 static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
 {
return readl(bgmac->plat.base + offset);
@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac 
*bgmac, u16 offset,
WARN_ON(1);
 }

+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
+{
+   struct bgmac *bgmac = netdev_priv(net_dev);
+   u32 val;
+
+   if (!bgmac->plat.nicpm_base)
+   return;
+
+   val = NICPM_IOMUX_CTRL_INIT_VAL;
+   switch (bgmac->net_dev->phydev->speed) {
+   default:
+   pr_err("Unsupported speed.  Defaulting to 1000Mb\n");

This should be dev_err

+   case SPEED_1000:
+   val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_100:
+   val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_10:
+   val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   }
+
+   writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
+
+   bgmac_adjust_link(bgmac->net_dev);
+}
+
 static int platform_phy_connect(struct bgmac *bgmac)
 {
struct phy_device *phy_dev;

-   phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
-bgmac_adjust_link);
+   if (bgmac->plat.nicpm_base)
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_nicpm_speed_set);
+   else
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_adjust_link);
if (!phy_dev) {
dev_err(bgmac->dev, "Phy connect failed\n");
return -ENODEV;
@@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
if (IS_ERR(bgmac->plat.idm_base))
return PTR_ERR(bgmac->plat.idm_base);

+   regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
+   if (regs) {
+   bgmac->plat.nicpm_base = devm_ioremap_resource(>dev,
+  regs);
+   if (IS_ERR(bgmac->plat.nicpm_base))
+   return PTR_ERR(bgmac->plat.nicpm_base);
+   }
+
bgmac->read = platform_bgmac_read;
bgmac->write = platform_bgmac_write;
bgmac->idm_read = platform_bgmac_idm_read;
@@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
 static const struct of_device_id bgmac_of_enet_match[] = {
{.compatible = "brcm,amac",},
{.compatible = "brcm,nsp-amac",},
+   {.compatible = "brcm,ns2-amac",},
{},
 };

diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 4584958..a805cc8 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
 /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
 static void bgmac_chip_init(struct bgmac *bgmac)
 {
+   /* Clear any erroneously pending interrupts */
+   bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
+
/* 1 interrupt per received frame */
bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);

diff --git

Re: [PATCH v3 0/6] add NS2 support to bgmac

2016-11-01 Thread Scott Branden


Hi Jon,

On 16-11-01 10:51 AM, Jon Mason wrote:

Changes in v3:
* Clean-up the bgmac DT binding doc (per Rob Herring)
* Document the lane swap binding and make it generic (Per Andrew Lunn)

Where is the documentation of the lane swap binding?




Changes in v2:
* Remove the PHY power-on (per Andrew Lunn)
* Misc PHY clean-ups regarding comments and #defines (per Andrew Lunn)
  This results on none of the original PHY code from Vikas being
  present.  So, I'm removing him as an author and giving him
  "Inspired-by" credit.
* Move PHY lane swapping to PHY driver (per Andrew Lunn and Florian
  Fainelli)
* Remove bgmac sleep (per Florian Fainelli)
* Re-add bgmac chip reset (per Florian Fainelli and Ray Jui)
* Rebased on latest net-next
* Added patch for bcm54xx_auxctl_read, which is used in the BCM54810


Add support for the amac found in the Broadcom Northstar2 SoC to the
bgmac driver.  This necessitates adding support to connect to an
externally defined phy (as described in the device tree) in the driver.
These phy changes are in addition to the changes necessary to get NS2
working.


Jon Mason (6):
  net: phy: broadcom: add bcm54xx_auxctl_read
  net: phy: broadcom: Add BCM54810 PHY entry
  Documentation: devicetree: net: add NS2 bindings to amac
  net: ethernet: bgmac: device tree phy enablement
  net: ethernet: bgmac: add NS2 support
  arm64: dts: NS2: add AMAC ethernet support

 .../devicetree/bindings/net/brcm,amac.txt  |  16 ++--
 arch/arm64/boot/dts/broadcom/ns2-svk.dts   |   5 ++
 arch/arm64/boot/dts/broadcom/ns2.dtsi  |  12 +++
 drivers/net/ethernet/broadcom/bgmac-bcma.c |  48 ++
 drivers/net/ethernet/broadcom/bgmac-platform.c | 100 -
 drivers/net/ethernet/broadcom/bgmac.c  |  55 ++--
 drivers/net/ethernet/broadcom/bgmac.h  |   8 ++
 drivers/net/phy/Kconfig|   2 +-
 drivers/net/phy/broadcom.c |  68 +-
 include/linux/brcmphy.h|  11 +++
 10 files changed, 268 insertions(+), 57 deletions(-)

Re: [PATCH 7/7] ARM: dts: NSP: Add bgmac entries

2016-07-08 Thread Scott Branden


Hi Jon,

In Subject line, you mean add amac entries.


On 16-07-08 08:56 AM, Jon Mason wrote:

Add device tree entries for the ethernet devices present on the
Broadcom Northstar Plus SoCs

Signed-off-by: Jon Mason 
---
  arch/arm/boot/dts/bcm-nsp.dtsi   | 18 ++
  arch/arm/boot/dts/bcm958625k.dts |  8 
  2 files changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index def9e78..f6d5abe 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -192,6 +192,24 @@
status = "disabled";
};

+   amac0: ethernet@22000 {
+   compatible = "brcm,nsp-amac";
+   reg = <0x022000 0x1000>,
+ <0x11 0x1000>;
+   reg-names = "amac_base", "idm_base";
+   interrupts = ;
+   status = "disabled";
+   };
+
+   amac1: ethernet@23000 {
+   compatible = "brcm,nsp-amac";
+   reg = <0x023000 0x1000>,
+ <0x111000 0x1000>;
+   reg-names = "amac_base", "idm_base";
+   interrupts = ;
+   status = "disabled";
+   };
+
nand: nand@26000 {
compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
reg = <0x026000 0x600>,
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index e298450..f41a13b 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -56,6 +56,14 @@
status = "okay";
  };

+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
   {
status = "okay";
  };



Regards,
 Scott

[PATCH v3 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

[PATCH v3 2/3] ethtool-copy.h: sync with net-next

[PATCH v3 1/3] Revert "ethtool: Add DMA Coalescing support"

[PATCH v3 0/3] ethtool: add ETHTOOL_RESET support via --reset command

Re: [PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

Re: [PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

Re: [PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

[PATCH v2 0/3] ethtool: add ETHTOOL_RESET support via --reset command

[PATCH v2 3/3] ethtool: Add ETHTOOL_RESET support via --reset command

[PATCH v2 2/3] ethtool-copy.h: sync with net-next

Re: ethtool-copy.h out of sync with linux header file?

Re: [PATCH] ethtool: Add ETHTOOL_RESET support via --reset command

Re: [PATCH] ethtool: Add ETHTOOL_RESET support via --reset command

ethtool-copy.h out of sync with linux header file?

[PATCH 0/2] net: ethtool: add support for ETH_RESET_AP

[PATCH 1/2] net: ethtool: add support for reset of AP inside NIC interface.

[PATCH 2/2] bnxt_en: Add ETH_RESET_AP support

[PATCH] ethtool: Add ETHTOOL_RESET support via --reset command

Re: [PATCH 1/1] net: ethtool: add support for reset of AP inside NIC interface.

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.

Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC

Re: [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding

Re: [PATCH v4 6/7] net: ethernet: bgmac: add NS2 support

Re: [PATCH v3 0/6] add NS2 support to bgmac

Re: [PATCH 7/7] ARM: dts: NSP: Add bgmac entries

31 matches

Site Navigation

Mail list logo

Footer information