* Re: [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command.
From: Johannes Berg @ 2018-04-19 15:26 UTC (permalink / raw)
To: Ben Greear, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <173c5f98-36bc-2e52-1e64-3a5f89008d46-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
>
> In order to efficiently parse lots of stats over and over again, I probe
> the stat names once on startup, map them to the variable I am trying to use
> (since different drivers may have different names for the same basic stat),
> and then I store the stat index.
>
> On subsequent stat reads, I just grab stats and go right to the index to
> store the stat.
>
> If the stats indexes change, that will complicate my logic quite a bit.
That's a good point.
> Maybe the flag could be called: ETHTOOL_GS2_NO_REFRESH_FW ?
Sounds more to the point to me, yeah.
> >
> > Also, wrt. the rest of the patch, I'd argue that it'd be worthwhile to
> > write the spatch and just add the flags argument to "get_ethtool_stats"
> > instead of adding a separate method - internally to the kernel it's not
> > that hard to change.
>
> Maybe this could be in followup patches? It's going to touch a lot of files,
> and might be hell to get merged all at once, and I've never used spatch, so
> just maybe someone else will volunteer that part :)
I guess you'll have to ask davem. :)
johannes
^ permalink raw reply
* Re: [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command.
From: Ben Greear @ 2018-04-19 15:25 UTC (permalink / raw)
To: Johannes Berg, netdev; +Cc: linux-wireless, ath10k
In-Reply-To: <1524119910.3024.12.camel@sipsolutions.net>
On 04/18/2018 11:38 PM, Johannes Berg wrote:
> On Wed, 2018-04-18 at 14:51 -0700, Ben Greear wrote:
>
>>> It'd be pretty hard to know which flags are firmware stats?
>>
>> Yes, it is, but ethtool stats are difficult to understand in a generic
>> manner anyway, so someone using them is already likely aware of low-level
>> details of the driver(s) they are using.
>
> Right. Come to think of it though,
>
>> + * @get_ethtool_stats2: Return extended statistics about the device.
>> + * This is only useful if the device maintains statistics not
>> + * included in &struct rtnl_link_stats64.
>> + * Takes a flags argument: 0 means all (same as get_ethtool_stats),
>> + * 0x1 (ETHTOOL_GS2_SKIP_FW) means skip firmware stats.
>> + * Other flags are reserved for now.
>> + * Same number of stats will be returned, but some of them might
>> + * not be as accurate/refreshed. This is to allow not querying
>> + * firmware or other expensive-to-read stats, for instance.
>
> "skip" vs. "don't refresh" is a bit ambiguous - I'd argue better to
> either really skip and not return the non-refreshed ones (also helps
> with the identifying), or rename the flag.
In order to efficiently parse lots of stats over and over again, I probe
the stat names once on startup, map them to the variable I am trying to use
(since different drivers may have different names for the same basic stat),
and then I store the stat index.
On subsequent stat reads, I just grab stats and go right to the index to
store the stat.
If the stats indexes change, that will complicate my logic quite a bit.
Maybe the flag could be called: ETHTOOL_GS2_NO_REFRESH_FW ?
>
> Also, wrt. the rest of the patch, I'd argue that it'd be worthwhile to
> write the spatch and just add the flags argument to "get_ethtool_stats"
> instead of adding a separate method - internally to the kernel it's not
> that hard to change.
Maybe this could be in followup patches? It's going to touch a lot of files,
and might be hell to get merged all at once, and I've never used spatch, so
just maybe someone else will volunteer that part :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH net-next] net: stmmac: Implement logic to automatically select HW Interface
From: Jose Abreu @ 2018-04-19 15:24 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, David S. Miller, Joao Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
Move all the core version detection to a common place ("hwif.c") and
implement a table which can be used to lookup the correct callbacks for
each IP version.
This simplifies the initialization flow of each IP version and eases
future implementation of new IP versions.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Vitor Soares <soares@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
Hi,
I tested this in DWMAC5. It would be great if anyone with older versions of
the core could also test this (I only have the setup for DWMAC5).
Thanks.
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 3 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 30 +---
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 1 -
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 29 +--
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 23 +--
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 -
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 41 +---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 216 ++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/hwif.h | 17 ++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 77 +-------
11 files changed, 275 insertions(+), 164 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/hwif.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 972e4ef..e3b578b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -4,7 +4,8 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o \
- dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o $(stmmac-y)
+ dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o hwif.o \
+ $(stmmac-y)
# Ordering matters. Generic driver must be last.
obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 59673c6..627e905 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -39,6 +39,7 @@
#define DWMAC_CORE_3_40 0x34
#define DWMAC_CORE_3_50 0x35
#define DWMAC_CORE_4_00 0x40
+#define DWMAC_CORE_4_10 0x41
#define DWMAC_CORE_5_00 0x50
#define DWMAC_CORE_5_10 0x51
#define STMMAC_CHAN0 0 /* Always supported and default for all chips */
@@ -428,12 +429,9 @@ struct stmmac_rx_routing {
u32 reg_shift;
};
-struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries,
- int *synopsys_id);
-struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id);
-struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries, int *synopsys_id);
+int dwmac100_setup(struct stmmac_priv *priv);
+int dwmac1000_setup(struct stmmac_priv *priv);
+int dwmac4_setup(struct stmmac_priv *priv);
void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
unsigned int high, unsigned int low);
@@ -453,24 +451,4 @@ void stmmac_dwmac4_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
extern const struct stmmac_mode_ops chain_mode_ops;
extern const struct stmmac_desc_ops dwmac4_desc_ops;
-/**
- * stmmac_get_synopsys_id - return the SYINID.
- * @priv: driver private structure
- * Description: this simple function is to decode and return the SYINID
- * starting from the HW core register.
- */
-static inline u32 stmmac_get_synopsys_id(u32 hwid)
-{
- /* Check Synopsys Id (not available on old chips) */
- if (likely(hwid)) {
- u32 uid = ((hwid & 0x0000ff00) >> 8);
- u32 synid = (hwid & 0x000000ff);
-
- pr_info("stmmac - user ID: 0x%x, Synopsys ID: 0x%x\n",
- uid, synid);
-
- return synid;
- }
- return 0;
-}
#endif /* __COMMON_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index c02d366..184ca13 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -29,7 +29,6 @@
#define GMAC_MII_DATA 0x00000014 /* MII Data */
#define GMAC_FLOW_CTRL 0x00000018 /* Flow Control */
#define GMAC_VLAN_TAG 0x0000001c /* VLAN Tag */
-#define GMAC_VERSION 0x00000020 /* GMAC CORE Version */
#define GMAC_DEBUG 0x00000024 /* GMAC debug register */
#define GMAC_WAKEUP_FILTER 0x00000028 /* Wake-up Frame Filter */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index ef10baf..0877bde 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -27,6 +27,7 @@
#include <linux/ethtool.h>
#include <net/dsa.h>
#include <asm/io.h>
+#include "stmmac.h"
#include "stmmac_pcs.h"
#include "dwmac1000.h"
@@ -498,7 +499,7 @@ static void dwmac1000_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
x->mac_gmii_rx_proto_engine++;
}
-static const struct stmmac_ops dwmac1000_ops = {
+const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac1000_rx_ipc_enable,
@@ -519,28 +520,21 @@ static void dwmac1000_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.pcs_get_adv_lp = dwmac1000_get_adv_lp,
};
-struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries,
- int *synopsys_id)
+int dwmac1000_setup(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
- u32 hwid = readl(ioaddr + GMAC_VERSION);
+ struct mac_device_info *mac = priv->hw;
- mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
- if (!mac)
- return NULL;
+ dev_info(priv->device, "\tDWMAC1000\n");
- mac->pcsr = ioaddr;
- mac->multicast_filter_bins = mcbins;
- mac->unicast_filter_entries = perfect_uc_entries;
+ priv->dev->priv_flags |= IFF_UNICAST_FLT;
+ mac->pcsr = priv->ioaddr;
+ mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
+ mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
mac->mcast_bits_log2 = 0;
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
- mac->mac = &dwmac1000_ops;
- mac->dma = &dwmac1000_dma_ops;
-
mac->link.duplex = GMAC_CONTROL_DM;
mac->link.speed10 = GMAC_CONTROL_PS;
mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
@@ -555,8 +549,5 @@ struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
mac->mii.clk_csr_shift = 2;
mac->mii.clk_csr_mask = GENMASK(5, 2);
- /* Get and dump the chip ID */
- *synopsys_id = stmmac_get_synopsys_id(hwid);
-
- return mac;
+ return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 91b23f9..b735143 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -27,6 +27,7 @@
#include <linux/crc32.h>
#include <net/dsa.h>
#include <asm/io.h>
+#include "stmmac.h"
#include "dwmac100.h"
static void dwmac100_core_init(struct mac_device_info *hw,
@@ -159,7 +160,7 @@ static void dwmac100_pmt(struct mac_device_info *hw, unsigned long mode)
return;
}
-static const struct stmmac_ops dwmac100_ops = {
+const struct stmmac_ops dwmac100_ops = {
.core_init = dwmac100_core_init,
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac100_rx_ipc_enable,
@@ -172,20 +173,13 @@ static void dwmac100_pmt(struct mac_device_info *hw, unsigned long mode)
.get_umac_addr = dwmac100_get_umac_addr,
};
-struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id)
+int dwmac100_setup(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
+ struct mac_device_info *mac = priv->hw;
- mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
- if (!mac)
- return NULL;
-
- pr_info("\tDWMAC100\n");
-
- mac->pcsr = ioaddr;
- mac->mac = &dwmac100_ops;
- mac->dma = &dwmac100_dma_ops;
+ dev_info(priv->device, "\tDWMAC100\n");
+ mac->pcsr = priv->ioaddr;
mac->link.duplex = MAC_CONTROL_F;
mac->link.speed10 = 0;
mac->link.speed100 = 0;
@@ -200,8 +194,5 @@ struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id)
mac->mii.clk_csr_shift = 2;
mac->mii.clk_csr_mask = GENMASK(5, 2);
- /* Synopsys Id is not available on old chips */
- *synopsys_id = 0;
-
- return mac;
+ return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index c7bff59..ec32fd7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -34,7 +34,6 @@
#define GMAC_PCS_BASE 0x000000e0
#define GMAC_PHYIF_CONTROL_STATUS 0x000000f8
#define GMAC_PMT 0x000000c0
-#define GMAC_VERSION 0x00000110
#define GMAC_DEBUG 0x00000114
#define GMAC_HW_FEATURE0 0x0000011c
#define GMAC_HW_FEATURE1 0x00000120
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index a3af92e..cdda0bf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -18,6 +18,7 @@
#include <linux/ethtool.h>
#include <linux/io.h>
#include <net/dsa.h>
+#include "stmmac.h"
#include "stmmac_pcs.h"
#include "dwmac4.h"
#include "dwmac5.h"
@@ -707,7 +708,7 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
x->mac_gmii_rx_proto_engine++;
}
-static const struct stmmac_ops dwmac4_ops = {
+const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
@@ -738,7 +739,7 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.set_filter = dwmac4_set_filter,
};
-static const struct stmmac_ops dwmac410_ops = {
+const struct stmmac_ops dwmac410_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_dwmac4_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
@@ -769,7 +770,7 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.set_filter = dwmac4_set_filter,
};
-static const struct stmmac_ops dwmac510_ops = {
+const struct stmmac_ops dwmac510_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_dwmac4_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
@@ -803,19 +804,16 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.safety_feat_dump = dwmac5_safety_feat_dump,
};
-struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries, int *synopsys_id)
+int dwmac4_setup(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
- u32 hwid = readl(ioaddr + GMAC_VERSION);
+ struct mac_device_info *mac = priv->hw;
- mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
- if (!mac)
- return NULL;
+ dev_info(priv->device, "\tDWMAC4/5\n");
- mac->pcsr = ioaddr;
- mac->multicast_filter_bins = mcbins;
- mac->unicast_filter_entries = perfect_uc_entries;
+ priv->dev->priv_flags |= IFF_UNICAST_FLT;
+ mac->pcsr = priv->ioaddr;
+ mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
+ mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
mac->mcast_bits_log2 = 0;
if (mac->multicast_filter_bins)
@@ -835,20 +833,5 @@ struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, int mcbins,
mac->mii.clk_csr_shift = 8;
mac->mii.clk_csr_mask = GENMASK(11, 8);
- /* Get and dump the chip ID */
- *synopsys_id = stmmac_get_synopsys_id(hwid);
-
- if (*synopsys_id > DWMAC_CORE_4_00)
- mac->dma = &dwmac410_dma_ops;
- else
- mac->dma = &dwmac4_dma_ops;
-
- if (*synopsys_id >= DWMAC_CORE_5_10)
- mac->mac = &dwmac510_ops;
- else if (*synopsys_id >= DWMAC_CORE_4_00)
- mac->mac = &dwmac410_ops;
- else
- mac->mac = &dwmac4_ops;
-
- return mac;
+ return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
new file mode 100644
index 0000000..45f6300
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (c) 2018 Synopsys, Inc. and/or its affiliates.
+// stmmac HW Interface Handling
+
+#include "common.h"
+#include "stmmac.h"
+
+static u32 stmmac_get_id(struct stmmac_priv *priv, u32 id_reg)
+{
+ u32 reg = readl(priv->ioaddr + id_reg);
+
+ if (!reg) {
+ dev_info(priv->device, "Version ID not available\n");
+ return 0x0;
+ }
+
+ dev_info(priv->device, "User ID: 0x%x, Synopsys ID: 0x%x\n",
+ (unsigned int)(reg & GENMASK(15, 8)) >> 8,
+ (unsigned int)(reg & GENMASK(7, 0)));
+ return reg & GENMASK(7, 0);
+}
+
+static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
+{
+ struct mac_device_info *mac = priv->hw;
+
+ if (priv->chain_mode) {
+ dev_info(priv->device, "Chain mode enabled\n");
+ priv->mode = STMMAC_CHAIN_MODE;
+ mac->mode = &chain_mode_ops;
+ } else {
+ dev_info(priv->device, "Ring mode enabled\n");
+ priv->mode = STMMAC_RING_MODE;
+ mac->mode = &ring_mode_ops;
+ }
+}
+
+static int stmmac_dwmac1_quirks(struct stmmac_priv *priv)
+{
+ struct mac_device_info *mac = priv->hw;
+
+ if (priv->plat->enh_desc) {
+ dev_info(priv->device, "Enhanced/Alternate descriptors\n");
+
+ /* GMAC older than 3.50 has no extended descriptors */
+ if (priv->synopsys_id >= DWMAC_CORE_3_50) {
+ dev_info(priv->device, "Enabled extended descriptors\n");
+ priv->extend_desc = 1;
+ } else {
+ dev_warn(priv->device, "Extended descriptors not supported\n");
+ }
+
+ mac->desc = &enh_desc_ops;
+ } else {
+ dev_info(priv->device, "Normal descriptors\n");
+ mac->desc = &ndesc_ops;
+ }
+
+ stmmac_dwmac_mode_quirk(priv);
+ return 0;
+}
+
+static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
+{
+ stmmac_dwmac_mode_quirk(priv);
+ return 0;
+}
+
+static const struct stmmac_hwif_entry {
+ bool gmac;
+ bool gmac4;
+ u32 min_id;
+ const void *desc;
+ const void *dma;
+ const void *mac;
+ const void *hwtimestamp;
+ const void *mode;
+ int (*setup)(struct stmmac_priv *priv);
+ int (*quirks)(struct stmmac_priv *priv);
+} stmmac_hw[] = {
+ /* NOTE: New HW versions shall go to the end of this table */
+ {
+ .gmac = false,
+ .gmac4 = false,
+ .min_id = 0,
+ .desc = NULL,
+ .dma = &dwmac100_dma_ops,
+ .mac = &dwmac100_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = NULL,
+ .setup = dwmac100_setup,
+ .quirks = stmmac_dwmac1_quirks,
+ }, {
+ .gmac = true,
+ .gmac4 = false,
+ .min_id = 0,
+ .desc = NULL,
+ .dma = &dwmac1000_dma_ops,
+ .mac = &dwmac1000_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = NULL,
+ .setup = dwmac1000_setup,
+ .quirks = stmmac_dwmac1_quirks,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = 0,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac4_dma_ops,
+ .mac = &dwmac4_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = NULL,
+ .setup = dwmac4_setup,
+ .quirks = stmmac_dwmac4_quirks,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = DWMAC_CORE_4_00,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac4_dma_ops,
+ .mac = &dwmac410_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = &dwmac4_ring_mode_ops,
+ .setup = dwmac4_setup,
+ .quirks = NULL,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = DWMAC_CORE_4_10,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac410_dma_ops,
+ .mac = &dwmac410_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = &dwmac4_ring_mode_ops,
+ .setup = dwmac4_setup,
+ .quirks = NULL,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = DWMAC_CORE_5_10,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac410_dma_ops,
+ .mac = &dwmac510_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = &dwmac4_ring_mode_ops,
+ .setup = dwmac4_setup,
+ .quirks = NULL,
+ }
+};
+
+int stmmac_hwif_init(struct stmmac_priv *priv)
+{
+ bool needs_gmac4 = priv->plat->has_gmac4;
+ bool needs_gmac = priv->plat->has_gmac;
+ const struct stmmac_hwif_entry *entry;
+ struct mac_device_info *mac;
+ int i, ret;
+ u32 id;
+
+ if (needs_gmac) {
+ id = stmmac_get_id(priv, GMAC_VERSION);
+ } else {
+ id = stmmac_get_id(priv, GMAC4_VERSION);
+ }
+
+ /* Save ID for later use */
+ priv->synopsys_id = id;
+
+ /* Check for HW specific setup first */
+ if (priv->plat->setup) {
+ priv->hw = priv->plat->setup(priv);
+ if (!priv->hw)
+ return -ENOMEM;
+ return 0;
+ }
+
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
+ if (!mac)
+ return -ENOMEM;
+
+ /* Fallback to generic HW */
+ for (i = ARRAY_SIZE(stmmac_hw) - 1; i >= 0; i--) {
+ entry = &stmmac_hw[i];
+
+ if (needs_gmac ^ entry->gmac)
+ continue;
+ if (needs_gmac4 ^ entry->gmac4)
+ continue;
+ if (id < entry->min_id)
+ continue;
+
+ mac->desc = entry->desc;
+ mac->dma = entry->dma;
+ mac->mac = entry->mac;
+ mac->ptp = entry->hwtimestamp;
+ mac->mode = entry->mode;
+
+ priv->hw = mac;
+
+ /* Entry found */
+ ret = entry->setup(priv);
+ if (ret)
+ return ret;
+
+ /* Run quirks, if needed */
+ if (entry->quirks) {
+ ret = entry->quirks(priv);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+ }
+
+ return -EINVAL;
+}
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index f81ded4..bfad616 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -418,4 +418,21 @@ struct stmmac_mode_ops {
#define stmmac_clean_desc3(__priv, __args...) \
stmmac_do_void_callback(__priv, mode, clean_desc3, __args)
+struct stmmac_priv;
+
+extern const struct stmmac_ops dwmac100_ops;
+extern const struct stmmac_dma_ops dwmac100_dma_ops;
+extern const struct stmmac_ops dwmac1000_ops;
+extern const struct stmmac_dma_ops dwmac1000_dma_ops;
+extern const struct stmmac_ops dwmac4_ops;
+extern const struct stmmac_dma_ops dwmac4_dma_ops;
+extern const struct stmmac_ops dwmac410_ops;
+extern const struct stmmac_dma_ops dwmac410_dma_ops;
+extern const struct stmmac_ops dwmac510_ops;
+
+#define GMAC_VERSION 0x00000020 /* GMAC CORE Version */
+#define GMAC4_VERSION 0x00000110 /* GMAC4+ CORE Version */
+
+int stmmac_hwif_init(struct stmmac_priv *priv);
+
#endif /* __STMMAC_HWIF_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index da50451..2443f20 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -130,6 +130,7 @@ struct stmmac_priv {
int eee_active;
int tx_lpi_timer;
unsigned int mode;
+ unsigned int chain_mode;
int extend_desc;
struct ptp_clock *ptp_clock;
struct ptp_clock_info ptp_clock_ops;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 90363a8..574924a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -769,7 +769,6 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
netdev_info(priv->dev,
"IEEE 1588-2008 Advanced Timestamp supported\n");
- priv->hw->ptp = &stmmac_ptp;
priv->hwts_tx_en = 0;
priv->hwts_rx_en = 0;
@@ -2122,32 +2121,6 @@ static void stmmac_mmc_setup(struct stmmac_priv *priv)
}
/**
- * stmmac_selec_desc_mode - to select among: normal/alternate/extend descriptors
- * @priv: driver private structure
- * Description: select the Enhanced/Alternate or Normal descriptors.
- * In case of Enhanced/Alternate, it checks if the extended descriptors are
- * supported by the HW capability register.
- */
-static void stmmac_selec_desc_mode(struct stmmac_priv *priv)
-{
- if (priv->plat->enh_desc) {
- dev_info(priv->device, "Enhanced/Alternate descriptors\n");
-
- /* GMAC older than 3.50 has no extended descriptors */
- if (priv->synopsys_id >= DWMAC_CORE_3_50) {
- dev_info(priv->device, "Enabled extended descriptors\n");
- priv->extend_desc = 1;
- } else
- dev_warn(priv->device, "Extended descriptors not supported\n");
-
- priv->hw->desc = &enh_desc_ops;
- } else {
- dev_info(priv->device, "Normal descriptors\n");
- priv->hw->desc = &ndesc_ops;
- }
-}
-
-/**
* stmmac_get_hw_features - get MAC capabilities from the HW cap. register.
* @priv: driver private structure
* Description:
@@ -4093,49 +4066,17 @@ static void stmmac_service_task(struct work_struct *work)
*/
static int stmmac_hw_init(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
-
- /* Identify the MAC HW device */
- if (priv->plat->setup) {
- mac = priv->plat->setup(priv);
- } else if (priv->plat->has_gmac) {
- priv->dev->priv_flags |= IFF_UNICAST_FLT;
- mac = dwmac1000_setup(priv->ioaddr,
- priv->plat->multicast_filter_bins,
- priv->plat->unicast_filter_entries,
- &priv->synopsys_id);
- } else if (priv->plat->has_gmac4) {
- priv->dev->priv_flags |= IFF_UNICAST_FLT;
- mac = dwmac4_setup(priv->ioaddr,
- priv->plat->multicast_filter_bins,
- priv->plat->unicast_filter_entries,
- &priv->synopsys_id);
- } else {
- mac = dwmac100_setup(priv->ioaddr, &priv->synopsys_id);
- }
- if (!mac)
- return -ENOMEM;
-
- priv->hw = mac;
+ int ret;
/* dwmac-sun8i only work in chain mode */
if (priv->plat->has_sun8i)
chain_mode = 1;
+ priv->chain_mode = chain_mode;
- /* To use the chained or ring mode */
- if (priv->synopsys_id >= DWMAC_CORE_4_00) {
- priv->hw->mode = &dwmac4_ring_mode_ops;
- } else {
- if (chain_mode) {
- priv->hw->mode = &chain_mode_ops;
- dev_info(priv->device, "Chain mode enabled\n");
- priv->mode = STMMAC_CHAIN_MODE;
- } else {
- priv->hw->mode = &ring_mode_ops;
- dev_info(priv->device, "Ring mode enabled\n");
- priv->mode = STMMAC_RING_MODE;
- }
- }
+ /* Initialize HW Interface */
+ ret = stmmac_hwif_init(priv);
+ if (ret)
+ return ret;
/* Get the HW capability (new GMAC newer than 3.50a) */
priv->hw_cap_support = stmmac_get_hw_features(priv);
@@ -4169,12 +4110,6 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
dev_info(priv->device, "No HW DMA feature register supported\n");
}
- /* To use alternate (extended), normal or GMAC4 descriptor structures */
- if (priv->synopsys_id >= DWMAC_CORE_4_00)
- priv->hw->desc = &dwmac4_desc_ops;
- else
- stmmac_selec_desc_mode(priv);
-
if (priv->plat->rx_coe) {
priv->hw->rx_csum = priv->plat->rx_coe;
dev_info(priv->device, "RX Checksum Offload Engine supported\n");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 3/3] dt-bindings: Document the DT bindings for lan78xx
From: Andrew Lunn @ 2018-04-19 15:20 UTC (permalink / raw)
To: Phil Elwell
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <1524148325-78945-5-git-send-email-phil@raspberrypi.org>
On Thu, Apr 19, 2018 at 03:32:05PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications without an EEPROM or programmed OTP.
>
> Document the supported properties in a bindings file.
>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v3 2/3] lan78xx: Read LED states from Device Tree
From: Andrew Lunn @ 2018-04-19 15:19 UTC (permalink / raw)
To: Phil Elwell
Cc: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <1524148325-78945-4-git-send-email-phil@raspberrypi.org>
> @@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
> mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
> phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
>
> + if (phydev->mdio.dev.of_node) {
> + u32 reg;
> + int len;
> +
> + len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
> + "microchip,led-modes",
> + sizeof(u32));
> + if (len >= 0) {
> + /* Ensure the appropriate LEDs are enabled */
> + lan78xx_read_reg(dev, HW_CFG, ®);
> + reg &= ~(HW_CFG_LED0_EN_ |
> + HW_CFG_LED1_EN_ |
> + HW_CFG_LED2_EN_ |
> + HW_CFG_LED3_EN_);
> + reg |= (len > 0) * HW_CFG_LED0_EN_ |
> + (len > 1) * HW_CFG_LED1_EN_ |
> + (len > 2) * HW_CFG_LED2_EN_ |
> + (len > 3) * HW_CFG_LED3_EN_;
> + lan78xx_write_reg(dev, HW_CFG, reg);
> + }
> + }
> +
Humm. Not nice. But i cannot think of a cleaner way of doing this.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH resend v3 3/3] dt-bindings: Document the DT bindings for lan78xx
From: Phil Elwell @ 2018-04-19 15:16 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
In-Reply-To: <1524151019-82823-1-git-send-email-phil@raspberrypi.org>
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in a bindings file.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
.../devicetree/bindings/net/microchip,lan78xx.txt | 54 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 0000000..a5d701b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,54 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+The Device Tree properties, if present, override the OTP and EEPROM.
+
+Required properties:
+- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
+
+Optional properties:
+- local-mac-address: see ethernet.txt
+- mac-address: see ethernet.txt
+
+Optional properties of the embedded PHY:
+- microchip,led-modes: a 0..4 element vector, with each element configuring
+ the operating mode of an LED. Omitted LEDs are turned off. Allowed values
+ are defined in "include/dt-bindings/net/microchip-lan78xx.h".
+
+Example:
+
+/* Based on the configuration for a Raspberry Pi 3 B+ */
+&usb {
+ usb1@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb1_1@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb424,7800";
+ reg = <1>;
+ local-mac-address = [ 00 11 22 33 44 55 ];
+
+ mdio {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ eth_phy: ethernet-phy@1 {
+ reg = <1>;
+ microchip,led-modes = <
+ LAN78XX_LINK_1000_ACTIVITY
+ LAN78XX_LINK_10_100_ACTIVITY
+ >;
+ };
+ };
+ };
+ };
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 23735d9..91cb961 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14572,6 +14572,7 @@ M: Woojung Huh <woojung.huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
F: drivers/net/usb/lan78xx.*
F: include/dt-bindings/net/microchip-lan78xx.h
--
2.7.4
^ permalink raw reply related
* [PATCH resend v3 2/3] lan78xx: Read LED states from Device Tree
From: Phil Elwell @ 2018-04-19 15:16 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
In-Reply-To: <1524151019-82823-1-git-send-email-phil@raspberrypi.org>
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/activity 5=link10/1000/activity
6=link10/100/activity 14=off 15=on
These values are given symbolic constants in a dt-bindings header.
Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
MAINTAINERS | 1 +
drivers/net/phy/microchip.c | 25 ++++++++++++++++++++++
drivers/net/usb/lan78xx.c | 32 ++++++++++++++++++++++++++++-
include/dt-bindings/net/microchip-lan78xx.h | 21 +++++++++++++++++++
include/linux/microchipphy.h | 3 +++
5 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d..23735d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14573,6 +14573,7 @@ M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/usb/lan78xx.*
+F: include/dt-bindings/net/microchip-lan78xx.h
USB MASS STORAGE DRIVER
M: Alan Stern <stern@rowland.harvard.edu>
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 0f293ef..ef5e160 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -20,6 +20,8 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/microchipphy.h>
+#include <linux/of.h>
+#include <dt-bindings/net/microchip-lan78xx.h>
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
#define DRIVER_DESC "Microchip LAN88XX PHY driver"
@@ -70,6 +72,8 @@ static int lan88xx_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
struct lan88xx_priv *priv;
+ u32 led_modes[4];
+ int len;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -77,6 +81,27 @@ static int lan88xx_probe(struct phy_device *phydev)
priv->wolopts = 0;
+ len = of_property_read_variable_u32_array(dev->of_node,
+ "microchip,led-modes",
+ led_modes,
+ 0,
+ ARRAY_SIZE(led_modes));
+ if (len >= 0) {
+ u32 reg = 0;
+ int i;
+
+ for (i = 0; i < len; i++) {
+ if (led_modes[i] > 15)
+ return -EINVAL;
+ reg |= led_modes[i] << (i * 4);
+ }
+ for (; i < ARRAY_SIZE(led_modes); i++)
+ reg |= LAN78XX_FORCE_LED_OFF << (i * 4);
+ (void)phy_write(phydev, LAN78XX_PHY_LED_MODE_SELECT, reg);
+ } else if (len == -EOVERFLOW) {
+ return -EINVAL;
+ }
+
/* these values can be used to identify internal PHY */
priv->chip_id = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_ID);
priv->chip_rev = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_REV);
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a823f01..6b03b97 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/microchipphy.h>
#include <linux/phy.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "lan78xx.h"
@@ -1760,6 +1761,7 @@ static int lan78xx_mdiobus_write(struct mii_bus *bus, int phy_id, int idx,
static int lan78xx_mdio_init(struct lan78xx_net *dev)
{
+ struct device_node *node;
int ret;
dev->mdiobus = mdiobus_alloc();
@@ -1788,7 +1790,13 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
break;
}
- ret = mdiobus_register(dev->mdiobus);
+ node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
+ if (node) {
+ ret = of_mdiobus_register(dev->mdiobus, node);
+ of_node_put(node);
+ } else {
+ ret = mdiobus_register(dev->mdiobus);
+ }
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
@@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
+ if (phydev->mdio.dev.of_node) {
+ u32 reg;
+ int len;
+
+ len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
+ "microchip,led-modes",
+ sizeof(u32));
+ if (len >= 0) {
+ /* Ensure the appropriate LEDs are enabled */
+ lan78xx_read_reg(dev, HW_CFG, ®);
+ reg &= ~(HW_CFG_LED0_EN_ |
+ HW_CFG_LED1_EN_ |
+ HW_CFG_LED2_EN_ |
+ HW_CFG_LED3_EN_);
+ reg |= (len > 0) * HW_CFG_LED0_EN_ |
+ (len > 1) * HW_CFG_LED1_EN_ |
+ (len > 2) * HW_CFG_LED2_EN_ |
+ (len > 3) * HW_CFG_LED3_EN_;
+ lan78xx_write_reg(dev, HW_CFG, reg);
+ }
+ }
+
genphy_config_aneg(phydev);
dev->fc_autoneg = phydev->autoneg;
diff --git a/include/dt-bindings/net/microchip-lan78xx.h b/include/dt-bindings/net/microchip-lan78xx.h
new file mode 100644
index 0000000..0742ff0
--- /dev/null
+++ b/include/dt-bindings/net/microchip-lan78xx.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_MICROCHIP_LAN78XX_H
+#define _DT_BINDINGS_MICROCHIP_LAN78XX_H
+
+/* LED modes for LAN7800/LAN7850 embedded PHY */
+
+#define LAN78XX_LINK_ACTIVITY 0
+#define LAN78XX_LINK_1000_ACTIVITY 1
+#define LAN78XX_LINK_100_ACTIVITY 2
+#define LAN78XX_LINK_10_ACTIVITY 3
+#define LAN78XX_LINK_100_1000_ACTIVITY 4
+#define LAN78XX_LINK_10_1000_ACTIVITY 5
+#define LAN78XX_LINK_10_100_ACTIVITY 6
+#define LAN78XX_DUPLEX_COLLISION 8
+#define LAN78XX_COLLISION 9
+#define LAN78XX_ACTIVITY 10
+#define LAN78XX_AUTONEG_FAULT 12
+#define LAN78XX_FORCE_LED_OFF 14
+#define LAN78XX_FORCE_LED_ON 15
+
+#endif
diff --git a/include/linux/microchipphy.h b/include/linux/microchipphy.h
index eb492d4..8e4015e 100644
--- a/include/linux/microchipphy.h
+++ b/include/linux/microchipphy.h
@@ -70,4 +70,7 @@
#define LAN88XX_MMD3_CHIP_ID (32877)
#define LAN88XX_MMD3_CHIP_REV (32878)
+/* Registers specific to the LAN7800/LAN7850 embedded phy */
+#define LAN78XX_PHY_LED_MODE_SELECT (0x1D)
+
#endif /* _MICROCHIPPHY_H */
--
2.7.4
^ permalink raw reply related
* [PATCH resend v3 1/3] lan78xx: Read MAC address from DT if present
From: Phil Elwell @ 2018-04-19 15:16 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
In-Reply-To: <1524151019-82823-1-git-send-email-phil@raspberrypi.org>
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
drivers/net/usb/lan78xx.c | 42 ++++++++++++++++++++----------------------
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0867f72..a823f01 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/microchipphy.h>
#include <linux/phy.h>
+#include <linux/of_net.h>
#include "lan78xx.h"
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
@@ -1652,34 +1653,31 @@ static void lan78xx_init_mac_address(struct lan78xx_net *dev)
addr[5] = (addr_hi >> 8) & 0xFF;
if (!is_valid_ether_addr(addr)) {
- /* reading mac address from EEPROM or OTP */
- if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0) ||
- (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
- if (is_valid_ether_addr(addr)) {
- /* eeprom values are valid so use them */
- netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
- } else {
- /* generate random MAC */
- random_ether_addr(addr);
- netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
- }
-
- addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
- addr_hi = addr[4] | (addr[5] << 8);
-
- ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
- ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+ if (!eth_platform_get_mac_address(&dev->udev->dev, addr)) {
+ /* valid address present in Device Tree */
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+ } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0) ||
+ (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+ is_valid_ether_addr(addr)) {
+ /* eeprom values are valid so use them */
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
"MAC address set to random addr");
}
+
+ addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+ addr_hi = addr[4] | (addr[5] << 8);
+
+ ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+ ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
--
2.7.4
^ permalink raw reply related
* [PATCH resend v3 0/3] lan78xx: Read configuration from Device Tree
From: Phil Elwell @ 2018-04-19 15:16 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
[ Resending due to incorrect distribution list ]
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for reading the MAC address and LED modes from
Device Tree.
v3:
- Move LED setting into PHY driver.
v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.
Phil Elwell (3):
lan78xx: Read MAC address from DT if present
lan78xx: Read LED states from Device Tree
dt-bindings: Document the DT bindings for lan78xx
.../devicetree/bindings/net/microchip,lan78xx.txt | 54 ++++++++++++++++
MAINTAINERS | 2 +
drivers/net/phy/microchip.c | 25 ++++++++
drivers/net/usb/lan78xx.c | 74 +++++++++++++++-------
include/dt-bindings/net/microchip-lan78xx.h | 21 ++++++
include/linux/microchipphy.h | 3 +
6 files changed, 156 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH 35/61] net: ethernet: ti: simplify getting .drvdata
From: Grygorii Strashko @ 2018-04-19 15:14 UTC (permalink / raw)
To: Wolfram Sang, linux-kernel
Cc: linux-renesas-soc, kernel-janitors, linux-omap, netdev
In-Reply-To: <20180419140641.27926-36-wsa+renesas@sang-engineering.com>
On 04/19/2018 09:06 AM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH net-next v4 1/3] vmcore: add API to collect hardware dump in second kernel
From: Rahul Lakkireddy @ 2018-04-19 14:56 UTC (permalink / raw)
To: Greg KH
Cc: netdev@vger.kernel.org, kexec@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net, viro@zeniv.linux.org.uk,
ebiederm@xmission.com, stephen@networkplumber.org,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
Ganesh GR, Nirranjan Kirubaharan, Indranil Choudhury
In-Reply-To: <20180419082456.GA8617@kroah.com>
On Thursday, April 04/19/18, 2018 at 13:54:56 +0530, Greg KH wrote:
> On Tue, Apr 17, 2018 at 01:14:17PM +0530, Rahul Lakkireddy wrote:
> > +config PROC_VMCORE_DEVICE_DUMP
> > + bool "Device Hardware/Firmware Log Collection"
> > + depends on PROC_VMCORE
> > + default y
>
> Only things that require the machine to keep working should be 'default
> y', please remove this, it's an option.
>
Ok. Will fix this.
> > + help
> > + Device drivers can collect the device specific snapshot of
> > + their hardware or firmware before they are initialized in
> > + crash recovery kernel. If you say Y here, the device dumps
> > + will be added as ELF notes to /proc/vmcore
>
> Which exact "device drivers" are you referring to here?
>
The API is generic enough to collect any type of device's dump. Any
driver that wants to collect its underlying hardware/firmware dump
can use the API. In our case, cxgb4 driver collects dumps of the
underlying Chelsio network devices.
Thanks,
Rahul
^ permalink raw reply
* Re: [PATCH v2 net 2/3] virtio_net: fix adding vids on big-endian
From: Michael S. Tsirkin @ 2018-04-19 14:56 UTC (permalink / raw)
To: Cornelia Huck
Cc: linux-kernel, Mikulas Patocka, Eric Dumazet, David Miller,
Thomas Huth, Jason Wang, virtualization, netdev
In-Reply-To: <20180419152641.092865f3.cohuck@redhat.com>
On Thu, Apr 19, 2018 at 03:26:41PM +0200, Cornelia Huck wrote:
> On Thu, 19 Apr 2018 08:30:49 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > Programming vids (adding or removing them) still passes
> > guest-endian values in the DMA buffer. That's wrong
> > if guest is big-endian and when virtio 1 is enabled.
> >
> > Note: this is on top of a previous patch:
> > virtio_net: split out ctrl buffer
> >
> > Fixes: 9465a7a6f ("virtio_net: enable v1.0 support")
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > drivers/net/virtio_net.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Ouch. Have you seen any bug reports for that?
No, but then vlans within VMs aren't used too often
(as opposed to attaching vlans by the HV).
--
MST
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel
From: Eric W. Biederman @ 2018-04-19 14:53 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: Dave Young, netdev@vger.kernel.org, kexec@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Indranil Choudhury, Nirranjan Kirubaharan,
stephen@networkplumber.org, Ganesh GR, akpm@linux-foundation.org,
torvalds@linux-foundation.org, davem@davemloft.net,
viro@zeniv.linux.org.uk
In-Reply-To: <20180419142747.GA30274@chelsio.com>
Rahul Lakkireddy <rahul.lakkireddy@chelsio.com> writes:
> On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
>> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
>> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> > > Hi Rahul,
>> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
>> > > > On production servers running variety of workloads over time, kernel
>> > > > panic can happen sporadically after days or even months. It is
>> > > > important to collect as much debug logs as possible to root cause
>> > > > and fix the problem, that may not be easy to reproduce. Snapshot of
>> > > > underlying hardware/firmware state (like register dump, firmware
>> > > > logs, adapter memory, etc.), at the time of kernel panic will be very
>> > > > helpful while debugging the culprit device driver.
>> > > >
>> > > > This series of patches add new generic framework that enable device
>> > > > drivers to collect device specific snapshot of the hardware/firmware
>> > > > state of the underlying device in the crash recovery kernel. In crash
>> > > > recovery kernel, the collected logs are added as elf notes to
>> > > > /proc/vmcore, which is copied by user space scripts for post-analysis.
>> > > >
>> > > > The sequence of actions done by device drivers to append their device
>> > > > specific hardware/firmware logs to /proc/vmcore are as follows:
>> > > >
>> > > > 1. During probe (before hardware is initialized), device drivers
>> > > > register to the vmcore module (via vmcore_add_device_dump()), with
>> > > > callback function, along with buffer size and log name needed for
>> > > > firmware/hardware log collection.
>> > >
>> > > I assumed the elf notes info should be prepared while kexec_[file_]load
>> > > phase. But I did not read the old comment, not sure if it has been discussed
>> > > or not.
>> > >
>> >
>> > We must not collect dumps in crashing kernel. Adding more things in
>> > crash dump path risks not collecting vmcore at all. Eric had
>> > discussed this in more detail at:
>> >
>> > https://lkml.org/lkml/2018/3/24/319
>> >
>> > We are safe to collect dumps in the second kernel. Each device dump
>> > will be exported as an elf note in /proc/vmcore.
>>
>> I understand that we should avoid adding anything in crash path. And I also
>> agree to collect device dump in second kernel. I just assumed device
>> dump use some memory area to store the debug info and the memory
>> is persistent so that this can be done in 2 steps, first register the
>> address in elf header in kexec_load, then collect the dump in 2nd
>> kernel. But it seems the driver is doing some other logic to collect
>> the info instead of just that simple like I thought.
>>
>
> It seems simpler, but I'm concerned with waste of memory area, if
> there are no device dumps being collected in second kernel. In
> approach proposed in these series, we dynamically allocate memory
> for the device dumps from second kernel's available memory.
Don't count that kernel having more than about 128MiB.
For that reason if for no other it would be nice if it was possible to
have the driver to not initialize the device and just stand there
handing out the data a piece at a time as it is read from /proc/vmcore.
The 2GiB number I read earlier concerns me for working in a limited
environment.
It might even make sense to separate this into a completely separate
module (depended upon the main driver if it makes sense to share
the functionality) so that people performing crash dumps would not
hesitate to include the code in their initramfs images.
I can see splitting a device up into a portion only to be used in case
of a crash dump and a normal portion like we do for main memory but I
doubt that makes sense in practice.
>> > > If do this in 2nd kernel a question is driver can be loaded later than vmcore init.
>> >
>> > Yes, drivers will add their device dumps after vmcore init.
>> >
>> > > How to guarantee the function works if vmcore reading happens before
>> > > the driver is loaded?
>> > >
>> > > Also it is possible that kdump initramfs does not contains the driver
>> > > module.
>> > >
>> > > Am I missing something?
>> > >
>> >
>> > Yes, driver must be in initramfs if it wants to collect and add device
>> > dump to /proc/vmcore in second kernel.
>>
>> In RH/Fedora kdump scripts we only add the things are required to
>> bring up the dump target, so that we can use as less memory as we can.
>>
>> For example, if a net driver panicked, and the dump target is rootfs
>> which is a scsi disk, then no network related stuff will be added in
>> initramfs.
>>
>> In this case the device dump info will be not collected..
>
> Correct. If the driver is not present in initramfs, it can't collect
> its underlying device's dump. Administrator is expected to add the
> driver to initramfs, if device dump needs to be collected.
That makes sense, as most people won't have that need. Still if we can
find something that can work automatically and safely without the need
for manual configuration people are more likely to use it.
Eric
^ permalink raw reply
* Re: unregister_netdevice: waiting for DEV to become free
From: Dmitry Vyukov @ 2018-04-19 14:53 UTC (permalink / raw)
To: syzbot; +Cc: LKML, syzkaller-bugs, netdev, Dan Streetman
In-Reply-To: <000000000000d71bf6056a34b628@google.com>
On Thu, Apr 19, 2018 at 4:52 PM, syzbot
<syzbot+2dfb68e639f0621b19fb@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +0000)
> Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=2dfb68e639f0621b19fb
>
> So far this crash happened 5 times on upstream.
> Unfortunately, I don't have any reproducer for this crash yet.
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5531107864870912
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=1808800213120130118
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
There are 2 reproducers for these hangs (presumably for different bugs):
https://groups.google.com/d/msg/syzkaller/-06_laheMF0/4wfWs6ATBwAJ
https://groups.google.com/d/msg/syzkaller/-06_laheMF0/MxCjIiHkBwAJ
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+2dfb68e639f0621b19fb@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> connbytes_mt_check: 1 callbacks suppressed
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> unregister_netdevice: waiting for lo to become free. Usage count = 3
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> kernel msg: ebtables bug: please report to author: Entries_size never zero
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> nla_parse: 1 callbacks suppressed
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
> netlink: 17 bytes leftover after parsing attributes in process
> `syz-executor6'.
> xt_connbytes: cannot load conntrack support for proto=7
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000d71bf6056a34b628%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] net: deal wrong skb and failure ret from __tcp_retransmit_skb
From: Liu, Changcheng @ 2018-04-19 14:38 UTC (permalink / raw)
To: Eric Dumazet, davem, kuznet, yoshfuji; +Cc: netdev, akpm
In-Reply-To: <b2901883-ec63-298c-6e83-edc8db23e4ad@gmail.com>
On 06:40 Thu 19 Apr, Eric Dumazet wrote:
>
>
> On 04/19/2018 04:26 AM, Liu, Changcheng wrote:
> > Hit below panic due to skb is NULL, WARN wrong skb first.
> > if __tcp_retransmit_skb return failure e.g. -EAGAIN, it
> > needn't do further action in tcp_retransmit_skb.
> >
> > gdb vmlinux
> > Reading symbols from vmlinux...done.
> > (gdb) p &((struct tcp_skb_cb *) \
> > &(((struct sk_buff *)0)->cb[0]))->tcp_gso_segs
> > $1 = (u16 *) 0x30 <irq_stack_union+48>
> >
> > [ 9040.917533] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
> > [ 9040.926279] IP: tcp_retransmit_skb+0x5c/0xc0
> > [ 9040.931043] PGD 0 P4D 0
> > [ 9040.933865] Oops: 0000 [#1] PREEMPT SMP PTI
> > [ 9040.972151] RIP: 0010:tcp_retransmit_skb+0x5c/0xc0
> > [ 9040.977496] RSP: 0018:ffff8802bec83e40 EFLAGS: 00010202
> > [ 9041.062527] Call Trace:
> > [ 9041.065250] <IRQ>
> > [ 9041.067489] tcp_retransmit_timer+0x481/0x820
> > [ 9041.077697] tcp_write_timer_handler+0xe9/0x230
> > [ 9041.082751] tcp_write_timer+0x75/0x80
> > [ 9041.086932] call_timer_fn+0x29/0x150
> > [ 9041.091018] run_timer_softirq+0x411/0x460
> > [ 9041.105017] __do_softirq+0x115/0x311
> > [ 9041.109103] irq_exit+0xb0/0xc0
> > [ 9041.112605] smp_apic_timer_interrupt+0x67/0x140
> >
> > Signed-off-by: Liu Changcheng <changcheng.liu@intel.com>
> >
>
> On which kernel have you seen this problem ?
[Changcheng]: My kernel is 4.16.0 Fearless Coyote
>
> In networking, we want patches with a 'Fixes:' tag to clearly identify which patch
> added a regression.
>
>
> Anyway your patch comes too late I guess
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=bffd168c3fc5cc7d2bad4c668fa90e7a9010db4b
[Changcheng]: Check upstream master kernel(head: 87ef12027b9b1), patch
isn't merged yet. I'll check it in my side.
>
>
^ permalink raw reply
* [PATCH v3 3/3] dt-bindings: Document the DT bindings for lan78xx
From: Phil Elwell @ 2018-04-19 14:32 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1524148325-78945-1-git-send-email-phil@raspberrypi.org>
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in a bindings file.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
.../devicetree/bindings/net/microchip,lan78xx.txt | 54 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 0000000..a5d701b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,54 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+The Device Tree properties, if present, override the OTP and EEPROM.
+
+Required properties:
+- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
+
+Optional properties:
+- local-mac-address: see ethernet.txt
+- mac-address: see ethernet.txt
+
+Optional properties of the embedded PHY:
+- microchip,led-modes: a 0..4 element vector, with each element configuring
+ the operating mode of an LED. Omitted LEDs are turned off. Allowed values
+ are defined in "include/dt-bindings/net/microchip-lan78xx.h".
+
+Example:
+
+/* Based on the configuration for a Raspberry Pi 3 B+ */
+&usb {
+ usb1@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb1_1@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb424,7800";
+ reg = <1>;
+ local-mac-address = [ 00 11 22 33 44 55 ];
+
+ mdio {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ eth_phy: ethernet-phy@1 {
+ reg = <1>;
+ microchip,led-modes = <
+ LAN78XX_LINK_1000_ACTIVITY
+ LAN78XX_LINK_10_100_ACTIVITY
+ >;
+ };
+ };
+ };
+ };
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 23735d9..91cb961 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14572,6 +14572,7 @@ M: Woojung Huh <woojung.huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
F: drivers/net/usb/lan78xx.*
F: include/dt-bindings/net/microchip-lan78xx.h
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] lan78xx: Read LED states from Device Tree
From: Phil Elwell @ 2018-04-19 14:32 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1524148325-78945-1-git-send-email-phil@raspberrypi.org>
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/activity 5=link10/1000/activity
6=link10/100/activity 14=off 15=on
These values are given symbolic constants in a dt-bindings header.
Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
MAINTAINERS | 1 +
drivers/net/phy/microchip.c | 25 ++++++++++++++++++++++
drivers/net/usb/lan78xx.c | 32 ++++++++++++++++++++++++++++-
include/dt-bindings/net/microchip-lan78xx.h | 21 +++++++++++++++++++
include/linux/microchipphy.h | 3 +++
5 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d..23735d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14573,6 +14573,7 @@ M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/usb/lan78xx.*
+F: include/dt-bindings/net/microchip-lan78xx.h
USB MASS STORAGE DRIVER
M: Alan Stern <stern@rowland.harvard.edu>
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 0f293ef..ef5e160 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -20,6 +20,8 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/microchipphy.h>
+#include <linux/of.h>
+#include <dt-bindings/net/microchip-lan78xx.h>
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
#define DRIVER_DESC "Microchip LAN88XX PHY driver"
@@ -70,6 +72,8 @@ static int lan88xx_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
struct lan88xx_priv *priv;
+ u32 led_modes[4];
+ int len;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -77,6 +81,27 @@ static int lan88xx_probe(struct phy_device *phydev)
priv->wolopts = 0;
+ len = of_property_read_variable_u32_array(dev->of_node,
+ "microchip,led-modes",
+ led_modes,
+ 0,
+ ARRAY_SIZE(led_modes));
+ if (len >= 0) {
+ u32 reg = 0;
+ int i;
+
+ for (i = 0; i < len; i++) {
+ if (led_modes[i] > 15)
+ return -EINVAL;
+ reg |= led_modes[i] << (i * 4);
+ }
+ for (; i < ARRAY_SIZE(led_modes); i++)
+ reg |= LAN78XX_FORCE_LED_OFF << (i * 4);
+ (void)phy_write(phydev, LAN78XX_PHY_LED_MODE_SELECT, reg);
+ } else if (len == -EOVERFLOW) {
+ return -EINVAL;
+ }
+
/* these values can be used to identify internal PHY */
priv->chip_id = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_ID);
priv->chip_rev = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_REV);
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a823f01..6b03b97 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/microchipphy.h>
#include <linux/phy.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "lan78xx.h"
@@ -1760,6 +1761,7 @@ static int lan78xx_mdiobus_write(struct mii_bus *bus, int phy_id, int idx,
static int lan78xx_mdio_init(struct lan78xx_net *dev)
{
+ struct device_node *node;
int ret;
dev->mdiobus = mdiobus_alloc();
@@ -1788,7 +1790,13 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
break;
}
- ret = mdiobus_register(dev->mdiobus);
+ node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
+ if (node) {
+ ret = of_mdiobus_register(dev->mdiobus, node);
+ of_node_put(node);
+ } else {
+ ret = mdiobus_register(dev->mdiobus);
+ }
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
@@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
+ if (phydev->mdio.dev.of_node) {
+ u32 reg;
+ int len;
+
+ len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
+ "microchip,led-modes",
+ sizeof(u32));
+ if (len >= 0) {
+ /* Ensure the appropriate LEDs are enabled */
+ lan78xx_read_reg(dev, HW_CFG, ®);
+ reg &= ~(HW_CFG_LED0_EN_ |
+ HW_CFG_LED1_EN_ |
+ HW_CFG_LED2_EN_ |
+ HW_CFG_LED3_EN_);
+ reg |= (len > 0) * HW_CFG_LED0_EN_ |
+ (len > 1) * HW_CFG_LED1_EN_ |
+ (len > 2) * HW_CFG_LED2_EN_ |
+ (len > 3) * HW_CFG_LED3_EN_;
+ lan78xx_write_reg(dev, HW_CFG, reg);
+ }
+ }
+
genphy_config_aneg(phydev);
dev->fc_autoneg = phydev->autoneg;
diff --git a/include/dt-bindings/net/microchip-lan78xx.h b/include/dt-bindings/net/microchip-lan78xx.h
new file mode 100644
index 0000000..0742ff0
--- /dev/null
+++ b/include/dt-bindings/net/microchip-lan78xx.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_MICROCHIP_LAN78XX_H
+#define _DT_BINDINGS_MICROCHIP_LAN78XX_H
+
+/* LED modes for LAN7800/LAN7850 embedded PHY */
+
+#define LAN78XX_LINK_ACTIVITY 0
+#define LAN78XX_LINK_1000_ACTIVITY 1
+#define LAN78XX_LINK_100_ACTIVITY 2
+#define LAN78XX_LINK_10_ACTIVITY 3
+#define LAN78XX_LINK_100_1000_ACTIVITY 4
+#define LAN78XX_LINK_10_1000_ACTIVITY 5
+#define LAN78XX_LINK_10_100_ACTIVITY 6
+#define LAN78XX_DUPLEX_COLLISION 8
+#define LAN78XX_COLLISION 9
+#define LAN78XX_ACTIVITY 10
+#define LAN78XX_AUTONEG_FAULT 12
+#define LAN78XX_FORCE_LED_OFF 14
+#define LAN78XX_FORCE_LED_ON 15
+
+#endif
diff --git a/include/linux/microchipphy.h b/include/linux/microchipphy.h
index eb492d4..8e4015e 100644
--- a/include/linux/microchipphy.h
+++ b/include/linux/microchipphy.h
@@ -70,4 +70,7 @@
#define LAN88XX_MMD3_CHIP_ID (32877)
#define LAN88XX_MMD3_CHIP_REV (32878)
+/* Registers specific to the LAN7800/LAN7850 embedded phy */
+#define LAN78XX_PHY_LED_MODE_SELECT (0x1D)
+
#endif /* _MICROCHIPPHY_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] lan78xx: Read MAC address from DT if present
From: Phil Elwell @ 2018-04-19 14:32 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1524148325-78945-1-git-send-email-phil@raspberrypi.org>
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
drivers/net/usb/lan78xx.c | 42 ++++++++++++++++++++----------------------
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0867f72..a823f01 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/microchipphy.h>
#include <linux/phy.h>
+#include <linux/of_net.h>
#include "lan78xx.h"
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
@@ -1652,34 +1653,31 @@ static void lan78xx_init_mac_address(struct lan78xx_net *dev)
addr[5] = (addr_hi >> 8) & 0xFF;
if (!is_valid_ether_addr(addr)) {
- /* reading mac address from EEPROM or OTP */
- if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0) ||
- (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
- if (is_valid_ether_addr(addr)) {
- /* eeprom values are valid so use them */
- netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
- } else {
- /* generate random MAC */
- random_ether_addr(addr);
- netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
- }
-
- addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
- addr_hi = addr[4] | (addr[5] << 8);
-
- ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
- ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+ if (!eth_platform_get_mac_address(&dev->udev->dev, addr)) {
+ /* valid address present in Device Tree */
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+ } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0) ||
+ (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+ is_valid_ether_addr(addr)) {
+ /* eeprom values are valid so use them */
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
"MAC address set to random addr");
}
+
+ addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+ addr_hi = addr[4] | (addr[5] << 8);
+
+ ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+ ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/3] lan78xx: Read configuration from Device Tree
From: Phil Elwell @ 2018-04-19 14:32 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
In-Reply-To: <1524148325-78945-1-git-send-email-phil@raspberrypi.org>
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for reading the MAC address and LED modes from
Device Tree.
v3:
- Move LED setting into PHY driver.
v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.
Phil Elwell (3):
lan78xx: Read MAC address from DT if present
lan78xx: Read LED states from Device Tree
dt-bindings: Document the DT bindings for lan78xx
.../devicetree/bindings/net/microchip,lan78xx.txt | 54 ++++++++++++++++
MAINTAINERS | 2 +
drivers/net/phy/microchip.c | 25 ++++++++
drivers/net/usb/lan78xx.c | 74 +++++++++++++++-------
include/dt-bindings/net/microchip-lan78xx.h | 21 ++++++
include/linux/microchipphy.h | 3 +
6 files changed, 156 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
--
2.7.4
^ permalink raw reply
* [PATCH v3 0/3] lan78xx: Read configuration from Device Tree
From: Phil Elwell @ 2018-04-19 14:32 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, David S. Miller, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Linus Walleij, Andrew Morton, Randy Dunlap,
netdev, devicetree, linux-kernel, linux-usb
Cc: Phil Elwell
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for reading the MAC address and LED modes from
Device Tree.
v3:
- Move LED setting into PHY driver.
v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.
Phil Elwell (3):
lan78xx: Read MAC address from DT if present
lan78xx: Read LED states from Device Tree
dt-bindings: Document the DT bindings for lan78xx
.../devicetree/bindings/net/microchip,lan78xx.txt | 54 ++++++++++++++++
MAINTAINERS | 2 +
drivers/net/phy/microchip.c | 25 ++++++++
drivers/net/usb/lan78xx.c | 74 +++++++++++++++-------
include/dt-bindings/net/microchip-lan78xx.h | 21 ++++++
include/linux/microchipphy.h | 3 +
6 files changed, 156 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel
From: Rahul Lakkireddy @ 2018-04-19 14:27 UTC (permalink / raw)
To: Dave Young
Cc: netdev@vger.kernel.org, kexec@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Indranil Choudhury, Nirranjan Kirubaharan,
stephen@networkplumber.org, Ganesh GR, ebiederm@xmission.com,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
davem@davemloft.net, viro@zeniv.linux.org.uk
In-Reply-To: <20180419014030.GA2340@dhcp-128-65.nay.redhat.com>
On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> > > Hi Rahul,
> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> > > > On production servers running variety of workloads over time, kernel
> > > > panic can happen sporadically after days or even months. It is
> > > > important to collect as much debug logs as possible to root cause
> > > > and fix the problem, that may not be easy to reproduce. Snapshot of
> > > > underlying hardware/firmware state (like register dump, firmware
> > > > logs, adapter memory, etc.), at the time of kernel panic will be very
> > > > helpful while debugging the culprit device driver.
> > > >
> > > > This series of patches add new generic framework that enable device
> > > > drivers to collect device specific snapshot of the hardware/firmware
> > > > state of the underlying device in the crash recovery kernel. In crash
> > > > recovery kernel, the collected logs are added as elf notes to
> > > > /proc/vmcore, which is copied by user space scripts for post-analysis.
> > > >
> > > > The sequence of actions done by device drivers to append their device
> > > > specific hardware/firmware logs to /proc/vmcore are as follows:
> > > >
> > > > 1. During probe (before hardware is initialized), device drivers
> > > > register to the vmcore module (via vmcore_add_device_dump()), with
> > > > callback function, along with buffer size and log name needed for
> > > > firmware/hardware log collection.
> > >
> > > I assumed the elf notes info should be prepared while kexec_[file_]load
> > > phase. But I did not read the old comment, not sure if it has been discussed
> > > or not.
> > >
> >
> > We must not collect dumps in crashing kernel. Adding more things in
> > crash dump path risks not collecting vmcore at all. Eric had
> > discussed this in more detail at:
> >
> > https://lkml.org/lkml/2018/3/24/319
> >
> > We are safe to collect dumps in the second kernel. Each device dump
> > will be exported as an elf note in /proc/vmcore.
>
> I understand that we should avoid adding anything in crash path. And I also
> agree to collect device dump in second kernel. I just assumed device
> dump use some memory area to store the debug info and the memory
> is persistent so that this can be done in 2 steps, first register the
> address in elf header in kexec_load, then collect the dump in 2nd
> kernel. But it seems the driver is doing some other logic to collect
> the info instead of just that simple like I thought.
>
It seems simpler, but I'm concerned with waste of memory area, if
there are no device dumps being collected in second kernel. In
approach proposed in these series, we dynamically allocate memory
for the device dumps from second kernel's available memory.
> >
> > > If do this in 2nd kernel a question is driver can be loaded later than vmcore init.
> >
> > Yes, drivers will add their device dumps after vmcore init.
> >
> > > How to guarantee the function works if vmcore reading happens before
> > > the driver is loaded?
> > >
> > > Also it is possible that kdump initramfs does not contains the driver
> > > module.
> > >
> > > Am I missing something?
> > >
> >
> > Yes, driver must be in initramfs if it wants to collect and add device
> > dump to /proc/vmcore in second kernel.
>
> In RH/Fedora kdump scripts we only add the things are required to
> bring up the dump target, so that we can use as less memory as we can.
>
> For example, if a net driver panicked, and the dump target is rootfs
> which is a scsi disk, then no network related stuff will be added in
> initramfs.
>
> In this case the device dump info will be not collected..
Correct. If the driver is not present in initramfs, it can't collect
its underlying device's dump. Administrator is expected to add the
driver to initramfs, if device dump needs to be collected.
> >
> > > >
> > > > 2. vmcore module allocates the buffer with requested size. It adds
> > > > an elf note and invokes the device driver's registered callback
> > > > function.
> > > >
> > > > 3. Device driver collects all hardware/firmware logs into the buffer
> > > > and returns control back to vmcore module.
> > > >
> > > > The device specific hardware/firmware logs can be seen as elf notes:
> > > >
> > > > # readelf -n /proc/vmcore
> > > >
> > > > Displaying notes found at file offset 0x00001000 with length 0x04003288:
> > > > Owner Data size Description
> > > > VMCOREDD_cxgb4_0000:02:00.4 0x02000fd8 Unknown note type: (0x00000700)
> > > > VMCOREDD_cxgb4_0000:04:00.4 0x02000fd8 Unknown note type: (0x00000700)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > CORE 0x00000150 NT_PRSTATUS (prstatus structure)
> > > > VMCOREINFO 0x0000074f Unknown note type: (0x00000000)
> > > >
> > > > Patch 1 adds API to vmcore module to allow drivers to register callback
> > > > to collect the device specific hardware/firmware logs. The logs will
> > > > be added to /proc/vmcore as elf notes.
> > > >
> > > > Patch 2 updates read and mmap logic to append device specific hardware/
> > > > firmware logs as elf notes.
> > > >
> > > > Patch 3 shows a cxgb4 driver example using the API to collect
> > > > hardware/firmware logs in crash recovery kernel, before hardware is
> > > > initialized.
> > > >
> > > > Thanks,
> > > > Rahul
> > > >
> > > > RFC v1: https://lkml.org/lkml/2018/3/2/542
> > > > RFC v2: https://lkml.org/lkml/2018/3/16/326
> > > >
Thanks,
Rahul
^ permalink raw reply
* [PATCH net] l2tp: fix {pppol2tp,l2tp_dfs}_seq_stop() in case of seq_file overflow
From: Guillaume Nault @ 2018-04-19 14:20 UTC (permalink / raw)
To: netdev; +Cc: James Chapman
Commit 0e0c3fee3a59 ("l2tp: hold reference on tunnels printed in pppol2tp proc file")
assumed that if pppol2tp_seq_stop() was called with non-NULL private
data (the 'v' pointer), then pppol2tp_seq_start() would not be called
again. It turns out that this isn't guaranteed, and overflowing the
seq_file's buffer in pppol2tp_seq_show() is a way to get into this
situation.
Therefore, pppol2tp_seq_stop() needs to reset pd->tunnel, so that
pppol2tp_seq_start() won't drop a reference again if it gets called.
We also have to clear pd->session, because the rest of the code expects
a non-NULL tunnel when pd->session is set.
The l2tp_debugfs module has the same issue. Fix it in the same way.
Fixes: 0e0c3fee3a59 ("l2tp: hold reference on tunnels printed in pppol2tp proc file")
Fixes: f726214d9b23 ("l2tp: hold reference on tunnels printed in l2tp/tunnels debugfs file")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
---
net/l2tp/l2tp_debugfs.c | 5 ++++-
net/l2tp/l2tp_ppp.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
Reproduced by tweaking .show() to write overly long data.
I don't believe the bug can be triggered in practice, but this
behaviour is part of the seq_file API and the fix doesn't increase
complexity.
diff --git a/net/l2tp/l2tp_debugfs.c b/net/l2tp/l2tp_debugfs.c
index b8f9d45bfeb1..7f1e842ef05a 100644
--- a/net/l2tp/l2tp_debugfs.c
+++ b/net/l2tp/l2tp_debugfs.c
@@ -106,8 +106,11 @@ static void l2tp_dfs_seq_stop(struct seq_file *p, void *v)
return;
/* Drop reference taken by last invocation of l2tp_dfs_next_tunnel() */
- if (pd->tunnel)
+ if (pd->tunnel) {
l2tp_tunnel_dec_refcount(pd->tunnel);
+ pd->tunnel = NULL;
+ pd->session = NULL;
+ }
}
static void l2tp_dfs_seq_tunnel_show(struct seq_file *m, void *v)
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 7d0c963680e6..1404bc1c1bb7 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -1618,8 +1618,11 @@ static void pppol2tp_seq_stop(struct seq_file *p, void *v)
return;
/* Drop reference taken by last invocation of pppol2tp_next_tunnel() */
- if (pd->tunnel)
+ if (pd->tunnel) {
l2tp_tunnel_dec_refcount(pd->tunnel);
+ pd->tunnel = NULL;
+ pd->session = NULL;
+ }
}
static void pppol2tp_seq_tunnel_show(struct seq_file *m, void *v)
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 03/39] proc: introduce proc_create_seq_private
From: Dan Carpenter @ 2018-04-19 14:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, devel,
Corey Minyard, linux-scsi, linux-acpi, Greg Kroah-Hartman,
Jiri Slaby, megaraidlinux.pdl, linux-kernel, Alexey Dobriyan,
linux-ide, netfilter-devel, Alexander Viro, netdev, Andrew Morton,
linux-ext4, linux-afs, jfs-discussion, drbd-dev
In-Reply-To: <20180419124140.9309-4-hch@lst.de>
On Thu, Apr 19, 2018 at 02:41:04PM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/s390/cio/blacklist.c b/drivers/s390/cio/blacklist.c
> index 2a3f874a21d5..ad35cddcf6af 100644
> --- a/drivers/s390/cio/blacklist.c
> +++ b/drivers/s390/cio/blacklist.c
> @@ -391,28 +391,15 @@ static const struct seq_operations cio_ignore_proc_seq_ops = {
> .show = cio_ignore_proc_seq_show,
> };
>
> -static int
> -cio_ignore_proc_open(struct inode *inode, struct file *file)
> -{
> - return seq_open_private(file, &cio_ignore_proc_seq_ops,
> - sizeof(struct ccwdev_iter));
> -}
> -
> -static const struct file_operations cio_ignore_proc_fops = {
> - .open = cio_ignore_proc_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = seq_release_private,
> - .write = cio_ignore_write,
^^^^^^^^^^^^^^^^
The cio_ignore_write() function isn't used any more so compilers will
complain.
> -};
> -
> static int
> cio_ignore_proc_init (void)
> {
> struct proc_dir_entry *entry;
>
> - entry = proc_create("cio_ignore", S_IFREG | S_IRUGO | S_IWUSR, NULL,
> - &cio_ignore_proc_fops);
> + entry = proc_create_seq_private("cio_ignore",
> + S_IFREG | S_IRUGO | S_IWUSR, NULL,
> + &cio_ignore_proc_seq_ops, sizeof(struct ccwdev_iter),
> + NULL);
> if (!entry)
> return -ENOENT;
> return 0;
regards,
dan carpenter
^ permalink raw reply
* [net-next PATCH] bpf: reserve xdp_frame size in xdp headroom
From: Jesper Dangaard Brouer @ 2018-04-19 14:17 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov; +Cc: netdev, Jesper Dangaard Brouer
Commit 6dfb970d3dbd ("xdp: avoid leaking info stored in frame data on
page reuse") tried to allow user/bpf_prog to (re)use area used by
xdp_frame (stored in frame headroom), by memset clearing area when
bpf_xdp_adjust_head give bpf_prog access to headroom area.
The mentioned commit had two bugs. (1) Didn't take bpf_xdp_adjust_meta
into account. (2) a combination of bpf_xdp_adjust_head calls, where
xdp->data is moved into xdp_frame section, can cause clearing
xdp_frame area again for area previously granted to bpf_prog.
After discussions with Daniel, we choose to implement a simpler
solution to the problem, which is to reserve the headroom used by
xdp_frame info.
This also avoids the situation where bpf_prog is allowed to adjust/add
headers, and then XDP_REDIRECT later drops the packet due to lack of
headroom for the xdp_frame. This would likely confuse the end-user.
Fixes: 6dfb970d3dbd ("xdp: avoid leaking info stored in frame data on page reuse")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/filter.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index a374b8560bc4..6398d2443f9f 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2694,20 +2694,13 @@ BPF_CALL_2(bpf_xdp_adjust_head, struct xdp_buff *, xdp, int, offset)
{
void *xdp_frame_end = xdp->data_hard_start + sizeof(struct xdp_frame);
unsigned long metalen = xdp_get_metalen(xdp);
- void *data_start = xdp->data_hard_start + metalen;
+ void *data_start = xdp_frame_end + metalen;
void *data = xdp->data + offset;
if (unlikely(data < data_start ||
data > xdp->data_end - ETH_HLEN))
return -EINVAL;
- /* Avoid info leak, when reusing area prev used by xdp_frame */
- if (data < xdp_frame_end) {
- unsigned long clearlen = xdp_frame_end - data;
-
- memset(data, 0, clearlen);
- }
-
if (metalen)
memmove(xdp->data_meta + offset,
xdp->data_meta, metalen);
@@ -2727,12 +2720,13 @@ static const struct bpf_func_proto bpf_xdp_adjust_head_proto = {
BPF_CALL_2(bpf_xdp_adjust_meta, struct xdp_buff *, xdp, int, offset)
{
+ void *xdp_frame_end = xdp->data_hard_start + sizeof(struct xdp_frame);
void *meta = xdp->data_meta + offset;
unsigned long metalen = xdp->data - meta;
if (xdp_data_meta_unsupported(xdp))
return -ENOTSUPP;
- if (unlikely(meta < xdp->data_hard_start ||
+ if (unlikely(meta < xdp_frame_end ||
meta > xdp->data))
return -EINVAL;
if (unlikely((metalen & (sizeof(__u32) - 1)) ||
^ permalink raw reply related
* [PATCH 00/61] tree-wide: simplify getting .drvdata
From: Wolfram Sang @ 2018-04-19 14:05 UTC (permalink / raw)
To: linux-kernel
Cc: linux-renesas-soc, kernel-janitors, Wolfram Sang, ac100,
acpi4asus-user, alsa-devel, devel, dmaengine, dri-devel,
freedreno, greybus-dev, iommu, linux-arm-kernel, linux-arm-msm,
linux-clk, linux-crypto, linux-fbdev, linux-gpio, linux-ide,
linux-iio, linux-input, linux-mediatek, linux-media, linux-mmc,
linux-mtd
I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:
- struct platform_device *pdev = to_platform_device(dev);
- struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+ struct ep93xx_keypad *keypad = dev_get_drvdata(dev);
I send this out as one patch per directory per subsystem. I think they should
be applied individually. If you prefer a broken out series per subsystem, I can
provide this as well. Just mail me.
A branch (tested by buildbot; only with all commits squashed into one commit
before) can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git coccinelle/get_drvdata
Open for other comments, suggestions, too, of course.
Here is the cocci-script I created (after <n> iterations by manually checking
samples):
@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
- struct platform_device *pdev = to_platform_device(d);
|
- struct platform_device *pdev;
...
- pdev = to_platform_device(d);
)
<... when != pdev
- &pdev->dev
+ d
...>
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- &pdev->dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (61):
ARM: plat-samsung: simplify getting .drvdata
ata: simplify getting .drvdata
auxdisplay: simplify getting .drvdata
bus: simplify getting .drvdata
clk: samsung: simplify getting .drvdata
crypto: simplify getting .drvdata
dma: simplify getting .drvdata
dmaengine: dw: simplify getting .drvdata
dmaengine: qcom: simplify getting .drvdata
gpio: simplify getting .drvdata
gpu: drm: msm: simplify getting .drvdata
gpu: drm: msm: adreno: simplify getting .drvdata
gpu: drm: msm: disp: mdp5: simplify getting .drvdata
gpu: drm: msm: dsi: simplify getting .drvdata
gpu: drm: omapdrm: displays: simplify getting .drvdata
gpu: drm: vc4: simplify getting .drvdata
hid: simplify getting .drvdata
iio: common: cros_ec_sensors: simplify getting .drvdata
iio: common: hid-sensors: simplify getting .drvdata
input: keyboard: simplify getting .drvdata
input: misc: simplify getting .drvdata
input: mouse: simplify getting .drvdata
input: touchscreen: simplify getting .drvdata
iommu: simplify getting .drvdata
media: platform: am437x: simplify getting .drvdata
media: platform: exynos4-is: simplify getting .drvdata
media: platform: s5p-mfc: simplify getting .drvdata
mmc: host: simplify getting .drvdata
mtd: devices: simplify getting .drvdata
mtd: nand: onenand: simplify getting .drvdata
net: dsa: simplify getting .drvdata
net: ethernet: cadence: simplify getting .drvdata
net: ethernet: davicom: simplify getting .drvdata
net: ethernet: smsc: simplify getting .drvdata
net: ethernet: ti: simplify getting .drvdata
net: ethernet: wiznet: simplify getting .drvdata
perf: simplify getting .drvdata
pinctrl: simplify getting .drvdata
pinctrl: intel: simplify getting .drvdata
platform: x86: simplify getting .drvdata
power: supply: simplify getting .drvdata
ptp: simplify getting .drvdata
pwm: simplify getting .drvdata
rtc: simplify getting .drvdata
slimbus: simplify getting .drvdata
spi: simplify getting .drvdata
staging: greybus: simplify getting .drvdata
staging: iio: adc: simplify getting .drvdata
staging: nvec: simplify getting .drvdata
thermal: simplify getting .drvdata
thermal: int340x_thermal: simplify getting .drvdata
thermal: st: simplify getting .drvdata
tty: serial: simplify getting .drvdata
uio: simplify getting .drvdata
usb: mtu3: simplify getting .drvdata
usb: phy: simplify getting .drvdata
video: fbdev: simplify getting .drvdata
video: fbdev: omap2: omapfb: displays: simplify getting .drvdata
watchdog: simplify getting .drvdata
net: dsa: simplify getting .drvdata
ASoC: atmel: simplify getting .drvdata
arch/arm/plat-samsung/adc.c | 3 +-
drivers/ata/pata_samsung_cf.c | 8 ++---
drivers/auxdisplay/arm-charlcd.c | 6 ++--
drivers/bus/brcmstb_gisb.c | 12 +++----
drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++--
drivers/crypto/exynos-rng.c | 6 ++--
drivers/crypto/picoxcell_crypto.c | 6 ++--
drivers/dma/at_hdmac.c | 9 ++---
drivers/dma/at_xdmac.c | 9 ++---
drivers/dma/dw/platform.c | 6 ++--
drivers/dma/fsldma.c | 6 ++--
drivers/dma/idma64.c | 6 ++--
drivers/dma/qcom/hidma.c | 3 +-
drivers/dma/qcom/hidma_mgmt_sys.c | 6 ++--
drivers/dma/ste_dma40.c | 12 +++----
drivers/dma/txx9dmac.c | 8 ++---
drivers/gpio/gpio-dwapb.c | 6 ++--
drivers/gpio/gpio-lynxpoint.c | 3 +-
drivers/gpio/gpio-omap.c | 12 +++----
drivers/gpio/gpio-tegra.c | 6 ++--
drivers/gpio/gpio-zynq.c | 6 ++--
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 ++--
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 ++--
drivers/gpu/drm/msm/msm_drv.c | 3 +-
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 18 ++++------
drivers/gpu/drm/vc4/vc4_drv.c | 3 +-
drivers/hid/hid-sensor-custom.c | 12 +++----
.../common/cros_ec_sensors/cros_ec_sensors_core.c | 6 ++--
.../iio/common/hid-sensors/hid-sensor-trigger.c | 9 ++---
drivers/input/keyboard/ep93xx_keypad.c | 10 +++---
drivers/input/keyboard/imx_keypad.c | 10 +++---
drivers/input/keyboard/lpc32xx-keys.c | 6 ++--
drivers/input/keyboard/matrix_keypad.c | 10 +++---
drivers/input/keyboard/omap4-keypad.c | 10 +++---
drivers/input/keyboard/pmic8xxx-keypad.c | 6 ++--
drivers/input/keyboard/pxa27x_keypad.c | 10 +++---
drivers/input/keyboard/samsung-keypad.c | 12 +++----
drivers/input/keyboard/snvs_pwrkey.c | 10 +++---
drivers/input/keyboard/spear-keyboard.c | 10 +++---
drivers/input/keyboard/st-keyscan.c | 6 ++--
drivers/input/keyboard/tegra-kbc.c | 10 +++---
drivers/input/misc/max77693-haptic.c | 6 ++--
drivers/input/misc/max8997_haptic.c | 3 +-
drivers/input/misc/palmas-pwrbutton.c | 6 ++--
drivers/input/misc/regulator-haptic.c | 6 ++--
drivers/input/misc/twl4030-vibra.c | 3 +-
drivers/input/misc/twl6040-vibra.c | 3 +-
drivers/input/mouse/navpoint.c | 6 ++--
drivers/input/touchscreen/imx6ul_tsc.c | 6 ++--
drivers/iommu/qcom_iommu.c | 6 ++--
drivers/media/platform/am437x/am437x-vpfe.c | 6 ++--
drivers/media/platform/exynos4-is/media-dev.c | 6 ++--
drivers/media/platform/exynos4-is/mipi-csis.c | 6 ++--
drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 ++--
drivers/mmc/host/davinci_mmc.c | 6 ++--
drivers/mmc/host/sdhci-of-arasan.c | 6 ++--
drivers/mmc/host/wmt-sdmmc.c | 6 ++--
drivers/mtd/devices/docg3.c | 3 +-
drivers/mtd/nand/onenand/samsung.c | 6 ++--
drivers/net/dsa/bcm_sf2.c | 6 ++--
drivers/net/dsa/qca8k.c | 6 ++--
drivers/net/ethernet/cadence/macb_main.c | 6 ++--
drivers/net/ethernet/davicom/dm9000.c | 6 ++--
drivers/net/ethernet/smsc/smc91x.c | 3 +-
drivers/net/ethernet/ti/cpsw.c | 6 ++--
drivers/net/ethernet/ti/davinci_emac.c | 6 ++--
drivers/net/ethernet/wiznet/w5300.c | 6 ++--
drivers/perf/arm_spe_pmu.c | 6 ++--
drivers/pinctrl/intel/pinctrl-baytrail.c | 6 ++--
drivers/pinctrl/intel/pinctrl-cherryview.c | 6 ++--
drivers/pinctrl/intel/pinctrl-intel.c | 6 ++--
drivers/pinctrl/pinctrl-amd.c | 6 ++--
drivers/pinctrl/pinctrl-at91-pio4.c | 6 ++--
drivers/platform/x86/asus-laptop.c | 3 +-
drivers/platform/x86/asus-wmi.c | 3 +-
drivers/platform/x86/samsung-laptop.c | 3 +-
drivers/power/supply/gpio-charger.c | 3 +-
drivers/ptp/ptp_dte.c | 6 ++--
drivers/pwm/pwm-atmel-tcb.c | 6 ++--
drivers/pwm/pwm-rcar.c | 3 +-
drivers/rtc/rtc-bq4802.c | 6 ++--
drivers/rtc/rtc-ds1216.c | 6 ++--
drivers/rtc/rtc-ds1511.c | 9 ++---
drivers/rtc/rtc-ds1553.c | 15 +++-----
drivers/rtc/rtc-ds1685.c | 21 ++++-------
drivers/rtc/rtc-ds1742.c | 6 ++--
drivers/rtc/rtc-lpc32xx.c | 16 ++++-----
drivers/rtc/rtc-m48t59.c | 41 +++++++++-------------
drivers/rtc/rtc-mv.c | 3 +-
drivers/rtc/rtc-mxc.c | 21 ++++-------
drivers/rtc/rtc-pcap.c | 15 +++-----
drivers/rtc/rtc-sh.c | 15 +++-----
drivers/rtc/rtc-stk17ta8.c | 15 +++-----
drivers/rtc/rtc-test.c | 3 +-
drivers/rtc/rtc-zynqmp.c | 10 +++---
drivers/slimbus/qcom-ctrl.c | 6 ++--
drivers/spi/spi-cadence.c | 6 ++--
drivers/spi/spi-zynqmp-gqspi.c | 6 ++--
drivers/staging/greybus/arche-platform.c | 3 +-
drivers/staging/iio/adc/ad7606_par.c | 6 ++--
drivers/staging/nvec/nvec.c | 6 ++--
drivers/thermal/int340x_thermal/int3400_thermal.c | 9 ++---
drivers/thermal/rockchip_thermal.c | 8 ++---
drivers/thermal/spear_thermal.c | 8 ++---
drivers/thermal/st/st_thermal.c | 6 ++--
drivers/thermal/zx2967_thermal.c | 6 ++--
drivers/tty/serial/imx.c | 18 ++++------
drivers/tty/serial/qcom_geni_serial.c | 6 ++--
drivers/tty/serial/st-asc.c | 6 ++--
drivers/tty/serial/xilinx_uartps.c | 6 ++--
drivers/uio/uio_fsl_elbc_gpcm.c | 6 ++--
drivers/usb/mtu3/mtu3_plat.c | 6 ++--
drivers/usb/phy/phy-am335x.c | 6 ++--
drivers/video/fbdev/auo_k190x.c | 12 +++----
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 18 ++++------
drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 ++--
drivers/video/fbdev/sh_mobile_meram.c | 6 ++--
drivers/watchdog/cadence_wdt.c | 6 ++--
drivers/watchdog/of_xilinx_wdt.c | 6 ++--
drivers/watchdog/wdat_wdt.c | 6 ++--
net/dsa/legacy.c | 6 ++--
sound/soc/atmel/atmel_ssc_dai.c | 6 ++--
123 files changed, 319 insertions(+), 607 deletions(-)
--
2.11.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox