* Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Nicolas Ferre @ 2017-01-25 9:26 UTC (permalink / raw)
To: Andrei Pistirica, netdev, linux-kernel, linux-arm-kernel, davem,
harinikatakamlinux, harini.katakam
Cc: punnaia, michals, anirudh, boris.brezillon, alexandre.belloni,
tbultel, richardcochran, rafalo
In-Reply-To: <9bc6b112-f79c-58e4-7d2b-718ee07ff3a1@atmel.com>
Le 19/01/2017 à 17:07, Nicolas Ferre a écrit :
> Le 19/01/2017 à 08:56, Andrei Pistirica a écrit :
>> This patch does the following:
>> - MACB/GEM-PTP interface
>> - registers and bitfields for TSU
>> - capability flags to enable PTP per platform basis
>>
>> Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Harini or Rafal, do you plan to review this patch and add your
"Reviewed-by" tags? It can be useful to make this support move forward.
Regards,
>> ---
>> Patch history:
>>
>> Version 1:
>> This is just the common code for MACB/GEM-PTP support.
>> Code is based on the comments related to the following patch series:
>> - [RFC PATCH net-next v1-to-4 1/2] macb: Add 1588 support in Cadence GEM
>> - [RFC PATCH net-next v1-to-4 2/2] macb: Enable 1588 support in SAMA5Dx platforms
>>
>> Version 2:
>> - Cosmetic changes and PTP capability flag changed doe to overlapping with JUMBO.
>>
>> Note: Patch on net-next: January 19.
>>
>> drivers/net/ethernet/cadence/macb.c | 32 +++++++++++++++-
>> drivers/net/ethernet/cadence/macb.h | 74 +++++++++++++++++++++++++++++++++++++
>> 2 files changed, 104 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>> index c0fb80a..ff1e648 100644
>> --- a/drivers/net/ethernet/cadence/macb.c
>> +++ b/drivers/net/ethernet/cadence/macb.c
>> @@ -2085,6 +2085,9 @@ static int macb_open(struct net_device *dev)
>>
>> netif_tx_start_all_queues(dev);
>>
>> + if (bp->ptp_info)
>> + bp->ptp_info->ptp_init(dev);
>> +
>> return 0;
>> }
>>
>> @@ -2106,6 +2109,9 @@ static int macb_close(struct net_device *dev)
>>
>> macb_free_consistent(bp);
>>
>> + if (bp->ptp_info)
>> + bp->ptp_info->ptp_remove(dev);
>> +
>> return 0;
>> }
>>
>> @@ -2379,6 +2385,17 @@ static int macb_set_ringparam(struct net_device *netdev,
>> return 0;
>> }
>>
>> +static int macb_get_ts_info(struct net_device *netdev,
>> + struct ethtool_ts_info *info)
>> +{
>> + struct macb *bp = netdev_priv(netdev);
>> +
>> + if (bp->ptp_info)
>> + return bp->ptp_info->get_ts_info(netdev, info);
>> +
>> + return ethtool_op_get_ts_info(netdev, info);
>> +}
>> +
>> static const struct ethtool_ops macb_ethtool_ops = {
>> .get_regs_len = macb_get_regs_len,
>> .get_regs = macb_get_regs,
>> @@ -2396,7 +2413,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
>> .get_regs_len = macb_get_regs_len,
>> .get_regs = macb_get_regs,
>> .get_link = ethtool_op_get_link,
>> - .get_ts_info = ethtool_op_get_ts_info,
>> + .get_ts_info = macb_get_ts_info,
>> .get_ethtool_stats = gem_get_ethtool_stats,
>> .get_strings = gem_get_ethtool_strings,
>> .get_sset_count = gem_get_sset_count,
>> @@ -2409,6 +2426,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
>> static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>> {
>> struct phy_device *phydev = dev->phydev;
>> + struct macb *bp = netdev_priv(dev);
>>
>> if (!netif_running(dev))
>> return -EINVAL;
>> @@ -2416,7 +2434,17 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>> if (!phydev)
>> return -ENODEV;
>>
>> - return phy_mii_ioctl(phydev, rq, cmd);
>> + if (!bp->ptp_info)
>> + return phy_mii_ioctl(phydev, rq, cmd);
>> +
>> + switch (cmd) {
>> + case SIOCSHWTSTAMP:
>> + return bp->ptp_info->set_hwtst(dev, rq, cmd);
>> + case SIOCGHWTSTAMP:
>> + return bp->ptp_info->get_hwtst(dev, rq);
>> + default:
>> + return phy_mii_ioctl(phydev, rq, cmd);
>> + }
>> }
>>
>> static int macb_set_features(struct net_device *netdev,
>> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
>> index d67adad..94ddedd 100644
>> --- a/drivers/net/ethernet/cadence/macb.h
>> +++ b/drivers/net/ethernet/cadence/macb.h
>> @@ -131,6 +131,20 @@
>> #define GEM_RXIPCCNT 0x01a8 /* IP header Checksum Error Counter */
>> #define GEM_RXTCPCCNT 0x01ac /* TCP Checksum Error Counter */
>> #define GEM_RXUDPCCNT 0x01b0 /* UDP Checksum Error Counter */
>> +#define GEM_TISUBN 0x01bc /* 1588 Timer Increment Sub-ns */
>> +#define GEM_TSH 0x01c0 /* 1588 Timer Seconds High */
>> +#define GEM_TSL 0x01d0 /* 1588 Timer Seconds Low */
>> +#define GEM_TN 0x01d4 /* 1588 Timer Nanoseconds */
>> +#define GEM_TA 0x01d8 /* 1588 Timer Adjust */
>> +#define GEM_TI 0x01dc /* 1588 Timer Increment */
>> +#define GEM_EFTSL 0x01e0 /* PTP Event Frame Tx Seconds Low */
>> +#define GEM_EFTN 0x01e4 /* PTP Event Frame Tx Nanoseconds */
>> +#define GEM_EFRSL 0x01e8 /* PTP Event Frame Rx Seconds Low */
>> +#define GEM_EFRN 0x01ec /* PTP Event Frame Rx Nanoseconds */
>> +#define GEM_PEFTSL 0x01f0 /* PTP Peer Event Frame Tx Secs Low */
>> +#define GEM_PEFTN 0x01f4 /* PTP Peer Event Frame Tx Ns */
>> +#define GEM_PEFRSL 0x01f8 /* PTP Peer Event Frame Rx Sec Low */
>> +#define GEM_PEFRN 0x01fc /* PTP Peer Event Frame Rx Ns */
>> #define GEM_DCFG1 0x0280 /* Design Config 1 */
>> #define GEM_DCFG2 0x0284 /* Design Config 2 */
>> #define GEM_DCFG3 0x0288 /* Design Config 3 */
>> @@ -174,6 +188,7 @@
>> #define MACB_NCR_TPF_SIZE 1
>> #define MACB_TZQ_OFFSET 12 /* Transmit zero quantum pause frame */
>> #define MACB_TZQ_SIZE 1
>> +#define MACB_SRTSM_OFFSET 15
>>
>> /* Bitfields in NCFGR */
>> #define MACB_SPD_OFFSET 0 /* Speed */
>> @@ -319,6 +334,32 @@
>> #define MACB_PTZ_SIZE 1
>> #define MACB_WOL_OFFSET 14 /* Enable wake-on-lan interrupt */
>> #define MACB_WOL_SIZE 1
>> +#define MACB_DRQFR_OFFSET 18 /* PTP Delay Request Frame Received */
>> +#define MACB_DRQFR_SIZE 1
>> +#define MACB_SFR_OFFSET 19 /* PTP Sync Frame Received */
>> +#define MACB_SFR_SIZE 1
>> +#define MACB_DRQFT_OFFSET 20 /* PTP Delay Request Frame Transmitted */
>> +#define MACB_DRQFT_SIZE 1
>> +#define MACB_SFT_OFFSET 21 /* PTP Sync Frame Transmitted */
>> +#define MACB_SFT_SIZE 1
>> +#define MACB_PDRQFR_OFFSET 22 /* PDelay Request Frame Received */
>> +#define MACB_PDRQFR_SIZE 1
>> +#define MACB_PDRSFR_OFFSET 23 /* PDelay Response Frame Received */
>> +#define MACB_PDRSFR_SIZE 1
>> +#define MACB_PDRQFT_OFFSET 24 /* PDelay Request Frame Transmitted */
>> +#define MACB_PDRQFT_SIZE 1
>> +#define MACB_PDRSFT_OFFSET 25 /* PDelay Response Frame Transmitted */
>> +#define MACB_PDRSFT_SIZE 1
>> +#define MACB_SRI_OFFSET 26 /* TSU Seconds Register Increment */
>> +#define MACB_SRI_SIZE 1
>> +
>> +/* Timer increment fields */
>> +#define MACB_TI_CNS_OFFSET 0
>> +#define MACB_TI_CNS_SIZE 8
>> +#define MACB_TI_ACNS_OFFSET 8
>> +#define MACB_TI_ACNS_SIZE 8
>> +#define MACB_TI_NIT_OFFSET 16
>> +#define MACB_TI_NIT_SIZE 8
>>
>> /* Bitfields in MAN */
>> #define MACB_DATA_OFFSET 0 /* data */
>> @@ -386,6 +427,17 @@
>> #define GEM_PBUF_LSO_OFFSET 27
>> #define GEM_PBUF_LSO_SIZE 1
>>
>> +/* Bitfields in TISUBN */
>> +#define GEM_SUBNSINCR_OFFSET 0
>> +#define GEM_SUBNSINCR_SIZE 16
>> +
>> +/* Bitfields in TI */
>> +#define GEM_NSINCR_OFFSET 0
>> +#define GEM_NSINCR_SIZE 8
>> +
>> +/* Bitfields in ADJ */
>> +#define GEM_ADDSUB_OFFSET 31
>> +#define GEM_ADDSUB_SIZE 1
>> /* Constants for CLK */
>> #define MACB_CLK_DIV8 0
>> #define MACB_CLK_DIV16 1
>> @@ -413,6 +465,7 @@
>> #define MACB_CAPS_NO_GIGABIT_HALF 0x00000008
>> #define MACB_CAPS_USRIO_DISABLED 0x00000010
>> #define MACB_CAPS_JUMBO 0x00000020
>> +#define MACB_CAPS_GEM_HAS_PTP 0x00000040
>> #define MACB_CAPS_FIFO_MODE 0x10000000
>> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
>> #define MACB_CAPS_SG_DISABLED 0x40000000
>> @@ -782,6 +835,20 @@ struct macb_or_gem_ops {
>> int (*mog_rx)(struct macb *bp, int budget);
>> };
>>
>> +/* MACB-PTP interface: adapt to platform needs. */
>> +struct macb_ptp_info {
>> + void (*ptp_init)(struct net_device *ndev);
>> + void (*ptp_remove)(struct net_device *ndev);
>> + s32 (*get_ptp_max_adj)(void);
>> + unsigned int (*get_tsu_rate)(struct macb *bp);
>> + int (*get_ts_info)(struct net_device *dev,
>> + struct ethtool_ts_info *info);
>> + int (*get_hwtst)(struct net_device *netdev,
>> + struct ifreq *ifr);
>> + int (*set_hwtst)(struct net_device *netdev,
>> + struct ifreq *ifr, int cmd);
>> +};
>> +
>> struct macb_config {
>> u32 caps;
>> unsigned int dma_burst_length;
>> @@ -874,6 +941,8 @@ struct macb {
>> unsigned int jumbo_max_len;
>>
>> u32 wol;
>> +
>> + struct macb_ptp_info *ptp_info; /* macb-ptp interface */
>> };
>>
>> static inline bool macb_is_gem(struct macb *bp)
>> @@ -881,4 +950,9 @@ static inline bool macb_is_gem(struct macb *bp)
>> return !!(bp->caps & MACB_CAPS_MACB_IS_GEM);
>> }
>>
>> +static inline bool gem_has_ptp(struct macb *bp)
>> +{
>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP);
>> +}
>> +
>> #endif /* _MACB_H */
>>
>
>
--
Nicolas Ferre
^ permalink raw reply
* NAPI on USB network drivers
From: Oliver Neukum @ 2017-01-25 9:34 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-usb
Hi,
looking at r8152 I noticed that it uses NAPI. I never considered
this for the generic USB networking code as you cannot disable
interrupts for USB. Is it still worth it? What are the benefits?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Harini Katakam @ 2017-01-25 9:37 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Andrei Pistirica, netdev, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, David Miller,
Harini Katakam, Punnaiah Choudary Kalluri, michals@xilinx.com,
Anirudha Sarangi, Boris Brezillon, alexandre.belloni, tbultel,
Richard Cochran, Rafal Ozieblo
In-Reply-To: <88d4aee3-cc38-b271-3f52-a28e5af7bdac@atmel.com>
On Wed, Jan 25, 2017 at 2:56 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Le 19/01/2017 à 17:07, Nicolas Ferre a écrit :
>> Le 19/01/2017 à 08:56, Andrei Pistirica a écrit :
>>> This patch does the following:
>>> - MACB/GEM-PTP interface
>>> - registers and bitfields for TSU
>>> - capability flags to enable PTP per platform basis
>>>
>>> Signed-off-by: Andrei Pistirica <andrei.pistirica@microchip.com>
>>
>> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Reviewed-by: Harini Katakam <harinik@xilinx.com>
>
> Harini or Rafal, do you plan to review this patch and add your
> "Reviewed-by" tags? It can be useful to make this support move forward.
Sure, reviewed and working with it, meant to add tag :)
Regards,
Harini
^ permalink raw reply
* RE: NAPI on USB network drivers
From: Hayes Wang @ 2017-01-25 9:39 UTC (permalink / raw)
To: Oliver Neukum
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1485336881.16604.2.camel-IBi9RG/b67k@public.gmane.org>
Oliver Neukum [mailto:oneukum@suse.com]
> Sent: Wednesday, January 25, 2017 5:35 PM
[...]
> looking at r8152 I noticed that it uses NAPI. I never considered
> this for the generic USB networking code as you cannot disable
> interrupts for USB. Is it still worth it? What are the benefits?
You could use napi_gro_receive() and it influences the performance.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: leds: Fix truncated LED trigger names
From: Geert Uytterhoeven @ 2017-01-25 9:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: Geert Uytterhoeven, David S. Miller, Zach Brown,
Volodymyr Bendiuga, Magnus Öberg, Florian Fainelli,
netdev@vger.kernel.org, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <20170124200339.GT10895@lunn.ch>
Hi Andrew,
On Tue, Jan 24, 2017 at 9:03 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index 5c9d2529685fe215..f6ab919528ab3627 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -25,7 +25,6 @@
>> #include <linux/timer.h>
>> #include <linux/workqueue.h>
>> #include <linux/mod_devicetable.h>
>> -#include <linux/phy_led_triggers.h>
>>
>> #include <linux/atomic.h>
>>
>> @@ -339,6 +338,8 @@ struct phy_c45_device_ids {
>> u32 device_ids[8];
>> };
>>
>> +#include <linux/phy_led_triggers.h>
>> +
>> /* phy_device: An instance of a PHY
>> *
>> * drv: Pointer to the driver for this PHY instance
>> diff --git a/include/linux/phy_led_triggers.h b/include/linux/phy_led_triggers.h
>> index a2daea0a37d2ae14..69dffb4fc5a294e9 100644
>> --- a/include/linux/phy_led_triggers.h
>> +++ b/include/linux/phy_led_triggers.h
>> @@ -20,9 +20,8 @@
>> #include <linux/leds.h>
>>
>> #define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 10
>> -#define PHY_MII_BUS_ID_SIZE (20 - 3)
>>
>> -#define PHY_LINK_LED_TRIGGER_NAME_SIZE (PHY_MII_BUS_ID_SIZE + \
>> +#define PHY_LINK_LED_TRIGGER_NAME_SIZE (MII_BUS_ID_SIZE + \
>> FIELD_SIZEOF(struct mdio_device, addr)+\
>> PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE)
>
> Hi Geert
>
> Using the macro is great, but it does seem a bit ugly having the
> include in the middle of the file.
>
> As far as i can see, phy.h only uses a pointer to a struct
> phy_led_trigger, not struct phy_led_trigger itself. Could you try
> removing the header file all together and just have a forward
> declaration of phy_led_trigger?
Thanks for the suggestion!
Yes, the include can be removed. A forward declaration isn't even needed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 0/3] net: phy: leds: Fix truncated LED trigger names and crashes
From: Geert Uytterhoeven @ 2017-01-25 10:39 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Zach Brown, Volodymyr Bendiuga
Cc: Andrew Lunn, Magnus Öberg, netdev, linux-renesas-soc,
linux-kernel, Geert Uytterhoeven
Hi David,
I started seeing crashes during s2ram and poweroff on all my ARM boards,
like:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
[<c04116d4>] (__list_del_entry_valid) from [<c05e8948>] (led_trigger_unregister+0x34/0xcc)
[<c05e8948>] (led_trigger_unregister) from [<c05336c4>] (phy_led_triggers_unregister+0x28/0x34)
[<c05336c4>] (phy_led_triggers_unregister) from [<c0531d44>] (phy_detach+0x30/0x74)
[<c0531d44>] (phy_detach) from [<c0538bdc>] (sh_eth_close+0x64/0x9c)
[<c0538bdc>] (sh_eth_close) from [<c04d4ce0>] (dpm_run_callback+0x48/0xc8)
or:
list_del corruption. prev->next should be dede6540, but was 2e323931
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:52!
...
[<c02f6d70>] (__list_del_entry_valid) from [<c0425168>] (led_trigger_unregister+0x34/0xcc)
[<c0425168>] (led_trigger_unregister) from [<c03a05a0>] (phy_led_triggers_unregister+0x28/0x34)
[<c03a05a0>] (phy_led_triggers_unregister) from [<c039ec04>] (phy_detach+0x30/0x74)
[<c039ec04>] (phy_detach) from [<c03a4fc0>] (sh_eth_close+0x6c/0xa4)
[<c03a4fc0>] (sh_eth_close) from [<c0483234>] (__dev_close_many+0xac/0xd0)
As the only clue was a kernel message like
sh-eth ee700000.ethernet eth0: No phy led trigger registered for speed(100)
I had to bisected this, leading to commit 4567d686f5c6d955 ("phy:
increase size of MII_BUS_ID_SIZE and bus_id"). Reverting that commit
fixed the issue.
More investigation revealed the crashes are due to the combination of
two things:
- Truncated LED trigger names, leading to duplicate names, and
registration failures,
- Bad error handling in case of registration failures.
Both are fixed by this patch series.
Changes compared to v1:
- Add Reviewed-by,
- New patch "net: phy: leds: Break dependency of phy.h on
phy_led_triggers.h",
- Drop moving the include of <linux/phy_led_triggers.h>, as
<linux/phy.h> no longer includes it,
- #include <linux/phy.h> from <linux/phy_led_triggers.h>.
Thanks!
Geert Uytterhoeven (3):
net: phy: leds: Clear phy_num_led_triggers on failure to avoid crash
net: phy: leds: Break dependency of phy.h on phy_led_triggers.h
net: phy: leds: Fix truncated LED trigger names
drivers/net/phy/phy.c | 1 +
drivers/net/phy/phy_led_triggers.c | 9 +++++++--
include/linux/phy.h | 1 -
include/linux/phy_led_triggers.h | 4 ++--
4 files changed, 10 insertions(+), 5 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/3] net: phy: leds: Clear phy_num_led_triggers on failure to avoid crash
From: Geert Uytterhoeven @ 2017-01-25 10:39 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Zach Brown, Volodymyr Bendiuga
Cc: Andrew Lunn, Magnus Öberg, netdev, linux-renesas-soc,
linux-kernel, Geert Uytterhoeven
In-Reply-To: <1485340790-10785-1-git-send-email-geert+renesas@glider.be>
phy_attach_direct() ignores errors returned by
phy_led_triggers_register(). I think that's OK, as LED triggers can be
considered a non-critical feature.
However, this causes problems later:
- phy_led_trigger_change_speed() will access the array
phy_device.phy_led_triggers, which has been freed in the error path
of phy_led_triggers_register(), which may lead to a crash.
- phy_led_triggers_unregister() will access the same array, leading to
crashes during s2ram or poweroff, like:
Unable to handle kernel NULL pointer dereference at virtual address
00000000
...
[<c04116d4>] (__list_del_entry_valid) from [<c05e8948>] (led_trigger_unregister+0x34/0xcc)
[<c05e8948>] (led_trigger_unregister) from [<c05336c4>] (phy_led_triggers_unregister+0x28/0x34)
[<c05336c4>] (phy_led_triggers_unregister) from [<c0531d44>] (phy_detach+0x30/0x74)
[<c0531d44>] (phy_detach) from [<c0538bdc>] (sh_eth_close+0x64/0x9c)
[<c0538bdc>] (sh_eth_close) from [<c04d4ce0>] (dpm_run_callback+0x48/0xc8)
or:
list_del corruption. prev->next should be dede6540, but was 2e323931
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:52!
...
[<c02f6d70>] (__list_del_entry_valid) from [<c0425168>] (led_trigger_unregister+0x34/0xcc)
[<c0425168>] (led_trigger_unregister) from [<c03a05a0>] (phy_led_triggers_unregister+0x28/0x34)
[<c03a05a0>] (phy_led_triggers_unregister) from [<c039ec04>] (phy_detach+0x30/0x74)
[<c039ec04>] (phy_detach) from [<c03a4fc0>] (sh_eth_close+0x6c/0xa4)
[<c03a4fc0>] (sh_eth_close) from [<c0483234>] (__dev_close_many+0xac/0xd0)
To fix this, clear phy_device.phy_num_led_triggers in the error path of
phy_led_triggers_register() fails.
Note that the "No phy led trigger registered for speed" message will
still be printed on link speed changes, which is a good cue that
something went wrong with the LED triggers.
Fixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy link state change")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
Alternatively, phy_attach_direct() could consider
phy_led_triggers_register() failures as fatal, so
phy_led_trigger_change_speed() and phy_led_triggers_unregister() are
never called afterwards.
Exposed by commit 4567d686f5c6d955 ("phy: increase size of
MII_BUS_ID_SIZE and bus_id"), which caused duplicate trigger names.
v2:
- Add Reviewed-by.
---
drivers/net/phy/phy_led_triggers.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
index fa62bdf2f52694de..3f619e7371e97d8a 100644
--- a/drivers/net/phy/phy_led_triggers.c
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -102,8 +102,10 @@ int phy_led_triggers_register(struct phy_device *phy)
sizeof(struct phy_led_trigger) *
phy->phy_num_led_triggers,
GFP_KERNEL);
- if (!phy->phy_led_triggers)
- return -ENOMEM;
+ if (!phy->phy_led_triggers) {
+ err = -ENOMEM;
+ goto out_clear;
+ }
for (i = 0; i < phy->phy_num_led_triggers; i++) {
err = phy_led_trigger_register(phy, &phy->phy_led_triggers[i],
@@ -120,6 +122,8 @@ int phy_led_triggers_register(struct phy_device *phy)
while (i--)
phy_led_trigger_unregister(&phy->phy_led_triggers[i]);
devm_kfree(&phy->mdio.dev, phy->phy_led_triggers);
+out_clear:
+ phy->phy_num_led_triggers = 0;
return err;
}
EXPORT_SYMBOL_GPL(phy_led_triggers_register);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] net: phy: leds: Break dependency of phy.h on phy_led_triggers.h
From: Geert Uytterhoeven @ 2017-01-25 10:39 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Zach Brown, Volodymyr Bendiuga
Cc: Andrew Lunn, Magnus Öberg, netdev, linux-renesas-soc,
linux-kernel, Geert Uytterhoeven
In-Reply-To: <1485340790-10785-1-git-send-email-geert+renesas@glider.be>
<linux/phy.h> includes <linux/phy_led_triggers.h>, which is not really
needed. Drop the include from <linux/phy.h>, and add it to all users
that didn't include it explicitly.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- New.
---
drivers/net/phy/phy.c | 1 +
drivers/net/phy/phy_led_triggers.c | 1 +
include/linux/phy.h | 1 -
3 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 48da6e93c3f783e0..807abd6e331f8aa2 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -29,6 +29,7 @@
#include <linux/mii.h>
#include <linux/ethtool.h>
#include <linux/phy.h>
+#include <linux/phy_led_triggers.h>
#include <linux/timer.h>
#include <linux/workqueue.h>
#include <linux/mdio.h>
diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
index 3f619e7371e97d8a..94ca42e630bbead0 100644
--- a/drivers/net/phy/phy_led_triggers.c
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -12,6 +12,7 @@
*/
#include <linux/leds.h>
#include <linux/phy.h>
+#include <linux/phy_led_triggers.h>
#include <linux/netdevice.h>
static struct phy_led_trigger *phy_speed_to_led_trigger(struct phy_device *phy,
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5c9d2529685fe215..43474f39ef6523c5 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -25,7 +25,6 @@
#include <linux/timer.h>
#include <linux/workqueue.h>
#include <linux/mod_devicetable.h>
-#include <linux/phy_led_triggers.h>
#include <linux/atomic.h>
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/3] net: phy: leds: Fix truncated LED trigger names
From: Geert Uytterhoeven @ 2017-01-25 10:39 UTC (permalink / raw)
To: David S. Miller, Florian Fainelli, Zach Brown, Volodymyr Bendiuga
Cc: Andrew Lunn, Magnus Öberg, netdev, linux-renesas-soc,
linux-kernel, Geert Uytterhoeven
In-Reply-To: <1485340790-10785-1-git-send-email-geert+renesas@glider.be>
Commit 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and
bus_id") increased the size of MII bus IDs, but forgot to update the
private definition in <linux/phy_led_triggers.h>.
This may cause:
1. Truncation of LED trigger names,
2. Duplicate LED trigger names,
3. Failures registering LED triggers,
4. Crashes due to bad error handling in the LED trigger failure path.
To fix this, and prevent the definitions going out of sync again in the
future, let the PHY LED trigger code use the existing MII_BUS_ID_SIZE
definition.
Example:
- Before I had triggers "ee700000.etherne:01:100Mbps" and
"ee700000.etherne:01:10Mbps",
- After the increase of MII_BUS_ID_SIZE, both became
"ee700000.ethernet-ffffffff:01:" => FAIL,
- Now, the triggers are "ee700000.ethernet-ffffffff:01:100Mbps" and
"ee700000.ethernet-ffffffff:01:10Mbps", which are unique again.
Fixes: 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and bus_id")
Fixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy link state change")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Drop moving the include of <linux/phy_led_triggers.h>, as
<linux/phy.h> no longer includes it,
- #include <linux/phy.h> from <linux/phy_led_triggers.h>.
---
include/linux/phy_led_triggers.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/phy_led_triggers.h b/include/linux/phy_led_triggers.h
index a2daea0a37d2ae14..b37b05bfd1a6dd8a 100644
--- a/include/linux/phy_led_triggers.h
+++ b/include/linux/phy_led_triggers.h
@@ -18,11 +18,11 @@
#ifdef CONFIG_LED_TRIGGER_PHY
#include <linux/leds.h>
+#include <linux/phy.h>
#define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 10
-#define PHY_MII_BUS_ID_SIZE (20 - 3)
-#define PHY_LINK_LED_TRIGGER_NAME_SIZE (PHY_MII_BUS_ID_SIZE + \
+#define PHY_LINK_LED_TRIGGER_NAME_SIZE (MII_BUS_ID_SIZE + \
FIELD_SIZEOF(struct mdio_device, addr)+\
PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation: devicetree: change the mediatek ethernet compatible string
From: Matthias Brugger @ 2017-01-25 10:43 UTC (permalink / raw)
To: John Crispin, Rob Herring, David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1485332455-34743-1-git-send-email-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
On 01/25/2017 09:20 AM, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
>
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
>
> Reported-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> ---
sounds reasonable to me:
Reviewed-by: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Documentation/devicetree/bindings/net/mediatek-net.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
> index c010faf..c7194e8 100644
> --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> @@ -7,7 +7,7 @@ have dual GMAC each represented by a child node..
> * Ethernet controller node
>
> Required properties:
> -- compatible: Should be "mediatek,mt7623-eth"
> +- compatible: Should be "mediatek,mt2701-eth"
> - reg: Address and length of the register set for the device
> - interrupts: Should contain the three frame engines interrupts in numeric
> order. These are fe_int0, fe_int1 and fe_int2.
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [patch] samples/bpf: silence shift wrapping warning
From: David Laight @ 2017-01-25 11:08 UTC (permalink / raw)
To: 'Alexei Starovoitov', Dan Carpenter
Cc: Arnaldo Carvalho de Melo, Thomas Graf, Alexei Starovoitov,
Joe Stringer, David S. Miller, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20170122225123.GA73160@ast-mbp.thefacebook.com>
From: Alexei Starovoitov
> Sent: 22 January 2017 22:51
> On Sat, Jan 21, 2017 at 07:51:43AM +0300, Dan Carpenter wrote:
> > max_key is a value in the 0-63 range, so on 32 bit systems the shift
> > could wrap.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Looks fine. I think 'net-next' is ok.
>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
>
> > diff --git a/samples/bpf/lwt_len_hist_user.c b/samples/bpf/lwt_len_hist_user.c
> > index ec8f3bb..bd06eef 100644
> > --- a/samples/bpf/lwt_len_hist_user.c
> > +++ b/samples/bpf/lwt_len_hist_user.c
> > @@ -68,7 +68,7 @@ int main(int argc, char **argv)
> > for (i = 1; i <= max_key + 1; i++) {
> > stars(starstr, data[i - 1], max_value, MAX_STARS);
> > printf("%8ld -> %-8ld : %-8ld |%-*s|\n",
> > - (1l << i) >> 1, (1l << i) - 1, data[i - 1],
> > + (1ULL << i) >> 1, (1ULL << i) - 1, data[i - 1],
> > MAX_STARS, starstr);
> > }
The format effectors are wrong on 32bit systems.
David
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Vlastimil Babka @ 2017-01-25 11:15 UTC (permalink / raw)
To: Michal Hocko
Cc: Kees Cook, Andrew Morton, David Rientjes, Mel Gorman,
Johannes Weiner, Al Viro, Linux-MM, LKML, Martin Schwidefsky,
Heiko Carstens, Herbert Xu, Anton Vorontsov, Colin Cross,
Tony Luck, Rafael J. Wysocki, Ben Skeggs, Kent Overstreet,
Santosh Raspatur, Hariprasad S, Tariq Toukan, Yishai Hadas,
Dan Williams, Oleg Drokin, Andreas
In-Reply-To: <20170124150004.GM6867@dhcp22.suse.cz>
On 01/24/2017 04:00 PM, Michal Hocko wrote:
>> > Well, I am not opposed to kvmalloc_array but I would argue that this
>> > conversion cannot introduce new overflow issues. The code would have
>> > to be broken already because even though kmalloc_array checks for the
>> > overflow but vmalloc fallback doesn't...
>>
>> Yeah I agree, but if some of the places were really wrong, after the
>> conversion we won't see them anymore.
>>
>> > If there is a general interest for this API I can add it.
>>
>> I think it would be better, yes.
>
> OK, fair enough. I will fold the following into the original patch. I
> was little bit reluctant to create kvcalloc so I've made the original
> callers more talkative and added | __GFP_ZERO.
Fair enough,
> To be honest I do not
> really like how kcalloc...
how kcalloc what?
[...]
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index cdc55d5ee4ad..eca16612b1ae 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -712,10 +712,7 @@ EXPORT_SYMBOL(xt_check_entry_offsets);
> */
> unsigned int *xt_alloc_entry_offsets(unsigned int size)
> {
> - if (size < (SIZE_MAX / sizeof(unsigned int)))
> - return kvzalloc(size * sizeof(unsigned int), GFP_KERNEL);
> -
> - return NULL;
> + return kvmalloc_array(size * sizeof(unsigned int), GFP_KERNEL | __GFP_ZERO);
This one wouldn't compile.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 0/2] More ethtool support and BGX configuration changes
From: sunil.kovvuri @ 2017-01-25 12:06 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, linux-arm-kernel, Sunil Goutham
From: Sunil Goutham <sgoutham@cavium.com>
These patches adds support to set queue sizes from ethtool and changes
the way serdes lane configuration is done by BGX driver on 81/83xx
platforms.
Sunil Goutham (2):
net: thunderx: Support to configure queue sizes from ethtool
net: thunderx: Leave serdes lane config on 81/83xx to firmware
.../net/ethernet/cavium/thunder/nicvf_ethtool.c | 39 ++++++++-
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 19 ++++-
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 16 +++-
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 95 ++++------------------
4 files changed, 83 insertions(+), 86 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] net: thunderx: Support to configure queue sizes from ethtool
From: sunil.kovvuri @ 2017-01-25 12:06 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, linux-arm-kernel, Sunil Goutham
In-Reply-To: <1485345984-28163-1-git-send-email-sunil.kovvuri@gmail.com>
From: Sunil Goutham <sgoutham@cavium.com>
Adds support to set Rx/Tx queue sizes from ethtool. Fixes
an issue with retrieving queue size. Also sets SQ's CQ_LIMIT
based on configured Tx queue size such that HW doesn't process
SQEs when there is no sufficient space in CQ.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
.../net/ethernet/cavium/thunder/nicvf_ethtool.c | 39 ++++++++++++++++++++--
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 19 +++++++++--
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 16 ++++++---
3 files changed, 65 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
index 5ac4746..02a986c 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
@@ -471,12 +471,46 @@ static void nicvf_get_ringparam(struct net_device *netdev,
struct nicvf *nic = netdev_priv(netdev);
struct queue_set *qs = nic->qs;
- ring->rx_max_pending = MAX_RCV_BUF_COUNT;
- ring->rx_pending = qs->rbdr_len;
+ ring->rx_max_pending = MAX_CMP_QUEUE_LEN;
+ ring->rx_pending = qs->cq_len;
ring->tx_max_pending = MAX_SND_QUEUE_LEN;
ring->tx_pending = qs->sq_len;
}
+static int nicvf_set_ringparam(struct net_device *netdev,
+ struct ethtool_ringparam *ring)
+{
+ struct nicvf *nic = netdev_priv(netdev);
+ struct queue_set *qs = nic->qs;
+ u32 rx_count, tx_count;
+
+ /* Due to HW errata this is not supported on T88 pass 1.x silicon */
+ if (pass1_silicon(nic->pdev))
+ return -EINVAL;
+
+ if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending))
+ return -EINVAL;
+
+ tx_count = clamp_t(u32, ring->tx_pending,
+ MIN_SND_QUEUE_LEN, MAX_SND_QUEUE_LEN);
+ rx_count = clamp_t(u32, ring->rx_pending,
+ MIN_CMP_QUEUE_LEN, MAX_CMP_QUEUE_LEN);
+
+ if ((tx_count == qs->sq_len) && (rx_count == qs->cq_len))
+ return 0;
+
+ /* Permitted lengths are 1K, 2K, 4K, 8K, 16K, 32K, 64K */
+ qs->sq_len = rounddown_pow_of_two(tx_count);
+ qs->cq_len = rounddown_pow_of_two(rx_count);
+
+ if (netif_running(netdev)) {
+ nicvf_stop(netdev);
+ nicvf_open(netdev);
+ }
+
+ return 0;
+}
+
static int nicvf_get_rss_hash_opts(struct nicvf *nic,
struct ethtool_rxnfc *info)
{
@@ -787,6 +821,7 @@ static const struct ethtool_ops nicvf_ethtool_ops = {
.get_regs = nicvf_get_regs,
.get_coalesce = nicvf_get_coalesce,
.get_ringparam = nicvf_get_ringparam,
+ .set_ringparam = nicvf_set_ringparam,
.get_rxnfc = nicvf_get_rxnfc,
.set_rxnfc = nicvf_set_rxnfc,
.get_rxfh_key_size = nicvf_get_rxfh_key_size,
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index d2ac133..ac0390b 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -603,7 +603,7 @@ void nicvf_cmp_queue_config(struct nicvf *nic, struct queue_set *qs,
cq_cfg.ena = 1;
cq_cfg.reset = 0;
cq_cfg.caching = 0;
- cq_cfg.qsize = CMP_QSIZE;
+ cq_cfg.qsize = ilog2(qs->cq_len >> 10);
cq_cfg.avg_con = 0;
nicvf_queue_reg_write(nic, NIC_QSET_CQ_0_7_CFG, qidx, *(u64 *)&cq_cfg);
@@ -652,9 +652,12 @@ static void nicvf_snd_queue_config(struct nicvf *nic, struct queue_set *qs,
sq_cfg.ena = 1;
sq_cfg.reset = 0;
sq_cfg.ldwb = 0;
- sq_cfg.qsize = SND_QSIZE;
+ sq_cfg.qsize = ilog2(qs->sq_len >> 10);
sq_cfg.tstmp_bgx_intf = 0;
- sq_cfg.cq_limit = 0;
+ /* CQ's level at which HW will stop processing SQEs to avoid
+ * transmitting a pkt with no space in CQ to post CQE_TX.
+ */
+ sq_cfg.cq_limit = (CMP_QUEUE_PIPELINE_RSVD * 256) / qs->cq_len;
nicvf_queue_reg_write(nic, NIC_QSET_SQ_0_7_CFG, qidx, *(u64 *)&sq_cfg);
/* Set threshold value for interrupt generation */
@@ -816,11 +819,21 @@ int nicvf_config_data_transfer(struct nicvf *nic, bool enable)
{
bool disable = false;
struct queue_set *qs = nic->qs;
+ struct queue_set *pqs = nic->pnicvf->qs;
int qidx;
if (!qs)
return 0;
+ /* Take primary VF's queue lengths.
+ * This is needed to take queue lengths set from ethtool
+ * into consideration.
+ */
+ if (nic->sqs_mode && pqs) {
+ qs->cq_len = pqs->cq_len;
+ qs->sq_len = pqs->sq_len;
+ }
+
if (enable) {
if (nicvf_alloc_resources(nic))
return -ENOMEM;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index 9e21046..5cb84da 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -59,8 +59,9 @@
/* Default queue count per QS, its lengths and threshold values */
#define DEFAULT_RBDR_CNT 1
-#define SND_QSIZE SND_QUEUE_SIZE2
+#define SND_QSIZE SND_QUEUE_SIZE0
#define SND_QUEUE_LEN (1ULL << (SND_QSIZE + 10))
+#define MIN_SND_QUEUE_LEN (1ULL << (SND_QUEUE_SIZE0 + 10))
#define MAX_SND_QUEUE_LEN (1ULL << (SND_QUEUE_SIZE6 + 10))
#define SND_QUEUE_THRESH 2ULL
#define MIN_SQ_DESC_PER_PKT_XMIT 2
@@ -70,11 +71,18 @@
/* Keep CQ and SQ sizes same, if timestamping
* is enabled this equation will change.
*/
-#define CMP_QSIZE CMP_QUEUE_SIZE2
+#define CMP_QSIZE CMP_QUEUE_SIZE0
#define CMP_QUEUE_LEN (1ULL << (CMP_QSIZE + 10))
+#define MIN_CMP_QUEUE_LEN (1ULL << (CMP_QUEUE_SIZE0 + 10))
+#define MAX_CMP_QUEUE_LEN (1ULL << (CMP_QUEUE_SIZE6 + 10))
#define CMP_QUEUE_CQE_THRESH (NAPI_POLL_WEIGHT / 2)
#define CMP_QUEUE_TIMER_THRESH 80 /* ~2usec */
+/* No of CQEs that might anyway gets used by HW due to pipelining
+ * effects irrespective of PASS/DROP/LEVELS being configured
+ */
+#define CMP_QUEUE_PIPELINE_RSVD 544
+
#define RBDR_SIZE RBDR_SIZE0
#define RCV_BUF_COUNT (1ULL << (RBDR_SIZE + 13))
#define MAX_RCV_BUF_COUNT (1ULL << (RBDR_SIZE6 + 13))
@@ -93,8 +101,8 @@
* RED accepts pkt if unused CQE < 2304 & >= 2560
* DROPs pkts if unused CQE < 2304
*/
-#define RQ_PASS_CQ_LVL 160ULL
-#define RQ_DROP_CQ_LVL 144ULL
+#define RQ_PASS_CQ_LVL 192ULL
+#define RQ_DROP_CQ_LVL 184ULL
/* RED and Backpressure levels of RBDR for pkt reception
* For RBDR, level is a measure of fullness i.e 0x0 means empty
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] net: thunderx: Leave serdes lane config on 81/83xx to firmware
From: sunil.kovvuri @ 2017-01-25 12:06 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, linux-arm-kernel, Sunil Goutham
In-Reply-To: <1485345984-28163-1-git-send-email-sunil.kovvuri@gmail.com>
From: Sunil Goutham <sgoutham@cavium.com>
For DLMs and SLMs on 80/81/83xx, many lane configurations
across different boards are coming up. Also kernel doesn't have
any way to identify board type/info and since firmware does,
just get rid of figuring out lane to serdes config and take
whatever has been programmed by low level firmware.
Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 95 +++++------------------
1 file changed, 18 insertions(+), 77 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 2f85b64..dfb2bad 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -894,17 +894,15 @@ static void bgx_print_qlm_mode(struct bgx *bgx, u8 lmacid)
struct device *dev = &bgx->pdev->dev;
struct lmac *lmac;
char str[20];
- u8 dlm;
- if (lmacid > bgx->max_lmac)
+ if (!bgx->is_dlm && lmacid)
return;
lmac = &bgx->lmac[lmacid];
- dlm = (lmacid / 2) + (bgx->bgx_id * 2);
if (!bgx->is_dlm)
sprintf(str, "BGX%d QLM mode", bgx->bgx_id);
else
- sprintf(str, "BGX%d DLM%d mode", bgx->bgx_id, dlm);
+ sprintf(str, "BGX%d LMAC%d mode", bgx->bgx_id, lmacid);
switch (lmac->lmac_type) {
case BGX_MODE_SGMII:
@@ -990,7 +988,6 @@ static void lmac_set_training(struct bgx *bgx, struct lmac *lmac, int lmacid)
static void bgx_set_lmac_config(struct bgx *bgx, u8 idx)
{
struct lmac *lmac;
- struct lmac *olmac;
u64 cmr_cfg;
u8 lmac_type;
u8 lane_to_sds;
@@ -1010,62 +1007,26 @@ static void bgx_set_lmac_config(struct bgx *bgx, u8 idx)
return;
}
- /* On 81xx BGX can be split across 2 DLMs
- * firmware programs lmac_type of LMAC0 and LMAC2
+ /* For DLMs or SLMs on 80/81/83xx so many lane configurations
+ * are possible and vary across boards. Also Kernel doesn't have
+ * any way to identify board type/info and since firmware does,
+ * just take lmac type and serdes lane config as is.
*/
- if ((idx == 0) || (idx == 2)) {
- cmr_cfg = bgx_reg_read(bgx, idx, BGX_CMRX_CFG);
- lmac_type = (u8)((cmr_cfg >> 8) & 0x07);
- lane_to_sds = (u8)(cmr_cfg & 0xFF);
- /* Check if config is not reset value */
- if ((lmac_type == 0) && (lane_to_sds == 0xE4))
- lmac->lmac_type = BGX_MODE_INVALID;
- else
- lmac->lmac_type = lmac_type;
- lmac_set_training(bgx, lmac, lmac->lmacid);
- lmac_set_lane2sds(bgx, lmac);
-
- olmac = &bgx->lmac[idx + 1];
- /* Check if other LMAC on the same DLM is already configured by
- * firmware, if so use the same config or else set as same, as
- * that of LMAC 0/2.
- * This check is needed as on 80xx only one lane of each of the
- * DLM of BGX0 is used, so have to rely on firmware for
- * distingushing 80xx from 81xx.
- */
- cmr_cfg = bgx_reg_read(bgx, idx + 1, BGX_CMRX_CFG);
- lmac_type = (u8)((cmr_cfg >> 8) & 0x07);
- lane_to_sds = (u8)(cmr_cfg & 0xFF);
- if ((lmac_type == 0) && (lane_to_sds == 0xE4)) {
- olmac->lmac_type = lmac->lmac_type;
- lmac_set_lane2sds(bgx, olmac);
- } else {
- olmac->lmac_type = lmac_type;
- olmac->lane_to_sds = lane_to_sds;
- }
- lmac_set_training(bgx, olmac, olmac->lmacid);
- }
-}
-
-static bool is_dlm0_in_bgx_mode(struct bgx *bgx)
-{
- struct lmac *lmac;
-
- if (!bgx->is_dlm)
- return true;
-
- lmac = &bgx->lmac[0];
- if (lmac->lmac_type == BGX_MODE_INVALID)
- return false;
-
- return true;
+ cmr_cfg = bgx_reg_read(bgx, idx, BGX_CMRX_CFG);
+ lmac_type = (u8)((cmr_cfg >> 8) & 0x07);
+ lane_to_sds = (u8)(cmr_cfg & 0xFF);
+ /* Check if config is reset value */
+ if ((lmac_type == 0) && (lane_to_sds == 0xE4))
+ lmac->lmac_type = BGX_MODE_INVALID;
+ else
+ lmac->lmac_type = lmac_type;
+ lmac->lane_to_sds = lane_to_sds;
+ lmac_set_training(bgx, lmac, lmac->lmacid);
}
static void bgx_get_qlm_mode(struct bgx *bgx)
{
struct lmac *lmac;
- struct lmac *lmac01;
- struct lmac *lmac23;
u8 idx;
/* Init all LMAC's type to invalid */
@@ -1081,29 +1042,9 @@ static void bgx_get_qlm_mode(struct bgx *bgx)
if (bgx->lmac_count > bgx->max_lmac)
bgx->lmac_count = bgx->max_lmac;
- for (idx = 0; idx < bgx->max_lmac; idx++)
- bgx_set_lmac_config(bgx, idx);
-
- if (!bgx->is_dlm || bgx->is_rgx) {
- bgx_print_qlm_mode(bgx, 0);
- return;
- }
-
- if (bgx->lmac_count) {
- bgx_print_qlm_mode(bgx, 0);
- bgx_print_qlm_mode(bgx, 2);
- }
-
- /* If DLM0 is not in BGX mode then LMAC0/1 have
- * to be configured with serdes lanes of DLM1
- */
- if (is_dlm0_in_bgx_mode(bgx) || (bgx->lmac_count > 2))
- return;
for (idx = 0; idx < bgx->lmac_count; idx++) {
- lmac01 = &bgx->lmac[idx];
- lmac23 = &bgx->lmac[idx + 2];
- lmac01->lmac_type = lmac23->lmac_type;
- lmac01->lane_to_sds = lmac23->lane_to_sds;
+ bgx_set_lmac_config(bgx, idx);
+ bgx_print_qlm_mode(bgx, idx);
}
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 2/3] net: phy: leds: Break dependency of phy.h on phy_led_triggers.h
From: Andrew Lunn @ 2017-01-25 12:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, Florian Fainelli, Zach Brown, Volodymyr Bendiuga,
Magnus Öberg, netdev, linux-renesas-soc, linux-kernel
In-Reply-To: <1485340790-10785-3-git-send-email-geert+renesas@glider.be>
On Wed, Jan 25, 2017 at 11:39:49AM +0100, Geert Uytterhoeven wrote:
> <linux/phy.h> includes <linux/phy_led_triggers.h>, which is not really
> needed. Drop the include from <linux/phy.h>, and add it to all users
> that didn't include it explicitly.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/3] net: phy: leds: Fix truncated LED trigger names
From: Andrew Lunn @ 2017-01-25 12:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, Florian Fainelli, Zach Brown, Volodymyr Bendiuga,
Magnus Öberg, netdev, linux-renesas-soc, linux-kernel
In-Reply-To: <1485340790-10785-4-git-send-email-geert+renesas@glider.be>
On Wed, Jan 25, 2017 at 11:39:50AM +0100, Geert Uytterhoeven wrote:
> Commit 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and
> bus_id") increased the size of MII bus IDs, but forgot to update the
> private definition in <linux/phy_led_triggers.h>.
> This may cause:
> 1. Truncation of LED trigger names,
> 2. Duplicate LED trigger names,
> 3. Failures registering LED triggers,
> 4. Crashes due to bad error handling in the LED trigger failure path.
>
> To fix this, and prevent the definitions going out of sync again in the
> future, let the PHY LED trigger code use the existing MII_BUS_ID_SIZE
> definition.
>
> Example:
> - Before I had triggers "ee700000.etherne:01:100Mbps" and
> "ee700000.etherne:01:10Mbps",
> - After the increase of MII_BUS_ID_SIZE, both became
> "ee700000.ethernet-ffffffff:01:" => FAIL,
> - Now, the triggers are "ee700000.ethernet-ffffffff:01:100Mbps" and
> "ee700000.ethernet-ffffffff:01:10Mbps", which are unique again.
>
> Fixes: 4567d686f5c6d955 ("phy: increase size of MII_BUS_ID_SIZE and bus_id")
> Fixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy link state change")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Michal Hocko @ 2017-01-25 13:09 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Kees Cook, Andrew Morton, David Rientjes, Mel Gorman,
Johannes Weiner, Al Viro, Linux-MM, LKML, Martin Schwidefsky,
Heiko Carstens, Herbert Xu, Anton Vorontsov, Colin Cross,
Tony Luck, Rafael J. Wysocki, Ben Skeggs, Kent Overstreet,
Santosh Raspatur, Hariprasad S, Tariq Toukan
In-Reply-To: <a4b4e2f4-f730-4f1d-7f41-36ba0d34f1a6@suse.cz>
On Wed 25-01-17 12:15:59, Vlastimil Babka wrote:
> On 01/24/2017 04:00 PM, Michal Hocko wrote:
> > > > Well, I am not opposed to kvmalloc_array but I would argue that this
> > > > conversion cannot introduce new overflow issues. The code would have
> > > > to be broken already because even though kmalloc_array checks for the
> > > > overflow but vmalloc fallback doesn't...
> > >
> > > Yeah I agree, but if some of the places were really wrong, after the
> > > conversion we won't see them anymore.
> > >
> > > > If there is a general interest for this API I can add it.
> > >
> > > I think it would be better, yes.
> >
> > OK, fair enough. I will fold the following into the original patch. I
> > was little bit reluctant to create kvcalloc so I've made the original
> > callers more talkative and added | __GFP_ZERO.
>
> Fair enough,
>
> > To be honest I do not
> > really like how kcalloc...
>
> how kcalloc what?
how kcalloc hides the GFP_ZERO and the name doesn't reflect that.
> [...]
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index cdc55d5ee4ad..eca16612b1ae 100644
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -712,10 +712,7 @@ EXPORT_SYMBOL(xt_check_entry_offsets);
> > */
> > unsigned int *xt_alloc_entry_offsets(unsigned int size)
> > {
> > - if (size < (SIZE_MAX / sizeof(unsigned int)))
> > - return kvzalloc(size * sizeof(unsigned int), GFP_KERNEL);
> > -
> > - return NULL;
> > + return kvmalloc_array(size * sizeof(unsigned int), GFP_KERNEL | __GFP_ZERO);
>
> This one wouldn't compile.
fixed, thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: NAPI on USB network drivers
From: Oliver Hartkopp @ 2017-01-25 13:33 UTC (permalink / raw)
To: Hayes Wang, Oliver Neukum
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB201A134A7-JIZ+AM9kKNzKeZCINmmWEypo8c9IxeqyAjHCUHv49ws@public.gmane.org>
On 01/25/2017 10:39 AM, Hayes Wang wrote:
> Oliver Neukum [mailto:oneukum-IBi9RG/b67k@public.gmane.org]
>> Sent: Wednesday, January 25, 2017 5:35 PM
> [...]
>> looking at r8152 I noticed that it uses NAPI. I never considered
>> this for the generic USB networking code as you cannot disable
>> interrupts for USB. Is it still worth it? What are the benefits?
>
> You could use napi_gro_receive() and it influences the performance.
Another positive effect with NAPI is that you won't face out-of-order
ethernet frames as you get with non-NAPI drivers, e.g. ax88179_178a
http://marc.info/?l=linux-can&m=148049063812807&w=2
We have the issue with CAN drivers where all USB drivers and >90% of the
I/O mapped drivers do not use NAPI.
I wonder whether it makes sense to add NAPI to a driver which only has
ONE RX buffer ... but when searching for a solution for o-o-o frames I
was always pointed to NAPI.
Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* ip link SR-IOV VF MAC address disparity
From: Leon Goldberg @ 2017-01-25 13:34 UTC (permalink / raw)
To: netdev; +Cc: Dan Kenigsberg, Edward Haas
Hey,
Using ip link to retrieve the MAC addresses of some SR-IOV virtual
functions, I'm receiving mixed results:
[root@nari05 sys]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq
master ovirtmgmt state UP mode DEFAULT qlen 1000
link/ether 78:e7:d1:e4:9b:64 brd ff:ff:ff:ff:ff:ff
3: enp2s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq master test1
state DOWN mode DEFAULT qlen 1000
link/ether 78:e7:d1:e4:9b:65 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 2 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 3 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 4 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
4: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP mode DEFAULT
link/ether 78:e7:d1:e4:9b:64 brd ff:ff:ff:ff:ff:ff
5: test1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN mode DEFAULT
link/ether 78:e7:d1:e4:9b:65 brd ff:ff:ff:ff:ff:ff
11: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT
link/ether 5e:b4:ac:5c:b9:a1 brd ff:ff:ff:ff:ff:ff
37: enp2s16f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT qlen 1000
link/ether 00:00:00:00:00:02 brd ff:ff:ff:ff:ff:ff
38: enp2s16f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT qlen 1000
link/ether d6:ee:45:57:c0:39 brd ff:ff:ff:ff:ff:ff
39: enp2s16f5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT qlen 1000
link/ether 4a:2c:25:42:97:4a brd ff:ff:ff:ff:ff:ff
40: enp2s16f7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT qlen 1000
link/ether c2:fe:2f:5e:f5:e8 brd ff:ff:ff:ff:ff:ff
41: enp2s17f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
mode DEFAULT qlen 1000
link/ether e6:31:a9:59:5f:ad brd ff:ff:ff:ff:ff:ff
enp2s0f1 is the physical function; enp2s1f* are the interfaces to the
virtual functions.
Essentially, I have 2 questions:
1) What is the difference between the entries under the physical
function and the interfaces?
2) How should I retrieve the correct MAC addresses? I'm aware of
/sys/.../<vf>/net/address, but I am now not sure it is the correct
source.
Thanks,
Leon
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Ilya Dryomov @ 2017-01-25 13:40 UTC (permalink / raw)
To: Michal Hocko
Cc: Vlastimil Babka, Kees Cook, Andrew Morton, David Rientjes,
Mel Gorman, Johannes Weiner, Al Viro, Linux-MM, LKML,
Martin Schwidefsky, Heiko Carstens, Herbert Xu, Anton Vorontsov,
Colin Cross, Tony Luck, Rafael J. Wysocki, Ben Skeggs,
Kent Overstreet, Santosh Raspatur, Hariprasad S
In-Reply-To: <20170125130901.GP32377@dhcp22.suse.cz>
On Wed, Jan 25, 2017 at 2:09 PM, Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 25-01-17 12:15:59, Vlastimil Babka wrote:
>> On 01/24/2017 04:00 PM, Michal Hocko wrote:
>> > > > Well, I am not opposed to kvmalloc_array but I would argue that this
>> > > > conversion cannot introduce new overflow issues. The code would have
>> > > > to be broken already because even though kmalloc_array checks for the
>> > > > overflow but vmalloc fallback doesn't...
>> > >
>> > > Yeah I agree, but if some of the places were really wrong, after the
>> > > conversion we won't see them anymore.
>> > >
>> > > > If there is a general interest for this API I can add it.
>> > >
>> > > I think it would be better, yes.
>> >
>> > OK, fair enough. I will fold the following into the original patch. I
>> > was little bit reluctant to create kvcalloc so I've made the original
>> > callers more talkative and added | __GFP_ZERO.
>>
>> Fair enough,
>>
>> > To be honest I do not
>> > really like how kcalloc...
>>
>> how kcalloc what?
>
> how kcalloc hides the GFP_ZERO and the name doesn't reflect that.
The userspace calloc() is specified to zero memory, so I'd say the name
does reflect that.
Thanks,
Ilya
^ permalink raw reply
* [PATCH net-next] sfc: reduce severity of PIO buffer alloc failures
From: Bert Kenward @ 2017-01-25 13:48 UTC (permalink / raw)
To: Dave Miller
Cc: Tomáš Pilař, Solarflare Linux Maintainers, netdev
From: Tomáš Pilař <tpilar@solarflare.com>
PIO buffer allocation can fail for two valid reasons:
- we've run out of them (results in -ENOSPC)
- the NIC configuration doesn't support them (results in -EPERM)
Since both these failures are expected netif_err is excessive.
Signed-off-by: Bert Kenward <bkenward@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index dccbbd323616..7c53da28ad64 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -1170,7 +1170,13 @@ static int efx_ef10_dimension_resources(struct efx_nic *efx)
nic_data->piobuf_size / efx_piobuf_size);
rc = efx_ef10_alloc_piobufs(efx, n_piobufs);
- if (rc)
+ if (rc == -ENOSPC)
+ netif_dbg(efx, probe, efx->net_dev,
+ "out of PIO buffers; cannot allocate more\n");
+ else if (rc == -EPERM)
+ netif_dbg(efx, probe, efx->net_dev,
+ "not permitted to allocate PIO buffers\n");
+ else if (rc)
netif_err(efx, probe, efx->net_dev,
"failed to allocate PIO buffers (%d)\n", rc);
else
@@ -1317,8 +1323,14 @@ static int efx_ef10_init_nic(struct efx_nic *efx)
efx_ef10_free_piobufs(efx);
}
- /* Log an error on failure, but this is non-fatal */
- if (rc)
+ /* Log an error on failure, but this is non-fatal.
+ * Permission errors are less important - we've presumably
+ * had the PIO buffer licence removed.
+ */
+ if (rc == -EPERM)
+ netif_dbg(efx, drv, efx->net_dev,
+ "not permitted to restore PIO buffers\n");
+ else if (rc)
netif_err(efx, drv, efx->net_dev,
"failed to restore PIO buffers (%d)\n", rc);
nic_data->must_restore_piobufs = false;
--
2.7.4
^ permalink raw reply related
* [PATCH 14/23] tools lib bpf: Fix map offsets in relocation
From: Arnaldo Carvalho de Melo @ 2017-01-25 13:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Joe Stringer, Wang Nan, Alexei Starovoitov,
Daniel Borkmann, netdev, Arnaldo Carvalho de Melo
In-Reply-To: <20170125135350.22983-1-acme@kernel.org>
From: Joe Stringer <joe@ovn.org>
Commit 4708bbda5cb2 ("tools lib bpf: Fix maps resolution") attempted to
fix map resolution by identifying the number of symbols that point to
maps, and using this number to resolve each of the maps.
However, during relocation the original definition of the map size was
still in use. For up to two maps, the calculation was correct if there
was a small difference in size between the map definition in libbpf and
the one that the client library uses. However if the difference was
large, particularly if more than two maps were used in the BPF program,
the relocation would fail.
For example, when using a map definition with size 28, with three maps,
map relocation would count:
(sym_offset / sizeof(struct bpf_map_def) => map_idx)
(0 / 16 => 0), ie map_idx = 0
(28 / 16 => 1), ie map_idx = 1
(56 / 16 => 3), ie map_idx = 3
So, libbpf reports:
libbpf: bpf relocation: map_idx 3 large than 2
Fix map relocation by checking the exact offset of maps when doing
relocation.
Signed-off-by: Joe Stringer <joe@ovn.org>
[Allow different map size in an object]
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: netdev@vger.kernel.org
Fixes: 4708bbda5cb2 ("tools lib bpf: Fix maps resolution")
Link: http://lkml.kernel.org/r/20170123011128.26534-2-joe@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/lib/bpf/libbpf.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 84e6b35da4bd..671d5ad07cf1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -779,7 +779,7 @@ static int
bpf_program__collect_reloc(struct bpf_program *prog,
size_t nr_maps, GElf_Shdr *shdr,
Elf_Data *data, Elf_Data *symbols,
- int maps_shndx)
+ int maps_shndx, struct bpf_map *maps)
{
int i, nrels;
@@ -829,7 +829,15 @@ bpf_program__collect_reloc(struct bpf_program *prog,
return -LIBBPF_ERRNO__RELOC;
}
- map_idx = sym.st_value / sizeof(struct bpf_map_def);
+ /* TODO: 'maps' is sorted. We can use bsearch to make it faster. */
+ for (map_idx = 0; map_idx < nr_maps; map_idx++) {
+ if (maps[map_idx].offset == sym.st_value) {
+ pr_debug("relocation: find map %zd (%s) for insn %u\n",
+ map_idx, maps[map_idx].name, insn_idx);
+ break;
+ }
+ }
+
if (map_idx >= nr_maps) {
pr_warning("bpf relocation: map_idx %d large than %d\n",
(int)map_idx, (int)nr_maps - 1);
@@ -953,7 +961,8 @@ static int bpf_object__collect_reloc(struct bpf_object *obj)
err = bpf_program__collect_reloc(prog, nr_maps,
shdr, data,
obj->efile.symbols,
- obj->efile.maps_shndx);
+ obj->efile.maps_shndx,
+ obj->maps);
if (err)
return err;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 15/23] tools lib bpf: Define prog_type fns with macro
From: Arnaldo Carvalho de Melo @ 2017-01-25 13:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Joe Stringer, Alexei Starovoitov, Daniel Borkmann,
netdev, Arnaldo Carvalho de Melo
In-Reply-To: <20170125135350.22983-1-acme@kernel.org>
From: Joe Stringer <joe@ovn.org>
Turning this into a macro allows future prog types to be added with a
single line per type.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: netdev@vger.kernel.org
Link: http://lkml.kernel.org/r/20170123011128.26534-3-joe@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/lib/bpf/libbpf.c | 41 ++++++++++++++++-------------------------
1 file changed, 16 insertions(+), 25 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 671d5ad07cf1..371cb40a2304 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1428,37 +1428,28 @@ static void bpf_program__set_type(struct bpf_program *prog,
prog->type = type;
}
-int bpf_program__set_tracepoint(struct bpf_program *prog)
-{
- if (!prog)
- return -EINVAL;
- bpf_program__set_type(prog, BPF_PROG_TYPE_TRACEPOINT);
- return 0;
-}
-
-int bpf_program__set_kprobe(struct bpf_program *prog)
-{
- if (!prog)
- return -EINVAL;
- bpf_program__set_type(prog, BPF_PROG_TYPE_KPROBE);
- return 0;
-}
-
static bool bpf_program__is_type(struct bpf_program *prog,
enum bpf_prog_type type)
{
return prog ? (prog->type == type) : false;
}
-bool bpf_program__is_tracepoint(struct bpf_program *prog)
-{
- return bpf_program__is_type(prog, BPF_PROG_TYPE_TRACEPOINT);
-}
-
-bool bpf_program__is_kprobe(struct bpf_program *prog)
-{
- return bpf_program__is_type(prog, BPF_PROG_TYPE_KPROBE);
-}
+#define BPF_PROG_TYPE_FNS(NAME, TYPE) \
+int bpf_program__set_##NAME(struct bpf_program *prog) \
+{ \
+ if (!prog) \
+ return -EINVAL; \
+ bpf_program__set_type(prog, TYPE); \
+ return 0; \
+} \
+ \
+bool bpf_program__is_##NAME(struct bpf_program *prog) \
+{ \
+ return bpf_program__is_type(prog, TYPE); \
+} \
+
+BPF_PROG_TYPE_FNS(kprobe, BPF_PROG_TYPE_KPROBE);
+BPF_PROG_TYPE_FNS(tracepoint, BPF_PROG_TYPE_TRACEPOINT);
int bpf_map__fd(struct bpf_map *map)
{
--
2.9.3
^ permalink raw reply related
* [PATCH 16/23] tools lib bpf: Add set/is helpers for all prog types
From: Arnaldo Carvalho de Melo @ 2017-01-25 13:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Joe Stringer, Alexei Starovoitov, Daniel Borkmann,
netdev, Arnaldo Carvalho de Melo
In-Reply-To: <20170125135350.22983-1-acme@kernel.org>
From: Joe Stringer <joe@ovn.org>
These bpf_prog_types were exposed in the uapi but there were no
corresponding functions to set these types for programs in libbpf.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: netdev@vger.kernel.org
Link: http://lkml.kernel.org/r/20170123011128.26534-4-joe@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/lib/bpf/libbpf.c | 5 +++++
tools/lib/bpf/libbpf.h | 10 ++++++++++
2 files changed, 15 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 371cb40a2304..406838fa9c4f 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -1448,8 +1448,13 @@ bool bpf_program__is_##NAME(struct bpf_program *prog) \
return bpf_program__is_type(prog, TYPE); \
} \
+BPF_PROG_TYPE_FNS(socket_filter, BPF_PROG_TYPE_SOCKET_FILTER);
BPF_PROG_TYPE_FNS(kprobe, BPF_PROG_TYPE_KPROBE);
+BPF_PROG_TYPE_FNS(sched_cls, BPF_PROG_TYPE_SCHED_CLS);
+BPF_PROG_TYPE_FNS(sched_act, BPF_PROG_TYPE_SCHED_ACT);
BPF_PROG_TYPE_FNS(tracepoint, BPF_PROG_TYPE_TRACEPOINT);
+BPF_PROG_TYPE_FNS(xdp, BPF_PROG_TYPE_XDP);
+BPF_PROG_TYPE_FNS(perf_event, BPF_PROG_TYPE_PERF_EVENT);
int bpf_map__fd(struct bpf_map *map)
{
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index a5a8b86a06fe..2188ccdc0e2d 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -174,11 +174,21 @@ int bpf_program__nth_fd(struct bpf_program *prog, int n);
/*
* Adjust type of bpf program. Default is kprobe.
*/
+int bpf_program__set_socket_filter(struct bpf_program *prog);
int bpf_program__set_tracepoint(struct bpf_program *prog);
int bpf_program__set_kprobe(struct bpf_program *prog);
+int bpf_program__set_sched_cls(struct bpf_program *prog);
+int bpf_program__set_sched_act(struct bpf_program *prog);
+int bpf_program__set_xdp(struct bpf_program *prog);
+int bpf_program__set_perf_event(struct bpf_program *prog);
+bool bpf_program__is_socket_filter(struct bpf_program *prog);
bool bpf_program__is_tracepoint(struct bpf_program *prog);
bool bpf_program__is_kprobe(struct bpf_program *prog);
+bool bpf_program__is_sched_cls(struct bpf_program *prog);
+bool bpf_program__is_sched_act(struct bpf_program *prog);
+bool bpf_program__is_xdp(struct bpf_program *prog);
+bool bpf_program__is_perf_event(struct bpf_program *prog);
/*
* We don't need __attribute__((packed)) now since it is
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox