* Re: [net-next 0/5] tipc: obsolete zone concept
From: David Miller @ 2018-03-17 21:12 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion, mohan.krishna.ghanta.krishnamurthy
In-Reply-To: <1521128935-6141-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 15 Mar 2018 16:48:49 +0100
> Functionality related to the 'zone' concept was never implemented in
> TIPC. In this series we eliminate the remaining traces of it in the
> code, and can hence take a first step in reducing the footprint and
> complexity of the binding table.
Series applied, thanks Jon.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH net-next 0/6] Converting pernet_operations (part #8)
From: David Miller @ 2018-03-17 21:07 UTC (permalink / raw)
To: ktkhai-5HdwGun5lf+gSpxsJD1C4w
Cc: dev-yBygre7rU0TnMu66kgdUjQ, wensong-ud5FBsm0p/xg9hUCZPvPmw,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
dsahern-Re5JQEeQqe8AvxtiuMwx3w, fw-HFFVJYpyMKqzQB+pC5nmwQ,
jchapman-Bm0nJX+W7e9BDgjK7y7TUQ, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
ja-FgGsKACvmQM, netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
rshearma-43mecJUBy8ZBDgjK7y7TUQ, g.nault-pHk1y4uTXVDytLWWfqlThQ,
pablo-Cap9r6Oaw4JrovVCs/uTlw, dwindsor-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <152110491273.28582.13804059107038714030.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
From: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
Date: Thu, 15 Mar 2018 12:10:47 +0300
> this series continues to review and to convert pernet_operations
> to make them possible to be executed in parallel for several
> net namespaces at the same time. There are different operations
> over the tree, mostly are ipvs.
Series applied, thanks Kirill.
^ permalink raw reply
* Re: [PATCH v2 net] net: sched: fix uses after free
From: David Miller @ 2018-03-17 21:04 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, john.fastabend, jhs
In-Reply-To: <20180315015300.233327-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 14 Mar 2018 18:53:00 -0700
> syzbot reported one use-after-free in pfifo_fast_enqueue() [1]
>
> Issue here is that we can not reuse skb after a successful skb_array_produce()
> since another cpu might have consumed it already.
>
> I believe a similar problem exists in try_bulk_dequeue_skb_slow()
> in case we put an skb into qdisc_enqueue_skb_bad_txq() for lockless qdisc.
...
> Fixes: c5ad119fb6c0 ("net: sched: pfifo_fast use skb_array")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot+ed43b6903ab968b16f54@syzkaller.appspotmail.com
Applied, thanks a lot Eric.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: Allow RX descriptors to be consumed before disabling NAPI.
From: David Miller @ 2018-03-17 21:01 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20180314231747.GA1263@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 14 Mar 2018 16:17:47 -0700
> From: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
>
> Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
> Acked-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
This must have a reasonable commit message added, and that commit
message must explain in detail what exactly is happening here.
But since I did read the patch I do not think that doing a looping
sleeping read is the way to fix this problem.
Instead, you should find some way to wait on the specific event that
needs to occur.
^ permalink raw reply
* Re: [PATCH 0/5] Enable XDP for ixgbevf
From: David Miller @ 2018-03-17 20:57 UTC (permalink / raw)
To: anthony.l.nguyen; +Cc: intel-wired-lan, john.fastabend, netdev
In-Reply-To: <20180316223406.7295-1-anthony.l.nguyen@intel.com>
From: Tony Nguyen <anthony.l.nguyen@intel.com>
Date: Fri, 16 Mar 2018 15:34:01 -0700
> This patch series implements support for XDP on ixgbevf;
> it is mainly based on the ixgbe implementation and supports
> the following actions: XDP_PASS, XDP_DROP, and XDP_TX.
I'm extremely pleased to see these patches.
^ permalink raw reply
* Re: [RFC 2/2] page_frag_cache: Store metadata in struct page
From: David Miller @ 2018-03-17 20:54 UTC (permalink / raw)
To: alexander.duyck; +Cc: willy, alexander.h.duyck, linux-mm, netdev, mawilcox
In-Reply-To: <CAKgT0Uf0qWbo7T8j00Owt_hEj6vZSY-MOsqUeZCek1x62DKz4Q@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Thu, 15 Mar 2018 14:26:28 -0700
> So my concern with this patch is that it is essentially trading off
> CPU performance for reduced size. One of the reasons for getting away
> from using the page pointer is because it is expensive to access the
> page when the ref_count is bouncing on multiple cache lines.
Agreed.
^ permalink raw reply
* Statement regarding NetDev conference and NetDev Society
From: David Miller @ 2018-03-17 20:25 UTC (permalink / raw)
To: netdev
As the Linux networking maintainer, I would like to make clear my
relationship with the Netdev Society and its event, the NetDev
conference. I am no longer associated with either.
I am writing to provide clarity on this situation to the subscribers
of the 'netdev' mailing list and the community at large.
Specifically, I am writing to make sure there isn't any confusion
through the use of the name "NetDev" that I either continue to plan,
support or participate in this event. I do not.
While in the past I have participated in the NetDev events as a member of
the NetDev technical committee and as a member of the NetDev Society's
board, I have formally left the board, am no longer associated with
planning the NetDev conference and do not intend to participate in future
NetDev conference events.
Having said all of this, I look forward to continued great work on the
netdev project and sharing cool advances in networking at the networking
track of Linux Plumbers Conference.
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Kees Cook @ 2018-03-17 20:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Rasmus Villemoes, Randy Dunlap, Miguel Ojeda, Ingo Molnar,
David Laight, Ian Abbott, linux-input, linux-btrfs,
Network Development, Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <CA+55aFwv0VC67cx2W9yrf7qSFKf6ncVRrsVyLGqdmfSBn4yTYw@mail.gmail.com>
On Sat, Mar 17, 2018 at 11:52 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So the above is completely insane, bit there is actually a chance that
> using that completely crazy "x -> sizeof(char[x])" conversion actually
> helps, because it really does have a (very odd) evaluation-time
> change. sizeof() has to be evaluated as part of the constant
> expression evaluation, in ways that "__builtin_constant_p()" isn't
> specified to be done.
>
> But it is also definitely me grasping at straws. If that doesn't work
> for 4.4, there's nothing else I can possibly see.
No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only
does it not change the complaint about __builtin_choose_expr(), it
also thinks that's a VLA now.
./include/linux/mm.h: In function ‘get_mm_hiwater_rss’:
./include/linux/mm.h:1567: warning: variable length array is used
./include/linux/mm.h:1567: error: first argument to
‘__builtin_choose_expr’ not a constant
6.8 is happy with it (of course).
I do think the earlier version (without the
sizeof-hiding-builting_constant_p) provides a template for a
const_max() that both you and Rasmus would be happy with, though!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH net-next 3/3] net: dsa: mv88e6xxx: Add MDIO interrupts for internal PHYs
From: Andrew Lunn @ 2018-03-17 19:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1521315125-25124-1-git-send-email-andrew@lunn.ch>
When registering an MDIO bus, it is possible to pass an array of
interrupts, one per address on the bus. phylib will then associate the
interrupt to the PHY device, if no other interrupt is provided.
Some of the global2 interrupts are PHY interrupts. Place them into the
MDIO bus structure.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 10 ++++++++++
drivers/net/dsa/mv88e6xxx/global2.c | 32 ++++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/global2.h | 16 ++++++++++++++++
3 files changed, 58 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 04226fa708e4..08a8aba216f3 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2291,12 +2291,19 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip *chip,
bus->write = mv88e6xxx_mdio_write;
bus->parent = chip->dev;
+ if (!external) {
+ err = mv88e6xxx_g2_irq_mdio_setup(chip, bus);
+ if (err)
+ return err;
+ }
+
if (np)
err = of_mdiobus_register(bus, np);
else
err = mdiobus_register(bus);
if (err) {
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
+ mv88e6xxx_g2_irq_mdio_free(chip, bus);
return err;
}
@@ -2323,6 +2330,9 @@ static void mv88e6xxx_mdios_unregister(struct mv88e6xxx_chip *chip)
list_for_each_entry(mdio_bus, &chip->mdios, list) {
bus = mdio_bus->bus;
+ if (!mdio_bus->external)
+ mv88e6xxx_g2_irq_mdio_free(chip, bus);
+
mdiobus_unregister(bus);
}
}
diff --git a/drivers/net/dsa/mv88e6xxx/global2.c b/drivers/net/dsa/mv88e6xxx/global2.c
index 5f370f1fc7c4..6c620974fef3 100644
--- a/drivers/net/dsa/mv88e6xxx/global2.c
+++ b/drivers/net/dsa/mv88e6xxx/global2.c
@@ -1107,6 +1107,38 @@ int mv88e6xxx_g2_irq_setup(struct mv88e6xxx_chip *chip)
return err;
}
+int mv88e6xxx_g2_irq_mdio_setup(struct mv88e6xxx_chip *chip,
+ struct mii_bus *bus)
+{
+ int phy, irq, err, err_phy;
+
+ for (phy = 0; phy < chip->info->num_internal_phys; phy++) {
+ irq = irq_find_mapping(chip->g2_irq.domain, phy);
+ if (irq < 0) {
+ err = irq;
+ goto out;
+ }
+ bus->irq[chip->info->port_base_addr + phy] = irq;
+ }
+ return 0;
+out:
+ err_phy = phy;
+
+ for (phy = 0; phy < err_phy; phy++)
+ irq_dispose_mapping(bus->irq[phy]);
+
+ return err;
+}
+
+void mv88e6xxx_g2_irq_mdio_free(struct mv88e6xxx_chip *chip,
+ struct mii_bus *bus)
+{
+ int phy;
+
+ for (phy = 0; phy < chip->info->num_internal_phys; phy++)
+ irq_dispose_mapping(bus->irq[phy]);
+}
+
int mv88e6xxx_g2_setup(struct mv88e6xxx_chip *chip)
{
u16 reg;
diff --git a/drivers/net/dsa/mv88e6xxx/global2.h b/drivers/net/dsa/mv88e6xxx/global2.h
index aa3f0a736966..520ec70d32e8 100644
--- a/drivers/net/dsa/mv88e6xxx/global2.h
+++ b/drivers/net/dsa/mv88e6xxx/global2.h
@@ -317,6 +317,11 @@ int mv88e6xxx_g2_setup(struct mv88e6xxx_chip *chip);
int mv88e6xxx_g2_irq_setup(struct mv88e6xxx_chip *chip);
void mv88e6xxx_g2_irq_free(struct mv88e6xxx_chip *chip);
+int mv88e6xxx_g2_irq_mdio_setup(struct mv88e6xxx_chip *chip,
+ struct mii_bus *bus);
+void mv88e6xxx_g2_irq_mdio_free(struct mv88e6xxx_chip *chip,
+ struct mii_bus *bus);
+
int mv88e6185_g2_mgmt_rsvd2cpu(struct mv88e6xxx_chip *chip);
int mv88e6352_g2_mgmt_rsvd2cpu(struct mv88e6xxx_chip *chip);
@@ -450,6 +455,17 @@ static inline void mv88e6xxx_g2_irq_free(struct mv88e6xxx_chip *chip)
{
}
+static inline int mv88e6xxx_g2_irq_mdio_setup(struct mv88e6xxx_chip *chip,
+ struct mii_bus *bus)
+{
+ return 0;
+}
+
+static inline void mv88e6xxx_g2_irq_mdio_free(struct mv88e6xxx_chip *chip,
+ struct mii_bus *bus)
+{
+}
+
static inline int mv88e6185_g2_mgmt_rsvd2cpu(struct mv88e6xxx_chip *chip)
{
return -EOPNOTSUPP;
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 1/3] net: dsa: mv88e6xxx: Add missing g1 IRQ numbers
From: Andrew Lunn @ 2018-03-17 19:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1521315125-25124-1-git-send-email-andrew@lunn.ch>
With the recent change to polling for interrupts, it is important that
the number of global 1 interrupts is listed. Without it, the driver
requests an interrupt domain for zero interrupts, which returns
EINVAL, and the probe fails.
Add two missing entries.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index bd3ee84770c7..003ce048f3c4 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3420,6 +3420,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.global2_addr = 0x1c,
.age_time_coeff = 3750,
.atu_move_port_mask = 0x1f,
+ .g1_irqs = 9,
.g2_irqs = 10,
.pvt = true,
.multi_chip = true,
@@ -3728,6 +3729,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.global2_addr = 0x1c,
.age_time_coeff = 3750,
.atu_move_port_mask = 0x1f,
+ .g1_irqs = 9,
.g2_irqs = 10,
.pvt = true,
.multi_chip = true,
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 2/3] net: dsa: mv88e6xxx: Add number of internal PHYs
From: Andrew Lunn @ 2018-03-17 19:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrew Lunn
In-Reply-To: <1521315125-25124-1-git-send-email-andrew@lunn.ch>
Add to the info structure the number of internal PHYs, if they generate
interrupts. Some of the older generations of switches have internal
PHYs, but no interrupt registers. In this case, set the count to zero.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 28 ++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/chip.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 003ce048f3c4..04226fa708e4 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3317,6 +3317,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6085",
.num_databases = 4096,
.num_ports = 10,
+ .num_internal_phys = 5,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3337,6 +3338,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6095/88E6095F",
.num_databases = 256,
.num_ports = 11,
+ .num_internal_phys = 0,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3355,6 +3357,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6097/88E6097F",
.num_databases = 4096,
.num_ports = 11,
+ .num_internal_phys = 8,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3375,6 +3378,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6123",
.num_databases = 4096,
.num_ports = 3,
+ .num_internal_phys = 5,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3395,6 +3399,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6131",
.num_databases = 256,
.num_ports = 8,
+ .num_internal_phys = 0,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3413,6 +3418,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6341",
.num_databases = 4096,
.num_ports = 6,
+ .num_internal_phys = 5,
.num_gpio = 11,
.max_vid = 4095,
.port_base_addr = 0x10,
@@ -3434,6 +3440,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6161",
.num_databases = 4096,
.num_ports = 6,
+ .num_internal_phys = 5,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3454,6 +3461,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6165",
.num_databases = 4096,
.num_ports = 6,
+ .num_internal_phys = 0,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3474,6 +3482,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6171",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3494,6 +3503,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6172",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.num_gpio = 15,
.max_vid = 4095,
.port_base_addr = 0x10,
@@ -3515,6 +3525,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6175",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3535,6 +3546,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6176",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.num_gpio = 15,
.max_vid = 4095,
.port_base_addr = 0x10,
@@ -3556,6 +3568,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6185",
.num_databases = 256,
.num_ports = 10,
+ .num_internal_phys = 0,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3574,6 +3587,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6190",
.num_databases = 4096,
.num_ports = 11, /* 10 + Z80 */
+ .num_internal_phys = 11,
.num_gpio = 16,
.max_vid = 8191,
.port_base_addr = 0x0,
@@ -3595,6 +3609,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6190X",
.num_databases = 4096,
.num_ports = 11, /* 10 + Z80 */
+ .num_internal_phys = 11,
.num_gpio = 16,
.max_vid = 8191,
.port_base_addr = 0x0,
@@ -3616,6 +3631,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6191",
.num_databases = 4096,
.num_ports = 11, /* 10 + Z80 */
+ .num_internal_phys = 11,
.max_vid = 8191,
.port_base_addr = 0x0,
.global1_addr = 0x1b,
@@ -3637,6 +3653,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6240",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.num_gpio = 15,
.max_vid = 4095,
.port_base_addr = 0x10,
@@ -3659,6 +3676,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6290",
.num_databases = 4096,
.num_ports = 11, /* 10 + Z80 */
+ .num_internal_phys = 11,
.num_gpio = 16,
.max_vid = 8191,
.port_base_addr = 0x0,
@@ -3681,6 +3699,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6320",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.num_gpio = 15,
.max_vid = 4095,
.port_base_addr = 0x10,
@@ -3688,6 +3707,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.global2_addr = 0x1c,
.age_time_coeff = 15000,
.g1_irqs = 8,
+ .g2_irqs = 10,
.atu_move_port_mask = 0xf,
.pvt = true,
.multi_chip = true,
@@ -3702,6 +3722,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6321",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.num_gpio = 15,
.max_vid = 4095,
.port_base_addr = 0x10,
@@ -3709,6 +3730,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.global2_addr = 0x1c,
.age_time_coeff = 15000,
.g1_irqs = 8,
+ .g2_irqs = 10,
.atu_move_port_mask = 0xf,
.multi_chip = true,
.tag_protocol = DSA_TAG_PROTO_EDSA,
@@ -3721,6 +3743,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.family = MV88E6XXX_FAMILY_6341,
.name = "Marvell 88E6341",
.num_databases = 4096,
+ .num_internal_phys = 5,
.num_ports = 6,
.num_gpio = 11,
.max_vid = 4095,
@@ -3744,6 +3767,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6350",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3764,6 +3788,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6351",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.max_vid = 4095,
.port_base_addr = 0x10,
.global1_addr = 0x1b,
@@ -3784,6 +3809,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6352",
.num_databases = 4096,
.num_ports = 7,
+ .num_internal_phys = 5,
.num_gpio = 15,
.max_vid = 4095,
.port_base_addr = 0x10,
@@ -3805,6 +3831,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6390",
.num_databases = 4096,
.num_ports = 11, /* 10 + Z80 */
+ .num_internal_phys = 11,
.num_gpio = 16,
.max_vid = 8191,
.port_base_addr = 0x0,
@@ -3826,6 +3853,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6390X",
.num_databases = 4096,
.num_ports = 11, /* 10 + Z80 */
+ .num_internal_phys = 11,
.num_gpio = 16,
.max_vid = 8191,
.port_base_addr = 0x0,
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index 26b9a618cdee..bad211014e91 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -110,6 +110,7 @@ struct mv88e6xxx_info {
const char *name;
unsigned int num_databases;
unsigned int num_ports;
+ unsigned int num_internal_phys;
unsigned int num_gpio;
unsigned int max_vid;
unsigned int port_base_addr;
--
2.16.2
^ permalink raw reply related
* [PATCH net-next 0/3] Automatic PHY interrupts
From: Andrew Lunn @ 2018-03-17 19:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrew Lunn
Now that the mv88e6xxx driver either installs in interrupt handler, or
polls for interrupts, it is possible to always handle PHY interrupts,
rather than have phylib perform the polling. This speeds up detection
of link changes and reduces the load on the MDIO bus, which is
beneficial for PTP.
Andrew Lunn (3):
net: dsa: mv88e6xxx: Add missing g1 IRQ numbers
net: dsa: mv88e6xxx: Add number of internal PHYs
net: dsa: mv88e6xxx: Add MDIO interrupts for internal PHYs
drivers/net/dsa/mv88e6xxx/chip.c | 40 +++++++++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/chip.h | 1 +
drivers/net/dsa/mv88e6xxx/global2.c | 32 +++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/global2.h | 16 +++++++++++++++
4 files changed, 89 insertions(+)
--
2.16.2
^ permalink raw reply
* [PATCH net-next] net: dsa: mv88e6xxx: Fix IRQ when loading module
From: Andrew Lunn @ 2018-03-17 19:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Andrew Lunn
Handle polled interrupts correctly when loading the module.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 294d711ee8c0 ("net: dsa: mv88e6xxx: Poll when no interrupt defined")
---
drivers/net/dsa/mv88e6xxx/chip.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index bd3ee84770c7..41f872d4ba3c 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4204,15 +4204,18 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev)
mv88e6xxx_unregister_switch(chip);
mv88e6xxx_mdios_unregister(chip);
- if (chip->irq > 0) {
- mv88e6xxx_g1_vtu_prob_irq_free(chip);
- mv88e6xxx_g1_atu_prob_irq_free(chip);
- if (chip->info->g2_irqs > 0)
- mv88e6xxx_g2_irq_free(chip);
- mutex_lock(&chip->reg_lock);
+ mv88e6xxx_g1_vtu_prob_irq_free(chip);
+ mv88e6xxx_g1_atu_prob_irq_free(chip);
+
+ if (chip->info->g2_irqs > 0)
+ mv88e6xxx_g2_irq_free(chip);
+
+ mutex_lock(&chip->reg_lock);
+ if (chip->irq > 0)
mv88e6xxx_g1_irq_free(chip);
- mutex_unlock(&chip->reg_lock);
- }
+ else
+ mv88e6xxx_irq_poll_free(chip);
+ mutex_unlock(&chip->reg_lock);
}
static const struct of_device_id mv88e6xxx_of_match[] = {
--
2.16.2
^ permalink raw reply related
* Re: NULL pointer dereferences with 4.14.27
From: Holger Hoffstätte @ 2018-03-17 19:12 UTC (permalink / raw)
To: Carlos Carvalho, linux-kernel, netdev
In-Reply-To: <20180317184110.GA9702@fisica.ufpr.br>
On 03/17/18 19:41, Carlos Carvalho wrote:
> I've put 4.14.27 this morning in this machine and in about 2h it started
> showing null dereferences identical to the following one. There were several of
> them, with about 1/2h of interval. Strangely it continued to work and I saw no
> other anomalies. I've just reverted to 4.14.26.
>
> It only happened in this machine, which has a net traffic of several Gb/s and
> thousands of simultaneous connections.
>
> Mar 17 13:29:21 sagres kernel: : BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> Mar 17 13:29:21 sagres kernel: : IP: tcp_push+0x4e/0xe7
> Mar 17 13:29:21 sagres kernel: : PGD 0 P4D 0
> Mar 17 13:29:21 sagres kernel: : Oops: 0002 [#1] SMP PTI
> Mar 17 13:29:21 sagres kernel: : CPU: 55 PID: 2658 Comm: apache2 Not tainted 4.14.27 #4
> Mar 17 13:29:21 sagres kernel: : task: ffff89791cf7e600 task.stack: ffffabdd91db8000
> Mar 17 13:29:21 sagres kernel: : RIP: 0010:tcp_push+0x4e/0xe7
> Mar 17 13:29:21 sagres kernel: : RSP: 0018:ffffabdd91dbbc10 EFLAGS: 00010246
> Mar 17 13:29:21 sagres kernel: : RAX: 0000000000000000 RBX: 00000000000004c4 RCX: 0000000000000001
> Mar 17 13:29:21 sagres kernel: : RDX: 0000000000000001 RSI: 0000000000000040 RDI: ffff89968330a100
> Mar 17 13:29:21 sagres kernel: : RBP: ffff89968330a250 R08: 0000000000007be8 R09: ffffe77cbfc4ab00
> Mar 17 13:29:21 sagres kernel: : R10: ffff89968330a250 R11: 0000000000000000 R12: ffff8987aab3bb80
> Mar 17 13:29:21 sagres kernel: : R13: ffff89968330a100 R14: ffff89791cf7e930 R15: 00000000ffffffe0
> Mar 17 13:29:21 sagres kernel: : FS: 00007f0bd67d4700(0000) GS:ffff89993f4c0000(0000) knlGS:0000000000000000
> Mar 17 13:29:21 sagres kernel: : CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Mar 17 13:29:21 sagres kernel: : CR2: 0000000000000038 CR3: 0000003ff4842006 CR4: 00000000003606e0
> Mar 17 13:29:21 sagres kernel: : DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> Mar 17 13:29:21 sagres kernel: : DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Mar 17 13:29:21 sagres kernel: : Call Trace:
> Mar 17 13:29:21 sagres kernel: : tcp_sendmsg_locked+0xac6/0xc1e
> Mar 17 13:29:21 sagres kernel: : tcp_sendmsg+0x23/0x35
> Mar 17 13:29:21 sagres kernel: : sock_sendmsg+0x11/0x1b
> Mar 17 13:29:21 sagres kernel: : sock_write_iter+0x71/0x87
> Mar 17 13:29:21 sagres kernel: : do_iter_readv_writev+0xf0/0x111
> Mar 17 13:29:21 sagres kernel: : do_iter_write+0x84/0xf0
> Mar 17 13:29:21 sagres kernel: : vfs_writev+0xad/0xfb
> Mar 17 13:29:21 sagres kernel: : ? do_writev+0x56/0x92
> Mar 17 13:29:21 sagres kernel: : do_writev+0x56/0x92
> Mar 17 13:29:21 sagres kernel: : do_syscall_64+0x181/0x210
> Mar 17 13:29:21 sagres kernel: : entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> Mar 17 13:29:21 sagres kernel: : RIP: 0033:0x7f13f1264017
> Mar 17 13:29:21 sagres kernel: : RSP: 002b:00007f0bd67d2810 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
> Mar 17 13:29:21 sagres kernel: : RAX: ffffffffffffffda RBX: 0000000000000079 RCX: 00007f13f1264017
> Mar 17 13:29:21 sagres kernel: : RDX: 000000000000000a RSI: 00007f0bd67d2970 RDI: 0000000000000079
> Mar 17 13:29:21 sagres kernel: : RBP: 00007f0bd67d2970 R08: 0000000000000000 R09: 00007f13680762c8
> Mar 17 13:29:21 sagres kernel: : R10: 0000556029c85dd4 R11: 0000000000000293 R12: 000000000000000a
> Mar 17 13:29:21 sagres kernel: : R13: 00007f0bd67d2970 R14: 00007f0bd67d28d0 R15: 0000556029ea1440
> Mar 17 13:29:21 sagres kernel: : Code: d0 75 02 31 c0 41 89 f3 41 81 e3 00 80 00 00 74 1a 44 8b 8f 58 05 00 00 41 d1 e9 44 2b 8f 5c 06 00 00 44 03 8f 64 06 00 00 79 10 <80> 48 38 08 8b 8f 5c 06 00 00 89 8f 64 06 00 00 40 80 e6 01 74
> Mar 17 13:29:21 sagres kernel: : RIP: tcp_push+0x4e/0xe7 RSP: ffffabdd91dbbc10
> Mar 17 13:29:21 sagres kernel: : CR2: 0000000000000038
> Mar 17 13:29:21 sagres kernel: : ---[ end trace f9a8f71d250d2782 ]---
>
Fixed by: https://www.spinics.net/lists/netdev/msg489445.html
-h
^ permalink raw reply
* Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
From: Linus Torvalds @ 2018-03-17 18:52 UTC (permalink / raw)
To: Kees Cook
Cc: Al Viro, Florian Weimer, Andrew Morton, Josh Poimboeuf,
Rasmus Villemoes, Randy Dunlap, Miguel Ojeda, Ingo Molnar,
David Laight, Ian Abbott, linux-input, linux-btrfs,
Network Development, Linux Kernel Mailing List, Kernel Hardening
In-Reply-To: <CAGXu5jJmAAgaq3VCsUN2yjpHLSc7P-kNrM_4c4cqP=ysFcETXA@mail.gmail.com>
On Sat, Mar 17, 2018 at 12:27 AM, Kees Cook <keescook@chromium.org> wrote:
>
> Unfortunately my 4.4 test fails quickly:
>
> ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’:
> ./include/linux/jiffies.h:444: error: first argument to
> ‘__builtin_choose_expr’ not a constant
Ok, so it really looks like that same "__builtin_constant_p() doesn't
return a constant".
Which is really odd, but there you have it.
I wonder if you can use that "sizeof()" to force evaluation of it,
because sizeof() really does end up being magical when it comes to
"integer constant expression".
So instead of this:
#define __no_side_effects(a,b) \
(__builtin_constant_p(a)&&__builtin_constant_p(b))
that just assumes that __builtin_constant_p() itself always counts as
a constant expression, what happens if you do
#define __is_constant(a) \
(sizeof(char[__builtin_constant_p(a)]))
#define __no_side_effects(a,b) \
(__is_constant(a) && __is_constant(b))
I realize that the above looks completely insane: the whole point is
to *not* have VLA's, and we know that __builtin_constant_p() isn't
always evaliated as a constant.
But hear me out: if the issue is that there's some evaluation ordering
between the two builtins, and the problem is that the
__builtin_choose_expr() part of the expression is expanded *before*
the __builtin_constant_p() has been expanded, then just hiding it
inside that bat-shit-crazy sizeof() will force that to be evaluated
first (because a sizeof() is defined to be a integer constant
expression.
So the above is completely insane, bit there is actually a chance that
using that completely crazy "x -> sizeof(char[x])" conversion actually
helps, because it really does have a (very odd) evaluation-time
change. sizeof() has to be evaluated as part of the constant
expression evaluation, in ways that "__builtin_constant_p()" isn't
specified to be done.
But it is also definitely me grasping at straws. If that doesn't work
for 4.4, there's nothing else I can possibly see.
Linus
^ permalink raw reply
* NULL pointer dereferences with 4.14.27
From: Carlos Carvalho @ 2018-03-17 18:41 UTC (permalink / raw)
To: linux-kernel, netdev
I've put 4.14.27 this morning in this machine and in about 2h it started
showing null dereferences identical to the following one. There were several of
them, with about 1/2h of interval. Strangely it continued to work and I saw no
other anomalies. I've just reverted to 4.14.26.
It only happened in this machine, which has a net traffic of several Gb/s and
thousands of simultaneous connections.
Mar 17 13:29:21 sagres kernel: : BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
Mar 17 13:29:21 sagres kernel: : IP: tcp_push+0x4e/0xe7
Mar 17 13:29:21 sagres kernel: : PGD 0 P4D 0
Mar 17 13:29:21 sagres kernel: : Oops: 0002 [#1] SMP PTI
Mar 17 13:29:21 sagres kernel: : CPU: 55 PID: 2658 Comm: apache2 Not tainted 4.14.27 #4
Mar 17 13:29:21 sagres kernel: : task: ffff89791cf7e600 task.stack: ffffabdd91db8000
Mar 17 13:29:21 sagres kernel: : RIP: 0010:tcp_push+0x4e/0xe7
Mar 17 13:29:21 sagres kernel: : RSP: 0018:ffffabdd91dbbc10 EFLAGS: 00010246
Mar 17 13:29:21 sagres kernel: : RAX: 0000000000000000 RBX: 00000000000004c4 RCX: 0000000000000001
Mar 17 13:29:21 sagres kernel: : RDX: 0000000000000001 RSI: 0000000000000040 RDI: ffff89968330a100
Mar 17 13:29:21 sagres kernel: : RBP: ffff89968330a250 R08: 0000000000007be8 R09: ffffe77cbfc4ab00
Mar 17 13:29:21 sagres kernel: : R10: ffff89968330a250 R11: 0000000000000000 R12: ffff8987aab3bb80
Mar 17 13:29:21 sagres kernel: : R13: ffff89968330a100 R14: ffff89791cf7e930 R15: 00000000ffffffe0
Mar 17 13:29:21 sagres kernel: : FS: 00007f0bd67d4700(0000) GS:ffff89993f4c0000(0000) knlGS:0000000000000000
Mar 17 13:29:21 sagres kernel: : CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mar 17 13:29:21 sagres kernel: : CR2: 0000000000000038 CR3: 0000003ff4842006 CR4: 00000000003606e0
Mar 17 13:29:21 sagres kernel: : DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Mar 17 13:29:21 sagres kernel: : DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Mar 17 13:29:21 sagres kernel: : Call Trace:
Mar 17 13:29:21 sagres kernel: : tcp_sendmsg_locked+0xac6/0xc1e
Mar 17 13:29:21 sagres kernel: : tcp_sendmsg+0x23/0x35
Mar 17 13:29:21 sagres kernel: : sock_sendmsg+0x11/0x1b
Mar 17 13:29:21 sagres kernel: : sock_write_iter+0x71/0x87
Mar 17 13:29:21 sagres kernel: : do_iter_readv_writev+0xf0/0x111
Mar 17 13:29:21 sagres kernel: : do_iter_write+0x84/0xf0
Mar 17 13:29:21 sagres kernel: : vfs_writev+0xad/0xfb
Mar 17 13:29:21 sagres kernel: : ? do_writev+0x56/0x92
Mar 17 13:29:21 sagres kernel: : do_writev+0x56/0x92
Mar 17 13:29:21 sagres kernel: : do_syscall_64+0x181/0x210
Mar 17 13:29:21 sagres kernel: : entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Mar 17 13:29:21 sagres kernel: : RIP: 0033:0x7f13f1264017
Mar 17 13:29:21 sagres kernel: : RSP: 002b:00007f0bd67d2810 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
Mar 17 13:29:21 sagres kernel: : RAX: ffffffffffffffda RBX: 0000000000000079 RCX: 00007f13f1264017
Mar 17 13:29:21 sagres kernel: : RDX: 000000000000000a RSI: 00007f0bd67d2970 RDI: 0000000000000079
Mar 17 13:29:21 sagres kernel: : RBP: 00007f0bd67d2970 R08: 0000000000000000 R09: 00007f13680762c8
Mar 17 13:29:21 sagres kernel: : R10: 0000556029c85dd4 R11: 0000000000000293 R12: 000000000000000a
Mar 17 13:29:21 sagres kernel: : R13: 00007f0bd67d2970 R14: 00007f0bd67d28d0 R15: 0000556029ea1440
Mar 17 13:29:21 sagres kernel: : Code: d0 75 02 31 c0 41 89 f3 41 81 e3 00 80 00 00 74 1a 44 8b 8f 58 05 00 00 41 d1 e9 44 2b 8f 5c 06 00 00 44 03 8f 64 06 00 00 79 10 <80> 48 38 08 8b 8f 5c 06 00 00 89 8f 64 06 00 00 40 80 e6 01 74
Mar 17 13:29:21 sagres kernel: : RIP: tcp_push+0x4e/0xe7 RSP: ffffabdd91dbbc10
Mar 17 13:29:21 sagres kernel: : CR2: 0000000000000038
Mar 17 13:29:21 sagres kernel: : ---[ end trace f9a8f71d250d2782 ]---
^ permalink raw reply
* Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
From: Sinan Kaya @ 2018-03-17 18:30 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, netdev, timur, sulrich, linux-arm-msm,
linux-arm-kernel, 'Steve Wise', 'Doug Ledford',
linux-rdma, linux-kernel, 'Michael Werner',
'Casey Leedom',
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
In-Reply-To: <20180317150520.GA23463@ziepe.ca>
+linuxppc-dev@lists.ozlabs.org
On 3/17/2018 11:05 AM, Jason Gunthorpe wrote:
> On Sat, Mar 17, 2018 at 12:25:14AM -0400, Sinan Kaya wrote:
>> On 3/17/2018 12:03 AM, Sinan Kaya wrote:
>>> On 3/16/2018 11:40 PM, Sinan Kaya wrote:
>>>> I'll change writel_relaxed() with __raw_writel() in the series like you suggested
>>>> and also look at your other comments.
>>>
>>> I spoke too soon.
>>>
>>> Now that I realized, code needs to follow one of the following patterns for correctness
>>>
>>> 1)
>>> wmb()
>>> writel()/writel_relaxed()
>>>
>>> or
>>>
>>> 2)
>>> wmb()
>>> __raw_wrltel()
>>> mmiowb()
>>>
>>> but definitely not
>>>
>>> wmb()
>>> __raw_wrltel()
>>>
>>> Since #1 == #2, I'll stick to my current implementation of writel_relaxed()
>>>
>>> Changing writel() to writel_relaxed() or __raw_writel() isn't enough. PowerPC needs mmiowb()
>>> for correctness. ARM's mmiowb() implementation is empty.
>>>
>>> So, there is no one size fits all solution with the current state of affairs.
>>>
>>>
>>
>> I think I finally got what you mean.
>>
>> Code seems to have
>>
>> wmb()
>> writel()/writeq()
>> wmb()
>>
>> this can be safely replaced with
>>
>> wmb()
>> __raw_writel()/__raw_writeq()
>> wmb()
>>
>> This will work on all arches. Below is the new version. Let me know if this is OK.
>>
>> +++ b/drivers/infiniband/hw/cxgb4/t4.h
>> @@ -457,7 +457,7 @@ static inline void pio_copy(u64 __iomem *dst, u64 *src)
>> int count = 8;
>>
>> while (count) {
>> - writeq(*src, dst);
>> + __raw_writeq(*src, dst);
>> src++;
>> dst++;
>> count--;
>> @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16 inc, union t4_wr *wqe)
>> (u64 *)wqe);
>> } else {
>> pr_debug("DB wq->sq.pidx = %d\n", wq->sq.pidx);
>> - writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
>> - wq->sq.bar2_va + SGE_UDB_KDOORBELL);
>> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
>> + wq->sq.bar2_va + SGE_UDB_KDOORBELL);
>> }
>>
>> /* Flush user doorbell area writes. */
>> wmb();
>> return;
>> }
>> - writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
>> + __raw_writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
>> + mmiowmb()
>> }
>>
>> static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
>> @@ -502,15 +503,16 @@ static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
>> (void *)wqe);
>> } else {
>> pr_debug("DB wq->rq.pidx = %d\n", wq->rq.pidx);
>> - writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
>> - wq->rq.bar2_va + SGE_UDB_KDOORBELL);
>> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
>> + wq->rq.bar2_va + SGE_UDB_KDOORBELL);
>> }
>>
>> /* Flush user doorbell area writes. */
>> wmb();
>> return;
>> }
>> - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
>> + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
>> + mmiowmb();
>
> No! NAK! Adding *new* barriers to use the *wrong* accessor is crazy!
>
> Your first patch was right, replacing
> wmb()
> writel()
>
> With wmb(); writel_relaxed() is fine, and helps ARM.
>
> The problem with PPC has nothing to do with the writel, it is with the
> spinlock, and we can't improve it without adding some new
> infrastructure. Certainly don't hack around the problem by using
> __raw_writel in multi-arch drivers!
>
> In userspace we settled on something like this as a pattern:
>
> mmio_wc_spin_lock()
> writel_wc_mmio()
> mmio_wc_spin_unlock()
>
> Where mmio_wc_spin_unlock incorporates the mmiowmb and is defined to
> fully contain all MMIO access to WC and UC memory.
>
> Due to our userspace the pattern is specifically used with MMIO writes
> to WC BAR memory, but it could be generalized..
>
> This allows all known arches to use the best code in all cases. x86
> can even optimize a lot and combine the mmiowmb() into the
> spin_unlock, apparently.
Given both Dave [1] and Jason's feedback, we have to ask PowerPC developers
to fix writel_relaxed().
Otherwise, PowerPC won't be able to take advantage of the optimizations
introduced in this series.
I don't think we need writel_really_relaxed() API.
Somebody also has to take a task and work very hard to get rid of __raw_writeX()
APIs in drivers/net directory. It looked like a very common practice though
it clearly violates multiarch portability concerns Jason and Deve highlighted.
This will be the next version:
iff --git a/drivers/infiniband/hw/cxgb4/t4.h b/drivers/infiniband/hw/cxgb4/t4.h
index 8369c7c..6e5658a 100644
--- a/drivers/infiniband/hw/cxgb4/t4.h
+++ b/drivers/infiniband/hw/cxgb4/t4.h
@@ -457,7 +457,7 @@ static inline void pio_copy(u64 __iomem *dst, u64 *src)
int count = 8;
while (count) {
- writeq(*src, dst);
+ writeq_relaxed(*src, dst);
src++;
dst++;
count--;
@@ -477,15 +477,15 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16 inc, union t4_wr *wqe)
(u64 *)wqe);
} else {
pr_debug("DB wq->sq.pidx = %d\n", wq->sq.pidx);
- writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
- wq->sq.bar2_va + SGE_UDB_KDOORBELL);
+ writel_relaxed(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
+ wq->sq.bar2_va + SGE_UDB_KDOORBELL);
}
/* Flush user doorbell area writes. */
wmb();
return;
}
- writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
+ writel_relaxed(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
}
static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
@@ -502,15 +502,15 @@ static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
(void *)wqe);
} else {
pr_debug("DB wq->rq.pidx = %d\n", wq->rq.pidx);
- writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
- wq->rq.bar2_va + SGE_UDB_KDOORBELL);
+ writel_relaxed(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
+ wq->rq.bar2_va + SGE_UDB_KDOORBELL);
}
/* Flush user doorbell area writes. */
wmb();
return;
}
- writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
+ writel_relaxed(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
}
[1] https://lkml.org/lkml/2018/3/17/100
>
> Jason
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Re: [PATCH v2 08/21] iio: adc: Remove depends on HAS_DMA in case of platform dependency
From: Jonathan Cameron @ 2018-03-17 16:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio, linux-fpga,
linux-remoteproc, alsa-devel, Bjorn Andersson, Eric Anholt,
netdev, linux-mtd, linux-i2c, linux1394-devel, Christoph Hellwig,
Marek Szyprowski, Stefan Wahren, Boris Brezillon,
James E . J . Bottomley, Herbert Xu, linux-scsi,
Richard Weinberger, Joerg Roedel, Jassi Brar, Marek Vasut,
linux-serial, Matias Bjorling
In-Reply-To: <1521208314-4783-9-git-send-email-geert@linux-m68k.org>
On Fri, 16 Mar 2018 14:51:41 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Acked-by: Robin Murphy <robin.murphy@arm.com>
Great.
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Thanks for doing this - this has been annoying for a long time :)
> ---
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Split per subsystem.
> ---
> drivers/iio/adc/Kconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 72bc2b71765ae2ff..57f46e88f5c2536e 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -158,7 +158,6 @@ config AT91_SAMA5D2_ADC
> tristate "Atmel AT91 SAMA5D2 ADC"
> depends on ARCH_AT91 || COMPILE_TEST
> depends on HAS_IOMEM
> - depends on HAS_DMA
> select IIO_TRIGGERED_BUFFER
> help
> Say yes here to build support for Atmel SAMA5D2 ADC which is
> @@ -647,7 +646,6 @@ config SD_ADC_MODULATOR
> config STM32_ADC_CORE
> tristate "STMicroelectronics STM32 adc core"
> depends on ARCH_STM32 || COMPILE_TEST
> - depends on HAS_DMA
> depends on OF
> depends on REGULATOR
> select IIO_BUFFER
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Frantisek Rysanek @ 2018-03-17 15:20 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <20180317145036.GA21704@lunn.ch>
On 17 Mar 2018 at 15:50, Andrew Lunn wrote:
> On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote:
> > On 16 Mar 2018 at 22:02, Andrew Lunn wrote:
> > >
> > > Does ethtool -m show anything useful?
> > >
> >
> > Not much. "unsupported".
>
> static int igb_get_module_info(struct net_device *netdev,
> struct ethtool_modinfo *modinfo)
> {
> struct igb_adapter *adapter = netdev_priv(netdev);
> struct e1000_hw *hw = &adapter->hw;
> u32 status = 0;
> u16 sff8472_rev, addr_mode;
> bool page_swap = false;
>
> if ((hw->phy.media_type == e1000_media_type_copper) ||
> (hw->phy.media_type == e1000_media_type_unknown))
> return -EOPNOTSUPP;
>
> Suggests that the driver does not know you have a fibre module.
>
Good! I'll check this out.
Even if it means that I have to hack the "sequence of initialization"
in the flow of driver code... (again.)
> > Right now I've modded igb_init_i2c() to engage the bit-banging
> > i2c driver for the i210 too
>
> I don't think that will work. The datasheet for the i210 talks about
> two registers for I2C/MDIO which are not bit-banging. Only the i350
> uses bit-banging.
>
>From the i210 datasheet, page 477:
chapter 8.17.9 "SFP I2C Parameters" - reg. I2CPARAMS (0x102C; R/W)
bit 8 "I2CBB_EN" = I2C bit-bang enable.
And about 6 more bits for SDA and SCL direction, input and output.
Looking through existing code of the bit-banging callbacks for i350,
their function would seem identical between the i210 and i350.
I may check the bit definition macros again, if the scope shows
nothing.
If the HW implementation of the I2C protocol doesn't work for some
reason, I can as well try bit-banging it.
Thanks for your continued input :-)
Frank
^ permalink raw reply
* Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
From: Jason Gunthorpe @ 2018-03-17 15:05 UTC (permalink / raw)
To: Sinan Kaya
Cc: Steve Wise, netdev, timur, sulrich, linux-arm-msm,
linux-arm-kernel, 'Steve Wise', 'Doug Ledford',
linux-rdma, linux-kernel, 'Michael Werner',
'Casey Leedom'
In-Reply-To: <1f5e3b14-05a1-08d0-c0cb-00805526448d@codeaurora.org>
On Sat, Mar 17, 2018 at 12:25:14AM -0400, Sinan Kaya wrote:
> On 3/17/2018 12:03 AM, Sinan Kaya wrote:
> > On 3/16/2018 11:40 PM, Sinan Kaya wrote:
> >> I'll change writel_relaxed() with __raw_writel() in the series like you suggested
> >> and also look at your other comments.
> >
> > I spoke too soon.
> >
> > Now that I realized, code needs to follow one of the following patterns for correctness
> >
> > 1)
> > wmb()
> > writel()/writel_relaxed()
> >
> > or
> >
> > 2)
> > wmb()
> > __raw_wrltel()
> > mmiowb()
> >
> > but definitely not
> >
> > wmb()
> > __raw_wrltel()
> >
> > Since #1 == #2, I'll stick to my current implementation of writel_relaxed()
> >
> > Changing writel() to writel_relaxed() or __raw_writel() isn't enough. PowerPC needs mmiowb()
> > for correctness. ARM's mmiowb() implementation is empty.
> >
> > So, there is no one size fits all solution with the current state of affairs.
> >
> >
>
> I think I finally got what you mean.
>
> Code seems to have
>
> wmb()
> writel()/writeq()
> wmb()
>
> this can be safely replaced with
>
> wmb()
> __raw_writel()/__raw_writeq()
> wmb()
>
> This will work on all arches. Below is the new version. Let me know if this is OK.
>
> +++ b/drivers/infiniband/hw/cxgb4/t4.h
> @@ -457,7 +457,7 @@ static inline void pio_copy(u64 __iomem *dst, u64 *src)
> int count = 8;
>
> while (count) {
> - writeq(*src, dst);
> + __raw_writeq(*src, dst);
> src++;
> dst++;
> count--;
> @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16 inc, union t4_wr *wqe)
> (u64 *)wqe);
> } else {
> pr_debug("DB wq->sq.pidx = %d\n", wq->sq.pidx);
> - writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
> - wq->sq.bar2_va + SGE_UDB_KDOORBELL);
> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
> + wq->sq.bar2_va + SGE_UDB_KDOORBELL);
> }
>
> /* Flush user doorbell area writes. */
> wmb();
> return;
> }
> - writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
> + __raw_writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
> + mmiowmb()
> }
>
> static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
> @@ -502,15 +503,16 @@ static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
> (void *)wqe);
> } else {
> pr_debug("DB wq->rq.pidx = %d\n", wq->rq.pidx);
> - writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
> - wq->rq.bar2_va + SGE_UDB_KDOORBELL);
> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
> + wq->rq.bar2_va + SGE_UDB_KDOORBELL);
> }
>
> /* Flush user doorbell area writes. */
> wmb();
> return;
> }
> - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + mmiowmb();
No! NAK! Adding *new* barriers to use the *wrong* accessor is crazy!
Your first patch was right, replacing
wmb()
writel()
With wmb(); writel_relaxed() is fine, and helps ARM.
The problem with PPC has nothing to do with the writel, it is with the
spinlock, and we can't improve it without adding some new
infrastructure. Certainly don't hack around the problem by using
__raw_writel in multi-arch drivers!
In userspace we settled on something like this as a pattern:
mmio_wc_spin_lock()
writel_wc_mmio()
mmio_wc_spin_unlock()
Where mmio_wc_spin_unlock incorporates the mmiowmb and is defined to
fully contain all MMIO access to WC and UC memory.
Due to our userspace the pattern is specifically used with MMIO writes
to WC BAR memory, but it could be generalized..
This allows all known arches to use the best code in all cases. x86
can even optimize a lot and combine the mmiowmb() into the
spin_unlock, apparently.
Jason
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Andrew Lunn @ 2018-03-17 14:50 UTC (permalink / raw)
To: Frantisek Rysanek; +Cc: netdev
In-Reply-To: <5AACC614.18709.335BD813@Frantisek.Rysanek.post.cz>
On Sat, Mar 17, 2018 at 08:39:00AM +0100, Frantisek Rysanek wrote:
> On 16 Mar 2018 at 22:02, Andrew Lunn wrote:
> >
> > Does ethtool -m show anything useful?
> >
>
> Not much. "unsupported".
static int igb_get_module_info(struct net_device *netdev,
struct ethtool_modinfo *modinfo)
{
struct igb_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
u32 status = 0;
u16 sff8472_rev, addr_mode;
bool page_swap = false;
if ((hw->phy.media_type == e1000_media_type_copper) ||
(hw->phy.media_type == e1000_media_type_unknown))
return -EOPNOTSUPP;
Suggests that the driver does not know you have a fibre module.
> Right now I've modded igb_init_i2c() to engage the bit-banging
> i2c driver for the i210 too
I don't think that will work. The datasheet for the i210 talks about
two registers for I2C/MDIO which are not bit-banging. Only the i350
uses bit-banging.
Andrew
^ permalink raw reply
* Re: [PATCH RFC RFC] rds: Use NETDEV_UNREGISTER in rds_tcp_dev_event() (then kill NETDEV_UNREGISTER_FINAL)
From: Sowmini Varadhan @ 2018-03-17 14:15 UTC (permalink / raw)
To: Kirill Tkhai
Cc: santosh.shilimkar, davem, netdev, linux-rdma, rds-devel, edumazet
In-Reply-To: <82d6e954-8043-078c-266c-2f1ac992f864@virtuozzo.com>
I spent a long time staring at both v1 and v2 of your patch.
I understand the overall goal, but I am afraid to say that these
patches are complete hacks.
I was trying to understand why patchv1 blows with a null rtn in
rds_tcp_init_net, but v2 does not, and the analysis is ugly.
I'm going to put down the analysis here, and others can
decide if this sort of hack is a healthy solution for a scaling
issue (IMHO it is not- we should get the real fix for the
scaling instead of using duck-tape-and-chewing-gum solutions)
What is happening in v1 is this:
1. Wnen I do "modprobe rds_tcp" in init_net, we end up doing the
following in rds_tcp_init
register_pernet_device(&rds_tcp_dev_ops);
register_pernet_device(&rds_tcp_net_ops);
Where rds_tcp_dev_ops has
.id = &rds_tcp_netid,
.size = sizeof(struct rds_tcp_net),
and rds_tcp_net_ops has 0 values for both of these.
2. So now pernet_list has &rds_tcp_net_ops as the first member of the
pernet_list.
3. Now I do "ip netns create blue". As part of setup_net(), we walk
the pernet_list and call the ->init of each member (through ops_init()).
So we'd hit rds_tcp_net_ops first. Since the id/size are 0, we'd
skip the struct rds_tcp_net allocation, so rds_tcp_init_net would
find a null return from net_generic() and bomb.
The way I view it (and ymmv) the hack here is to call both
register_pernet_device and register_pernet_subsys: the kernel only
guarantees that calling *one* of register_pernet_* will ensure
that you can safely call net_generic() afterwards.
The v2 patch "works around" this by reordering the registration.
So this time, init_net will set up the rds_tcp_net_ops as the second
member, and the first memeber will be the pernet_operations struct
that has non-zero id and size.
But then the unregistration (necessarily) works in the opposite order
you have to unregister_pernet_device first (so that interfaces are
quiesced) and then unregister_pernet_subsys() so that sockets can
be safely quiesced.
I dont think this type of hack makes the code cleaner, it just
make things much harder to understand, and completely brittle
for subsequent changes.
To solve the scaling problem why not just have a well-defined
callback to modules when devices are quiesced, instead of
overloading the pernet_device registration in this obscure way?
^ permalink raw reply
* Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
From: David Miller @ 2018-03-17 13:27 UTC (permalink / raw)
To: okaya
Cc: swise, netdev, timur, sulrich, linux-arm-msm, linux-arm-kernel,
swise, dledford, jgg, linux-rdma, linux-kernel, werner, leedom
In-Reply-To: <1f5e3b14-05a1-08d0-c0cb-00805526448d@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Sat, 17 Mar 2018 00:25:14 -0400
> I think I finally got what you mean.
>
> Code seems to have
>
> wmb()
> writel()/writeq()
> wmb()
>
> this can be safely replaced with
>
> wmb()
> __raw_writel()/__raw_writeq()
> wmb()
>
> This will work on all arches. Below is the new version. Let me know if this is OK.
Unfortunately, I think this won't work.
At least on sparc, the __raw_*() variants also change the endianness to
native endianness.
PowerPC does this as well, even documented in a comment :-)
/*
* Non ordered and non-swapping "raw" accessors
*/
Only the non-__raw_ variants do the endianness swap to/from
little-endian.
^ permalink raw reply
* Re: [v2] vhost: add vsock compat ioctl
From: David Miller @ 2018-03-17 13:24 UTC (permalink / raw)
To: sonnyrao; +Cc: netdev
In-Reply-To: <CAPz6YkX8SZVOFyOAdhrotvQ7MtGYnuzb_=+tSfX6jB+rvQm2_w@mail.gmail.com>
From: Sonny Rao <sonnyrao@chromium.org>
Date: Fri, 16 Mar 2018 17:54:12 -0700
> On Fri, Mar 16, 2018 at 12:30 PM, David Miller <davem@davemloft.net> wrote:
>>
>> Although the top level ioctls are probably size and layout compatible,
>> I do not think that the deeper ioctls can be called by compat binaries
>> without some translations in order for them to work.
>
> Ok, thanks -- I have only tested VHOST_VSOCK_SET_GUEST_CID and
> VHOST_VSOCK_SET_RUNNING but by deeper ioctls I think you might mean
> the ioctls under vhost_dev_ioctl() and vhost_vring_ioctl()?
Yes.
^ permalink raw reply
* RE: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
From: Steve Wise @ 2018-03-17 13:23 UTC (permalink / raw)
To: 'Sinan Kaya', netdev, timur, sulrich
Cc: linux-arm-msm, linux-arm-kernel, 'Steve Wise',
'Doug Ledford', 'Jason Gunthorpe', linux-rdma,
linux-kernel, 'Michael Werner', 'Casey Leedom'
In-Reply-To: <1f5e3b14-05a1-08d0-c0cb-00805526448d@codeaurora.org>
>
> On 3/17/2018 12:03 AM, Sinan Kaya wrote:
> > On 3/16/2018 11:40 PM, Sinan Kaya wrote:
> >> I'll change writel_relaxed() with __raw_writel() in the series like you
> suggested
> >> and also look at your other comments.
> >
> > I spoke too soon.
> >
> > Now that I realized, code needs to follow one of the following patterns
> for correctness
> >
> > 1)
> > wmb()
> > writel()/writel_relaxed()
> >
> > or
> >
> > 2)
> > wmb()
> > __raw_wrltel()
> > mmiowb()
> >
> > but definitely not
> >
> > wmb()
> > __raw_wrltel()
> >
> > Since #1 == #2, I'll stick to my current implementation of writel_relaxed()
> >
> > Changing writel() to writel_relaxed() or __raw_writel() isn't enough.
> PowerPC needs mmiowb()
> > for correctness. ARM's mmiowb() implementation is empty.
> >
> > So, there is no one size fits all solution with the current state of affairs.
> >
> >
>
> I think I finally got what you mean.
>
> Code seems to have
>
> wmb()
> writel()/writeq()
> wmb()
>
> this can be safely replaced with
>
> wmb()
> __raw_writel()/__raw_writeq()
> wmb()
>
> This will work on all arches. Below is the new version. Let me know if this is
> OK.
>
> +++ b/drivers/infiniband/hw/cxgb4/t4.h
> @@ -457,7 +457,7 @@ static inline void pio_copy(u64 __iomem *dst, u64
> *src)
> int count = 8;
>
> while (count) {
> - writeq(*src, dst);
> + __raw_writeq(*src, dst);
> src++;
> dst++;
> count--;
> @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq,
> u16 inc, union t4_wr *wqe)
> (u64 *)wqe);
> } else {
> pr_debug("DB wq->sq.pidx = %d\n", wq->sq.pidx);
> - writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
> - wq->sq.bar2_va + SGE_UDB_KDOORBELL);
> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
> + wq->sq.bar2_va + SGE_UDB_KDOORBELL);
> }
>
> /* Flush user doorbell area writes. */
> wmb();
> return;
> }
> - writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
> + __raw_writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
> + mmiowmb()
> }
>
> static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
> @@ -502,15 +503,16 @@ static inline void t4_ring_rq_db(struct t4_wq *wq,
> u16 inc,
> (void *)wqe);
> } else {
> pr_debug("DB wq->rq.pidx = %d\n", wq->rq.pidx);
> - writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
> - wq->rq.bar2_va + SGE_UDB_KDOORBELL);
> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
> + wq->rq.bar2_va + SGE_UDB_KDOORBELL);
> }
>
> /* Flush user doorbell area writes. */
> wmb();
> return;
> }
> - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
> + mmiowmb();
> }
>
>
Yes, this is what chelsio recommended to me.
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ 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