* Re: [PATCH] net: ethtool: avoid allocation failure for dump_regs
From: John W. Linville @ 2017-01-19 15:56 UTC (permalink / raw)
To: David Arcari; +Cc: David Miller, netdev, Johannes Berg, Kalle Valo
In-Reply-To: <20170119141508.GA6245@tuxdriver.com>
I forgot to Cc Johannes and Kalle...
On Thu, Jan 19, 2017 at 09:15:09AM -0500, John W. Linville wrote:
> On Thu, Jan 19, 2017 at 07:35:22AM -0500, David Arcari wrote:
> > On 01/18/2017 11:45 AM, David Miller wrote:
> > > From: David Arcari <darcari@redhat.com>
> > > Date: Wed, 18 Jan 2017 08:34:05 -0500
> > >
> > >> If the user executes 'ethtool -d' for an interface and the associated
> > >> get_regs_len() function returns 0, the user will see a call trace from
> > >> the vmalloc() call in ethtool_get_regs(). This patch modifies
> > >> ethtool_get_regs() to avoid the call to vmalloc when the size is zero.
> > >>
> > >> Signed-off-by: David Arcari <darcari@redhat.com>
> > > I think when the driver indicates this, it is equivalent to saying that
> > > the operation isn't supported.
> > >
> > > Also, this guards us against ->get_regs() methods that don't handle
> > > zero length requests properly. I see many which are going to do
> > > really terrible things in that situation.
> > >
> > > Therefore, if get_regs_len() returns zero, treat it the safe as if the
> > > ethtool operations were NULL.
> > >
> > > Thanks.
> >
> > That was actually the fix that I was originally considering, but it
> > turns out
> > there is a problem with it.
> >
> > I found that the vmalloc error was occurring because
> > ieee80211_get_regs_len() in
> > net/mac80211/ethtool.c was returning zero. The ieee80211_get_regs in
> > the same
> > file returns the hw version. It turns out that this information is used
> > by the
> > at76c50x-usb driver in the user space ethtool to report which HW variant
> > is in
> > use. Returning an error when regs_len() returns zero would break this
> > functionality.
> >
> > -Dave
>
> I'm responsible for this mess. The original idea was for various
> mac80211-based drivers to override the ethtool operation and provide
> their own dump operation, but the mac80211 crowd never embraced
> the idea.
>
> In the meantime, I added the default implementation which just
> passed-up wdev->wiphy->hw_version as the version info for a 0-length
> register dump. I then implemented a driver-specific regiser dump
> handler for userland ethtool that would interpret the hardware version
> information for the at76c50x-usb driver.
>
> So the net of it is, if we treat a return of 0 from get_regs_len()
> as "not supported", we break this one driver-specific feature for
> userland ethtool. Realistically, there are probably very few users
> to care. But I can't guarantee that the number is zero.
>
> Possible solutions:
>
> -- break userland ethtool for at76c50x-usb
> -- avoid 0-len allocation attempt (David Arcari's patch)
> -- make allocator accept a 0 length value w/o oops'ing
> -- change mac8011 code to return non-zero from get_regs_len()
>
> Thoughts? The last option holds a certain attraction, but I'm not
> sure how to make it useful...?
>
> John
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH v3 net-next] phy: increase size of MII_BUS_ID_SIZE and bus_id
From: Volodymyr Bendiuga @ 2017-01-19 16:05 UTC (permalink / raw)
To: f.fainelli, andrew, netdev, volodymyr.bendiuga
Cc: Volodymyr Bendiuga, Magnus Öberg
Some bus names are pretty long and do not fit into
17 chars. Increase therefore MII_BUS_ID_SIZE and
phy_fixup.bus_id to larger number. Now mii_bus.id
can host larger name.
Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
Signed-off-by: Magnus Öberg <magnus.oberg@westermo.se>
---
include/linux/phy.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f7d95f6..5c9d252 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -158,11 +158,7 @@ static inline const char *phy_modes(phy_interface_t interface)
/* Used when trying to connect to a specific phy (mii bus id:phy device id) */
#define PHY_ID_FMT "%s:%02x"
-/*
- * Need to be a little smaller than phydev->dev.bus_id to leave room
- * for the ":%02x"
- */
-#define MII_BUS_ID_SIZE (20 - 3)
+#define MII_BUS_ID_SIZE 61
/* Or MII_ADDR_C45 into regnum for read/write on mii_bus to enable the 21 bit
IEEE 802.3ae clause 45 addressing mode used by 10GIGE phy chips. */
@@ -632,7 +628,7 @@ struct phy_driver {
/* A Structure for boards to register fixups with the PHY Lib */
struct phy_fixup {
struct list_head list;
- char bus_id[20];
+ char bus_id[MII_BUS_ID_SIZE + 3];
u32 phy_uid;
u32 phy_uid_mask;
int (*run)(struct phy_device *phydev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH iproute2 v4 3/4] ifstat: Add 64 bits based stats to extended statistics
From: Roopa Prabhu @ 2017-01-19 16:06 UTC (permalink / raw)
To: Nogah Frankel
Cc: Stephen Hemminger, netdev@vger.kernel.org, roszenrami@gmail.com,
Jiri Pirko, Ido Schimmel, Elad Raz, Yotam Gigi, Or Gerlitz
In-Reply-To: <DB5PR05MB1895D7CFBE9E127AAAE672DBAC7E0@DB5PR05MB1895.eurprd05.prod.outlook.com>
On 1/19/17, 7:21 AM, Nogah Frankel wrote:
>> -----Original Message-----
>> From: Nogah Frankel
>> Sent: Sunday, January 15, 2017 3:55 PM
>> To: 'Stephen Hemminger' <stephen@networkplumber.org>
>> Cc: netdev@vger.kernel.org; roszenrami@gmail.com; roopa@cumulusnetworks.com; Jiri
>> Pirko <jiri@mellanox.com>; Ido Schimmel <idosch@mellanox.com>; Elad Raz
>> <eladr@mellanox.com>; Yotam Gigi <yotamg@mellanox.com>; Or Gerlitz
>> <ogerlitz@mellanox.com>
>> Subject: RE: [PATCH iproute2 v4 3/4] ifstat: Add 64 bits based stats to extended statistics
>>
>>
>>
>>> -----Original Message-----
>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>>> Sent: Friday, January 13, 2017 3:44 AM
>>> To: Nogah Frankel <nogahf@mellanox.com>
>>> Cc: netdev@vger.kernel.org; roszenrami@gmail.com; roopa@cumulusnetworks.com;
>> Jiri
>>> Pirko <jiri@mellanox.com>; Ido Schimmel <idosch@mellanox.com>; Elad Raz
>>> <eladr@mellanox.com>; Yotam Gigi <yotamg@mellanox.com>; Or Gerlitz
>>> <ogerlitz@mellanox.com>
>>> Subject: Re: [PATCH iproute2 v4 3/4] ifstat: Add 64 bits based stats to extended statistics
>>>
>>> On Thu, 12 Jan 2017 15:49:50 +0200
>>> Nogah Frankel <nogahf@mellanox.com> wrote:
>>>
>>>> The default stats for ifstat are 32 bits based.
>>>> The kernel supports 64 bits based stats. (They are returned in struct
>>>> rtnl_link_stats64 which is an exact copy of struct rtnl_link_stats, in
>>>> which the "normal" stats are returned, but with fields of u64 instead of
>>>> u32). This patch adds them as an extended stats.
>>>>
>>>> It is read with filter type IFLA_STATS_LINK_64 and no sub type.
>>>>
>>>> It is under the name 64bits
>>>> (or any shorten of it as "64")
>>>>
>>>> For example:
>>>> ifstat -x 64bit
>>>>
>>>> Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
>>>> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>>> Other commands (like ip link) always use the 64 bit statistics if available
>>> from the device. I see no reason that ifstat needs to be different.
>>>
>> Do you mean to change the default ifstat results to be 64 bits based?
>> I tried it in the first version, but Roopa commented that it was not a good idea.
>> She said they tried it in the past and it caused backward compatibilities problems.
>> (Or maybe I didn't understand correctly)
> So, can I leave the default ifstat results to be 32 bits based, for the time being?
>
>From past discussions: Moving the default to 64bit has compat issues with the old history file.
There is a way to make it work by using a new file header (to indicate that it is 64 bit) in
a freshly created history file and also check this header before dumping stats into the history file.
ie maintain backward compat without introducing a new option. It is doable.
One approach is, you can drop the 64bit option from this series and
try updating the default to 64 bit (with compat handling code) in a later series.
^ permalink raw reply
* Re: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM
From: Nicolas Ferre @ 2017-01-19 16:07 UTC (permalink / raw)
To: Andrei Pistirica, netdev, linux-kernel, linux-arm-kernel, davem,
harinikatakamlinux, harini.katakam
Cc: boris.brezillon, rafalo, alexandre.belloni, michals, tbultel,
anirudh, punnaia, richardcochran
In-Reply-To: <1484841375-11420-1-git-send-email-andrei.pistirica@microchip.com>
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>
Thanks, 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
* Re: [PATCH] net/mlx5e: Remove unused variable
From: David Miller @ 2017-01-19 16:15 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, galp-VPRAkNaXOzVWk0Htik3J/w,
tariqt-VPRAkNaXOzVWk0Htik3J/w, maorg-VPRAkNaXOzVWk0Htik3J/w,
eranbe-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170119093401.2582672-1-arnd-r2nGTMty4D4@public.gmane.org>
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Date: Thu, 19 Jan 2017 10:33:29 +0100
> A cleanup removed the only user of this variable
>
> mlx5/core/en_ethtool.c: In function 'mlx5e_set_channels':
> mlx5/core/en_ethtool.c:546:6: error: unused variable 'ncv' [-Werror=unused-variable]
>
> Let's remove the declaration as well.
>
> Fixes: 639e9e94160e ("net/mlx5e: Remove unnecessary checks when setting num channels")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] ipv6: addrconf: Avoid addrconf_disable_change() using RCU read-side lock
From: David Miller @ 2017-01-19 16:09 UTC (permalink / raw)
To: wangkefeng.wang
Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
dingtianhong, weiyongjun1, guohanjun
In-Reply-To: <1484814381-61150-1-git-send-email-wangkefeng.wang@huawei.com>
From: Kefeng Wang <wangkefeng.wang@huawei.com>
Date: Thu, 19 Jan 2017 16:26:21 +0800
> Just like commit 4acd4945cd1e ("ipv6: addrconf: Avoid calling
> netdevice notifiers with RCU read-side lock"), it is unnecessary
> to make addrconf_disable_change() use RCU iteration over the
> netdev list, since it already holds the RTNL lock, or we may meet
> Illegal context switch in RCU read-side critical section.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/sched: cls_flower: reduce fl_change stack size
From: David Miller @ 2017-01-19 16:23 UTC (permalink / raw)
To: arnd
Cc: jhs, jiri, hadarh, amir, paulb, ogerlitz, simon.horman, roid,
netdev, linux-kernel
In-Reply-To: <20170119094551.2780983-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 19 Jan 2017 10:45:31 +0100
> The new ARP support has pushed the stack size over the edge on ARM,
> as there are two large objects on the stack in this function (mask
> and tb) and both have now grown a bit more:
>
> net/sched/cls_flower.c: In function 'fl_change':
> net/sched/cls_flower.c:928:1: error: the frame size of 1072 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> We can solve this by dynamically allocating one or both of them.
> I first tried to do it just for the mask, but that only saved
> 152 bytes on ARM, while this version just does it for the 'tb'
> array, bringing the stack size back down to 664 bytes.
>
> Fixes: 99d31326cbe6 ("net/sched: cls_flower: Support matching on ARP")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: Initializing MAC address at run-time
From: Uwe Kleine-König @ 2017-01-19 16:26 UTC (permalink / raw)
To: Mason
Cc: Mark Rutland, DT, Arnd Bergmann, Kevin Hilman, netdev,
Thibaud Cornic, Linux ARM
In-Reply-To: <79fef293-74ec-dece-1941-747cd55f1ca2@free.fr>
Hello,
On Thu, Jan 19, 2017 at 04:31:56PM +0100, Mason wrote:
> Do you agree that such boot loader would execute code that is roughly
> identical to the one posted for illustration purposes?
> 1. find the MAC address to use for eth0
> 2. find the eth0 node in the DT
> 3. insert the right prop in the eth0 node
yes.
> In which case, it seems a waste to add the DT library to the boot
> loader, when the operation can be done in Linux, which requires the
> DT library anyway. (Additionally, adding DT support to some custom
> legacy boot loader might be a complex task.)
With this reasoning you can discuss away the bootloader. Linux relies on
a bootloader for a reason. It's there to initialize RAM and some further
things that Linux might not be able to and provide a machine description
to Linux (either in form of a dtb or an ATAG list) such that Linux
doesn't need to fiddle with machine specific stuff in early init code.
> > c) Adapt the dtb before it is written to the boot medium.
>
> This is not applicable, as the DTB is not written to the board.
Ah, then adapt the dtb before it is put into the tftp folder.
> > d) Let the bootloader configure the device and teach the driver to pick
> > up the mac from the device's address space.
>
> I'm not sure what you call "the device" ?
The network device. IIRC the fec driver checks if there is something
configured in the two registers configuring the MAC before falling back
to a random MAC.
> > e) Accept that the mac address is random during development, and make
> > Userspace configure the MAC address, which is early enough for
> > production use.
>
> During development, some devs configure the DHCP server to provide
> a specific uImage and/or rootfs to their board, based on the MAC
> address. This scheme would fall apart with a random MAC.
>
> > Not sure d) is considered ok today, but some drivers have this feature.
> > I'd say b) is the best choice.
>
> In my mind, doing it early in Linux is similar in spirit to doing it
> at the boot loader stage, in that it's neatly separated from the rest
> of the setup.
Sure you can do this. But it won't be accepted mainline for sure.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v3] net/irda: fix lockdep annotation
From: David Miller @ 2017-01-19 16:27 UTC (permalink / raw)
To: dvyukov; +Cc: davej, samuel, glider, andreyknvl, netdev
In-Reply-To: <CACT4Y+Yx3wVAgxJRYKMOYM419NTSc9naSxUVfwCb21kjvAnF6Q@mail.gmail.com>
From: Dmitry Vyukov <dvyukov@google.com>
Date: Thu, 19 Jan 2017 11:05:36 +0100
> Thanks for looking into it! This particular issue bothers my fuzzers
> considerably. I agree that removing recursion is better.
> So do how we proceed? Will you mail this as a real patch?
Someone needs to test this:
diff --git a/net/irda/irqueue.c b/net/irda/irqueue.c
index acbe61c..160dc89 100644
--- a/net/irda/irqueue.c
+++ b/net/irda/irqueue.c
@@ -383,9 +383,6 @@ EXPORT_SYMBOL(hashbin_new);
* for deallocating this structure if it's complex. If not the user can
* just supply kfree, which should take care of the job.
*/
-#ifdef CONFIG_LOCKDEP
-static int hashbin_lock_depth = 0;
-#endif
int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
{
irda_queue_t* queue;
@@ -396,22 +393,27 @@ int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
IRDA_ASSERT(hashbin->magic == HB_MAGIC, return -1;);
/* Synchronize */
- if ( hashbin->hb_type & HB_LOCK ) {
- spin_lock_irqsave_nested(&hashbin->hb_spinlock, flags,
- hashbin_lock_depth++);
- }
+ if (hashbin->hb_type & HB_LOCK)
+ spin_lock_irqsave(&hashbin->hb_spinlock, flags);
/*
* Free the entries in the hashbin, TODO: use hashbin_clear when
* it has been shown to work
*/
for (i = 0; i < HASHBIN_SIZE; i ++ ) {
- queue = dequeue_first((irda_queue_t**) &hashbin->hb_queue[i]);
- while (queue ) {
- if (free_func)
- (*free_func)(queue);
- queue = dequeue_first(
- (irda_queue_t**) &hashbin->hb_queue[i]);
+ while (1) {
+ queue = dequeue_first((irda_queue_t**) &hashbin->hb_queue[i]);
+
+ if (!queue)
+ break;
+
+ if (free_func) {
+ if (hashbin->hb_type & HB_LOCK)
+ spin_unlock_irqrestore(&hashbin->hb_spinlock, flags);
+ free_func(queue);
+ if (hashbin->hb_type & HB_LOCK)
+ spin_lock_irqsave(&hashbin->hb_spinlock, flags);
+ }
}
}
@@ -420,12 +422,8 @@ int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
hashbin->magic = ~HB_MAGIC;
/* Release lock */
- if ( hashbin->hb_type & HB_LOCK) {
+ if (hashbin->hb_type & HB_LOCK)
spin_unlock_irqrestore(&hashbin->hb_spinlock, flags);
-#ifdef CONFIG_LOCKDEP
- hashbin_lock_depth--;
-#endif
- }
/*
* Free the hashbin structure
^ permalink raw reply related
* Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Greg KH @ 2017-01-19 16:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Jason Cooper, Vivien Didelot, netdev,
Russell King, open list, Gregory Clement, David S. Miller,
moderated list:ARM SUB-ARCHITECTURES, Sebastian Hesselbarth
In-Reply-To: <20170119145315.GD21805@lunn.ch>
On Thu, Jan 19, 2017 at 03:53:15PM +0100, Andrew Lunn wrote:
> > > > struct dsa_platform_data {
> > > > /*
> > > > * Reference to a Linux network interface that connects
> > > > * to the root switch chip of the tree.
> > > > */
> > > > struct device *netdev;
> >
> > This I think is the oddest thing, why do you need to have the "root
> > switch" here? You seem to have dropped the next value in this
> > structure:
> > struct net_device *of_netdev;
>
> We are implementing platform_data for devices which don't support
> device tree. When using OF, we don't have any of these issues. We can
> go straight to the device.
>
> It is a bit convoluted, but look at
> arch/arm/mach-orion5x/rd88f5181l-ge-setup.c. It defines the start of
> the dsa_platform_data in that file. It then gets passed through
> common.c: orion5x_eth_switch_init() to
> arch/arm/plat-orion/common.c:orion_ge00_switch_init() :
>
> void __init orion_ge00_switch_init(struct dsa_platform_data *d)
> {
> int i;
>
> d->netdev = &orion_ge00.dev;
> for (i = 0; i < d->nr_chips; i++)
> d->chip[i].host_dev = &orion_ge_mvmdio.dev;
>
> platform_device_register_data(NULL, "dsa", 0, d, sizeof(d));
> }
>
> Where we have
>
> static struct platform_device orion_ge00 = {
> .name = MV643XX_ETH_NAME,
> .id = 0,
> .num_resources = 1,
> .resource = orion_ge00_resources,
> .dev = {
> .coherent_dma_mask = DMA_BIT_MASK(32),
> },
> };
>
> So this is the platform device for the Ethernet device. We cannot go
> to the net_device, because it does not exist until this Ethernet
> platform device is instantiated.
Ok, fine, but why isn't the ethernet device a child of this platform
device? Why is it floating around somewhere else? You don't see that
happening for other devices.
> > Shouldn't you have a bus for RGMII devices? Is that the real problem
> > here, you don't have a representation for your RGMII "bus" with a
> > controller to bundle everything under (like a USB host controller, it
> > bridges from one bus to another).
>
> RGMII is not a bus. It is a point to point link.
That's fine, but you have multiple devices talking across it, so in the
kernel driver model "naming", it's a bus. Anything can be a bus, it's
just a way to group together devices of the same type.
> Normally, it is
> between the Ethernet MAC and the Ethernet PHY. But you can also have
> it between an Ethernet MAC and another Ethernet MAC. I'm not sure
> describing this is a bus would be practical. It would mean every
> ethernet driver also becomes a bus driver!
Instead of a custom platform device driver, yes. Is that a big deal?
How many do you have?
> Every Ethernet PHY would become a bus device. That is a huge change,
> for a few legacy boards which are not getting converted to device
> tree.
How many different drivers are we talking about here?
> > If so, why is eth1 not below f1072004.mdio-mi in the heirachy already?
>
> See the initial diagram above. The switch has two parents. It hangs of
> an MDIO bus, and you would like to make RGMII also a bus. Can the
> device model handle that? I thought it was a tree, not a graph?
It is a tree, you are correct. But right now you are picking and
choosing where you want to put that network device. Why not put it over
on the mdio bus? Or, like I mentioned, make it a custom bus where you
can properly show this relationship, not just in a generic "let's jump
to the parent and poke around randomly."
Again, it's that last sentance that I object the most to here. You all
keep ignoring it for some reason...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] net: atm: Fix build error when !CONFIG_PROC_FS
From: David Miller @ 2017-01-19 16:32 UTC (permalink / raw)
To: augustocaringi; +Cc: jiri, idosch, netdev, linux-kernel
In-Reply-To: <1484823626-8150-1-git-send-email-augustocaringi@gmail.com>
From: Augusto Mecking Caringi <augustocaringi@gmail.com>
Date: Thu, 19 Jan 2017 11:00:12 +0000
> When CONFIG_ATM_CLIP is set and CONFIG_PROC_FS is not set, the building
> was failing whith the error:
>
> net/atm/clip.c: In function ‘atm_clip_exit’:
> net/atm/clip.c:933:27: error: ‘atm_proc_root’ undeclared (first use in
> this function)
> remove_proc_entry("arp", atm_proc_root);
> ^
>
> Fix it by putting the proc cleanup code inside a #ifdef CONFIG_PROC_FS
> block.
>
> Signed-off-by: Augusto Mecking Caringi <augustocaringi@gmail.com>
When CONFIG_PROC_FS is not defined, remove_proc_entry is defined as the
macro:
#define remove_proc_entry(name, parent) do {} while (0)
Therefore it is impossible for atm_proc_root to be referened in any way.
The fallback macro is designed exactly so that ugly ifdefs like the one
you are proposing aren't necessary.
I'm not applyiing this patch, something else is happening in your tree.
^ permalink raw reply
* [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
From: Vineeth Remanan Pillai @ 2017-01-19 16:35 UTC (permalink / raw)
To: David Miller, netdev, linux-kernel; +Cc: vineethp
In-Reply-To: <1484771149-12699-1-git-send-email-vineethp@u480fcf3b67f557f68df1.ant.amazon.com>
From: Vineeth Remanan Pillai <vineethp@amazon.com>
During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.
The issue is with the retry logic which schedules the timer if the
created slots are less than NET_RX_SLOTS_MIN. The count of new request
slots to be pushed are calculated as a difference between new req_prod
and rsp_cons which could be more than the actual slots, if there are
unconsumed responses.
The fix is to calculate the count of newly created slots as the
difference between new req_prod and old req_prod.
Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
Changes in v2:
- Removed the old implementation of enabling polling on
skb allocation error.
- Corrected the refill timer logic to schedule when newly
created slots since last push is less than NET_RX_SLOTS_MIN.
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 40f26b6..2c7c29f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -321,7 +321,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
queue->rx.req_prod_pvt = req_prod;
/* Not enough requests? Try again later. */
- if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+ if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {
mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
return;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Russell King - ARM Linux @ 2017-01-19 16:35 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Lunn, Florian Fainelli, Jason Cooper, Vivien Didelot,
netdev, open list, Gregory Clement, David S. Miller,
moderated list:ARM SUB-ARCHITECTURES, Sebastian Hesselbarth
In-Reply-To: <20170119163013.GA22777@kroah.com>
On Thu, Jan 19, 2017 at 05:30:13PM +0100, Greg KH wrote:
> On Thu, Jan 19, 2017 at 03:53:15PM +0100, Andrew Lunn wrote:
> > > > > struct dsa_platform_data {
> > > > > /*
> > > > > * Reference to a Linux network interface that connects
> > > > > * to the root switch chip of the tree.
> > > > > */
> > > > > struct device *netdev;
> > >
> > > This I think is the oddest thing, why do you need to have the "root
> > > switch" here? You seem to have dropped the next value in this
> > > structure:
> > > struct net_device *of_netdev;
> >
> > We are implementing platform_data for devices which don't support
> > device tree. When using OF, we don't have any of these issues. We can
> > go straight to the device.
> >
> > It is a bit convoluted, but look at
> > arch/arm/mach-orion5x/rd88f5181l-ge-setup.c. It defines the start of
> > the dsa_platform_data in that file. It then gets passed through
> > common.c: orion5x_eth_switch_init() to
> > arch/arm/plat-orion/common.c:orion_ge00_switch_init() :
> >
> > void __init orion_ge00_switch_init(struct dsa_platform_data *d)
> > {
> > int i;
> >
> > d->netdev = &orion_ge00.dev;
> > for (i = 0; i < d->nr_chips; i++)
> > d->chip[i].host_dev = &orion_ge_mvmdio.dev;
> >
> > platform_device_register_data(NULL, "dsa", 0, d, sizeof(d));
> > }
> >
> > Where we have
> >
> > static struct platform_device orion_ge00 = {
> > .name = MV643XX_ETH_NAME,
> > .id = 0,
> > .num_resources = 1,
> > .resource = orion_ge00_resources,
> > .dev = {
> > .coherent_dma_mask = DMA_BIT_MASK(32),
> > },
> > };
> >
> > So this is the platform device for the Ethernet device. We cannot go
> > to the net_device, because it does not exist until this Ethernet
> > platform device is instantiated.
>
> Ok, fine, but why isn't the ethernet device a child of this platform
> device? Why is it floating around somewhere else? You don't see that
> happening for other devices.
The ethernet device is not a child of the DSA device. I'm going to
send a mail I've had queued up for a few hours redoing Andrew's
ASCII art, because I think that's what's causing the confusion here,
provided I haven't discarded it.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: xennet_start_xmit assumptions
From: David Miller @ 2017-01-19 16:37 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev, Paul.Durrant, wei.liu2, xen-devel, konrad.wilk
In-Reply-To: <20170119111426.GA22018@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Thu, 19 Jan 2017 06:14:26 -0500
> I'll probably work on fixing packet_snd to return -EINVAL
> or similar when the len is zero this week.
I thought we had code which made sure that at least a minimal
link layer header was present in the SKB?
Specifically I'm talking about the dev_validate_header() check.
That is supposed to protect us from these kinds of situations.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v3 net-next] phy: increase size of MII_BUS_ID_SIZE and bus_id
From: Andrew Lunn @ 2017-01-19 16:40 UTC (permalink / raw)
To: Volodymyr Bendiuga
Cc: f.fainelli, netdev, volodymyr.bendiuga, Magnus Öberg
In-Reply-To: <1484841904-19313-1-git-send-email-volodymyr.bendiuga@gmail.com>
On Thu, Jan 19, 2017 at 05:05:04PM +0100, Volodymyr Bendiuga wrote:
> Some bus names are pretty long and do not fit into
> 17 chars. Increase therefore MII_BUS_ID_SIZE and
> phy_fixup.bus_id to larger number. Now mii_bus.id
> can host larger name.
>
> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
> Signed-off-by: Magnus Öberg <magnus.oberg@westermo.se>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] tcp: initialize max window for a new fastopen socket
From: David Miller @ 2017-01-19 16:41 UTC (permalink / raw)
To: alexey.kodanev; +Cc: netdev, eric.dumazet, ycheng, ncardwell
In-Reply-To: <1484832999-1849-1-git-send-email-alexey.kodanev@oracle.com>
From: Alexey Kodanev <alexey.kodanev@oracle.com>
Date: Thu, 19 Jan 2017 16:36:39 +0300
> Found that if we run LTP netstress test with large MSS (65K),
> the first attempt from server to send data comparable to this
> MSS on fastopen connection will be delayed by the probe timer.
>
> Here is an example:
>
> < S seq 0:0 win 43690 options [mss 65495 wscale 7 tfo cookie] length 32
> > S. seq 0:0 ack 1 win 43690 options [mss 65495 wscale 7] length 0
> < . ack 1 win 342 length 0
>
> Inside tcp_sendmsg(), tcp_send_mss() returns max MSS in 'mss_now',
> as well as in 'size_goal'. This results the segment not queued for
> transmition until all the data copied from user buffer. Then, inside
> __tcp_push_pending_frames(), it breaks on send window test and
> continues with the check probe timer.
>
> Fragmentation occurs in tcp_write_wakeup()...
>
> +0.2 > P. seq 1:43777 ack 1 win 342 length 43776
> < . ack 43777, win 1365 length 0
> > P. seq 43777:65001 ack 1 win 342 options [...] length 21224
> ...
>
> This also contradicts with the fact that we should bound to the half
> of the window if it is large.
>
> Fix this flaw by correctly initializing max_window. Before that, it
> could have large values that affect further calculations of 'size_goal'.
>
> Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Inconsistency in packet drop due to MTU (eth vs veth)
From: Fredrik Markstrom @ 2017-01-19 16:41 UTC (permalink / raw)
To: netdev
Cc: Evan Jones, David S. Miller, Cong Wang, Greg Kroah-Hartman,
Vijay Pandurangan, linux-kernel
Hello,
I've noticed an inconsistency between how physical ethernet and veth handles mtu.
If I setup two physical interfaces (directly connected) with different mtu:s, only the size of the outgoing packets are limited by the mtu. But with veth a packet is dropped if the mtu of the receiving interface is smaller then the packet size.
This seems inconsistent to me, but maybe there is a reason for it ?
Can someone confirm if it's a deliberate inconsistency or just a side effect of using dev_forward_skb() ?
Example:
Using physical interfaces
=================
client> ip link set dev eth0 mtu 500
server> ip link set dev eth2 mtu 1500
server> ping -qc 2 -s 600 client
PING 135.15.35.74 (135.15.35.74) 1100(1128) bytes of data.
--- 135.15.35.74 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.818/0.864/0.910/0.046 ms
Using veth
=============
server> ip netns add clientns
server> ip link add name serverif type veth peer name clientif
server> ip addr add 10.0.0.1/24 dev serverif
server> ip link set serverif mtu 1500 up
server> ip link set clientif up netns clientns
server> ip netns exec clientns ip link set clientif mtu 500
server> ip netns exec clientns ip addr add 10.0.0.74/24 dev clientif
server> ping -qc 2 -s 600 10.0.0.74
PING 10.0.0.74 (10.0.0.74) 600(628) bytes of data.
--- 10.0.0.74 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms
/F
^ permalink raw reply
* Re: [PATCH net] gianfar: Do not reuse pages from emergency reserve
From: David Miller @ 2017-01-19 16:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, claudiu.manoil
In-Reply-To: <1484797482.16328.13.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jan 2017 19:44:42 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> A driver using dev_alloc_page() must not reuse a page that had to
> use emergency memory reserve.
>
> Otherwise all packets using this page will be immediately dropped,
> unless for very specific sockets having SOCK_MEMALLOC bit set.
>
> This issue might be hard to debug, because only a fraction of the RX
> ring buffer would suffer from drops.
>
> Fixes: 75354148ce69 ("gianfar: Add paged allocation and Rx S/G")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: caif: Remove unused stats member from struct chnl_net
From: David Miller @ 2017-01-19 16:51 UTC (permalink / raw)
To: tklauser; +Cc: dmitry.tarnyagin, netdev
In-Reply-To: <20170119150425.12559-1-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 19 Jan 2017 16:04:25 +0100
> The stats member of struct chnl_net is used nowhere in the code, so it
> might as well be removed.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Russell King - ARM Linux @ 2017-01-19 16:51 UTC (permalink / raw)
To: Andrew Lunn, Greg KH
Cc: Florian Fainelli, netdev, Jason Cooper, Sebastian Hesselbarth,
Gregory Clement, Vivien Didelot, David S. Miller,
moderated list:ARM SUB-ARCHITECTURES, open list
In-Reply-To: <20170119145315.GD21805@lunn.ch>
(This is mainly for Greg's benefit to help him understand the issue.)
I think the diagram you gave initially made this confusing, as it
talks about a CPU(sic) producing the "RGMII" and "MII-MGMT".
Let's instead show a better representation that hopefully helps Greg
understand networking. :)
CPU
System <-B-> Ethernet controller <-P-> } PHY <---> network cable
} - - - - - - - or - - - - - - -
MDIO bus -------M---> } Switch <-P-> PHYs <--> network
`----M----^ cables
'B' can be an on-SoC bus or something like PCI.
'P' are the high-speed connectivity between the ethernet controller and
PHY which carries the packet data. It has no addressing, it's a point
to point link. RGMII is just one wiring example, there are many
different interfaces there (SGMII, AUI, XAUI, XGMII to name a few.)
'M' are the MDIO bus, which is the bus by which ethernet PHYs and
switches can be identified and controlled.
The MDIO bus has a bus_type, has host drivers which are sometimes
part of the ethernet controller, but can also be stand-alone devices
shared between multiple ethernet controllers.
PHYs are a kind of MDIO device which are members of the MDIO bus
type. Each PHY (and switch) has a numerical address, and identifying
numbers within its register set which identifies the manufacturer
and device type. We have device_driver objects for these.
Expanding the above diagram to make it (hopefully) even clearer,
we can have this classic setup:
CPU
System <-B-> Ethernet controller <-P-> PHY <---> network cable
MDIO bus -------M------^
Or, in the case of two DSA switches attached to an Ethernet controller:
|~~~~~~~~|
System <-B-> Ethernet controller <-P-> Switch <-P-> PHY1 <--> network cable
MDIO bus ----+--M---> 1 <-P-> PHY2 <--> network cable
| | ... |
| | <-P-> PHYn <--> network cable
| |....^...| |
| | `---M---'
| P
| |
| |~~~~v~~~|
`------> Switch <-P-> PHY1 <--> network cable
| 2 ... |
| <-P-> PHYn <--> network cable
|........| |
`---M---'
The problem that the DSA guys are trying to deal with is how to
represent the link between the DSA switches (which are devices
sitting off their controlling bus - the MDIO bus) and the ethernet
controller associated with that collection of devices, be it a
switch or PHY.
Merely changing the parent/child relationships to try and solve
one issue just creates exactly the same problem elsewhere.
So, I hope with these diagrams, you can see that trying to make
the ethernet controller a child device of the DSA switches
means that (eg) it's no longer a PCI device, which is rather
absurd, especially when considering that what happens to the
right of the ethernet controller in the diagrams above is
normally external chips to the SoC or ethernet device.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v6 00/13] net: ethernet: aquantia: Add AQtion 2.5/5 GB NIC driver
From: David Miller @ 2017-01-19 16:55 UTC (permalink / raw)
To: Alexander.Loktionov
Cc: netdev, vomlehn, Simon.Edelhaus, Dmitrii.Tarakanov, Pavel.Belous
In-Reply-To: <cover.1484788010.git.vomlehn@texas.net>
From: Alexander Loktionov <Alexander.Loktionov@aquantia.com>
Date: Wed, 18 Jan 2017 17:07:51 -0800
> From: David VomLehn <vomlehn@texas.net>
>
> This series introduces the AQtion NIC driver for the aQuantia
> AQC107/AQC108 network devices.
>
> This series introduces the AQtion NIC driver for the aQuantia
> AQC107/AQC108 network devices.
You don't need to say this twice :-)
Also, please incorporate the fix posted by the kbuild test robot.
^ permalink raw reply
* [PATCH v2 2/5] net: ethernet: ti: cpsw: don't disable interrupts in ndo_open
From: Ivan Khoronzhuk @ 2017-01-19 16:58 UTC (permalink / raw)
To: mugunthanvnm
Cc: grygorii.strashko, netdev, linux-omap, linux-kernel,
Ivan Khoronzhuk
In-Reply-To: <1484845107-30331-1-git-send-email-ivan.khoronzhuk@linaro.org>
No need to disable interrupts if no open devices,
they are disabled anyway.
Even no need to disable interrupts if some ndev is opened, In this
case shared resources are not touched, only parameters of ndev shell,
so no reason to disable them also. Removed lines have proved it.
So, no need in redundant check and interrupt disable.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
drivers/net/ethernet/ti/cpsw.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 296ddf2..f798905 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1480,8 +1480,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
return ret;
}
- if (!cpsw_common_res_usage_state(cpsw))
- cpsw_intr_disable(cpsw);
netif_carrier_off(ndev);
/* Notify the stack of the actual queue counts. */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 net-next] phy: increase size of MII_BUS_ID_SIZE and bus_id
From: David Miller @ 2017-01-19 16:52 UTC (permalink / raw)
To: volodymyr.bendiuga
Cc: f.fainelli, andrew, netdev, volodymyr.bendiuga, magnus.oberg
In-Reply-To: <1484841904-19313-1-git-send-email-volodymyr.bendiuga@gmail.com>
From: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
Date: Thu, 19 Jan 2017 17:05:04 +0100
> Some bus names are pretty long and do not fit into
> 17 chars. Increase therefore MII_BUS_ID_SIZE and
> phy_fixup.bus_id to larger number. Now mii_bus.id
> can host larger name.
>
> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
> Signed-off-by: Magnus Öberg <magnus.oberg@westermo.se>
Applied.
^ permalink raw reply
* [PATCH v2 4/5] net: ethernet: ti: cpsw: don't duplicate common res in rx handler
From: Ivan Khoronzhuk @ 2017-01-19 16:58 UTC (permalink / raw)
To: mugunthanvnm
Cc: grygorii.strashko, netdev, linux-omap, linux-kernel,
Ivan Khoronzhuk
In-Reply-To: <1484845107-30331-1-git-send-email-ivan.khoronzhuk@linaro.org>
No need to duplicate the same function in rx handler to get info
if any interface is running.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
drivers/net/ethernet/ti/cpsw.c | 40 ++++++++++++++++------------------------
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index c681d39..1f14afd 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -671,6 +671,18 @@ static void cpsw_intr_disable(struct cpsw_common *cpsw)
return;
}
+static int cpsw_get_usage_count(struct cpsw_common *cpsw)
+{
+ u32 i;
+ u32 usage_count = 0;
+
+ for (i = 0; i < cpsw->data.slaves; i++)
+ if (netif_running(cpsw->slaves[i].ndev))
+ usage_count++;
+
+ return usage_count;
+}
+
static void cpsw_tx_handler(void *token, int len, int status)
{
struct netdev_queue *txq;
@@ -703,18 +715,10 @@ static void cpsw_rx_handler(void *token, int len, int status)
cpsw_dual_emac_src_port_detect(cpsw, status, ndev, skb);
if (unlikely(status < 0) || unlikely(!netif_running(ndev))) {
- bool ndev_status = false;
- struct cpsw_slave *slave = cpsw->slaves;
- int n;
-
- if (cpsw->data.dual_emac) {
- /* In dual emac mode check for all interfaces */
- for (n = cpsw->data.slaves; n; n--, slave++)
- if (netif_running(slave->ndev))
- ndev_status = true;
- }
-
- if (ndev_status && (status >= 0)) {
+ /* In dual emac mode check for all interfaces */
+ if (cpsw->data.dual_emac &&
+ cpsw_get_usage_count(cpsw) &&
+ (status >= 0)) {
/* The packet received is for the interface which
* is already down and the other interface is up
* and running, instead of freeing which results
@@ -1234,18 +1238,6 @@ static void cpsw_get_ethtool_stats(struct net_device *ndev,
}
}
-static int cpsw_get_usage_count(struct cpsw_common *cpsw)
-{
- u32 i;
- u32 usage_count = 0;
-
- for (i = 0; i < cpsw->data.slaves; i++)
- if (netif_running(cpsw->slaves[i].ndev))
- usage_count++;
-
- return usage_count;
-}
-
static inline int cpsw_tx_packet_submit(struct cpsw_priv *priv,
struct sk_buff *skb,
struct cpdma_chan *txch)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/5] net: ethernet: ti: cpsw: correct common res usage
From: Ivan Khoronzhuk @ 2017-01-19 16:58 UTC (permalink / raw)
To: mugunthanvnm
Cc: grygorii.strashko, netdev, linux-omap, linux-kernel,
Ivan Khoronzhuk
This series is intended to remove unneeded redundancies connected with
common resource usage function.
Since v1:
- changed name to cpsw_get_usage_count()
- added comments to open/closw for cpsw_get_usage_count()
- added patch:
net: ethernet: ti: cpsw: clarify ethtool ops changing num of descs
Based on net-next/master
Ivan Khoronzhuk (5):
net: ethernet: ti: cpsw: remove dual check from common res usage
function
net: ethernet: ti: cpsw: don't disable interrupts in ndo_open
net: ethernet: ti: cpsw: don't duplicate ndev_running
net: ethernet: ti: cpsw: don't duplicate common res in rx handler
net: ethernet: ti: cpsw: clarify ethtool ops changing num of descs
drivers/net/ethernet/ti/cpsw.c | 200 ++++++++++++++++++-----------------------
1 file changed, 88 insertions(+), 112 deletions(-)
--
2.7.4
^ 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