* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: Saeed Mahameed @ 2019-08-06 20:42 UTC (permalink / raw)
To: hslester96@gmail.com
Cc: linux-rdma@vger.kernel.org, davem@davemloft.net,
netdev@vger.kernel.org, leon@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190802164828.20243-1-hslester96@gmail.com>
On Sat, 2019-08-03 at 00:48 +0800, Chuhong Yuan wrote:
> refcount_t is better for reference counters since its
> implementation can prevent overflows.
> So convert atomic_t ref counters to refcount_t.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> Changes in v2:
> - Add #include.
>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Dave, up to you take it, or leave it to me :).
^ permalink raw reply
* Re: [PATCH v6 1/3] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: John Hubbard @ 2019-08-06 20:43 UTC (permalink / raw)
To: Ira Weiny, john.hubbard
Cc: Andrew Morton, Alexander Viro, Björn Töpel,
Boaz Harrosh, Christoph Hellwig, Daniel Vetter, Dan Williams,
Dave Chinner, David Airlie, David S . Miller, Ilya Dryomov,
Jan Kara, Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML
In-Reply-To: <20190806174017.GB4748@iweiny-DESK2.sc.intel.com>
On 8/6/19 10:40 AM, Ira Weiny wrote:
> On Sun, Aug 04, 2019 at 02:40:40PM -0700, john.hubbard@gmail.com wrote:
>> From: John Hubbard <jhubbard@nvidia.com>
>>
>> Provide a more capable variation of put_user_pages_dirty_lock(),
>> and delete put_user_pages_dirty(). This is based on the
>> following:
>>
>> 1. Lots of call sites become simpler if a bool is passed
>> into put_user_page*(), instead of making the call site
>> choose which put_user_page*() variant to call.
>>
>> 2. Christoph Hellwig's observation that set_page_dirty_lock()
>> is usually correct, and set_page_dirty() is usually a
>> bug, or at least questionable, within a put_user_page*()
>> calling chain.
>>
>> This leads to the following API choices:
>>
>> * put_user_pages_dirty_lock(page, npages, make_dirty)
>>
>> * There is no put_user_pages_dirty(). You have to
>> hand code that, in the rare case that it's
>> required.
>>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>> Cc: Matthew Wilcox <willy@infradead.org>
>> Cc: Jan Kara <jack@suse.cz>
>> Cc: Ira Weiny <ira.weiny@intel.com>
>> Cc: Jason Gunthorpe <jgg@ziepe.ca>
>> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
>
> I assume this is superseded by the patch in the large series?
>
Actually, it's the other way around (there is a note that that effect
in the admittedly wall-of-text cover letter [1] in the 34-patch series.
However, I'm trying hard to ensure that it doesn't actually matter:
* Patch 1 in the latest of each patch series, is identical
* I'm reposting the two series together.
...and yes, it might have been better to merge the two patchsets, but
the smaller one is more reviewable. And as a result, Andrew has already
merged it into the akpm tree.
[1] https://lore.kernel.org/r/20190804224915.28669-1-jhubbard@nvidia.com
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: David Miller @ 2019-08-06 20:48 UTC (permalink / raw)
To: saeedm; +Cc: hslester96, linux-rdma, netdev, leon, linux-kernel
In-Reply-To: <aaf9680afe5c62d0cf71ff4382b66b3e4d735008.camel@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 6 Aug 2019 20:42:56 +0000
> On Sat, 2019-08-03 at 00:48 +0800, Chuhong Yuan wrote:
>> refcount_t is better for reference counters since its
>> implementation can prevent overflows.
>> So convert atomic_t ref counters to refcount_t.
>>
>> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
>> ---
>> Changes in v2:
>> - Add #include.
>>
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
>
> Dave, up to you take it, or leave it to me :).
Please take it, thank you.
^ permalink raw reply
* Re: [PATCH net] inet: frags: re-introduce skb coalescing for local delivery
From: David Miller @ 2019-08-06 20:57 UTC (permalink / raw)
To: gnault; +Cc: netdev, fw, edumazet, posk, alex.aring
In-Reply-To: <22d8da10c97214edd0677e6478093ad9376180ef.1564758715.git.gnault@redhat.com>
From: Guillaume Nault <gnault@redhat.com>
Date: Fri, 2 Aug 2019 17:15:03 +0200
> Before commit d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6
> defrag"), a netperf UDP_STREAM test[0] using big IPv6 datagrams (thus
> generating many fragments) and running over an IPsec tunnel, reported
> more than 6Gbps throughput. After that patch, the same test gets only
> 9Mbps when receiving on a be2net nic (driver can make a big difference
> here, for example, ixgbe doesn't seem to be affected).
>
> By reusing the IPv4 defragmentation code, IPv6 lost fragment coalescing
> (IPv4 fragment coalescing was dropped by commit 14fe22e33462 ("Revert
> "ipv4: use skb coalescing in defragmentation"")).
...
> Re-introducing fragment coalescing is enough to get the initial
> performances again (6.6Gbps with be2net): driver doesn't drop frames
> anymore (no more rx_drops_no_frags errors) and the reassembly engine
> works at full speed.
>
> This patch is quite conservative and only coalesces skbs for local
> IPv4 and IPv6 delivery (in order to avoid changing skb geometry when
> forwarding). Coalescing could be extended in the future if need be, as
> more scenarios would probably benefit from it.
Eric and Florian, please review.
^ permalink raw reply
* Re: [PATCH][net-next][V2] net/mlx5: remove self-assignment on esw->dev
From: Saeed Mahameed @ 2019-08-06 21:01 UTC (permalink / raw)
To: linux-rdma@vger.kernel.org, colin.king@canonical.com,
davem@davemloft.net, leon@kernel.org, netdev@vger.kernel.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190802151316.16011-1-colin.king@canonical.com>
On Fri, 2019-08-02 at 16:13 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a self assignment of esw->dev to itself, clean this up by
> removing it. Also make dev a const pointer.
>
> Addresses-Coverity: ("Self assignment")
> Fixes: 6cedde451399 ("net/mlx5: E-Switch, Verify support QoS element
> type")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>
> V2: make dev const
>
Applied to mlx5-next.
Thanks,
Saeed.
^ permalink raw reply
* Re: [PATCH net 0/2] Fix batched event generation for vlan action
From: David Miller @ 2019-08-06 21:06 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1564773407-26209-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Fri, 2 Aug 2019 15:16:45 -0400
> When adding or deleting a batch of entries, the kernel sends up to
> TCA_ACT_MAX_PRIO (defined to 32 in kernel) entries in an event to user
> space. However it does not consider that the action sizes may vary and
> require different skb sizes.
>
> For example, consider the following script adding 32 entries with all
> supported vlan parameters (in order to maximize netlink messages size):
>
> % cat tc-batch.sh
> TC="sudo /mnt/iproute2.git/tc/tc"
>
> $TC actions flush action vlan
> for i in `seq 1 $1`;
> do
> cmd="action vlan push protocol 802.1q id 4094 priority 7 pipe \
> index $i cookie aabbccddeeff112233445566778800a1 "
> args=$args$cmd
> done
> $TC actions add $args
> %
> % ./tc-batch.sh 32
> Error: Failed to fill netlink attributes while adding TC action.
> We have an error talking to the kernel
> %
>
> patch 1 adds callback in tc_action_ops of vlan action, which calculates
> the action size, and passes size to tcf_add_notify()/tcf_del_notify().
>
> patch 2 updates the TDC test suite with relevant vlan test cases.
Series applied and patch #1 queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: dump CPU port regs through master
From: David Miller @ 2019-08-06 21:08 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, f.fainelli, andrew, linville, cphealy
In-Reply-To: <20190802193455.17126-2-vivien.didelot@gmail.com>
From: Vivien Didelot <vivien.didelot@gmail.com>
Date: Fri, 2 Aug 2019 15:34:55 -0400
> Merge the CPU port registers dump into the master interface registers
> dump through ethtool, by nesting the ethtool_drvinfo and ethtool_regs
> structures of the CPU port into the dump.
>
> drvinfo->regdump_len will contain the full data length, while regs->len
> will contain only the master interface registers dump length.
>
> This allows for example to dump the CPU port registers on a ZII Dev
> C board like this:
...
> Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
Applied, thanks Vivien.
^ permalink raw reply
* Re: [PATCH v2] net: mdio-octeon: Fix Kconfig warnings and build errors
From: David Miller @ 2019-08-06 21:11 UTC (permalink / raw)
To: natechancellor
Cc: andrew, broonie, devel, f.fainelli, gregkh, hkallweit1,
kernel-build-reports, linux-arm-kernel, linux-next, lkp, netdev,
rdunlap, willy
In-Reply-To: <20190803060155.89548-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Fri, 2 Aug 2019 23:01:56 -0700
> After commit 171a9bae68c7 ("staging/octeon: Allow test build on
> !MIPS"), the following combination of configs cause a few Kconfig
> warnings and build errors (distilled from arm allyesconfig and Randy's
> randconfig builds):
>
> CONFIG_NETDEVICES=y
> CONFIG_STAGING=y
> CONFIG_COMPILE_TEST=y
>
> and CONFIG_OCTEON_ETHERNET as either a module or built-in.
>
> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
> Selected by [y]:
> - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
> COMPILE_TEST [=y]) && NETDEVICES [=y]
>
> In file included from ../drivers/net/phy/mdio-octeon.c:14:
> ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> function ‘writeq’; did you mean ‘writel’?
> [-Werror=implicit-function-declaration]
> 111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
> | ^~~~~~
>
> CONFIG_64BIT is not strictly necessary if the proper readq/writeq
> definitions are included from io-64-nonatomic-lo-hi.h.
>
> CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
> of commit f9dc9ac51610 ("of/mdio: Add dummy functions in of_mdio.h.").
>
> Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
> Reported-by: kbuild test robot <lkp@intel.com>
> Reported-by: Mark Brown <broonie@kernel.org>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied to net-next.
Please make it clear what tree your changes are targetting in the future,
thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: modify assignment to OR for dev_flags in phy_attach_direct
From: Andrew Lunn @ 2019-08-06 21:11 UTC (permalink / raw)
To: Tao Ren
Cc: Florian Fainelli, Heiner Kallweit, David S . Miller,
Vladimir Oltean, Arun Parameswaran, Justin Chen, netdev,
linux-kernel, openbmc
In-Reply-To: <20190805185551.3140564-1-taoren@fb.com>
On Mon, Aug 05, 2019 at 11:55:51AM -0700, Tao Ren wrote:
> Modify the assignment to OR when dealing with phydev->dev_flags in
> phy_attach_direct function, and this is to make sure dev_flags set in
> driver's probe callback won't be lost.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> CC: Heiner Kallweit <hkallweit1@gmail.com>
> CC: Vladimir Oltean <olteanv@gmail.com>
> Signed-off-by: Tao Ren <taoren@fb.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v1 0/3] net: hisilicon: Fix a few problems with hip04_eth
From: David Miller @ 2019-08-06 21:15 UTC (permalink / raw)
To: xiaojiangfeng
Cc: yisen.zhuang, salil.mehta, netdev, linux-kernel, leeyou.li,
xiaowei774, nixiaoming
In-Reply-To: <1564835501-90257-1-git-send-email-xiaojiangfeng@huawei.com>
From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date: Sat, 3 Aug 2019 20:31:38 +0800
> During the use of the hip04_eth driver,
> several problems were found,
> which solved the hip04_tx_reclaim reentry problem,
> fixed the problem that hip04_mac_start_xmit never
> returns NETDEV_TX_BUSY
> and the dma_map_single failed on the arm64 platform.
Series applied.
^ permalink raw reply
* Re: [PATCH net 0/2] action fixes for flow_offload infra compatibility
From: David Miller @ 2019-08-06 21:15 UTC (permalink / raw)
To: vladbu; +Cc: netdev, pieter.jansenvanvuuren, jhs, xiyou.wangcong, jiri
In-Reply-To: <20190803133619.10574-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Sat, 3 Aug 2019 16:36:17 +0300
> Fix rcu warnings due to usage of action helpers that expect rcu read lock
> protection from rtnl-protected context of flow_offload infra.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Two small fq_codel optimizations
From: David Miller @ 2019-08-06 21:18 UTC (permalink / raw)
To: dave.taht; +Cc: netdev
In-Reply-To: <1564875449-12122-1-git-send-email-dave.taht@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Sat, 3 Aug 2019 16:37:27 -0700
> These two patches improve fq_codel performance
> under extreme network loads. The first patch
> more rapidly escalates the codel count under
> overload, the second just kills a totally useless
> statistic.
>
> (sent together because they'd otherwise conflict)
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: remove access to legacy register MultiIntr
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <d550e704-3854-d91e-22fd-253ede944c3e@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:42:57 +0200
> This code piece was inherited from RTL8139 code, the register at
> address 0x5c however has a different meaning on RTL8169 and is unused.
> So we can remove this.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: add helper r8168_mac_ocp_modify
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <dc905b86-2852-86c2-be14-22164bd4a06d@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:47:51 +0200
> Add a helper for MAC OCP read-modify-write operations.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] r8169: sync PCIe PHY init with vendor driver 8.047.01
From: David Miller @ 2019-08-06 21:20 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <52b6804e-b2d4-0724-9b71-45ec46f4b1b4@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 4 Aug 2019 09:52:33 +0200
> Synchronize PCIe PHY initialization with vendor driver version 8.047.01.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next 0/8][pull request] 100GbE Intel Wired LAN Driver Updates 2019-08-04
From: David Miller @ 2019-08-06 21:21 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190804115926.31944-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 4 Aug 2019 04:59:18 -0700
> This series contains more updates to fm10k from Jake Keller.
>
> Jake removes the unnecessary initialization of some variables to help
> resolve static code checker warnings. Explicitly return success during
> resume, since the value of 'err' is always success. Fixed a issue with
> incrementing a void pointer, which can produce undefined behavior. Used
> the __always_unused macro for function templates that are passed as
> parameters in functions, but are not used. Simplified the code by
> removing an unnecessary macro in determining the value of NON_Q_VECTORS.
> Fixed an issue, using bitwise operations to prevent the low address
> overwriting the high portion of the address.
Pulled, thanks Jeff.
^ permalink raw reply
* linux-next: Fixes tag needs some work in the net tree
From: Stephen Rothwell @ 2019-08-06 21:22 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roman Mashak
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi all,
In commit
b35475c5491a ("net sched: update vlan action for batched events operations")
Fixes tag
Fixes: c7e2b9689 ("sched: introduce vlan action")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 00/10] Support tunnels over VLAN in NFP
From: David Miller @ 2019-08-06 21:24 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1564931351-1036-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Sun, 4 Aug 2019 16:09:02 +0100
> This patchset deals with tunnel encap and decap when the end-point IP
> address is on an internal port (for example and OvS VLAN port). Tunnel
> encap without VLAN is already supported in the NFP driver. This patchset
> extends that to include a push VLAN along with tunnel header push.
>
> Patches 1-4 extend the flow_offload IR API to include actions that use
> skbedit to set the ptype of an SKB and that send a packet to port ingress
> from the act_mirred module. Such actions are used in flower rules that
> forward tunnel packets to internal ports where they can be decapsulated.
> OvS and its TC API is an example of a user-space app that produces such
> rules.
>
> Patch 5 modifies the encap offload code to allow the pushing of a VLAN
> header after a tunnel header push.
>
> Patches 6-10 deal with tunnel decap when the end-point is on an internal
> port. They detect 'pre-tunnel rules' which do not deal with tunnels
> themselves but, rather, forward packets to internal ports where they
> can be decapped if required. Such rules are offloaded to a table in HW
> along with an indication of whether packets need to be passed to this
> table of not (based on their destination MAC address). Matching against
> this table prior to decapsulation in HW allows the correct parsing and
> handling of outer VLANs on tunnelled packets and the correct updating of
> stats for said 'pre-tunnel' rules.
Series applied, thanks John.
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: Saeed Mahameed @ 2019-08-06 21:25 UTC (permalink / raw)
To: davem@davemloft.net
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
hslester96@gmail.com, linux-rdma@vger.kernel.org, leon@kernel.org
In-Reply-To: <20190806.134848.2232719643712591918.davem@davemloft.net>
On Tue, 2019-08-06 at 13:48 -0700, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Tue, 6 Aug 2019 20:42:56 +0000
>
> > On Sat, 2019-08-03 at 00:48 +0800, Chuhong Yuan wrote:
> > > refcount_t is better for reference counters since its
> > > implementation can prevent overflows.
> > > So convert atomic_t ref counters to refcount_t.
> > >
> > > Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> > > ---
> > > Changes in v2:
> > > - Add #include.
> > >
> >
> > Acked-by: Saeed Mahameed <saeedm@mellanox.com>
> >
> > Dave, up to you take it, or leave it to me :).
>
> Please take it, thank you.
Ok, running some build tests will apply shortly to net-next-mlx5.
Thanks everyone!
^ permalink raw reply
* Re: [PATCH net 0/5] Fixes for SJA1105 DSA: FDBs, Learning and PTP
From: David Miller @ 2019-08-06 21:38 UTC (permalink / raw)
To: olteanv; +Cc: f.fainelli, vivien.didelot, andrew, netdev
In-Reply-To: <20190804223848.31676-1-olteanv@gmail.com>
From: Vladimir Oltean <olteanv@gmail.com>
Date: Mon, 5 Aug 2019 01:38:43 +0300
> This is an assortment of functional fixes for the sja1105 switch driver
> targeted for the "net" tree (although they apply on net-next just as
> well).
>
> Patch 1/5 ("net: dsa: sja1105: Fix broken learning with vlan_filtering
> disabled") repairs a breakage introduced in the early development stages
> of the driver: support for traffic from the CPU has broken "normal"
> frame forwarding (based on DMAC) - there is connectivity through the
> switch only because all frames are flooded.
> I debated whether this patch qualifies as a fix, since it puts the
> switch into a mode it has never operated in before (aka SVL). But
> "normal" forwarding did use to work before the "Traffic support for
> SJA1105 DSA driver" patchset, and arguably this patch should have been
> part of that.
> Also, it would be strange for this feature to be broken in the 5.2 LTS.
>
> Patch 2/5 ("net: dsa: sja1105: Use the LOCKEDS bit for SJA1105 E/T as
> well") is a simplification of a previous FDB-related patch that is
> currently in the 5.3 rc's.
>
> Patches 3/5 - 5/5 fix various crashes found while running linuxptp over the
> switch ports for extended periods of time, or in conjunction with other
> error conditions. The fixed-up commits were all introduced in 5.2.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next v2] openvswitch: Print error when ovs_execute_actions() fails
From: David Miller @ 2019-08-06 21:38 UTC (permalink / raw)
To: pkusunyifeng; +Cc: netdev, pshelar, gvrose8192
In-Reply-To: <1564973771-22542-1-git-send-email-pkusunyifeng@gmail.com>
From: Yifeng Sun <pkusunyifeng@gmail.com>
Date: Sun, 4 Aug 2019 19:56:11 -0700
> Currently in function ovs_dp_process_packet(), return values of
> ovs_execute_actions() are silently discarded. This patch prints out
> an debug message when error happens so as to provide helpful hints
> for debugging.
> ---
> v1->v2: Fixed according to Pravin's review.
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/5] r8152: replace array with linking list for rx information
From: Jakub Kicinski @ 2019-08-06 21:40 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <20190806125342.4620a94f@cakuba.netronome.com>
On Tue, 6 Aug 2019 12:53:42 -0700, Jakub Kicinski wrote:
> > @@ -744,6 +745,8 @@ struct r8152 {
> > void (*autosuspend_en)(struct r8152 *tp, bool enable);
> > } rtl_ops;
> >
> > + atomic_t rx_count;
>
> I wonder what the advantage of rx_count being atomic is, perhpas it
> could be protected by the same lock as the list head?
Okay, I see you're using it to test the queue length without the lock in
a later patch.
^ permalink raw reply
* Re: [net-next v2 0/8][pull request] 40GbE Intel Wired LAN Driver Updates 2019-08-05
From: David Miller @ 2019-08-06 21:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190805185459.12846-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 5 Aug 2019 11:54:51 -0700
> This series contains updates to i40e driver only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] net: dsa: qca8k: Add of_node_put() in qca8k_setup_mdio_bus()
From: David Miller @ 2019-08-06 21:35 UTC (permalink / raw)
To: nishkadg.linux; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20190804153019.2317-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Sun, 4 Aug 2019 21:00:18 +0530
> Each iteration of for_each_available_child_of_node() puts the previous
> node, but in the case of a return from the middle of the loop, there
> is no put, thus causing a memory leak. Hence add an of_node_put() before
> the return.
> Additionally, the local variable ports in the function
> qca8k_setup_mdio_bus() takes the return value of of_get_child_by_name(),
> which gets a node but does not put it. If the function returns without
> putting ports, it may cause a memory leak. Hence put ports before the
> mid-loop return statement, and also outside the loop after its last usage
> in this function.
> Issues found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Appplied.
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S
From: Tao Ren @ 2019-08-06 21:42 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S . Miller,
Arun Parameswaran, Justin Chen, Vladimir Oltean,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20190806210931.3723590-1-taoren@fb.com>
Hi Andrew / Heiner / Vladimir,
On 8/6/19 2:09 PM, Tao Ren wrote:
> The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
> example, on Facebook CMM BMC platform), mainly because genphy functions
> are designed for copper links, and 1000Base-X (clause 37) auto negotiation
> needs to be handled differently.
>
> This patch enables 1000Base-X support for BCM54616S by customizing 3
> driver callbacks:
>
> - probe: probe callback detects PHY's operation mode based on
> INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX
> Control register.
>
> - config_aneg: bcm54616s_config_aneg_1000bx function is added for auto
> negotiation in 1000Base-X mode.
>
> - read_status: BCM54616S and BCM5482 PHY share the same read_status
> callback which manually set link speed and duplex mode in 1000Base-X
> mode.
>
> Signed-off-by: Tao Ren <taoren@fb.com>
I customized config_aneg function for BCM54616S 1000Base-X mode and link-down issue is also fixed: the patch is tested on Facebook CMM and Minipack BMC and everything looks normal. Please kindly review when you have bandwidth and let me know if you have further suggestions.
BTW, I would be happy to help if we decide to add a set of genphy functions for clause 37, although that may mean I need more help/guidance from you :-)
Cheers,
Tao
^ 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