* Re: [PATCH] net: eth: realtek: atp: checkpatch errors and warnings corrected
From: Roberto Medina @ 2014-11-05 7:44 UTC (permalink / raw)
To: David Laight, Joe Perches
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9E71E4@AcuExch.aculab.com>
On 11/04/2014 11:19 AM, David Laight wrote:
>
> That code (and all the ones below) are gibberish, neither the old or new
> sequences make any sense.
>
Thank you for your feedback I did it again and objdiff doesn't show any
changes (if I'm not mistaken).
> Almost as though you used the wrong instruction set!
>
> David
diff -Nurd
/home/vov/Git/linux-next/.tmp_objdiff/a641d0e/drivers/net/ethernet/realtek/atp.dis
/home/vov/Git/linux-next/.tmp_objdiff/5f19b70/drivers/net/ethernet/realtek/atp.dis
---
/home/vov/Git/linux-next/.tmp_objdiff/a641d0e/drivers/net/ethernet/realtek/atp.dis
2014-11-05 08:38:49.244100507 +0100
+++
/home/vov/Git/linux-next/.tmp_objdiff/5f19b70/drivers/net/ethernet/realtek/atp.dis
2014-11-05 08:39:14.654101606 +0100
@@ -1357,7 +1357,7 @@
Disassembly of section .bss:
-00000000 <num_tx_since_rx.36127>:
+00000000 <num_tx_since_rx.36172>:
: 00 00 add %al,(%eax)
...
Thanks,
Roberto
^ permalink raw reply
* [PATCH V2 2/4] can: m_can: workaround for transmit data less than 4 bytes
From: Dong Aisheng @ 2014-11-05 7:58 UTC (permalink / raw)
To: linux-can
Cc: mkl, wg, varkabhadram, netdev, socketcan, b29396,
linux-arm-kernel
In-Reply-To: <1415174326-6623-1-git-send-email-b29396@freescale.com>
At least on the i.MX6SX with M_CAN IP version 3.0.x, an issue with
the Message RAM was discovered. Sending CAN frames with dlc less
than 4 bytes will lead to bit errors, when the first 8 bytes of
the Message RAM have not been initialized (i.e. written to).
To work around this issue, the first 8 bytes are initialized in open()
function.
Without the workaround, we can easily see the following errors:
root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
[ 66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@imx6qdlsolo:~# cansend can0 123#112233
[ 66.935640] m_can 20e8000.can can0: Bit Error Uncorrected
Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
ChangeLog since v1:
* initialize the first 8 bytes of Tx Buffer of Message RAM in open()
to workaround the issue
---
drivers/net/can/m_can/m_can.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 664fe30..f47c200 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -902,6 +902,15 @@ static void m_can_chip_config(struct net_device *dev)
/* set bittiming params */
m_can_set_bittiming(dev);
+ /* At least on the i.MX6SX with M_CAN IP version 3.0.x, an issue with
+ * the Message RAM was discovered. Sending CAN frames with dlc less
+ * than 4 bytes will lead to bit errors, when the first 8 bytes of
+ * the Message RAM have not been initialized (i.e. written to).
+ * To work around this issue, the first 8 bytes are initialized here.
+ */
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
+
m_can_config_endisable(priv, false);
}
--
1.9.1
^ permalink raw reply related
* [PATCH RFC net] ip_tunnel: Respect the IP_DF bit of the inner packet.
From: Steffen Klassert @ 2014-11-05 8:09 UTC (permalink / raw)
To: netdev
The pmtu calculation depends on the IP_DF bit in tnl_update_pmtu().
If the IP_DF bit is set, the pmtu calculation is based on the outer
packet size. Otherwise it is based on the inner packet size.
If xfrm is used after tunneling through an ipip device, the mtu of
the outer device can be lower than the mtu of the ipip device.
Reporting the mtu of the ipip device is wrong in this case. So
respect the IP_DF bit of the inner packet on ipv4 to report the
calculated mtu of the outer device.
Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
I marked this as RFC because it affects the mtu calculation of
gre tunnels too. I think it should be ok, but I have no testcase
to confirm the correctness for gre tunnels. So would be good if
someone with gre knowlegde could look at this.
If it turns out that we can't do that for gre, we need to
split this code back into a gre and an ipip version.
net/ipv4/ip_tunnel.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 0bb8e14..f6f2d10 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -738,7 +738,11 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
goto tx_error;
}
- if (tnl_update_pmtu(dev, skb, rt, tnl_params->frag_off)) {
+ df = tnl_params->frag_off;
+ if (skb->protocol == htons(ETH_P_IP))
+ df |= (inner_iph->frag_off&htons(IP_DF));
+
+ if (tnl_update_pmtu(dev, skb, rt, df)) {
ip_rt_put(rt);
goto tx_error;
}
@@ -767,10 +771,6 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
ttl = ip4_dst_hoplimit(&rt->dst);
}
- df = tnl_params->frag_off;
- if (skb->protocol == htons(ETH_P_IP))
- df |= (inner_iph->frag_off&htons(IP_DF));
-
max_headroom = LL_RESERVED_SPACE(rt->dst.dev) + sizeof(struct iphdr)
+ rt->dst.header_len + ip_encap_hlen(&tunnel->encap);
if (max_headroom > dev->needed_headroom)
--
1.9.1
^ permalink raw reply related
* Bug#764162: [PATCH 0/1] mv643xx_eth: Disable TSO by default
From: Ian Campbell @ 2014-11-05 8:39 UTC (permalink / raw)
To: Karl Beldan
Cc: Ezequiel Garcia, netdev, David Miller, Thomas Petazzoni,
Gregory Clement, Tawfik Bayouk, Lior Amsalem, Nadav Haklai,
764162
In-Reply-To: <20141104142020.GA6728@magnum.frso.rivierawaves.com>
On Tue, 2014-11-04 at 15:20 +0100, Karl Beldan wrote:
> On Sat, Nov 01, 2014 at 12:30:19PM -0300, Ezequiel Garcia wrote:
> > Several users ([1], [2]) have been reporting data corruption with TSO on
> > Kirkwood platforms (i.e. using the mv643xx_eth driver).
> >
> > Until we manage to find what's causing this, this simple patch will make
> > the TSO path disabled by default. This patch should be queued for stable,
> > fixing the TSO feature introduced in v3.16.
> >
> > The corruption itself is very easy to reproduce: checking md5sum on a mounted
> > NFS directory gives a different result each time. Same tests using the mvneta
> > driver (Armada 370/38x/XP SoC) pass with no issues.
> >
> > Frankly, I'm a bit puzzled about this, and so any ideas or debugging hints
> > are well received.
> >
>
> Hi,
>
> Can you try this :
It fixes things for me, thanks!
Tested-by: Ian Campbell <ijc@hellion.org.uk>
> @@ -1067,7 +1082,8 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
> txq->tx_desc_count--;
>
> skb = NULL;
> - if (cmd_sts & TX_LAST_DESC)
> + if ((cmd_sts & (TX_LAST_DESC | TX_ENABLE_INTERRUPT)) ==
> + (TX_LAST_DESC | TX_ENABLE_INTERRUPT))
> skb = __skb_dequeue(&txq->tx_skb);
>
> if (cmd_sts & ERROR_SUMMARY) {
>
^ permalink raw reply
* Re: [PATCH] stmmac: fix sparse warnings
From: Andy Shevchenko @ 2014-11-05 9:03 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: netdev, Kweh Hock Leong, David S . Miller, Vince Bridgers
In-Reply-To: <54590045.3050305@st.com>
On Tue, 2014-11-04 at 17:35 +0100, Giuseppe CAVALLARO wrote:
> On 11/3/2014 6:28 PM, Andy Shevchenko wrote:
> > This patch fixes the following sparse warnings.
> >
> > drivers/net/ethernet/stmicro/stmmac/enh_desc.c:381:30: warning: symbol 'enh_desc_ops' was not declared. Should it be static?
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:253:30: warning: symbol 'ndesc_ops' was not declared. Should it be static?
> > drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c:141:33: warning: symbol 'stmmac_ptp' was not declared. Should it be static?
> >
> > There is no functional change.
>
> Hello Andy
>
> I have never seen this kind of warnings. I prefer to not include the
> stmmac.h in enh_desc.c and norm_desc.c but eventually to move the
> following from stmmac.h to common.h:
> extern const struct stmmac_desc_ops enh_desc_ops;
> extern const struct stmmac_desc_ops ndesc_ops;
> what do you think?
If it would work I do this way certainly. Thanks for the tip.
Will check soon and resubmit new version.
>
> peppe
>
>
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> > drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 ++
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 ++
> > drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 ++
> > 3 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> > index 1e2bcf5..ddd4272 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> > @@ -23,8 +23,10 @@
> > *******************************************************************************/
> >
> > #include <linux/stmmac.h>
> > +
> > #include "common.h"
> > #include "descs_com.h"
> > +#include "stmmac.h"
> >
> > static int enh_desc_get_tx_status(void *data, struct stmmac_extra_stats *x,
> > struct dma_desc *p, void __iomem *ioaddr)
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> > index 35ad4f4..46b882c 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> > @@ -23,8 +23,10 @@
> > *******************************************************************************/
> >
> > #include <linux/stmmac.h>
> > +
> > #include "common.h"
> > #include "descs_com.h"
> > +#include "stmmac.h"
> >
> > static int ndesc_get_tx_status(void *data, struct stmmac_extra_stats *x,
> > struct dma_desc *p, void __iomem *ioaddr)
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> > index 76ad214..88e0da3 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
> > @@ -25,8 +25,10 @@
> >
> > #include <linux/io.h>
> > #include <linux/delay.h>
> > +
> > #include "common.h"
> > #include "stmmac_ptp.h"
> > +#include "stmmac.h"
> >
> > static void stmmac_config_hw_tstamping(void __iomem *ioaddr, u32 data)
> > {
> >
>
--
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH V2 1/4] can: m_can: update to support CAN FD features
From: Dong Aisheng @ 2014-11-05 7:58 UTC (permalink / raw)
To: linux-can
Cc: mkl, wg, varkabhadram, netdev, socketcan, b29396,
linux-arm-kernel
Bosch M_CAN is CAN FD capable device. This patch implements the CAN
FD features include up to 64 bytes payload and bitrate switch function.
1) Change the Rx FIFO and Tx Buffer to 64 bytes for support CAN FD
up to 64 bytes payload. It's backward compatible with old 8 bytes
normal CAN frame.
2) Allocate can frame or canfd frame based on EDL bit
3) Bitrate Switch function is disabled by default and will be enabled
according to CANFD_BRS bit in cf->flags.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
Changes Since V1:
* Allocate can frame or canfd frame based on EDL bit
* Only check and set RTR bit for normal frame (no EDL bit set)
---
drivers/net/can/m_can/m_can.c | 172 +++++++++++++++++++++++++++++++-----------
1 file changed, 129 insertions(+), 43 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 6160b9c..664fe30 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -105,14 +105,36 @@ enum m_can_mram_cfg {
MRAM_CFG_NUM,
};
+/* Fast Bit Timing & Prescaler Register (FBTP) */
+#define FBTR_FBRP_MASK 0x1f
+#define FBTR_FBRP_SHIFT 16
+#define FBTR_FTSEG1_SHIFT 8
+#define FBTR_FTSEG1_MASK (0xf << FBTR_FTSEG1_SHIFT)
+#define FBTR_FTSEG2_SHIFT 4
+#define FBTR_FTSEG2_MASK (0x7 << FBTR_FTSEG2_SHIFT)
+#define FBTR_FSJW_SHIFT 0
+#define FBTR_FSJW_MASK 0x3
+
/* Test Register (TEST) */
#define TEST_LBCK BIT(4)
/* CC Control Register(CCCR) */
-#define CCCR_TEST BIT(7)
-#define CCCR_MON BIT(5)
-#define CCCR_CCE BIT(1)
-#define CCCR_INIT BIT(0)
+#define CCCR_TEST BIT(7)
+#define CCCR_CMR_MASK 0x3
+#define CCCR_CMR_SHIFT 10
+#define CCCR_CMR_CANFD 0x1
+#define CCCR_CMR_CANFD_BRS 0x2
+#define CCCR_CMR_CAN 0x3
+#define CCCR_CME_MASK 0x3
+#define CCCR_CME_SHIFT 8
+#define CCCR_CME_CAN 0
+#define CCCR_CME_CANFD 0x1
+#define CCCR_CME_CANFD_BRS 0x2
+#define CCCR_TEST BIT(7)
+#define CCCR_MON BIT(5)
+#define CCCR_CCE BIT(1)
+#define CCCR_INIT BIT(0)
+#define CCCR_CANFD 0x10
/* Bit Timing & Prescaler Register (BTP) */
#define BTR_BRP_MASK 0x3ff
@@ -204,6 +226,7 @@ enum m_can_mram_cfg {
/* Rx Buffer / FIFO Element Size Configuration (RXESC) */
#define M_CAN_RXESC_8BYTES 0x0
+#define M_CAN_RXESC_64BYTES 0x777
/* Tx Buffer Configuration(TXBC) */
#define TXBC_NDTB_OFF 16
@@ -211,6 +234,7 @@ enum m_can_mram_cfg {
/* Tx Buffer Element Size Configuration(TXESC) */
#define TXESC_TBDS_8BYTES 0x0
+#define TXESC_TBDS_64BYTES 0x7
/* Tx Event FIFO Con.guration (TXEFC) */
#define TXEFC_EFS_OFF 16
@@ -219,11 +243,11 @@ enum m_can_mram_cfg {
/* Message RAM Configuration (in bytes) */
#define SIDF_ELEMENT_SIZE 4
#define XIDF_ELEMENT_SIZE 8
-#define RXF0_ELEMENT_SIZE 16
-#define RXF1_ELEMENT_SIZE 16
+#define RXF0_ELEMENT_SIZE 72
+#define RXF1_ELEMENT_SIZE 72
#define RXB_ELEMENT_SIZE 16
#define TXE_ELEMENT_SIZE 8
-#define TXB_ELEMENT_SIZE 16
+#define TXB_ELEMENT_SIZE 72
/* Message RAM Elements */
#define M_CAN_FIFO_ID 0x0
@@ -231,11 +255,17 @@ enum m_can_mram_cfg {
#define M_CAN_FIFO_DATA(n) (0x8 + ((n) << 2))
/* Rx Buffer Element */
+/* R0 */
#define RX_BUF_ESI BIT(31)
#define RX_BUF_XTD BIT(30)
#define RX_BUF_RTR BIT(29)
+/* R1 */
+#define RX_BUF_ANMF BIT(31)
+#define RX_BUF_EDL BIT(21)
+#define RX_BUF_BRS BIT(20)
/* Tx Buffer Element */
+/* R0 */
#define TX_BUF_XTD BIT(30)
#define TX_BUF_RTR BIT(29)
@@ -327,41 +357,65 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
m_can_write(priv, M_CAN_ILE, 0x0);
}
-static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
- u32 rxfs)
+static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
{
+ struct net_device_stats *stats = &dev->stats;
struct m_can_priv *priv = netdev_priv(dev);
- u32 id, fgi;
+ struct canfd_frame *cf;
+ struct sk_buff *skb;
+ u32 id, fgi, dlc;
+ int i;
/* calculate the fifo get index for where to read data */
fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
+ dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
+ if (dlc & RX_BUF_EDL)
+ skb = alloc_canfd_skb(dev, &cf);
+ else
+ skb = alloc_can_skb(dev, (struct can_frame **)&cf);
+ if (!skb) {
+ stats->rx_dropped++;
+ return;
+ }
+
id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
if (id & RX_BUF_XTD)
cf->can_id = (id & CAN_EFF_MASK) | CAN_EFF_FLAG;
else
cf->can_id = (id >> 18) & CAN_SFF_MASK;
- if (id & RX_BUF_RTR) {
+ if (id & RX_BUF_ESI) {
+ cf->flags |= CANFD_ESI;
+ netdev_dbg(dev, "ESI Error\n");
+ }
+
+ if (!(dlc & RX_BUF_EDL) && (id & RX_BUF_RTR)) {
cf->can_id |= CAN_RTR_FLAG;
} else {
id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
- cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
- *(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
- M_CAN_FIFO_DATA(0));
- *(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
- M_CAN_FIFO_DATA(1));
+ cf->len = can_dlc2len(get_canfd_dlc((id >> 16) & 0x0F));
+
+ if (id & RX_BUF_BRS)
+ cf->flags |= CANFD_BRS;
+
+ for (i = 0; i < cf->len; i += 4)
+ *(u32 *)(cf->data + i) =
+ m_can_fifo_read(priv, fgi,
+ M_CAN_FIFO_DATA(i / 4));
}
/* acknowledge rx fifo 0 */
m_can_write(priv, M_CAN_RXF0A, fgi);
+
+ stats->rx_packets++;
+ stats->rx_bytes += cf->len;
+
+ netif_receive_skb(skb);
}
static int m_can_do_rx_poll(struct net_device *dev, int quota)
{
struct m_can_priv *priv = netdev_priv(dev);
- struct net_device_stats *stats = &dev->stats;
- struct sk_buff *skb;
- struct can_frame *frame;
u32 pkts = 0;
u32 rxfs;
@@ -375,18 +429,7 @@ static int m_can_do_rx_poll(struct net_device *dev, int quota)
if (rxfs & RXFS_RFL)
netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
- skb = alloc_can_skb(dev, &frame);
- if (!skb) {
- stats->rx_dropped++;
- return pkts;
- }
-
- m_can_read_fifo(dev, frame, rxfs);
-
- stats->rx_packets++;
- stats->rx_bytes += frame->can_dlc;
-
- netif_receive_skb(skb);
+ m_can_read_fifo(dev, rxfs);
quota--;
pkts++;
@@ -744,10 +787,23 @@ static const struct can_bittiming_const m_can_bittiming_const = {
.brp_inc = 1,
};
+static const struct can_bittiming_const m_can_data_bittiming_const = {
+ .name = KBUILD_MODNAME,
+ .tseg1_min = 2, /* Time segment 1 = prop_seg + phase_seg1 */
+ .tseg1_max = 16,
+ .tseg2_min = 1, /* Time segment 2 = phase_seg2 */
+ .tseg2_max = 8,
+ .sjw_max = 4,
+ .brp_min = 1,
+ .brp_max = 32,
+ .brp_inc = 1,
+};
+
static int m_can_set_bittiming(struct net_device *dev)
{
struct m_can_priv *priv = netdev_priv(dev);
const struct can_bittiming *bt = &priv->can.bittiming;
+ const struct can_bittiming *dbt = &priv->can.data_bittiming;
u16 brp, sjw, tseg1, tseg2;
u32 reg_btp;
@@ -758,7 +814,17 @@ static int m_can_set_bittiming(struct net_device *dev)
reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
(tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
m_can_write(priv, M_CAN_BTP, reg_btp);
- netdev_dbg(dev, "setting BTP 0x%x\n", reg_btp);
+
+ if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
+ brp = dbt->brp - 1;
+ sjw = dbt->sjw - 1;
+ tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
+ tseg2 = dbt->phase_seg2 - 1;
+ reg_btp = (brp << FBTR_FBRP_SHIFT) | (sjw << FBTR_FSJW_SHIFT) |
+ (tseg1 << FBTR_FTSEG1_SHIFT) |
+ (tseg2 << FBTR_FTSEG2_SHIFT);
+ m_can_write(priv, M_CAN_FBTP, reg_btp);
+ }
return 0;
}
@@ -778,8 +844,8 @@ static void m_can_chip_config(struct net_device *dev)
m_can_config_endisable(priv, true);
- /* RX Buffer/FIFO Element Size 8 bytes data field */
- m_can_write(priv, M_CAN_RXESC, M_CAN_RXESC_8BYTES);
+ /* RX Buffer/FIFO Element Size 64 bytes data field */
+ m_can_write(priv, M_CAN_RXESC, M_CAN_RXESC_64BYTES);
/* Accept Non-matching Frames Into FIFO 0 */
m_can_write(priv, M_CAN_GFC, 0x0);
@@ -788,8 +854,8 @@ static void m_can_chip_config(struct net_device *dev)
m_can_write(priv, M_CAN_TXBC, (1 << TXBC_NDTB_OFF) |
priv->mcfg[MRAM_TXB].off);
- /* only support 8 bytes firstly */
- m_can_write(priv, M_CAN_TXESC, TXESC_TBDS_8BYTES);
+ /* support 64 bytes payload */
+ m_can_write(priv, M_CAN_TXESC, TXESC_TBDS_64BYTES);
m_can_write(priv, M_CAN_TXEFC, (1 << TXEFC_EFS_OFF) |
priv->mcfg[MRAM_TXE].off);
@@ -804,7 +870,8 @@ static void m_can_chip_config(struct net_device *dev)
RXFC_FWM_1 | priv->mcfg[MRAM_RXF1].off);
cccr = m_can_read(priv, M_CAN_CCCR);
- cccr &= ~(CCCR_TEST | CCCR_MON);
+ cccr &= ~(CCCR_TEST | CCCR_MON | (CCCR_CMR_MASK << CCCR_CMR_SHIFT) |
+ (CCCR_CME_MASK << CCCR_CME_SHIFT));
test = m_can_read(priv, M_CAN_TEST);
test &= ~TEST_LBCK;
@@ -816,6 +883,9 @@ static void m_can_chip_config(struct net_device *dev)
test |= TEST_LBCK;
}
+ if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
+ cccr |= CCCR_CME_CANFD_BRS << CCCR_CME_SHIFT;
+
m_can_write(priv, M_CAN_CCCR, cccr);
m_can_write(priv, M_CAN_TEST, test);
@@ -880,11 +950,13 @@ static struct net_device *alloc_m_can_dev(void)
priv->dev = dev;
priv->can.bittiming_const = &m_can_bittiming_const;
+ priv->can.data_bittiming_const = &m_can_data_bittiming_const;
priv->can.do_set_mode = m_can_set_mode;
priv->can.do_get_berr_counter = m_can_get_berr_counter;
priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
CAN_CTRLMODE_LISTENONLY |
- CAN_CTRLMODE_BERR_REPORTING;
+ CAN_CTRLMODE_BERR_REPORTING |
+ CAN_CTRLMODE_FD;
return dev;
}
@@ -967,8 +1039,9 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
struct net_device *dev)
{
struct m_can_priv *priv = netdev_priv(dev);
- struct can_frame *cf = (struct can_frame *)skb->data;
- u32 id;
+ struct canfd_frame *cf = (struct canfd_frame *)skb->data;
+ u32 id, cccr;
+ int i;
if (can_dropped_invalid_skb(dev, skb))
return NETDEV_TX_OK;
@@ -987,11 +1060,24 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
/* message ram configuration */
m_can_fifo_write(priv, 0, M_CAN_FIFO_ID, id);
- m_can_fifo_write(priv, 0, M_CAN_FIFO_DLC, cf->can_dlc << 16);
- m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), *(u32 *)(cf->data + 0));
- m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), *(u32 *)(cf->data + 4));
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DLC, can_len2dlc(cf->len) << 16);
+
+ for (i = 0; i < cf->len; i += 4)
+ m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(i / 4),
+ *(u32 *)(cf->data + i));
+
can_put_echo_skb(skb, dev, 0);
+ if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
+ cccr = m_can_read(priv, M_CAN_CCCR);
+ cccr &= ~(CCCR_CMR_MASK << CCCR_CMR_SHIFT);
+ if (cf->flags & CANFD_BRS)
+ cccr |= CCCR_CMR_CANFD_BRS << CCCR_CMR_SHIFT;
+ else
+ cccr |= CCCR_CMR_CANFD << CCCR_CMR_SHIFT;
+ m_can_write(priv, M_CAN_CCCR, cccr);
+ }
+
/* enable first TX buffer to start transfer */
m_can_write(priv, M_CAN_TXBTIE, 0x1);
m_can_write(priv, M_CAN_TXBAR, 0x1);
--
1.9.1
^ permalink raw reply related
* [PATCH V1 3/4] can: add can_is_canfd_skb() API
From: Dong Aisheng @ 2014-11-05 7:58 UTC (permalink / raw)
To: linux-can
Cc: mkl, wg, varkabhadram, netdev, socketcan, b29396,
linux-arm-kernel
In-Reply-To: <1415174326-6623-1-git-send-email-b29396@freescale.com>
The CAN device drivers can use it to check if the frame to send is on
CAN FD mode or normal CAN mode.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
include/linux/can/dev.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 6992afc..fe3be29 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -99,6 +99,11 @@ inval_skb:
return 1;
}
+static inline int can_is_canfd_skb(struct sk_buff *skb)
+{
+ return skb->protocol == htons(ETH_P_CANFD);
+}
+
/* get data length from can_dlc with sanitized can_dlc */
u8 can_dlc2len(u8 can_dlc);
--
1.9.1
^ permalink raw reply related
* [PATCH V1 4/4] can: m_can: allow to send std frame on CAN FD mode
From: Dong Aisheng @ 2014-11-05 7:58 UTC (permalink / raw)
To: linux-can
Cc: mkl, wg, varkabhadram, netdev, socketcan, b29396,
linux-arm-kernel
In-Reply-To: <1415174326-6623-1-git-send-email-b29396@freescale.com>
The current code sends all CAN frames on CAN FD format(with BRS or not)
if CAN_CTRLMODE_FD is enabled.
However, even CAN_CTRLMODE_FD is enabled, the can tool may still
send normal frames.
e.g.
ip link set can0 up type can bitrate 1000000 dbitrate 1000000 fd on
cansend can0 123#112233
Therefore sending normal CAN frame on FD format seems not reasonable
and the CAN FD incapable device may not be able to receive it correctly.
The patch switches the M_CAN operation mode to ISO11898-1 instead of
staying on CAN FD operation mode by writing "11" to CMR bit if find
we're sending a normal can skb.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
---
drivers/net/can/m_can/m_can.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f47c200..219c4b7 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1080,10 +1080,14 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
cccr = m_can_read(priv, M_CAN_CCCR);
cccr &= ~(CCCR_CMR_MASK << CCCR_CMR_SHIFT);
- if (cf->flags & CANFD_BRS)
- cccr |= CCCR_CMR_CANFD_BRS << CCCR_CMR_SHIFT;
- else
- cccr |= CCCR_CMR_CANFD << CCCR_CMR_SHIFT;
+ if (can_is_canfd_skb(skb)) {
+ if (cf->flags & CANFD_BRS)
+ cccr |= CCCR_CMR_CANFD_BRS << CCCR_CMR_SHIFT;
+ else
+ cccr |= CCCR_CMR_CANFD << CCCR_CMR_SHIFT;
+ } else {
+ cccr |= CCCR_CMR_CAN << CCCR_CMR_SHIFT;
+ }
m_can_write(priv, M_CAN_CCCR, cccr);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Add more checks for get_btc_status callback
From: Mike Galbraith @ 2014-11-05 9:16 UTC (permalink / raw)
To: Larry Finger
Cc: Murilo Opsfelder Araujo, linux-kernel, linux-wireless, netdev,
Chaoming Li, John W. Linville, Thadeu Cascardo, troy_tan
In-Reply-To: <5451BED0.2060906@lwfinger.net>
On Wed, 2014-10-29 at 23:30 -0500, Larry Finger wrote:
> On 10/29/2014 06:28 PM, Murilo Opsfelder Araujo wrote:
> > This is a complement of commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
> > "rtlwifi: Add check for get_btc_status callback".
> >
> > With this patch, next-20141029 at least does not panic with rtl8192se
> > device.
> >
>
> This patch is OK, but as noted it is not complete.
>
> I have patches to fix all the kernel panics for rtl8192se AND rtl8192ce. There
> are missing parts, but I would prefer submitting mine, which would conflict with
> this one. For that reason, NACK for this one, and please apply the set I am
> submitting now.
It's all in there now, but my RTL8191SEvB is still dead. Squabbling
with it isn't going all that well either.
As soon as 38506ece rtlwifi: rtl_pci: Start modification for new drivers
is applied, explosions appear. Subsequently applying...
08054200 rtlwifi: Add check for get_btc_status callback
c0386f15 rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing get_btc_status
50147969 rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
30c5ccc6 rtlwifi: rtl8192se: Add missing section to read descriptor setting
75a916e1 rtlwifi: rtl8192se: Fix firmware loading
...fixes that mess up, but leaves the interface dead in the same manner
as if nothing has been reverted. So it _seems_ the bustage lurks in
38506ece somewhere. Too bad it's non-dinky, and written in wifi-ese :)
-Mike
Full revert series:
patches/revert-75a916e1944fea8347d2245c62567187e4eff9dd
patches/revert-8ae3c16e41b02db8ffe4121468519d6352baedc1
patches/revert-30c5ccc6afee39754cff75ad8d775ad39a2ce989
patches/revert-501479699ff484ba8acc1d07022271f00cfc55a3
patches/revert-c0386f1584127442d0f2aea41bc948056d6b1337
patches/revert-08054200117a95afc14c3d2ed3a38bf4e345bf78
patches/revert-4f2b244c7d5b81ce4f0c6c0382f3a3b7c2dbec1c
patches/revert-cefe3dfdb9f5f498cae9871f7e52800f5e22c614
patches/revert-b2d624a5810203a1a8b7735e1ec5685109b22fc3
patches/revert-d514aefb8ce89562ef2d7dcddc530e5de6287c4b
patches/revert-598a0df07fc6c4642f9b0497cef1233e41d4c987
patches/revert-47481d977cb2987ab363202c68a79ec1bccd357c
patches/revert-1fca350b761631d182c2e8bce530896e66404bc2
patches/revert-3f08e47291879fb047d7d4464d2beaedfea4eb63
patches/revert-989377e1cc9e713822d148d2e638d6c63d8a94b1
patches/revert-574a7930d7c4d0fe4295868e52a5277bd9595b5e
patches/revert-ef09396ef622572c604d4977e76f6151ef68ed21
patches/revert-557f933113a42a48ec617b81b5ea53fd7202b1ed
patches/revert-9f087a924427c01190b205f0051be00808c99828
patches/revert-5c99f04fec93068147a3e95b439b345f203ac5b9
patches/revert-0529c6b8176135bcae1ab66bed6c1288456fbdec
patches/revert-b1a3bfc97cd95681c511515534b84843998f3ea0
patches/revert-7fe3b3abb5da3a105d87640db693c41259138294
patches/revert-34ed780a6afc4df5e3285d20fac721c591e0724e
patches/revert-21e4b0726dc671c423e2dc9a85364716219c4502
patches/revert-c151aed6aa146e9587590051aba9da68b9370f9b
patches/revert-f3a97e93814aeac3f13e857a0071726acc9bd626
patches/revert-d3feae41a3473a0f7b431d6af4e092865d586e52
patches/revert-3c67b8f9f3b5bb1207c9bb198e5ef04ff56921dd
patches/revert-9afa2e44f4d8f9d031f815c32bb8f225f0f6746b
patches/revert-f7953b2ad66cc5fc66e13d5c0a40e61b45cdfca8
patches/revert-38506ecefab911785d5e1aa5889f6eeb462e0954
patches/revert-fd09ff958777cf583d7541f180991c0fc50bd2f7
patches/revert-560e334dbd9907ecdd25318fbdb33179c5d5a3bd
patches/revert-5eef40e5687da4ad0123e231e4fe952a12655f0b
patches/revert-6b5447ce630cdc231caf4f958325f8fa925216bf
patches/revert-dbb30ebeefaf01121b32ae6b5baf29524f3a0b30
patches/revert-4f4378dead3792d21577739f07869fbd843dab23
patches/revert-ed364abffd6e19bec67b7ccda8237213b8b37640
patches/revert-c96fd200e9af8ad4c4891ef579044a75c659d8c7
patches/revert-2ec7f01c35727574953dbd884d7d45da940a25ee
patches/revert-f5b5869095819970333dc9de54eed5c552407d35
patches/revert-2187e9a2ce575ee85a1ce31fa2ecbc0f580c105f
patches/revert-e8f3fef412d4ffd8cb1bd5cd7a6e5572e21bf80a
patches/revert-e79fff28587c9437282c863722d1fa186143f62a
^ permalink raw reply
* RE: [PATCH net 5/5] qlcnic: Implement ndo_gso_check()
From: Shahed Shaikh @ 2014-11-05 9:17 UTC (permalink / raw)
To: Joe Stringer, netdev
Cc: sathya.perla@emulex.com, jeffrey.t.kirsher@intel.com,
linux.nics@intel.com, amirv@mellanox.com, Dept-GE Linux NIC Dev,
Tom Herbert (Partner - google), linux-kernel
In-Reply-To: <1415138202-1197-6-git-send-email-joestringer@nicira.com>
> -----Original Message-----
> From: Joe Stringer [mailto:joestringer@nicira.com]
> Sent: Wednesday, November 05, 2014 3:27 AM
> To: netdev
> Cc: sathya.perla@emulex.com; jeffrey.t.kirsher@intel.com;
> linux.nics@intel.com; amirv@mellanox.com; Shahed Shaikh; Dept-GE Linux
> NIC Dev; Tom Herbert (Partner - google); linux-kernel
> Subject: [PATCH net 5/5] qlcnic: Implement ndo_gso_check()
>
> ndo_gso_check() was recently introduced to allow NICs to report the
> offloading support that they have on a per-skb basis. Add an implementation
> for this driver which checks for something that looks like VXLAN.
>
> Implementation shamelessly stolen from Tom Herbert:
> http://thread.gmane.org/gmane.linux.network/332428/focus=333111
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> index f5e29f7..6184f47 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> @@ -505,6 +505,17 @@ static void qlcnic_del_vxlan_port(struct net_device
> *netdev, } #endif
>
> +static bool qlcnic_gso_check(struct sk_buff *skb, struct net_device
> +*dev) {
> + if ((skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL) &&
> + (skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
> + skb->inner_protocol != htons(ETH_P_TEB) ||
> + skb_inner_mac_header(skb) - skb_transport_header(skb) != 16))
> + return false;
> +
Hi Joe,
Yes, qlcnic driver only supports VXLAN offload.
It would be good to put a comment about value 16 to make it more intuitive.
e.g. 16 is the size of outer UDP header + VXLAN header.
Anyway, patch looks good to me.
Acked-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Thanks,
Shahed
^ permalink raw reply
* Re: [PATCH V1 net-next 5/5] net/mlx4_core: Add retrieval of CONFIG_DEV parameters
From: Or Gerlitz @ 2014-11-05 9:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, netdev, Matan Barak, Amir Vadai, Saeed Mahameed,
Shani Michaeli, Ido Shamay
In-Reply-To: <1415119714.1005.3.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/4/2014 6:48 PM, Eric Dumazet wrote:
> This added following warnings :
>
> CC drivers/net/ethernet/mellanox/mlx4/fw.o
> drivers/net/ethernet/mellanox/mlx4/fw.c: In function 'mlx4_config_dev_retrieval':
> drivers/net/ethernet/mellanox/mlx4/fw.c:1944:12: warning: 'config_dev.rx_checksum_val' may be used uninitialized in this function [-Wmaybe-uninitialized]
> In file included from include/linux/swab.h:4:0,
> from include/uapi/linux/byteorder/little_endian.h:12,
> from include/linux/byteorder/little_endian.h:4,
> from ./arch/x86/include/uapi/asm/byteorder.h:4,
> from include/asm-generic/bitops/le.h:5,
> from ./arch/x86/include/asm/bitops.h:504,
> from include/linux/bitops.h:33,
> from include/linux/kernel.h:10,
> from include/linux/skbuff.h:17,
> from include/linux/if_ether.h:23,
> from include/linux/etherdevice.h:25,
> from drivers/net/ethernet/mellanox/mlx4/fw.c:35:
> include/uapi/linux/swab.h:53:93: warning: 'config_dev.vxlan_udp_dport' may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/net/ethernet/mellanox/mlx4/fw.c:1922:25: note: 'config_dev.vxlan_udp_dport' was declared here
>
>
Oh, missed that since we build with CONFIG_CC_OPTIMIZE_FOR_SIZE which
for some reason cause the kernel Makefile to mask away that warning?!
> ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
> else
> KBUILD_CFLAGS += -O2
> endif
Anyway, this seems as false positive since just before using the struct
mlx4_config_dev instance we go through mlx4_CONFIG_DEV_get() which
either fills in values for the fields or return error and in that case,
we don't use them... the below patch makes gcc (4.8.2) happy, but it's
not really needed... thoughts?
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c
b/drivers/net/ethernet/mellanox/mlx4/fw.c
index d6dba77..9a4703f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -1929,7 +1929,7 @@ int mlx4_config_dev_retrieval(struct mlx4_dev *dev,
if (!(dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_CONFIG_DEV))
return -ENOTSUPP;
-
+ memset(&config_dev, 0, sizeof(config_dev));
err = mlx4_CONFIG_DEV_get(dev, &config_dev);
if (err)
return err;
Or.
^ permalink raw reply related
* Re: [PATCH] ipvs: Keep skb->sk when allocating headroom on tunnel xmit
From: Julian Anastasov @ 2014-11-05 9:21 UTC (permalink / raw)
To: Calvin Owens
Cc: Simon Horman, Wensong Zhang, lvs-devel, linux-kernel, netdev,
agartrell, kernel-team
In-Reply-To: <1415147860-11389-1-git-send-email-calvinowens@fb.com>
Hello,
On Tue, 4 Nov 2014, Calvin Owens wrote:
> ip_vs_prepare_tunneled_skb() ignores ->sk when allocating a new
> skb, either unconditionally setting ->sk to NULL or allowing
> the uninitialized ->sk from a newly allocated skb to leak through
> to the caller.
>
> This patch properly copies ->sk and increments its reference count.
>
> Signed-off-by: Calvin Owens <calvinowens@fb.com>
Good catch. Please, extend your patch to
fix also the second place that has such error,
ip_vs_tunnel_xmit_v6. This call is missing from long time,
it was not needed. But commits that allow skb->sk (local
clients) already need it, eg.
- f2428ed5e7bc89c7 ("ipvs: load balance ipv6 connections from a local
process"), 2.6.28
- 4856c84c1358b798 ("ipvs: load balance IPv4 connections from a local
process"), 2.6.28
> ---
> net/netfilter/ipvs/ip_vs_xmit.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
> index 437a366..bd90bf8 100644
> --- a/net/netfilter/ipvs/ip_vs_xmit.c
> +++ b/net/netfilter/ipvs/ip_vs_xmit.c
> @@ -846,6 +846,8 @@ ip_vs_prepare_tunneled_skb(struct sk_buff *skb, int skb_af,
> new_skb = skb_realloc_headroom(skb, max_headroom);
> if (!new_skb)
> goto error;
> + if (skb->sk)
> + skb_set_owner_w(new_skb, skb->sk);
> consume_skb(skb);
> skb = new_skb;
> }
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] stmmac: fix sparse warnings
From: Giuseppe CAVALLARO @ 2014-11-05 9:27 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: netdev, Kweh Hock Leong, David S . Miller, Vince Bridgers
In-Reply-To: <1415178226.472.9.camel@linux.intel.com>
On 11/5/2014 10:03 AM, Andy Shevchenko wrote:
> On Tue, 2014-11-04 at 17:35 +0100, Giuseppe CAVALLARO wrote:
>> On 11/3/2014 6:28 PM, Andy Shevchenko wrote:
>>> This patch fixes the following sparse warnings.
>>>
>>> drivers/net/ethernet/stmicro/stmmac/enh_desc.c:381:30: warning: symbol 'enh_desc_ops' was not declared. Should it be static?
>>> drivers/net/ethernet/stmicro/stmmac/norm_desc.c:253:30: warning: symbol 'ndesc_ops' was not declared. Should it be static?
>>> drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c:141:33: warning: symbol 'stmmac_ptp' was not declared. Should it be static?
>>>
>>> There is no functional change.
>>
>> Hello Andy
>>
>> I have never seen this kind of warnings. I prefer to not include the
>> stmmac.h in enh_desc.c and norm_desc.c but eventually to move the
>> following from stmmac.h to common.h:
>> extern const struct stmmac_desc_ops enh_desc_ops;
>> extern const struct stmmac_desc_ops ndesc_ops;
>> what do you think?
>
> If it would work I do this way certainly. Thanks for the tip.
yes Andy just verified with sparse, pls also fix:
extern const struct stmmac_hwtimestamp stmmac_ptp;
in the same way.
>
> Will check soon and resubmit new version.
sure and you can add my Acked-by:
peppe
>
>>
>> peppe
>>
>>
>>>
>>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>>> ---
>>> drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 ++
>>> drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 ++
>>> drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 ++
>>> 3 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
>>> index 1e2bcf5..ddd4272 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
>>> @@ -23,8 +23,10 @@
>>> *******************************************************************************/
>>>
>>> #include <linux/stmmac.h>
>>> +
>>> #include "common.h"
>>> #include "descs_com.h"
>>> +#include "stmmac.h"
>>>
>>> static int enh_desc_get_tx_status(void *data, struct stmmac_extra_stats *x,
>>> struct dma_desc *p, void __iomem *ioaddr)
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
>>> index 35ad4f4..46b882c 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
>>> @@ -23,8 +23,10 @@
>>> *******************************************************************************/
>>>
>>> #include <linux/stmmac.h>
>>> +
>>> #include "common.h"
>>> #include "descs_com.h"
>>> +#include "stmmac.h"
>>>
>>> static int ndesc_get_tx_status(void *data, struct stmmac_extra_stats *x,
>>> struct dma_desc *p, void __iomem *ioaddr)
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
>>> index 76ad214..88e0da3 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
>>> @@ -25,8 +25,10 @@
>>>
>>> #include <linux/io.h>
>>> #include <linux/delay.h>
>>> +
>>> #include "common.h"
>>> #include "stmmac_ptp.h"
>>> +#include "stmmac.h"
>>>
>>> static void stmmac_config_hw_tstamping(void __iomem *ioaddr, u32 data)
>>> {
>>>
>>
>
>
^ permalink raw reply
* RE: [PATCH v2 1/1] ip-link: in human readable output use dynamic precision length
From: David Laight @ 2014-11-05 9:30 UTC (permalink / raw)
To: 'Christian Hesse'; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <20141104221038.440fd9d7@leda.localdomain>
From: Christian Hesse
...
>
> I do not like this at all... snprintf() would be nice for a catch-all, but we
> have to take care of negative values. So let's try something different.
> I will think about it and send a new patch.
>
> > > + precision = 0;
> > > +
> > > + snprintf(buf, sizeof(buf), "%.*f%c%s", precision,
> > > + (double) count / powi, *prefix, use_iec ? "i" : "");
> > >
> > > fprintf(fp, "%-*s ", width, buf);
> > > }
> >
> > The above will go wrong in all sorts of horrid ways....
> > For instance you are doing a truncating integer divide, but the FP
> > value will get rounded for display.
> >
> > It would be safer to use integers throughout.
>
> My implementation used integers, but Stephen changes this to floating point
> with his cleanups.
>
> IMHO the rounding is ok. This is for *human* readability. ;)
> Whoever wants correct values should not ask ip to print human readable values
> but rely on pure numbers.
Rounding the value is fine, the difference between 1000 and 1024
is not that great either.
The problem is that the two calculations get rounded differently.
If the FP value ends up being 9.999999 it will be printed as 10.0
but your field width calculation will only have allowed for
a single digit.
> > Oh, and a 2Mbit E1 link is actually 2048000 :-)
>
> Sorry? Did not get the point.
That was really in reference to a much earlier comment about comms
always using 1000.
David
^ permalink raw reply
* Re: [PATCH V1 3/4] can: add can_is_canfd_skb() API
From: Oliver Hartkopp @ 2014-11-05 9:39 UTC (permalink / raw)
To: Dong Aisheng, linux-can; +Cc: mkl, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <1415174326-6623-3-git-send-email-b29396@freescale.com>
On 05.11.2014 08:58, Dong Aisheng wrote:
> The CAN device drivers can use it to check if the frame to send is on
> CAN FD mode or normal CAN mode.
>
> Signed-off-by: Dong Aisheng <b29396@freescale.com>
> ---
> include/linux/can/dev.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
> index 6992afc..fe3be29 100644
> --- a/include/linux/can/dev.h
> +++ b/include/linux/can/dev.h
> @@ -99,6 +99,11 @@ inval_skb:
> return 1;
> }
>
> +static inline int can_is_canfd_skb(struct sk_buff *skb)
> +{
> + return skb->protocol == htons(ETH_P_CANFD);
return skb->len == CANFD_MTU;
Please take the length as distinction as we do it in linux/net/can/ too.
You can add my
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
in the updated post then.
Regards,
Oliver
^ permalink raw reply
* [PATCH v2] stmmac: fix sparse warnings
From: Andy Shevchenko @ 2014-11-05 9:45 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, David S . Miller, Vince Bridgers
Cc: Andy Shevchenko
This patch fixes the following sparse warnings.
drivers/net/ethernet/stmicro/stmmac/enh_desc.c:381:30: warning: symbol 'enh_desc_ops' was not declared. Should it be static?
drivers/net/ethernet/stmicro/stmmac/norm_desc.c:253:30: warning: symbol 'ndesc_ops' was not declared. Should it be static?
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c:141:33: warning: symbol 'stmmac_ptp' was not declared. Should it be static?
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
---
Since v1:
- redone as Giuseppe suggested
drivers/net/ethernet/stmicro/stmmac/common.h | 5 +++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 4 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 593e6c4..12a174e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -341,6 +341,9 @@ struct stmmac_desc_ops {
int (*get_rx_timestamp_status) (void *desc, u32 ats);
};
+extern const struct stmmac_desc_ops enh_desc_ops;
+extern const struct stmmac_desc_ops ndesc_ops;
+
struct stmmac_dma_ops {
/* DMA core initialization */
int (*init) (void __iomem *ioaddr, int pbl, int fb, int mb,
@@ -410,6 +413,8 @@ struct stmmac_hwtimestamp {
u64(*get_systime) (void __iomem *ioaddr);
};
+extern const struct stmmac_hwtimestamp stmmac_ptp;
+
struct mac_link {
int port;
int duplex;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c3c4065..2d0036e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -122,9 +122,7 @@ int stmmac_mdio_unregister(struct net_device *ndev);
int stmmac_mdio_register(struct net_device *ndev);
int stmmac_mdio_reset(struct mii_bus *mii);
void stmmac_set_ethtool_ops(struct net_device *netdev);
-extern const struct stmmac_desc_ops enh_desc_ops;
-extern const struct stmmac_desc_ops ndesc_ops;
-extern const struct stmmac_hwtimestamp stmmac_ptp;
+
int stmmac_ptp_register(struct stmmac_priv *priv);
void stmmac_ptp_unregister(struct stmmac_priv *priv);
int stmmac_resume(struct net_device *ndev);
--
2.1.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCHv1 net-next] xen-netback: remove unconditional pull_skb_tail in guest Tx path
From: Ian Campbell @ 2014-11-05 9:51 UTC (permalink / raw)
To: David Miller
Cc: zoltan.kiss, david.vrabel, netdev, malcolm.crossley, wei.liu2,
xen-devel
In-Reply-To: <20141104.161704.1690311989900127361.davem@davemloft.net>
On Tue, 2014-11-04 at 16:17 -0500, David Miller wrote:
> From: Zoltan Kiss <zoltan.kiss@linaro.org>
> Date: Mon, 03 Nov 2014 18:23:03 +0000
>
> >
> >
> > On 03/11/14 17:46, David Vrabel wrote:
> >> On 03/11/14 17:39, Ian Campbell wrote:
> >>> On Mon, 2014-11-03 at 17:23 +0000, David Vrabel wrote:
> >>>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
> >>>>
> >>>> Unconditionally pulling 128 bytes into the linear buffer is not
> >>>> required. Netback has already grant copied up-to 128 bytes from the
> >>>> first slot of a packet into the linear buffer. The first slot normally
> >>>> contain all the IPv4/IPv6 and TCP/UDP headers.
> >>>
> >>> What about when it doesn't? It sounds as if we now won't pull up,
> >>> which
> >>> would be bad.
> >>
> >> The network stack will always pull any headers it needs to inspect
> >> (the
> >> frag may be a userspace page which has the same security issues as a
> >> frag with a foreign page).
> > I wouldn't bet my life on this, but indeed it should always happen.
>
> I would bet my life on it.
>
> Every protocol demux starts with pskb_may_pull() to pull frag data
> into the linear area, if necessary, before looking at headers.
Then I stand corrected, I was sure this wasn't the case (but my
information could well be a decade out of date...).
Is this also true for things which hit the iptables paths? I suppose
they must necessarily have already been through the protocol demux stage
before iptables would even be able to interpret them as e.g. an IP
packet.
Ian.
^ permalink raw reply
* Re: [PATCHv1 net-next] xen-netback: remove unconditional pull_skb_tail in guest Tx path
From: Ian Campbell @ 2014-11-05 9:53 UTC (permalink / raw)
To: David Miller; +Cc: david.vrabel, netdev, xen-devel, wei.liu2, malcolm.crossley
In-Reply-To: <20141104.164113.2265592775058059992.davem@davemloft.net>
On Tue, 2014-11-04 at 16:41 -0500, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 3 Nov 2014 17:23:51 +0000
>
> > From: Malcolm Crossley <malcolm.crossley@citrix.com>
> >
> > Unconditionally pulling 128 bytes into the linear buffer is not
> > required. Netback has already grant copied up-to 128 bytes from the
> > first slot of a packet into the linear buffer. The first slot normally
> > contain all the IPv4/IPv6 and TCP/UDP headers.
> >
> > The unconditional pull would often copy frag data unnecessarily. This
> > is a performance problem when running on a version of Xen where grant
> > unmap avoids TLB flushes for pages which are not accessed. TLB
> > flushes can now be avoided for > 99% of unmaps (it was 0% before).
> >
> > Grant unmap TLB flush avoidance will be available in a future version
> > of Xen (probably 4.6).
> >
> > Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com>
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>
> Now that this has been discussed a bit, it is possible to get an ack or two?
I'd like to see the commit message expanded to explain why this isn't
introducing a (security) bug by not pulling enough stuff into the header
(IOW the conclusion of the discussion).
Ian.
^ permalink raw reply
* Re: [PATCH net 2/2] geneve: Unregister pernet subsys on module unload.
From: Nicolas Dichtel @ 2014-11-05 10:08 UTC (permalink / raw)
To: Jesse Gross, David S. Miller; +Cc: netdev, Andy Zhou
In-Reply-To: <1415072318-64442-2-git-send-email-jesse@nicira.com>
Le 04/11/2014 04:38, Jesse Gross a écrit :
> The pernet ops aren't ever unregistered, which causes a memory
> leak and an OOPs if the module is ever reinserted.
>
> CC: Andy Zhou <azhou@nicira.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Fixes: 0b5e8b8eeae4 ("net: Add Geneve tunneling protocol driver")
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH 0/1] mv643xx_eth: Disable TSO by default
From: Karl Beldan @ 2014-11-05 10:09 UTC (permalink / raw)
To: Ian Campbell
Cc: Ezequiel Garcia, netdev, David Miller, Thomas Petazzoni,
Gregory Clement, Tawfik Bayouk, Lior Amsalem, Nadav Haklai,
764162
In-Reply-To: <1415176766.31613.7.camel@hellion.org.uk>
On Wed, Nov 05, 2014 at 08:39:26AM +0000, Ian Campbell wrote:
> On Tue, 2014-11-04 at 15:20 +0100, Karl Beldan wrote:
> > On Sat, Nov 01, 2014 at 12:30:19PM -0300, Ezequiel Garcia wrote:
> > > Several users ([1], [2]) have been reporting data corruption with TSO on
> > > Kirkwood platforms (i.e. using the mv643xx_eth driver).
> > >
> > > Until we manage to find what's causing this, this simple patch will make
> > > the TSO path disabled by default. This patch should be queued for stable,
> > > fixing the TSO feature introduced in v3.16.
> > >
> > > The corruption itself is very easy to reproduce: checking md5sum on a mounted
> > > NFS directory gives a different result each time. Same tests using the mvneta
> > > driver (Armada 370/38x/XP SoC) pass with no issues.
> > >
> > > Frankly, I'm a bit puzzled about this, and so any ideas or debugging hints
> > > are well received.
> > >
> >
> > Hi,
> >
> > Can you try this :
>
> It fixes things for me, thanks!
>
> Tested-by: Ian Campbell <ijc@hellion.org.uk>
>
Good thing, thanks for your feedbak Ian !
Karl
^ permalink raw reply
* Re: [PATCH V2 1/4] can: m_can: update to support CAN FD features
From: Oliver Hartkopp @ 2014-11-05 10:12 UTC (permalink / raw)
To: Dong Aisheng, linux-can; +Cc: mkl, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <1415174326-6623-1-git-send-email-b29396@freescale.com>
On 05.11.2014 08:58, Dong Aisheng wrote:
> @@ -327,41 +357,65 @@ static inline void m_can_disable_all_interrupts(const struct m_can_priv *priv)
> m_can_write(priv, M_CAN_ILE, 0x0);
> }
>
> -static void m_can_read_fifo(const struct net_device *dev, struct can_frame *cf,
> - u32 rxfs)
> +static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
> {
> + struct net_device_stats *stats = &dev->stats;
> struct m_can_priv *priv = netdev_priv(dev);
> - u32 id, fgi;
> + struct canfd_frame *cf;
> + struct sk_buff *skb;
> + u32 id, fgi, dlc;
> + int i;
>
> /* calculate the fifo get index for where to read data */
> fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
> + dlc = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
> + if (dlc & RX_BUF_EDL)
> + skb = alloc_canfd_skb(dev, &cf);
> + else
> + skb = alloc_can_skb(dev, (struct can_frame **)&cf);
Yes. That's the way it should look like ;-)
> + if (!skb) {
> + stats->rx_dropped++;
> + return;
> + }
> +
> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_ID);
> if (id & RX_BUF_XTD)
> cf->can_id = (id & CAN_EFF_MASK) | CAN_EFF_FLAG;
> else
> cf->can_id = (id >> 18) & CAN_SFF_MASK;
>
> - if (id & RX_BUF_RTR) {
> + if (id & RX_BUF_ESI) {
> + cf->flags |= CANFD_ESI;
> + netdev_dbg(dev, "ESI Error\n");
> + }
> +
> + if (!(dlc & RX_BUF_EDL) && (id & RX_BUF_RTR)) {
> cf->can_id |= CAN_RTR_FLAG;
> } else {
> id = m_can_fifo_read(priv, fgi, M_CAN_FIFO_DLC);
> - cf->can_dlc = get_can_dlc((id >> 16) & 0x0F);
> - *(u32 *)(cf->data + 0) = m_can_fifo_read(priv, fgi,
> - M_CAN_FIFO_DATA(0));
> - *(u32 *)(cf->data + 4) = m_can_fifo_read(priv, fgi,
> - M_CAN_FIFO_DATA(1));
> + cf->len = can_dlc2len(get_canfd_dlc((id >> 16) & 0x0F));
if (dlc & RX_BUF_EDL)
cf->len = can_dlc2len((id >> 16) & 0x0F);
else
cf->len = get_can_dlc((id >> 16) & 0x0F);
(..)
> @@ -804,7 +870,8 @@ static void m_can_chip_config(struct net_device *dev)
> RXFC_FWM_1 | priv->mcfg[MRAM_RXF1].off);
>
> cccr = m_can_read(priv, M_CAN_CCCR);
> - cccr &= ~(CCCR_TEST | CCCR_MON);
> + cccr &= ~(CCCR_TEST | CCCR_MON | (CCCR_CMR_MASK << CCCR_CMR_SHIFT) |
> + (CCCR_CME_MASK << CCCR_CME_SHIFT));
> test = m_can_read(priv, M_CAN_TEST);
> test &= ~TEST_LBCK;
>
> @@ -816,6 +883,9 @@ static void m_can_chip_config(struct net_device *dev)
> test |= TEST_LBCK;
> }
>
> + if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
> + cccr |= CCCR_CME_CANFD_BRS << CCCR_CME_SHIFT;
> +
> m_can_write(priv, M_CAN_CCCR, cccr);
> m_can_write(priv, M_CAN_TEST, test);
>
(..)
>
> + if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
> + cccr = m_can_read(priv, M_CAN_CCCR);
> + cccr &= ~(CCCR_CMR_MASK << CCCR_CMR_SHIFT);
> + if (cf->flags & CANFD_BRS)
> + cccr |= CCCR_CMR_CANFD_BRS << CCCR_CMR_SHIFT;
> + else
> + cccr |= CCCR_CMR_CANFD << CCCR_CMR_SHIFT;
> + m_can_write(priv, M_CAN_CCCR, cccr);
> + }
Unfortunately No. Here it becomes complicated due to the fact that the
revision 3.0.x does not support per-frame switching for FD/BRS ...
When (priv->can.ctrlmode & CAN_CTRLMODE_FD) is true this *only* tells us, that
the controller is _capable_ to send either CAN or CAN FD frames.
It does not configure the controller into one of these specific settings!
Additionally: AFAIK when writing to the CCCR you have to make sure that
there's currently no ongoing transfer.
I would suggest the following approach to make the revision 3.0.x act like a
correct CAN FD capable controller:
- create a helper function to switch FD and BRS while taking care of ongoing
transmissions
- create a variable that knows the current tx_mode for FD and BRS
When we need to send a CAN frame which doesn't fit the settings in the tx_mode
we need to switch the CCCR and update the tx_mode variable.
This at least reduces the needed CCCR operations.
And it also addresses the intention of your patch
[PATCH V1 4/4] can: m_can: allow to send std frame on CAN FD mode
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH V2 2/4] can: m_can: workaround for transmit data less than 4 bytes
From: Marc Kleine-Budde @ 2014-11-05 10:17 UTC (permalink / raw)
To: Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, socketcan, linux-arm-kernel
In-Reply-To: <1415174326-6623-2-git-send-email-b29396@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]
On 11/05/2014 08:58 AM, Dong Aisheng wrote:
> At least on the i.MX6SX with M_CAN IP version 3.0.x, an issue with
Can you add the imx mask revision, too and the exact m_can version (is
available).
> the Message RAM was discovered. Sending CAN frames with dlc less
> than 4 bytes will lead to bit errors, when the first 8 bytes of
> the Message RAM have not been initialized (i.e. written to).
> To work around this issue, the first 8 bytes are initialized in open()
> function.
>
> Without the workaround, we can easily see the following errors:
> root@imx6qdlsolo:~# ip link set can0 up type can bitrate 1000000
> [ 66.882520] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
> root@imx6qdlsolo:~# cansend can0 123#112233
> [ 66.935640] m_can 20e8000.can can0: Bit Error Uncorrected
>
> Signed-off-by: Dong Aisheng <b29396@freescale.com>
> ---
> ChangeLog since v1:
> * initialize the first 8 bytes of Tx Buffer of Message RAM in open()
> to workaround the issue
> ---
> drivers/net/can/m_can/m_can.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 664fe30..f47c200 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -902,6 +902,15 @@ static void m_can_chip_config(struct net_device *dev)
> /* set bittiming params */
> m_can_set_bittiming(dev);
>
> + /* At least on the i.MX6SX with M_CAN IP version 3.0.x, an issue with
> + * the Message RAM was discovered. Sending CAN frames with dlc less
> + * than 4 bytes will lead to bit errors, when the first 8 bytes of
> + * the Message RAM have not been initialized (i.e. written to).
> + * To work around this issue, the first 8 bytes are initialized here.
> + */
> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
> +
> m_can_config_endisable(priv, false);
> }
>
>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v3 3/4] stmmac: pci: use managed resources
From: Andy Shevchenko @ 2014-11-05 10:27 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
Vince Bridgers
Cc: Andy Shevchenko
In-Reply-To: <1415183249-9231-1-git-send-email-andriy.shevchenko@linux.intel.com>
Migrate pci driver to managed resources to reduce boilerplate error handling
code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 43 ++++++------------------
1 file changed, 10 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index f19ac8e..5357a3f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -71,46 +71,37 @@ static void stmmac_default_data(void)
static int stmmac_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
- int ret = 0;
- void __iomem *addr = NULL;
- struct stmmac_priv *priv = NULL;
+ struct stmmac_priv *priv;
int i;
+ int ret;
/* Enable pci device */
- ret = pci_enable_device(pdev);
+ ret = pcim_enable_device(pdev);
if (ret) {
pr_err("%s : ERROR: failed to enable %s device\n", __func__,
pci_name(pdev));
return ret;
}
- if (pci_request_regions(pdev, STMMAC_RESOURCE_NAME)) {
- pr_err("%s: ERROR: failed to get PCI region\n", __func__);
- ret = -ENODEV;
- goto err_out_req_reg_failed;
- }
/* Get the base address of device */
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
- addr = pci_iomap(pdev, i, 0);
- if (addr == NULL) {
- pr_err("%s: ERROR: cannot map register memory aborting",
- __func__);
- ret = -EIO;
- goto err_out_map_failed;
- }
+ ret = pcim_iomap_regions(pdev, BIT(i), pci_name(pdev));
+ if (ret)
+ return ret;
break;
}
+
pci_set_master(pdev);
stmmac_default_data();
- priv = stmmac_dvr_probe(&(pdev->dev), &plat_dat, addr);
+ priv = stmmac_dvr_probe(&pdev->dev, &plat_dat,
+ pcim_iomap_table(pdev)[i]);
if (IS_ERR(priv)) {
pr_err("%s: main driver probe failed", __func__);
- ret = PTR_ERR(priv);
- goto err_out;
+ return PTR_ERR(priv);
}
priv->dev->irq = pdev->irq;
priv->wol_irq = pdev->irq;
@@ -120,15 +111,6 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
pr_debug("STMMAC platform driver registration completed");
return 0;
-
-err_out:
- pci_clear_master(pdev);
-err_out_map_failed:
- pci_release_regions(pdev);
-err_out_req_reg_failed:
- pci_disable_device(pdev);
-
- return ret;
}
/**
@@ -141,13 +123,8 @@ err_out_req_reg_failed:
static void stmmac_pci_remove(struct pci_dev *pdev)
{
struct net_device *ndev = pci_get_drvdata(pdev);
- struct stmmac_priv *priv = netdev_priv(ndev);
stmmac_dvr_remove(ndev);
-
- pci_iounmap(pdev, priv->ioaddr);
- pci_release_regions(pdev);
- pci_disable_device(pdev);
}
#ifdef CONFIG_PM_SLEEP
--
2.1.1
^ permalink raw reply related
* [PATCH v3 0/4] stmmac: pci: various cleanups and fixes
From: Andy Shevchenko @ 2014-11-05 10:27 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
Vince Bridgers
Cc: Andy Shevchenko
There are few cleanups and fixes regarding to stmmac PCI driver.
This has been tested on Intel Galileo board with recent net-next tree.
Since v2:
- drop patch 5/5 since it will be part of a big change across entire subsystem
Since v1:
- remove already applied patch
- append patch 1/5
- rework patch 3/5 to be functional compatible with original code
Andy Shevchenko (4):
stmmac: pci: use defined constant instead of magic number
stmmac: pci: convert to use dev_pm_ops
stmmac: pci: use managed resources
stmmac: pci: convert to use dev_* macros
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 80 ++++++++----------------
1 file changed, 26 insertions(+), 54 deletions(-)
--
2.1.1
^ permalink raw reply
* [PATCH v3 1/4] stmmac: pci: use defined constant instead of magic number
From: Andy Shevchenko @ 2014-11-05 10:27 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev, Kweh Hock Leong, David S . Miller,
Vince Bridgers
Cc: Andy Shevchenko
In-Reply-To: <1415183249-9231-1-git-send-email-andriy.shevchenko@linux.intel.com>
The last standard PCI resource is defined as PCI_STD_RESOURCE_END. Thus, we
could use it instead of plain integer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index e17a970..e45794d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -90,7 +90,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
}
/* Get the base address of device */
- for (i = 0; i <= 5; i++) {
+ for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
addr = pci_iomap(pdev, i, 0);
--
2.1.1
^ permalink raw reply related
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