* [net-next:master 13/221] drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
From: kbuild test robot @ 2018-09-23 21:22 UTC (permalink / raw)
To: Moritz Fischer; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 18932 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 12ba7e1045521ec9f251c93ae0a6735cc3f42337
commit: 7e8d5755be0e6c92d3b86a85e54c6a550b1910c5 [13/221] net: nixge: Add support for 64-bit platforms
config: i386-randconfig-x075-09240403 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 7e8d5755be0e6c92d3b86a85e54c6a550b1910c5
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/net//ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_release':
drivers/net//ethernet/ni/nixge.c:254:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)
^
In file included from include/linux/skbuff.h:17:0,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from drivers/net//ethernet/ni/nixge.c:7:
drivers/net//ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_init':
drivers/net//ethernet/ni/nixge.c:130:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_lo = lower_32_bits(((u64)addr)); \
^
include/linux/kernel.h:234:33: note: in definition of macro 'lower_32_bits'
#define lower_32_bits(n) ((u32)(n))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net//ethernet/ni/nixge.c:326:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:131:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_hi = upper_32_bits(((u64)addr)); \
^
include/linux/kernel.h:228:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net//ethernet/ni/nixge.c:326:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c: In function 'nixge_recv':
drivers/net//ethernet/ni/nixge.c:604:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)nixge_hw_dma_bd_get_addr(cur_p,
^
In file included from include/linux/skbuff.h:17:0,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from drivers/net//ethernet/ni/nixge.c:7:
drivers/net//ethernet/ni/nixge.c:130:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_lo = lower_32_bits(((u64)addr)); \
^
include/linux/kernel.h:234:33: note: in definition of macro 'lower_32_bits'
#define lower_32_bits(n) ((u32)(n))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:646:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(cur_p, new_skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:131:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_hi = upper_32_bits(((u64)addr)); \
^
include/linux/kernel.h:228:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:646:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(cur_p, new_skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/nixge_hw_dma_bd_set_addr +145 drivers/net//ethernet/ni/nixge.c
> 7 #include <linux/etherdevice.h>
8 #include <linux/module.h>
9 #include <linux/netdevice.h>
10 #include <linux/of_address.h>
11 #include <linux/of_mdio.h>
12 #include <linux/of_net.h>
13 #include <linux/of_platform.h>
14 #include <linux/of_irq.h>
15 #include <linux/skbuff.h>
16 #include <linux/phy.h>
17 #include <linux/mii.h>
18 #include <linux/nvmem-consumer.h>
19 #include <linux/ethtool.h>
20 #include <linux/iopoll.h>
21
22 #define TX_BD_NUM 64
23 #define RX_BD_NUM 128
24
25 /* Axi DMA Register definitions */
26 #define XAXIDMA_TX_CR_OFFSET 0x00 /* Channel control */
27 #define XAXIDMA_TX_SR_OFFSET 0x04 /* Status */
28 #define XAXIDMA_TX_CDESC_OFFSET 0x08 /* Current descriptor pointer */
29 #define XAXIDMA_TX_TDESC_OFFSET 0x10 /* Tail descriptor pointer */
30
31 #define XAXIDMA_RX_CR_OFFSET 0x30 /* Channel control */
32 #define XAXIDMA_RX_SR_OFFSET 0x34 /* Status */
33 #define XAXIDMA_RX_CDESC_OFFSET 0x38 /* Current descriptor pointer */
34 #define XAXIDMA_RX_TDESC_OFFSET 0x40 /* Tail descriptor pointer */
35
36 #define XAXIDMA_CR_RUNSTOP_MASK 0x1 /* Start/stop DMA channel */
37 #define XAXIDMA_CR_RESET_MASK 0x4 /* Reset DMA engine */
38
39 #define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
40 #define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
41 #define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
42 #define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
43
44 #define XAXIDMA_DELAY_MASK 0xFF000000 /* Delay timeout counter */
45 #define XAXIDMA_COALESCE_MASK 0x00FF0000 /* Coalesce counter */
46
47 #define XAXIDMA_DELAY_SHIFT 24
48 #define XAXIDMA_COALESCE_SHIFT 16
49
50 #define XAXIDMA_IRQ_IOC_MASK 0x00001000 /* Completion intr */
51 #define XAXIDMA_IRQ_DELAY_MASK 0x00002000 /* Delay interrupt */
52 #define XAXIDMA_IRQ_ERROR_MASK 0x00004000 /* Error interrupt */
53 #define XAXIDMA_IRQ_ALL_MASK 0x00007000 /* All interrupts */
54
55 /* Default TX/RX Threshold and waitbound values for SGDMA mode */
56 #define XAXIDMA_DFT_TX_THRESHOLD 24
57 #define XAXIDMA_DFT_TX_WAITBOUND 254
58 #define XAXIDMA_DFT_RX_THRESHOLD 24
59 #define XAXIDMA_DFT_RX_WAITBOUND 254
60
61 #define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
62 #define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
63 #define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
64 #define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
65 #define XAXIDMA_BD_STS_INT_ERR_MASK 0x10000000 /* Internal err */
66 #define XAXIDMA_BD_STS_ALL_ERR_MASK 0x70000000 /* All errors */
67 #define XAXIDMA_BD_STS_RXSOF_MASK 0x08000000 /* First rx pkt */
68 #define XAXIDMA_BD_STS_RXEOF_MASK 0x04000000 /* Last rx pkt */
69 #define XAXIDMA_BD_STS_ALL_MASK 0xFC000000 /* All status bits */
70
71 #define NIXGE_REG_CTRL_OFFSET 0x4000
72 #define NIXGE_REG_INFO 0x00
73 #define NIXGE_REG_MAC_CTL 0x04
74 #define NIXGE_REG_PHY_CTL 0x08
75 #define NIXGE_REG_LED_CTL 0x0c
76 #define NIXGE_REG_MDIO_DATA 0x10
77 #define NIXGE_REG_MDIO_ADDR 0x14
78 #define NIXGE_REG_MDIO_OP 0x18
79 #define NIXGE_REG_MDIO_CTRL 0x1c
80
81 #define NIXGE_ID_LED_CTL_EN BIT(0)
82 #define NIXGE_ID_LED_CTL_VAL BIT(1)
83
84 #define NIXGE_MDIO_CLAUSE45 BIT(12)
85 #define NIXGE_MDIO_CLAUSE22 0
86 #define NIXGE_MDIO_OP(n) (((n) & 0x3) << 10)
87 #define NIXGE_MDIO_OP_ADDRESS 0
88 #define NIXGE_MDIO_C45_WRITE BIT(0)
89 #define NIXGE_MDIO_C45_READ (BIT(1) | BIT(0))
90 #define NIXGE_MDIO_C22_WRITE BIT(0)
91 #define NIXGE_MDIO_C22_READ BIT(1)
92 #define NIXGE_MDIO_ADDR(n) (((n) & 0x1f) << 5)
93 #define NIXGE_MDIO_MMD(n) (((n) & 0x1f) << 0)
94
95 #define NIXGE_REG_MAC_LSB 0x1000
96 #define NIXGE_REG_MAC_MSB 0x1004
97
98 /* Packet size info */
99 #define NIXGE_HDR_SIZE 14 /* Size of Ethernet header */
100 #define NIXGE_TRL_SIZE 4 /* Size of Ethernet trailer (FCS) */
101 #define NIXGE_MTU 1500 /* Max MTU of an Ethernet frame */
102 #define NIXGE_JUMBO_MTU 9000 /* Max MTU of a jumbo Eth. frame */
103
104 #define NIXGE_MAX_FRAME_SIZE (NIXGE_MTU + NIXGE_HDR_SIZE + NIXGE_TRL_SIZE)
105 #define NIXGE_MAX_JUMBO_FRAME_SIZE \
106 (NIXGE_JUMBO_MTU + NIXGE_HDR_SIZE + NIXGE_TRL_SIZE)
107
108 struct nixge_hw_dma_bd {
109 u32 next_lo;
110 u32 next_hi;
111 u32 phys_lo;
112 u32 phys_hi;
113 u32 reserved3;
114 u32 reserved4;
115 u32 cntrl;
116 u32 status;
117 u32 app0;
118 u32 app1;
119 u32 app2;
120 u32 app3;
121 u32 app4;
122 u32 sw_id_offset_lo;
123 u32 sw_id_offset_hi;
124 u32 reserved6;
125 };
126
127 #ifdef CONFIG_PHYS_ADDR_T_64BIT
128 #define nixge_hw_dma_bd_set_addr(bd, field, addr) \
129 do { \
> 130 (bd)->field##_lo = lower_32_bits(((u64)addr)); \
131 (bd)->field##_hi = upper_32_bits(((u64)addr)); \
132 } while (0)
133 #else
134 #define nixge_hw_dma_bd_set_addr(bd, field, addr) \
135 ((bd)->field##_lo = lower_32_bits((addr)))
136 #endif
137
138 #define nixge_hw_dma_bd_set_phys(bd, addr) \
139 nixge_hw_dma_bd_set_addr((bd), phys, (addr))
140
141 #define nixge_hw_dma_bd_set_next(bd, addr) \
142 nixge_hw_dma_bd_set_addr((bd), next, (addr))
143
144 #define nixge_hw_dma_bd_set_offset(bd, addr) \
> 145 nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
146
147 #ifdef CONFIG_PHYS_ADDR_T_64BIT
148 #define nixge_hw_dma_bd_get_addr(bd, field) \
149 (dma_addr_t)((((u64)(bd)->field##_hi) << 32) | ((bd)->field##_lo))
150 #else
151 #define nixge_hw_dma_bd_get_addr(bd, field) \
152 (dma_addr_t)((bd)->field##_lo)
153 #endif
154
155 struct nixge_tx_skb {
156 struct sk_buff *skb;
157 dma_addr_t mapping;
158 size_t size;
159 bool mapped_as_page;
160 };
161
162 struct nixge_priv {
163 struct net_device *ndev;
164 struct napi_struct napi;
165 struct device *dev;
166
167 /* Connection to PHY device */
168 struct device_node *phy_node;
169 phy_interface_t phy_mode;
170
171 int link;
172 unsigned int speed;
173 unsigned int duplex;
174
175 /* MDIO bus data */
176 struct mii_bus *mii_bus; /* MII bus reference */
177
178 /* IO registers, dma functions and IRQs */
179 void __iomem *ctrl_regs;
180 void __iomem *dma_regs;
181
182 struct tasklet_struct dma_err_tasklet;
183
184 int tx_irq;
185 int rx_irq;
186
187 /* Buffer descriptors */
188 struct nixge_hw_dma_bd *tx_bd_v;
189 struct nixge_tx_skb *tx_skb;
190 dma_addr_t tx_bd_p;
191
192 struct nixge_hw_dma_bd *rx_bd_v;
193 dma_addr_t rx_bd_p;
194 u32 tx_bd_ci;
195 u32 tx_bd_tail;
196 u32 rx_bd_ci;
197
198 u32 coalesce_count_rx;
199 u32 coalesce_count_tx;
200 };
201
202 static void nixge_dma_write_reg(struct nixge_priv *priv, off_t offset, u32 val)
203 {
204 writel(val, priv->dma_regs + offset);
205 }
206
207 static void nixge_dma_write_desc_reg(struct nixge_priv *priv, off_t offset,
208 dma_addr_t addr)
209 {
210 writel(lower_32_bits(addr), priv->dma_regs + offset);
211 #ifdef CONFIG_PHYS_ADDR_T_64BIT
212 writel(upper_32_bits(addr), priv->dma_regs + offset + 4);
213 #endif
214 }
215
216 static u32 nixge_dma_read_reg(const struct nixge_priv *priv, off_t offset)
217 {
218 return readl(priv->dma_regs + offset);
219 }
220
221 static void nixge_ctrl_write_reg(struct nixge_priv *priv, off_t offset, u32 val)
222 {
223 writel(val, priv->ctrl_regs + offset);
224 }
225
226 static u32 nixge_ctrl_read_reg(struct nixge_priv *priv, off_t offset)
227 {
228 return readl(priv->ctrl_regs + offset);
229 }
230
231 #define nixge_ctrl_poll_timeout(priv, addr, val, cond, sleep_us, timeout_us) \
232 readl_poll_timeout((priv)->ctrl_regs + (addr), (val), (cond), \
233 (sleep_us), (timeout_us))
234
235 #define nixge_dma_poll_timeout(priv, addr, val, cond, sleep_us, timeout_us) \
236 readl_poll_timeout((priv)->dma_regs + (addr), (val), (cond), \
237 (sleep_us), (timeout_us))
238
239 static void nixge_hw_dma_bd_release(struct net_device *ndev)
240 {
241 struct nixge_priv *priv = netdev_priv(ndev);
242 dma_addr_t phys_addr;
243 struct sk_buff *skb;
244 int i;
245
246 for (i = 0; i < RX_BD_NUM; i++) {
247 phys_addr = nixge_hw_dma_bd_get_addr(&priv->rx_bd_v[i],
248 phys);
249
250 dma_unmap_single(ndev->dev.parent, phys_addr,
251 NIXGE_MAX_JUMBO_FRAME_SIZE,
252 DMA_FROM_DEVICE);
253
254 skb = (struct sk_buff *)
255 nixge_hw_dma_bd_get_addr(&priv->rx_bd_v[i],
256 sw_id_offset);
257 dev_kfree_skb(skb);
258 }
259
260 if (priv->rx_bd_v)
261 dma_free_coherent(ndev->dev.parent,
262 sizeof(*priv->rx_bd_v) * RX_BD_NUM,
263 priv->rx_bd_v,
264 priv->rx_bd_p);
265
266 if (priv->tx_skb)
267 devm_kfree(ndev->dev.parent, priv->tx_skb);
268
269 if (priv->tx_bd_v)
270 dma_free_coherent(ndev->dev.parent,
271 sizeof(*priv->tx_bd_v) * TX_BD_NUM,
272 priv->tx_bd_v,
273 priv->tx_bd_p);
274 }
275
276 static int nixge_hw_dma_bd_init(struct net_device *ndev)
277 {
278 struct nixge_priv *priv = netdev_priv(ndev);
279 struct sk_buff *skb;
280 dma_addr_t phys;
281 u32 cr;
282 int i;
283
284 /* Reset the indexes which are used for accessing the BDs */
285 priv->tx_bd_ci = 0;
286 priv->tx_bd_tail = 0;
287 priv->rx_bd_ci = 0;
288
289 /* Allocate the Tx and Rx buffer descriptors. */
290 priv->tx_bd_v = dma_zalloc_coherent(ndev->dev.parent,
291 sizeof(*priv->tx_bd_v) * TX_BD_NUM,
292 &priv->tx_bd_p, GFP_KERNEL);
293 if (!priv->tx_bd_v)
294 goto out;
295
296 priv->tx_skb = devm_kcalloc(ndev->dev.parent,
297 TX_BD_NUM, sizeof(*priv->tx_skb),
298 GFP_KERNEL);
299 if (!priv->tx_skb)
300 goto out;
301
302 priv->rx_bd_v = dma_zalloc_coherent(ndev->dev.parent,
303 sizeof(*priv->rx_bd_v) * RX_BD_NUM,
304 &priv->rx_bd_p, GFP_KERNEL);
305 if (!priv->rx_bd_v)
306 goto out;
307
308 for (i = 0; i < TX_BD_NUM; i++) {
309 nixge_hw_dma_bd_set_next(&priv->tx_bd_v[i],
310 priv->tx_bd_p +
311 sizeof(*priv->tx_bd_v) *
312 ((i + 1) % TX_BD_NUM));
313 }
314
315 for (i = 0; i < RX_BD_NUM; i++) {
316 nixge_hw_dma_bd_set_next(&priv->rx_bd_v[i],
317 priv->rx_bd_p
318 + sizeof(*priv->rx_bd_v) *
319 ((i + 1) % RX_BD_NUM));
320
321 skb = netdev_alloc_skb_ip_align(ndev,
322 NIXGE_MAX_JUMBO_FRAME_SIZE);
323 if (!skb)
324 goto out;
325
> 326 nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
327 phys = dma_map_single(ndev->dev.parent, skb->data,
328 NIXGE_MAX_JUMBO_FRAME_SIZE,
329 DMA_FROM_DEVICE);
330
331 nixge_hw_dma_bd_set_phys(&priv->rx_bd_v[i], phys);
332
333 priv->rx_bd_v[i].cntrl = NIXGE_MAX_JUMBO_FRAME_SIZE;
334 }
335
336 /* Start updating the Rx channel control register */
337 cr = nixge_dma_read_reg(priv, XAXIDMA_RX_CR_OFFSET);
338 /* Update the interrupt coalesce count */
339 cr = ((cr & ~XAXIDMA_COALESCE_MASK) |
340 ((priv->coalesce_count_rx) << XAXIDMA_COALESCE_SHIFT));
341 /* Update the delay timer count */
342 cr = ((cr & ~XAXIDMA_DELAY_MASK) |
343 (XAXIDMA_DFT_RX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
344 /* Enable coalesce, delay timer and error interrupts */
345 cr |= XAXIDMA_IRQ_ALL_MASK;
346 /* Write to the Rx channel control register */
347 nixge_dma_write_reg(priv, XAXIDMA_RX_CR_OFFSET, cr);
348
349 /* Start updating the Tx channel control register */
350 cr = nixge_dma_read_reg(priv, XAXIDMA_TX_CR_OFFSET);
351 /* Update the interrupt coalesce count */
352 cr = (((cr & ~XAXIDMA_COALESCE_MASK)) |
353 ((priv->coalesce_count_tx) << XAXIDMA_COALESCE_SHIFT));
354 /* Update the delay timer count */
355 cr = (((cr & ~XAXIDMA_DELAY_MASK)) |
356 (XAXIDMA_DFT_TX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
357 /* Enable coalesce, delay timer and error interrupts */
358 cr |= XAXIDMA_IRQ_ALL_MASK;
359 /* Write to the Tx channel control register */
360 nixge_dma_write_reg(priv, XAXIDMA_TX_CR_OFFSET, cr);
361
362 /* Populate the tail pointer and bring the Rx Axi DMA engine out of
363 * halted state. This will make the Rx side ready for reception.
364 */
365 nixge_dma_write_desc_reg(priv, XAXIDMA_RX_CDESC_OFFSET, priv->rx_bd_p);
366 cr = nixge_dma_read_reg(priv, XAXIDMA_RX_CR_OFFSET);
367 nixge_dma_write_reg(priv, XAXIDMA_RX_CR_OFFSET,
368 cr | XAXIDMA_CR_RUNSTOP_MASK);
369 nixge_dma_write_desc_reg(priv, XAXIDMA_RX_TDESC_OFFSET, priv->rx_bd_p +
370 (sizeof(*priv->rx_bd_v) * (RX_BD_NUM - 1)));
371
372 /* Write to the RS (Run-stop) bit in the Tx channel control register.
373 * Tx channel is now ready to run. But only after we write to the
374 * tail pointer register that the Tx channel will start transmitting.
375 */
376 nixge_dma_write_desc_reg(priv, XAXIDMA_TX_CDESC_OFFSET, priv->tx_bd_p);
377 cr = nixge_dma_read_reg(priv, XAXIDMA_TX_CR_OFFSET);
378 nixge_dma_write_reg(priv, XAXIDMA_TX_CR_OFFSET,
379 cr | XAXIDMA_CR_RUNSTOP_MASK);
380
381 return 0;
382 out:
383 nixge_hw_dma_bd_release(ndev);
384 return -ENOMEM;
385 }
386
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32795 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
From: Ido Schimmel @ 2018-09-23 21:51 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <20180923205809.GA30338@lunn.ch>
On Sun, Sep 23, 2018 at 10:58:09PM +0200, Andrew Lunn wrote:
> > Therefore tweak the check to accept any FW version that is:
> >
> > - on the same branch as the preferred version, and
> > - the same as or newer than the preferred version.
>
> Hi Ido
>
> Do you print this information out? If the check fails, it would be
> useful to know what the minimal version is.
Hi Andrew,
Yes, we do print it. It is the version the driver will try to load
during initialization in case current version is incompatible:
dev_info(mlxsw_sp->bus_info->dev, "Flashing firmware using file %s\n",
fw_filename);
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
From: Andrew Lunn @ 2018-09-23 22:04 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <20180923215100.GA24149@splinter>
On Mon, Sep 24, 2018 at 12:51:00AM +0300, Ido Schimmel wrote:
> On Sun, Sep 23, 2018 at 10:58:09PM +0200, Andrew Lunn wrote:
> > > Therefore tweak the check to accept any FW version that is:
> > >
> > > - on the same branch as the preferred version, and
> > > - the same as or newer than the preferred version.
> >
> > Hi Ido
> >
> > Do you print this information out? If the check fails, it would be
> > useful to know what the minimal version is.
>
> Hi Andrew,
>
> Yes, we do print it. It is the version the driver will try to load
> during initialization in case current version is incompatible:
>
> dev_info(mlxsw_sp->bus_info->dev, "Flashing firmware using file %s\n",
> fw_filename);
Ah. O.K. Thanks.
But doesn't that mean you reflash the device with the minimum version,
when in fact there could be a much newer version in /lib/firmware?
Andrew
^ permalink raw reply
* Re: KMSAN: uninit-value in memcmp (2)
From: Vladis Dronov @ 2018-09-23 22:09 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, syzkaller-bugs, David Miller, Eric Dumazet, LKML, netdev,
sunlianwen
In-Reply-To: <CACT4Y+Z1G_QMG_PQu_ZwHsyhwyh_DBOG4mX9n=va08w3Z7j02Q@mail.gmail.com>
Hello, Dmirty,
Thank you for the reply. Can we please, discuss this further?
> You can see on dashboard that the last crash
> for the second version (2) happened just few days ago. So this is a
> different bug.
Well... yes and no. When I was looking at this bug (bug?id=088efeac32fd) I was looking
at the report at "2018/05/09 18:55" (https://syzkaller.appspot.com/text?tag=CrashReport&x=141b707b800000),
since it was the only report with a reproducer. This was my error.
The error and the call trace in this report are:
>>>
BUG: KMSAN: uninit-value in memcmp+0x119/0x180 lib/string.c:861
CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 4.17.0-rc3+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
memcmp+0x119/0x180 lib/string.c:861
__hw_addr_add_ex net/core/dev_addr_lists.c:61 [inline]
__dev_mc_add+0x1fc/0x900 net/core/dev_addr_lists.c:670
dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
igmp6_group_added+0x2db/0xa00 net/ipv6/mcast.c:662
ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
addrconf_join_solict net/ipv6/addrconf.c:2103 [inline]
addrconf_dad_begin net/ipv6/addrconf.c:3853 [inline]
addrconf_dad_work+0x462/0x2a20 net/ipv6/addrconf.c:3979
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
kthread+0x539/0x720 kernel/kthread.c:239
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
Local variable description: ----buf@igmp6_group_added
Variable was created at:
igmp6_group_added+0x4a/0xa00 net/ipv6/mcast.c:650
ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
<<<
It is the same like in bug?id=3887c0d99aecb27d085180c5222d245d08a30806
which, after some more test, made me believe these bugs are duplicate
and are fixed by the same commit.
But let's look at another report at "2018/09/12 21:00"
(https://syzkaller.appspot.com/text?tag=CrashReport&x=14f99b71400000)
at the bug (bug?id=088efeac32fd), the one you've mentioned as
"the last crash for the second version (2) happened just few days ago".
Its error and the call trace are completely different:
>>>
BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
CPU: 0 PID: 6107 Comm: syz-executor4 Not tainted 4.19.0-rc3+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x14b/0x190 lib/dump_stack.c:113
kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
__msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
memcmp+0x11d/0x180 lib/string.c:863
dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
...
Uninit was created at:
...
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2718 [inline]
__kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:996 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
<<<
This is a different bug. How come these 2 different reports for 2 different
bugs have ended in the same syzkaller report (bug?id=088efeac32fd) ?
One bug is fixed by the "net: fix uninit-value in __hw_addr_add_ex()" commit,
the second one is not, but they are still in the same syzkaller report.
This was the reason of my confusion. I'm not sure how to fix this. If it is possible,
probably we need to cancel/revoke "#syz fix: net: fix uninit-value in __hw_addr_add_ex()"
for this syzkaller report (bug?id=088efeac32fd). And then "split" it into 2 or
more different reports, but I'm not sure if this is possible.
Probably, syzkaller needs to look deeper into the KMSAN reports to differentiate
KMSAN errors happening because of different reasons.
Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer
----- Original Message -----
> From: "Dmitry Vyukov" <dvyukov@google.com>
> To: "Vladis Dronov" <vdronov@redhat.com>
> Cc: "syzbot" <syzbot+d3402c47f680ff24b29c@syzkaller.appspotmail.com>, "syzkaller-bugs"
> <syzkaller-bugs@googlegroups.com>, "David Miller" <davem@davemloft.net>, "Eric Dumazet" <edumazet@google.com>,
> "LKML" <linux-kernel@vger.kernel.org>, "netdev" <netdev@vger.kernel.org>, "sunlianwen" <sunlw.fnst@cn.fujitsu.com>
> Sent: Sunday, September 23, 2018 6:22:36 PM
> Subject: Re: KMSAN: uninit-value in memcmp (2)
>
> On Sun, Sep 23, 2018 at 6:02 PM, Vladis Dronov <vdronov@redhat.com> wrote:
> > #syz fix: net: fix uninit-value in __hw_addr_add_ex()
>
> Hi Vladis,
>
> This can be fixed with "net: fix uninit-value in __hw_addr_add_ex()".
> That commit landed in April, syzbot waited till the commit reached all
> tested trees, and then closed the bug.
> But the similar bug continued to happen, so syzbot created second
> version of this bug (2). You can see on dashboard that the last crash
> for the second version (2) happened just few days ago. So this is a
> different bug.
>
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
From: Ido Schimmel @ 2018-09-23 22:28 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Ido Schimmel, netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <20180923220417.GA31923@lunn.ch>
On Mon, Sep 24, 2018 at 12:04:17AM +0200, Andrew Lunn wrote:
> On Mon, Sep 24, 2018 at 12:51:00AM +0300, Ido Schimmel wrote:
> > On Sun, Sep 23, 2018 at 10:58:09PM +0200, Andrew Lunn wrote:
> > > > Therefore tweak the check to accept any FW version that is:
> > > >
> > > > - on the same branch as the preferred version, and
> > > > - the same as or newer than the preferred version.
> > >
> > > Hi Ido
> > >
> > > Do you print this information out? If the check fails, it would be
> > > useful to know what the minimal version is.
> >
> > Hi Andrew,
> >
> > Yes, we do print it. It is the version the driver will try to load
> > during initialization in case current version is incompatible:
> >
> > dev_info(mlxsw_sp->bus_info->dev, "Flashing firmware using file %s\n",
> > fw_filename);
>
> Ah. O.K. Thanks.
>
> But doesn't that mean you reflash the device with the minimum version,
> when in fact there could be a much newer version in /lib/firmware?
No, because we always enforce the latest version we post to
linux-firmware. We try to keep firmware updates at a minimum, so if we
decided to post a new version it's either because the driver now
requires a feature from this version (which makes older versions
incompatible) or because a critical bug was fixed in that version.
^ permalink raw reply
* Re: KMSAN: uninit-value in memcmp (2)
From: Alexander Potapenko @ 2018-09-24 6:53 UTC (permalink / raw)
To: Vladis Dronov
Cc: Dmitriy Vyukov, syzbot+d3402c47f680ff24b29c, syzkaller-bugs,
David Miller, Eric Dumazet, LKML, Networking, sunlw.fnst
In-Reply-To: <1040580049.15456466.1537740558279.JavaMail.zimbra@redhat.com>
On Mon, Sep 24, 2018 at 12:09 AM Vladis Dronov <vdronov@redhat.com> wrote:
>
> Hello, Dmirty,
>
> Thank you for the reply. Can we please, discuss this further?
Hi Vladis,
> > You can see on dashboard that the last crash
> > for the second version (2) happened just few days ago. So this is a
> > different bug.
FWIW I've just double-checked that the reproducer provided by
syzkaller in the original message still triggers the report from the
original message in the latest KMSAN tree (which already contains the
__hw_addr_add_ex() fix from April).
> Well... yes and no. When I was looking at this bug (bug?id=088efeac32fd) I was looking
> at the report at "2018/05/09 18:55" (https://syzkaller.appspot.com/text?tag=CrashReport&x=141b707b800000),
> since it was the only report with a reproducer. This was my error.
>
> The error and the call trace in this report are:
>
> >>>
> BUG: KMSAN: uninit-value in memcmp+0x119/0x180 lib/string.c:861
> CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 4.17.0-rc3+ #88
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Workqueue: ipv6_addrconf addrconf_dad_work
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x185/0x1d0 lib/dump_stack.c:113
> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
> memcmp+0x119/0x180 lib/string.c:861
> __hw_addr_add_ex net/core/dev_addr_lists.c:61 [inline]
> __dev_mc_add+0x1fc/0x900 net/core/dev_addr_lists.c:670
> dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
> igmp6_group_added+0x2db/0xa00 net/ipv6/mcast.c:662
> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
> addrconf_join_solict net/ipv6/addrconf.c:2103 [inline]
> addrconf_dad_begin net/ipv6/addrconf.c:3853 [inline]
> addrconf_dad_work+0x462/0x2a20 net/ipv6/addrconf.c:3979
> process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
> worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
> kthread+0x539/0x720 kernel/kthread.c:239
> ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
>
> Local variable description: ----buf@igmp6_group_added
> Variable was created at:
> igmp6_group_added+0x4a/0xa00 net/ipv6/mcast.c:650
> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
> <<<
>
> It is the same like in bug?id=3887c0d99aecb27d085180c5222d245d08a30806
> which, after some more test, made me believe these bugs are duplicate
> and are fixed by the same commit.
>
> But let's look at another report at "2018/09/12 21:00"
> (https://syzkaller.appspot.com/text?tag=CrashReport&x=14f99b71400000)
> at the bug (bug?id=088efeac32fd), the one you've mentioned as
> "the last crash for the second version (2) happened just few days ago".
>
> Its error and the call trace are completely different:
>
> >>>
> BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
> CPU: 0 PID: 6107 Comm: syz-executor4 Not tainted 4.19.0-rc3+ #45
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x14b/0x190 lib/dump_stack.c:113
> kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
> __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
> memcmp+0x11d/0x180 lib/string.c:863
> dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
> ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
> rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
> rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
> netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
> rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
> netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
> netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
> netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg net/socket.c:631 [inline]
> ...
> Uninit was created at:
> ...
> slab_post_alloc_hook mm/slab.h:446 [inline]
> slab_alloc_node mm/slub.c:2718 [inline]
> __kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
> __kmalloc_reserve net/core/skbuff.c:138 [inline]
> __alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
> alloc_skb include/linux/skbuff.h:996 [inline]
> netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
> netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg net/socket.c:631 [inline]
> ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
> <<<
>
> This is a different bug. How come these 2 different reports for 2 different
> bugs have ended in the same syzkaller report (bug?id=088efeac32fd) ?
I suspect this is because syzbot used the top stack frame as the
report signature.
There's a mechanism to ignore frames like memcmp() in the reports, not
sure why didn't it work in this case (maybe it just wasn't in place at
the time the report happened).
> One bug is fixed by the "net: fix uninit-value in __hw_addr_add_ex()" commit,
> the second one is not, but they are still in the same syzkaller report.
>
> This was the reason of my confusion. I'm not sure how to fix this. If it is possible,
> probably we need to cancel/revoke "#syz fix: net: fix uninit-value in __hw_addr_add_ex()"
> for this syzkaller report (bug?id=088efeac32fd). And then "split" it into 2 or
> more different reports, but I'm not sure if this is possible.
>
> Probably, syzkaller needs to look deeper into the KMSAN reports to differentiate
> KMSAN errors happening because of different reasons.
>
> Best regards,
> Vladis Dronov | Red Hat, Inc. | Product Security Engineer
>
> ----- Original Message -----
> > From: "Dmitry Vyukov" <dvyukov@google.com>
> > To: "Vladis Dronov" <vdronov@redhat.com>
> > Cc: "syzbot" <syzbot+d3402c47f680ff24b29c@syzkaller.appspotmail.com>, "syzkaller-bugs"
> > <syzkaller-bugs@googlegroups.com>, "David Miller" <davem@davemloft.net>, "Eric Dumazet" <edumazet@google.com>,
> > "LKML" <linux-kernel@vger.kernel.org>, "netdev" <netdev@vger.kernel.org>, "sunlianwen" <sunlw.fnst@cn.fujitsu.com>
> > Sent: Sunday, September 23, 2018 6:22:36 PM
> > Subject: Re: KMSAN: uninit-value in memcmp (2)
> >
> > On Sun, Sep 23, 2018 at 6:02 PM, Vladis Dronov <vdronov@redhat.com> wrote:
> > > #syz fix: net: fix uninit-value in __hw_addr_add_ex()
> >
> > Hi Vladis,
> >
> > This can be fixed with "net: fix uninit-value in __hw_addr_add_ex()".
> > That commit landed in April, syzbot waited till the commit reached all
> > tested trees, and then closed the bug.
> > But the similar bug continued to happen, so syzbot created second
> > version of this bug (2). You can see on dashboard that the last crash
> > for the second version (2) happened just few days ago. So this is a
> > different bug.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/1040580049.15456466.1537740558279.JavaMail.zimbra%40redhat.com.
> For more options, visit https://groups.google.com/d/optout.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* RE: [PATCH] bonding: avoid repeated display of same link status change
From: Manish Kumar Singh @ 2018-09-24 7:05 UTC (permalink / raw)
To: Eric Dumazet, netdev
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
linux-kernel
In-Reply-To: <05f57c08-3ebb-7ee5-7ab2-519cb5a70bd8@gmail.com>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: 18 सितम्बर 2018 19:30
> To: Manish Kumar Singh; Eric Dumazet; netdev@vger.kernel.org
> Cc: Jay Vosburgh; Veaceslav Falico; Andy Gospodarek; David S. Miller; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] bonding: avoid repeated display of same link status
> change
>
>
>
> On 09/17/2018 10:05 PM, Manish Kumar Singh wrote:
> >
> >
> >> -----Original Message-----
> >> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> >> Sent: 17 सितम्बर 2018 20:08
> >> To: Manish Kumar Singh; netdev@vger.kernel.org
> >> Cc: Jay Vosburgh; Veaceslav Falico; Andy Gospodarek; David S. Miller;
> linux-
> >> kernel@vger.kernel.org
> >> Subject: Re: [PATCH] bonding: avoid repeated display of same link status
> >> change
> >>
> >>
> >>
> >> On 09/17/2018 12:20 AM, mk.singh@oracle.com wrote:
> >>> From: Manish Kumar Singh <mk.singh@oracle.com>
> >>>
> >>> When link status change needs to be committed and rtnl lock couldn't be
> >>> taken, avoid redisplay of same link status change message.
> >>>
> >>> Signed-off-by: Manish Kumar Singh <mk.singh@oracle.com>
> >>> ---
> >>> drivers/net/bonding/bond_main.c | 6 ++++--
> >>> include/net/bonding.h | 1 +
> >>> 2 files changed, 5 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/net/bonding/bond_main.c
> >> b/drivers/net/bonding/bond_main.c
> >>> index 217b790d22ed..fb4e3aff1677 100644
> >>> --- a/drivers/net/bonding/bond_main.c
> >>> +++ b/drivers/net/bonding/bond_main.c
> >>> @@ -2087,7 +2087,7 @@ static int bond_miimon_inspect(struct bonding
> >> *bond)
> >>> bond_propose_link_state(slave, BOND_LINK_FAIL);
> >>> commit++;
> >>> slave->delay = bond->params.downdelay;
> >>> - if (slave->delay) {
> >>> + if (slave->delay && !bond->rtnl_needed) {
> >>> netdev_info(bond->dev, "link status down
> for
> >> %sinterface %s, disabling it in %d ms\n",
> >>> (BOND_MODE(bond) ==
> >>> BOND_MODE_ACTIVEBACKUP) ?
> >>> @@ -2127,7 +2127,7 @@ static int bond_miimon_inspect(struct bonding
> >> *bond)
> >>> commit++;
> >>> slave->delay = bond->params.updelay;
> >>>
> >>> - if (slave->delay) {
> >>> + if (slave->delay && !bond->rtnl_needed) {
> >>> netdev_info(bond->dev, "link status up for
> >> interface %s, enabling it in %d ms\n",
> >>> slave->dev->name,
> >>> ignore_updelay ? 0 :
> >>> @@ -2301,9 +2301,11 @@ static void bond_mii_monitor(struct
> >> work_struct *work)
> >>> if (!rtnl_trylock()) {
> >>> delay = 1;
> >>> should_notify_peers = false;
> >>> + bond->rtnl_needed = true;
> >>
> >> How can you set a shared variable with no synchronization ?
> > Thanks Eric for reviewing the patch. rtnl_needed is not a shared variable, it
> is part of bonding structure, that is one per bonding driver instance. There
> can't be two parallel instances of bond_miimon_inspect for a single bonding
> driver instance at any given point of time. and only bond_miimon_inspect
> updates it. That’s why I think there is no need of any synchronization here.
> >
> >
>
> If rtnl_trylock() can not grab RTNL,
> there is no way the current thread can set the variable without a race, if the
> word including rtnl_needed is shared by other fields in the structure.
>
> Your patch adds a subtle possibility of future bugs, even if it runs fine today.
>
> Do not pave the way for future bugs, make your code robust, please.
Thankyou Eric, we are making the changes and will repost the patch after testing it.
-Manish
>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] gpiolib: Fix missing updates of bitmap index
From: Linus Walleij @ 2018-09-24 8:11 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg KH, kishon,
Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven, Sebastien Bourdelin
In-Reply-To: <20180923235336.22148-2-jmkrzyszt@gmail.com>
On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik <jmkrzyszt@gmail.com> wrote:
> In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast
> processing path in get/set array"), bitmap index is not updated with
> next found zero bit position as it should while skipping over pins
> already processed via fast bitmap path, possibly resulting in an
> infinite loop. Fix it.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Patch applied!
Thanks for working on getting this into shape!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net-next 0/2] net: mvpp2: Add txq to CPU mapping
From: Maxime Chevallier @ 2018-09-24 9:11 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
Hi everyone,
This short series adds XPS support to the mvpp2 driver, by mapping
txqs and CPUs. This comes with a patch using round-robin scheduling
for the HW to pick the next txq to transmit from, instead of the default
fixed-priority scheduling.
Maxime Chevallier (2):
net: mvpp2: support XPS by mapping TX queues to CPUs
net: mvpp2: use round-robin scheduling for TX queues on the same CPU
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletion(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 1/2] net: mvpp2: support XPS by mapping TX queues to CPUs
From: Maxime Chevallier @ 2018-09-24 9:11 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
In-Reply-To: <20180924091106.15094-1-maxime.chevallier@bootlin.com>
Since the PPv2 controller has multiple TX queues, we can spread traffic
by assining TX queues to CPUs, allowing to use XPS to balance egress
traffic between CPUs.
Suggested-by : Yan Markman <ymarkman@marvell.com>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d30ccc515bb7..bdacb9577216 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -2423,13 +2423,17 @@ static int mvpp2_setup_rxqs(struct mvpp2_port *port)
static int mvpp2_setup_txqs(struct mvpp2_port *port)
{
struct mvpp2_tx_queue *txq;
- int queue, err;
+ int queue, err, cpu;
for (queue = 0; queue < port->ntxqs; queue++) {
txq = port->txqs[queue];
err = mvpp2_txq_init(port, txq);
if (err)
goto err_cleanup;
+
+ /* Assign this queue to a CPU */
+ cpu = queue % num_present_cpus();
+ netif_set_xps_queue(port->dev, cpumask_of(cpu), queue);
}
if (port->has_tx_irqs) {
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 2/2] net: mvpp2: use round-robin scheduling for TX queues on the same CPU
From: Maxime Chevallier @ 2018-09-24 9:11 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, miquel.raynal, nadavh, stefanc,
ymarkman, mw
In-Reply-To: <20180924091106.15094-1-maxime.chevallier@bootlin.com>
This commit allows each TXQ to be picked in a round-robin fashion by
the PPv2 transmit scheduling mechanism. This is opposed to the default
behaviour that prioritizes the highest numbered queues.
Suggested-by: Yan Markman <ymarkman@marvell.com>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 1 +
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index f5dceef60b0e..176c6b56fdcc 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -331,6 +331,7 @@
#define MVPP2_TXP_SCHED_ENQ_MASK 0xff
#define MVPP2_TXP_SCHED_DISQ_OFFSET 8
#define MVPP2_TXP_SCHED_CMD_1_REG 0x8010
+#define MVPP2_TXP_SCHED_FIXED_PRIO_REG 0x8014
#define MVPP2_TXP_SCHED_PERIOD_REG 0x8018
#define MVPP2_TXP_SCHED_MTU_REG 0x801c
#define MVPP2_TXP_MTU_MAX 0x7FFFF
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index bdacb9577216..c2ed71788e4f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1448,6 +1448,9 @@ static void mvpp2_defaults_set(struct mvpp2_port *port)
tx_port_num);
mvpp2_write(port->priv, MVPP2_TXP_SCHED_CMD_1_REG, 0);
+ /* Set TXQ scheduling to Round-Robin */
+ mvpp2_write(port->priv, MVPP2_TXP_SCHED_FIXED_PRIO_REG, 0);
+
/* Close bandwidth for all queues */
for (queue = 0; queue < MVPP2_MAX_TXQ; queue++) {
ptxq = mvpp2_txq_phys(port->id, queue);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: David Miller @ 2018-09-24 5:04 UTC (permalink / raw)
To: edumazet
Cc: netdev, michael.chan, ariel.elior, eric.dumazet, tariqt, saeedm,
jeffrey.t.kirsher, jakub.kicinski, songliubraving, j.vosburgh,
vfalico, andy
In-Reply-To: <20180921222752.101307-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 21 Sep 2018 15:27:37 -0700
> As diagnosed by Song Liu, ndo_poll_controller() can
> be very dangerous on loaded hosts, since the cpu
> calling ndo_poll_controller() might steal all NAPI
> contexts (for all RX/TX queues of the NIC).
>
> This capture, showing one ksoftirqd eating all cycles
> can last for unlimited amount of time, since one
> cpu is generally not able to drain all the queues under load.
>
> It seems that all networking drivers that do use NAPI
> for their TX completions, should not provide a ndo_poll_controller() :
>
> Most NAPI drivers have netpoll support already handled
> in core networking stack, since netpoll_poll_dev()
> uses poll_napi(dev) to iterate through registered
> NAPI contexts for a device.
>
> This patch series take care of the first round, we will
> handle other drivers in future rounds.
Series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path
From: Janusz Krzysztofik @ 2018-09-24 11:08 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Andrew Lunn, Ulf Hansson, linux-doc, Tony Lindgren, Linus Walleij,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, devel, Florian Fainelli, Jonathan Corbet,
Krzysztof Kozlowski, Kishon Vijay Abraham I, linux-iio,
Peter Korsgaard, Geert Uytterhoeven, linux-serial, Jiri Slaby,
Michael Hennerich, Uwe Kleine-König, linux-gpio,
Russell King
In-Reply-To: <20180924094339eucas1p282f2f7cb627c183fe87da044edb90fa5~XTMgQ4GFs1339913399eucas1p2N@eucas1p2.samsung.com>
Hi Marek,
2018-09-24 11:43 GMT+02:00, Marek Szyprowski <m.szyprowski@samsung.com>:
> Hi Janusz,
>
> On 2018-09-24 01:53, Janusz Krzysztofik wrote:
>> While investigating possible reasons of GPIO fast bitmap processing
>> related boot hang on Samsung Snow Chromebook, reported by Marek
>> Szyprowski (thanks!), I've discovered one coding bug, addressed by
>> PATCH 1/2 of this series, and one potential regression introduced at
>> design level of the solution, hopefully fixed by PATCH 2/2. See
>> commit messages for details.
>>
>> Janusz Krzysztofik (2):
>> gpiolib: Fix missing updates of bitmap index
>> gpiolib: Fix array members of same chip processed separately
>>
>> The fixes should resolve the boot hang observed by Marek, however the
>> second change excludes that particular case from fast bitmap processing
>> and restores the old behaviour.
>
> I confirm, that the above 2 patches fixes boot issue on Samsung Snow
> Chromebook with next-20180920.
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>> Hence, it is possible still another
>> issue which have had an influence on that boot hang exists in the code.
>> In order to fully verify the fix, it would have to be tested on a
>> platform where an array of GPIO descriptors is used which starts from
>> at least two consecutive pins of one GPIO chip in hardware order,
>> starting ftom 0, followed by one or more pins belonging to other
>> chip(s).
>>
>> In order to verify if separate calls to .set() chip callback for each
>> pin instead of one call to .set_multiple() is actually the reason of
>> boot hang on Samsung Snow Chromebook, the affected driver -
>> drivers/mmc/core/pwrseq_simple.c - would have to be temporarily
>> modified for testing purposes so it calls gpiod_set_value() for each
>> pin instead of gpiod_set_array_value() for all of them. If that would
>> also result in boot hang, we could be sure the issue was really the
>> one addressed by the second fix. Marek, could you please try to
>> perform such test?
>
> Yes, I've just tested next-20180920 only with the first patch from this
> patchset and the mentioned change to drivers/mmc/core/pwrseq_simple.c.
> It boots fine, so indeed the issue is in handling of arrays of gpios.
>
> Just to be sure I did it right, this is my change to the mentioned file:
Yeah, that's what I had on mind. However, I'd be more lucky if it didn't work
for you. Setting the pins sequentially, not simultaneously as before, was
exactly what I hoped was the reason of the hang.
> diff --git a/drivers/mmc/core/pwrseq_simple.c
> b/drivers/mmc/core/pwrseq_simple.c
> index 7f882a2bb872..9397dc1f2e38 100644
> --- a/drivers/mmc/core/pwrseq_simple.c
> +++ b/drivers/mmc/core/pwrseq_simple.c
> @@ -38,16 +38,11 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
> mmc_pwrseq_simple *pwrseq,
> int value)
> {
> struct gpio_descs *reset_gpios = pwrseq->reset_gpios;
> + int i;
>
> - if (!IS_ERR(reset_gpios)) {
> - DECLARE_BITMAP(values, BITS_PER_TYPE(value));
> - int nvalues = reset_gpios->ndescs;
> -
> - values[0] = value;
> -
> - gpiod_set_array_value_cansleep(nvalues, reset_gpios->desc,
> - reset_gpios->info, values);
> - }
> + if (!IS_ERR(reset_gpios))
> + for (i = 0; i < reset_gpios->ndescs; i++)
The only difference from the behaviour when the hang was occurring is now
the order the pins are manipulated. Maybe that matters?
Could you please retry the same with the order of pins reversed, either in
the .dts file or here inside this for loop?
Thanks,
Janusz
> + gpiod_set_value_cansleep(reset_gpios->desc[i], value);
> }
>
> static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
>
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
^ permalink raw reply
* [PATCH v2 net-next 5/9] bnxt_en: return proper error when FW returns HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
Return proper error code when Firmware returns
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED for HWRM_NVM_GET/SET_VARIABLE
commands.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 58e3061..1b25e3a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -77,8 +77,12 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
memcpy(buf, data_addr, bytesize);
dma_free_coherent(&bp->pdev->dev, bytesize, data_addr, data_dma_addr);
- if (rc)
+ if (rc == HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED) {
+ netdev_err(bp->dev, "PF does not have admin privileges to modify NVM config\n");
+ return -EACCES;
+ } else if (rc) {
return -EIO;
+ }
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 4/9] bnxt_en: Use ignore_ari devlink parameter
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds support for ignore_ari generic permanent mode
devlink parameter. This parameter is disabled by default. It can be
enabled using devlink param commands.
ignore_ari - If enabled, device ignores ARI(Alternate Routing ID)
capability, even when platforms has the support and creates same number
of partitions when platform does not support ARI capability.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 6 ++++++
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index f3b9fbc..58e3061 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -24,6 +24,8 @@
static const struct bnxt_dl_nvm_param nvm_params[] = {
{DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
BNXT_NVM_SHARED_CFG, 1},
+ {DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
+ BNXT_NVM_SHARED_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -105,6 +107,10 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
NULL),
+ DEVLINK_PARAM_GENERIC(IGNORE_ARI,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ NULL),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index 2f68dc0..da146492 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -33,6 +33,8 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
}
}
+#define NVM_OFF_IGNORE_ARI 164
+#define NVM_OFF_HW_TC_OFFLOAD 170
#define NVM_OFF_ENABLE_SRIOV 401
enum bnxt_nvm_dir_type {
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 1/9] devlink: Add generic parameter ignore_ari
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
ignore_ari - Device ignores ARI(Alternate Routing ID) capability,
even when platforms has the support and creates same number of
partitions when platform does not support ARI capability.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 4 ++++
net/core/devlink.c | 5 +++++
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index b9b89d6..90d8343 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -362,6 +362,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_MAX_MACS,
DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV,
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
+ DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -380,6 +381,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_NAME "region_snapshot_enable"
#define DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_TYPE DEVLINK_PARAM_TYPE_BOOL
+#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME "ignore_ari"
+#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE DEVLINK_PARAM_TYPE_BOOL
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 65fc366..6b08ad6 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2676,6 +2676,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_NAME,
.type = DEVLINK_PARAM_GENERIC_REGION_SNAPSHOT_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
+ .name = DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME,
+ .type = DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 0/9] bnxt_en: devlink param updates
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
This patchset adds support for 3 generic and 1 driver-specific devlink
parameters. Add documentation for these configuration parameters.
Also, this patchset adds support to return proper error code if
HWRM_NVM_GET/SET_VARIABLE commands return error code
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED.
v1->v2:
-Remove hw_tc_offload parameter.
-Update all patches with Cc of MAINTAINERS.
-Add more description in commit message for device specific parameter.
-Add a new Documentation/networking/devlink-params.txt with some
generic devlink parameters information.
-Add a new Documentation/networking/devlink-params-bnxt_en.txt with devlink
parameters information that are supported by bnxt_en driver.
Vasundhara Volam (9):
devlink: Add generic parameter ignore_ari
devlink: Add generic parameter msix_vec_per_pf_max
devlink: Add generic parameter msix_vec_per_pf_min
bnxt_en: Use ignore_ari devlink parameter
bnxt_en: return proper error when FW returns
HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED
bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink
params.
bnxt_en: Add a driver specific gre_ver_check devlink parameter.
devlink: Add Documentation/networking/devlink-params.txt
devlink: Add Documentation/networking/devlink-params-bnxt.txt
Documentation/networking/devlink-params-bnxt.txt | 35 +++++++++
Documentation/networking/devlink-params.txt | 42 +++++++++++
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 86 +++++++++++++++++++++--
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 8 +++
include/net/devlink.h | 12 ++++
net/core/devlink.c | 15 ++++
6 files changed, 194 insertions(+), 4 deletions(-)
create mode 100644 Documentation/networking/devlink-params-bnxt.txt
create mode 100644 Documentation/networking/devlink-params.txt
--
1.8.3.1
^ permalink raw reply
* [PATCH v2 net-next 7/9] bnxt_en: Add a driver specific gre_ver_check devlink parameter.
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds following driver-specific permanent mode boolean
parameter.
gre_ver_check - Generic Routing Encapsulation(GRE) version check
will be enabled in the device. If disabled, device skips version
checking for GRE packets.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 24 ++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 7dc754b..fdeb4e5 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -21,6 +21,11 @@
#endif /* CONFIG_BNXT_SRIOV */
};
+enum bnxt_dl_param_id {
+ BNXT_DEVLINK_PARAM_ID_BASE = DEVLINK_PARAM_GENERIC_ID_MAX,
+ BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK,
+};
+
static const struct bnxt_dl_nvm_param nvm_params[] = {
{DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
BNXT_NVM_SHARED_CFG, 1},
@@ -30,6 +35,8 @@
NVM_OFF_MSIX_VEC_PER_PF_MAX, BNXT_NVM_SHARED_CFG, 10},
{DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
+ {BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
+ BNXT_NVM_SHARED_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -109,9 +116,15 @@ static int bnxt_dl_nvm_param_get(struct devlink *dl, u32 id,
{
struct hwrm_nvm_get_variable_input req = {0};
struct bnxt *bp = bnxt_get_bp_from_dl(dl);
+ int rc;
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_GET_VARIABLE, -1, -1);
- return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
+ rc = bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
+ if (!rc)
+ if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
+ ctx->val.vbool = !ctx->val.vbool;
+
+ return rc;
}
static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
@@ -121,6 +134,10 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
struct bnxt *bp = bnxt_get_bp_from_dl(dl);
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_SET_VARIABLE, -1, -1);
+
+ if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
+ ctx->val.vbool = !ctx->val.vbool;
+
return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
}
@@ -161,6 +178,11 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
bnxt_dl_msix_validate),
+ DEVLINK_PARAM_DRIVER(BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK,
+ "gre_ver_check", DEVLINK_PARAM_TYPE_BOOL,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ NULL),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index 0e67c05..e36e41a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -37,6 +37,7 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
#define NVM_OFF_MSIX_VEC_PER_PF_MIN 114
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_HW_TC_OFFLOAD 170
+#define NVM_OFF_DIS_GRE_VER_CHECK 171
#define NVM_OFF_ENABLE_SRIOV 401
#define BNXT_MSIX_VEC_MAX 1280
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 3/9] devlink: Add generic parameter msix_vec_per_pf_min
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
msix_vec_per_pf_min - This param sets the number of minimal MSIX
vectors required for the device initialization. This value is set
in the device which limits MSIX vectors per PF.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 4 ++++
net/core/devlink.c | 5 +++++
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 59be17b..361f525 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -364,6 +364,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -388,6 +389,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME "msix_vec_per_pf_max"
#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE DEVLINK_PARAM_TYPE_U32
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_NAME "msix_vec_per_pf_min"
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_TYPE DEVLINK_PARAM_TYPE_U32
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 7e0ac2e..8faf889 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2686,6 +2686,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME,
.type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
+ .name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_NAME,
+ .type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MIN_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 8/9] devlink: Add Documentation/networking/devlink-params.txt
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds a new file to add information about some of the
generic configuration parameters set via devlink.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
Documentation/networking/devlink-params.txt | 42 +++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/networking/devlink-params.txt
diff --git a/Documentation/networking/devlink-params.txt b/Documentation/networking/devlink-params.txt
new file mode 100644
index 0000000..ae444ff
--- /dev/null
+++ b/Documentation/networking/devlink-params.txt
@@ -0,0 +1,42 @@
+Devlink configuration parameters
+================================
+Following is the list of configuration parameters via devlink interface.
+Each parameter can be generic or driver specific and are device level
+parameters.
+
+Note that the driver-specific files should contain the generic params
+they support to, with supported config modes.
+
+Each parameter can be set in different configuration modes:
+ runtime - set while driver is running, no reset required.
+ driverinit - applied while driver initializes, requires restart
+ driver by devlink reload command.
+ permanent - written to device's non-volatile memory, hard reset
+ required.
+
+Following is the list of parameters:
+====================================
+enable_sriov [DEVICE, GENERIC]
+ Enable Single Root I/O Virtualisation (SRIOV) in
+ the device.
+ Type: Boolean
+
+ignore_ari [DEVICE, GENERIC]
+ Ignore Alternative Routing-ID Interpretation (ARI)
+ capability. If enabled, adapter will ignore ARI
+ capability even when platforms has the support
+ enabled and creates same number of partitions when
+ platform does not support ARI.
+ Type: Boolean
+
+msix_vec_per_pf_max [DEVICE, GENERIC]
+ Provides the maximum number of MSIX interrupts that
+ a device can create. Value is same across all
+ physical functions (PFs) in the device.
+ Type: u32
+
+msix_vec_per_pf_min [DEVICE, GENERIC]
+ Provides the minimum number of MSIX interrupts required
+ for the device initialization. Value is same across all
+ physical functions (PFs) in the device.
+ Type: u32
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 2/9] devlink: Add generic parameter msix_vec_per_pf_max
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
msix_vec_per_pf_max - This param sets the number of MSIX vectors
that the device requests from the host on driver initialization.
This value is set in the device which is applicable per PF.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 4 ++++
net/core/devlink.c | 5 +++++
2 files changed, 9 insertions(+)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 90d8343..59be17b 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -363,6 +363,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV,
DEVLINK_PARAM_GENERIC_ID_REGION_SNAPSHOT,
DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI,
+ DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -384,6 +385,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME "ignore_ari"
#define DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE DEVLINK_PARAM_TYPE_BOOL
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME "msix_vec_per_pf_max"
+#define DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE DEVLINK_PARAM_TYPE_U32
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 6b08ad6..7e0ac2e 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2681,6 +2681,11 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_IGNORE_ARI_NAME,
.type = DEVLINK_PARAM_GENERIC_IGNORE_ARI_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ .name = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_NAME,
+ .type = DEVLINK_PARAM_GENERIC_MSIX_VEC_PER_PF_MAX_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 9/9] devlink: Add Documentation/networking/devlink-params-bnxt.txt
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds a new file to add information about configuration
parameters that are supported by bnxt_en driver via devlink.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
Documentation/networking/devlink-params-bnxt.txt | 35 ++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/networking/devlink-params-bnxt.txt
diff --git a/Documentation/networking/devlink-params-bnxt.txt b/Documentation/networking/devlink-params-bnxt.txt
new file mode 100644
index 0000000..ca7c457
--- /dev/null
+++ b/Documentation/networking/devlink-params-bnxt.txt
@@ -0,0 +1,35 @@
+enable_sriov [DEVICE, GENERIC]
+ Enable Single Root I/O Virtualisation (SRIOV) in
+ the device.
+ Type: Boolean
+ Configuration mode: Permanent
+
+ignore_ari [DEVICE, GENERIC]
+ Ignore Alternative Routing-ID Interpretation (ARI)
+ capability. If enabled, adapter will ignore ARI
+ capability even when platforms has the support
+ enabled and creates same number of partitions when
+ platform does not support ARI.
+ Type: Boolean
+ Configuration mode: Permanent
+
+msix_vec_per_pf_max [DEVICE, GENERIC]
+ Provides the maximum number of MSIX interrupts that
+ a device can create. Value is same across all
+ physical functions (PFs) in the device.
+ Type: u32
+ Configuration mode: Permanent
+
+msix_vec_per_pf_min [DEVICE, GENERIC]
+ Provides the minimum number of MSIX interrupts required
+ or the device initialization. Value is same across all
+ physical functions (PFs) in the device.
+ Type: u32
+ Configuration mode: Permanent
+
+gre_ver_check [DEVICE, DRIVER-SPECIFIC]
+ Generic Routing Encapsulation (GRE) version check will
+ be enabled in the device. If disabled, device skips
+ version checking for incoming packets.
+ Type: Boolean
+ Configuration mode: Permanent
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 net-next 6/9] bnxt_en: Use msix_vec_per_pf_max and msix_vec_per_pf_min devlink params.
From: Vasundhara Volam @ 2018-09-24 5:16 UTC (permalink / raw)
To: davem; +Cc: michael.chan, netdev
In-Reply-To: <1537766181-18994-1-git-send-email-vasundhara-v.volam@broadcom.com>
This patch adds support for following generic permanent mode
devlink parameters. They can be modified using devlink param
commands.
msix_vec_per_pf_max - This param sets the number of MSIX vectors
that the device requests from the host on driver initialization.
This value is set in the device which limits MSIX vectors per PF.
msix_vec_per_pf_min - This param sets the number of minimal MSIX
vectors required for the device initialization. Value 0 indicates
a default value is selected. This value is set in the device which
limits MSIX vectors per PF.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 50 ++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 5 +++
2 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 1b25e3a..7dc754b 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -26,6 +26,10 @@
BNXT_NVM_SHARED_CFG, 1},
{DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
BNXT_NVM_SHARED_CFG, 1},
+ {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
+ NVM_OFF_MSIX_VEC_PER_PF_MAX, BNXT_NVM_SHARED_CFG, 10},
+ {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
+ NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -54,8 +58,22 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
idx = bp->pf.fw_fid - BNXT_FIRST_PF_FID;
bytesize = roundup(nvm_param.num_bits, BITS_PER_BYTE) / BITS_PER_BYTE;
- if (nvm_param.num_bits == 1)
- buf = &val->vbool;
+ switch (bytesize) {
+ case 1:
+ if (nvm_param.num_bits == 1)
+ buf = &val->vbool;
+ else
+ buf = &val->vu8;
+ break;
+ case 2:
+ buf = &val->vu16;
+ break;
+ case 4:
+ buf = &val->vu32;
+ break;
+ default:
+ return -EFAULT;
+ }
data_addr = dma_zalloc_coherent(&bp->pdev->dev, bytesize,
&data_dma_addr, GFP_KERNEL);
@@ -106,6 +124,26 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
}
+static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
+ union devlink_param_value val,
+ struct netlink_ext_ack *extack)
+{
+ int max_val;
+
+ if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX)
+ max_val = BNXT_MSIX_VEC_MAX;
+
+ if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN)
+ max_val = BNXT_MSIX_VEC_MIN_MAX;
+
+ if (val.vu32 < 0 || val.vu32 > max_val) {
+ NL_SET_ERR_MSG_MOD(extack, "MSIX value is exceeding the range");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct devlink_param bnxt_dl_params[] = {
DEVLINK_PARAM_GENERIC(ENABLE_SRIOV,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
@@ -115,6 +153,14 @@ static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
NULL),
+ DEVLINK_PARAM_GENERIC(MSIX_VEC_PER_PF_MAX,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ bnxt_dl_msix_validate),
+ DEVLINK_PARAM_GENERIC(MSIX_VEC_PER_PF_MIN,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ bnxt_dl_msix_validate),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index da146492..0e67c05 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -33,10 +33,15 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
}
}
+#define NVM_OFF_MSIX_VEC_PER_PF_MAX 108
+#define NVM_OFF_MSIX_VEC_PER_PF_MIN 114
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_HW_TC_OFFLOAD 170
#define NVM_OFF_ENABLE_SRIOV 401
+#define BNXT_MSIX_VEC_MAX 1280
+#define BNXT_MSIX_VEC_MIN_MAX 128
+
enum bnxt_nvm_dir_type {
BNXT_NVM_SHARED_CFG = 40,
BNXT_NVM_PORT_CFG,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 net] net: aquantia: memory corruption on jumbo frames
From: David Miller @ 2018-09-24 5:25 UTC (permalink / raw)
To: igor.russkikh; +Cc: nikita.danilov, netdev, f.gerold
In-Reply-To: <71ff3378-b20e-e0e9-d643-d4f7401d1864@aquantia.com>
From: Igor Russkikh <igor.russkikh@aquantia.com>
Date: Tue, 18 Sep 2018 11:28:55 +0300
>
>>> Fixes: 018423e90bee ("net: ethernet: aquantia: Add ring support code")
>>>
>>> Reported-by: Friedemann Gerold <f.gerold@b-c-s.de>
>>> Reported-by: Michael Rauch <michael@rauch.be>
>>> Signed-off-by: Friedemann Gerold <f.gerold@b-c-s.de>
>>> Tested-by: Nikita Danilov <nikita.danilov@aquantia.com>
>>> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
>>
>> APplied and queued up for -stable.
>
> Hi David, I see this was applied to net-next tree only.
> Can we have it in net? We consider it as critical flaw.
Sorry about that, fixed.
^ permalink raw reply
* Re: [PATCH net-next] tcp: expose sk_state in tcp_retransmit_skb tracepoint
From: Yafang Shao @ 2018-09-24 12:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, David Miller, netdev, LKML
In-Reply-To: <375c389d-f391-5b72-bc52-9a82d61c6bd7@gmail.com>
On Mon, Sep 24, 2018 at 5:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 09/23/2018 12:49 PM, Yafang Shao wrote:
>> With sk_state, we can know whether this connection is in SYN_SENT state
>> or ESTBLISHED state.
>> The reason to distinguish between these two scenario is that the
>> retransmission in ESTABLISHED state always mean network congestion while
>> in SYN_SENT state it always mean server issue, i.e. the syn packet is
>> dropped due to syn backlog queue full.
>
> You mean, a packet drop on the remote peer ?
>
Yes, I mean drop on the remote peer.
> It could also be a packet drop in the network.
>
Yes of course.
> Your patch is good, but changelog is quite misleading.
Will modify the changelog.
Thanks
Yafang
^ 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