* Re: [PATCH net v2] net: phy: fix WoL handling when suspending the PHY
From: Heiner Kallweit @ 2018-09-23 13:39 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <f8737cef-88d2-0f60-bc96-88251e77c1bd@gmail.com>
Sorry, this patch was accidentally sent as reply.
On 23.09.2018 15:33, Heiner Kallweit wrote:
> Actually there's nothing wrong with the two changes marked as "Fixes",
> they just revealed a problem which has been existing before.
> After having switched r8169 to phylib it was reported that WoL from
> shutdown doesn't work any longer (WoL from suspend isn't affected).
> Reason is that during shutdown phy_disconnect()->phy_detach()->
> phy_suspend() is called.
> A similar issue occurs when the phylib state machine calls
> phy_suspend() when handling state PHY_HALTED.
>
> Core of the problem is that phy_suspend() suspends the PHY when it
> should not due to WoL. phy_suspend() checks for WoL already, but this
> works only if the PHY driver handles WoL (what is rarely the case).
> Typically WoL is handled by the MAC driver.
>
> phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
> but that's used only when suspending the system, not in other cases
> like shutdown.
>
> Therefore factor out the relevant check from
> mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
> use it in phy_suspend().
>
> Last but not least change phy_detach() to call phy_suspend() before
> attached_dev is set to NULL. phy_suspend() accesses attached_dev
> when checking whether the MAC driver activated WoL.
>
> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in phy_stop")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> v2:
> - improved commit message
> - reduced scope of patch, don't touch functionality of
> mdio_bus_phy_suspend and mdio_bus_phy_resume
> ---
> drivers/net/phy/phy_device.c | 42 ++++++++++++++++++++++--------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index af64a9320..4cab94bae 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>
> +static bool phy_may_suspend(struct phy_device *phydev)
> +{
> + struct net_device *netdev = phydev->attached_dev;
> +
> + if (!netdev)
> + return true;
> +
> + /* Don't suspend PHY if the attached netdev parent may wakeup.
> + * The parent may point to a PCI device, as in tg3 driver.
> + */
> + if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
> + return false;
> +
> + /* Also don't suspend PHY if the netdev itself may wakeup. This
> + * is the case for devices w/o underlaying pwr. mgmt. aware bus,
> + * e.g. SoC devices.
> + */
> + return !device_may_wakeup(&netdev->dev);
> +}
> +
> #ifdef CONFIG_PM
> static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> {
> @@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> if (!netdev)
> return !phydev->suspended;
>
> - /* Don't suspend PHY if the attached netdev parent may wakeup.
> - * The parent may point to a PCI device, as in tg3 driver.
> - */
> - if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
> - return false;
> -
> - /* Also don't suspend PHY if the netdev itself may wakeup. This
> - * is the case for devices w/o underlaying pwr. mgmt. aware bus,
> - * e.g. SoC devices.
> - */
> - if (device_may_wakeup(&netdev->dev))
> - return false;
> -
> - return true;
> + return phy_may_suspend(phydev);
> }
>
> static int mdio_bus_phy_suspend(struct device *dev)
> @@ -1132,9 +1139,9 @@ void phy_detach(struct phy_device *phydev)
> sysfs_remove_link(&dev->dev.kobj, "phydev");
> sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
> }
> + phy_suspend(phydev);
> phydev->attached_dev->phydev = NULL;
> phydev->attached_dev = NULL;
> - phy_suspend(phydev);
> phydev->phylink = NULL;
>
> phy_led_triggers_unregister(phydev);
> @@ -1171,9 +1178,12 @@ int phy_suspend(struct phy_device *phydev)
> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> int ret = 0;
>
> + if (phydev->suspended)
> + return 0;
> +
> /* If the device has WOL enabled, we cannot suspend the PHY */
> phy_ethtool_get_wol(phydev, &wol);
> - if (wol.wolopts)
> + if (wol.wolopts || !phy_may_suspend(phydev))
> return -EBUSY;
>
> if (phydev->drv && phydrv->suspend)
>
^ permalink raw reply
* Re: [PATCH] RDS: IB: Use DEFINE_PER_CPU_SHARED_ALIGNED for rds_ib_stats
From: Nathan Chancellor @ 2018-09-23 19:38 UTC (permalink / raw)
To: David Miller
Cc: santosh.shilimkar, netdev, linux-rdma, linux-kernel, ndesaulniers
In-Reply-To: <20180923.121927.436285462706036460.davem@davemloft.net>
On Sun, Sep 23, 2018 at 12:19:27PM -0700, David Miller wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
> Date: Sat, 22 Sep 2018 23:44:45 -0700
>
> > I have sent a v2 because this should be DECLARE_PER_CPU_SHARED_ALIGNED,
> > not DEFINE (thanks to 0day for catching it).
>
> Your first version was already applied to the networking GIT tree, so
> you will need to submit a relative fixup with a proper "Fixes: " tag.
Hi David,
My apologies, I didn't receive an email saying my patch was applied so I
didn't think to check your tree. I'll be better about this in the
future.
Thank you for fixing this up yourself and all your patience, sorry for
all the noise!
Nathan
^ permalink raw reply
* Re: [PATCH net-next v9 0/6] net: vhost: improve performance when enable busyloop
From: Tonghao Zhang @ 2018-09-23 13:48 UTC (permalink / raw)
To: jasowang, mst, makita.toshiaki
Cc: virtualization, Linux Kernel Network Developers
In-Reply-To: <1536493887-2637-1-git-send-email-xiangxia.m.yue@gmail.com>
On Sun, Sep 9, 2018 at 7:52 PM <xiangxia.m.yue@gmail.com> wrote:
>
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> This patches improve the guest receive performance.
> On the handle_tx side, we poll the sock receive queue
> at the same time. handle_rx do that in the same way.
>
> For more performance report, see patch 4, 5, 6
>
> Tonghao Zhang (6):
> net: vhost: lock the vqs one by one
> net: vhost: replace magic number of lock annotation
> net: vhost: factor out busy polling logic to vhost_net_busy_poll()
> net: vhost: add rx busy polling in tx path
> net: vhost: disable rx wakeup during tx busypoll
> net: vhost: make busyloop_intr more accurate
>
> drivers/vhost/net.c | 163 +++++++++++++++++++++++++++++++-------------------
> drivers/vhost/vhost.c | 24 +++-----
> 2 files changed, 108 insertions(+), 79 deletions(-)
>
> --
> 1.8.3.1
>
ping ?
^ permalink raw reply
* [PATCH net-next] tcp: expose sk_state in tcp_retransmit_skb tracepoint
From: Yafang Shao @ 2018-09-23 19:49 UTC (permalink / raw)
To: edumazet, davem; +Cc: netdev, linux-kernel, Yafang Shao
With sk_state, we can know whether this connection is in SYN_SENT state
or ESTBLISHED state.
The reason to distinguish between these two scenario is that the
retransmission in ESTABLISHED state always mean network congestion while
in SYN_SENT state it always mean server issue, i.e. the syn packet is
dropped due to syn backlog queue full.
PS: SYNACK retransmission is traced in tcp_retransmit_synack tracepoint.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
include/trace/events/tcp.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index ac55b32..2bc9960 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -56,6 +56,7 @@
TP_STRUCT__entry(
__field(const void *, skbaddr)
__field(const void *, skaddr)
+ __field(int, state)
__field(__u16, sport)
__field(__u16, dport)
__array(__u8, saddr, 4)
@@ -70,6 +71,7 @@
__entry->skbaddr = skb;
__entry->skaddr = sk;
+ __entry->state = sk->sk_state;
__entry->sport = ntohs(inet->inet_sport);
__entry->dport = ntohs(inet->inet_dport);
@@ -84,9 +86,10 @@
sk->sk_v6_rcv_saddr, sk->sk_v6_daddr);
),
- TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c",
+ TP_printk("sport=%hu dport=%hu saddr=%pI4 daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c state=%s\n",
__entry->sport, __entry->dport, __entry->saddr, __entry->daddr,
- __entry->saddr_v6, __entry->daddr_v6)
+ __entry->saddr_v6, __entry->daddr_v6,
+ show_tcp_state_name(__entry->state))
);
DEFINE_EVENT(tcp_event_sk_skb, tcp_retransmit_skb,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH RFT net-next 0/2] net: phy: Eliminate unnecessary soft
From: Clemens Gruber @ 2018-09-23 14:25 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, David S. Miller, Andrew Lunn
In-Reply-To: <20180919013505.11347-1-f.fainelli@gmail.com>
Hi,
On Tue, Sep 18, 2018 at 06:35:03PM -0700, Florian Fainelli wrote:
> Hi all,
>
> This patch series eliminates unnecessary software resets of the PHY.
> This should hopefully not break anybody's hardware; but I would
> appreciate testing to make sure this is is the case.
>
> Sorry for this long email list, I wanted to make sure I reached out to
> all people who made changes to the Marvell PHY driver.
>
> Thank you!
>
> Florian Fainelli (2):
> net: phy: Stop with excessive soft reset
> net: phy: marvell: Avoid unnecessary soft reset
>
> drivers/net/phy/marvell.c | 63 ++++++++++++------------------------
> drivers/net/phy/phy_device.c | 2 --
> 2 files changed, 21 insertions(+), 44 deletions(-)
>
> --
> 2.17.1
>
I tested your patches on our board with a Marvell 88E1510. Looks good!
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Clemens
^ permalink raw reply
* [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
From: Ido Schimmel @ 2018-09-23 14:48 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
From: Petr Machata <petrm@mellanox.com>
Up until now, mlxsw tolerated firmware versions that weren't exactly
matching the required version, if the branch number matched. That
allowed the users to test various firmware versions as long as they were
on the right branch.
On the other hand, it made it impossible for mlxsw to put a hard lower
bound on a version that fixes all problems known to date. If a user had
a somewhat older FW version installed, mlxsw would start up just fine,
possibly performing non-optimally as it would use features that trigger
problematic behavior.
Therefore tweak the check to accept any FW version that is:
- on the same branch as the preferred version, and
- the same as or newer than the preferred version.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 1fc20263b15b..33a024274a1f 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -331,7 +331,10 @@ static int mlxsw_sp_fw_rev_validate(struct mlxsw_sp *mlxsw_sp)
return -EINVAL;
}
if (MLXSW_SP_FWREV_MINOR_TO_BRANCH(rev->minor) ==
- MLXSW_SP_FWREV_MINOR_TO_BRANCH(req_rev->minor))
+ MLXSW_SP_FWREV_MINOR_TO_BRANCH(req_rev->minor) &&
+ (rev->minor > req_rev->minor ||
+ (rev->minor == req_rev->minor &&
+ rev->subminor >= req_rev->subminor)))
return 0;
dev_info(mlxsw_sp->bus_info->dev, "The firmware version %d.%d.%d is incompatible with the driver\n",
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] tcp: expose sk_state in tcp_retransmit_skb tracepoint
From: Eric Dumazet @ 2018-09-23 21:42 UTC (permalink / raw)
To: Yafang Shao, edumazet, davem; +Cc: netdev, linux-kernel
In-Reply-To: <1537732141-22468-1-git-send-email-laoar.shao@gmail.com>
On 09/23/2018 12:49 PM, Yafang Shao wrote:
> With sk_state, we can know whether this connection is in SYN_SENT state
> or ESTBLISHED state.
> The reason to distinguish between these two scenario is that the
> retransmission in ESTABLISHED state always mean network congestion while
> in SYN_SENT state it always mean server issue, i.e. the syn packet is
> dropped due to syn backlog queue full.
You mean, a packet drop on the remote peer ?
It could also be a packet drop in the network.
Your patch is good, but changelog is quite misleading.
^ permalink raw reply
* Re: [RFC 2/3 net] lorawan: Add macro and definition for LoRaWAN class modlue
From: Andreas Färber @ 2018-09-23 16:06 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: netdev, linux-arm-kernel, linux-kernel, Jiri Pirko,
Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, contact@snootlab.com, Ben Whitten,
Brian Ray, lora, Alexander Graf, Michal Kubeček
In-Reply-To: <f7ea222671a2bc6fe0a060c4bdb1ebae162d0d91.1535039998.git.starnight@g.ncu.edu.tw>
Hi Jian-Hong,
Many thanks and sorry for the delay. This patch mostly looks good and
should go in before its first uses, so I would like to queue it soon for
my hardware-MAC module drivers - but some questions below. Also a typo
in the subject, and we should probably prepend "net: " and I would
personally not mention the module here as it's a userspace API.
Am 23.08.18 um 19:15 schrieb Jian-Hong Pan:
> This patch add the macro and definition for the implementation of
> LoRaWAN protocol.
I would fix up the grammar nits in my tree then.
>
> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
> ---
> include/linux/socket.h | 5 ++++-
> include/uapi/linux/if_arp.h | 1 +
> include/uapi/linux/if_ether.h | 1 +
> net/core/dev.c | 4 ++--
> security/selinux/hooks.c | 4 +++-
> security/selinux/include/classmap.h | 4 +++-
> 6 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index aa1e288b1659..e5c8381fd1aa 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -209,8 +209,9 @@ struct ucred {
> */
> #define AF_XDP 44 /* XDP sockets */
> #define AF_LORA 45 /* LoRa sockets */
> +#define AF_LORAWAN 46 /* LoRaWAN sockets */
>
> -#define AF_MAX 46 /* For now.. */
> +#define AF_MAX 47 /* For now.. */
>
> /* Protocol families, same as address families. */
> #define PF_UNSPEC AF_UNSPEC
> @@ -261,6 +262,7 @@ struct ucred {
> #define PF_SMC AF_SMC
> #define PF_XDP AF_XDP
> #define PF_LORA AF_LORA
> +#define PF_LORAWAN AF_LORAWAN
> #define PF_MAX AF_MAX
>
> /* Maximum queue length specifiable by listen. */
> @@ -343,6 +345,7 @@ struct ucred {
> #define SOL_KCM 281
> #define SOL_TLS 282
> #define SOL_XDP 283
> +#define SOL_LORAWAN 284
>
> /* IPX options */
> #define IPX_TYPE 1
> diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
> index 1ed7cb3f2129..2376f7839355 100644
> --- a/include/uapi/linux/if_arp.h
> +++ b/include/uapi/linux/if_arp.h
> @@ -99,6 +99,7 @@
> #define ARPHRD_6LOWPAN 825 /* IPv6 over LoWPAN */
> #define ARPHRD_VSOCKMON 826 /* Vsock monitor header */
> #define ARPHRD_LORA 827 /* LoRa */
> +#define ARPHRD_LORAWAN 828 /* LoRaWAN */
>
> #define ARPHRD_VOID 0xFFFF /* Void type, nothing is known */
> #define ARPHRD_NONE 0xFFFE /* zero header length */
> diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
> index 45644dcf5b39..b1ac70d4a377 100644
> --- a/include/uapi/linux/if_ether.h
> +++ b/include/uapi/linux/if_ether.h
> @@ -148,6 +148,7 @@
> * aggregation protocol
> */
> #define ETH_P_LORA 0x00FA /* LoRa */
> +#define ETH_P_LORAWAN 0x00FB /* LoRaWAN */
>
> /*
> * This is an Ethernet frame header.
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f68122f0ab02..b95ce79ec5a8 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -297,7 +297,7 @@ static const unsigned short netdev_lock_type[] = {
> ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
> ARPHRD_FCFABRIC, ARPHRD_IEEE80211, ARPHRD_IEEE80211_PRISM,
> ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET, ARPHRD_PHONET_PIPE,
> - ARPHRD_IEEE802154, ARPHRD_VOID, ARPHRD_NONE};
> + ARPHRD_IEEE802154, ARPHRD_LORAWAN, ARPHRD_VOID, ARPHRD_NONE};
>
> static const char *const netdev_lock_name[] = {
> "_xmit_NETROM", "_xmit_ETHER", "_xmit_EETHER", "_xmit_AX25",
> @@ -314,7 +314,7 @@ static const char *const netdev_lock_name[] = {
> "_xmit_IRDA", "_xmit_FCPP", "_xmit_FCAL", "_xmit_FCPL",
> "_xmit_FCFABRIC", "_xmit_IEEE80211", "_xmit_IEEE80211_PRISM",
> "_xmit_IEEE80211_RADIOTAP", "_xmit_PHONET", "_xmit_PHONET_PIPE",
> - "_xmit_IEEE802154", "_xmit_VOID", "_xmit_NONE"};
> + "_xmit_IEEE802154", "_xmit_LORAWAN", "_xmit_VOID", "_xmit_NONE"};
>
> static struct lock_class_key netdev_xmit_lock_key[ARRAY_SIZE(netdev_lock_type)];
> static struct lock_class_key netdev_addr_lock_key[ARRAY_SIZE(netdev_lock_type)];
All your new constants except SOL_LORAWAN are always next to a LoRa one,
but not in these two arrays. I don't have such changes in my original
LoRa patch - am I missing such an array extension for ARPHRD_LORA then,
or what is the criteria for when to add this?
Other changes look fine to me.
Regards,
Andreas
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index aaf520a689d8..0da3a1d69cb8 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1477,7 +1477,9 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
> return SECCLASS_XDP_SOCKET;
> case PF_LORA:
> return SECCLASS_LORA_SOCKET;
> -#if PF_MAX > 46
> + case PF_LORAWAN:
> + return SECCLASS_LORAWAN_SOCKET;
> +#if PF_MAX > 47
> #error New address family defined, please update this function.
> #endif
> }
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index 060d4bf8385e..fa0151fe6f32 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -244,9 +244,11 @@ struct security_class_mapping secclass_map[] = {
> { COMMON_SOCK_PERMS, NULL } },
> { "lora_socket",
> { COMMON_SOCK_PERMS, NULL } },
> + { "lorawan_socket",
> + { COMMON_SOCK_PERMS, NULL } },
> { NULL }
> };
>
> -#if PF_MAX > 46
> +#if PF_MAX > 47
> #error New address family defined, please update secclass_map.
> #endif
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: KMSAN: uninit-value in memcmp (2)
From: Dmitry Vyukov @ 2018-09-23 16:22 UTC (permalink / raw)
To: Vladis Dronov
Cc: syzbot, syzkaller-bugs, David Miller, Eric Dumazet, LKML, netdev,
sunlianwen
In-Reply-To: <125732064.15444205.1537718529926.JavaMail.zimbra@redhat.com>
On Sun, Sep 23, 2018 at 6:02 PM, Vladis Dronov <vdronov@redhat.com> wrote:
> #syz fix: net: fix uninit-value in __hw_addr_add_ex()
Hi Vladis,
This can be fixed with "net: fix uninit-value in __hw_addr_add_ex()".
That commit landed in April, syzbot waited till the commit reached all
tested trees, and then closed the bug.
But the similar bug continued to happen, so syzbot created second
version of this bug (2). You can see on dashboard that the last crash
for the second version (2) happened just few days ago. So this is a
different bug.
^ permalink raw reply
* Re: [RFC 1/3 net] lorawan: Add LoRaWAN class module
From: Andreas Färber @ 2018-09-23 16:40 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: netdev, linux-arm-kernel, linux-kernel, Jiri Pirko,
Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, Jon Ortego, contact@snootlab.com, Ben Whitten,
Brian Ray, lora, Alexander Graf, Michal Kubeček
In-Reply-To: <fc737f3940bbe91341fb15d85ac11931eb56d1fc.1535039998.git.starnight@g.ncu.edu.tw>
Hi Jian-Hong,
[+ Afonso]
Am 23.08.18 um 19:15 schrieb Jian-Hong Pan:
> LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa devices.
>
> This patch implements part of Class A end-devices features defined in
> LoRaWAN(TM) Specification Ver. 1.0.2:
> 1. End-device receive slot timing
> 2. Only single channel and single data rate for now
> 3. Unconfirmed data up/down message types
> 4. Encryption/decryption for up/down link data messages
>
> It also implements the the functions and maps to Datagram socket for
> LoRaWAN unconfirmed data messages.
>
> On the other side, it defines the basic interface and operation
> functions for compatible LoRa device drivers.
>
> Signed-off-by: Jian-Hong Pan <starnight@g.ncu.edu.tw>
> ---
> include/linux/maclorawan/lora.h | 239 +++++++++++
> net/maclorawan/Kconfig | 14 +
> net/maclorawan/Makefile | 2 +
> net/maclorawan/lorawan.h | 219 ++++++++++
> net/maclorawan/lrwsec.c | 237 +++++++++++
> net/maclorawan/lrwsec.h | 57 +++
> net/maclorawan/mac.c | 552 +++++++++++++++++++++++++
> net/maclorawan/main.c | 665 ++++++++++++++++++++++++++++++
> net/maclorawan/socket.c | 700 ++++++++++++++++++++++++++++++++
> 9 files changed, 2685 insertions(+)
> create mode 100644 include/linux/maclorawan/lora.h
Can we use include/linux/lora/lorawan.h for simplicity?
> create mode 100644 net/maclorawan/Kconfig
> create mode 100644 net/maclorawan/Makefile
> create mode 100644 net/maclorawan/lorawan.h
> create mode 100644 net/maclorawan/lrwsec.c
> create mode 100644 net/maclorawan/lrwsec.h
> create mode 100644 net/maclorawan/mac.c
> create mode 100644 net/maclorawan/main.c
> create mode 100644 net/maclorawan/socket.c
This patch is much too large for me to review...
It also doesn't seem to follow the structure I suggested: 802.15.4 has
two separate directories, net/ieee802154/ and net/mac802154/. Therefore
I had suggested net/maclorawan/ only for code that translates from
ETH_P_LORAWAN to ETH_P_LORA socket buffers, i.e. your soft MAC. Generic
socket code that applies also to hard MAC drivers I expected to go
either to net/lora/lorawan/ or better net/lorawan/ or some other clearly
separate location, with its own Kconfig symbol - any reason not to?
Consider which parts can be enabled/used independently of each other,
then you can put them into two (or more?) different patches.
Also please use SPDX license identifiers in your headers.
And please don't put the whole world in To, use CC.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net v2] net: phy: fix WoL handling when suspending the PHY
From: Florian Fainelli @ 2018-09-23 16:49 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <faf1163d-7ba8-8cd9-f84c-3b924f3a6a16@gmail.com>
On September 23, 2018 6:38:21 AM PDT, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>Actually there's nothing wrong with the two changes marked as "Fixes",
>they just revealed a problem which has been existing before.
>After having switched r8169 to phylib it was reported that WoL from
>shutdown doesn't work any longer (WoL from suspend isn't affected).
>Reason is that during shutdown phy_disconnect()->phy_detach()->
>phy_suspend() is called.
>A similar issue occurs when the phylib state machine calls
>phy_suspend() when handling state PHY_HALTED.
>
>Core of the problem is that phy_suspend() suspends the PHY when it
>should not due to WoL. phy_suspend() checks for WoL already, but this
>works only if the PHY driver handles WoL (what is rarely the case).
>Typically WoL is handled by the MAC driver.
>
>phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
>but that's used only when suspending the system, not in other cases
>like shutdown.
>
>Therefore factor out the relevant check from
>mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
>use it in phy_suspend().
>
>Last but not least change phy_detach() to call phy_suspend() before
>attached_dev is set to NULL. phy_suspend() accesses attached_dev
>when checking whether the MAC driver activated WoL.
The rationale for the change makes sense but I am worried about a couple of things:
- we have seen drivers fail to call SET_NETDEV_DEV() correctly, or sometimes it is made possible because they are Device Tree only objects without a backing parent struct device (CONFIG_OF makes it possible), so we could be missing some cases here but this is not a big deal
- most Ethernet controller implementations typically set the device as a wake-up enabled device when an user issues the appropriate ethtool -s iface wol <parameters> and not at driver probe or ndo_open() time. There are exceptions like ASIX USB Ethernet adapters that AFAIR are wake-up enabled all the time. The main concern here is that at the time of suspend device_may_wakeup() evaluates to true and we keep the PHY on even though the driver/user was not requesting for WoL per-se
What you encode here is definitely the behavior that Ethernet controllers should have, but we should also audit drivers that use PHYLIB and implement WoL that this is not going to regresses their power management or ability to wake up from PHY, and finally, that there is not redundant code already in place.
>
>Fixes: f1e911d5d0df ("r8169: add basic phylib support")
>Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in
>phy_stop")
>Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>---
>v2:
>- improved commit message
>- reduced scope of patch, don't touch functionality of
> mdio_bus_phy_suspend and mdio_bus_phy_resume
>---
> drivers/net/phy/phy_device.c | 42 ++++++++++++++++++++++--------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
>diff --git a/drivers/net/phy/phy_device.c
>b/drivers/net/phy/phy_device.c
>index af64a9320..4cab94bae 100644
>--- a/drivers/net/phy/phy_device.c
>+++ b/drivers/net/phy/phy_device.c
>@@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>
>+static bool phy_may_suspend(struct phy_device *phydev)
>+{
>+ struct net_device *netdev = phydev->attached_dev;
>+
>+ if (!netdev)
>+ return true;
>+
>+ /* Don't suspend PHY if the attached netdev parent may wakeup.
>+ * The parent may point to a PCI device, as in tg3 driver.
>+ */
>+ if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>+ return false;
>+
>+ /* Also don't suspend PHY if the netdev itself may wakeup. This
>+ * is the case for devices w/o underlaying pwr. mgmt. aware bus,
>+ * e.g. SoC devices.
>+ */
>+ return !device_may_wakeup(&netdev->dev);
>+}
>+
> #ifdef CONFIG_PM
> static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> {
>@@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct
>phy_device *phydev)
> if (!netdev)
> return !phydev->suspended;
>
>- /* Don't suspend PHY if the attached netdev parent may wakeup.
>- * The parent may point to a PCI device, as in tg3 driver.
>- */
>- if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>- return false;
>-
>- /* Also don't suspend PHY if the netdev itself may wakeup. This
>- * is the case for devices w/o underlaying pwr. mgmt. aware bus,
>- * e.g. SoC devices.
>- */
>- if (device_may_wakeup(&netdev->dev))
>- return false;
>-
>- return true;
>+ return phy_may_suspend(phydev);
> }
>
> static int mdio_bus_phy_suspend(struct device *dev)
>@@ -1132,9 +1139,9 @@ void phy_detach(struct phy_device *phydev)
> sysfs_remove_link(&dev->dev.kobj, "phydev");
> sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
> }
>+ phy_suspend(phydev);
> phydev->attached_dev->phydev = NULL;
> phydev->attached_dev = NULL;
>- phy_suspend(phydev);
> phydev->phylink = NULL;
>
> phy_led_triggers_unregister(phydev);
>@@ -1171,9 +1178,12 @@ int phy_suspend(struct phy_device *phydev)
> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> int ret = 0;
>
>+ if (phydev->suspended)
>+ return 0;
>+
> /* If the device has WOL enabled, we cannot suspend the PHY */
> phy_ethtool_get_wol(phydev, &wol);
>- if (wol.wolopts)
>+ if (wol.wolopts || !phy_may_suspend(phydev))
> return -EBUSY;
>
> if (phydev->drv && phydrv->suspend)
--
Florian
^ permalink raw reply
* Re: [PATCH net] af_key: free SKBs under RCU protection
From: Eric Dumazet @ 2018-09-23 17:15 UTC (permalink / raw)
To: stranche, Eric Dumazet; +Cc: netdev, steffen.klassert
In-Reply-To: <357e28c3fa0c7bacaffde4e960f58a87@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
On 09/20/2018 12:25 PM, stranche@codeaurora.org wrote:
> Perhaps a cleaner solution here is to always clone the SKB in
> pfkey_broadcast_one(). That will ensure that the two kfree_skb() calls
> in pfkey_broadcast() will never be passed an SKB with sock_rfree() as
> its destructor, and we can avoid this race condition.
Yes, this whole idea of avoiding the cloning is brain dead.
Better play safe and having a straightforward implementation.
I suggest something like this (I could not reproduce the bug with the syzkaller repro)
Note that I removed the sock_hold(sk)/sock_put(sk) pair as this is useless.
The only time GFP_KERNEL might be used is when the sk is already owned by the caller.
net/key/af_key.c | 40 +++++++++++++++-------------------------
1 file changed, 15 insertions(+), 25 deletions(-)
[-- Attachment #2: patch2712.txt --]
[-- Type: text/plain, Size: 2418 bytes --]
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 9d61266526e767770d9a1ce184ac8cdd59de309a..7da629d5971712d5219528c55bad869bb084a343 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -196,30 +196,22 @@ static int pfkey_release(struct socket *sock)
return 0;
}
-static int pfkey_broadcast_one(struct sk_buff *skb, struct sk_buff **skb2,
- gfp_t allocation, struct sock *sk)
+static int pfkey_broadcast_one(struct sk_buff *skb, gfp_t allocation,
+ struct sock *sk)
{
int err = -ENOBUFS;
- sock_hold(sk);
- if (*skb2 == NULL) {
- if (refcount_read(&skb->users) != 1) {
- *skb2 = skb_clone(skb, allocation);
- } else {
- *skb2 = skb;
- refcount_inc(&skb->users);
- }
- }
- if (*skb2 != NULL) {
- if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf) {
- skb_set_owner_r(*skb2, sk);
- skb_queue_tail(&sk->sk_receive_queue, *skb2);
- sk->sk_data_ready(sk);
- *skb2 = NULL;
- err = 0;
- }
+ if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf)
+ return err;
+
+ skb = skb_clone(skb, allocation);
+
+ if (skb) {
+ skb_set_owner_r(skb, sk);
+ skb_queue_tail(&sk->sk_receive_queue, skb);
+ sk->sk_data_ready(sk);
+ err = 0;
}
- sock_put(sk);
return err;
}
@@ -234,7 +226,6 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t allocation,
{
struct netns_pfkey *net_pfkey = net_generic(net, pfkey_net_id);
struct sock *sk;
- struct sk_buff *skb2 = NULL;
int err = -ESRCH;
/* XXX Do we need something like netlink_overrun? I think
@@ -253,7 +244,7 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t allocation,
* socket.
*/
if (pfk->promisc)
- pfkey_broadcast_one(skb, &skb2, GFP_ATOMIC, sk);
+ pfkey_broadcast_one(skb, GFP_ATOMIC, sk);
/* the exact target will be processed later */
if (sk == one_sk)
@@ -268,7 +259,7 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t allocation,
continue;
}
- err2 = pfkey_broadcast_one(skb, &skb2, GFP_ATOMIC, sk);
+ err2 = pfkey_broadcast_one(skb, GFP_ATOMIC, sk);
/* Error is cleared after successful sending to at least one
* registered KM */
@@ -278,9 +269,8 @@ static int pfkey_broadcast(struct sk_buff *skb, gfp_t allocation,
rcu_read_unlock();
if (one_sk != NULL)
- err = pfkey_broadcast_one(skb, &skb2, allocation, one_sk);
+ err = pfkey_broadcast_one(skb, allocation, one_sk);
- kfree_skb(skb2);
kfree_skb(skb);
return err;
}
^ permalink raw reply related
* Re: [PATCH net] devlink: double free in devlink_resource_fill()
From: Jiri Pirko @ 2018-09-23 17:20 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Jiri Pirko, David S. Miller, netdev, kernel-janitors
In-Reply-To: <20180921080755.GA16307@mwanda>
Fri, Sep 21, 2018 at 10:07:55AM CEST, dan.carpenter@oracle.com wrote:
>Smatch reports that devlink_dpipe_send_and_alloc_skb() frees the skb
>on error so this is a double free. We fixed a bunch of these bugs in
>commit 7fe4d6dcbcb4 ("devlink: Remove redundant free on error path") but
>we accidentally overlooked this one.
>
>Fixes: d9f9b9a4d05f ("devlink: Add support for resource abstraction")
>Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path
From: Janusz Krzysztofik @ 2018-09-23 23:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Ulf Hansson, linux-doc, Tony Lindgren,
Dominik Brodowski, Peter Rosin, netdev, linux-i2c,
Peter Meerwald-Stadler, Marek Szyprowski, devel, Florian Fainelli,
Jonathan Corbet, Janusz Krzysztofik, Krzysztof Kozlowski,
Kishon Vijay Abraham I, linux-iio, Peter Korsgaard,
Geert Uytterhoeven, linux-serial, Jiri Slaby, Michael Hennerich,
Uwe Kleine-König, linux-gpio
In-Reply-To: <2785169.v6aIfS3K2k@z50>
While investigating possible reasons of GPIO fast bitmap processing
related boot hang on Samsung Snow Chromebook, reported by Marek
Szyprowski (thanks!), I've discovered one coding bug, addressed by
PATCH 1/2 of this series, and one potential regression introduced at
design level of the solution, hopefully fixed by PATCH 2/2. See
commit messages for details.
Janusz Krzysztofik (2):
gpiolib: Fix missing updates of bitmap index
gpiolib: Fix array members of same chip processed separately
The fixes should resolve the boot hang observed by Marek, however the
second change excludes that particular case from fast bitmap processing
and restores the old behaviour. Hence, it is possible still another
issue which have had an influence on that boot hang exists in the code.
In order to fully verify the fix, it would have to be tested on a
platform where an array of GPIO descriptors is used which starts from
at least two consecutive pins of one GPIO chip in hardware order,
starting ftom 0, followed by one or more pins belonging to other
chip(s).
In order to verify if separate calls to .set() chip callback for each
pin instead of one call to .set_multiple() is actually the reason of
boot hang on Samsung Snow Chromebook, the affected driver -
drivers/mmc/core/pwrseq_simple.c - would have to be temporarily
modified for testing purposes so it calls gpiod_set_value() for each
pin instead of gpiod_set_array_value() for all of them. If that would
also result in boot hang, we could be sure the issue was really the
one addressed by the second fix. Marek, could you please try to
perform such test?
Thanks,
Janusz
diffstat:
Documentation/driver-api/gpio/board.rst | 19 +++++++++----
drivers/gpio/gpiolib.c | 46 +++++++++++++++++++++-----------
2 files changed, 45 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH 1/2] gpiolib: Fix missing updates of bitmap index
From: Janusz Krzysztofik @ 2018-09-23 23:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg Kroah-Hartman,
Kishon Vijay Abraham I, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Jiri Slaby, Willy Tarreau, Geert Uytterhoeven
In-Reply-To: <20180923235336.22148-1-jmkrzyszt@gmail.com>
In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast
processing path in get/set array"), bitmap index is not updated with
next found zero bit position as it should while skipping over pins
already processed via fast bitmap path, possibly resulting in an
infinite loop. Fix it.
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
drivers/gpio/gpiolib.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a53d17745d21..7d9536a79a66 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2880,8 +2880,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
__set_bit(hwgpio, mask);
if (array_info)
- find_next_zero_bit(array_info->get_mask,
- array_size, i);
+ i = find_next_zero_bit(array_info->get_mask,
+ array_size, i);
else
i++;
} while ((i < array_size) &&
@@ -2905,7 +2905,8 @@ int gpiod_get_array_value_complex(bool raw, bool can_sleep,
trace_gpio_value(desc_to_gpio(desc), 1, value);
if (array_info)
- find_next_zero_bit(array_info->get_mask, i, j);
+ j = find_next_zero_bit(array_info->get_mask, i,
+ j);
else
j++;
}
@@ -3192,8 +3193,8 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep,
}
if (array_info)
- find_next_zero_bit(array_info->set_mask,
- array_size, i);
+ i = find_next_zero_bit(array_info->set_mask,
+ array_size, i);
else
i++;
} while ((i < array_size) &&
--
2.16.4
^ permalink raw reply related
* [PATCH 2/2] gpiolib: Fix array members of same chip processed separately
From: Janusz Krzysztofik @ 2018-09-23 23:53 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Corbet, Miguel Ojeda Sandonis, Peter Korsgaard,
Peter Rosin, Ulf Hansson, Andrew Lunn, Florian Fainelli,
David S. Miller, Dominik Brodowski, Greg Kroah-Hartman,
Kishon Vijay Abraham I, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Hartmut Knaack, Peter Meerwald-Stadler,
Jiri Slaby, Willy Tarreau, Geert Uytterhoeven
In-Reply-To: <20180923235336.22148-1-jmkrzyszt@gmail.com>
New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays
matching GPIO hardware") forcibly tries to find an array member which
has its array index number equal to its hardware pin number and set
up an array info for possible fast bitmap processing of all arrray
pins belonging to that chip which also satisfy that numbering rule.
Depending on array content, it may happen that consecutive array
members which belong to the same chip but don't have array indexes
equal to their pin hardware numbers will be split into groups, some of
them processed together via the fast bitmap path, and rest of them
separetely. However, applications may expect all those pins being
processed together with a single call to .set_multiple() chip callback,
like that was done before the change.
Limit applicability of fast bitmap processing path to cases where all
pins of consecutive array members starting from 0 which belong to the
same chip have their hardware numbers equal to their corresponding
array indexes. That should still speed up processing of applications
using whole GPIO banks as I/O ports, while not breaking simultaneous
manipulation of consecutive pins of the same chip which don't follow
the equal numbering rule.
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
---
Documentation/driver-api/gpio/board.rst | 19 +++++++++++++-----
drivers/gpio/gpiolib.c | 35 +++++++++++++++++++++++----------
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst
index c66821e033c2..a0f294e2e250 100644
--- a/Documentation/driver-api/gpio/board.rst
+++ b/Documentation/driver-api/gpio/board.rst
@@ -202,9 +202,18 @@ mapped to the device determines if the array qualifies for fast bitmap
processing. If yes, a bitmap is passed over get/set array functions directly
between a caller and a respective .get/set_multiple() callback of a GPIO chip.
-In order to qualify for fast bitmap processing, the pin mapping must meet the
+In order to qualify for fast bitmap processing, the array must meet the
following requirements:
-- it must belong to the same chip as other 'fast' pins of the function,
-- its index within the function must match its hardware number within the chip.
-
-Open drain and open source pins are excluded from fast bitmap output processing.
+- pin hardware number of array member 0 must also be 0,
+- pin hardware numbers of consecutive array members which belong to the same
+ chip as member 0 does must also match their array indexes.
+
+Otherwise fast bitmap processing path is not used in order to avoid consecutive
+pins which belong to the same chip but are not in hardware order being processed
+separately.
+
+If the array applies for fast bitmap processing path, pins which belong to
+different chips than member 0 does, as well as those with indexes different from
+their hardware pin numbers, are excluded from the fast path, both input and
+output. Moreover, open drain and open source pins are excluded from fast bitmap
+output processing.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 7d9536a79a66..6ae13e3e05f1 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -4376,11 +4376,10 @@ struct gpio_descs *__must_check gpiod_get_array(struct device *dev,
chip = gpiod_to_chip(desc);
/*
- * Select a chip of first array member
- * whose index matches its pin hardware number
- * as a candidate for fast bitmap processing.
+ * If pin hardware number of array member 0 is also 0, select
+ * its chip as a candidate for fast bitmap processing path.
*/
- if (!array_info && gpio_chip_hwgpio(desc) == descs->ndescs) {
+ if (descs->ndescs == 0 && gpio_chip_hwgpio(desc) == 0) {
struct gpio_descs *array;
bitmap_size = BITS_TO_LONGS(chip->ngpio > count ?
@@ -4414,14 +4413,30 @@ struct gpio_descs *__must_check gpiod_get_array(struct device *dev,
count - descs->ndescs);
descs->info = array_info;
}
- /*
- * Unmark members which don't qualify for fast bitmap
- * processing (different chip, not in hardware order)
- */
- if (array_info && (chip != array_info->chip ||
- gpio_chip_hwgpio(desc) != descs->ndescs)) {
+ /* Unmark array members which don't belong to the 'fast' chip */
+ if (array_info && array_info->chip != chip) {
__clear_bit(descs->ndescs, array_info->get_mask);
__clear_bit(descs->ndescs, array_info->set_mask);
+ }
+ /*
+ * Detect array members which belong to the 'fast' chip
+ * but their pins are not in hardware order.
+ */
+ else if (array_info &&
+ gpio_chip_hwgpio(desc) != descs->ndescs) {
+ /*
+ * Don't use fast path if all array members processed so
+ * far belong to the same chip as this one but its pin
+ * hardware number is different from its array index.
+ */
+ if (bitmap_full(array_info->get_mask, descs->ndescs)) {
+ array_info = NULL;
+ } else {
+ __clear_bit(descs->ndescs,
+ array_info->get_mask);
+ __clear_bit(descs->ndescs,
+ array_info->set_mask);
+ }
} else if (array_info) {
/* Exclude open drain or open source from fast output */
if (gpiochip_line_is_open_drain(chip, descs->ndescs) ||
--
2.16.4
^ permalink raw reply related
* linux-next: manual merge of the bpf-next tree with Linus' tree
From: Stephen Rothwell @ 2018-09-24 0:19 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Arnaldo Carvalho de Melo, Yonghong Song
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/lib/bpf/Build
between commit:
6d41907c630d ("tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systems")
from Linus' tree and commit:
f7010770fbac ("tools/bpf: move bpf/lib netlink related functions into a new file")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/lib/bpf/Build
index 6eb9bacd1948,512b2c0ba0d2..000000000000
--- a/tools/lib/bpf/Build
+++ b/tools/lib/bpf/Build
@@@ -1,1 -1,1 +1,1 @@@
- libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o str_error.o
-libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o netlink.o
++libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o str_error.o netlink.o
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3 1/2] netfilter: nf_tables: add SECMARK support
From: Christian Göttsche @ 2018-09-23 18:26 UTC (permalink / raw)
To: pablo, kadlec, fw, davem, netfilter-devel, coreteam, netdev,
linux-kernel, paul, sds, eparis, jmorris, serge, selinux,
linux-security-module
Add the ability to set the security context of packets within the nf_tables framework.
Add a nft_object for holding security contexts in the kernel and manipulating packets on the wire.
Convert the security context strings at rule addition time to security identifiers.
This is the same behavior like in xt_SECMARK and offers better performance than computing it per packet.
Set the maximum security context length to 256.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
---
v3: switch context string from char[] to char *
rename function to nft_secmark_compute_secid()
v2: convert security context strings to ids on rule addition time
Based on nf-next
Tested with v4.18.8
include/net/netfilter/nf_tables_core.h | 4 +
include/uapi/linux/netfilter/nf_tables.h | 18 +++-
net/netfilter/nf_tables_core.c | 28 +++++-
net/netfilter/nft_meta.c | 107 +++++++++++++++++++++++
4 files changed, 152 insertions(+), 5 deletions(-)
diff --git a/include/net/netfilter/nf_tables_core.h b/include/net/netfilter/nf_tables_core.h
index 8da837d2a..2046d104f 100644
--- a/include/net/netfilter/nf_tables_core.h
+++ b/include/net/netfilter/nf_tables_core.h
@@ -16,6 +16,10 @@ extern struct nft_expr_type nft_meta_type;
extern struct nft_expr_type nft_rt_type;
extern struct nft_expr_type nft_exthdr_type;
+#ifdef CONFIG_NETWORK_SECMARK
+extern struct nft_object_type nft_secmark_obj_type;
+#endif
+
int nf_tables_core_module_init(void);
void nf_tables_core_module_exit(void);
diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index 702e4f0be..5444e7687 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -1176,6 +1176,21 @@ enum nft_quota_attributes {
};
#define NFTA_QUOTA_MAX (__NFTA_QUOTA_MAX - 1)
+/**
+ * enum nft_secmark_attributes - nf_tables secmark object netlink attributes
+ *
+ * @NFTA_SECMARK_CTX: security context (NLA_STRING)
+ */
+enum nft_secmark_attributes {
+ NFTA_SECMARK_UNSPEC,
+ NFTA_SECMARK_CTX,
+ __NFTA_SECMARK_MAX,
+};
+#define NFTA_SECMARK_MAX (__NFTA_SECMARK_MAX - 1)
+
+/* Max security context length */
+#define NFT_SECMARK_CTX_MAXLEN 256
+
/**
* enum nft_reject_types - nf_tables reject expression reject types
*
@@ -1432,7 +1447,8 @@ enum nft_ct_timeout_timeout_attributes {
#define NFT_OBJECT_CONNLIMIT 5
#define NFT_OBJECT_TUNNEL 6
#define NFT_OBJECT_CT_TIMEOUT 7
-#define __NFT_OBJECT_MAX 8
+#define NFT_OBJECT_SECMARK 8
+#define __NFT_OBJECT_MAX 9
#define NFT_OBJECT_MAX (__NFT_OBJECT_MAX - 1)
/**
diff --git a/net/netfilter/nf_tables_core.c b/net/netfilter/nf_tables_core.c
index ffd5c0f94..3fbce3b9c 100644
--- a/net/netfilter/nf_tables_core.c
+++ b/net/netfilter/nf_tables_core.c
@@ -249,12 +249,24 @@ static struct nft_expr_type *nft_basic_types[] = {
&nft_exthdr_type,
};
+static struct nft_object_type *nft_basic_objects[] = {
+#ifdef CONFIG_NETWORK_SECMARK
+ &nft_secmark_obj_type,
+#endif
+};
+
int __init nf_tables_core_module_init(void)
{
- int err, i;
+ int err, i, j = 0;
+
+ for (i = 0; i < ARRAY_SIZE(nft_basic_objects); i++) {
+ err = nft_register_obj(nft_basic_objects[i]);
+ if (err)
+ goto err;
+ }
- for (i = 0; i < ARRAY_SIZE(nft_basic_types); i++) {
- err = nft_register_expr(nft_basic_types[i]);
+ for (j = 0; j < ARRAY_SIZE(nft_basic_types); j++) {
+ err = nft_register_expr(nft_basic_types[j]);
if (err)
goto err;
}
@@ -262,8 +274,12 @@ int __init nf_tables_core_module_init(void)
return 0;
err:
+ while (j-- > 0)
+ nft_unregister_expr(nft_basic_types[j]);
+
while (i-- > 0)
- nft_unregister_expr(nft_basic_types[i]);
+ nft_unregister_obj(nft_basic_objects[i]);
+
return err;
}
@@ -274,4 +290,8 @@ void nf_tables_core_module_exit(void)
i = ARRAY_SIZE(nft_basic_types);
while (i-- > 0)
nft_unregister_expr(nft_basic_types[i]);
+
+ i = ARRAY_SIZE(nft_basic_objects);
+ while (i-- > 0)
+ nft_unregister_obj(nft_basic_objects[i]);
}
diff --git a/net/netfilter/nft_meta.c b/net/netfilter/nft_meta.c
index 297fe7d97..c8ac0ef4b 100644
--- a/net/netfilter/nft_meta.c
+++ b/net/netfilter/nft_meta.c
@@ -543,3 +543,110 @@ struct nft_expr_type nft_meta_type __read_mostly = {
.maxattr = NFTA_META_MAX,
.owner = THIS_MODULE,
};
+
+#ifdef CONFIG_NETWORK_SECMARK
+
+struct nft_secmark {
+ u32 secid;
+ char *ctx;
+};
+
+static const struct nla_policy nft_secmark_policy[NFTA_SECMARK_MAX + 1] = {
+ [NFTA_SECMARK_CTX] = { .type = NLA_STRING, .len = NFT_SECMARK_CTX_MAXLEN },
+};
+
+static int nft_secmark_compute_secid(struct nft_secmark *priv)
+{
+ int err;
+ u32 tmp_secid = 0;
+
+ err = security_secctx_to_secid(priv->ctx, strlen(priv->ctx), &tmp_secid);
+ if (err)
+ return err;
+
+ if (!tmp_secid)
+ return -ENOENT;
+
+ err = security_secmark_relabel_packet(tmp_secid);
+ if (err)
+ return err;
+
+ priv->secid = tmp_secid;
+ return 0;
+}
+
+static void nft_secmark_obj_eval(struct nft_object *obj, struct nft_regs *regs, const struct nft_pktinfo *pkt)
+{
+ const struct nft_secmark *priv = nft_obj_data(obj);
+ struct sk_buff *skb = pkt->skb;
+
+ skb->secmark = priv->secid;
+}
+
+
+static int nft_secmark_obj_init(const struct nft_ctx *ctx, const struct nlattr * const tb[], struct nft_object *obj)
+{
+ int err;
+ struct nft_secmark *priv = nft_obj_data(obj);
+
+ if (tb[NFTA_SECMARK_CTX] == NULL)
+ return -EINVAL;
+
+ priv->ctx = nla_strdup(tb[NFTA_SECMARK_CTX], GFP_KERNEL);
+ if (!priv->ctx)
+ return -ENOMEM;
+
+ err = nft_secmark_compute_secid(priv);
+ if (err) {
+ kfree(priv->ctx);
+ return err;
+ }
+
+ security_secmark_refcount_inc();
+
+ return 0;
+}
+
+static int nft_secmark_obj_dump(struct sk_buff *skb, struct nft_object *obj, bool reset)
+{
+ int err;
+ struct nft_secmark *priv = nft_obj_data(obj);
+
+ if (nla_put_string(skb, NFTA_SECMARK_CTX, priv->ctx))
+ return -1;
+
+ if (reset) {
+ err = nft_secmark_compute_secid(priv);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
+static void nft_secmark_obj_destroy(const struct nft_ctx *ctx, struct nft_object *obj)
+{
+ struct nft_secmark *priv = nft_obj_data(obj);
+
+ security_secmark_refcount_dec();
+
+ kfree(priv->ctx);
+}
+
+static const struct nft_object_ops nft_secmark_obj_ops = {
+ .type = &nft_secmark_obj_type,
+ .size = sizeof(struct nft_secmark),
+ .init = nft_secmark_obj_init,
+ .eval = nft_secmark_obj_eval,
+ .dump = nft_secmark_obj_dump,
+ .destroy = nft_secmark_obj_destroy,
+};
+struct nft_object_type nft_secmark_obj_type __read_mostly = {
+ .type = NFT_OBJECT_SECMARK,
+ .ops = &nft_secmark_obj_ops,
+ .maxattr = NFTA_SECMARK_MAX,
+ .policy = nft_secmark_policy,
+ .owner = THIS_MODULE,
+};
+
+#endif /* CONFIG_NETWORK_SECMARK */
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: David Miller @ 2018-09-23 19:29 UTC (permalink / raw)
To: edumazet
Cc: netdev, michael.chan, ariel.elior, eric.dumazet, tariqt, saeedm,
jeffrey.t.kirsher, jakub.kicinski, songliubraving, j.vosburgh,
vfalico, andy
In-Reply-To: <20180921222752.101307-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 21 Sep 2018 15:27:37 -0700
> As diagnosed by Song Liu, ndo_poll_controller() can
> be very dangerous on loaded hosts, since the cpu
> calling ndo_poll_controller() might steal all NAPI
> contexts (for all RX/TX queues of the NIC).
>
> This capture, showing one ksoftirqd eating all cycles
> can last for unlimited amount of time, since one
> cpu is generally not able to drain all the queues under load.
>
> It seems that all networking drivers that do use NAPI
> for their TX completions, should not provide a ndo_poll_controller() :
>
> Most NAPI drivers have netpoll support already handled
> in core networking stack, since netpoll_poll_dev()
> uses poll_napi(dev) to iterate through registered
> NAPI contexts for a device.
I'm having trouble understanding the difference.
If the drivers are processing all of the RX/TX queue draining by hand
in their ndo_poll_controller() method, how is that different from the
generic code walking all of the registererd NAPI instances one by one?
^ permalink raw reply
* Re: [PATCH net v2] net: phy: fix WoL handling when suspending the PHY
From: Heiner Kallweit @ 2018-09-23 19:30 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller,
Realtek linux nic maintainers
Cc: netdev@vger.kernel.org
In-Reply-To: <75BE6B3C-DB93-4892-9059-E263374D934B@gmail.com>
On 23.09.2018 18:49, Florian Fainelli wrote:
>
>
> On September 23, 2018 6:38:21 AM PDT, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> Actually there's nothing wrong with the two changes marked as "Fixes",
>> they just revealed a problem which has been existing before.
>> After having switched r8169 to phylib it was reported that WoL from
>> shutdown doesn't work any longer (WoL from suspend isn't affected).
>> Reason is that during shutdown phy_disconnect()->phy_detach()->
>> phy_suspend() is called.
>> A similar issue occurs when the phylib state machine calls
>> phy_suspend() when handling state PHY_HALTED.
>>
>> Core of the problem is that phy_suspend() suspends the PHY when it
>> should not due to WoL. phy_suspend() checks for WoL already, but this
>> works only if the PHY driver handles WoL (what is rarely the case).
>> Typically WoL is handled by the MAC driver.
>>
>> phylib knows about this and handles it in mdio_bus_phy_may_suspend(),
>> but that's used only when suspending the system, not in other cases
>> like shutdown.
>>
>> Therefore factor out the relevant check from
>> mdio_bus_phy_may_suspend() to a new function phy_may_suspend() and
>> use it in phy_suspend().
>>
>> Last but not least change phy_detach() to call phy_suspend() before
>> attached_dev is set to NULL. phy_suspend() accesses attached_dev
>> when checking whether the MAC driver activated WoL.
>
> The rationale for the change makes sense but I am worried about a couple of things:
>
> - we have seen drivers fail to call SET_NETDEV_DEV() correctly, or sometimes it is made possible because they are Device Tree only objects without a backing parent struct device (CONFIG_OF makes it possible), so we could be missing some cases here but this is not a big deal
>
> - most Ethernet controller implementations typically set the device as a wake-up enabled device when an user issues the appropriate ethtool -s iface wol <parameters> and not at driver probe or ndo_open() time. There are exceptions like ASIX USB Ethernet adapters that AFAIR are wake-up enabled all the time. The main concern here is that at the time of suspend device_may_wakeup() evaluates to true and we keep the PHY on even though the driver/user was not requesting for WoL per-se
>
> What you encode here is definitely the behavior that Ethernet controllers should have, but we should also audit drivers that use PHYLIB and implement WoL that this is not going to regresses their power management or ability to wake up from PHY, and finally, that there is not redundant code already in place.
>
Good points. It's somehow unfortunate that we don't have a clear info
whether WoL is enabled for a netdevice or not. Instead we have to
evaluate different hints and make an educated guess (which can be
wrong like in the potential cases you described).
One idea that comes to my mind: Add a flag wol_enabled to struct net_device
and set it in ethtool_set_wol. Then we could use this new flag in phy_suspend().
This would transparently fix the issue for the most common cases.
Still we would have to think about cases like WoL being enabled w/o explicitly
configuring it (e.g. BIOS enables WoL).
What do you think?
>>
>> Fixes: f1e911d5d0df ("r8169: add basic phylib support")
>> Fixes: e8cfd9d6c772 ("net: phy: call state machine synchronously in
>> phy_stop")
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> v2:
>> - improved commit message
>> - reduced scope of patch, don't touch functionality of
>> mdio_bus_phy_suspend and mdio_bus_phy_resume
>> ---
>> drivers/net/phy/phy_device.c | 42 ++++++++++++++++++++++--------------
>> 1 file changed, 26 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy_device.c
>> b/drivers/net/phy/phy_device.c
>> index af64a9320..4cab94bae 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -75,6 +75,26 @@ extern struct phy_driver genphy_10g_driver;
>> static LIST_HEAD(phy_fixup_list);
>> static DEFINE_MUTEX(phy_fixup_lock);
>>
>> +static bool phy_may_suspend(struct phy_device *phydev)
>> +{
>> + struct net_device *netdev = phydev->attached_dev;
>> +
>> + if (!netdev)
>> + return true;
>> +
>> + /* Don't suspend PHY if the attached netdev parent may wakeup.
>> + * The parent may point to a PCI device, as in tg3 driver.
>> + */
>> + if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>> + return false;
>> +
>> + /* Also don't suspend PHY if the netdev itself may wakeup. This
>> + * is the case for devices w/o underlaying pwr. mgmt. aware bus,
>> + * e.g. SoC devices.
>> + */
>> + return !device_may_wakeup(&netdev->dev);
>> +}
>> +
>> #ifdef CONFIG_PM
>> static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>> {
>> @@ -93,20 +113,7 @@ static bool mdio_bus_phy_may_suspend(struct
>> phy_device *phydev)
>> if (!netdev)
>> return !phydev->suspended;
>>
>> - /* Don't suspend PHY if the attached netdev parent may wakeup.
>> - * The parent may point to a PCI device, as in tg3 driver.
>> - */
>> - if (netdev->dev.parent && device_may_wakeup(netdev->dev.parent))
>> - return false;
>> -
>> - /* Also don't suspend PHY if the netdev itself may wakeup. This
>> - * is the case for devices w/o underlaying pwr. mgmt. aware bus,
>> - * e.g. SoC devices.
>> - */
>> - if (device_may_wakeup(&netdev->dev))
>> - return false;
>> -
>> - return true;
>> + return phy_may_suspend(phydev);
>> }
>>
>> static int mdio_bus_phy_suspend(struct device *dev)
>> @@ -1132,9 +1139,9 @@ void phy_detach(struct phy_device *phydev)
>> sysfs_remove_link(&dev->dev.kobj, "phydev");
>> sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
>> }
>> + phy_suspend(phydev);
>> phydev->attached_dev->phydev = NULL;
>> phydev->attached_dev = NULL;
>> - phy_suspend(phydev);
>> phydev->phylink = NULL;
>>
>> phy_led_triggers_unregister(phydev);
>> @@ -1171,9 +1178,12 @@ int phy_suspend(struct phy_device *phydev)
>> struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
>> int ret = 0;
>>
>> + if (phydev->suspended)
>> + return 0;
>> +
>> /* If the device has WOL enabled, we cannot suspend the PHY */
>> phy_ethtool_get_wol(phydev, &wol);
>> - if (wol.wolopts)
>> + if (wol.wolopts || !phy_may_suspend(phydev))
>> return -EBUSY;
>>
>> if (phydev->drv && phydrv->suspend)
>
^ permalink raw reply
* Re: [PATCH net 00/15] netpoll: avoid capture effects for NAPI drivers
From: Eric Dumazet @ 2018-09-23 19:47 UTC (permalink / raw)
To: David Miller
Cc: netdev, michael.chan, Ariel Elior, Eric Dumazet, Tariq Toukan,
Saeed Mahameed, Jeff Kirsher, jakub.kicinski, songliubraving,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <20180923.122915.2174284095784692286.davem@davemloft.net>
On Sun, Sep 23, 2018 at 12:29 PM David Miller <davem@davemloft.net> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
> Date: Fri, 21 Sep 2018 15:27:37 -0700
>
> > As diagnosed by Song Liu, ndo_poll_controller() can
> > be very dangerous on loaded hosts, since the cpu
> > calling ndo_poll_controller() might steal all NAPI
> > contexts (for all RX/TX queues of the NIC).
> >
> > This capture, showing one ksoftirqd eating all cycles
> > can last for unlimited amount of time, since one
> > cpu is generally not able to drain all the queues under load.
> >
> > It seems that all networking drivers that do use NAPI
> > for their TX completions, should not provide a ndo_poll_controller() :
> >
> > Most NAPI drivers have netpoll support already handled
> > in core networking stack, since netpoll_poll_dev()
> > uses poll_napi(dev) to iterate through registered
> > NAPI contexts for a device.
>
> I'm having trouble understanding the difference.
>
> If the drivers are processing all of the RX/TX queue draining by hand
> in their ndo_poll_controller() method, how is that different from the
> generic code walking all of the registererd NAPI instances one by one?
(resent in plain text mode this time)
Reading poll_napi() and poll_one_napi() I thought that we were using
NAPI_STATE_NPSVC
and cmpxchg(&napi->poll_owner, -1, cpu) to _temporary_ [1] own each
napi at a time.
But I do see we also have this part at the beginning of poll_one_napi() :
if (!test_bit(NAPI_STATE_SCHED, &napi->state))
return;
So we probably should remove it. (The normal napi->poll() calls would
not proceed since napi->poll_owner would not be -1)
[1]
While if a cpu succeeds into setting NAPI_STATE_SCHED, it means it has
to own it as long as the
napi->poll() does not call napi_complete_done(), and this can be
forever (the capture effect)
Basically calling napi_schedule() is the dangerous part.
I believe busy_polling and netpoll are the same intruders (as they can
run on arbitrary cpus).
But netpoll is far more problematic since it iterates through all RX/TX queues.
^ permalink raw reply
* Syrian Rescue
From: Syrian Rescue @ 2018-09-23 20:09 UTC (permalink / raw)
To: Recipients
Dear Sir/Madam,
My name is Rybak Ahmed from Syria. I am a miner and i wish to introduce my Gold/Diamonds funds which I and my partner sold. Because of the constant war going on in our country my partner and his family are all dead.Hence i take this upon myself to find trustworthy partners who will be able to partner with me to obtain the document needed, in order for us to receive our $6,200,000.00 which is currently in Bank of America escrow account.
Please note that my attorney/broker will discuss further with you as to what is needed to obtain the change of name, from my partner's to yours.
Your share will be 30% and send me 70% to my account that I will give you after you have receive the US$6,200,000.00 (six million and two hundred thousand dollars).You have nothing to lose. Just indicate your readiness by writing me back to my e-mail
Looking forward to your interest.
Sincerely,
Rybak Ahmed
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: Make MLXSW_SP1_FWREV_MINOR a hard requirement
From: Andrew Lunn @ 2018-09-23 20:58 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, jiri, petrm, mlxsw
In-Reply-To: <20180923144855.26444-1-idosch@mellanox.com>
> Therefore tweak the check to accept any FW version that is:
>
> - on the same branch as the preferred version, and
> - the same as or newer than the preferred version.
Hi Ido
Do you print this information out? If the check fails, it would be
useful to know what the minimal version is.
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] netfilter: nf_tables: add requirements for connsecmark support
From: kbuild test robot @ 2018-09-24 3:03 UTC (permalink / raw)
To: Christian Göttsche
Cc: kbuild-all, pablo, kadlec, fw, davem, netfilter-devel, coreteam,
netdev, linux-kernel, paul, sds, eparis, jmorris, serge, selinux,
linux-security-module
In-Reply-To: <20180923091611.19815-2-cgzones@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on nf-next/master]
[also build test ERROR on v4.19-rc5 next-20180921]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Christian-G-ttsche/netfilter-nf_tables-add-SECMARK-support/20180923-213820
base: https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: x86_64-randconfig-s3-09241007 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
net//netfilter/nft_ct.c: In function 'nft_ct_set_eval':
>> net//netfilter/nft_ct.c:303:22: error: 'value' undeclared (first use in this function); did you mean 'false'?
if (ct->secmark != value) {
^~~~~
false
net//netfilter/nft_ct.c:303:22: note: each undeclared identifier is reported only once for each function it appears in
vim +303 net//netfilter/nft_ct.c
275
276 static void nft_ct_set_eval(const struct nft_expr *expr,
277 struct nft_regs *regs,
278 const struct nft_pktinfo *pkt)
279 {
280 const struct nft_ct *priv = nft_expr_priv(expr);
281 struct sk_buff *skb = pkt->skb;
282 #ifdef CONFIG_NF_CONNTRACK_MARK
283 u32 value = regs->data[priv->sreg];
284 #endif
285 enum ip_conntrack_info ctinfo;
286 struct nf_conn *ct;
287
288 ct = nf_ct_get(skb, &ctinfo);
289 if (ct == NULL || nf_ct_is_template(ct))
290 return;
291
292 switch (priv->key) {
293 #ifdef CONFIG_NF_CONNTRACK_MARK
294 case NFT_CT_MARK:
295 if (ct->mark != value) {
296 ct->mark = value;
297 nf_conntrack_event_cache(IPCT_MARK, ct);
298 }
299 break;
300 #endif
301 #ifdef CONFIG_NF_CONNTRACK_SECMARK
302 case NFT_CT_SECMARK:
> 303 if (ct->secmark != value) {
304 ct->secmark = value;
305 nf_conntrack_event_cache(IPCT_SECMARK, ct);
306 }
307 break;
308 #endif
309 #ifdef CONFIG_NF_CONNTRACK_LABELS
310 case NFT_CT_LABELS:
311 nf_connlabels_replace(ct,
312 ®s->data[priv->sreg],
313 ®s->data[priv->sreg],
314 NF_CT_LABELS_MAX_SIZE / sizeof(u32));
315 break;
316 #endif
317 #ifdef CONFIG_NF_CONNTRACK_EVENTS
318 case NFT_CT_EVENTMASK: {
319 struct nf_conntrack_ecache *e = nf_ct_ecache_find(ct);
320 u32 ctmask = regs->data[priv->sreg];
321
322 if (e) {
323 if (e->ctmask != ctmask)
324 e->ctmask = ctmask;
325 break;
326 }
327
328 if (ctmask && !nf_ct_is_confirmed(ct))
329 nf_ct_ecache_ext_add(ct, ctmask, 0, GFP_ATOMIC);
330 break;
331 }
332 #endif
333 default:
334 break;
335 }
336 }
337
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31606 bytes --]
^ permalink raw reply
* [net-next:master 13/221] drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
From: kbuild test robot @ 2018-09-23 21:22 UTC (permalink / raw)
To: Moritz Fischer; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 18932 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 12ba7e1045521ec9f251c93ae0a6735cc3f42337
commit: 7e8d5755be0e6c92d3b86a85e54c6a550b1910c5 [13/221] net: nixge: Add support for 64-bit platforms
config: i386-randconfig-x075-09240403 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 7e8d5755be0e6c92d3b86a85e54c6a550b1910c5
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/net//ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_release':
drivers/net//ethernet/ni/nixge.c:254:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)
^
In file included from include/linux/skbuff.h:17:0,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from drivers/net//ethernet/ni/nixge.c:7:
drivers/net//ethernet/ni/nixge.c: In function 'nixge_hw_dma_bd_init':
drivers/net//ethernet/ni/nixge.c:130:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_lo = lower_32_bits(((u64)addr)); \
^
include/linux/kernel.h:234:33: note: in definition of macro 'lower_32_bits'
#define lower_32_bits(n) ((u32)(n))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net//ethernet/ni/nixge.c:326:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:131:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_hi = upper_32_bits(((u64)addr)); \
^
include/linux/kernel.h:228:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net//ethernet/ni/nixge.c:326:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c: In function 'nixge_recv':
drivers/net//ethernet/ni/nixge.c:604:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)nixge_hw_dma_bd_get_addr(cur_p,
^
In file included from include/linux/skbuff.h:17:0,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from drivers/net//ethernet/ni/nixge.c:7:
drivers/net//ethernet/ni/nixge.c:130:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_lo = lower_32_bits(((u64)addr)); \
^
include/linux/kernel.h:234:33: note: in definition of macro 'lower_32_bits'
#define lower_32_bits(n) ((u32)(n))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:646:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(cur_p, new_skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:131:37: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(bd)->field##_hi = upper_32_bits(((u64)addr)); \
^
include/linux/kernel.h:228:35: note: in definition of macro 'upper_32_bits'
#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16))
^
>> drivers/net//ethernet/ni/nixge.c:145:2: note: in expansion of macro 'nixge_hw_dma_bd_set_addr'
nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/ni/nixge.c:646:3: note: in expansion of macro 'nixge_hw_dma_bd_set_offset'
nixge_hw_dma_bd_set_offset(cur_p, new_skb);
^~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/nixge_hw_dma_bd_set_addr +145 drivers/net//ethernet/ni/nixge.c
> 7 #include <linux/etherdevice.h>
8 #include <linux/module.h>
9 #include <linux/netdevice.h>
10 #include <linux/of_address.h>
11 #include <linux/of_mdio.h>
12 #include <linux/of_net.h>
13 #include <linux/of_platform.h>
14 #include <linux/of_irq.h>
15 #include <linux/skbuff.h>
16 #include <linux/phy.h>
17 #include <linux/mii.h>
18 #include <linux/nvmem-consumer.h>
19 #include <linux/ethtool.h>
20 #include <linux/iopoll.h>
21
22 #define TX_BD_NUM 64
23 #define RX_BD_NUM 128
24
25 /* Axi DMA Register definitions */
26 #define XAXIDMA_TX_CR_OFFSET 0x00 /* Channel control */
27 #define XAXIDMA_TX_SR_OFFSET 0x04 /* Status */
28 #define XAXIDMA_TX_CDESC_OFFSET 0x08 /* Current descriptor pointer */
29 #define XAXIDMA_TX_TDESC_OFFSET 0x10 /* Tail descriptor pointer */
30
31 #define XAXIDMA_RX_CR_OFFSET 0x30 /* Channel control */
32 #define XAXIDMA_RX_SR_OFFSET 0x34 /* Status */
33 #define XAXIDMA_RX_CDESC_OFFSET 0x38 /* Current descriptor pointer */
34 #define XAXIDMA_RX_TDESC_OFFSET 0x40 /* Tail descriptor pointer */
35
36 #define XAXIDMA_CR_RUNSTOP_MASK 0x1 /* Start/stop DMA channel */
37 #define XAXIDMA_CR_RESET_MASK 0x4 /* Reset DMA engine */
38
39 #define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
40 #define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
41 #define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
42 #define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
43
44 #define XAXIDMA_DELAY_MASK 0xFF000000 /* Delay timeout counter */
45 #define XAXIDMA_COALESCE_MASK 0x00FF0000 /* Coalesce counter */
46
47 #define XAXIDMA_DELAY_SHIFT 24
48 #define XAXIDMA_COALESCE_SHIFT 16
49
50 #define XAXIDMA_IRQ_IOC_MASK 0x00001000 /* Completion intr */
51 #define XAXIDMA_IRQ_DELAY_MASK 0x00002000 /* Delay interrupt */
52 #define XAXIDMA_IRQ_ERROR_MASK 0x00004000 /* Error interrupt */
53 #define XAXIDMA_IRQ_ALL_MASK 0x00007000 /* All interrupts */
54
55 /* Default TX/RX Threshold and waitbound values for SGDMA mode */
56 #define XAXIDMA_DFT_TX_THRESHOLD 24
57 #define XAXIDMA_DFT_TX_WAITBOUND 254
58 #define XAXIDMA_DFT_RX_THRESHOLD 24
59 #define XAXIDMA_DFT_RX_WAITBOUND 254
60
61 #define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
62 #define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
63 #define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
64 #define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
65 #define XAXIDMA_BD_STS_INT_ERR_MASK 0x10000000 /* Internal err */
66 #define XAXIDMA_BD_STS_ALL_ERR_MASK 0x70000000 /* All errors */
67 #define XAXIDMA_BD_STS_RXSOF_MASK 0x08000000 /* First rx pkt */
68 #define XAXIDMA_BD_STS_RXEOF_MASK 0x04000000 /* Last rx pkt */
69 #define XAXIDMA_BD_STS_ALL_MASK 0xFC000000 /* All status bits */
70
71 #define NIXGE_REG_CTRL_OFFSET 0x4000
72 #define NIXGE_REG_INFO 0x00
73 #define NIXGE_REG_MAC_CTL 0x04
74 #define NIXGE_REG_PHY_CTL 0x08
75 #define NIXGE_REG_LED_CTL 0x0c
76 #define NIXGE_REG_MDIO_DATA 0x10
77 #define NIXGE_REG_MDIO_ADDR 0x14
78 #define NIXGE_REG_MDIO_OP 0x18
79 #define NIXGE_REG_MDIO_CTRL 0x1c
80
81 #define NIXGE_ID_LED_CTL_EN BIT(0)
82 #define NIXGE_ID_LED_CTL_VAL BIT(1)
83
84 #define NIXGE_MDIO_CLAUSE45 BIT(12)
85 #define NIXGE_MDIO_CLAUSE22 0
86 #define NIXGE_MDIO_OP(n) (((n) & 0x3) << 10)
87 #define NIXGE_MDIO_OP_ADDRESS 0
88 #define NIXGE_MDIO_C45_WRITE BIT(0)
89 #define NIXGE_MDIO_C45_READ (BIT(1) | BIT(0))
90 #define NIXGE_MDIO_C22_WRITE BIT(0)
91 #define NIXGE_MDIO_C22_READ BIT(1)
92 #define NIXGE_MDIO_ADDR(n) (((n) & 0x1f) << 5)
93 #define NIXGE_MDIO_MMD(n) (((n) & 0x1f) << 0)
94
95 #define NIXGE_REG_MAC_LSB 0x1000
96 #define NIXGE_REG_MAC_MSB 0x1004
97
98 /* Packet size info */
99 #define NIXGE_HDR_SIZE 14 /* Size of Ethernet header */
100 #define NIXGE_TRL_SIZE 4 /* Size of Ethernet trailer (FCS) */
101 #define NIXGE_MTU 1500 /* Max MTU of an Ethernet frame */
102 #define NIXGE_JUMBO_MTU 9000 /* Max MTU of a jumbo Eth. frame */
103
104 #define NIXGE_MAX_FRAME_SIZE (NIXGE_MTU + NIXGE_HDR_SIZE + NIXGE_TRL_SIZE)
105 #define NIXGE_MAX_JUMBO_FRAME_SIZE \
106 (NIXGE_JUMBO_MTU + NIXGE_HDR_SIZE + NIXGE_TRL_SIZE)
107
108 struct nixge_hw_dma_bd {
109 u32 next_lo;
110 u32 next_hi;
111 u32 phys_lo;
112 u32 phys_hi;
113 u32 reserved3;
114 u32 reserved4;
115 u32 cntrl;
116 u32 status;
117 u32 app0;
118 u32 app1;
119 u32 app2;
120 u32 app3;
121 u32 app4;
122 u32 sw_id_offset_lo;
123 u32 sw_id_offset_hi;
124 u32 reserved6;
125 };
126
127 #ifdef CONFIG_PHYS_ADDR_T_64BIT
128 #define nixge_hw_dma_bd_set_addr(bd, field, addr) \
129 do { \
> 130 (bd)->field##_lo = lower_32_bits(((u64)addr)); \
131 (bd)->field##_hi = upper_32_bits(((u64)addr)); \
132 } while (0)
133 #else
134 #define nixge_hw_dma_bd_set_addr(bd, field, addr) \
135 ((bd)->field##_lo = lower_32_bits((addr)))
136 #endif
137
138 #define nixge_hw_dma_bd_set_phys(bd, addr) \
139 nixge_hw_dma_bd_set_addr((bd), phys, (addr))
140
141 #define nixge_hw_dma_bd_set_next(bd, addr) \
142 nixge_hw_dma_bd_set_addr((bd), next, (addr))
143
144 #define nixge_hw_dma_bd_set_offset(bd, addr) \
> 145 nixge_hw_dma_bd_set_addr((bd), sw_id_offset, (addr))
146
147 #ifdef CONFIG_PHYS_ADDR_T_64BIT
148 #define nixge_hw_dma_bd_get_addr(bd, field) \
149 (dma_addr_t)((((u64)(bd)->field##_hi) << 32) | ((bd)->field##_lo))
150 #else
151 #define nixge_hw_dma_bd_get_addr(bd, field) \
152 (dma_addr_t)((bd)->field##_lo)
153 #endif
154
155 struct nixge_tx_skb {
156 struct sk_buff *skb;
157 dma_addr_t mapping;
158 size_t size;
159 bool mapped_as_page;
160 };
161
162 struct nixge_priv {
163 struct net_device *ndev;
164 struct napi_struct napi;
165 struct device *dev;
166
167 /* Connection to PHY device */
168 struct device_node *phy_node;
169 phy_interface_t phy_mode;
170
171 int link;
172 unsigned int speed;
173 unsigned int duplex;
174
175 /* MDIO bus data */
176 struct mii_bus *mii_bus; /* MII bus reference */
177
178 /* IO registers, dma functions and IRQs */
179 void __iomem *ctrl_regs;
180 void __iomem *dma_regs;
181
182 struct tasklet_struct dma_err_tasklet;
183
184 int tx_irq;
185 int rx_irq;
186
187 /* Buffer descriptors */
188 struct nixge_hw_dma_bd *tx_bd_v;
189 struct nixge_tx_skb *tx_skb;
190 dma_addr_t tx_bd_p;
191
192 struct nixge_hw_dma_bd *rx_bd_v;
193 dma_addr_t rx_bd_p;
194 u32 tx_bd_ci;
195 u32 tx_bd_tail;
196 u32 rx_bd_ci;
197
198 u32 coalesce_count_rx;
199 u32 coalesce_count_tx;
200 };
201
202 static void nixge_dma_write_reg(struct nixge_priv *priv, off_t offset, u32 val)
203 {
204 writel(val, priv->dma_regs + offset);
205 }
206
207 static void nixge_dma_write_desc_reg(struct nixge_priv *priv, off_t offset,
208 dma_addr_t addr)
209 {
210 writel(lower_32_bits(addr), priv->dma_regs + offset);
211 #ifdef CONFIG_PHYS_ADDR_T_64BIT
212 writel(upper_32_bits(addr), priv->dma_regs + offset + 4);
213 #endif
214 }
215
216 static u32 nixge_dma_read_reg(const struct nixge_priv *priv, off_t offset)
217 {
218 return readl(priv->dma_regs + offset);
219 }
220
221 static void nixge_ctrl_write_reg(struct nixge_priv *priv, off_t offset, u32 val)
222 {
223 writel(val, priv->ctrl_regs + offset);
224 }
225
226 static u32 nixge_ctrl_read_reg(struct nixge_priv *priv, off_t offset)
227 {
228 return readl(priv->ctrl_regs + offset);
229 }
230
231 #define nixge_ctrl_poll_timeout(priv, addr, val, cond, sleep_us, timeout_us) \
232 readl_poll_timeout((priv)->ctrl_regs + (addr), (val), (cond), \
233 (sleep_us), (timeout_us))
234
235 #define nixge_dma_poll_timeout(priv, addr, val, cond, sleep_us, timeout_us) \
236 readl_poll_timeout((priv)->dma_regs + (addr), (val), (cond), \
237 (sleep_us), (timeout_us))
238
239 static void nixge_hw_dma_bd_release(struct net_device *ndev)
240 {
241 struct nixge_priv *priv = netdev_priv(ndev);
242 dma_addr_t phys_addr;
243 struct sk_buff *skb;
244 int i;
245
246 for (i = 0; i < RX_BD_NUM; i++) {
247 phys_addr = nixge_hw_dma_bd_get_addr(&priv->rx_bd_v[i],
248 phys);
249
250 dma_unmap_single(ndev->dev.parent, phys_addr,
251 NIXGE_MAX_JUMBO_FRAME_SIZE,
252 DMA_FROM_DEVICE);
253
254 skb = (struct sk_buff *)
255 nixge_hw_dma_bd_get_addr(&priv->rx_bd_v[i],
256 sw_id_offset);
257 dev_kfree_skb(skb);
258 }
259
260 if (priv->rx_bd_v)
261 dma_free_coherent(ndev->dev.parent,
262 sizeof(*priv->rx_bd_v) * RX_BD_NUM,
263 priv->rx_bd_v,
264 priv->rx_bd_p);
265
266 if (priv->tx_skb)
267 devm_kfree(ndev->dev.parent, priv->tx_skb);
268
269 if (priv->tx_bd_v)
270 dma_free_coherent(ndev->dev.parent,
271 sizeof(*priv->tx_bd_v) * TX_BD_NUM,
272 priv->tx_bd_v,
273 priv->tx_bd_p);
274 }
275
276 static int nixge_hw_dma_bd_init(struct net_device *ndev)
277 {
278 struct nixge_priv *priv = netdev_priv(ndev);
279 struct sk_buff *skb;
280 dma_addr_t phys;
281 u32 cr;
282 int i;
283
284 /* Reset the indexes which are used for accessing the BDs */
285 priv->tx_bd_ci = 0;
286 priv->tx_bd_tail = 0;
287 priv->rx_bd_ci = 0;
288
289 /* Allocate the Tx and Rx buffer descriptors. */
290 priv->tx_bd_v = dma_zalloc_coherent(ndev->dev.parent,
291 sizeof(*priv->tx_bd_v) * TX_BD_NUM,
292 &priv->tx_bd_p, GFP_KERNEL);
293 if (!priv->tx_bd_v)
294 goto out;
295
296 priv->tx_skb = devm_kcalloc(ndev->dev.parent,
297 TX_BD_NUM, sizeof(*priv->tx_skb),
298 GFP_KERNEL);
299 if (!priv->tx_skb)
300 goto out;
301
302 priv->rx_bd_v = dma_zalloc_coherent(ndev->dev.parent,
303 sizeof(*priv->rx_bd_v) * RX_BD_NUM,
304 &priv->rx_bd_p, GFP_KERNEL);
305 if (!priv->rx_bd_v)
306 goto out;
307
308 for (i = 0; i < TX_BD_NUM; i++) {
309 nixge_hw_dma_bd_set_next(&priv->tx_bd_v[i],
310 priv->tx_bd_p +
311 sizeof(*priv->tx_bd_v) *
312 ((i + 1) % TX_BD_NUM));
313 }
314
315 for (i = 0; i < RX_BD_NUM; i++) {
316 nixge_hw_dma_bd_set_next(&priv->rx_bd_v[i],
317 priv->rx_bd_p
318 + sizeof(*priv->rx_bd_v) *
319 ((i + 1) % RX_BD_NUM));
320
321 skb = netdev_alloc_skb_ip_align(ndev,
322 NIXGE_MAX_JUMBO_FRAME_SIZE);
323 if (!skb)
324 goto out;
325
> 326 nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
327 phys = dma_map_single(ndev->dev.parent, skb->data,
328 NIXGE_MAX_JUMBO_FRAME_SIZE,
329 DMA_FROM_DEVICE);
330
331 nixge_hw_dma_bd_set_phys(&priv->rx_bd_v[i], phys);
332
333 priv->rx_bd_v[i].cntrl = NIXGE_MAX_JUMBO_FRAME_SIZE;
334 }
335
336 /* Start updating the Rx channel control register */
337 cr = nixge_dma_read_reg(priv, XAXIDMA_RX_CR_OFFSET);
338 /* Update the interrupt coalesce count */
339 cr = ((cr & ~XAXIDMA_COALESCE_MASK) |
340 ((priv->coalesce_count_rx) << XAXIDMA_COALESCE_SHIFT));
341 /* Update the delay timer count */
342 cr = ((cr & ~XAXIDMA_DELAY_MASK) |
343 (XAXIDMA_DFT_RX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
344 /* Enable coalesce, delay timer and error interrupts */
345 cr |= XAXIDMA_IRQ_ALL_MASK;
346 /* Write to the Rx channel control register */
347 nixge_dma_write_reg(priv, XAXIDMA_RX_CR_OFFSET, cr);
348
349 /* Start updating the Tx channel control register */
350 cr = nixge_dma_read_reg(priv, XAXIDMA_TX_CR_OFFSET);
351 /* Update the interrupt coalesce count */
352 cr = (((cr & ~XAXIDMA_COALESCE_MASK)) |
353 ((priv->coalesce_count_tx) << XAXIDMA_COALESCE_SHIFT));
354 /* Update the delay timer count */
355 cr = (((cr & ~XAXIDMA_DELAY_MASK)) |
356 (XAXIDMA_DFT_TX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
357 /* Enable coalesce, delay timer and error interrupts */
358 cr |= XAXIDMA_IRQ_ALL_MASK;
359 /* Write to the Tx channel control register */
360 nixge_dma_write_reg(priv, XAXIDMA_TX_CR_OFFSET, cr);
361
362 /* Populate the tail pointer and bring the Rx Axi DMA engine out of
363 * halted state. This will make the Rx side ready for reception.
364 */
365 nixge_dma_write_desc_reg(priv, XAXIDMA_RX_CDESC_OFFSET, priv->rx_bd_p);
366 cr = nixge_dma_read_reg(priv, XAXIDMA_RX_CR_OFFSET);
367 nixge_dma_write_reg(priv, XAXIDMA_RX_CR_OFFSET,
368 cr | XAXIDMA_CR_RUNSTOP_MASK);
369 nixge_dma_write_desc_reg(priv, XAXIDMA_RX_TDESC_OFFSET, priv->rx_bd_p +
370 (sizeof(*priv->rx_bd_v) * (RX_BD_NUM - 1)));
371
372 /* Write to the RS (Run-stop) bit in the Tx channel control register.
373 * Tx channel is now ready to run. But only after we write to the
374 * tail pointer register that the Tx channel will start transmitting.
375 */
376 nixge_dma_write_desc_reg(priv, XAXIDMA_TX_CDESC_OFFSET, priv->tx_bd_p);
377 cr = nixge_dma_read_reg(priv, XAXIDMA_TX_CR_OFFSET);
378 nixge_dma_write_reg(priv, XAXIDMA_TX_CR_OFFSET,
379 cr | XAXIDMA_CR_RUNSTOP_MASK);
380
381 return 0;
382 out:
383 nixge_hw_dma_bd_release(ndev);
384 return -ENOMEM;
385 }
386
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32795 bytes --]
^ permalink raw reply
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