* [bpf-next 0/2] cleanup SOCK_DEBUG() and introduce BPF_SOCK_OPS_STATS_CB
From: Yafang Shao @ 2019-02-12 11:31 UTC (permalink / raw)
To: daniel, ast
Cc: yhs, brakmo, edumazet, davem, netdev, linux-kernel, shaoyafang,
Yafang Shao
SOCK_DEBUG is a very ancient debugging interface, and it's not very useful
for debugging.
This pacthset cleanups SOCK_DEBUG() and replace it with a new methord
based on BPF.
I cleanup SOCK_DEBUG() only for TCP, and other protocols are kept as is.
After this patchset, the SO_DEBUG interface will not take any effect for
TCP, but I still keep it in sock_{s,g}etsockopt() for TCP to avoid breaking
applications.
In the future we may extend tcp_stats() as bellow or something else to
cover all the LINUX_MIB_* and TCP_MIB_* proposaled[0] in the netconf2018.
now:
tcp_stats(struct sock *sk, int mib_idx)
future:
tcp_stats(struct sock *sk, int mib_idx, int packets)
The argument packets can be 1 to indicates this is a event only;
and skb_shinfo(skb)->gso_segs to indicates the number of packets
are also concerned.
[0] page 14,
http://vger.kernel.org/netconf2018_files/BrendanGregg_netconf2018.pdf
Yafang Shao (2):
tcp: replace SOCK_DEBUG() with tcp_stats()
bpf: add BPF_SOCK_OPS_STATS_CB for tcp_stats()
include/uapi/linux/bpf.h | 5 +++++
include/uapi/linux/snmp.h | 3 +++
net/ipv4/proc.c | 3 +++
net/ipv4/tcp_input.c | 27 ++++++++++++---------------
net/ipv6/tcp_ipv6.c | 2 --
5 files changed, 23 insertions(+), 17 deletions(-)
--
1.8.3.1
^ permalink raw reply
* RE: [PATCH V1 net 2/2] net: ena: update driver version from 2.0.2 to 2.0.3
From: Kiyanovski, Arthur @ 2019-02-12 11:42 UTC (permalink / raw)
To: Moritz Fischer
Cc: David S. Miller, netdev@vger.kernel.org, Woodhouse, David,
Machulsky, Zorik, Matushevsky, Alexander, Bshara, Saeed,
Wilson, Matt, Liguori, Anthony, Bshara, Nafea, Tzalik, Guy,
Belgazal, Netanel, Saidi, Ali
In-Reply-To: <CAAtXAHefiwhcDYnSXPjj5_NJ5dJ44L3OAkqLp6viYYHXbfn_1A@mail.gmail.com>
Hi Moritz,
> -----Original Message-----
> From: Moritz Fischer <moritz.fischer@ettus.com>
> Subject: Re: [PATCH V1 net 2/2] net: ena: update driver version from 2.0.2 to
> 2.0.3
>
> Hi Arthur,
>
> On Mon, Feb 11, 2019 at 9:19 AM <akiyano@amazon.com> wrote:
> >
> > From: Arthur Kiyanovski <akiyano@amazon.com>
> >
> > Update driver version due to bug fix.
>
> Wouldn't you want to do this atomically with the actual fix in one commit?
>
> Thanks,
> Moritz
Thanks for the feedback.
I don't want to add the version to the fix.
Version 2.0.3 includes all of its content that came before this fix, including features.
Fixes are cherry-picked to older driver versions automatically using the "Fixes:" directive.
If I add the version change to the fix, older driver versions that get this fix will become version 2.0.3, which is incorrect feature-wise.
Thanks,
Arthur
^ permalink raw reply
* pull-request: mac80211 2019-02-12
From: Johannes Berg @ 2019-02-12 11:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
We have few more fixes, mostly one-liners; two are bigger:
* the speculation one, only because the function had multiple
return points and that had to change, and
* the peer measurement locking one, because I had to refactor
a function to be able to call it with or without locking
(depending on context).
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit f09bef61f1ed72869b231e5cff16e73a06505cfb:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf (2019-02-05 11:23:23 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2019-02-12
for you to fetch changes up to 6157ca0d6bfe437691b1e98a62e2efe12b6714da:
mac80211: Fix Tx aggregation session tear down with ITXQs (2019-02-11 15:50:56 +0100)
----------------------------------------------------------------
Just a few fixes:
* aggregation session teardown with internal TXQs was
continuing to send some frames marked as aggregation,
fix from Ilan
* IBSS join was missed during firmware restart, should
such a thing happen
* speculative execution based on the return value of
cfg80211_classify8021d() - which is controlled by the
sender of the packet - could be problematic in some
code using it, prevent it
* a few peer measurement fixes
----------------------------------------------------------------
Aviya Erenfeld (1):
nl80211: Fix FTM per burst maximum value
Ilan Peer (1):
mac80211: Fix Tx aggregation session tear down with ITXQs
Johannes Berg (5):
cfg80211: pmsr: fix MAC address setting
cfg80211: pmsr: fix abort locking
mac80211: call drv_ibss_join() on restart
cfg80211: pmsr: record netlink port ID
cfg80211: prevent speculation on cfg80211_classify8021d() return
net/mac80211/agg-tx.c | 4 +++-
net/mac80211/util.c | 6 +++++-
net/wireless/core.c | 2 ++
net/wireless/nl80211.c | 2 +-
net/wireless/pmsr.c | 26 +++++++++++++++++---------
net/wireless/util.c | 35 ++++++++++++++++++++++++-----------
6 files changed, 52 insertions(+), 23 deletions(-)
^ permalink raw reply
* Re: [v3,4/5] net: phy: at803x: Disable phy delay for RGMII mode
From: Peter Ujfalusi @ 2019-02-12 12:09 UTC (permalink / raw)
To: Vinod Koul
Cc: David S Miller, Roger Quadros, netdev, linux-arm-msm,
Niklas Cassel, Bjorn Andersson, Andrew Lunn, Florian Fainelli,
Nori, Sekhar
In-Reply-To: <20190212113114.GZ4296@vkoul-mobl>
Hi Vinod,
On 12/02/2019 13.31, Vinod Koul wrote:
> Hi Peter,
>
> On 12-02-19, 12:55, Peter Ujfalusi wrote:
>> Vinod,
>>
>> On 21/01/2019 11.13, Vinod Koul wrote:
>>> For RGMII mode, phy delay should be disabled. Add this case along
>>> with disable delay routines.
>>
>> In next-20190211 I need to revert this patch to get cpsw networking to
>> work on am335x-evmsk. The board uses AR8031_AL1A PHY, which is handled
>> by the phy/at803x.c
>
> I see that DTS specifies that you are using phy-mode = "rgmii-txid".
> RGMII mode implies that we should not have any delay in the
> phy, so this patch does the right thing.
Right, on am335x-evmsk:
[ 3.393406] at803x_config_init: phydev->interface: 11
So PHY_INTERFACE_MODE_RGMII_TXID.
> In the previous version of the patch I did propose to add a DT entry so
> that current users who are wrongly using this would not be impacted but
> the suggestion was to get them fixed.
>
> So in you case do you need rgmii-txd mode if so why should the delay be
> enabled for this? We can add a patch that enabled delay for your
> controller but that cant be rgmii mode.
I'm not too familiar with the networking, but the AR8031 datasheet does
tell that the debug_5:bit8 is 0 by default (rgmii tx clock delay disable).
In the errata document of am335x (http://www.ti.com/lit/pdf/sprz360),
1.0.10 I believe tells that the delay needs to be enabled on the rgmii
ethernet PHY because the internal delay is not working (?) and advises
that the delay might need to be enabled on the rgmii PHY.
The PHY_INTERFACE_MODE_RGMII_TXID delay was enabled in the PHY driver
since 2013 (1ca6d1b1aef4628ff0fe458135ddb008d134ad8f)
To me it looks like that when AR8031 is used with am335x the 'rgmii tx
clock delay' needs to be enabled.
Sekhar, Roger: any insights, thoughts?
>
> Thanks
>
>
>>
>> On next-20190211:
>> [ 3.374601] net eth0: initializing cpsw version 1.12 (0)
>> [ 3.384484] Atheros 8031 ethernet 4a101000.mdio:00: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
>> [ 3.400041] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
>> [ 3.410813] mmc1: new SDIO card at address 0001
>> [ 3.439362] IP-Config: Complete:
>> [ 3.442649] device=eth0, hwaddr=bc:6a:29:7d:2c:a9, ipaddr=10.0.0.90, mask=255.255.255.0, gw=10.0.0.1
>> [ 3.452840] host=10.0.0.90, domain=, nis-domain=(none)
>> [ 3.458462] bootserver=10.0.0.30, rootserver=10.0.0.30, rootpath=
>> [ 3.466296] vwl1271: disabling
>> [ 3.470195] ALSA device list:
>> [ 3.473189] #0: AM335x-EVMSK
>>
>> After reverting this patch:
>> [ 3.374636] net eth0: initializing cpsw version 1.12 (0)
>> [ 3.384534] Atheros 8031 ethernet 4a101000.mdio:00: attached PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
>> [ 3.400125] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
>> [ 3.410866] mmc1: new SDIO card at address 0001
>> [ 3.439379] IP-Config: Complete:
>> [ 3.442666] device=eth0, hwaddr=bc:6a:29:7d:2c:a9, ipaddr=10.0.0.90, mask=255.255.255.0, gw=10.0.0.1
>> [ 3.452865] host=10.0.0.90, domain=, nis-domain=(none)
>> [ 3.458482] bootserver=10.0.0.30, rootserver=10.0.0.30, rootpath=
>> [ 3.466334] vwl1271: disabling
>> [ 3.470245] ALSA device list:
>> [ 3.473241] #0: AM335x-EVMSK
>> [ 3.501052] VFS: Mounted root (nfs filesystem) readonly on device 0:15.
>> [ 3.508694] devtmpfs: mounted
>> [ 3.514546] Freeing unused kernel memory: 1024K
>> [ 3.520567] Run /sbin/init as init process
>>
>> and the board boots to nfsroot fine.
>>
>>
>>> Signed-off-by: Vinod Koul <vkoul@kernel.org>
>>> ---
>>> drivers/net/phy/at803x.c | 22 ++++++++++++----------
>>> 1 file changed, 12 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
>>> index f9432d053a22..8ff12938ab47 100644
>>> --- a/drivers/net/phy/at803x.c
>>> +++ b/drivers/net/phy/at803x.c
>>> @@ -110,16 +110,16 @@ static int at803x_debug_reg_mask(struct phy_device *phydev, u16 reg,
>>> return phy_write(phydev, AT803X_DEBUG_DATA, val);
>>> }
>>>
>>> -static inline int at803x_enable_rx_delay(struct phy_device *phydev)
>>> +static inline int at803x_disable_rx_delay(struct phy_device *phydev)
>>> {
>>> - return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0, 0,
>>> - AT803X_DEBUG_RX_CLK_DLY_EN);
>>> + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0,
>>> + AT803X_DEBUG_RX_CLK_DLY_EN, 0);
>>> }
>>>
>>> -static inline int at803x_enable_tx_delay(struct phy_device *phydev)
>>> +static inline int at803x_disable_tx_delay(struct phy_device *phydev)
>>> {
>>> - return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_5, 0,
>>> - AT803X_DEBUG_TX_CLK_DLY_EN);
>>> + return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_5,
>>> + AT803X_DEBUG_TX_CLK_DLY_EN, 0);
>>> }
>>>
>>> /* save relevant PHY registers to private copy */
>>> @@ -256,15 +256,17 @@ static int at803x_config_init(struct phy_device *phydev)
>>> return ret;
>>>
>>> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
>>> - phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
>>> - ret = at803x_enable_rx_delay(phydev);
>>> + phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>>> + phydev->interface == PHY_INTERFACE_MODE_RGMII) {
>>> + ret = at803x_disable_rx_delay(phydev);
>>> if (ret < 0)
>>> return ret;
>>> }
>>>
>>> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
>>> - phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
>>> - ret = at803x_enable_tx_delay(phydev);
>>> + phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
>>> + phydev->interface == PHY_INTERFACE_MODE_RGMII) {
>>> + ret = at803x_disable_tx_delay(phydev);
>>> if (ret < 0)
>>> return ret;
>>> }
>>>
>>
>> - Péter
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH net] af_key: unconditionally clone on broadcast
From: Steffen Klassert @ 2019-02-12 12:16 UTC (permalink / raw)
To: David Miller; +Cc: stranche, eric.dumazet, netdev
In-Reply-To: <20190211.124554.1686370406673029680.davem@davemloft.net>
On Mon, Feb 11, 2019 at 12:45:54PM -0800, David Miller wrote:
> From: Sean Tranchetti <stranche@codeaurora.org>
> Date: Thu, 7 Feb 2019 13:33:21 -0700
>
> > Attempting to avoid cloning the skb when broadcasting by inflating
> > the refcount with sock_hold/sock_put while under RCU lock is dangerous
> > and violates RCU principles. It leads to subtle race conditions when
> > attempting to free the SKB, as we may reference sockets that have
> > already been freed by the stack.
> ...
> > Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
> > ---
> > Realized I never actually sent this patch out after testing the changes
> > Eric recommended. Whoops. Better late then never, I suppose...
>
> Steffen, I assume you will review and pick this up.
I was not on Cc and overlooked it at the list.
Thanks for the pointer!
Now applied to the ipsec tree, thanks Sean!
^ permalink raw reply
* Re: [v3,4/5] net: phy: at803x: Disable phy delay for RGMII mode
From: Vinod Koul @ 2019-02-12 12:17 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: David S Miller, Roger Quadros, netdev, linux-arm-msm,
Niklas Cassel, Bjorn Andersson, Andrew Lunn, Florian Fainelli,
Nori, Sekhar
In-Reply-To: <20190212113114.GZ4296@vkoul-mobl>
Hi again,
On 12-02-19, 17:01, Vinod Koul wrote:
> Hi Peter,
>
> On 12-02-19, 12:55, Peter Ujfalusi wrote:
> > Vinod,
> >
> > On 21/01/2019 11.13, Vinod Koul wrote:
> > > For RGMII mode, phy delay should be disabled. Add this case along
> > > with disable delay routines.
> >
> > In next-20190211 I need to revert this patch to get cpsw networking to
> > work on am335x-evmsk. The board uses AR8031_AL1A PHY, which is handled
> > by the phy/at803x.c
>
> I see that DTS specifies that you are using phy-mode = "rgmii-txid".
> RGMII mode implies that we should not have any delay in the
> phy, so this patch does the right thing.
>
> In the previous version of the patch I did propose to add a DT entry so
> that current users who are wrongly using this would not be impacted but
> the suggestion was to get them fixed.
>
> So in you case do you need rgmii-txd mode if so why should the delay be
> enabled for this? We can add a patch that enabled delay for your
> controller but that cant be rgmii mode.
Relooking at this again and seeing the mode definitions in
Documentation/devicetree/bindings/net/ethernet.txt,
I think I have got it wrong.. (thanks to Niklas for discussion)
So in case of rgmii mode delay should be disabled and in case of
rgmii-id/rxid/txid it should be enabled. I will send a patch to address
this shortly, please do test.
Thanks
--
~Vinod
^ permalink raw reply
* Re: [PATCH net-next 1/3] mlxsw: spectrum_switchdev: Remove getting PORT_BRIDGE_FLAGS
From: Ido Schimmel @ 2019-02-12 12:18 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <20190211211749.19847-2-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 01:17:47PM -0800, Florian Fainelli wrote:
> There is no code that will query the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
> attribute remove support for that.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v4 1/9] Documentation: networking: switchdev: Update port parent ID section
From: Ido Schimmel @ 2019-02-12 12:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <20190211191001.8623-2-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 11:09:53AM -0800, Florian Fainelli wrote:
> Update the section about switchdev drivers having to implement a
> switchdev_port_attr_get() function to return
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
> commit bccb30254a4a ("net: Get rid of
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID").
>
> Fixes: bccb30254a4a ("net: Get rid of SWITCHDEV_ATTR_ID_PORT_PARENT_ID")
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
^ permalink raw reply
* Re: [PATCH 1/1] bnx2x: Add FW 7.13.11.0.
From: Josh Boyer @ 2019-02-12 12:37 UTC (permalink / raw)
To: Rahul Verma
Cc: Kyle McMartin, netdev, linux-rdma, linux-scsi, Linux Firmware,
Ben Hutchings, ariel.elior
In-Reply-To: <20190208085704.26959-1-rahul.verma@cavium.com>
On Sat, Feb 9, 2019 at 11:06 PM Rahul Verma <rahul.verma@cavium.com> wrote:
>
> From: Rahul Verma <Rahul.Verma@cavium.com>
>
> This patch adds new FW for bnx2x, which adds the following:
> - TX VLAN filtering support.
> - Enable TPA only for packets without VLAN.
>
> It also addresses few critical issues,
> - Fairness algorithm misbehaviour when minimum bandwidth configured
> for all PFs.
> - Error recovery issue on TAPE devices.
> - FW not discarding FIP frames that are not designated to PF.
> - Kernel driver initialization failure after preboot driver.
> - VxLAN stops working after sending inner IP fragmented traffic.
> - Issues in the following FW flows:
> SD VLAN update, TX packet drop, packet padding flow, vlan add/remove.
>
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
> Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com>
> Signed-off-by: Rahul Verma <Rahul.Verma@cavium.com>
Applied and pushed out.
josh
^ permalink raw reply
* Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
From: Tariq Toukan @ 2019-02-12 12:39 UTC (permalink / raw)
To: Eric Dumazet, Ilias Apalodimas, Matthew Wilcox, brouer@redhat.com
Cc: David Miller, toke@redhat.com, netdev@vger.kernel.org,
mgorman@techsingularity.net, linux-mm@kvack.org
In-Reply-To: <64f7af75-e6df-7abc-c4ce-82e6ca51fafe@gmail.com>
On 2/11/2019 7:14 PM, Eric Dumazet wrote:
>
>
> On 02/11/2019 12:53 AM, Tariq Toukan wrote:
>>
>
>> Hi,
>>
>> It's great to use the struct page to store its dma mapping, but I am
>> worried about extensibility.
>> page_pool is evolving, and it would need several more per-page fields.
>> One of them would be pageref_bias, a planned optimization to reduce the
>> number of the costly atomic pageref operations (and replace existing
>> code in several drivers).
>>
>
> But the point about pageref_bias is to place it in a different cache line than "struct page"
>
> The major cost is having a cache line bouncing between producer and consumer.
>
pageref_bias is meant to be dirtied only by the page requester, i.e. the
NIC driver / page_pool.
All other components (basically, SKB release flow / put_page) should
continue working with the atomic page_refcnt, and not dirty the
pageref_bias.
However, what bothers me more is another issue.
The optimization doesn't cleanly combine with the new page_pool
direction for maintaining a queue for "available" pages, as the put_page
flow would need to read pageref_bias, asynchronously, and act accordingly.
The suggested hook in put_page (to catch the 2 -> 1 "biased refcnt"
transition) causes a problem to the traditional pageref_bias idea, as it
implies a new point in which the pageref_bias field is read
*asynchronously*. This would risk missing the this critical 2 -> 1
transition! Unless pageref_bias is atomic...
> pageref_bias means the producer only have to read the "struct page" and not dirty it
> in the case the page can be recycled.
>
>
>
>> I would replace this dma field with a pointer to an extensible struct,
>> that would contain the dma mapping (and other stuff in the near future).
>> This pointer fits perfectly with the existing unsigned long private;
>> they can share the memory, for both 32- and 64-bits systems.
>>
>> The only downside is one more pointer de-reference. This should be perf
>> tested.
>> However, when introducing the page refcnt bias optimization into
>> page_pool, I believe the perf gain would be guaranteed.
>
> Only in some cases perhaps (when the cache line can be dirtied without performance hit)
>
^ permalink raw reply
* Re: [PATCH net] dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exit
From: Andrew Lunn @ 2019-02-12 12:56 UTC (permalink / raw)
To: Heiner Kallweit
Cc: John David Anglin, Russell King, Vivien Didelot, Florian Fainelli,
netdev
In-Reply-To: <13c1e6d5-c287-0091-3b24-1978f9a18e7e@gmail.com>
On Tue, Feb 12, 2019 at 07:51:05AM +0100, Heiner Kallweit wrote:
> On 12.02.2019 04:58, Andrew Lunn wrote:
> >>> Hi David
> >>>
> >>> I just tested this on one of my boards. It loops endlessly:
> >>>
> >>> [ 47.173396] mv88e6xxx_g1_irq_thread_work: c881 a8 80
> >>> [ 47.182108] mv88e6xxx_g1_irq_thread_work: c881 a8 80
> >>> [ 47.190820] mv88e6xxx_g1_irq_thread_work: c881 a8 80
> >>> [ 47.199535] mv88e6xxx_g1_irq_thread_work: c881 a8 80
> >>> [ 47.208254] mv88e6xxx_g1_irq_thread_work: c881 a8 80
> >>>
> >>> These are reg, ctl1, reg & ctl1.
> >>>
> >>> So there is an unhandled device interrupt.
> >
> > Hi Heiner
> >
> > Your patch Fixes: 2b3e88ea6528 ("net: phy: improve phy state
> > checking") is causing me problems with interrupts for the Marvell
> > switches.
> >
> Hi Andrew,
>
> what kernel version is it?
It is a little bit old, 5.0-rc1 net-next. I should rebase and
retest. I'm testing on a ZII board which is not fully in mainline So i
need some patches.
> And the PHY driver in use is "Marvell 88E6390" ?
Yes, the marvell 1G driver.
Andrew
^ permalink raw reply
* [PATCH net] sfc: initialise found bitmap in efx_ef10_mtd_probe
From: Bert Kenward @ 2019-02-12 13:10 UTC (permalink / raw)
To: Dave Miller; +Cc: linux-net-drivers, netdev
The bitmap of found partitions in efx_ef10_mtd_probe was not
initialised, causing partitions to be suppressed based off whatever
value was in the bitmap at the start.
Fixes: 3366463513f5 ("sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe")
Signed-off-by: Bert Kenward <bkenward@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 2f2bda68d861..c08034154a9a 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -6115,7 +6115,7 @@ static int efx_ef10_mtd_probe_partition(struct efx_nic *efx,
static int efx_ef10_mtd_probe(struct efx_nic *efx)
{
MCDI_DECLARE_BUF(outbuf, MC_CMD_NVRAM_PARTITIONS_OUT_LENMAX);
- DECLARE_BITMAP(found, EF10_NVRAM_PARTITION_COUNT);
+ DECLARE_BITMAP(found, EF10_NVRAM_PARTITION_COUNT) = { 0 };
struct efx_mcdi_mtd_partition *parts;
size_t outlen, n_parts_total, i, n_parts;
unsigned int type;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V1 net 2/2] net: ena: update driver version from 2.0.2 to 2.0.3
From: Andrew Lunn @ 2019-02-12 13:11 UTC (permalink / raw)
To: Kiyanovski, Arthur
Cc: Moritz Fischer, David S. Miller, netdev@vger.kernel.org,
Woodhouse, David, Machulsky, Zorik, Matushevsky, Alexander,
Bshara, Saeed, Wilson, Matt, Liguori, Anthony, Bshara, Nafea,
Tzalik, Guy, Belgazal, Netanel, Saidi, Ali
In-Reply-To: <55dcaee1242649e2a4d8984f120844ae@EX13D22EUA004.ant.amazon.com>
On Tue, Feb 12, 2019 at 11:42:31AM +0000, Kiyanovski, Arthur wrote:
> Hi Moritz,
>
> > -----Original Message-----
> > From: Moritz Fischer <moritz.fischer@ettus.com>
> > Subject: Re: [PATCH V1 net 2/2] net: ena: update driver version from 2.0.2 to
> > 2.0.3
> >
> > Hi Arthur,
> >
> > On Mon, Feb 11, 2019 at 9:19 AM <akiyano@amazon.com> wrote:
> > >
> > > From: Arthur Kiyanovski <akiyano@amazon.com>
> > >
> > > Update driver version due to bug fix.
> >
> > Wouldn't you want to do this atomically with the actual fix in one commit?
> >
> > Thanks,
> > Moritz
>
> Thanks for the feedback.
> I don't want to add the version to the fix.
> Version 2.0.3 includes all of its content that came before this fix, including features.
> Fixes are cherry-picked to older driver versions automatically using the "Fixes:" directive.
> If I add the version change to the fix, older driver versions that get this fix will become version 2.0.3, which is incorrect feature-wise.
Hi Arthur
I think this points out how useless the version string it, and why
many drivers don't use it.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v4 0/9] net: Remove switchdev_ops
From: Ido Schimmel @ 2019-02-12 13:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <20190211191001.8623-1-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 11:09:52AM -0800, Florian Fainelli wrote:
> Hi all,
>
> This patch series finishes by the removal of switchdev_ops. To get there
> we convert the existing switchdev_port_attr_{set,get} switchdev_ops to
> use a blocking notifier, thus making it consistent with how the objects
> are pushed to the switchdev enabled devices.
>
> Please review and let me know what you think!
>
> David, I would like to get Ido's feedback on this to make sure I did not
> miss something, thank you!
Hi Florian,
Why do you still keep switchdev_port_attr_get()? I believe we can remove
it and simplify things.
After your recent patchset to remove 'PORT_BRIDGE_FLAGS', the only
remaining user of get() is 'PORT_BRIDGE_FLAGS_SUPPORT'. It can be
converted to a blocking set() with 'PORT_PRE_BRIDGE_FLAGS' (or a similar
name).
I would like to make sure we're in sync with regards to future changes.
After this patchset to get rid of switchdev_ops we can continue to
completely removing switchdev (I believe Jiri approves). The
prepare-commit model is not really needed and the two switchdev
notification chains can be split into bridge and vxlan specific chains.
Notifications sent in an atomic context can be handled by drivers
directly in this context. Similar to how FDB/route/neighbour are
handled. It will really simplify things. No need for the defer flag
anymore and tricks like 'PORT_BRIDGE_FLAGS_SUPPORT' and
'PORT_PRE_BRIDGE_FLAGS'. In the atomic context the driver can veto the
requested bridge flags, but program the device from a blocking context
(using a workqueue).
^ permalink raw reply
* Re: [v3,4/5] net: phy: at803x: Disable phy delay for RGMII mode
From: Marc Gonzalez @ 2019-02-12 13:34 UTC (permalink / raw)
To: Peter Ujfalusi, Vinod Koul, Roger Quadros, Florian Fainelli
Cc: David S Miller, netdev, MSM, Niklas Cassel, Bjorn Andersson,
Andrew Lunn, Nori Sekhar
In-Reply-To: <147151c4-d162-4ebe-189a-564492d84d18@ti.com>
On 12/02/2019 11:55, Peter Ujfalusi wrote:
> On 21/01/2019 11.13, Vinod Koul wrote:
>
>> For RGMII mode, phy delay should be disabled. Add this case along
>> with disable delay routines.
>
> In next-20190211 I need to revert this patch to get cpsw networking
> to work on am335x-evmsk. The board uses AR8031_AL1A PHY, which is
> handled by the phy/at803x.c
I'm having flashbacks:
[PATCH 1/2] net: phy: at803x: Fix RGMII RX and TX clock delays setup
https://www.spinics.net/lists/netdev/msg445053.html
Quirks of the Atheros 8035 PHY
https://www.spinics.net/lists/netdev/msg444527.html
See also
http://patchwork.ozlabs.org/project/netdev/list/?submitter=67482&state=*
Regards.
^ permalink raw reply
* Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
From: Jesper Dangaard Brouer @ 2019-02-12 13:49 UTC (permalink / raw)
To: Tariq Toukan
Cc: Eric Dumazet, Ilias Apalodimas, Matthew Wilcox, David Miller,
toke@redhat.com, netdev@vger.kernel.org,
mgorman@techsingularity.net, linux-mm@kvack.org, brouer
In-Reply-To: <27e97aac-f25b-d46c-3e70-7d0d44f784b5@mellanox.com>
On Tue, 12 Feb 2019 12:39:59 +0000
Tariq Toukan <tariqt@mellanox.com> wrote:
> On 2/11/2019 7:14 PM, Eric Dumazet wrote:
> >
> > On 02/11/2019 12:53 AM, Tariq Toukan wrote:
> >>
> >
> >> Hi,
> >>
> >> It's great to use the struct page to store its dma mapping, but I am
> >> worried about extensibility.
> >> page_pool is evolving, and it would need several more per-page fields.
> >> One of them would be pageref_bias, a planned optimization to reduce the
> >> number of the costly atomic pageref operations (and replace existing
> >> code in several drivers).
> >>
> >
> > But the point about pageref_bias is to place it in a different
> > cache line than "struct page"
Yes, exactly.
> > The major cost is having a cache line bouncing between producer and
> > consumer.
>
> pageref_bias is meant to be dirtied only by the page requester, i.e. the
> NIC driver / page_pool.
> All other components (basically, SKB release flow / put_page) should
> continue working with the atomic page_refcnt, and not dirty the
> pageref_bias.
>
> However, what bothers me more is another issue.
> The optimization doesn't cleanly combine with the new page_pool
> direction for maintaining a queue for "available" pages, as the put_page
> flow would need to read pageref_bias, asynchronously, and act accordingly.
>
> The suggested hook in put_page (to catch the 2 -> 1 "biased refcnt"
> transition) causes a problem to the traditional pageref_bias idea, as it
> implies a new point in which the pageref_bias field is read
> *asynchronously*. This would risk missing the this critical 2 -> 1
> transition! Unless pageref_bias is atomic...
I want to stop you here...
It seems to me that you are trying to shoehorn in a refcount
optimization into page_pool. The page_pool is optimized for the XDP
case of one-frame-per-page, where we can avoid changing the refcount,
and tradeoff memory usage for speed. It is compatible with the elevated
refcount usage, but that is not the optimization target.
If the case you are optimizing for is "packing" more frames in a page,
then the page_pool might be the wrong choice. To me it would make more
sense to create another enum xdp_mem_type, that generalize the
pageref_bias tricks also used by some drivers.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v4 2/9] switchdev: Add SWITCHDEV_PORT_ATTR_SET, SWITCHDEV_PORT_ATTR_GET
From: Ido Schimmel @ 2019-02-12 13:55 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <20190211191001.8623-3-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 11:09:54AM -0800, Florian Fainelli wrote:
> In preparation for allowing switchdev enabled drivers to veto specific
> attribute settings from within the context of the caller, introduce a
> new switchdev notifier type for port attributes.
>
> Suggested-by: Ido Schimmel <idosch@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> include/net/switchdev.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
> index 5e87b54c5dc5..b8becabbef38 100644
> --- a/include/net/switchdev.h
> +++ b/include/net/switchdev.h
> @@ -143,6 +143,9 @@ enum switchdev_notifier_type {
> SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE,
> SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE,
> SWITCHDEV_VXLAN_FDB_OFFLOADED,
> +
> + SWITCHDEV_PORT_ATTR_SET, /* Blocking. */
> + SWITCHDEV_PORT_ATTR_GET, /* Blocking. */
As I wrote in the cover letter, I don't believe GET is needed.
> };
>
> struct switchdev_notifier_info {
> @@ -165,6 +168,13 @@ struct switchdev_notifier_port_obj_info {
> bool handled;
> };
>
> +struct switchdev_notifier_port_attr_info {
> + struct switchdev_notifier_info info; /* must be first */
> + struct switchdev_attr *attr;
> + struct switchdev_trans *trans;
> + bool handled;
> +};
> +
> static inline struct net_device *
> switchdev_notifier_info_to_dev(const struct switchdev_notifier_info *info)
> {
> --
> 2.17.1
>
^ permalink raw reply
* [REGRESSION 4.20] mvneta - DMA-API: device driver tries to sync DMA memory it has not allocated
From: Russell King - ARM Linux admin @ 2019-02-12 13:59 UTC (permalink / raw)
To: Thomas Petazzoni, netdev
Hi,
Booting 4.20 on SolidRun Clearfog reliably provokes the following
warning - this is with mvneta built in, but DSA as modules:
WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230 check_sync+0x514/0x5bc
mvneta f1070000.ethernet: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000002dd7dc00] [size=240 bytes]
Modules linked in: ahci mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021 spi_orion evbug sfp mdio_i2c ip_tables x_tables
CPU: 0 PID: 555 Comm: bridge-network- Not tainted 4.20.0+ #291
Hardware name: Marvell Armada 380/385 (Device Tree)
[<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14)
[<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4)
[<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124)
[<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48)
[<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>] (check_sync+0x514/0x5bc)
[<c00b0370>] (check_sync) from [<c00b04f8>] (debug_dma_sync_single_range_for_cpu+0x6c/0x74)
[<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>] (mvneta_poll+0x298/0xf58)
[<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424)
[<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540)
[<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144)
[<c00386e0>] (irq_exit) from [<c009b5e0>] (__handle_domain_irq+0x58/0xb0)
[<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>] (gic_handle_irq+0x48/0x98)
[<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98)
...
This appears to be from:
if (rx_bytes <= rx_copybreak) {
/* better copy a small frame and not unmap the DMA region */
skb = netdev_alloc_skb_ip_align(dev, rx_bytes);
if (unlikely(!skb))
goto err_drop_frame_ret_pool;
dma_sync_single_range_for_cpu(dev->dev.parent,
rx_desc->buf_phys_addr,
MVNETA_MH_SIZE + NET_SKB_PAD,
rx_bytes,
DMA_FROM_DEVICE);
which suggests that rx_desc->buf_phys_addr is not something that should
be passed to dma_sync_single_range_for_cpu(). I've not been able to
track down why that is, nor which interface is provoking that.
As I don't have the details of how the buffer management hardware works
on Armada 388, I'm unable to debug this myself.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next v4 0/9] net: Remove switchdev_ops
From: Jiri Pirko @ 2019-02-12 13:53 UTC (permalink / raw)
To: Ido Schimmel
Cc: Florian Fainelli, netdev@vger.kernel.org, David S. Miller,
open list, open list:STAGING SUBSYSTEM,
moderated list:ETHERNET BRIDGE, Jiri Pirko, andrew@lunn.ch,
vivien.didelot@gmail.com
In-Reply-To: <20190212131443.GA13819@splinter>
Tue, Feb 12, 2019 at 02:14:47PM CET, idosch@mellanox.com wrote:
>On Mon, Feb 11, 2019 at 11:09:52AM -0800, Florian Fainelli wrote:
>> Hi all,
>>
>> This patch series finishes by the removal of switchdev_ops. To get there
>> we convert the existing switchdev_port_attr_{set,get} switchdev_ops to
>> use a blocking notifier, thus making it consistent with how the objects
>> are pushed to the switchdev enabled devices.
>>
>> Please review and let me know what you think!
>>
>> David, I would like to get Ido's feedback on this to make sure I did not
>> miss something, thank you!
>
>Hi Florian,
>
>Why do you still keep switchdev_port_attr_get()? I believe we can remove
>it and simplify things.
>
>After your recent patchset to remove 'PORT_BRIDGE_FLAGS', the only
>remaining user of get() is 'PORT_BRIDGE_FLAGS_SUPPORT'. It can be
>converted to a blocking set() with 'PORT_PRE_BRIDGE_FLAGS' (or a similar
>name).
Let's do that in a follow-up.
>
>I would like to make sure we're in sync with regards to future changes.
>After this patchset to get rid of switchdev_ops we can continue to
>completely removing switchdev (I believe Jiri approves). The
Yes.
>prepare-commit model is not really needed and the two switchdev
>notification chains can be split into bridge and vxlan specific chains.
>
>Notifications sent in an atomic context can be handled by drivers
>directly in this context. Similar to how FDB/route/neighbour are
>handled. It will really simplify things. No need for the defer flag
>anymore and tricks like 'PORT_BRIDGE_FLAGS_SUPPORT' and
>'PORT_PRE_BRIDGE_FLAGS'. In the atomic context the driver can veto the
>requested bridge flags, but program the device from a blocking context
>(using a workqueue).
Sounds good to me.
^ permalink raw reply
* Re: [PATCH net-next v4 4/9] mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_GET/SET
From: Ido Schimmel @ 2019-02-12 14:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <20190211191001.8623-5-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 11:09:56AM -0800, Florian Fainelli wrote:
> Following patches will change the way we communicate getting or setting
> a port's attribute and use a blocking notifier to perform those tasks.
>
> Prepare mlxsw to support receiving notifier events targeting
> SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
> mlxsw_sp_port_attr_{set,get} calls.
>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../mellanox/mlxsw/spectrum_switchdev.c | 23 +++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> index 95e37de3e48f..88d4994309a7 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> @@ -3443,6 +3443,26 @@ mlxsw_sp_switchdev_handle_vxlan_obj_del(struct net_device *vxlan_dev,
> }
> }
>
> +static int
> +mlxsw_sp_switchdev_port_attr_event(unsigned long event, struct net_device *dev,
> + struct switchdev_notifier_port_attr_info *port_attr_info)
> +{
> + int err = -EOPNOTSUPP;
> +
> + switch (event) {
> + case SWITCHDEV_PORT_ATTR_SET:
> + err = mlxsw_sp_port_attr_set(dev, port_attr_info->attr,
> + port_attr_info->trans);
It is not that simple. These functions expect 'dev' to be an mlxsw
netdev since the operation is propagated using the device chain. This is
not the case with notification chains. 'dev' can be any netdev in the
system and then this line in mlxsw_sp_port_attr_set() is not correct:
struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(dev);
You can check commit f30f0601eb93 ("switchdev: Add helpers to aid
traversal through lower devices") for reference.
> + break;
> + case SWITCHDEV_PORT_ATTR_GET:
> + err = mlxsw_sp_port_attr_get(dev, port_attr_info->attr);
> + break;
> + }
> +
> + port_attr_info->handled = true;
I believe this should only be set in case the driver actually handled
the notification. That's how it works for objects.
I suggest looking at the series merged in commit 06d212900ea9 ("Merge
branch 'switchdev-blocking-notifiers'").
> + return notifier_from_errno(err);
> +}
> +
> static int mlxsw_sp_switchdev_blocking_event(struct notifier_block *unused,
> unsigned long event, void *ptr)
> {
> @@ -3466,6 +3486,9 @@ static int mlxsw_sp_switchdev_blocking_event(struct notifier_block *unused,
> mlxsw_sp_port_dev_check,
> mlxsw_sp_port_obj_del);
> return notifier_from_errno(err);
> + case SWITCHDEV_PORT_ATTR_SET: /* fall through */
> + case SWITCHDEV_PORT_ATTR_GET:
> + return mlxsw_sp_switchdev_port_attr_event(event, dev, ptr);
> }
>
> return NOTIFY_DONE;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next v4 9/9] net: Remove switchdev_ops
From: Ido Schimmel @ 2019-02-12 14:10 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, David S. Miller, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <20190211191001.8623-10-f.fainelli@gmail.com>
On Mon, Feb 11, 2019 at 11:10:01AM -0800, Florian Fainelli wrote:
> Now that we have converted all possible callers to using a switchdev
> notifier for attributes we do not have a need for implementing
> switchdev_ops anymore, and this can be removed from all drivers the
> net_device structure.
>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 12 ------------
> drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 --
> .../mellanox/mlxsw/spectrum_switchdev.c | 13 -------------
> drivers/net/ethernet/mscc/ocelot.c | 5 -----
> drivers/net/ethernet/rocker/rocker_main.c | 6 ------
> drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 6 ------
> include/linux/netdevice.h | 3 ---
> include/net/switchdev.h | 18 ------------------
> net/dsa/slave.c | 6 ------
There's also this line that can be removed from the 8021q driver:
net/8021q/vlan_dev.c:34:#include <net/switchdev.h>
^ permalink raw reply
* Re: [PATCH] ipv6: fix icmp6_send() route lookup
From: Alin Năstac @ 2019-02-12 14:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20190211.123818.1763509059512954986.davem@davemloft.net>
On Mon, Feb 11, 2019 at 9:38 PM David Miller <davem@davemloft.net> wrote:
>
> From: Alin Nastac <alin.nastac@gmail.com>
> Date: Thu, 7 Feb 2019 16:05:31 +0100
>
> > Original packet destination address must be used as saddr for the
> > route lookup performed by icmp6_send() even when this address is
> > not local. This fixes the IPv6 router ability to send back
> > destination unreachable ICMPv6 errors for forwarded packets when
> > the route toward the saddr of the original packet is source
> > filtered (e.g. a default route with a "from PD" attribute, where
> > PD is the delegated prefix).
> >
> > Signed-off-by: Alin Nastac <alin.nastac@gmail.com>
>
> Yes, but however this will change behavior for a lot of situations
> not just the one you are interested in.
>
> The base ipv6_chk_addr() test has been there for more than a decade
> and I'm not comfortable with changing this logic until I see you
> write up a full audit of all of the use cases of icmp6_send() and
> how they are impacted by your changes.
Please consider these:
- saddr variable is used only to perform route lookup towards the skb
originator and is explicitly reset to NULL when skb is multicast (see
the if statement below the change).
- In order for icmp6_send() to perform its duty, this route lookup
must succeed.
- As long as your IPv6 routes don't use source filtering or
source-based routing, this change will have absolutely no effect on
the kernel behavior because route lookup will succeed regardless of
the fl6.saddr value.
I don't contest the usefulness of ipv6_chk_addr(), it clearly has its
purpose. However when it comes to generating ICMPv6 errors, both
routers and hosts are entitled to generate them (see RFC 4443), hence
this test shouldn't be called here.
^ permalink raw reply
* [PATCH] net: phy: at803x: disable delay only for RGMII mode
From: Vinod Koul @ 2019-02-12 14:19 UTC (permalink / raw)
To: David S Miller
Cc: linux-arm-msm, Bjorn Andersson, Vinod Koul, netdev, Niklas Cassel,
Andrew Lunn, Florian Fainelli, Nori, Sekhar, Peter Ujfalusi,
Marc Gonzalez
Per "Documentation/devicetree/bindings/net/ethernet.txt" RGMII mode
should not have delay in PHY whereas RGMII_ID and RGMII_RXID/RGMII_TXID
can have delay in phy.
So disable the delay only for RGMII mode and disable for other modes
Fixes: cd28d1d6e52e: ("net: phy: at803x: Disable phy delay for RGMII mode")
Reported-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/net/phy/at803x.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 8ff12938ab47..7b54b54e3316 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -110,6 +110,18 @@ static int at803x_debug_reg_mask(struct phy_device *phydev, u16 reg,
return phy_write(phydev, AT803X_DEBUG_DATA, val);
}
+static inline int at803x_enable_rx_delay(struct phy_device *phydev)
+{
+ return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0, 0,
+ AT803X_DEBUG_RX_CLK_DLY_EN);
+}
+
+static inline int at803x_enable_tx_delay(struct phy_device *phydev)
+{
+ return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_5, 0,
+ AT803X_DEBUG_TX_CLK_DLY_EN);
+}
+
static inline int at803x_disable_rx_delay(struct phy_device *phydev)
{
return at803x_debug_reg_mask(phydev, AT803X_DEBUG_REG_0,
@@ -255,18 +267,25 @@ static int at803x_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
- phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
- phydev->interface == PHY_INTERFACE_MODE_RGMII) {
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII) {
ret = at803x_disable_rx_delay(phydev);
if (ret < 0)
return ret;
+ ret = at803x_disable_tx_delay(phydev);
+ if (ret < 0)
+ return ret;
+ };
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
+ ret = at803x_enable_rx_delay(phydev);
+ if (ret < 0)
+ return ret;
}
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
- phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
- phydev->interface == PHY_INTERFACE_MODE_RGMII) {
- ret = at803x_disable_tx_delay(phydev);
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+ ret = at803x_enable_tx_delay(phydev);
if (ret < 0)
return ret;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v2 06/16] net: bridge: Stop calling switchdev_port_attr_get()
From: Ido Schimmel @ 2019-02-12 14:20 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org, bridge@lists.linux-foundation.org,
Jiri Pirko, andrew@lunn.ch, vivien.didelot@gmail.com
In-Reply-To: <73a10fbb-7689-74a7-3fbf-076f8dc9d76f@gmail.com>
On Sun, Feb 10, 2019 at 11:34:14AM -0800, Florian Fainelli wrote:
> Le 2/10/19 à 11:05 AM, Ido Schimmel a écrit :
> > On Sun, Feb 10, 2019 at 09:50:55AM -0800, Florian Fainelli wrote:
> >> Now that all switchdev drivers have been converted to checking the
> >> bridge port flags during the prepare phase of the
> >> switchdev_port_attr_set(), we can move straight to trying to set the
> >> desired flag through SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS.
> >>
> >> Acked-by: Jiri Pirko <jiri@mellanox.com>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> ---
> >> net/bridge/br_switchdev.c | 20 +++-----------------
> >> 1 file changed, 3 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
> >> index db9e8ab96d48..939f300522c5 100644
> >> --- a/net/bridge/br_switchdev.c
> >> +++ b/net/bridge/br_switchdev.c
> >> @@ -64,29 +64,15 @@ int br_switchdev_set_port_flag(struct net_bridge_port *p,
> >> {
> >> struct switchdev_attr attr = {
> >> .orig_dev = p->dev,
> >> - .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
> >> + .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS,
> >> + .flags = SWITCHDEV_F_DEFER,
> >
> > How does this work? You defer the operation, so the driver cannot veto
> > it. This is why we have SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT
> > which is not deferred.
>
> I missed that indeed, how would you feel about splitting the attribute
> setting into different phases:
>
> - checking that the attribute setting is supported (caller context, so
> possibly atomic)
> - allocating and committing resources (deferred context)
Yes, this is what I suggested in the other thread. Lets continue
discussion there.
We are doing that when processing route notifications (for example), but
we are missing a check in caller context that resources can actually be
allocated. That's part of a bigger task to track resources in mlxsw.
>
> For pretty much any DSA driver, we will have to be in sleepable context
> anyway because of MDIO, SPI, I2C, whatever transport layer.
>
> Not sure how to best approach this now...
> --
> Florian
^ permalink raw reply
* [net-next PATCH V2 0/3] Fix page_pool API and dma address storage
From: Jesper Dangaard Brouer @ 2019-02-12 14:48 UTC (permalink / raw)
To: netdev, linux-mm
Cc: Toke Høiland-Jørgensen, Ilias Apalodimas, willy,
Saeed Mahameed, Alexander Duyck, Jesper Dangaard Brouer,
Andrew Morton, mgorman, David S. Miller, Tariq Toukan
As pointed out by David Miller in [1] the current page_pool implementation
stores dma_addr_t in page->private. This won't work on 32-bit platforms with
64-bit DMA addresses since the page->private is an unsigned long and the
dma_addr_t a u64.
Since no driver is yet using the DMA mapping capabilities of the API let's
fix this by storing the information in 'struct page' and use that to store
and retrieve DMA addresses from network drivers.
As long as the addresses returned from dma_map_page() are aligned the first
bit, used by the compound pages code should not be set.
Ilias tested this on Espressobin driver mvneta, for which we have patches
for using the DMA API of page_pool.
[1]: https://lore.kernel.org/netdev/20181207.230655.1261252486319967024.davem@davemloft.net/
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
Ilias Apalodimas (1):
net: page_pool: don't use page->private to store dma_addr_t
Jesper Dangaard Brouer (2):
mm: add dma_addr_t to struct page
page_pool: use DMA_ATTR_SKIP_CPU_SYNC for DMA mappings
include/linux/mm_types.h | 7 +++++++
net/core/page_pool.c | 22 ++++++++++++++--------
2 files changed, 21 insertions(+), 8 deletions(-)
--
^ 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