* Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: David Miller @ 2016-04-24 18:54 UTC (permalink / raw)
To: hannes; +Cc: eric.dumazet, Valdis.Kletnieks, netdev, linux-kernel
In-Reply-To: <571D14F8.6070306@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 24 Apr 2016 20:48:24 +0200
> Eric's patch is worth to apply anyway, but I am not sure if it solves
> the (fundamental) problem. I couldn't reproduce it with the exact next-
> tag provided in the initial mail. All other reports also only happend
> with linux-next and not net-next.
Ok, Eric please submit it formally.
Thanks!
^ permalink raw reply
* Re: [PATCH net V1 0/8] mlx5 driver updates and fixes
From: David Miller @ 2016-04-24 18:53 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, talal, eranbe
In-Reply-To: <1461274387-10653-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 22 Apr 2016 00:32:59 +0300
> Changes from V0:
> - Dropped: ("net/mlx5e: Reset link modes upon setting speed to zero")
> - Fixed compilation issue introduced to mlx5_ib driver.
> - Rebased to df637193906a ('Revert "Prevent NUll pointer dereference with two PHYs on cpsw"')
>
> This series has few bug fixes for mlx5 core and ethernet driver.
>
> Eli fixed a wrong static local variable declaration in flow steering API.
> Majd added the support of ConnectX-5 PF and VF and added the support
> for kernel shutdown pci callback for more robust reboot procedures.
> Maor fixed a soft lockup in flow steering.
> Rana fixed a wrog speed define in mlx5 EN driver.
> I also had the chance to introduce some bug fixes in mlx5 EN mtu
> reporting and handling.
Series applied and...
> For -stable:
> net/mlx5_core: Fix soft lockup in steering error flow
> net/mlx5e: Device's mtu field is u16 and not int
> net/mlx5e: Fix minimum MTU
> net/mlx5e: Use vport MTU rather than physical port MTU
queued up for -stable.
Thanks.
^ permalink raw reply
* Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: Hannes Frederic Sowa @ 2016-04-24 18:48 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, Valdis.Kletnieks, netdev, linux-kernel
In-Reply-To: <20160424.143833.2292980084570149367.davem@davemloft.net>
On 24.04.2016 20:38, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Thu, 21 Apr 2016 15:49:37 +0200
>
>> On 21.04.2016 15:31, Eric Dumazet wrote:
>>> On Thu, 2016-04-21 at 05:05 -0400, Valdis.Kletnieks@vt.edu wrote:
>>>> On Thu, 21 Apr 2016 09:42:12 +0200, Hannes Frederic Sowa said:
>>>>> Hi,
>>>>>
>>>>> On Thu, Apr 21, 2016, at 02:30, Valdis Kletnieks wrote:
>>>>>> linux-next 20160420 is whining at an incredible rate - in 20 minutes of
>>>>>> uptime, I piled up some 41,000 hits from all over the place (cleaned up
>>>>>> to skip the CPU and PID so the list isn't quite so long):
>>>>>
>>>>> Thanks for the report. Can you give me some more details:
>>>>>
>>>>> Is this an nfs socket? Do you by accident know if this socket went
>>>>> through xs_reclassify_socket at any point? We do hold the appropriate
>>>>> locks at that point but I fear that the lockdep reinitialization
>>>>> confused lockdep.
>>>>
>>>> It wasn't an NFS socket, as NFS wasn't even active at the time. I'm reasonably
>>>> sure that multiple sockets were in play, given that tcp_v6_rcv and
>>>> udpv6_queue_rcv_skb were both implicated. I strongly suspect that pretty much
>>>> any IPv6 traffic could do it - the frequency dropped off quite a bit when I
>>>> closed firefox, which is usually a heavy network hitter on my laptop.
>>>
>>>
>>> Looks like the following patch is needed, can you try it please ?
>>>
>>> Thanks !
>>>
>>> diff --git a/include/net/sock.h b/include/net/sock.h
>>> index d997ec13a643..db8301c76d50 100644
>>> --- a/include/net/sock.h
>>> +++ b/include/net/sock.h
>>> @@ -1350,7 +1350,8 @@ static inline bool lockdep_sock_is_held(const struct sock *csk)
>>> {
>>> struct sock *sk = (struct sock *)csk;
>>>
>>> - return lockdep_is_held(&sk->sk_lock) ||
>>> + return !debug_locks ||
>>> + lockdep_is_held(&sk->sk_lock) ||
>>> lockdep_is_held(&sk->sk_lock.slock);
>>> }
>>> #endif
>>
>> I would prefer to add debug_locks at the WARN_ON level, like
>> WARN_ON(debug_locks && !lockdep_sock_is_held(sk)), but I am not sure if
>> this fixes the initial splat.
>
> Can we finish this conversation out and come up with a final patch
> for this soon?
Eric's patch is worth to apply anyway, but I am not sure if it solves
the (fundamental) problem. I couldn't reproduce it with the exact next-
tag provided in the initial mail. All other reports also only happend
with linux-next and not net-next.
I hope I Valdis provides his config soon and I will continue my analysis
on this then.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net 1/1] qlcnic: Update version to 5.3.64
From: David Miller @ 2016-04-24 18:45 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Dept-GELinuxNICDev
In-Reply-To: <1461259520-14893-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Thu, 21 Apr 2016 13:25:20 -0400
> Just updating the version as many fixes got
> accumulated over 5.3.63
>
> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp-tso: do not split TSO packets at retransmit time
From: David Miller @ 2016-04-24 18:44 UTC (permalink / raw)
To: edumazet; +Cc: netdev, ncardwell, ycheng, eric.dumazet
In-Reply-To: <1461261323-14355-1-git-send-email-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 21 Apr 2016 10:55:23 -0700
> Linux TCP stack painfully segments all TSO/GSO packets before retransmits.
>
> This was fine back in the days when TSO/GSO were emerging, with their
> bugs, but we believe the dark age is over.
>
> Keeping big packets in write queues, but also in stack traversal
> has a lot of benefits.
> - Less memory overhead, because write queues have less skbs
> - Less cpu overhead at ACK processing.
> - Better SACK processing, as lot of studies mentioned how
> awful linux was at this ;)
> - Less cpu overhead to send the rtx packets
> (IP stack traversal, netfilter traversal, drivers...)
> - Better latencies in presence of losses.
> - Smaller spikes in fq like packet schedulers, as retransmits
> are not constrained by TCP Small Queues.
>
> 1 % packet losses are common today, and at 100Gbit speeds, this
> translates to ~80,000 losses per second.
> Losses are often correlated, and we see many retransmit events
> leading to 1-MSS train of packets, at the time hosts are already
> under stress.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller
From: David Miller @ 2016-04-24 18:40 UTC (permalink / raw)
To: marex; +Cc: netdev, peppe.cavallaro, alexandre.torgue, mgerlach, dinguyen
In-Reply-To: <1461240710-5381-1-git-send-email-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Thu, 21 Apr 2016 14:11:50 +0200
> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
> in stmmac_main.c functions call devm_reset_control_get() to register an
> reset controller for the stmmac. This results in an attempt to register
> two reset controllers for the same non-shared reset line.
>
> The first attempt to register the reset controller works fine. The second
> attempt fails with warning from the reset controller core, see below.
> The warning is produced because the reset line is non-shared and thus
> it is allowed to have only up-to one reset controller associated with
> that reset line, not two or more.
>
> The solution has multiple parts. First, the original socfpga_dwmac_init()
> is tweaked to use reset controller pointer from the stmmac_priv (private
> data of the stmmac core) instead of the local instance, which was used
> before. The local re-registration of the reset controller is removed.
>
> Next, the socfpga_dwmac_init() is moved after stmmac_dvr_probe() in the
> probe function. This order is legal according to Altera and it makes the
> code much easier, since there is no need to temporarily register and
> unregister the reset controller ; the reset controller is already registered
> by the stmmac_dvr_probe().
>
> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
> since the functionality is already performed by the stmmac core.
...
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Matthew Gerlach <mgerlach@opensource.altera.com>
> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> Cc: David S. Miller <davem@davemloft.net>
Applied, thanks.
^ permalink raw reply
* Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408
From: David Miller @ 2016-04-24 18:38 UTC (permalink / raw)
To: hannes; +Cc: eric.dumazet, Valdis.Kletnieks, netdev, linux-kernel
In-Reply-To: <5718DA71.7050902@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 21 Apr 2016 15:49:37 +0200
> On 21.04.2016 15:31, Eric Dumazet wrote:
>> On Thu, 2016-04-21 at 05:05 -0400, Valdis.Kletnieks@vt.edu wrote:
>>> On Thu, 21 Apr 2016 09:42:12 +0200, Hannes Frederic Sowa said:
>>>> Hi,
>>>>
>>>> On Thu, Apr 21, 2016, at 02:30, Valdis Kletnieks wrote:
>>>>> linux-next 20160420 is whining at an incredible rate - in 20 minutes of
>>>>> uptime, I piled up some 41,000 hits from all over the place (cleaned up
>>>>> to skip the CPU and PID so the list isn't quite so long):
>>>>
>>>> Thanks for the report. Can you give me some more details:
>>>>
>>>> Is this an nfs socket? Do you by accident know if this socket went
>>>> through xs_reclassify_socket at any point? We do hold the appropriate
>>>> locks at that point but I fear that the lockdep reinitialization
>>>> confused lockdep.
>>>
>>> It wasn't an NFS socket, as NFS wasn't even active at the time. I'm reasonably
>>> sure that multiple sockets were in play, given that tcp_v6_rcv and
>>> udpv6_queue_rcv_skb were both implicated. I strongly suspect that pretty much
>>> any IPv6 traffic could do it - the frequency dropped off quite a bit when I
>>> closed firefox, which is usually a heavy network hitter on my laptop.
>>
>>
>> Looks like the following patch is needed, can you try it please ?
>>
>> Thanks !
>>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index d997ec13a643..db8301c76d50 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -1350,7 +1350,8 @@ static inline bool lockdep_sock_is_held(const struct sock *csk)
>> {
>> struct sock *sk = (struct sock *)csk;
>>
>> - return lockdep_is_held(&sk->sk_lock) ||
>> + return !debug_locks ||
>> + lockdep_is_held(&sk->sk_lock) ||
>> lockdep_is_held(&sk->sk_lock.slock);
>> }
>> #endif
>
> I would prefer to add debug_locks at the WARN_ON level, like
> WARN_ON(debug_locks && !lockdep_sock_is_held(sk)), but I am not sure if
> this fixes the initial splat.
Can we finish this conversation out and come up with a final patch
for this soon?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v1 1/1] tipc: fix stale links after re-enabling bearer
From: David Miller @ 2016-04-24 18:36 UTC (permalink / raw)
To: parthasarathy.bhuvaragan; +Cc: jon.maloy, netdev, tipc-discussion
In-Reply-To: <1461246673-6127-1-git-send-email-parthasarathy.bhuvaragan@ericsson.com>
From: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date: Thu, 21 Apr 2016 15:51:13 +0200
> Commit 42b18f605fea ("tipc: refactor function tipc_link_timeout()"),
> introduced a bug which prevents sending of probe messages during
> link synchronization phase. This leads to hanging links, if the
> bearer is disabled/enabled after links are up.
>
> In this commit, we send the probe messages correctly.
> Fixes: 42b18f605fea ("tipc: refactor function tipc_link_timeout()")
>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Please always group a "Fixes: " tag with the other tags. It is just
another tag like Signed-off-by: and Acked-by: and therefore should be
grouped together with them.
Applied, thanks.
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
^ permalink raw reply
* Re: [PATCH net v2 0/9] macsec: a few fixes
From: David Miller @ 2016-04-24 18:32 UTC (permalink / raw)
To: sd; +Cc: netdev, lrichard, hannes, johannes, dan.carpenter
In-Reply-To: <cover.1461315621.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Fri, 22 Apr 2016 11:28:00 +0200
> Some small fixes for the macsec driver:
> - possible NULL pointer dereferences
> - netlink dumps fixes: RTNL locking, consistent dumps
> - a reference counting bug
> - wrong name for uapi constant
> - a few memory leaks
>
> Patches 1 to 5 are the same as in v1, patches 6 to 9 are new.
> Patch 6 fixes the memleak that Lance spotted in v1.
Series applied, thanks Sabrina.
^ permalink raw reply
* Re: [patch net 0/3] bridge: mdb: Couple of fixes
From: David Miller @ 2016-04-24 18:23 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, ogerlitz, stephen, nikolay
In-Reply-To: <1461235965-3930-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 21 Apr 2016 12:52:42 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> Elad says:
>
> This patchset fixes two problems reported by Nikolay Aleksandrov. The first
> problem is that the MDB offload flag might be accesed without helding the
> multicast_lock.
> The second problem is that the switchdev mdb offload is deferred and
> the offload bit was marked regardless if the operation succeeded or not.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] MAINTAINERS: net: add entry for TI Ethernet Switch drivers
From: David Miller @ 2016-04-24 18:20 UTC (permalink / raw)
To: grygorii.strashko
Cc: netdev, linux-kernel, nsekhar, linux-omap, tony, mugunthanvnm,
richardcochran
In-Reply-To: <1461233636-18667-1-git-send-email-grygorii.strashko@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Thu, 21 Apr 2016 13:13:56 +0300
> Add record for TI Ethernet Switch Driver CPSW/CPDMA/MDIO HW
> (am33/am43/am57/dr7/davinci) to ensure that related patches
> will go through dedicated linux-omap list.
>
> Also add Mugunthan as maintainer and myself as the reviewer.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Mugunthan V N <mugunthanvnm@ti.com>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> Changes in v2:
> - added netdev@vger.kernel.org list
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: David Miller @ 2016-04-24 18:18 UTC (permalink / raw)
To: pramod.kumar-dY08KVG/lbpWk0Htik3J/w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
wens-jdAy2FN1RRM, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
arnd-r2nGTMty4D4, suzuki.poulose-5wv7dgnIgG8,
punit.agrawal-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, anup.patel-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <1461230323-27891-2-git-send-email-pramod.kumar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
From: Pramod Kumar <pramod.kumar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Date: Thu, 21 Apr 2016 14:48:38 +0530
> +struct shared_mdio_master *shared_mdio_alloc_master(struct device *parent,
> + struct device_node *node)
> +{
> + int ret = 0;
> + struct shared_mdio_master *master;
Always order local variable declarations in reverse christmas tree
(longest to shortest line) order.
> +static int shared_mdio_driver_probe(struct device *dev)
> +{
> + int rc;
> + struct shared_mdio_master *master = to_shared_mdio_master(dev);
> + struct shared_mdio_driver *drv = to_shared_mdio_driver(dev->driver);
Likewise.
Please audit your entire submission for this issue.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] macvtap: add namespace support to the sysfs device class
From: David Miller @ 2016-04-24 18:14 UTC (permalink / raw)
To: marc; +Cc: netdev, ebiederm
In-Reply-To: <1461161491-22867-1-git-send-email-marc@arista.com>
From: Marc Angel <marc@arista.com>
Date: Wed, 20 Apr 2016 16:11:31 +0200
> However, doing this has the side effect of changing
> /sys/devices/virtual/net/macvtapX/tapNN into
> /sys/devices/virtual/net/macvtapX/macvtap/tapNN
I'm really not comfortable at all with having this sysfs
device name change.
^ permalink raw reply
* [PATCH v3 03/21] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Chris Wilson @ 2016-04-24 18:10 UTC (permalink / raw)
To: intel-gfx
Cc: Tvrtko Ursulin, netdev, Yishai Hadas, linux-kernel,
Peter Zijlstra (Intel), Luis R . Rodriguez, dri-devel, linux-rdma,
Daniel Vetter, Dan Williams, Ingo Molnar, David Hildenbrand
In-Reply-To: <1461521419-18086-1-git-send-email-chris@chris-wilson.co.uk>
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Yishai Hadas <yishaih@mellanox.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/gpu/drm/i915/intel_overlay.c | 3 ++-
drivers/net/ethernet/mellanox/mlx4/pd.c | 4 +++-
include/linux/io-mapping.h | 10 +++++++---
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index 9746b9841c13..0d5a376878d3 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem *)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
- overlay->flip_addr);
+ overlay->flip_addr,
+ PAGE_SIZE);
return regs;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node)
goto free_uar;
}
- uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << PAGE_SHIFT);
+ uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+ uar->index << PAGE_SHIFT,
+ PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
}
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
resource_size_t phys_addr;
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
- return ioremap_wc(phys_addr, PAGE_SIZE);
+ return ioremap_wc(phys_addr, size);
}
static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
/* Non-atomic map/unmap */
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
return ((char __force __iomem *) mapping) + offset;
}
--
2.8.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH net-next 0/2] tcp: Handle txstamp_ack when fragmenting/coalescing skbs
From: David Miller @ 2016-04-24 18:07 UTC (permalink / raw)
To: kafai; +Cc: netdev, edumazet, ncardwell, soheil, willemb, ycheng, kernel-team
In-Reply-To: <1461131448-1460418-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Tue, 19 Apr 2016 22:50:46 -0700
> This patchset is to handle the txstamp-ack bit when
> fragmenting/coalescing skbs.
...
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 5/5] of_mdio: get_phy_device() doesn't return NULL anymore
From: Sergei Shtylyov @ 2016-04-24 17:37 UTC (permalink / raw)
To: f.fainelli, netdev; +Cc: arnd, Rob Herring, Frank Rowand, Grant Likely
In-Reply-To: <2718908.IUaySUkXrd@wasted.cogentembedded.com>
On 04/24/2016 08:31 PM, Sergei Shtylyov wrote:
> Now that get_phy_device() no longer returns NULL on error, we don't need
> to check for it...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
Oops, forgot to CC: the DT people, doing that now...
> ---
> drivers/of/of_mdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: net-next/drivers/of/of_mdio.c
> ===================================================================
> --- net-next.orig/drivers/of/of_mdio.c
> +++ net-next/drivers/of/of_mdio.c
> @@ -56,7 +56,7 @@ static void of_mdiobus_register_phy(stru
> phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
> else
> phy = get_phy_device(mdio, addr, is_c45);
> - if (IS_ERR_OR_NULL(phy))
> + if (IS_ERR(phy))
> return;
>
> rc = irq_of_parse_and_map(child, 0);
^ permalink raw reply
* [PATCH 5/5] of_mdio: get_phy_device() doesn't return NULL anymore
From: Sergei Shtylyov @ 2016-04-24 17:31 UTC (permalink / raw)
To: f.fainelli, netdev; +Cc: arnd
In-Reply-To: <56219623.1S7UfcqQqc@wasted.cogentembedded.com>
Now that get_phy_device() no longer returns NULL on error, we don't need
to check for it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/of/of_mdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/of/of_mdio.c
===================================================================
--- net-next.orig/drivers/of/of_mdio.c
+++ net-next/drivers/of/of_mdio.c
@@ -56,7 +56,7 @@ static void of_mdiobus_register_phy(stru
phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
else
phy = get_phy_device(mdio, addr, is_c45);
- if (IS_ERR_OR_NULL(phy))
+ if (IS_ERR(phy))
return;
rc = irq_of_parse_and_map(child, 0);
^ permalink raw reply
* [PATCH 4/5] mdio_bus: get_phy_device() doesn't return NULL anymore
From: Sergei Shtylyov @ 2016-04-24 17:30 UTC (permalink / raw)
To: f.fainelli, netdev; +Cc: arnd
In-Reply-To: <56219623.1S7UfcqQqc@wasted.cogentembedded.com>
Now that get_phy_device() no longer returns NULL on error, we don't need
to check for it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/phy/mdio_bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/net/phy/mdio_bus.c
===================================================================
--- net-next.orig/drivers/net/phy/mdio_bus.c
+++ net-next/drivers/net/phy/mdio_bus.c
@@ -419,7 +419,7 @@ struct phy_device *mdiobus_scan(struct m
int err;
phydev = get_phy_device(bus, addr, false);
- if (IS_ERR(phydev) || phydev == NULL)
+ if (IS_ERR(phydev))
return phydev;
/*
^ permalink raw reply
* [PATCH 3/5] fixed_phy: get_phy_device() doesn't return NULL anymore
From: Sergei Shtylyov @ 2016-04-24 17:29 UTC (permalink / raw)
To: f.fainelli, netdev; +Cc: arnd
In-Reply-To: <56219623.1S7UfcqQqc@wasted.cogentembedded.com>
Now that get_phy_device() no longer returns NULL on error, we don't need
to check for it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/phy/fixed_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/net/phy/fixed_phy.c
===================================================================
--- net-next.orig/drivers/net/phy/fixed_phy.c
+++ net-next/drivers/net/phy/fixed_phy.c
@@ -328,7 +328,7 @@ struct phy_device *fixed_phy_register(un
return ERR_PTR(ret);
phy = get_phy_device(fmb->mii_bus, phy_addr, false);
- if (!phy || IS_ERR(phy)) {
+ if (IS_ERR(phy)) {
fixed_phy_del(phy_addr);
return ERR_PTR(-EINVAL);
}
^ permalink raw reply
* [PATCH 2/5] xgene: get_phy_device() doesn't return NULL anymore
From: Sergei Shtylyov @ 2016-04-24 17:27 UTC (permalink / raw)
To: f.fainelli, isubramanian, kchudgar; +Cc: netdev, arnd
In-Reply-To: <56219623.1S7UfcqQqc@wasted.cogentembedded.com>
Now that get_phy_device() no longer returns NULL on error, we don't need
to check for it...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
===================================================================
--- net-next.orig/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ net-next/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -824,7 +824,7 @@ static int xgene_mdiobus_register(struct
return -EINVAL;
phy = get_phy_device(mdio, phy_id, false);
- if (!phy || IS_ERR(phy))
+ if (IS_ERR(phy))
return -EIO;
ret = phy_device_register(phy);
^ permalink raw reply
* [PATCH 1/5] phylib: don't return NULL from get_phy_device()
From: Sergei Shtylyov @ 2016-04-24 17:25 UTC (permalink / raw)
To: f.fainelli, netdev; +Cc: arnd
In-Reply-To: <56219623.1S7UfcqQqc@wasted.cogentembedded.com>
Arnd Bergmann asked that get_phy_device() returns either NULL or the error
value, not both on error. Do as he said, return ERR_PTR(-ENODEV) instead
of NULL when the PHY ID registers read as all ones.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/phy/phy_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net-next/drivers/net/phy/phy_device.c
===================================================================
--- net-next.orig/drivers/net/phy/phy_device.c
+++ net-next/drivers/net/phy/phy_device.c
@@ -529,7 +529,7 @@ struct phy_device *get_phy_device(struct
/* If the phy_id is mostly Fs, there is no device there */
if ((phy_id & 0x1fffffff) == 0x1fffffff)
- return NULL;
+ return ERR_PTR(-ENODEV);
return phy_device_create(bus, addr, phy_id, is_c45, &c45_ids);
}
^ permalink raw reply
* [PATCH 0/5] Don't return NULL from get_phy_device() anymore
From: Sergei Shtylyov @ 2016-04-24 17:23 UTC (permalink / raw)
To: f.fainelli, netdev; +Cc: arnd
Hello.
Here's the set of 5 patches against DaveM's 'net-next.git' repo. The first
patch makes get_phy_device() return only error values on error, the rest of
the patches clean up the callers of that function...
[1/5] phylib-don-t-return-NULL-from-get_phy_device.patch
[2/5] xgene-get_phy_device-doesn-t-return-NULL-anymore.patch
[3/5] fixed_phy-get_phy_device-doesn-t-return-NULL-anymore.patch
[4/5] mdio_bus-get_phy_device-doesn-t-return-NULL-anymore.patch
[5/5] of_mdio-get_phy_device-doesn-t-return-NULL-anymore.patch
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] ravb: Remove rx buffer ALIGN
From: Yoshihiro Kaneko @ 2016-04-24 16:16 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Sergei Shtylyov, Simon Horman, Magnus Damm,
linux-renesas-soc
From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Aligning the reception data size is not required.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
---
This patch is based on the master branch of David Miller's next networking
tree.
drivers/net/ethernet/renesas/ravb_main.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 238b56f..66ed80c 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -246,10 +246,10 @@ static void ravb_ring_format(struct net_device *ndev, int q)
for (i = 0; i < priv->num_rx_ring[q]; i++) {
/* RX descriptor */
rx_desc = &priv->rx_ring[q][i];
- /* The size of the buffer should be on 16-byte boundary. */
- rx_desc->ds_cc = cpu_to_le16(ALIGN(PKT_BUF_SZ, 16));
- dma_addr = dma_map_single(ndev->dev.parent, priv->rx_skb[q][i]->data,
- ALIGN(PKT_BUF_SZ, 16),
+ rx_desc->ds_cc = cpu_to_le16(PKT_BUF_SZ);
+ dma_addr = dma_map_single(ndev->dev.parent,
+ priv->rx_skb[q][i]->data,
+ PKT_BUF_SZ,
DMA_FROM_DEVICE);
/* We just set the data size to 0 for a failed mapping which
* should prevent DMA from happening...
@@ -557,8 +557,9 @@ static bool ravb_rx(struct net_device *ndev, int *quota, int q)
skb = priv->rx_skb[q][entry];
priv->rx_skb[q][entry] = NULL;
- dma_unmap_single(ndev->dev.parent, le32_to_cpu(desc->dptr),
- ALIGN(PKT_BUF_SZ, 16),
+ dma_unmap_single(ndev->dev.parent,
+ le32_to_cpu(desc->dptr),
+ PKT_BUF_SZ,
DMA_FROM_DEVICE);
get_ts &= (q == RAVB_NC) ?
RAVB_RXTSTAMP_TYPE_V2_L2_EVENT :
@@ -588,8 +589,7 @@ static bool ravb_rx(struct net_device *ndev, int *quota, int q)
for (; priv->cur_rx[q] - priv->dirty_rx[q] > 0; priv->dirty_rx[q]++) {
entry = priv->dirty_rx[q] % priv->num_rx_ring[q];
desc = &priv->rx_ring[q][entry];
- /* The size of the buffer should be on 16-byte boundary. */
- desc->ds_cc = cpu_to_le16(ALIGN(PKT_BUF_SZ, 16));
+ desc->ds_cc = cpu_to_le16(PKT_BUF_SZ);
if (!priv->rx_skb[q][entry]) {
skb = netdev_alloc_skb(ndev,
--
1.9.1
^ permalink raw reply related
* [PATCH] sh_eth: get rid of the 2nd parameter to sh_eth_dev_init()
From: Sergei Shtylyov @ 2016-04-24 16:11 UTC (permalink / raw)
To: netdev, linux-renesas-soc
sh_eth_dev_init() is now always called with 'true' as the 2nd argument,
so that there's no more sense in having 2 parameters to this function...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net-next.git' repo.
drivers/net/ethernet/renesas/sh_eth.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1229,7 +1229,7 @@ ring_free:
return -ENOMEM;
}
-static int sh_eth_dev_init(struct net_device *ndev, bool start)
+static int sh_eth_dev_init(struct net_device *ndev)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
int ret;
@@ -1279,10 +1279,8 @@ static int sh_eth_dev_init(struct net_de
RFLR);
sh_eth_modify(ndev, EESR, 0, 0);
- if (start) {
- mdp->irq_enabled = true;
- sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
- }
+ mdp->irq_enabled = true;
+ sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
/* PAUSE Prohibition */
sh_eth_write(ndev, ECMR_ZPF | (mdp->duplex ? ECMR_DM : 0) |
@@ -1295,8 +1293,7 @@ static int sh_eth_dev_init(struct net_de
sh_eth_write(ndev, mdp->cd->ecsr_value, ECSR);
/* E-MAC Interrupt Enable register */
- if (start)
- sh_eth_write(ndev, mdp->cd->ecsipr_value, ECSIPR);
+ sh_eth_write(ndev, mdp->cd->ecsipr_value, ECSIPR);
/* Set MAC address */
update_mac_address(ndev);
@@ -1309,10 +1306,8 @@ static int sh_eth_dev_init(struct net_de
if (mdp->cd->tpauser)
sh_eth_write(ndev, TPAUSER_UNLIMITED, TPAUSER);
- if (start) {
- /* Setting the Rx mode will start the Rx process. */
- sh_eth_write(ndev, EDRRR_R, EDRRR);
- }
+ /* Setting the Rx mode will start the Rx process. */
+ sh_eth_write(ndev, EDRRR_R, EDRRR);
return ret;
}
@@ -2194,7 +2189,7 @@ static int sh_eth_set_ringparam(struct n
__func__);
return ret;
}
- ret = sh_eth_dev_init(ndev, true);
+ ret = sh_eth_dev_init(ndev);
if (ret < 0) {
netdev_err(ndev, "%s: sh_eth_dev_init failed.\n",
__func__);
@@ -2246,7 +2241,7 @@ static int sh_eth_open(struct net_device
goto out_free_irq;
/* device init */
- ret = sh_eth_dev_init(ndev, true);
+ ret = sh_eth_dev_init(ndev);
if (ret)
goto out_free_irq;
@@ -2299,7 +2294,7 @@ static void sh_eth_tx_timeout(struct net
}
/* device init */
- sh_eth_dev_init(ndev, true);
+ sh_eth_dev_init(ndev);
netif_start_queue(ndev);
}
^ permalink raw reply
* [PATCH net-next] sctp: sctp_diag should fill RMEM_ALLOC with asoc->rmem_alloc when rcvbuf_policy is set
From: Xin Long @ 2016-04-24 15:21 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Vlad Yasevich, daniel, davem,
eric.dumazet
For sctp assoc, when rcvbuf_policy is set, it will has it's own
rmem_alloc, when we dump asoc info in sctp_diag, we should use that
value on RMEM_ALLOC as well, just like WMEM_ALLOC.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/sctp_diag.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
index bb2d8d9..b5269df 100644
--- a/net/sctp/sctp_diag.c
+++ b/net/sctp/sctp_diag.c
@@ -145,7 +145,11 @@ static int inet_sctp_diag_fill(struct sock *sk, struct sctp_association *asoc,
else
amt = sk_wmem_alloc_get(sk);
mem[SK_MEMINFO_WMEM_ALLOC] = amt;
- mem[SK_MEMINFO_RMEM_ALLOC] = sk_rmem_alloc_get(sk);
+ if (asoc && asoc->ep->rcvbuf_policy)
+ amt = atomic_read(&asoc->rmem_alloc);
+ else
+ amt = sk_rmem_alloc_get(sk);
+ mem[SK_MEMINFO_RMEM_ALLOC] = amt;
mem[SK_MEMINFO_RCVBUF] = sk->sk_rcvbuf;
mem[SK_MEMINFO_SNDBUF] = sk->sk_sndbuf;
mem[SK_MEMINFO_FWD_ALLOC] = sk->sk_forward_alloc;
--
2.1.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox