* Re: [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Masami Hiramatsu @ 2017-12-12 2:29 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Kunihiko Hayashi, Mark Rutland, Andrew Lunn, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Linux kernel mailing list, Masahiro Yamada, Rob Herring,
Philippe Ombredanne, Jassi Brar, David S. Miller,
linux-arm-kernel
In-Reply-To: <20171211134627.GU10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Hi Russell,
2017-12-11 22:46 GMT+09:00 Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>:
> On Mon, Dec 11, 2017 at 10:34:17PM +0900, Masami Hiramatsu wrote:
>> IMHO, even if we use SPDX license identifier, I recommend to use
>> C-style comments as many other files do, since it is C code.
>> If SPDX identifier requires C++ style, that is SPDX parser's issue
>> and should be fixed to get it from C-style comment.
>
> See the numerous emails on this subject already. The issue of C
> vs C++ comments has come up many times by many different people, but
> the result is the same. That's not going to happen. Linux kernel
> C files are required to use "//" for the SPDX identifier by order
> of Linus Torvalds.
OK, I got it.
>
> Linus has also revealed in that discussion that he has a preference
> for "//" style commenting for single comments, so it seems that the
> kernel coding style may change - but there is no desire for patches
> to "clean up" single line comments to use "//".
Thank you for making it clear.
Then what I'm considering is copyright notice lines. Those are usually
treat as the header lines, not single line. So
> +// SDPX-License-Identifier: GPL-2.0
> +// sni_ave.c - Socionext UniPhier AVE ethernet driver
> +// Copyright 2014 Panasonic Corporation
> +// Copyright 2015-2017 Socionext Inc.
is acceptable? or should we keep C-style header lines for new drivers?
> +// SDPX-License-Identifier: GPL-2.0
> +/*
> + * sni_ave.c - Socionext UniPhier AVE ethernet driver
> + * Copyright 2014 Panasonic Corporation
> + * Copyright 2015-2017 Socionext Inc.
> + */
I just concern that those lines are not "single". that's all. :)
>
> For further information, and to see the discussion that has already
> happened, the arguments that have been made about style, see the
> threads for the patch series that tglx has been posting wrt documenting
> the SPDX stuff for the kernel.
OK, got it.
https://lkml.org/lkml/2017/11/16/663
Thanks,
>
> Thanks (let's stop rehashing the same arguments.)
>
--
Masami Hiramatsu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Setting large MTU size on slave interfaces may stall the whole system
From: Qing Huang @ 2017-12-12 3:21 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <9f95c2a0-e4fe-270d-790a-beeb6b3e7690@oracle.com>
(resend this email in text format)
Hi,
We found an issue with the bonding driver when testing Mellanox devices.
The following test commands will stall the whole system sometimes, with
serial console
flooded with log messages from the bond_miimon_inspect() function.
Setting mtu size
to be 1500 seems okay but very rarely it may hit the same problem too.
ip address flush dev ens3f0
ip link set dev ens3f0 down
ip address flush dev ens3f1
ip link set dev ens3f1 down
[root@ca-hcl629 etc]# modprobe bonding mode=0 miimon=250 use_carrier=1
updelay=500 downdelay=500
[root@ca-hcl629 etc]# ifconfig bond0 up
[root@ca-hcl629 etc]# ifenslave bond0 ens3f0 ens3f1
[root@ca-hcl629 etc]# ip link set bond0 mtu 4500 up
Seiral console output:
** 4 printk messages dropped ** [ 3717.743761] bond0: link status down for
interface ens3f0, disabling it in 500 ms
** 5 printk messages dropped ** [ 3717.755737] bond0: link status down for
interface ens3f0, disabling it in 500 ms
** 5 printk messages dropped ** [ 3717.767758] bond0: link status down for
interface ens3f0, disabling it in 500 ms
** 4 printk messages dropped ** [ 3717.777737] bond0: link status down for
interface ens3f0, disabling it in 500 ms
or
** 4 printk messages dropped ** [274743.297863] bond0: link status down
again
after 500 ms for interface enp48s0f1
** 4 printk messages dropped ** [274743.307866] bond0: link status down
again
after 500 ms for interface enp48s0f1
** 4 printk messages dropped ** [274743.317857] bond0: link status down
again
after 500 ms for interface enp48s0f1
** 4 printk messages dropped ** [274743.327823] bond0: link status down
again
after 500 ms for interface enp48s0f1
** 4 printk messages dropped ** [274743.337817] bond0: link status down
again
after 500 ms for interface enp48s0f1
The root cause is the combined affect from commit
1f2cd845d3827412e82bf26dde0abca332ede402(Revert
"Merge branch 'bonding_monitor_locking'") and commit
de77ecd4ef02ca783f7762e04e92b3d0964be66b
("bonding: improve link-status update in mii-monitoring"). E.g.
reverting the second commit, we don't
see the problem.
It seems that when setting a large mtu size on an RoCE interface, the
RTNL mutex may be held too long by the slave
interface, causing bond_mii_monitor() to be called repeatedly at an
interval of 1 tick (1K HZ kernel configuration)
and kernel to become unresponsive.
We found two possible solutions:
#1, don't re-arm the mii monitor thread too quick if we cannot get RTNL
lock:
index b2db581..8fd587a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2266,7 +2266,6 @@ static void bond_mii_monitor(struct work_struct
*work)
/* Race avoidance with bond_close cancel of workqueue */
if (!rtnl_trylock()) {
- delay = 1;
should_notify_peers = false;
goto re_arm;
}
#2, we use printk_ratelimit() to avoid flooding log messages generated
by bond_miimon_inspect().
index b2db581..0183b7f 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2054,7 +2054,7 @@ static int bond_miimon_inspect(struct bonding *bond)
bond_propose_link_state(slave, BOND_LINK_FAIL);
commit++;
slave->delay = bond->params.downdelay;
- if (slave->delay) {
+ if (slave->delay && printk_ratelimit()) {
netdev_info(bond->dev, "link status
down for
%sinterface %s, disabling it in %d ms\n",
(BOND_MODE(bond) ==
BOND_MODE_ACTIVEBACKUP) ?
@@ -2105,7 +2105,8 @@ static int bond_miimon_inspect(struct bonding *bond)
case BOND_LINK_BACK:
if (!link_state) {
bond_propose_link_state(slave,
BOND_LINK_DOWN);
- netdev_info(bond->dev, "link status down
again after %d ms for interface %s\n",
+ if(printk_ratelimit())
+ netdev_info(bond->dev, "link status
down again after %d ms for interface %s\n",
(bond->params.updelay -
slave->delay) *
bond->params.miimon,
slave->dev->name);
Regarding the flooding messages, the netdev_info output is misleading
anyway
when bond_mii_monitor() is called at 1 tick interval due to lock
contention.
Solution #1 looks simpler and cleaner to me. Any side affect of doing that?
Thanks,
Qing
^ permalink raw reply related
* [BUG] 3com/3c59x: two possible sleep-in-atomic bugs
From: Jia-Ju Bai @ 2017-12-12 3:34 UTC (permalink / raw)
To: klassert, vortex, becker, David Miller; +Cc: netdev, Linux Kernel Mailing List
According to drivers/net/ethernet/3com/3c59x.c, the kernel module may
sleep in the interrupt handler.
The function call paths are:
boomerang_interrupt (interrupt handler)
vortex_error
vortex_up
pci_set_power_state --> may sleep
pci_enable_device --> may sleep
vortex_interrupt (interrupt handler)
vortex_error
vortex_up
pci_set_power_state --> may sleep
pci_enable_device --> may sleep
I do not find a good way to fix them, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and
checked by my code review.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()
From: Jakub Kicinski @ 2017-12-12 4:02 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, netdev, linux-kernel
In-Reply-To: <20171211155422.GA12326@ZenIV.linux.org.uk>
On Mon, 11 Dec 2017 15:54:22 +0000, Al Viro wrote:
> Essentially, it gives helpers for work with bitfields in fixed-endian.
> Suppose we have e.g. a little-endian 32bit value with fixed layout;
> expressing that as a bitfield would go like
> struct foo {
> unsigned foo:4; /* bits 0..3 */
> unsigned :2;
> unsigned bar:12; /* bits 6..17 */
> unsigned baz:14; /* bits 18..31 */
> }
> Even for host-endian it doesn't work all that well - you end up with
> ifdefs in structure definition and generated code stinks. For fixed-endian
> it gets really painful, and people tend to use explicit shift-and-mask
> kind of macros for accessing the fields (and often enough get the
> endianness conversions wrong, at that). With these primitives
>
> struct foo v <=> __le32 v
> v.foo = i ? 1 : 2 <=> v = le32_replace_bits(v, i ? 1 : 2, 0, 4)
> f(4 + v.baz) <=> f(4 + le32_get_bits(v, 18, 14))
Looks very useful. The [start bit, size] pair may not land itself
too nicely to creating defines, though. Which is why in
include/linux/bitfield.h we tried to use a shifted mask and work
backwards from that single value what the start and size are. commit
3e9b3112ec74 ("add basic register-field manipulation macros") has the
description. Could a similar trick perhaps be applicable here?
^ permalink raw reply
* Re: [PATCH net] tcp md5sig: Use skb's saddr when replying to an incoming segment
From: Eric Dumazet @ 2017-12-12 4:51 UTC (permalink / raw)
To: Christoph Paasch, David Miller; +Cc: netdev
In-Reply-To: <20171211080546.89418-1-cpaasch@apple.com>
On Mon, 2017-12-11 at 00:05 -0800, Christoph Paasch wrote:
> The MD5-key that belongs to a connection is identified by the peer's
> IP-address. When we are in tcp_v4(6)_reqsk_send_ack(), we are
> replying
> to an incoming segment from tcp_check_req() that failed the seq-
> number
> checks.
>
> Thus, to find the correct key, we need to use the skb's saddr and not
> the daddr.
>
> This bug seems to have been there since quite a while, but probably
> got
> unnoticed because the consequences are not catastrophic. We will call
> tcp_v4_reqsk_send_ack only to send a challenge-ACK back to the peer,
> thus the connection doesn't really fail.
>
> Fixes: 9501f9722922 ("tcp md5sig: Let the caller pass appropriate key
> for tcp_v{4,6}_do_calc_md5_hash().")
> Signed-off-by: Christoph Paasch <cpaasch@apple.com>
> ---
> net/ipv4/tcp_ipv4.c | 2 +-
> net/ipv6/tcp_ipv6.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* [PATCH net-next] tcp/dccp: avoid one atomic operation for timewait hashdance
From: Eric Dumazet @ 2017-12-12 5:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
First, rename __inet_twsk_hashdance() to inet_twsk_hashdance()
Then, remove one inet_twsk_put() by setting tw_refcnt to 3 instead
of 4, but adding a fat warning that we do not have the right to access
tw anymore after inet_twsk_hashdance()
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/inet_timewait_sock.h | 4 ++--
net/dccp/minisocks.c | 7 ++++---
net/ipv4/inet_timewait_sock.c | 27 +++++++++++++--------------
net/ipv4/tcp_minisocks.c | 7 ++++---
4 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/include/net/inet_timewait_sock.h b/include/net/inet_timewait_sock.h
index 1356fa6a7566bf8b53632215ef8de4b153848f9b..899495589a7ea2bf693cdda42f83cec160e861b5 100644
--- a/include/net/inet_timewait_sock.h
+++ b/include/net/inet_timewait_sock.h
@@ -93,8 +93,8 @@ struct inet_timewait_sock *inet_twsk_alloc(const struct sock *sk,
struct inet_timewait_death_row *dr,
const int state);
-void __inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
- struct inet_hashinfo *hashinfo);
+void inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
+ struct inet_hashinfo *hashinfo);
void __inet_twsk_schedule(struct inet_timewait_sock *tw, int timeo,
bool rearm);
diff --git a/net/dccp/minisocks.c b/net/dccp/minisocks.c
index 178bb9833311f83205317b07fe64cb2e45a9f734..37ccbe62eb1af3f9dffbf63323c008cc96cd8ea1 100644
--- a/net/dccp/minisocks.c
+++ b/net/dccp/minisocks.c
@@ -63,9 +63,10 @@ void dccp_time_wait(struct sock *sk, int state, int timeo)
*/
local_bh_disable();
inet_twsk_schedule(tw, timeo);
- /* Linkage updates. */
- __inet_twsk_hashdance(tw, sk, &dccp_hashinfo);
- inet_twsk_put(tw);
+ /* Linkage updates.
+ * Note that access to tw after this point is illegal.
+ */
+ inet_twsk_hashdance(tw, sk, &dccp_hashinfo);
local_bh_enable();
} else {
/* Sorry, if we're out of memory, just CLOSE this
diff --git a/net/ipv4/inet_timewait_sock.c b/net/ipv4/inet_timewait_sock.c
index b563e0c46bac2362acccf38495546a8b6b726384..277ff69a312dca1d0bc04be4b0b36db133aaf63b 100644
--- a/net/ipv4/inet_timewait_sock.c
+++ b/net/ipv4/inet_timewait_sock.c
@@ -97,7 +97,7 @@ static void inet_twsk_add_bind_node(struct inet_timewait_sock *tw,
* Essentially we whip up a timewait bucket, copy the relevant info into it
* from the SK, and mess with hash chains and list linkage.
*/
-void __inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
+void inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
struct inet_hashinfo *hashinfo)
{
const struct inet_sock *inet = inet_sk(sk);
@@ -119,18 +119,6 @@ void __inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
spin_lock(lock);
- /*
- * Step 2: Hash TW into tcp ehash chain.
- * Notes :
- * - tw_refcnt is set to 4 because :
- * - We have one reference from bhash chain.
- * - We have one reference from ehash chain.
- * - We have one reference from timer.
- * - One reference for ourself (our caller will release it).
- * We can use atomic_set() because prior spin_lock()/spin_unlock()
- * committed into memory all tw fields.
- */
- refcount_set(&tw->tw_refcnt, 4);
inet_twsk_add_node_rcu(tw, &ehead->chain);
/* Step 3: Remove SK from hash chain */
@@ -138,8 +126,19 @@ void __inet_twsk_hashdance(struct inet_timewait_sock *tw, struct sock *sk,
sock_prot_inuse_add(sock_net(sk), sk->sk_prot, -1);
spin_unlock(lock);
+
+ /* tw_refcnt is set to 3 because we have :
+ * - one reference for bhash chain.
+ * - one reference for ehash chain.
+ * - one reference for timer.
+ * We can use atomic_set() because prior spin_lock()/spin_unlock()
+ * committed into memory all tw fields.
+ * Also note that after this point, we lost our implicit reference
+ * so we are not allowed to use tw anymore.
+ */
+ refcount_set(&tw->tw_refcnt, 3);
}
-EXPORT_SYMBOL_GPL(__inet_twsk_hashdance);
+EXPORT_SYMBOL_GPL(inet_twsk_hashdance);
static void tw_timer_handler(struct timer_list *t)
{
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index b079b619b60ca577d5ef20a5065fce87acecd96c..a8384b0c11f8fa589e2ed5311899b62c80a269f8 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -316,9 +316,10 @@ void tcp_time_wait(struct sock *sk, int state, int timeo)
*/
local_bh_disable();
inet_twsk_schedule(tw, timeo);
- /* Linkage updates. */
- __inet_twsk_hashdance(tw, sk, &tcp_hashinfo);
- inet_twsk_put(tw);
+ /* Linkage updates.
+ * Note that access to tw after this point is illegal.
+ */
+ inet_twsk_hashdance(tw, sk, &tcp_hashinfo);
local_bh_enable();
} else {
/* Sorry, if we're out of memory, just CLOSE this
^ permalink raw reply related
* [PATCH v5 0/3] Add andestech atcpit100 timer
From: Rick Chen @ 2017-12-12 5:46 UTC (permalink / raw)
To: rickchen36-Re5JQEeQqe8AvxtiuMwx3w, rick-MUIXKm3Oiri1Z/+hSey0Gg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
linux-arch-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA, marc.zyngier-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
deanbo422-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
dhowells-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
linux-serial-u79uwXL29TY76Z2rM5mHXA
Changelog v5:
- Patch 1/3: Changes
- Patch 2/3: New
- Patch 3/3: Changes
[Patch 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
1 No need to split out the Makefile patch from the actual driver.
Suggested by Arnd Bergmann
2 Add of_clk.name = "PCLK" to be explicit on what we use.
Suggested by Linus Walleij
3 Remove the GENERIC_CLOCKEVENTS from Kconfig.
Suggested by Daniel Lezcano
4 Add depends on NDS32 || COMPILE_TEST in Kconfig
Suggested by Greentime Hu
[Patch 2/3] clocksource/drivers/atcpit100: VDSO support
Why implemented in timer driver, please see details from
https://lkml.org/lkml/2017/12/8/362
[PATCH v3 17/33] nds32: VDSO support.
Suggested by Mark Rutland
Here Mark Rutlan suggested as below:
You should not add properties to arbitrary DT bindings to
handle a Linux implementation detail.
Please remove this DT code, and have the drivers for those
timer blocks export this information to your vdso code somehow.
[Patch 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc
Fix incorrect description about PCLK.
Suggested by Linus Walleij
Rick Chen (3):
clocksource/drivers/atcpit100: Add andestech atcpit100 timer
clocksource/drivers/atcpit100: VDSO support
dt-bindings: timer: Add andestech atcpit100 timer binding doc
.../bindings/timer/andestech,atcpit100-timer.txt | 33 +++
drivers/clocksource/Kconfig | 7 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-atcpit100.c | 270 +++++++++++++++++++++
4 files changed, 311 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
create mode 100644 drivers/clocksource/timer-atcpit100.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v5 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer
From: Rick Chen @ 2017-12-12 5:46 UTC (permalink / raw)
To: rickchen36, rick, linux-kernel, arnd, linus.walleij,
daniel.lezcano, linux-arch, tglx, jason, marc.zyngier, robh+dt,
netdev, deanbo422, devicetree, viro, dhowells, will.deacon,
linux-serial
Cc: Greentime Hu
In-Reply-To: <1513057621-19084-1-git-send-email-rickchen36@gmail.com>
ATCPIT100 is often used on the Andes architecture,
This timer provide 4 PIT channels. Each PIT channel is a
multi-function timer, can be configured as 32,16,8 bit timers
or PWM as well.
For system timer it will set channel 1 32-bit timer0 as clock
source and count downwards until underflow and restart again.
It also set channel 0 32-bit timer0 as clock event and count
downwards until condition match. It will generate an interrupt
for handling periodically.
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Signed-off-by: Greentime Hu <green.hu@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/clocksource/Kconfig | 7 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-atcpit100.c | 255 ++++++++++++++++++++++++++++++++++
3 files changed, 263 insertions(+)
create mode 100644 drivers/clocksource/timer-atcpit100.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cc60620..8c57ef2 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -615,4 +615,11 @@ config CLKSRC_ST_LPC
Enable this option to use the Low Power controller timer
as clocksource.
+config CLKSRC_ATCPIT100
+ bool "Clocksource for AE3XX platform"
+ depends on NDS32 || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ This option enables support for the Andestech AE3XX platform timers.
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 72711f1..7d072f5 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -75,3 +75,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
obj-$(CONFIG_H8300_TPU) += h8300_tpu.o
obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
obj-$(CONFIG_X86_NUMACHIP) += numachip.o
+obj-$(CONFIG_CLKSRC_ATCPIT100) += timer-atcpit100.o
diff --git a/drivers/clocksource/timer-atcpit100.c b/drivers/clocksource/timer-atcpit100.c
new file mode 100644
index 0000000..0077fdb
--- /dev/null
+++ b/drivers/clocksource/timer-atcpit100.c
@@ -0,0 +1,255 @@
+/*
+ * Andestech ATCPIT100 Timer Device Driver Implementation
+ *
+ * Copyright (C) 2017 Andes Technology Corporation
+ * Rick Chen, Andes Technology Corporation <rick@andestech.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ */
+
+#include <linux/irq.h>
+#include <linux/clocksource.h>
+#include <linux/clockchips.h>
+#include <linux/interrupt.h>
+#include <linux/ioport.h>
+#include <linux/cpufreq.h>
+#include <linux/sched.h>
+#include <linux/sched_clock.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include "timer-of.h"
+
+/*
+ * Definition of register offsets
+ */
+
+/* ID and Revision Register */
+#define ID_REV 0x0
+
+/* Configuration Register */
+#define CFG 0x10
+
+/* Interrupt Enable Register */
+#define INT_EN 0x14
+#define CH_INT_EN(c, i) ((1<<i)<<(4*c))
+#define CH0INT0EN 0x01
+
+/* Interrupt Status Register */
+#define INT_STA 0x18
+#define CH0INT0 0x01
+
+/* Channel Enable Register */
+#define CH_EN 0x1C
+#define CH0TMR0EN 0x1
+#define CH1TMR0EN 0x10
+
+/* Channel 0 , 1 Control Register */
+#define CH0_CTL (0x20)
+#define CH1_CTL (0x20 + 0x10)
+
+/* Channel clock source , bit 3 , 0:External clock , 1:APB clock */
+#define APB_CLK BIT(3)
+
+/* Channel mode , bit 0~2 */
+#define TMR_32 0x1
+#define TMR_16 0x2
+#define TMR_8 0x3
+
+/* Channel 0 , 1 Reload Register */
+#define CH0_REL (0x24)
+#define CH1_REL (0x24 + 0x10)
+
+/* Channel 0 , 1 Counter Register */
+#define CH0_CNT (0x28)
+#define CH1_CNT (0x28 + 0x10)
+
+#define TIMER_SYNC_TICKS 3
+
+static void atcpit100_ch1_tmr0_en(void __iomem *base)
+{
+ writel(~0, base + CH1_REL);
+ writel(APB_CLK|TMR_32, base + CH1_CTL);
+}
+
+static void atcpit100_ch0_tmr0_en(void __iomem *base)
+{
+ writel(APB_CLK|TMR_32, base + CH0_CTL);
+}
+
+static void atcpit100_clkevt_time_setup(void __iomem *base, unsigned long delay)
+{
+ writel(delay, base + CH0_CNT);
+ writel(delay, base + CH0_REL);
+}
+
+static void atcpit100_timer_clear_interrupt(void __iomem *base)
+{
+ u32 val;
+
+ val = readl(base + INT_STA);
+ writel(val | CH0INT0, base + INT_STA);
+}
+
+static void atcpit100_clocksource_start(void __iomem *base)
+{
+ u32 val;
+
+ val = readl(base + CH_EN);
+ writel(val | CH1TMR0EN, base + CH_EN);
+}
+
+static void atcpit100_clkevt_time_start(void __iomem *base)
+{
+ u32 val;
+
+ val = readl(base + CH_EN);
+ writel(val | CH0TMR0EN, base + CH_EN);
+}
+
+static void atcpit100_clkevt_time_stop(void __iomem *base)
+{
+ u32 val;
+
+ atcpit100_timer_clear_interrupt(base);
+ val = readl(base + CH_EN);
+ writel(val & ~CH0TMR0EN, base + CH_EN);
+}
+
+static int atcpit100_clkevt_next_event(unsigned long evt,
+ struct clock_event_device *clkevt)
+{
+ struct timer_of *to = to_timer_of(clkevt);
+
+ writel(evt, timer_of_base(to) + CH0_REL);
+
+ return 0;
+}
+
+static int atcpit100_clkevt_set_periodic(struct clock_event_device *evt)
+{
+ struct timer_of *to = to_timer_of(evt);
+
+ atcpit100_clkevt_time_setup(timer_of_base(to), timer_of_period(to));
+ atcpit100_clkevt_time_start(timer_of_base(to));
+
+ return 0;
+}
+static int atcpit100_clkevt_shutdown(struct clock_event_device *evt)
+{
+ struct timer_of *to = to_timer_of(evt);
+
+ atcpit100_clkevt_time_stop(timer_of_base(to));
+
+ return 0;
+}
+static int atcpit100_clkevt_set_oneshot(struct clock_event_device *evt)
+{
+ struct timer_of *to = to_timer_of(evt);
+ u32 val;
+
+ writel(~0x0, timer_of_base(to) + CH0_REL);
+ val = readl(timer_of_base(to) + CH_EN);
+ writel(val | CH0TMR0EN, timer_of_base(to) + CH_EN);
+
+ return 0;
+}
+
+static irqreturn_t atcpit100_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *evt = (struct clock_event_device *)dev_id;
+ struct timer_of *to = to_timer_of(evt);
+
+ atcpit100_timer_clear_interrupt(timer_of_base(to));
+
+ evt->event_handler(evt);
+
+ return IRQ_HANDLED;
+}
+
+static struct timer_of to = {
+ .flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE,
+
+ .clkevt = {
+ .name = "atcpit100_tick",
+ .rating = 300,
+ .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
+ .set_state_shutdown = atcpit100_clkevt_shutdown,
+ .set_state_periodic = atcpit100_clkevt_set_periodic,
+ .set_state_oneshot = atcpit100_clkevt_set_oneshot,
+ .tick_resume = atcpit100_clkevt_shutdown,
+ .set_next_event = atcpit100_clkevt_next_event,
+ .cpumask = cpu_all_mask,
+ },
+
+ .of_irq = {
+ .handler = atcpit100_timer_interrupt,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
+ },
+
+ /*
+ * FIXME: we currently only support clocking using PCLK
+ * and using EXTCLK is not supported in the driver.
+ */
+ .of_clk = {
+ .name = "PCLK",
+ }
+};
+
+static u64 notrace atcpit100_timer_sched_read(void)
+{
+ return ~readl(timer_of_base(&to) + CH1_CNT);
+}
+
+static int __init atcpit100_timer_init(struct device_node *node)
+{
+ int ret;
+ u32 val;
+ void __iomem *base;
+
+ ret = timer_of_init(node, &to);
+ if (ret)
+ return ret;
+
+ base = timer_of_base(&to);
+
+ sched_clock_register(atcpit100_timer_sched_read, 32,
+ timer_of_rate(&to));
+
+ ret = clocksource_mmio_init(base + CH1_CNT,
+ node->name, timer_of_rate(&to), 300, 32,
+ clocksource_mmio_readl_down);
+
+ if (ret) {
+ pr_err("Failed to register clocksource\n");
+ return ret;
+ }
+
+ /* clear channel 0 timer0 interrupt */
+ atcpit100_timer_clear_interrupt(base);
+
+ clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
+ TIMER_SYNC_TICKS, 0xffffffff);
+ atcpit100_ch0_tmr0_en(base);
+ atcpit100_ch1_tmr0_en(base);
+ atcpit100_clocksource_start(base);
+ atcpit100_clkevt_time_start(base);
+
+ /* Enable channel 0 timer0 interrupt */
+ val = readl(base + INT_EN);
+ writel(val | CH0INT0EN, base + INT_EN);
+
+ return ret;
+}
+
+TIMER_OF_DECLARE(atcpit100, "andestech,atcpit100", atcpit100_timer_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/3] clocksource/drivers/atcpit100: VDSO support
From: Rick Chen @ 2017-12-12 5:47 UTC (permalink / raw)
To: rickchen36, rick, linux-kernel, arnd, linus.walleij,
daniel.lezcano, linux-arch, tglx, jason, marc.zyngier, robh+dt,
netdev, deanbo422, devicetree, viro, dhowells, will.deacon,
linux-serial
Cc: Vincent Chen, Greentime Hu
In-Reply-To: <1513057621-19084-1-git-send-email-rickchen36@gmail.com>
VDSO needs real-time cycle count to ensure the time accuracy.
Unlike others, nds32 architecture does not define clock source,
hence VDSO needs atcpit100 offering real-time cycle count
to derive the correct time.
Signed-off-by: Vincent Chen <vincentc@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Signed-off-by: Greentime Hu <green.hu@gmail.com>
---
drivers/clocksource/timer-atcpit100.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/clocksource/timer-atcpit100.c b/drivers/clocksource/timer-atcpit100.c
index 0077fdb..1be6c0a 100644
--- a/drivers/clocksource/timer-atcpit100.c
+++ b/drivers/clocksource/timer-atcpit100.c
@@ -29,6 +29,9 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include "timer-of.h"
+#ifdef CONFIG_NDS32
+#include <asm/vdso_timer_info.h>
+#endif
/*
* Definition of register offsets
@@ -211,6 +214,14 @@ static u64 notrace atcpit100_timer_sched_read(void)
return ~readl(timer_of_base(&to) + CH1_CNT);
}
+#ifdef CONFIG_NDS32
+static void fill_vdso_need_info(void)
+{
+ timer_info.cycle_count_down = true;
+ timer_info.cycle_count_reg_offset = CH1_CNT;
+}
+#endif
+
static int __init atcpit100_timer_init(struct device_node *node)
{
int ret;
@@ -249,6 +260,10 @@ static int __init atcpit100_timer_init(struct device_node *node)
val = readl(base + INT_EN);
writel(val | CH0INT0EN, base + INT_EN);
+#ifdef CONFIG_NDS32
+ fill_vdso_need_info();
+#endif
+
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc
From: Rick Chen @ 2017-12-12 5:47 UTC (permalink / raw)
To: rickchen36, rick, linux-kernel, arnd, linus.walleij,
daniel.lezcano, linux-arch, tglx, jason, marc.zyngier, robh+dt,
netdev, deanbo422, devicetree, viro, dhowells, will.deacon,
linux-serial
Cc: Greentime Hu
In-Reply-To: <1513057621-19084-1-git-send-email-rickchen36@gmail.com>
Add a document to describe Andestech atcpit100 timer and
binding information.
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Signed-off-by: Greentime Hu <green.hu@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/timer/andestech,atcpit100-timer.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
new file mode 100644
index 0000000..14812f68
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
@@ -0,0 +1,33 @@
+Andestech ATCPIT100 timer
+------------------------------------------------------------------
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible : Should be "andestech,atcpit100"
+- reg : Address and length of the register set
+- interrupts : Reference to the timer interrupt
+- clocks : a clock to provide the tick rate for "andestech,atcpit100"
+- clock-names : should be "PCLK" for the peripheral clock source.
+
+Examples:
+
+timer0: timer@f0400000 {
+ compatible = "andestech,atcpit100";
+ reg = <0xf0400000 0x1000>;
+ interrupts = <2 4>;
+ clocks = <&apb>;
+ clock-names = "PCLK";
+};
--
2.7.4
^ permalink raw reply related
* Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()
From: Al Viro @ 2017-12-12 6:20 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Linus Torvalds, netdev, linux-kernel
In-Reply-To: <20171211200224.23bc5df4@cakuba.netronome.com>
On Mon, Dec 11, 2017 at 08:02:24PM -0800, Jakub Kicinski wrote:
> On Mon, 11 Dec 2017 15:54:22 +0000, Al Viro wrote:
> > Essentially, it gives helpers for work with bitfields in fixed-endian.
> > Suppose we have e.g. a little-endian 32bit value with fixed layout;
> > expressing that as a bitfield would go like
> > struct foo {
> > unsigned foo:4; /* bits 0..3 */
> > unsigned :2;
> > unsigned bar:12; /* bits 6..17 */
> > unsigned baz:14; /* bits 18..31 */
> > }
> > Even for host-endian it doesn't work all that well - you end up with
> > ifdefs in structure definition and generated code stinks. For fixed-endian
> > it gets really painful, and people tend to use explicit shift-and-mask
> > kind of macros for accessing the fields (and often enough get the
> > endianness conversions wrong, at that). With these primitives
> >
> > struct foo v <=> __le32 v
> > v.foo = i ? 1 : 2 <=> v = le32_replace_bits(v, i ? 1 : 2, 0, 4)
> > f(4 + v.baz) <=> f(4 + le32_get_bits(v, 18, 14))
>
> Looks very useful. The [start bit, size] pair may not land itself
> too nicely to creating defines, though. Which is why in
> include/linux/bitfield.h we tried to use a shifted mask and work
> backwards from that single value what the start and size are. commit
> 3e9b3112ec74 ("add basic register-field manipulation macros") has the
> description. Could a similar trick perhaps be applicable here?
Umm... What's wrong with
#define FIELD_FOO 0,4
#define FIELD_BAR 6,12
#define FIELD_BAZ 18,14
A macro can bloody well expand to any sequence of tokens - le32_get_bits(v, FIELD_BAZ)
will become le32_get_bits(v, 18, 14) just fine. What's the problem with that?
^ permalink raw reply
* Re: [PATCH] ptr_ring: add barriers
From: George Cherian @ 2017-12-12 6:28 UTC (permalink / raw)
To: David Miller, mst
Cc: linux-kernel, george.cherian, jasowang, edumazet, netdev,
virtualization
In-Reply-To: <20171211.105308.1899676147655539775.davem@davemloft.net>
Hi David,
On 12/11/2017 09:23 PM, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Tue, 5 Dec 2017 21:29:37 +0200
>
>> Users of ptr_ring expect that it's safe to give the
>> data structure a pointer and have it be available
>> to consumers, but that actually requires an smb_wmb
>> or a stronger barrier.
>>
>> In absence of such barriers and on architectures that reorder writes,
>> consumer might read an un=initialized value from an skb pointer stored
>> in the skb array. This was observed causing crashes.
>>
>> To fix, add memory barriers. The barrier we use is a wmb, the
>> assumption being that producers do not need to read the value so we do
>> not need to order these reads.
>>
>> Reported-by: George Cherian <george.cherian@cavium.com>
>> Suggested-by: Jason Wang <jasowang@redhat.com>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> I'm asked for asking for testing feedback and did not get it in a
> reasonable amount of time.
>
The tests have completed more than 48 hours without any failures.
I won't interrupt the same and run for longer time.
In case of any issue I will report the same.
> So I'm applying this as-is, and queueing it up for -stable.
>
> Thank you.
Regards,
-George
>
^ permalink raw reply
* [PATCH v2 0/3] r8169: extend PCI core and switch to device-managed functions in probe
From: Heiner Kallweit @ 2017-12-12 6:34 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
Probe error path and remove callback can be significantly simplified
by using device-managed functions. To be able to do this in the r8169
driver we need a device-managed version of pci_set_mwi first.
v2:
Change patch 1 based on Björn's review comments and add his Acked-by.
Heiner Kallweit (3):
PCI: Add pcim_set_mwi(), a device-managed pci_set_mwi()
r8169: switch to device-managed functions in probe
r8169: remove netif_napi_del in probe error path
drivers/net/ethernet/realtek/r8169.c | 87 +++++++++---------------------------
drivers/pci/pci.c | 25 +++++++++++
include/linux/pci.h | 1 +
3 files changed, 46 insertions(+), 67 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v2 1/3] PCI: Add pcim_set_mwi(), a device-managed pci_set_mwi()
From: Heiner Kallweit @ 2017-12-12 6:40 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
Add pcim_set_mwi(), a device-managed version of pci_set_mwi().
First user is the Realtek r8169 driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
v2:
- Reorder calls
- Adjust and commit message
---
drivers/pci/pci.c | 25 +++++++++++++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4a7c6864f..764ca7b88 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1458,6 +1458,7 @@ struct pci_devres {
unsigned int pinned:1;
unsigned int orig_intx:1;
unsigned int restore_intx:1;
+ unsigned int mwi:1;
u32 region_mask;
};
@@ -1476,6 +1477,9 @@ static void pcim_release(struct device *gendev, void *res)
if (this->region_mask & (1 << i))
pci_release_region(dev, i);
+ if (this->mwi)
+ pci_clear_mwi(dev);
+
if (this->restore_intx)
pci_intx(dev, this->orig_intx);
@@ -3760,6 +3764,27 @@ int pci_set_mwi(struct pci_dev *dev)
}
EXPORT_SYMBOL(pci_set_mwi);
+/**
+ * pcim_set_mwi - a device-managed pci_set_mwi()
+ * @dev: the PCI device for which MWI is enabled
+ *
+ * Managed pci_set_mwi().
+ *
+ * RETURNS: An appropriate -ERRNO error value on error, or zero for success.
+ */
+int pcim_set_mwi(struct pci_dev *dev)
+{
+ struct pci_devres *dr;
+
+ dr = find_pci_dr(dev);
+ if (!dr)
+ return -ENOMEM;
+
+ dr->mwi = 1;
+ return pci_set_mwi(dev);
+}
+EXPORT_SYMBOL(pcim_set_mwi);
+
/**
* pci_try_set_mwi - enables memory-write-invalidate PCI transaction
* @dev: the PCI device for which MWI is enabled
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 978aad784..0a7ac863a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1064,6 +1064,7 @@ int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state);
int pci_set_cacheline_size(struct pci_dev *dev);
#define HAVE_PCI_SET_MWI
int __must_check pci_set_mwi(struct pci_dev *dev);
+int __must_check pcim_set_mwi(struct pci_dev *dev);
int pci_try_set_mwi(struct pci_dev *dev);
void pci_clear_mwi(struct pci_dev *dev);
void pci_intx(struct pci_dev *dev, int enable);
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/3] r8169: remove netif_napi_del in probe error path
From: Heiner Kallweit @ 2017-12-12 6:41 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
netif_napi_del is called implicitely by free_netdev, therefore we
don't have to do it explicitely.
When the probe error path is reached, the net_device isn't
registered yet. Therefore reordering the call to netif_napi_del
shouldn't cause any issues.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- no changes
---
drivers/net/ethernet/realtek/r8169.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3c7d90d3a..857f67beb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -8672,14 +8672,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
GFP_KERNEL);
- if (!tp->counters) {
- rc = -ENOMEM;
- goto err_out_msi_5;
- }
+ if (!tp->counters)
+ return -ENOMEM;
rc = register_netdev(dev);
if (rc < 0)
- goto err_out_msi_5;
+ return rc;
pci_set_drvdata(pdev, dev);
@@ -8709,11 +8707,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
netif_carrier_off(dev);
return 0;
-
-err_out_msi_5:
- netif_napi_del(&tp->napi);
-
- return rc;
}
static struct pci_driver rtl8169_pci_driver = {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/3] r8169: switch to device-managed functions in probe
From: Heiner Kallweit @ 2017-12-12 6:41 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
Simplify probe error path and remove callback by using device-managed
functions.
rtl_disable_msi isn't needed any longer because the release callback
of pcim_enable_device does this implicitely.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- no changes
---
drivers/net/ethernet/realtek/r8169.c | 80 +++++++++---------------------------
1 file changed, 20 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index fc0d5fa65..3c7d90d3a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4643,16 +4643,6 @@ static void rtl8169_phy_timer(struct timer_list *t)
rtl_schedule_task(tp, RTL_FLAG_TASK_PHY_PENDING);
}
-static void rtl8169_release_board(struct pci_dev *pdev, struct net_device *dev,
- void __iomem *ioaddr)
-{
- iounmap(ioaddr);
- pci_release_regions(pdev);
- pci_clear_mwi(pdev);
- pci_disable_device(pdev);
- free_netdev(dev);
-}
-
DECLARE_RTL_COND(rtl_phy_reset_cond)
{
return tp->phy_reset_pending(tp);
@@ -4784,14 +4774,6 @@ static int rtl_tbi_ioctl(struct rtl8169_private *tp, struct mii_ioctl_data *data
return -EOPNOTSUPP;
}
-static void rtl_disable_msi(struct pci_dev *pdev, struct rtl8169_private *tp)
-{
- if (tp->features & RTL_FEATURE_MSI) {
- pci_disable_msi(pdev);
- tp->features &= ~RTL_FEATURE_MSI;
- }
-}
-
static void rtl_init_mdio_ops(struct rtl8169_private *tp)
{
struct mdio_ops *ops = &tp->mdio_ops;
@@ -8256,9 +8238,6 @@ static void rtl_remove_one(struct pci_dev *pdev)
unregister_netdev(dev);
- dma_free_coherent(&tp->pci_dev->dev, sizeof(*tp->counters),
- tp->counters, tp->counters_phys_addr);
-
rtl_release_firmware(tp);
if (pci_dev_run_wake(pdev))
@@ -8266,9 +8245,6 @@ static void rtl_remove_one(struct pci_dev *pdev)
/* restore original MAC address */
rtl_rar_set(tp, dev->perm_addr);
-
- rtl_disable_msi(pdev, tp);
- rtl8169_release_board(pdev, dev, tp->mmio_addr);
}
static const struct net_device_ops rtl_netdev_ops = {
@@ -8445,11 +8421,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
MODULENAME, RTL8169_VERSION);
}
- dev = alloc_etherdev(sizeof (*tp));
- if (!dev) {
- rc = -ENOMEM;
- goto out;
- }
+ dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
+ if (!dev)
+ return -ENOMEM;
SET_NETDEV_DEV(dev, &pdev->dev);
dev->netdev_ops = &rtl_netdev_ops;
@@ -8472,13 +8446,13 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
PCIE_LINK_STATE_CLKPM);
/* enable device (incl. PCI PM wakeup and hotplug setup) */
- rc = pci_enable_device(pdev);
+ rc = pcim_enable_device(pdev);
if (rc < 0) {
netif_err(tp, probe, dev, "enable failure\n");
- goto err_out_free_dev_1;
+ return rc;
}
- if (pci_set_mwi(pdev) < 0)
+ if (pcim_set_mwi(pdev) < 0)
netif_info(tp, probe, dev, "Mem-Wr-Inval unavailable\n");
/* make sure PCI base addr 1 is MMIO */
@@ -8486,30 +8460,28 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
netif_err(tp, probe, dev,
"region #%d not an MMIO resource, aborting\n",
region);
- rc = -ENODEV;
- goto err_out_mwi_2;
+ return -ENODEV;
}
/* check for weird/broken PCI region reporting */
if (pci_resource_len(pdev, region) < R8169_REGS_SIZE) {
netif_err(tp, probe, dev,
"Invalid PCI region size(s), aborting\n");
- rc = -ENODEV;
- goto err_out_mwi_2;
+ return -ENODEV;
}
rc = pci_request_regions(pdev, MODULENAME);
if (rc < 0) {
netif_err(tp, probe, dev, "could not request regions\n");
- goto err_out_mwi_2;
+ return rc;
}
/* ioremap MMIO region */
- ioaddr = ioremap(pci_resource_start(pdev, region), R8169_REGS_SIZE);
+ ioaddr = devm_ioremap(&pdev->dev, pci_resource_start(pdev, region),
+ R8169_REGS_SIZE);
if (!ioaddr) {
netif_err(tp, probe, dev, "cannot remap MMIO, aborting\n");
- rc = -EIO;
- goto err_out_free_res_3;
+ return -EIO;
}
tp->mmio_addr = ioaddr;
@@ -8535,7 +8507,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (rc < 0) {
netif_err(tp, probe, dev, "DMA configuration failed\n");
- goto err_out_unmap_4;
+ return rc;
}
}
@@ -8697,8 +8669,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->rtl_fw = RTL_FIRMWARE_UNKNOWN;
- tp->counters = dma_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
- &tp->counters_phys_addr, GFP_KERNEL);
+ tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
+ &tp->counters_phys_addr,
+ GFP_KERNEL);
if (!tp->counters) {
rc = -ENOMEM;
goto err_out_msi_5;
@@ -8706,7 +8679,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
rc = register_netdev(dev);
if (rc < 0)
- goto err_out_cnt_6;
+ goto err_out_msi_5;
pci_set_drvdata(pdev, dev);
@@ -8735,25 +8708,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
netif_carrier_off(dev);
-out:
- return rc;
+ return 0;
-err_out_cnt_6:
- dma_free_coherent(&pdev->dev, sizeof(*tp->counters), tp->counters,
- tp->counters_phys_addr);
err_out_msi_5:
netif_napi_del(&tp->napi);
- rtl_disable_msi(pdev, tp);
-err_out_unmap_4:
- iounmap(ioaddr);
-err_out_free_res_3:
- pci_release_regions(pdev);
-err_out_mwi_2:
- pci_clear_mwi(pdev);
- pci_disable_device(pdev);
-err_out_free_dev_1:
- free_netdev(dev);
- goto out;
+
+ return rc;
}
static struct pci_driver rtl8169_pci_driver = {
--
2.15.1
^ permalink raw reply related
* Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530
From: Sean Wang @ 2017-12-12 6:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20171207152415.GB24750-g2DYL2Zd6BY@public.gmane.org>
Hi, Andrew
All sounds reasonable. All will be fixed in the next version.
Sean
On Thu, 2017-12-07 at 16:24 +0100, Andrew Lunn wrote:
> > static void
> > +mt7530_port_set_vlan_unware(struct dsa_switch *ds, int port)
> > +{
> > + struct mt7530_priv *priv = ds->priv;
> > + int i;
> > + bool all_user_ports_removed = true;
>
> Hi Sean
>
> Reverse Christmas tree please.
>
will be fixed
> > +static int
> > +mt7530_vlan_cmd(struct mt7530_priv *priv, enum mt7530_vlan_cmd cmd, u16 vid)
> > +{
> > + u32 val;
> > + int ret;
> > + struct mt7530_dummy_poll p;
>
> Here too.
>
will be fixed
> > +static int
> > +mt7530_port_vlan_prepare(struct dsa_switch *ds, int port,
> > + const struct switchdev_obj_port_vlan *vlan,
> > + struct switchdev_trans *trans)
> > +{
> > + struct mt7530_priv *priv = ds->priv;
> > +
> > + /* The port is being kept as VLAN-unware port when bridge is set up
> > + * with vlan_filtering not being set, Otherwise, the port and the
> > + * corresponding CPU port is required the setup for becoming a
> > + * VLAN-ware port.
> > + */
> > + if (!priv->ports[port].vlan_filtering)
> > + return 0;
> > +
> > + mt7530_port_set_vlan_ware(ds, port);
> > + mt7530_port_set_vlan_ware(ds, MT7530_CPU_PORT);
>
> A prepare function should just validate that it is possible to carry
> out the operation. It should not change any state. These two last
> lines probably don't belong here.
>
okay, it will be moved into the proper place such as
mt7530_port_vlan_filtering
> > +
> > + return 0;
> > +}
> > +
> > +static void
> > +mt7530_hw_vlan_add(struct mt7530_priv *priv,
> > + struct mt7530_hw_vlan_entry *entry)
> > +{
> > + u32 val;
> > + u8 new_members;
>
> Reverse Christmas tree. Please check the whole patch.
>
will be fixed
> > +static inline void INIT_MT7530_HW_ENTRY(struct mt7530_hw_vlan_entry *e,
> > + int port, bool untagged)
> > +{
> > + e->port = port;
> > + e->untagged = untagged;
> > +}
>
> All CAPITAL letters is for #defines. This is just a normal
> function. Please use lower case.
>
will be fixed
> Andrew
>
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag
From: Sean Wang @ 2017-12-12 7:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <20171207153016.GC24750@lunn.ch>
On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> > {
> > struct dsa_port *dp = dsa_slave_to_port(dev);
> > u8 *mtk_tag;
> > + bool is_vlan_skb = true;
>
> ..
>
> > + /* Mark tag attribute on special tag insertion to notify hardware
> > + * whether that's a combined special tag with 802.1Q header.
> > + */
> > + mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > + MTK_HDR_XMIT_UNTAGGED;
> > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > - mtk_tag[2] = 0;
> > - mtk_tag[3] = 0;
> > +
> > + /* Tag control information is kept for 802.1Q */
> > + if (!is_vlan_skb) {
> > + mtk_tag[2] = 0;
> > + mtk_tag[3] = 0;
> > + }
> >
> > return skb;
> > }
>
> Hi Sean
>
> So you can mark a packet for egress. What about ingress? How do you
> know the VLAN/PORT combination for packets the CPU receives? I would
> of expected a similar change to mtk_tag_rcv().
>
> Andrew
Hi, Andrew
It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
present since it is able to put the VLAN tag after the special tag and
then follow the existing way to parse.
Sean
^ permalink raw reply
* Re: [PATCH bpf 2/3] bpf: fix build issues on um due to mising bpf_perf_event.h
From: Richard Weinberger @ 2017-12-12 7:55 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev, Hendrik Brueckner
In-Reply-To: <20171212012532.30268-3-daniel@iogearbox.net>
Am Dienstag, 12. Dezember 2017, 02:25:31 CET schrieb Daniel Borkmann:
> Since c895f6f703ad ("bpf: correct broken uapi for
> BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build
> on i386 or x86_64:
>
> [...]
> CC init/main.o
> In file included from ../include/linux/perf_event.h:18:0,
> from ../include/linux/trace_events.h:10,
> from ../include/trace/syscall.h:7,
> from ../include/linux/syscalls.h:82,
> from ../init/main.c:20:
> ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
> asm/bpf_perf_event.h: No such file or directory #include
> <asm/bpf_perf_event.h>
> [...]
>
> Lets add missing bpf_perf_event.h also to um arch. This seems
> to be the only one still missing.
>
> Fixes: c895f6f703ad ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT
> program type") Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Suggested-by: Richard Weinberger <richard@sigma-star.at>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
> Cc: Richard Weinberger <richard@sigma-star.at>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
> arch/um/include/asm/Kbuild | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
> index 50a32c3..73c57f6 100644
> --- a/arch/um/include/asm/Kbuild
> +++ b/arch/um/include/asm/Kbuild
> @@ -1,4 +1,5 @@
> generic-y += barrier.h
> +generic-y += bpf_perf_event.h
> generic-y += bug.h
> generic-y += clkdev.h
> generic-y += current.h
Acked-by: Richard Weinberger <richard@nod.at>
Thanks,
//richard
--
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530
From: Felix Fietkau @ 2017-12-12 8:24 UTC (permalink / raw)
To: sean.wang, davem, andrew, f.fainelli, vivien.didelot
Cc: netdev, linux-kernel, linux-mediatek
In-Reply-To: <792c2d52b8da717b55ead9d480863ca390fe91b3.1512625814.git.sean.wang@mediatek.com>
On 2017-12-07 07:06, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> MT7530 can treat each port as either VLAN-unware port or VLAN-ware port
Shouldn't that be VLAN-unaware/VLAN-aware (in the code as well)?
- Felix
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag
From: Andrew Lunn @ 2017-12-12 8:28 UTC (permalink / raw)
To: Sean Wang
Cc: davem, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <1513063281.28444.25.camel@mtkswgap22>
On Tue, Dec 12, 2017 at 03:21:21PM +0800, Sean Wang wrote:
> On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> > > {
> > > struct dsa_port *dp = dsa_slave_to_port(dev);
> > > u8 *mtk_tag;
> > > + bool is_vlan_skb = true;
> >
> > ..
> >
> > > + /* Mark tag attribute on special tag insertion to notify hardware
> > > + * whether that's a combined special tag with 802.1Q header.
> > > + */
> > > + mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > > + MTK_HDR_XMIT_UNTAGGED;
> > > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > > - mtk_tag[2] = 0;
> > > - mtk_tag[3] = 0;
> > > +
> > > + /* Tag control information is kept for 802.1Q */
> > > + if (!is_vlan_skb) {
> > > + mtk_tag[2] = 0;
> > > + mtk_tag[3] = 0;
> > > + }
> > >
> > > return skb;
> > > }
> >
> > Hi Sean
> >
> > So you can mark a packet for egress. What about ingress? How do you
> > know the VLAN/PORT combination for packets the CPU receives? I would
> > of expected a similar change to mtk_tag_rcv().
> >
> > Andrew
>
> Hi, Andrew
>
> It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
> present since it is able to put the VLAN tag after the special tag and
> then follow the existing way to parse.
Hi Sean
O.K. Please mention this in the commit message. Since it was something
i was expecting, it should be documented why it is not needed.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] net: dsa: allow XAUI phy interface mode
From: Andrew Lunn @ 2017-12-12 8:35 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: David Miller, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20171211190220.GY10595@n2100.armlinux.org.uk>
> That's something like it - asked Andrew via IRC on Saturday:
>
> Do we want to do the XAUI thing as one patch to avoid any breakage, and
> if so via whom?
Hi Russell
Sorry for not replying. I was on a plane by then.
> and haven't had a response. Normally arm-soc folk want patches
> touching arch/arm/boot/dts to go via their tree.
>
> So, until I know what to do, I can't proceed with this... and I've
> soo many outstanding net patches now that I'm losing track of where
> each patch I've sent out is. Sorry, I'm failing.
I would put both patches via netdev, to avoid breakage. We have done
this before for the ZII devel board, with the imx maintainers ACK. I
don't expect any clashes in the DT file. The 10Gb port might be added
soon, but i think there is enough separation in the changes they won't
result in a conflict if they take a different path.
Do you want me to send a v2, with the additional DT patch?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530
From: Sean Wang @ 2017-12-12 8:36 UTC (permalink / raw)
To: Felix Fietkau
Cc: davem, andrew, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <94df4a0c-3e9b-a51e-6f2d-5adc43e3b9e4@nbd.name>
On Tue, 2017-12-12 at 09:24 +0100, Felix Fietkau wrote:
> On 2017-12-07 07:06, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > MT7530 can treat each port as either VLAN-unware port or VLAN-ware port
> Shouldn't that be VLAN-unaware/VLAN-aware (in the code as well)?
>
> - Felix
>
Hi, Felix
Thank you. It is my misspelling problem. I will fix them all with this
including in the code.
Sean
^ permalink raw reply
* [BUG] skge: a possible sleep-in-atomic bug in skge_remove
From: Jia-Ju Bai @ 2017-12-12 8:38 UTC (permalink / raw)
To: mlindner, stephen, shemminger, shemminger
Cc: netdev, Linux Kernel Mailing List
According to drivers/net/ethernet/marvell/skge.c, the driver may sleep
under a spinlock.
The function call path is:
skge_remove (acquire the spinlock)
free_irq --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag
From: Sean Wang @ 2017-12-12 8:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <20171212082837.GM28672@lunn.ch>
On Tue, 2017-12-12 at 09:28 +0100, Andrew Lunn wrote:
> On Tue, Dec 12, 2017 at 03:21:21PM +0800, Sean Wang wrote:
> > On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > > > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> > > > {
> > > > struct dsa_port *dp = dsa_slave_to_port(dev);
> > > > u8 *mtk_tag;
> > > > + bool is_vlan_skb = true;
> > >
> > > ..
> > >
> > > > + /* Mark tag attribute on special tag insertion to notify hardware
> > > > + * whether that's a combined special tag with 802.1Q header.
> > > > + */
> > > > + mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > > > + MTK_HDR_XMIT_UNTAGGED;
> > > > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > > > - mtk_tag[2] = 0;
> > > > - mtk_tag[3] = 0;
> > > > +
> > > > + /* Tag control information is kept for 802.1Q */
> > > > + if (!is_vlan_skb) {
> > > > + mtk_tag[2] = 0;
> > > > + mtk_tag[3] = 0;
> > > > + }
> > > >
> > > > return skb;
> > > > }
> > >
> > > Hi Sean
> > >
> > > So you can mark a packet for egress. What about ingress? How do you
> > > know the VLAN/PORT combination for packets the CPU receives? I would
> > > of expected a similar change to mtk_tag_rcv().
> > >
> > > Andrew
> >
> > Hi, Andrew
> >
> > It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
> > present since it is able to put the VLAN tag after the special tag and
> > then follow the existing way to parse.
>
> Hi Sean
>
> O.K. Please mention this in the commit message. Since it was something
> i was expecting, it should be documented why it is not needed.
>
> Thanks
> Andrew
Sure. I will add this in the commit message.
Sean
>
^ 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