* Re: [PATCHv2 net 0/2] Add netdev_level_ratelimited to avoid netdev msg flush
From: Hangbin Liu @ 2019-08-12 7:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, joe, tlfalcon
In-Reply-To: <20190811.210820.1168889173898610979.davem@davemloft.net>
On Sun, Aug 11, 2019 at 09:08:20PM -0700, David Miller wrote:
> From: Hangbin Liu <liuhangbin@gmail.com>
> Date: Fri, 9 Aug 2019 08:29:39 +0800
>
> > ibmveth 30000003 env3: h_multicast_ctrl rc=4 when adding an entry to the filter table
> > error when add more thann 256 memberships in one multicast group. I haven't
> > found this issue on other driver. It looks like an ibm driver issue and need
> > to be fixed separately.
>
> You need to root cause and fix the reason this message appears so much.
>
> Once I let you rate limit the message you will have zero incentive to
> fix the real problem and fix it.
Sorry, I'm not familiar with ibmveth driver...
Hi Thomas,
Would you please help check why this issue happens
Thanks
Hangbbin
^ permalink raw reply
* Re: [PING 2] [PATCH v5 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: Lars Poeschel @ 2019-08-12 7:40 UTC (permalink / raw)
To: Johan Hovold
Cc: devicetree, Samuel Ortiz, open list:NFC SUBSYSTEM, open list,
netdev
In-Reply-To: <20190805124236.GG3574@localhost>
On Mon, Aug 05, 2019 at 02:42:36PM +0200, Johan Hovold wrote:
> You may want to resend this series to netdev now. David Miller will be
> picking up NFC patches directly from there.
Thank you very much for this information. Johannes Berg did reach out to
me already.
Rebase, test and resend is queued up for one of my next free timeslots.
Thanks again,
Lars
^ permalink raw reply
* [PATCH 1/5] can: xilinx_can: defer the probe if clock is not found
From: Appana Durga Kedareswara rao @ 2019-08-12 7:28 UTC (permalink / raw)
To: wg, mkl, davem, michal.simek
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel,
Venkatesh Yadav Abbarapu
In-Reply-To: <1565594914-18999-1-git-send-email-appana.durga.rao@xilinx.com>
From: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
It's not always the case that clock is already available when can
driver get probed at the first time, e.g. the clock is provided by
clock wizard which may be probed after can driver. So let's defer
the probe when devm_clk_get() call fails and give it chance to
try later.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/can/xilinx_can.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index bd95cfa..ac175ab 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -1791,7 +1791,8 @@ static int xcan_probe(struct platform_device *pdev)
/* Getting the CAN can_clk info */
priv->can_clk = devm_clk_get(&pdev->dev, "can_clk");
if (IS_ERR(priv->can_clk)) {
- dev_err(&pdev->dev, "Device clock not found.\n");
+ if (PTR_ERR(priv->can_clk) != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Device clock not found.\n");
ret = PTR_ERR(priv->can_clk);
goto err_free;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] can: xilinx_can: Fix the data updation logic for CANFD FD frames
From: Appana Durga Kedareswara rao @ 2019-08-12 7:28 UTC (permalink / raw)
To: wg, mkl, davem, michal.simek
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel,
Appana Durga Kedareswara rao
In-Reply-To: <1565594914-18999-1-git-send-email-appana.durga.rao@xilinx.com>
commit c223da689324 ("can: xilinx_can: Add support for CANFD FD frames")
is writing data to a wrong offset for FD frames.
This patch fixes this issue.
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Reviewed-by: Shubhrajyoti Datta <Shubhrajyoti.datta@xilinx.com>
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/can/xilinx_can.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 2d3399e..c9b951b 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -66,8 +66,7 @@ enum xcan_reg {
#define XCAN_FRAME_DLC_OFFSET(frame_base) ((frame_base) + 0x04)
#define XCAN_FRAME_DW1_OFFSET(frame_base) ((frame_base) + 0x08)
#define XCAN_FRAME_DW2_OFFSET(frame_base) ((frame_base) + 0x0C)
-#define XCANFD_FRAME_DW_OFFSET(frame_base, n) (((frame_base) + 0x08) + \
- ((n) * XCAN_CANFD_FRAME_SIZE))
+#define XCANFD_FRAME_DW_OFFSET(frame_base) ((frame_base) + 0x08)
#define XCAN_CANFD_FRAME_SIZE 0x48
#define XCAN_TXMSG_FRAME_OFFSET(n) (XCAN_TXMSG_BASE_OFFSET + \
@@ -600,7 +599,7 @@ static void xcan_write_frame(struct xcan_priv *priv, struct sk_buff *skb,
if (priv->devtype.cantype == XAXI_CANFD ||
priv->devtype.cantype == XAXI_CANFD_2_0) {
for (i = 0; i < cf->len; i += 4) {
- ramoff = XCANFD_FRAME_DW_OFFSET(frame_offset, dwindex) +
+ ramoff = XCANFD_FRAME_DW_OFFSET(frame_offset) +
(dwindex * XCANFD_DW_BYTES);
priv->write_reg(priv, ramoff,
be32_to_cpup((__be32 *)(cf->data + i)));
@@ -816,10 +815,8 @@ static int xcanfd_rx(struct net_device *ndev, int frame_base)
struct net_device_stats *stats = &ndev->stats;
struct canfd_frame *cf;
struct sk_buff *skb;
- u32 id_xcan, dlc, data[2] = {0, 0}, dwindex = 0, i, fsr, readindex;
+ u32 id_xcan, dlc, data[2] = {0, 0}, dwindex = 0, i, dw_offset;
- fsr = priv->read_reg(priv, XCAN_FSR_OFFSET);
- readindex = fsr & XCAN_FSR_RI_MASK;
id_xcan = priv->read_reg(priv, XCAN_FRAME_ID_OFFSET(frame_base));
dlc = priv->read_reg(priv, XCAN_FRAME_DLC_OFFSET(frame_base));
if (dlc & XCAN_DLCR_EDL_MASK)
@@ -863,26 +860,16 @@ static int xcanfd_rx(struct net_device *ndev, int frame_base)
/* Check the frame received is FD or not*/
if (dlc & XCAN_DLCR_EDL_MASK) {
for (i = 0; i < cf->len; i += 4) {
- if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
- data[0] = priv->read_reg(priv,
- (XCAN_RXMSG_2_FRAME_OFFSET(readindex) +
- (dwindex * XCANFD_DW_BYTES)));
- else
- data[0] = priv->read_reg(priv,
- (XCAN_RXMSG_FRAME_OFFSET(readindex) +
- (dwindex * XCANFD_DW_BYTES)));
+ dw_offset = XCANFD_FRAME_DW_OFFSET(frame_base) +
+ (dwindex * XCANFD_DW_BYTES);
+ data[0] = priv->read_reg(priv, dw_offset);
*(__be32 *)(cf->data + i) = cpu_to_be32(data[0]);
dwindex++;
}
} else {
for (i = 0; i < cf->len; i += 4) {
- if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
- data[0] = priv->read_reg(priv,
- XCAN_RXMSG_2_FRAME_OFFSET(readindex) +
- i);
- else
- data[0] = priv->read_reg(priv,
- XCAN_RXMSG_FRAME_OFFSET(readindex) + i);
+ dw_offset = XCANFD_FRAME_DW_OFFSET(frame_base);
+ data[0] = priv->read_reg(priv, dw_offset + i);
*(__be32 *)(cf->data + i) = cpu_to_be32(data[0]);
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH 5/5] can: xilinx_can: Fix the data phase btr1 calculation
From: Appana Durga Kedareswara rao @ 2019-08-12 7:28 UTC (permalink / raw)
To: wg, mkl, davem, michal.simek
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, Srinivas Neeli
In-Reply-To: <1565594914-18999-1-git-send-email-appana.durga.rao@xilinx.com>
From: Srinivas Neeli <srinivas.neeli@xilinx.com>
While calculating bitrate for the data phase, the driver is using phase
segment 1 of the arbitration phase instead of the data phase.
Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com>
Acked-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/can/xilinx_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 4cb8c1c9..ab26691 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -425,7 +425,7 @@ static int xcan_set_bittiming(struct net_device *ndev)
btr0 = dbt->brp - 1;
/* Setting Time Segment 1 in BTR Register */
- btr1 = dbt->prop_seg + bt->phase_seg1 - 1;
+ btr1 = dbt->prop_seg + dbt->phase_seg1 - 1;
/* Setting Time Segment 2 in BTR Register */
btr1 |= (dbt->phase_seg2 - 1) << priv->devtype.btr_ts2_shift;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] can: xilinx_can: Fix FSR register handling in the rx path
From: Appana Durga Kedareswara rao @ 2019-08-12 7:28 UTC (permalink / raw)
To: wg, mkl, davem, michal.simek
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel,
Appana Durga Kedareswara rao
In-Reply-To: <1565594914-18999-1-git-send-email-appana.durga.rao@xilinx.com>
After commit c223da689324 ("can: xilinx_can: Add support for
CANFD FD frames") Driver is updating the FSR IRI index multiple
times(i.e in xcanfd_rx() and xcan_rx_fifo_get_next_frame()),
It should be updated once per rx packet this patch fixes this issue,
also this patch removes the unnecessary fsr register checks in
xcanfd_rx() API.
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Reviewed-by: Shubhrajyoti Datta <Shubhrajyoti.datta@xilinx.com>
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/can/xilinx_can.c | 139 ++++++++++++++++++++-----------------------
1 file changed, 63 insertions(+), 76 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index ac175ab..2d3399e 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -819,91 +819,78 @@ static int xcanfd_rx(struct net_device *ndev, int frame_base)
u32 id_xcan, dlc, data[2] = {0, 0}, dwindex = 0, i, fsr, readindex;
fsr = priv->read_reg(priv, XCAN_FSR_OFFSET);
- if (fsr & XCAN_FSR_FL_MASK) {
- readindex = fsr & XCAN_FSR_RI_MASK;
- id_xcan = priv->read_reg(priv,
- XCAN_FRAME_ID_OFFSET(frame_base));
- dlc = priv->read_reg(priv, XCAN_FRAME_DLC_OFFSET(frame_base));
- if (dlc & XCAN_DLCR_EDL_MASK)
- skb = alloc_canfd_skb(ndev, &cf);
- else
- skb = alloc_can_skb(ndev, (struct can_frame **)&cf);
+ readindex = fsr & XCAN_FSR_RI_MASK;
+ id_xcan = priv->read_reg(priv, XCAN_FRAME_ID_OFFSET(frame_base));
+ dlc = priv->read_reg(priv, XCAN_FRAME_DLC_OFFSET(frame_base));
+ if (dlc & XCAN_DLCR_EDL_MASK)
+ skb = alloc_canfd_skb(ndev, &cf);
+ else
+ skb = alloc_can_skb(ndev, (struct can_frame **)&cf);
- if (unlikely(!skb)) {
- stats->rx_dropped++;
- return 0;
- }
+ if (unlikely(!skb)) {
+ stats->rx_dropped++;
+ return 0;
+ }
- /* Change Xilinx CANFD data length format to socketCAN data
- * format
- */
- if (dlc & XCAN_DLCR_EDL_MASK)
- cf->len = can_dlc2len((dlc & XCAN_DLCR_DLC_MASK) >>
+ /* Change Xilinx CANFD data length format to socketCAN data
+ * format
+ */
+ if (dlc & XCAN_DLCR_EDL_MASK)
+ cf->len = can_dlc2len((dlc & XCAN_DLCR_DLC_MASK) >>
+ XCAN_DLCR_DLC_SHIFT);
+ else
+ cf->len = get_can_dlc((dlc & XCAN_DLCR_DLC_MASK) >>
XCAN_DLCR_DLC_SHIFT);
- else
- cf->len = get_can_dlc((dlc & XCAN_DLCR_DLC_MASK) >>
- XCAN_DLCR_DLC_SHIFT);
-
- /* Change Xilinx CAN ID format to socketCAN ID format */
- if (id_xcan & XCAN_IDR_IDE_MASK) {
- /* The received frame is an Extended format frame */
- cf->can_id = (id_xcan & XCAN_IDR_ID1_MASK) >> 3;
- cf->can_id |= (id_xcan & XCAN_IDR_ID2_MASK) >>
- XCAN_IDR_ID2_SHIFT;
- cf->can_id |= CAN_EFF_FLAG;
- if (id_xcan & XCAN_IDR_RTR_MASK)
- cf->can_id |= CAN_RTR_FLAG;
- } else {
- /* The received frame is a standard format frame */
- cf->can_id = (id_xcan & XCAN_IDR_ID1_MASK) >>
- XCAN_IDR_ID1_SHIFT;
- if (!(dlc & XCAN_DLCR_EDL_MASK) && (id_xcan &
- XCAN_IDR_SRR_MASK))
- cf->can_id |= CAN_RTR_FLAG;
- }
- /* Check the frame received is FD or not*/
- if (dlc & XCAN_DLCR_EDL_MASK) {
- for (i = 0; i < cf->len; i += 4) {
- if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
- data[0] = priv->read_reg(priv,
+ /* Change Xilinx CAN ID format to socketCAN ID format */
+ if (id_xcan & XCAN_IDR_IDE_MASK) {
+ /* The received frame is an Extended format frame */
+ cf->can_id = (id_xcan & XCAN_IDR_ID1_MASK) >> 3;
+ cf->can_id |= (id_xcan & XCAN_IDR_ID2_MASK) >>
+ XCAN_IDR_ID2_SHIFT;
+ cf->can_id |= CAN_EFF_FLAG;
+ if (id_xcan & XCAN_IDR_RTR_MASK)
+ cf->can_id |= CAN_RTR_FLAG;
+ } else {
+ /* The received frame is a standard format frame */
+ cf->can_id = (id_xcan & XCAN_IDR_ID1_MASK) >>
+ XCAN_IDR_ID1_SHIFT;
+ if (!(dlc & XCAN_DLCR_EDL_MASK) && (id_xcan &
+ XCAN_IDR_SRR_MASK))
+ cf->can_id |= CAN_RTR_FLAG;
+ }
+
+ /* Check the frame received is FD or not*/
+ if (dlc & XCAN_DLCR_EDL_MASK) {
+ for (i = 0; i < cf->len; i += 4) {
+ if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
+ data[0] = priv->read_reg(priv,
(XCAN_RXMSG_2_FRAME_OFFSET(readindex) +
(dwindex * XCANFD_DW_BYTES)));
- else
- data[0] = priv->read_reg(priv,
+ else
+ data[0] = priv->read_reg(priv,
(XCAN_RXMSG_FRAME_OFFSET(readindex) +
- (dwindex * XCANFD_DW_BYTES)));
- *(__be32 *)(cf->data + i) =
- cpu_to_be32(data[0]);
- dwindex++;
- }
- } else {
- for (i = 0; i < cf->len; i += 4) {
- if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
- data[0] = priv->read_reg(priv,
- XCAN_RXMSG_2_FRAME_OFFSET(readindex) + i);
- else
- data[0] = priv->read_reg(priv,
- XCAN_RXMSG_FRAME_OFFSET(readindex) + i);
- *(__be32 *)(cf->data + i) =
- cpu_to_be32(data[0]);
- }
+ (dwindex * XCANFD_DW_BYTES)));
+ *(__be32 *)(cf->data + i) = cpu_to_be32(data[0]);
+ dwindex++;
+ }
+ } else {
+ for (i = 0; i < cf->len; i += 4) {
+ if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
+ data[0] = priv->read_reg(priv,
+ XCAN_RXMSG_2_FRAME_OFFSET(readindex) +
+ i);
+ else
+ data[0] = priv->read_reg(priv,
+ XCAN_RXMSG_FRAME_OFFSET(readindex) + i);
+ *(__be32 *)(cf->data + i) = cpu_to_be32(data[0]);
}
- /* Update FSR Register so that next packet will save to
- * buffer
- */
- fsr = priv->read_reg(priv, XCAN_FSR_OFFSET);
- fsr |= XCAN_FSR_IRI_MASK;
- priv->write_reg(priv, XCAN_FSR_OFFSET, fsr);
- fsr = priv->read_reg(priv, XCAN_FSR_OFFSET);
- stats->rx_bytes += cf->len;
- stats->rx_packets++;
- netif_receive_skb(skb);
-
- return 1;
}
- /* If FSR Register is not updated with fill level */
- return 0;
+ stats->rx_bytes += cf->len;
+ stats->rx_packets++;
+ netif_receive_skb(skb);
+
+ return 1;
}
/**
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] can: xilinx_can: Fix FSR register FL and RI mask values for canfd 2.0
From: Appana Durga Kedareswara rao @ 2019-08-12 7:28 UTC (permalink / raw)
To: wg, mkl, davem, michal.simek
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel,
Appana Durga Kedareswara rao
In-Reply-To: <1565594914-18999-1-git-send-email-appana.durga.rao@xilinx.com>
For CANFD 2.0 IP configuration existing driver is using incorrect mask
values for FSR register FL and RI fields.
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Acked-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/can/xilinx_can.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index c9b951b..4cb8c1c9 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -123,8 +123,10 @@ enum xcan_reg {
#define XCAN_IDR_RTR_MASK 0x00000001 /* Remote TX request */
#define XCAN_DLCR_DLC_MASK 0xF0000000 /* Data length code */
#define XCAN_FSR_FL_MASK 0x00003F00 /* RX Fill Level */
+#define XCAN_2_FSR_FL_MASK 0x00007F00 /* RX Fill Level */
#define XCAN_FSR_IRI_MASK 0x00000080 /* RX Increment Read Index */
#define XCAN_FSR_RI_MASK 0x0000001F /* RX Read Index */
+#define XCAN_2_FSR_RI_MASK 0x0000003F /* RX Read Index */
#define XCAN_DLCR_EDL_MASK 0x08000000 /* EDL Mask in DLC */
#define XCAN_DLCR_BRS_MASK 0x04000000 /* BRS Mask in DLC */
@@ -1138,7 +1140,7 @@ static int xcan_rx_fifo_get_next_frame(struct xcan_priv *priv)
int offset;
if (priv->devtype.flags & XCAN_FLAG_RX_FIFO_MULTI) {
- u32 fsr;
+ u32 fsr, mask;
/* clear RXOK before the is-empty check so that any newly
* received frame will reassert it without a race
@@ -1148,12 +1150,17 @@ static int xcan_rx_fifo_get_next_frame(struct xcan_priv *priv)
fsr = priv->read_reg(priv, XCAN_FSR_OFFSET);
/* check if RX FIFO is empty */
- if (!(fsr & XCAN_FSR_FL_MASK))
+ if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
+ mask = XCAN_2_FSR_FL_MASK;
+ else
+ mask = XCAN_FSR_FL_MASK;
+
+ if (!(fsr & mask))
return -ENOENT;
if (priv->devtype.flags & XCAN_FLAG_CANFD_2)
offset =
- XCAN_RXMSG_2_FRAME_OFFSET(fsr & XCAN_FSR_RI_MASK);
+ XCAN_RXMSG_2_FRAME_OFFSET(fsr & XCAN_2_FSR_RI_MASK);
else
offset =
XCAN_RXMSG_FRAME_OFFSET(fsr & XCAN_FSR_RI_MASK);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] can: xilinx_can: Bug fixes
From: Appana Durga Kedareswara rao @ 2019-08-12 7:28 UTC (permalink / raw)
To: wg, mkl, davem, michal.simek
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel,
Appana Durga Kedareswara rao
This patch series fixes below issues
--> Bugs in the driver w.r.to CANFD 2.0 IP support
--> Defer the probe if clock is not found
Appana Durga Kedareswara rao (3):
can: xilinx_can: Fix FSR register handling in the rx path
can: xilinx_can: Fix the data updation logic for CANFD FD frames
can: xilinx_can: Fix FSR register FL and RI mask values for canfd 2.0
Srinivas Neeli (1):
can: xilinx_can: Fix the data phase btr1 calculation
Venkatesh Yadav Abbarapu (1):
can: xilinx_can: defer the probe if clock is not found
drivers/net/can/xilinx_can.c | 162 +++++++++++++++++++------------------------
1 file changed, 72 insertions(+), 90 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v4 1/2] perf machine: Support arch's specific kernel start address
From: Adrian Hunter @ 2019-08-12 7:23 UTC (permalink / raw)
To: Leo Yan
Cc: Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Milian Wolff, Donald Yandt, Davidlohr Bueso, Wei Li, Mark Drayton,
Tzvetomir Stoyanov (VMware), linux-kernel, netdev, bpf,
clang-built-linux, Mathieu Poirier
In-Reply-To: <20190812070236.GA8062@leoy-ThinkPad-X240s>
On 12/08/19 10:02 AM, Leo Yan wrote:
> On Mon, Aug 12, 2019 at 09:37:33AM +0300, Adrian Hunter wrote:
>> On 10/08/19 10:21 AM, Leo Yan wrote:
>>> machine__get_kernel_start() gives out the kernel start address; some
>>> architectures need to tweak the start address so that can reflect the
>>> kernel start address correctly. This is not only for x86_64 arch, but
>>> it is also required by other architectures, e.g. arm/arm64 needs to
>>> tweak the kernel start address so can include the kernel memory regions
>>> which are used before the '_stext' symbol.
>>>
>>> This patch refactors machine__get_kernel_start() by adding a weak
>>> arch__fix_kernel_text_start(), any architecture can implement it to
>>> tweak its specific start address; this also allows the arch specific
>>> code to be placed into 'arch' folder.
>>>
>>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>>> ---
>>> tools/perf/arch/x86/util/machine.c | 10 ++++++++++
>>> tools/perf/util/machine.c | 13 +++++++------
>>> tools/perf/util/machine.h | 2 ++
>>> 3 files changed, 19 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/tools/perf/arch/x86/util/machine.c b/tools/perf/arch/x86/util/machine.c
>>> index 1e9ec783b9a1..9f012131534a 100644
>>> --- a/tools/perf/arch/x86/util/machine.c
>>> +++ b/tools/perf/arch/x86/util/machine.c
>>> @@ -101,4 +101,14 @@ int machine__create_extra_kernel_maps(struct machine *machine,
>>> return ret;
>>> }
>>>
>>> +void arch__fix_kernel_text_start(u64 *start)
>>> +{
>>> + /*
>>> + * On x86_64, PTI entry trampolines are less than the
>>> + * start of kernel text, but still above 2^63. So leave
>>> + * kernel_start = 1ULL << 63 for x86_64.
>>> + */
>>> + *start = 1ULL << 63;
>>> +}
>>
>> That is needed for reporting x86 data on any arch i.e. it is not specific to
>> the compile-time architecture, it is specific to the perf.data file
>> architecture, which is what machine__is() compares. So, this looks wrong.
>
> Thanks for reviewing, Adrian.
>
> If so, I think we should extend the function machine__get_kernel_start()
> as below; for building successfully, will always define the macro
> ARM_PRE_START_SIZE in Makefile.config.
>
> @Arnaldo, @Adrian, Please let me know if this works for you?
I don't know how you intend to calculate ARM_PRE_START_SIZE, but below is OK
for x86.
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index f6ee7fbad3e4..30a0ff627263 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -2687,13 +2687,26 @@ int machine__get_kernel_start(struct machine *machine)
> machine->kernel_start = 1ULL << 63;
> if (map) {
> err = map__load(map);
> + if (err)
> + return err;
> +
> /*
> * On x86_64, PTI entry trampolines are less than the
> * start of kernel text, but still above 2^63. So leave
> * kernel_start = 1ULL << 63 for x86_64.
> */
> - if (!err && !machine__is(machine, "x86_64"))
> + if (!machine__is(machine, "x86_64"))
> machine->kernel_start = map->start;
> +
> + /*
> + * On arm/arm64, some memory regions are prior to '_stext'
> + * symbol; to reflect the complete kernel address space,
> + * compensate these pre-defined regions for kernel start
> + * address.
> + */
> + if (machine__is(machine, "arm64") ||
> + machine__is(machine, "arm"))
machine__is() does not normalize the architecture, so you may want to use
perf_env__arch() instead.
> + machine->kernel_start -= ARM_PRE_START_SIZE;
> }
> return err;
> }
>
> Thanks,
> Leo Yan
>
>>> +
>>> #endif
>>> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
>>> index f6ee7fbad3e4..603518835692 100644
>>> --- a/tools/perf/util/machine.c
>>> +++ b/tools/perf/util/machine.c
>>> @@ -2671,6 +2671,10 @@ int machine__nr_cpus_avail(struct machine *machine)
>>> return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
>>> }
>>>
>>> +void __weak arch__fix_kernel_text_start(u64 *start __maybe_unused)
>>> +{
>>> +}
>>> +
>>> int machine__get_kernel_start(struct machine *machine)
>>> {
>>> struct map *map = machine__kernel_map(machine);
>>> @@ -2687,14 +2691,11 @@ int machine__get_kernel_start(struct machine *machine)
>>> machine->kernel_start = 1ULL << 63;
>>> if (map) {
>>> err = map__load(map);
>>> - /*
>>> - * On x86_64, PTI entry trampolines are less than the
>>> - * start of kernel text, but still above 2^63. So leave
>>> - * kernel_start = 1ULL << 63 for x86_64.
>>> - */
>>> - if (!err && !machine__is(machine, "x86_64"))
>>> + if (!err)
>>> machine->kernel_start = map->start;
>>> }
>>> +
>>> + arch__fix_kernel_text_start(&machine->kernel_start);
>>> return err;
>>> }
>>>
>>> diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
>>> index ef803f08ae12..9cb459f4bfbc 100644
>>> --- a/tools/perf/util/machine.h
>>> +++ b/tools/perf/util/machine.h
>>> @@ -278,6 +278,8 @@ void machine__get_kallsyms_filename(struct machine *machine, char *buf,
>>> int machine__create_extra_kernel_maps(struct machine *machine,
>>> struct dso *kernel);
>>>
>>> +void arch__fix_kernel_text_start(u64 *start);
>>> +
>>> /* Kernel-space maps for symbols that are outside the main kernel map and module maps */
>>> struct extra_kernel_map {
>>> u64 start;
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v3 bpf-next] btf: expose BTF info through sysfs
From: Greg KH @ 2019-08-12 7:08 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, netdev, ast, daniel, yhs, andrii.nakryiko, kernel-team,
Masahiro Yamada, Arnaldo Carvalho de Melo, Jiri Olsa,
Sam Ravnborg
In-Reply-To: <20190812061405.2290824-1-andriin@fb.com>
On Sun, Aug 11, 2019 at 11:14:05PM -0700, Andrii Nakryiko wrote:
> Make .BTF section allocated and expose its contents through sysfs.
>
> /sys/kernel/btf directory is created to contain all the BTFs present
> inside kernel. Currently there is only kernel's main BTF, represented as
> /sys/kernel/btf/kernel file. Once kernel modules' BTFs are supported,
> each module will expose its BTF as /sys/kernel/btf/<module-name> file.
>
> Current approach relies on a few pieces coming together:
> 1. pahole is used to take almost final vmlinux image (modulo .BTF and
> kallsyms) and generate .BTF section by converting DWARF info into
> BTF. This section is not allocated and not mapped to any segment,
> though, so is not yet accessible from inside kernel at runtime.
> 2. objcopy dumps .BTF contents into binary file and subsequently
> convert binary file into linkable object file with automatically
> generated symbols _binary__btf_kernel_bin_start and
> _binary__btf_kernel_bin_end, pointing to start and end, respectively,
> of BTF raw data.
> 3. final vmlinux image is generated by linking this object file (and
> kallsyms, if necessary). sysfs_btf.c then creates
> /sys/kernel/btf/kernel file and exposes embedded BTF contents through
> it. This allows, e.g., libbpf and bpftool access BTF info at
> well-known location, without resorting to searching for vmlinux image
> on disk (location of which is not standardized and vmlinux image
> might not be even available in some scenarios, e.g., inside qemu
> during testing).
>
> Alternative approach using .incbin assembler directive to embed BTF
> contents directly was attempted but didn't work, because sysfs_proc.o is
> not re-compiled during link-vmlinux.sh stage. This is required, though,
> to update embedded BTF data (initially empty data is embedded, then
> pahole generates BTF info and we need to regenerate sysfs_btf.o with
> updated contents, but it's too late at that point).
>
> If BTF couldn't be generated due to missing or too old pahole,
> sysfs_btf.c handles that gracefully by detecting that
> _binary__btf_kernel_bin_start (weak symbol) is 0 and not creating
> /sys/kernel/btf at all.
>
> v2->v3:
> - added Documentation/ABI/testing/sysfs-kernel-btf (Greg K-H);
> - created proper kobject (btf_kobj) for btf directory (Greg K-H);
> - undo v2 change of reusing vmlinux, as it causes extra kallsyms pass
> due to initially missing __binary__btf_kernel_bin_{start/end} symbols;
>
> v1->v2:
> - allow kallsyms stage to re-use vmlinux generated by gen_btf();
>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> Documentation/ABI/testing/sysfs-kernel-btf | 17 +++++++
> kernel/bpf/Makefile | 3 ++
> kernel/bpf/sysfs_btf.c | 51 +++++++++++++++++++++
> scripts/link-vmlinux.sh | 52 ++++++++++++++--------
> 4 files changed, 104 insertions(+), 19 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-kernel-btf
> create mode 100644 kernel/bpf/sysfs_btf.c
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v4 1/2] perf machine: Support arch's specific kernel start address
From: Leo Yan @ 2019-08-12 7:02 UTC (permalink / raw)
To: Adrian Hunter
Cc: Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Milian Wolff, Donald Yandt, Davidlohr Bueso, Wei Li, Mark Drayton,
Tzvetomir Stoyanov (VMware), linux-kernel, netdev, bpf,
clang-built-linux, Mathieu Poirier
In-Reply-To: <c1818f6f-37df-6971-fddc-6663e5b6ff95@intel.com>
On Mon, Aug 12, 2019 at 09:37:33AM +0300, Adrian Hunter wrote:
> On 10/08/19 10:21 AM, Leo Yan wrote:
> > machine__get_kernel_start() gives out the kernel start address; some
> > architectures need to tweak the start address so that can reflect the
> > kernel start address correctly. This is not only for x86_64 arch, but
> > it is also required by other architectures, e.g. arm/arm64 needs to
> > tweak the kernel start address so can include the kernel memory regions
> > which are used before the '_stext' symbol.
> >
> > This patch refactors machine__get_kernel_start() by adding a weak
> > arch__fix_kernel_text_start(), any architecture can implement it to
> > tweak its specific start address; this also allows the arch specific
> > code to be placed into 'arch' folder.
> >
> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > ---
> > tools/perf/arch/x86/util/machine.c | 10 ++++++++++
> > tools/perf/util/machine.c | 13 +++++++------
> > tools/perf/util/machine.h | 2 ++
> > 3 files changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/tools/perf/arch/x86/util/machine.c b/tools/perf/arch/x86/util/machine.c
> > index 1e9ec783b9a1..9f012131534a 100644
> > --- a/tools/perf/arch/x86/util/machine.c
> > +++ b/tools/perf/arch/x86/util/machine.c
> > @@ -101,4 +101,14 @@ int machine__create_extra_kernel_maps(struct machine *machine,
> > return ret;
> > }
> >
> > +void arch__fix_kernel_text_start(u64 *start)
> > +{
> > + /*
> > + * On x86_64, PTI entry trampolines are less than the
> > + * start of kernel text, but still above 2^63. So leave
> > + * kernel_start = 1ULL << 63 for x86_64.
> > + */
> > + *start = 1ULL << 63;
> > +}
>
> That is needed for reporting x86 data on any arch i.e. it is not specific to
> the compile-time architecture, it is specific to the perf.data file
> architecture, which is what machine__is() compares. So, this looks wrong.
Thanks for reviewing, Adrian.
If so, I think we should extend the function machine__get_kernel_start()
as below; for building successfully, will always define the macro
ARM_PRE_START_SIZE in Makefile.config.
@Arnaldo, @Adrian, Please let me know if this works for you?
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index f6ee7fbad3e4..30a0ff627263 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2687,13 +2687,26 @@ int machine__get_kernel_start(struct machine *machine)
machine->kernel_start = 1ULL << 63;
if (map) {
err = map__load(map);
+ if (err)
+ return err;
+
/*
* On x86_64, PTI entry trampolines are less than the
* start of kernel text, but still above 2^63. So leave
* kernel_start = 1ULL << 63 for x86_64.
*/
- if (!err && !machine__is(machine, "x86_64"))
+ if (!machine__is(machine, "x86_64"))
machine->kernel_start = map->start;
+
+ /*
+ * On arm/arm64, some memory regions are prior to '_stext'
+ * symbol; to reflect the complete kernel address space,
+ * compensate these pre-defined regions for kernel start
+ * address.
+ */
+ if (machine__is(machine, "arm64") ||
+ machine__is(machine, "arm"))
+ machine->kernel_start -= ARM_PRE_START_SIZE;
}
return err;
}
Thanks,
Leo Yan
> > +
> > #endif
> > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> > index f6ee7fbad3e4..603518835692 100644
> > --- a/tools/perf/util/machine.c
> > +++ b/tools/perf/util/machine.c
> > @@ -2671,6 +2671,10 @@ int machine__nr_cpus_avail(struct machine *machine)
> > return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
> > }
> >
> > +void __weak arch__fix_kernel_text_start(u64 *start __maybe_unused)
> > +{
> > +}
> > +
> > int machine__get_kernel_start(struct machine *machine)
> > {
> > struct map *map = machine__kernel_map(machine);
> > @@ -2687,14 +2691,11 @@ int machine__get_kernel_start(struct machine *machine)
> > machine->kernel_start = 1ULL << 63;
> > if (map) {
> > err = map__load(map);
> > - /*
> > - * On x86_64, PTI entry trampolines are less than the
> > - * start of kernel text, but still above 2^63. So leave
> > - * kernel_start = 1ULL << 63 for x86_64.
> > - */
> > - if (!err && !machine__is(machine, "x86_64"))
> > + if (!err)
> > machine->kernel_start = map->start;
> > }
> > +
> > + arch__fix_kernel_text_start(&machine->kernel_start);
> > return err;
> > }
> >
> > diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
> > index ef803f08ae12..9cb459f4bfbc 100644
> > --- a/tools/perf/util/machine.h
> > +++ b/tools/perf/util/machine.h
> > @@ -278,6 +278,8 @@ void machine__get_kallsyms_filename(struct machine *machine, char *buf,
> > int machine__create_extra_kernel_maps(struct machine *machine,
> > struct dso *kernel);
> >
> > +void arch__fix_kernel_text_start(u64 *start);
> > +
> > /* Kernel-space maps for symbols that are outside the main kernel map and module maps */
> > struct extra_kernel_map {
> > u64 start;
> >
>
^ permalink raw reply related
* Re: [PATCH v4 1/2] perf machine: Support arch's specific kernel start address
From: Adrian Hunter @ 2019-08-12 6:37 UTC (permalink / raw)
To: Leo Yan, Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Milian Wolff, Donald Yandt, Davidlohr Bueso, Wei Li, Mark Drayton,
Tzvetomir Stoyanov (VMware), linux-kernel, netdev, bpf,
clang-built-linux, Mathieu Poirier
In-Reply-To: <20190810072135.27072-2-leo.yan@linaro.org>
On 10/08/19 10:21 AM, Leo Yan wrote:
> machine__get_kernel_start() gives out the kernel start address; some
> architectures need to tweak the start address so that can reflect the
> kernel start address correctly. This is not only for x86_64 arch, but
> it is also required by other architectures, e.g. arm/arm64 needs to
> tweak the kernel start address so can include the kernel memory regions
> which are used before the '_stext' symbol.
>
> This patch refactors machine__get_kernel_start() by adding a weak
> arch__fix_kernel_text_start(), any architecture can implement it to
> tweak its specific start address; this also allows the arch specific
> code to be placed into 'arch' folder.
>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> tools/perf/arch/x86/util/machine.c | 10 ++++++++++
> tools/perf/util/machine.c | 13 +++++++------
> tools/perf/util/machine.h | 2 ++
> 3 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/arch/x86/util/machine.c b/tools/perf/arch/x86/util/machine.c
> index 1e9ec783b9a1..9f012131534a 100644
> --- a/tools/perf/arch/x86/util/machine.c
> +++ b/tools/perf/arch/x86/util/machine.c
> @@ -101,4 +101,14 @@ int machine__create_extra_kernel_maps(struct machine *machine,
> return ret;
> }
>
> +void arch__fix_kernel_text_start(u64 *start)
> +{
> + /*
> + * On x86_64, PTI entry trampolines are less than the
> + * start of kernel text, but still above 2^63. So leave
> + * kernel_start = 1ULL << 63 for x86_64.
> + */
> + *start = 1ULL << 63;
> +}
That is needed for reporting x86 data on any arch i.e. it is not specific to
the compile-time architecture, it is specific to the perf.data file
architecture, which is what machine__is() compares. So, this looks wrong.
> +
> #endif
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index f6ee7fbad3e4..603518835692 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -2671,6 +2671,10 @@ int machine__nr_cpus_avail(struct machine *machine)
> return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
> }
>
> +void __weak arch__fix_kernel_text_start(u64 *start __maybe_unused)
> +{
> +}
> +
> int machine__get_kernel_start(struct machine *machine)
> {
> struct map *map = machine__kernel_map(machine);
> @@ -2687,14 +2691,11 @@ int machine__get_kernel_start(struct machine *machine)
> machine->kernel_start = 1ULL << 63;
> if (map) {
> err = map__load(map);
> - /*
> - * On x86_64, PTI entry trampolines are less than the
> - * start of kernel text, but still above 2^63. So leave
> - * kernel_start = 1ULL << 63 for x86_64.
> - */
> - if (!err && !machine__is(machine, "x86_64"))
> + if (!err)
> machine->kernel_start = map->start;
> }
> +
> + arch__fix_kernel_text_start(&machine->kernel_start);
> return err;
> }
>
> diff --git a/tools/perf/util/machine.h b/tools/perf/util/machine.h
> index ef803f08ae12..9cb459f4bfbc 100644
> --- a/tools/perf/util/machine.h
> +++ b/tools/perf/util/machine.h
> @@ -278,6 +278,8 @@ void machine__get_kallsyms_filename(struct machine *machine, char *buf,
> int machine__create_extra_kernel_maps(struct machine *machine,
> struct dso *kernel);
>
> +void arch__fix_kernel_text_start(u64 *start);
> +
> /* Kernel-space maps for symbols that are outside the main kernel map and module maps */
> struct extra_kernel_map {
> u64 start;
>
^ permalink raw reply
* [PATCH] net/mlx4_en: fix a memory leak bug
From: Wenwen Wang @ 2019-08-12 6:36 UTC (permalink / raw)
To: Wenwen Wang
Cc: Tariq Toukan, David S. Miller,
open list:MELLANOX ETHERNET DRIVER (mlx4_en),
open list:MELLANOX MLX4 core VPI driver, open list
In mlx4_en_config_rss_steer(), 'rss_map->indir_qp' is allocated through
kzalloc(). After that, mlx4_qp_alloc() is invoked to configure RSS
indirection. However, if mlx4_qp_alloc() fails, the allocated
'rss_map->indir_qp' is not deallocated, leading to a memory leak bug.
To fix the above issue, add the 'mlx4_err' label to free
'rss_map->indir_qp'.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6c01314..9476dbd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1187,7 +1187,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
err = mlx4_qp_alloc(mdev->dev, priv->base_qpn, rss_map->indir_qp);
if (err) {
en_err(priv, "Failed to allocate RSS indirection QP\n");
- goto rss_err;
+ goto mlx4_err;
}
rss_map->indir_qp->event = mlx4_en_sqp_event;
@@ -1241,6 +1241,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
MLX4_QP_STATE_RST, NULL, 0, 0, rss_map->indir_qp);
mlx4_qp_remove(mdev->dev, rss_map->indir_qp);
mlx4_qp_free(mdev->dev, rss_map->indir_qp);
+mlx4_err:
kfree(rss_map->indir_qp);
rss_map->indir_qp = NULL;
rss_err:
--
2.7.4
^ permalink raw reply related
* [PATCH] e1000: fix memory leaks
From: Wenwen Wang @ 2019-08-12 5:59 UTC (permalink / raw)
To: Wenwen Wang
Cc: Jeff Kirsher, David S. Miller,
moderated list:INTEL ETHERNET DRIVERS,
open list:NETWORKING DRIVERS, open list
In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if
e1000_up() fails, leading to memory leaks. Refactor the code to fix this
issue.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index a410085..2e07ffa 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -607,6 +607,7 @@ static int e1000_set_ringparam(struct net_device *netdev,
for (i = 0; i < adapter->num_rx_queues; i++)
rxdr[i].count = rxdr->count;
+ err = 0;
if (netif_running(adapter->netdev)) {
/* Try to get new resources before deleting old */
err = e1000_setup_all_rx_resources(adapter);
@@ -627,14 +628,13 @@ static int e1000_set_ringparam(struct net_device *netdev,
adapter->rx_ring = rxdr;
adapter->tx_ring = txdr;
err = e1000_up(adapter);
- if (err)
- goto err_setup;
}
kfree(tx_old);
kfree(rx_old);
clear_bit(__E1000_RESETTING, &adapter->flags);
- return 0;
+ return err;
+
err_setup_tx:
e1000_free_all_rx_resources(adapter);
err_setup_rx:
@@ -646,7 +646,6 @@ static int e1000_set_ringparam(struct net_device *netdev,
err_alloc_tx:
if (netif_running(adapter->netdev))
e1000_up(adapter);
-err_setup:
clear_bit(__E1000_RESETTING, &adapter->flags);
return err;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] net: can: Fix compiling warning
From: maowenan @ 2019-08-12 5:48 UTC (permalink / raw)
To: Oliver Hartkopp, Dan Carpenter
Cc: davem, netdev, linux-kernel, kernel-janitors
In-Reply-To: <6e1c5aa0-8ed3-eec3-a34d-867ea8f54e9d@hartkopp.net>
On 2019/8/7 0:41, Oliver Hartkopp wrote:
> Hello Dan,
>
> On 06/08/2019 15.52, Dan Carpenter wrote:
>> On Fri, Aug 02, 2019 at 10:10:20AM +0200, Oliver Hartkopp wrote:
>
>>> Btw. what kind of compiler/make switches are you using so that I can see
>>> these warnings myself the next time?
>>
>> These are Sparse warnings, not from GCC.
>
> I compiled the code (the original version), but I do not get that "Should it be static?" warning:
Hello Oliver,
here are my steps for net/can/bcm.c,
make allmodconfig ARCH=mips CROSS_COMPILE=mips-linux-gnu-
make C=2 net/can/bcm.o ARCH=mips CROSS_COMPILE=mips-linux-gnu-
CHECK scripts/mod/empty.c
CALL scripts/checksyscalls.sh
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
CALL scripts/atomic/check-atomics.sh
CHECK net/can/bcm.c
./include/linux/slab.h:672:13: error: undefined identifier '__builtin_mul_overflow'
./include/linux/slab.h:672:13: error: not a function <noident>
./include/linux/slab.h:672:13: error: not a function <noident>
net/can/bcm.c:1683:5: warning: symbol 'bcm_sock_no_ioctlcmd' was not declared. Should it be static?
./include/linux/slab.h:672:13: warning: call with no type!
CC [M] net/can/bcm.o
for net/can/raw.c,
make allmodconfig ARCH=mips CROSS_COMPILE=mips-linux-gnu-
make C=2 net/can/raw.o ARCH=mips CROSS_COMPILE=mips-linux-gnu-
CHECK scripts/mod/empty.c
CALL scripts/checksyscalls.sh
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
CALL scripts/atomic/check-atomics.sh
CHECK net/can/raw.c
net/can/raw.c:840:5: warning: symbol 'raw_sock_no_ioctlcmd' was not declared. Should it be static?
CC [M] net/can/raw.o
^ permalink raw reply
* Re: [PATCH net] net: phy: rtl8211f: do a double read to get real time link status
From: Yonglong Liu @ 2019-08-12 4:49 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn
Cc: davem, netdev, linux-kernel, linuxarm, salil.mehta, yisen.zhuang,
shiju.jose
In-Reply-To: <7f18113e-268b-6a4a-af83-236cfa337fcd@gmail.com>
On 2019/8/10 4:05, Heiner Kallweit wrote:
> On 09.08.2019 06:57, Yonglong Liu wrote:
>>
>>
>> On 2019/8/9 4:34, Andrew Lunn wrote:
>>> On Thu, Aug 08, 2019 at 10:01:39PM +0200, Heiner Kallweit wrote:
>>>> On 08.08.2019 21:40, Andrew Lunn wrote:
>>>>>> @@ -568,6 +568,11 @@ int phy_start_aneg(struct phy_device *phydev)
>>>>>> if (err < 0)
>>>>>> goto out_unlock;
>>>>>>
>>>>>> + /* The PHY may not yet have cleared aneg-completed and link-up bit
>>>>>> + * w/o this delay when the following read is done.
>>>>>> + */
>>>>>> + usleep_range(1000, 2000);
>>>>>> +
>>>>>
>>>>> Hi Heiner
>>>>>
>>>>> Does 802.3 C22 say anything about this?
>>>>>
>>>> C22 says:
>>>> "The Auto-Negotiation process shall be restarted by setting bit 0.9 to a logic one. This bit is self-
>>>> clearing, and a PHY shall return a value of one in bit 0.9 until the Auto-Negotiation process has been
>>>> initiated."
>>>>
>>>> Maybe we should read bit 0.9 in genphy_update_link() after having read BMSR and report
>>>> aneg-complete and link-up as false (no matter of their current value) if 0.9 is set.
>>>
>>> Yes. That sounds sensible.
>>>
>>> Andrew
>>>
>>> .
>>>
>>
>> Hi Heiner:
>> I have test more than 50 times, it works. Previously less
>> than 20 times must be recurrence. so I think this patch solved the
>> problem.
>> And I checked about 40 times of the time gap between read
>> and autoneg started, all of them is more than 2ms, as below:
>>
>> kworker/u257:1-670 [015] .... 27.182632: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x00 val:0x1240
>> kworker/u257:1-670 [015] .... 27.184670: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
>>
>>
>
> Instead of using this fixed delay, the following experimental patch
> considers that fact that between triggering aneg start and actual
> start of aneg (incl. clearing aneg-complete bit) Clause 22 requires
> a PHY to keep bit 0.9 (aneg restart) set.
> Could you please test this instead of the fixed-delay patch?
>
> Thanks, Heiner
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index b039632de..163295dbc 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1741,7 +1741,17 @@ EXPORT_SYMBOL(genphy_aneg_done);
> */
> int genphy_update_link(struct phy_device *phydev)
> {
> - int status;
> + int status = 0, bmcr;
> +
> + bmcr = phy_read(phydev, MII_BMCR);
> + if (bmcr < 0)
> + return bmcr;
> +
> + /* Autoneg is being started, therefore disregard BMSR value and
> + * report link as down.
> + */
> + if (bmcr & BMCR_ANRESTART)
> + goto done;
>
> /* The link state is latched low so that momentary link
> * drops can be detected. Do not double-read the status
>
Hi Heiner:
Have test 50+ times, this patch can solved the problem too!
Share the mdio trace after executing ifconfig ethx up:
# tracer: nop
#
# entries-in-buffer/entries-written: 60/60 #P:128
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
ifconfig-1174 [005] .... 27.026691: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 27.026734: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x04 val:0x01e1
kworker/u257:1-670 [020] .... 27.026744: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x04 val:0x05e1
kworker/u257:1-670 [020] .... 27.026799: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
kworker/u257:1-670 [020] .... 27.026834: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x09 val:0x0200
kworker/u257:1-670 [020] .... 27.026869: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 27.026879: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x00 val:0x1240
kworker/u257:1-670 [020] .... 27.026932: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1240
kworker/u257:1-670 [020] .... 28.031770: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 28.031837: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
kworker/u257:1-670 [020] .... 29.055837: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [020] .... 29.055873: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
kworker/u257:0-8 [004] .... 30.079840: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 30.079875: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x7989
kworker/u257:0-8 [004] .... 31.103771: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 31.103839: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79a9
kworker/u257:0-8 [004] .... 31.103906: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x0a val:0x7803
kworker/u257:0-8 [004] .... 31.103973: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x09 val:0x0200
kworker/u257:0-8 [004] .... 31.104041: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x05 val:0xc1e1
kworker/u257:0-8 [004] .... 32.127814: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 32.127881: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
kworker/u257:0-8 [004] .... 32.127948: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x0a val:0x4800
kworker/u257:0-8 [004] .... 32.128015: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x09 val:0x0200
kworker/u257:0-8 [004] .... 32.128082: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x05 val:0xc1e1
kworker/u257:0-8 [004] .... 33.151775: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:0-8 [004] .... 33.151815: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
kworker/u257:1-670 [021] .... 34.175771: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
kworker/u257:1-670 [021] .... 34.175838: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x01 val:0x79ad
ifconfig-1177 [005] .... 35.052340: mdio_access: mii-0000:bd:00.3 read phy:0x07 reg:0x00 val:0x1040
ifconfig-1177 [005] .... 35.052350: mdio_access: mii-0000:bd:00.3 write phy:0x07 reg:0x00 val:0x1840
^ permalink raw reply
* Re: [PATCH] net: tc35815: Explicitly check NET_IP_ALIGN is not zero in tc35815_rx
From: David Miller @ 2019-08-12 4:42 UTC (permalink / raw)
To: natechancellor; +Cc: netdev, linux-kernel, clang-built-linux
In-Reply-To: <20190812031345.41157-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Sun, 11 Aug 2019 20:13:45 -0700
> clang warns:
>
> drivers/net/ethernet/toshiba/tc35815.c:1507:30: warning: use of logical
> '&&' with constant operand [-Wconstant-logical-operand]
> if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
> ^ ~~~~~~~~~~~~
> drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: use '&' for a
> bitwise operation
> if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
> ^~
> &
> drivers/net/ethernet/toshiba/tc35815.c:1507:30: note: remove constant to
> silence this warning
> if (!HAVE_DMA_RXALIGN(lp) && NET_IP_ALIGN)
> ~^~~~~~~~~~~~~~~
> 1 warning generated.
>
> Explicitly check that NET_IP_ALIGN is not zero, which matches how this
> is checked in other parts of the tree. Because NET_IP_ALIGN is a build
> time constant, this check will be constant folded away during
> optimization.
>
> Fixes: 82a9928db560 ("tc35815: Enable StripCRC feature")
> Link: https://github.com/ClangBuiltLinux/linux/issues/608
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied but I think clang is being rediculous.
^ permalink raw reply
* Re: [PATCH v3] tipc: initialise addr_trail_end when setting node addresses
From: David Miller @ 2019-08-12 4:40 UTC (permalink / raw)
To: chris.packham; +Cc: jon.maloy, ying.xue, netdev, tipc-discussion, linux-kernel
In-Reply-To: <20190811201825.13876-1-chris.packham@alliedtelesis.co.nz>
From: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date: Mon, 12 Aug 2019 08:18:25 +1200
> We set the field 'addr_trial_end' to 'jiffies', instead of the current
> value 0, at the moment the node address is initialized. This guarantees
> we don't inadvertently enter an address trial period when the node
> address is explicitly set by the user.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v3] net: dsa: Check existence of .port_mdb_add callback before calling it
From: David Miller @ 2019-08-12 4:37 UTC (permalink / raw)
To: wens; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190811141825.11566-1-wens@kernel.org>
From: Chen-Yu Tsai <wens@kernel.org>
Date: Sun, 11 Aug 2019 22:18:25 +0800
> From: Chen-Yu Tsai <wens@csie.org>
>
> The dsa framework has optional .port_mdb_{prepare,add,del} callback fields
> for drivers to handle multicast database entries. When adding an entry, the
> framework goes through a prepare phase, then a commit phase. Drivers not
> providing these callbacks should be detected in the prepare phase.
>
> DSA core may still bypass the bridge layer and call the dsa_port_mdb_add
> function directly with no prepare phase or no switchdev trans object,
> and the framework ends up calling an undefined .port_mdb_add callback.
> This results in a NULL pointer dereference, as shown in the log below.
>
> The other functions seem to be properly guarded. Do the same for
> .port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
...
> Fixes: e6db98db8a95 ("net: dsa: add switch mdb bitmap functions")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] mlxsw: spectrum_ptp: Keep unmatched entries in a linked list
From: David Miller @ 2019-08-12 4:36 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, richardcochran, mlxsw, idosch
In-Reply-To: <20190811074837.28216-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Sun, 11 Aug 2019 10:48:37 +0300
> From: Petr Machata <petrm@mellanox.com>
>
> To identify timestamps for matching with their packets, Spectrum-1 uses a
> five-tuple of (port, direction, domain number, message type, sequence ID).
> If there are several clients from the same domain behind a single port
> sending Delay_Req's, the only thing differentiating these packets, as far
> as Spectrum-1 is concerned, is the sequence ID. Should sequence IDs between
> individual clients be similar, conflicts may arise. That is not a problem
> to hardware, which will simply deliver timestamps on a first comes, first
> served basis.
>
> However the driver uses a simple hash table to store the unmatched pieces.
> When a new conflicting piece arrives, it pushes out the previously stored
> one, which if it is a packet, is delivered without timestamp. Later on as
> the corresponding timestamps arrive, the first one is mismatched to the
> second packet, and the second one is never matched and eventually is GCd.
>
> To correct this issue, instead of using a simple rhashtable, use rhltable
> to keep the unmatched entries.
>
> Previously, a found unmatched entry would always be removed from the hash
> table. That is not the case anymore--an incompatible entry is left in the
> hash table. Therefore removal from the hash table cannot be used to confirm
> the validity of the looked-up pointer, instead the lookup would simply need
> to be redone. Therefore move it inside the critical section. This
> simplifies a lot of the code.
>
> Fixes: 8748642751ed ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls")
> Reported-by: Alex Veber <alexve@mellanox.com>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: nps_enet: Fix function names in doc comments
From: David Miller @ 2019-08-12 4:32 UTC (permalink / raw)
To: j.neuschaefer; +Cc: netdev, gregkh, alexios.zavras, tglx, allison, linux-kernel
In-Reply-To: <20190810111159.3389-1-j.neuschaefer@gmx.net>
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Date: Sat, 10 Aug 2019 13:11:56 +0200
> Adjust the function names in two doc comments to match the corresponding
> functions.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Applied.
^ permalink raw reply
* Re: [PATCH] caif: no need to check return value of debugfs_create functions
From: David Miller @ 2019-08-12 4:31 UTC (permalink / raw)
To: gregkh; +Cc: netdev, rfontana, swinslow
In-Reply-To: <20190810104243.GA24741@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat, 10 Aug 2019 12:42:43 +0200
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Richard Fontana <rfontana@redhat.com>
> Cc: Steve Winslow <swinslow@gmail.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH] xen-netback: no need to check return value of debugfs_create functions
From: David Miller @ 2019-08-12 4:30 UTC (permalink / raw)
To: gregkh; +Cc: wei.liu, paul.durrant, xen-devel, netdev
In-Reply-To: <20190810103108.GA29487@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sat, 10 Aug 2019 12:31:08 +0200
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Wei Liu <wei.liu@kernel.org>
> Cc: Paul Durrant <paul.durrant@citrix.com>
> Cc: xen-devel@lists.xenproject.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net] rxrpc: Fix local refcounting
From: David Miller @ 2019-08-12 4:29 UTC (permalink / raw)
To: dhowells; +Cc: netdev, jaltman, linux-afs, linux-kernel
In-Reply-To: <156538726702.16201.13552536596121161945.stgit@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Fri, 09 Aug 2019 22:47:47 +0100
> Fix rxrpc_unuse_local() to handle a NULL local pointer as it can be called
> on an unbound socket on which rx->local is not yet set.
>
> The following reproduced (includes omitted):
>
> int main(void)
> {
> socket(AF_RXRPC, SOCK_DGRAM, AF_INET);
> return 0;
> }
>
> causes the following oops to occur:
>
> BUG: kernel NULL pointer dereference, address: 0000000000000010
> ...
> RIP: 0010:rxrpc_unuse_local+0x8/0x1b
> ...
> Call Trace:
> rxrpc_release+0x2b5/0x338
> __sock_release+0x37/0xa1
> sock_close+0x14/0x17
> __fput+0x115/0x1e9
> task_work_run+0x72/0x98
> do_exit+0x51b/0xa7a
> ? __context_tracking_exit+0x4e/0x10e
> do_group_exit+0xab/0xab
> __x64_sys_exit_group+0x14/0x17
> do_syscall_64+0x89/0x1d4
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Reported-by: syzbot+20dee719a2e090427b5f@syzkaller.appspotmail.com
> Fixes: 730c5fd42c1e ("rxrpc: Fix local endpoint refcounting")
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Jeffrey Altman <jaltman@auristor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/7] net: dsa: mv88e6xxx: prepare Wait Bit operation
From: David Miller @ 2019-08-12 4:27 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, f.fainelli, andrew
In-Reply-To: <20190809224759.5743-1-vivien.didelot@gmail.com>
From: Vivien Didelot <vivien.didelot@gmail.com>
Date: Fri, 9 Aug 2019 18:47:52 -0400
> The Remote Management Interface has its own implementation of a Wait
> Bit operation, which requires a bit number and a value to wait for.
>
> In order to prepare the introduction of this implementation, rework the
> code waiting for bits and masks in mv88e6xxx to match this signature.
>
> This has the benefit to unify the implementation of wait routines while
> removing obsolete wait and update functions and also reducing the code.
Series applied, thanks.
^ 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