* [BACKPORT 4.14.y v2 5/6] ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
From: Baolin Wang @ 2019-09-05 3:10 UTC (permalink / raw)
To: stable, paulus
Cc: ebiggers, linux-ppp, netdev, arnd, baolin.wang, orsonzhai,
vincent.guittot, linux-kernel
In-Reply-To: <cover.1567649728.git.baolin.wang@linaro.org>
From: Eric Biggers <ebiggers@google.com>
[Upstream commit 25a09ce79639a8775244808c17282c491cff89cf]
Commit 0e5a610b5ca5 ("ppp: mppe: switch to RC4 library interface"),
which was merged through the crypto tree for v5.3, changed ppp_mppe.c to
use the new arc4_crypt() library function rather than access RC4 through
the dynamic crypto_skcipher API.
Meanwhile commit aad1dcc4f011 ("ppp: mppe: Add softdep to arc4") was
merged through the net tree and added a module soft-dependency on "arc4".
The latter commit no longer makes sense because the code now uses the
"libarc4" module rather than "arc4", and also due to the direct use of
arc4_crypt(), no module soft-dependency is required.
So revert the latter commit.
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/net/ppp/ppp_mppe.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ppp/ppp_mppe.c b/drivers/net/ppp/ppp_mppe.c
index d9eda7c..6c7fd98 100644
--- a/drivers/net/ppp/ppp_mppe.c
+++ b/drivers/net/ppp/ppp_mppe.c
@@ -63,7 +63,6 @@
MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point Encryption support");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE));
-MODULE_SOFTDEP("pre: arc4");
MODULE_VERSION("1.0.2");
static unsigned int
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 2/3] bpf: implement CAP_BPF
From: Alexei Starovoitov @ 2019-09-05 3:15 UTC (permalink / raw)
To: Song Liu
Cc: Alexei Starovoitov, David S . Miller, Daniel Borkmann,
Peter Zijlstra, Andy Lutomirski, Networking, bpf, Kernel Team,
linux-api@vger.kernel.org
In-Reply-To: <E342EC2A-24F6-4581-BFDC-119B5E02B560@fb.com>
On Thu, Sep 05, 2019 at 02:51:51AM +0000, Song Liu wrote:
>
>
> > On Sep 4, 2019, at 6:32 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Sep 05, 2019 at 12:34:36AM +0000, Song Liu wrote:
> >>
> >>
> >>> On Sep 4, 2019, at 11:43 AM, Alexei Starovoitov <ast@kernel.org> wrote:
> >>>
> >>> Implement permissions as stated in uapi/linux/capability.h
> >>>
> >>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> >>>
> >>
> >> [...]
> >>
> >>> @@ -1648,11 +1648,11 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr)
> >>> is_gpl = license_is_gpl_compatible(license);
> >>>
> >>> if (attr->insn_cnt == 0 ||
> >>> - attr->insn_cnt > (capable(CAP_SYS_ADMIN) ? BPF_COMPLEXITY_LIMIT_INSNS : BPF_MAXINSNS))
> >>> + attr->insn_cnt > (capable_bpf() ? BPF_COMPLEXITY_LIMIT_INSNS : BPF_MAXINSNS))
> >>> return -E2BIG;
> >>> if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
> >>> type != BPF_PROG_TYPE_CGROUP_SKB &&
> >>> - !capable(CAP_SYS_ADMIN))
> >>> + !capable_bpf())
> >>> return -EPERM;
> >>
> >> Do we allow load BPF_PROG_TYPE_SOCKET_FILTER and BPF_PROG_TYPE_CGROUP_SKB
> >> without CAP_BPF? If so, maybe highlight in the header?
> >
> > of course. there is no change in behavior.
> > 'highlight in the header'?
> > you mean in commit log?
> > I think it's a bit weird to describe things in commit that patch
> > is _not_ changing vs things that patch does actually change.
> > This type of comment would be great in a doc though.
> > The doc will be coming separately in the follow up assuming
> > the whole thing lands. I'll remember to note that bit.
>
> I meant capability.h:
>
> + * CAP_BPF allows the following BPF operations:
> + * - Loading all types of BPF programs
>
> But CAP_BPF is not required to load all types of programs.
yes, but above statement is still correct, right?
And right below it says:
* CAP_BPF allows the following BPF operations:
* - Loading all types of BPF programs
* - Creating all types of BPF maps except:
* - stackmap that needs CAP_TRACING
* - devmap that needs CAP_NET_ADMIN
* - cpumap that needs CAP_SYS_ADMIN
which is also correct, but CAP_BPF is not required
for array, hash, prog_array, percpu, map-in-map ...
except their lru variants...
and except if they contain bpf_spin_lock...
and if they need BTF it currently can be loaded with cap_sys_admin only...
If we say something about socket_filter, cg_skb progs in capability.h
we should clarify maps as well, but then it will become too big for .h
The comments in capability.h already look too long to me.
All that info and a lot more belongs in the doc.
> On a second thought, I am not sure whether we will keep capability.h
> up to date with all features. So this is probably OK.
It's clearly not for cap_sys_admin.
cap_net_admin is not up to date either.
These two are kitchen sink of anything root-like and networking-root like.
Developers didn't bother updating that .h
With CAP_BPF we can enforce through patch acceptance policy that
major new things (like big verifier features) should have a line
in capability.h
Though .h is not a replacement for proper doc which will come as follow up.
Unlike bpf.h that serves as a template for auto-generating man pages
capability.h is not such thing. I won't change often either.
So normal doc is a better way to document all details.
^ permalink raw reply
* Re: [PATCHv2 net-next] ipmr: remove cache_resolve_queue_len
From: Hangbin Liu @ 2019-09-05 3:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Phil Karn, Sukumar Gopalakrishnan, David S . Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI
In-Reply-To: <aa759647-953e-23b5-32e2-b0b7373e07e4@gmail.com>
On Wed, Sep 04, 2019 at 09:50:15AM +0200, Eric Dumazet wrote:
> > +static int queue_count(struct mr_table *mrt)
> > +{
> > + struct list_head *pos;
> > + int count = 0;
> > +
> > + spin_lock_bh(&mfc_unres_lock);
> > + list_for_each(pos, &mrt->mfc_unres_queue)
> > + count++;
> > + spin_unlock_bh(&mfc_unres_lock);
> > +
> > + return count;
> > +}
>
> I guess that even if we remove a limit on the number of items, we probably should
> keep the atomic counter (no code churn, patch much easier to review...)
>
> Your patch could be a one liner really [1]
>
> Eventually replacing this linear list with an RB-tree, so that we can be on the safe side.
>
> [1]
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index c07bc82cbbe96d53d05c1665b2f03faa055f1084..313470f6bb148326b4afbc00d265b6a1e40d93bd 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -1134,8 +1134,8 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
>
> if (!found) {
> /* Create a new entry if allowable */
> - if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
> - (c = ipmr_cache_alloc_unres()) == NULL) {
> + c = ipmr_cache_alloc_unres();
> + if (!c) {
> spin_unlock_bh(&mfc_unres_lock);
>
> kfree_skb(skb);
hmm, that looks more clear and easy to review..
Hi David, Alexey,
What do you think? If you also agree, I could post a new version patch.
Thanks
Hangbin
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the arm-soc tree
From: Stephen Rothwell @ 2019-09-05 3:42 UTC (permalink / raw)
To: David Miller, Networking, Olof Johansson, Arnd Bergmann, ARM
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Stephen Boyd
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/nuvoton/w90p910_ether.c
between commit:
00d2fbf73d55 ("net: remove w90p910-ether driver")
from the arm-soc tree and commit:
d1a55841ab24 ("net: Remove dev_err() usage after platform_get_irq()")
from the net-next tree.
I fixed it up (I removed the file) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] cfg80211: Do not compare with boolean in nl80211_common_reg_change_event
From: zhong jiang @ 2019-09-05 4:25 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, zhongjiang, netdev, linux-kernel
With the help of boolinit.cocci, we use !nl80211_reg_change_event_fill
instead of (nl80211_reg_change_event_fill == false). Meanwhile, Clean
up the code.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/wireless/nl80211.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 3e30e18..0c7fa60 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -14997,12 +14997,10 @@ void nl80211_common_reg_change_event(enum nl80211_commands cmd_id,
return;
hdr = nl80211hdr_put(msg, 0, 0, 0, cmd_id);
- if (!hdr) {
- nlmsg_free(msg);
- return;
- }
+ if (!hdr)
+ goto nla_put_failure;
- if (nl80211_reg_change_event_fill(msg, request) == false)
+ if (!nl80211_reg_change_event_fill(msg, request))
goto nla_put_failure;
genlmsg_end(msg, hdr);
--
1.7.12.4
^ permalink raw reply related
* Zdravstvujte! Vas interesujut klientskie bazy dannyh?
From: netdev @ 2019-09-04 21:56 UTC (permalink / raw)
To: netdev
Zdravstvujte! Vas interesujut klientskie bazy dannyh?
^ permalink raw reply
* Re: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self wakeup
From: Sean Nyekjaer @ 2019-09-05 5:57 UTC (permalink / raw)
To: Joakim Zhang, mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Martin Hundebøll
In-Reply-To: <DB7PR04MB4618E527339B69AEAD46FB06E6A20@DB7PR04MB4618.eurprd04.prod.outlook.com>
On 29/08/2019 09.30, Joakim Zhang wrote:
> Hi Sean,
>
> I'm sorry that I can't get the debug log as the site can't be reached. And I connect two boards to do test at my side, this issue can't be reproduced.
>
> Best Regards,
> Joakim Zhang
Hi Joakim,
What commit and branch are you doing your tests with?
/Sean
^ permalink raw reply
* Re: [PATCHv2 1/1] forcedeth: use per cpu to collect xmit/recv statistics
From: David Miller @ 2019-09-05 6:13 UTC (permalink / raw)
To: yanjun.zhu; +Cc: eric.dumazet, netdev
In-Reply-To: <70ae3f79-0c57-97d4-ebec-1378782605c8@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Thu, 5 Sep 2019 10:48:01 +0800
>
> On 2019/9/5 6:22, David Miller wrote:
>> From: Zhu Yanjun <yanjun.zhu@oracle.com>
>> Date: Sun, 1 Sep 2019 03:26:13 -0400
>>
>>> +static inline void nv_get_stats(int cpu, struct fe_priv *np,
>>> + struct rtnl_link_stats64 *storage)
>> ...
>>> +static inline void rx_missing_handler(u32 flags, struct fe_priv *np)
>>> +{
>> Never use the inline keyword in foo.c files, let the compiler decide.
>
> Thanks a lot for your advice. I will pay attention to the usage of
> inline in the
>
> source code.
>
> If you agree, I will send V3 about this soon.
Of course "I agree" with my own feedback. Please just make V3 with
the inline keywords removed.
^ permalink raw reply
* pull request: bluetooth 2019-09-05
From: Johan Hedberg @ 2019-09-05 6:14 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
Hi Dave,
Here are a few more Bluetooth fixes for 5.3. I hope they can still make
it. There's one USB ID addition for btusb, two reverts due to discovered
regressions, and two other important fixes.
Please let me know if there any issues pulling. Thanks.
Johan
---
The following changes since commit 8693265329560af4d1190aaa195ad767a05ceeab:
Merge tag 'mac80211-for-davem-2019-08-29' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2019-08-29 16:44:15 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git for-upstream
for you to fetch changes up to 68d19d7d995759b96169da5aac313363f92a9075:
Revert "Bluetooth: validate BLE connection interval updates" (2019-09-05 09:02:59 +0300)
----------------------------------------------------------------
Harish Bandi (1):
Bluetooth: hci_qca: disable irqs when spinlock is acquired
Jian-Hong Pan (1):
Bluetooth: btrtl: Additional Realtek 8822CE Bluetooth devices
Marcel Holtmann (1):
Revert "Bluetooth: validate BLE connection interval updates"
Mario Limonciello (1):
Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"
Navid Emamdoost (1):
Bluetooth: bpa10x: change return value
drivers/bluetooth/bpa10x.c | 2 +-
drivers/bluetooth/btusb.c | 8 +++-----
drivers/bluetooth/hci_qca.c | 10 ++++++----
net/bluetooth/hci_event.c | 5 -----
net/bluetooth/l2cap_core.c | 9 +--------
5 files changed, 11 insertions(+), 23 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] ethtool: implement Energy Detect Powerdown support via phy-tunable
From: Ardelean, Alexandru @ 2019-09-05 6:25 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com
In-Reply-To: <20190904195357.GA21264@lunn.ch>
On Wed, 2019-09-04 at 21:53 +0200, Andrew Lunn wrote:
> [External]
>
> On Wed, Sep 04, 2019 at 07:23:21PM +0300, Alexandru Ardelean wrote:
>
> Hi Alexandru
>
> Somewhere we need a comment stating what EDPD means. Here would be a
> good place.
ack
>
> > +#define ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL 0x7fff
> > +#define ETHTOOL_PHY_EDPD_NO_TX 0x8000
> > +#define ETHTOOL_PHY_EDPD_DISABLE 0
>
> I think you are passing a u16. So why not 0xfffe and 0xffff? We also
> need to make it clear what the units are for interval. This file
I initially thought about keeping this u8 and going with 0xff & 0xfe.
But 254 or 253 could be too small to specify the value of an interval.
Also (maybe due ti all the coding-patterns that I saw over the course of some time), make me feel that I should add a
flag somewhere.
Bottom line is: 0xfffe and 0xffff also work from my side, if it is acceptable (by the community).
Another approach I considered, was to maybe have this EDPD just do enable & disable (which is sufficient for the `adin`
PHY & `micrel` as well).
That would mean that if we would ever want to configure the TX interval (in the future), we would need an extra PHY-
tunable parameter just for that; because changing the enable/disable behavior would be dangerous.
And also, deferring the TX-interval configuration, does not sound like good design/pattern, since it can allow for tons
of PHY-tunable parameters for every little knob.
> specifies the contract between the kernel and user space. So we need
> to clearly define what we mean here. Lots of comments are better than
> no comments.
Will come back with more comments.
>
> Andrew
^ permalink raw reply
* Re: pull request: bluetooth 2019-09-05
From: David Miller @ 2019-09-05 6:32 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-bluetooth
In-Reply-To: <20190905061444.GA47480@blobacz-mobl.ger.corp.intel.com>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Thu, 5 Sep 2019 09:14:44 +0300
> Here are a few more Bluetooth fixes for 5.3. I hope they can still make
> it. There's one USB ID addition for btusb, two reverts due to discovered
> regressions, and two other important fixes.
>
> Please let me know if there any issues pulling. Thanks.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: adin: implement Energy Detect Powerdown mode via phy-tunable
From: Ardelean, Alexandru @ 2019-09-05 6:32 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
hkallweit1@gmail.com
In-Reply-To: <20190904200350.GB21264@lunn.ch>
On Wed, 2019-09-04 at 22:03 +0200, Andrew Lunn wrote:
> [External]
>
> On Wed, Sep 04, 2019 at 07:23:22PM +0300, Alexandru Ardelean wrote:
> > This driver becomes the first user of the kernel's `ETHTOOL_PHY_EDPD`
> > phy-tunable feature.
> > EDPD is also enabled by default on PHY config_init, but can be disabled via
> > the phy-tunable control.
> >
> > When enabling EDPD, it's also a good idea (for the ADIN PHYs) to enable TX
> > periodic pulses, so that in case the other PHY is also on EDPD mode, there
> > is no lock-up situation where both sides are waiting for the other to
> > transmit.
> >
> > Via the phy-tunable control, TX pulses can be disabled if specifying 0
> > `tx-interval` via ethtool.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/net/phy/adin.c | 50 ++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> > index 4dec83df048d..742728ab2a5d 100644
> > --- a/drivers/net/phy/adin.c
> > +++ b/drivers/net/phy/adin.c
> > @@ -26,6 +26,11 @@
> >
> > #define ADIN1300_RX_ERR_CNT 0x0014
> >
> > +#define ADIN1300_PHY_CTRL_STATUS2 0x0015
> > +#define ADIN1300_NRG_PD_EN BIT(3)
> > +#define ADIN1300_NRG_PD_TX_EN BIT(2)
> > +#define ADIN1300_NRG_PD_STATUS BIT(1)
> > +
> > #define ADIN1300_PHY_CTRL2 0x0016
> > #define ADIN1300_DOWNSPEED_AN_100_EN BIT(11)
> > #define ADIN1300_DOWNSPEED_AN_10_EN BIT(10)
> > @@ -328,12 +333,51 @@ static int adin_set_downshift(struct phy_device *phydev, u8 cnt)
> > ADIN1300_DOWNSPEEDS_EN);
> > }
> >
> > +static int adin_get_edpd(struct phy_device *phydev, u16 *tx_interval)
> > +{
> > + int val;
> > +
> > + val = phy_read(phydev, ADIN1300_PHY_CTRL_STATUS2);
> > + if (val < 0)
> > + return val;
> > +
> > + if (ADIN1300_NRG_PD_EN & val) {
> > + if (val & ADIN1300_NRG_PD_TX_EN)
> > + *tx_interval = 1;
>
> What does 1 mean? 1 pico second, one hour? Anything but zero seconds?
> Does the datasheet specify what it actually does? Maybe you should be
> using ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL here, to indicate you actually
> have no idea, but it is the default for this PHY?
This PHY currently has a 1 second TX interval.
As specified by the datasheet (page 22 Energy-Detect Powerdown Mode section):
https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1300.pdf
"The PHY monitors the line for signal energy and sends a link pulse once every second"
Currently there is no control exposed to configure this interval; but there could be some registers (that are not
exposed yet) that could control this.
Micrel's datasheet mentions (page 27 3.16.1ENERGY-DETECT POWER-DOWN MODE section):
http://ww1.microchip.com/downloads/en/devicedoc/00002117f.pdf
"In EDPD Mode, the KSZ9031RNX shuts down all transceiver blocks, except for the transmitter and energy detect cir-cuits.
Power can be reduced further by extending the time interval between the transmissions of link pulses to check forthe
presence of a link partner."
I did not check for Micrel to see how that interval is controlled.
The reason for doing this TX interval control was mostly based on this mention from Micrel's datasheet, with
consideration that it could work ADIN & other future PHYs.
>
> > + else
> > + *tx_interval = ETHTOOL_PHY_EDPD_NO_TX;
> > + } else {
> > + *tx_interval = ETHTOOL_PHY_EDPD_DISABLE;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int adin_set_edpd(struct phy_device *phydev, u16 tx_interval)
> > +{
> > + u16 val;
> > +
> > + if (tx_interval == ETHTOOL_PHY_EDPD_DISABLE)
> > + return phy_clear_bits(phydev, ADIN1300_PHY_CTRL_STATUS2,
> > + (ADIN1300_NRG_PD_EN | ADIN1300_NRG_PD_TX_EN));
> > +
> > + val = ADIN1300_NRG_PD_EN;
> > + if (tx_interval != ETHTOOL_PHY_EDPD_NO_TX)
> > + val |= ADIN1300_NRG_PD_TX_EN;
>
> So you silently accept any interval? That sounds wrong. You really
> should be returning -EINVAL for any value other than, either 1, or
> maybe ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL, if you change the get
> function.
ack;
will use ETHTOOL_PHY_EDPD_DFLT_TX_INTERVAL, ETHTOOL_PHY_EDPD_NO_TX && 1 as acceptable values here
>
> Andrew
^ permalink raw reply
* [PATCH] iavf: fix MAC address setting for VFs when filter is rejected
From: Stefan Assmann @ 2019-09-05 6:34 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, davem, jeffrey.t.kirsher, lihong.yang, sassmann
Currently iavf unconditionally applies MAC address change requests. This
brings the VF in a state where it is no longer able to pass traffic if
the PF rejects a MAC filter change for the VF.
A typical scenario for a rejected MAC filter is for an untrusted VF to
request to change the MAC address when an administratively set MAC is
present.
To keep iavf working in this scenario the MAC filter handling in iavf
needs to act on the PF reply regarding the MAC filter change. In the
case of an ack the new MAC address gets set, whereas in the case of a
nack the previous MAC address needs to stay in place.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 1 -
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 7 +++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 39cc67cde89e..9e571a657fe7 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -826,7 +826,6 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
if (f) {
ether_addr_copy(hw->mac.addr, addr->sa_data);
- ether_addr_copy(netdev->dev_addr, adapter->hw.mac.addr);
}
return (f == NULL) ? -ENOMEM : 0;
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index d49d58a6de80..c46770eba320 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -1252,6 +1252,8 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
case VIRTCHNL_OP_ADD_ETH_ADDR:
dev_err(&adapter->pdev->dev, "Failed to add MAC filter, error %s\n",
iavf_stat_str(&adapter->hw, v_retval));
+ /* restore administratively set MAC address */
+ ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr);
break;
case VIRTCHNL_OP_DEL_VLAN:
dev_err(&adapter->pdev->dev, "Failed to delete VLAN filter, error %s\n",
@@ -1319,6 +1321,11 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
}
}
switch (v_opcode) {
+ case VIRTCHNL_OP_ADD_ETH_ADDR: {
+ if (!ether_addr_equal(netdev->dev_addr, adapter->hw.mac.addr))
+ ether_addr_copy(netdev->dev_addr, adapter->hw.mac.addr);
+ }
+ break;
case VIRTCHNL_OP_GET_STATS: {
struct iavf_eth_stats *stats =
(struct iavf_eth_stats *)msg;
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 net-next] net: stmmac: Add support for MDIO interrupts
From: Andrew Lunn @ 2019-09-05 6:40 UTC (permalink / raw)
To: Voon, Weifeng
Cc: David S. Miller, Maxime Coquelin, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jose Abreu, Giuseppe Cavallaro,
Alexandre Torgue, Ong, Boon Leong
In-Reply-To: <D6759987A7968C4889FDA6FA91D5CBC81475C23E@PGSMSX103.gar.corp.intel.com>
>
> The change log is near the end of the patch:
> /**
> --
> Changelog v2
> *mdio interrupt mode or polling mode will depends on mdio interrupt enable bit
> *Disable the mdio interrupt enable bit in stmmac_release
> *Remove the condition for initialize wait queues
> *Applied reverse Christmas tree
> 1.9.1
At the end, nobody sees it, because everybody else does it at the beginning.
https://www.kernel.org/doc/html/latest/process/submitting-patches.html?highlight=submitting#the-canonical-patch-format
This talks about the ---. David prefers to see the change log before
the ---. Other maintainers want it after the ---.
>
> >
> > The formatting of this patch also looks a bit odd. Did you use git
> > format-patch ; git send-email?
>
> Yes, I do git format-patch, then ./scripts/checkpatch.pl.
> Lastly git send-email
What looked odd is the missing --- marker. git format-patch should of
create that as part of the patch.
Andrew
^ permalink raw reply
* RE: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self wakeup
From: Joakim Zhang @ 2019-09-05 7:10 UTC (permalink / raw)
To: Sean Nyekjaer, mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Martin Hundebøll
In-Reply-To: <588ab34d-613d-ac01-7949-921140ca4543@geanix.com>
> -----Original Message-----
> From: Sean Nyekjaer <sean@geanix.com>
> Sent: 2019年9月5日 13:58
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; mkl@pengutronix.de;
> linux-can@vger.kernel.org
> Cc: wg@grandegger.com; netdev@vger.kernel.org; dl-linux-imx
> <linux-imx@nxp.com>; Martin Hundebøll <martin@geanix.com>
> Subject: Re: [PATCH REPOST 1/2] can: flexcan: fix deadlock when using self
> wakeup
>
>
>
> On 29/08/2019 09.30, Joakim Zhang wrote:
> > Hi Sean,
> >
> > I'm sorry that I can't get the debug log as the site can't be reached. And I
> connect two boards to do test at my side, this issue can't be reproduced.
> >
> > Best Regards,
> > Joakim Zhang
>
> Hi Joakim,
>
> What commit and branch are you doing your tests with?
Hi Sean,
Could you update lastest flexcan driver using linux-can-next/flexcan and then merge below two patches from linux-can/testing?
d0b53616716e (HEAD -> testing, origin/testing) can: flexcan: add LPSR mode support for i.MX7D
803eb6bad65b can: flexcan: fix deadlock when using self wakeup
Best Regards,
Joakim Zhang
> /Sean
^ permalink raw reply
* RE: [EXT] [PATCH] net: qed: Move static keyword to the front of declaration
From: Michal Kalderon @ 2019-09-05 7:10 UTC (permalink / raw)
To: Krzysztof Wilczynski, Ariel Elior
Cc: David S. Miller, GR-everest-linux-l2, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190904141730.31497-1-kw@linux.com>
> From: Krzysztof Wilczynski <kswilczynski@gmail.com> On Behalf Of Krzysztof
> Wilczynski
>
> External Email
>
> ----------------------------------------------------------------------
> Move the static keyword to the front of declaration of iwarp_state_names,
> and resolve the following compiler warning that can be seen when building
> with warnings enabled (W=1):
>
> drivers/net/ethernet/qlogic/qed/qed_iwarp.c:385:1: warning:
> ‘static’ is not at beginning of declaration [-Wold-style-declaration]
>
> Also, resolve checkpatch.pl script warning:
>
> WARNING: static const char * array should probably be
> static const char * const
>
> Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
> ---
> Related: https://lore.kernel.org/r/20190827233017.GK9987@google.com
>
> drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> index f380fae8799d..65ec16a31658 100644
> --- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> +++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
> @@ -382,7 +382,7 @@ qed_iwarp2roce_state(enum qed_iwarp_qp_state
> state)
> }
> }
>
> -const static char *iwarp_state_names[] = {
> +static const char * const iwarp_state_names[] = {
> "IDLE",
> "RTS",
> "TERMINATE",
Thanks,
Acked-by: Michal Kalderon <michal.kalderon@marvell.com>
> --
> 2.22.1
^ permalink raw reply
* Re: [PATCH v7 net-next 00/19] ionic: Add ionic driver
From: David Miller @ 2019-09-05 7:25 UTC (permalink / raw)
To: snelson; +Cc: netdev
In-Reply-To: <20190903222821.46161-1-snelson@pensando.io>
From: Shannon Nelson <snelson@pensando.io>
Date: Tue, 3 Sep 2019 15:28:02 -0700
> This is a patch series that adds the ionic driver, supporting the Pensando
> ethernet device.
>
> In this initial patchset we implement basic transmit and receive. Later
> patchsets will add more advanced features.
>
> Our thanks to Saeed Mahameed, David Miller, Andrew Lunn, Michal Kubecek,
> Jacub Kicinski, Jiri Pirko, Yunsheng Lin, and the ever present kbuild
> test robots for their comments and suggestions.
...
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH][next] net/sched: cbs: remove redundant assignment to variable port_rate
From: David Miller @ 2019-09-05 7:37 UTC (permalink / raw)
To: colin.king
Cc: jhs, xiyou.wangcong, jiri, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190902182637.22167-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Mon, 2 Sep 2019 19:26:37 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Variable port_rate is being initialized with a value that is never read
> and is being re-assigned a little later on. The assignment is redundant
> and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] Convert usage of IN_MULTICAST to ipv4_is_multicast
From: David Miller @ 2019-09-05 7:38 UTC (permalink / raw)
To: dave.taht; +Cc: netdev
In-Reply-To: <1567466976-1351-1-git-send-email-dave.taht@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Mon, 2 Sep 2019 16:29:36 -0700
> IN_MULTICAST's primary intent is as a uapi macro.
>
> Elsewhere in the kernel we use ipv4_is_multicast consistently.
>
> This patch unifies linux's multicast checks to use that function
> rather than this macro.
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
> Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net/tls: minor cleanups
From: David Miller @ 2019-09-05 7:51 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, oss-drivers, davejwatson, borisp, aviadye, john.fastabend,
daniel
In-Reply-To: <20190903043106.27570-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 2 Sep 2019 21:31:01 -0700
> This set is a grab bag of TLS cleanups accumulated in my tree
> in an attempt to avoid merge problems with net. Nothing stands
> out. First patch dedups context information. Next control path
> locking is very slightly optimized. Fourth patch cleans up
> ugly #ifdefs.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] vsock/virtio: a better comment on credit update
From: David Miller @ 2019-09-05 7:53 UTC (permalink / raw)
To: mst; +Cc: linux-kernel, sgarzare, stefanha, kvm, virtualization, netdev
In-Reply-To: <20190903073748.25214-1-mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 3 Sep 2019 03:38:16 -0400
> The comment we have is just repeating what the code does.
> Include the *reason* for the condition instead.
>
> Cc: Stefano Garzarella <sgarzare@redhat.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied.
^ permalink raw reply
* Re: pull-request: can-next 2019-09-03,pull-request: can-next 2019-09-03
From: David Miller @ 2019-09-05 7:57 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, linux-can
In-Reply-To: <a6751a50-f15d-612d-783b-a706098ea90e@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 3 Sep 2019 11:46:31 +0200
> this is a pull request for net-next/master consisting of 15 patches.
>
> The first patch is by Christer Beskow, targets the kvaser_pciefd driver
> and fixes the PWM generator's frequency.
>
> The next three patches are by Dan Murphy, the tcan4x5x is updated to use
> a proper interrupts/interrupt-parent DT binding to specify the devices
> IRQ line. Further the unneeded wake ups of the device is removed from
> the driver.
>
> A patch by me for the mcp25xx driver removes the deprecated board file
> setup example. Three patches by Andy Shevchenko simplify clock handling,
> update the driver from OF to device property API and simplify the
> mcp251x_can_suspend() function.
>
> The remaining 7 patches are by me and clean up checkpatch warnings in
> the generic CAN device infrastructure.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net] tipc: add NULL pointer check before calling kfree_rcu
From: David Miller @ 2019-09-05 7:59 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, jon.maloy, ying.xue, tipc-discussion
In-Reply-To: <f42a6270d821baf1445b5fa40dc201f7c9c5ebd0.1567504392.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 3 Sep 2019 17:53:12 +0800
> Unlike kfree(p), kfree_rcu(p, rcu) won't do NULL pointer check. When
> tipc_nametbl_remove_publ returns NULL, the panic below happens:
...
> Fixes: 97ede29e80ee ("tipc: convert name table read-write lock to RCU")
> Reported-by: Li Shuang <shuali@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net/skbuff: silence warnings under memory pressure
From: Eric Dumazet @ 2019-09-05 8:32 UTC (permalink / raw)
To: Qian Cai, Sergey Senozhatsky
Cc: Sergey Senozhatsky, Michal Hocko, Eric Dumazet, davem, netdev,
linux-mm, linux-kernel, Petr Mladek, Steven Rostedt
In-Reply-To: <1567629737.5576.87.camel@lca.pw>
On 9/4/19 10:42 PM, Qian Cai wrote:
> To summary, those look to me are all good long-term improvement that would
> reduce the likelihood of this kind of livelock in general especially for other
> unknown allocations that happen while processing softirqs, but it is still up to
> the air if it fixes it 100% in all situations as printk() is going to take more
> time and could deal with console hardware that involve irq_exit() anyway.
>
> On the other hand, adding __GPF_NOWARN in the build_skb() allocation will fix
> this known NET_TX_SOFTIRQ case which is common when softirqd involved at least
> in short-term. It even have a benefit to reduce the overall warn_alloc() noise
> out there.
>
> I can resubmit with an update changelog. Does it make any sense?
It does not make sense.
We have thousands other GFP_ATOMIC allocations in the networking stacks.
Soon you will have to send more and more patches adding __GFP_NOWARN once
your workloads/tests can hit all these various points.
It is really time to fix this problem generically, instead of having
to review hundreds of patches.
This was my initial feedback really, nothing really has changed since.
The ability to send a warning with a stack trace, holding the cpu
for many milliseconds should not be decided case by case, otherwise
every call points will decide to opt-out from the harmful warnings.
^ permalink raw reply
* Re: [net-next 2/3] ravb: Remove undocumented processing
From: Simon Horman @ 2019-09-05 8:34 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: David Miller, Magnus Damm, netdev, linux-renesas-soc,
Kazuya Mizuguchi
In-Reply-To: <f54e244a-2d9d-7ba8-02fb-af5572b3a191@cogentembedded.com>
On Mon, Sep 02, 2019 at 08:41:14PM +0300, Sergei Shtylyov wrote:
> On 09/02/2019 11:06 AM, Simon Horman wrote:
>
> > From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> >
> > This patch removes the use of the undocumented registers
> > CDCR, LCCR, CERCR, CEECR and the undocumented BOC bit of the CCC register.
>
> The driver has many more #define's marked as undocumented. It's not clear
> why you crammed the counters and the endianness bit in one patch. It clearly
> needs to be split -- one patch for the MAC counters and one patch for the
> AVB-DMAC bit.
Thanks for the suggestion, I will split the patch.
> > Current documentation for EtherAVB (ravb) describes the offset of
> > what the driver uses as the BOC bit as reserved and that only a value of
> > 0 should be written. Furthermore, the offsets used for the undocumented
> > registers are also considered reserved nd should not be written to.
> >
> > After some internal investigation with Renesas it remains unclear
> > why this driver accesses these fields but regardless of what the historical
> > reasons are the current code is considered incorrect.
> >
> > Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> [...]
>
> MBR, Sergei
>
^ 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