* Re: [PATCH v1 1/2] dt-binding: net: document NPCM7xx EMC 10/100 DT bindings
From: Rob Herring @ 2019-08-21 18:33 UTC (permalink / raw)
To: Avi Fishman
Cc: venture, yuenn, benjaminfair, davem, mark.rutland, gregkh,
tmaimon77, tali.perry1, openbmc, netdev, devicetree, linux-kernel,
tglx
In-Reply-To: <20190801072611.27935-2-avifishman70@gmail.com>
On Thu, Aug 01, 2019 at 10:26:10AM +0300, Avi Fishman wrote:
> Added device tree binding documentation for
> Nuvoton NPCM7xx Ethernet MAC Controller (EMC) 10/100 RMII
>
> Signed-off-by: Avi Fishman <avifishman70@gmail.com>
> ---
> .../bindings/net/nuvoton,npcm7xx-emc.txt | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt
Consider converting this to DT schema (YAML).
>
> diff --git a/Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt b/Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt
> new file mode 100644
> index 000000000000..a7ac3ca66de9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/nuvoton,npcm7xx-emc.txt
> @@ -0,0 +1,38 @@
> +Nuvoton NPCM7XX 10/100 Ethernet MAC Controller (EMC)
> +
> +The NPCM7XX provides one or two Ethernet MAC RMII Controllers
> +for WAN/LAN applications
> +
> +Required properties:
> +- device_type : Should be "network"
Drop this. device_type is deprecated for FDT except for a few cases.
> +- compatible : "nuvoton,npcm750-emc" for Poleg NPCM7XX.
> +- reg : Offset and length of the register set for the device.
> +- interrupts : Contain the emc interrupts with flags for falling edge.
> + first interrupt dedicated to Txirq
> + second interrupt dedicated to Rxirq
> +- phy-mode : Should be "rmii" (see ethernet.txt in the same directory)
> +- clocks : phandle of emc reference clock.
> +- resets : phandle to the reset control for this device.
> +- use-ncsi : Use the NC-SI stack instead of an MDIO PHY
Vendor prefix needed.
> +
> +Example:
> +
> +emc0: eth@f0825000 {
ethernet@...
> + device_type = "network";
> + compatible = "nuvoton,npcm750-emc";
> + reg = <0xf0825000 0x1000>;
> + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> + phy-mode = "rmii";
> + clocks = <&clk NPCM7XX_CLK_AHB>;
> +
> + #use-ncsi; /* add this to support ncsi */
Doesn't match the binding.
> +
> + clock-names = "clk_emc";
> + resets = <&rstc 6>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&r1_pins
> + &r1err_pins
> + &r1md_pins>;
> + status = "okay";
Drop status in examples.
> +};
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH 30/38] cls_flower: Use XArray list of filters in fl_walk
From: Vlad Buslov @ 2019-08-21 18:32 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190820223259.22348-31-willy@infradead.org>
On Wed 21 Aug 2019 at 01:32, Matthew Wilcox <willy@infradead.org> wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Instead of iterating over every filter attached to every mark, just
> iterate over each filter.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> net/sched/cls_flower.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index 54026c9e9b05..2a1999d2b507 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -575,18 +575,15 @@ static void fl_destroy(struct tcf_proto *tp, bool rtnl_held,
> struct netlink_ext_ack *extack)
> {
> struct cls_fl_head *head = fl_head_dereference(tp);
> - struct fl_flow_mask *mask, *next_mask;
> - struct cls_fl_filter *f, *next;
> + struct cls_fl_filter *f;
> + unsigned long handle;
> bool last;
>
> - list_for_each_entry_safe(mask, next_mask, &head->masks, list) {
> - list_for_each_entry_safe(f, next, &mask->filters, list) {
> - __fl_delete(tp, f, &last, rtnl_held, extack);
> - if (last)
> - break;
> - }
> + xa_for_each(&head->filters, handle, f) {
> + __fl_delete(tp, f, &last, rtnl_held, extack);
> + if (last)
> + break;
> }
> - xa_destroy(&head->filters);
>
> __module_get(THIS_MODULE);
> tcf_queue_work(&head->rwork, fl_destroy_sleepable);
What is the motivation for this change? You substitute O(n) iteration
over linked list with O(nlogn) iteration over xarray without any
apparent benefit.
^ permalink raw reply
* Re: [RFC PATCH bpf-next 00/14] xdp_flow: Flow offload to XDP
From: Jakub Kicinski @ 2019-08-21 18:38 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Stanislav Fomichev, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, David S. Miller,
Jesper Dangaard Brouer, John Fastabend, Jamal Hadi Salim,
Cong Wang, Jiri Pirko, netdev, bpf, William Tu
In-Reply-To: <250f99fd-7289-a8e2-a710-560305e2d17d@gmail.com>
On Wed, 21 Aug 2019 17:49:33 +0900, Toshiaki Makita wrote:
> > Having an implementation nor support a feature of another implementation
> > and degrade gracefully to the slower one is not necessarily breakage.
> > We need to make a concious decision here, hence the clarifying question.
>
> As I described above, breakage can happen in some case, and if the patch
> breaks xdp_flow I think we need to fix xdp_flow at the same time. If
> xdp_flow does not support newly added features but it works for existing
> ones, it is OK. In the first place not all features can be offloaded to
> xdp_flow. I think this is the same as HW-offload.
I see, that sounds reasonable, yes. Thanks for clarifying.
^ permalink raw reply
* [PATCH] mISDN: Delete unnecessary checks before the macro call “dev_kfree_skb”
From: Markus Elfring @ 2019-08-21 18:45 UTC (permalink / raw)
To: netdev, Alexios Zavras, Allison Randal, Armijn Hemel,
Arnd Bergmann, David S. Miller, Fuqian Huang, Greg Kroah-Hartman,
Heiner Kallweit, Kangjie Lu, Karsten Keil, Thomas Gleixner
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 21 Aug 2019 20:10:56 +0200
The dev_kfree_skb() function performs also input parameter validation.
Thus the test around the shown calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/isdn/hardware/mISDN/avmfritz.c | 3 +--
drivers/isdn/hardware/mISDN/hfcpci.c | 6 ++----
drivers/isdn/hardware/mISDN/mISDNipac.c | 12 ++++--------
drivers/isdn/hardware/mISDN/mISDNisar.c | 3 +--
drivers/isdn/hardware/mISDN/netjet.c | 3 +--
drivers/isdn/hardware/mISDN/w6692.c | 9 +++------
drivers/isdn/mISDN/l1oip_core.c | 3 +--
drivers/isdn/mISDN/layer2.c | 9 +++------
drivers/isdn/mISDN/stack.c | 6 ++----
drivers/isdn/mISDN/tei.c | 6 ++----
10 files changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/avmfritz.c b/drivers/isdn/hardware/mISDN/avmfritz.c
index 81f2b183acc8..1137dd152b5c 100644
--- a/drivers/isdn/hardware/mISDN/avmfritz.c
+++ b/drivers/isdn/hardware/mISDN/avmfritz.c
@@ -509,8 +509,7 @@ HDLC_irq_xpr(struct bchannel *bch)
if (bch->tx_skb && bch->tx_idx < bch->tx_skb->len) {
hdlc_fill_fifo(bch);
} else {
- if (bch->tx_skb)
- dev_kfree_skb(bch->tx_skb);
+ dev_kfree_skb(bch->tx_skb);
if (get_next_bframe(bch)) {
hdlc_fill_fifo(bch);
test_and_clear_bit(FLG_TX_EMPTY, &bch->Flags);
diff --git a/drivers/isdn/hardware/mISDN/hfcpci.c b/drivers/isdn/hardware/mISDN/hfcpci.c
index 4a069582fc6b..2330a7d24267 100644
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -1119,8 +1119,7 @@ tx_birq(struct bchannel *bch)
if (bch->tx_skb && bch->tx_idx < bch->tx_skb->len)
hfcpci_fill_fifo(bch);
else {
- if (bch->tx_skb)
- dev_kfree_skb(bch->tx_skb);
+ dev_kfree_skb(bch->tx_skb);
if (get_next_bframe(bch))
hfcpci_fill_fifo(bch);
}
@@ -1132,8 +1131,7 @@ tx_dirq(struct dchannel *dch)
if (dch->tx_skb && dch->tx_idx < dch->tx_skb->len)
hfcpci_fill_dfifo(dch->hw);
else {
- if (dch->tx_skb)
- dev_kfree_skb(dch->tx_skb);
+ dev_kfree_skb(dch->tx_skb);
if (get_next_dframe(dch))
hfcpci_fill_dfifo(dch->hw);
}
diff --git a/drivers/isdn/hardware/mISDN/mISDNipac.c b/drivers/isdn/hardware/mISDN/mISDNipac.c
index f915399d75ca..bca880213e91 100644
--- a/drivers/isdn/hardware/mISDN/mISDNipac.c
+++ b/drivers/isdn/hardware/mISDN/mISDNipac.c
@@ -190,8 +190,7 @@ isac_rme_irq(struct isac_hw *isac)
#endif
}
WriteISAC(isac, ISAC_CMDR, 0x80);
- if (isac->dch.rx_skb)
- dev_kfree_skb(isac->dch.rx_skb);
+ dev_kfree_skb(isac->dch.rx_skb);
isac->dch.rx_skb = NULL;
} else {
count = ReadISAC(isac, ISAC_RBCL) & 0x1f;
@@ -210,8 +209,7 @@ isac_xpr_irq(struct isac_hw *isac)
if (isac->dch.tx_skb && isac->dch.tx_idx < isac->dch.tx_skb->len) {
isac_fill_fifo(isac);
} else {
- if (isac->dch.tx_skb)
- dev_kfree_skb(isac->dch.tx_skb);
+ dev_kfree_skb(isac->dch.tx_skb);
if (get_next_dframe(&isac->dch))
isac_fill_fifo(isac);
}
@@ -464,8 +462,7 @@ isacsx_rme_irq(struct isac_hw *isac)
isac->dch.err_crc++;
#endif
WriteISAC(isac, ISACX_CMDRD, ISACX_CMDRD_RMC);
- if (isac->dch.rx_skb)
- dev_kfree_skb(isac->dch.rx_skb);
+ dev_kfree_skb(isac->dch.rx_skb);
isac->dch.rx_skb = NULL;
} else {
count = ReadISAC(isac, ISACX_RBCLD) & 0x1f;
@@ -1012,8 +1009,7 @@ hscx_xpr(struct hscx_hw *hx)
if (hx->bch.tx_skb && hx->bch.tx_idx < hx->bch.tx_skb->len) {
hscx_fill_fifo(hx);
} else {
- if (hx->bch.tx_skb)
- dev_kfree_skb(hx->bch.tx_skb);
+ dev_kfree_skb(hx->bch.tx_skb);
if (get_next_bframe(&hx->bch)) {
hscx_fill_fifo(hx);
test_and_clear_bit(FLG_TX_EMPTY, &hx->bch.Flags);
diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c b/drivers/isdn/hardware/mISDN/mISDNisar.c
index fd5c52f37802..4a3e748a1c26 100644
--- a/drivers/isdn/hardware/mISDN/mISDNisar.c
+++ b/drivers/isdn/hardware/mISDN/mISDNisar.c
@@ -690,8 +690,7 @@ send_next(struct isar_ch *ch)
}
}
}
- if (ch->bch.tx_skb)
- dev_kfree_skb(ch->bch.tx_skb);
+ dev_kfree_skb(ch->bch.tx_skb);
if (get_next_bframe(&ch->bch)) {
isar_fill_fifo(ch);
test_and_clear_bit(FLG_TX_EMPTY, &ch->bch.Flags);
diff --git a/drivers/isdn/hardware/mISDN/netjet.c b/drivers/isdn/hardware/mISDN/netjet.c
index 4e30affd1a7c..61caa7e50b9a 100644
--- a/drivers/isdn/hardware/mISDN/netjet.c
+++ b/drivers/isdn/hardware/mISDN/netjet.c
@@ -605,8 +605,7 @@ bc_next_frame(struct tiger_ch *bc)
if (bc->bch.tx_skb && bc->bch.tx_idx < bc->bch.tx_skb->len) {
fill_dma(bc);
} else {
- if (bc->bch.tx_skb)
- dev_kfree_skb(bc->bch.tx_skb);
+ dev_kfree_skb(bc->bch.tx_skb);
if (get_next_bframe(&bc->bch)) {
fill_dma(bc);
test_and_clear_bit(FLG_TX_EMPTY, &bc->bch.Flags);
diff --git a/drivers/isdn/hardware/mISDN/w6692.c b/drivers/isdn/hardware/mISDN/w6692.c
index 2402608dc98d..bad55fdacd36 100644
--- a/drivers/isdn/hardware/mISDN/w6692.c
+++ b/drivers/isdn/hardware/mISDN/w6692.c
@@ -356,8 +356,7 @@ handle_rxD(struct w6692_hw *card) {
card->dch.err_rx++;
#endif
}
- if (card->dch.rx_skb)
- dev_kfree_skb(card->dch.rx_skb);
+ dev_kfree_skb(card->dch.rx_skb);
card->dch.rx_skb = NULL;
WriteW6692(card, W_D_CMDR, W_D_CMDR_RACK | W_D_CMDR_RRST);
} else {
@@ -376,8 +375,7 @@ handle_txD(struct w6692_hw *card) {
if (card->dch.tx_skb && card->dch.tx_idx < card->dch.tx_skb->len) {
W6692_fill_Dfifo(card);
} else {
- if (card->dch.tx_skb)
- dev_kfree_skb(card->dch.tx_skb);
+ dev_kfree_skb(card->dch.tx_skb);
if (get_next_dframe(&card->dch))
W6692_fill_Dfifo(card);
}
@@ -636,8 +634,7 @@ send_next(struct w6692_ch *wch)
if (wch->bch.tx_skb && wch->bch.tx_idx < wch->bch.tx_skb->len) {
W6692_fill_Bfifo(wch);
} else {
- if (wch->bch.tx_skb)
- dev_kfree_skb(wch->bch.tx_skb);
+ dev_kfree_skb(wch->bch.tx_skb);
if (get_next_bframe(&wch->bch)) {
W6692_fill_Bfifo(wch);
test_and_clear_bit(FLG_TX_EMPTY, &wch->bch.Flags);
diff --git a/drivers/isdn/mISDN/l1oip_core.c b/drivers/isdn/mISDN/l1oip_core.c
index 447f241467bd..b57dcb834594 100644
--- a/drivers/isdn/mISDN/l1oip_core.c
+++ b/drivers/isdn/mISDN/l1oip_core.c
@@ -1254,8 +1254,7 @@ release_card(struct l1oip *hc)
mISDN_freebchannel(hc->chan[ch].bch);
kfree(hc->chan[ch].bch);
#ifdef REORDER_DEBUG
- if (hc->chan[ch].disorder_skb)
- dev_kfree_skb(hc->chan[ch].disorder_skb);
+ dev_kfree_skb(hc->chan[ch].disorder_skb);
#endif
}
}
diff --git a/drivers/isdn/mISDN/layer2.c b/drivers/isdn/mISDN/layer2.c
index 68a481516729..5bf7fcb282c4 100644
--- a/drivers/isdn/mISDN/layer2.c
+++ b/drivers/isdn/mISDN/layer2.c
@@ -900,8 +900,7 @@ l2_disconnect(struct FsmInst *fi, int event, void *arg)
send_uframe(l2, NULL, DISC | 0x10, CMD);
mISDN_FsmDelTimer(&l2->t203, 1);
restart_t200(l2, 2);
- if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb(skb);
}
static void
@@ -1722,8 +1721,7 @@ l2_set_own_busy(struct FsmInst *fi, int event, void *arg)
enquiry_cr(l2, RNR, RSP, 0);
test_and_clear_bit(FLG_ACK_PEND, &l2->flag);
}
- if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb(skb);
}
static void
@@ -1736,8 +1734,7 @@ l2_clear_own_busy(struct FsmInst *fi, int event, void *arg)
enquiry_cr(l2, RR, RSP, 0);
test_and_clear_bit(FLG_ACK_PEND, &l2->flag);
}
- if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb(skb);
}
static void
diff --git a/drivers/isdn/mISDN/stack.c b/drivers/isdn/mISDN/stack.c
index fa2237e7bcf8..27aa32914425 100644
--- a/drivers/isdn/mISDN/stack.c
+++ b/drivers/isdn/mISDN/stack.c
@@ -75,8 +75,7 @@ send_socklist(struct mISDN_sock_list *sl, struct sk_buff *skb)
cskb = NULL;
}
read_unlock(&sl->lock);
- if (cskb)
- dev_kfree_skb(cskb);
+ dev_kfree_skb(cskb);
}
static void
@@ -134,8 +133,7 @@ send_layer2(struct mISDNstack *st, struct sk_buff *skb)
}
out:
mutex_unlock(&st->lmutex);
- if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb(skb);
}
static inline int
diff --git a/drivers/isdn/mISDN/tei.c b/drivers/isdn/mISDN/tei.c
index a4fa594e1caf..59d28cb19738 100644
--- a/drivers/isdn/mISDN/tei.c
+++ b/drivers/isdn/mISDN/tei.c
@@ -1328,10 +1328,8 @@ mgr_bcast(struct mISDNchannel *ch, struct sk_buff *skb)
}
out:
read_unlock_irqrestore(&mgr->lock, flags);
- if (cskb)
- dev_kfree_skb(cskb);
- if (skb)
- dev_kfree_skb(skb);
+ dev_kfree_skb(cskb);
+ dev_kfree_skb(skb);
return 0;
}
--
2.23.0
^ permalink raw reply related
* Re: [GIT PULL] Keys: Set 4 - Key ACLs for 5.3
From: Mimi Zohar @ 2019-08-21 14:20 UTC (permalink / raw)
To: David Howells
Cc: Linus Torvalds, James Morris, keyrings, Netdev, linux-nfs, CIFS,
linux-afs, linux-fsdevel, linux-integrity, LSM List,
Linux List Kernel Mailing
In-Reply-To: <23498.1565962602@warthog.procyon.org.uk>
On Fri, 2019-08-16 at 14:36 +0100, David Howells wrote:
> Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> > Sorry for the delay. An exception is needed for loading builtin keys
> > "KEY_ALLOC_BUILT_IN" onto a keyring that is not writable by userspace.
> > The following works, but probably is not how David would handle the
> > exception.
>
> I think the attached is the right way to fix it.
>
> load_system_certificate_list(), for example, when it creates keys does this:
>
> key = key_create_or_update(make_key_ref(builtin_trusted_keys, 1),
>
> marking the keyring as "possessed" in make_key_ref(). This allows the
> possessor permits to be used - and that's the *only* way to use them for
> internal keyrings like this because you can't link to them and you can't join
> them.
In addition, as long as additional keys still can't be added or
existing keys updated by userspace on the .builtin_trusted_keys, then
this is fine.
>
> David
> ---
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 57be78b5fdfc..1f8f26f7bb05 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -99,7 +99,7 @@ static __init int system_trusted_keyring_init(void)
> builtin_trusted_keys =
> keyring_alloc(".builtin_trusted_keys",
> KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> - &internal_key_acl, KEY_ALLOC_NOT_IN_QUOTA,
> + &internal_keyring_acl, KEY_ALLOC_NOT_IN_QUOTA,
> NULL, NULL);
> if (IS_ERR(builtin_trusted_keys))
> panic("Can't allocate builtin trusted keyring\n");
> diff --git a/security/keys/permission.c b/security/keys/permission.c
> index fc84d9ef6239..86efd3eaf083 100644
> --- a/security/keys/permission.c
> +++ b/security/keys/permission.c
> @@ -47,7 +47,7 @@ struct key_acl internal_keyring_acl = {
> .usage = REFCOUNT_INIT(1),
> .nr_ace = 2,
> .aces = {
> - KEY_POSSESSOR_ACE(KEY_ACE_SEARCH),
> + KEY_POSSESSOR_ACE(KEY_ACE_SEARCH | KEY_ACE_WRITE),
> KEY_OWNER_ACE(KEY_ACE_VIEW | KEY_ACE_READ | KEY_ACE_SEARCH),
> }
> };
Thanks, David. The builtin keys are now being loaded.
Mimi
^ permalink raw reply
* Re: net: micrel: confusion about phyids used in driver
From: allan.nielsen @ 2019-08-21 18:49 UTC (permalink / raw)
To: Florian Fainelli
Cc: Uwe Kleine-König, Nicolas Ferre, netdev, andrew, kernel,
hkallweit1, Ravi.Hegde, Tristram.Ha, Yuiko.Oshino, Woojung.Huh
In-Reply-To: <1057c2c2-e1f0-75ba-3878-dbd52805e0cc@gmail.com>
The 08/21/2019 10:24, Florian Fainelli wrote:
> +Allan,
>
> On 8/20/19 1:25 PM, Uwe Kleine-König wrote:
> > Hello Nicolas,
> >
> > there are some open questions regarding details about some PHYs
> > supported in the drivers/net/phy/micrel.c driver.
> >
> > On Thu, Aug 08, 2019 at 10:36:37AM +0200, Uwe Kleine-König wrote:
> >> On Tue, Jul 02, 2019 at 08:55:07PM +0000, Yuiko.Oshino@microchip.com wrote:
> >>>> On Fri, May 10, 2019 at 09:22:43AM +0200, Uwe Kleine-König wrote:
> >>>>> On Thu, May 09, 2019 at 11:07:45PM +0200, Andrew Lunn wrote:
> >>>>>> On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote:
> >>>>>>> On 09.05.2019 22:29, Uwe Kleine-König wrote:
> >>>>>>>> I have a board here that has a KSZ8051MLL (datasheet:
> >>>>>>>> http://ww1.microchip.com/downloads/en/DeviceDoc/ksz8051mll.pdf, phyid:
> >>>>>>>> 0x0022155x) assembled. The actual phyid is 0x00221556.
> >
> > The short version is that a phy with ID 0x00221556 matches two
> > phy_driver entries in the driver:
> >
> > { .phy_id = PHY_ID_KSZ8031, .phy_id_mask = 0x00ffffff, ... },
> > { .phy_id = PHY_ID_KSZ8051, .phy_id_mask = MICREL_PHY_ID_MASK, ... }
> >
> > The driver doesn't behave optimal for "my" KSZ8051MLL with both entries
> > ... It seems to work, but not all features of the phy are used and the
> > bootlog claims this was a KSZ8031 because that's the first match in the
> > list.
> >
> > So we're in need of someone who can get their hands on some more
> > detailed documentation than publicly available to allow to make the
> > driver handle the KSZ8051MLL correctly without breaking other stuff.
> >
> > I assume you are in a different department of Microchip than the people
> > caring for PHYs, but maybe you can still help finding someone who cares?
>
> Allan, is this something you could help with? Thanks!
Sorry, I'm new in Microchip (was aquired through Microsemi), and I know next to
nothing about the Micrel stuff.
Woojung: Can you comment on this, or try to direct this to someone who knows
something...
> >>>>>>> I think the datasheets are the source of the confusion. If the
> >>>>>>> datasheets for different chips list 0x0022155x as PHYID each, and
> >>>>>>> authors of support for additional chips don't check the existing
> >>>>>>> code, then happens what happened.
> >>>>>>>
> >>>>>>> However it's not a rare exception and not Microchip-specific that
> >>>>>>> sometimes vendors use the same PHYID for different chips.
> >>>>>
> >>>>> From the vendor's POV it is even sensible to reuse the phy IDs iff the
> >>>>> chips are "compatible".
> >>>>>
> >>>>> Assuming that the last nibble of the phy ID actually helps to
> >>>>> distinguish the different (not completely) compatible chips, we need
> >>>>> some more detailed information than available in the data sheets I have.
> >>>>> There is one person in the recipents of this mail with an
> >>>>> @microchip.com address (hint, hint!).
> >>>>
> >>>> can you give some input here or forward to a person who can?
> >>>
> >>> I forward this to the team.
> >>
> >> This thread still sits in my inbox waiting for some feedback. Did
> >> something happen on your side?
> >
> > This is still true, didn't hear back from Yuiko Oshino for some time
> > now.
> >
> > Best regards
> > Uwe
> >
>
>
> --
> Florian
--
/Allan
^ permalink raw reply
* Re: [EXT] Re: [PATCH net-next 0/1] Add BASE-T1 PHY support
From: Andrew Lunn @ 2019-08-21 18:57 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Christian Herber, davem@davemloft.net, Florian Fainelli,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5c920846-b8f5-d087-cea4-a8ca3f816127@gmail.com>
> The current patch set IMO is a little bit hacky. I'm not 100% happy
> with the implicit assumption that there can't be devices supporting
> T1 and classic BaseT modes or fiber modes.
>
> Andrew: Do you have an opinion on that?
Hi Heiner
I would also like cleaner integration. I doubt here is anything in the
standard which says you cannot combine these modes. It is more a
marketing question if anybody would build such a device. Maybe not
directly into a vehicle, but you could imaging a mobile test device
which uses T1 to talk to the car and T4 to connect to the garage
network?
So i don't think we should limit ourselves. phylib should provide a
clean, simple set of helpers to perform standard operations for
various modes. Drivers can make use of those helpers. That much should
be clear. If we try to make genphy support them all simultaneously, is
less clear.
Andrew
^ permalink raw reply
* Re: Regression fix for bpf in v5.3 (was Re: [RFC PATCH] bpf: handle 32-bit zext during constant blinding)
From: Naveen N. Rao @ 2019-08-21 19:12 UTC (permalink / raw)
To: Jiong Wang, Michael Ellerman
Cc: Alexei Starovoitov, bpf, Daniel Borkmann, linux-kernel,
linuxppc-dev, netdev
In-Reply-To: <87k1b6yeh1.fsf@netronome.com>
Jiong Wang wrote:
>
> Michael Ellerman writes:
>
>> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>>> Since BPF constant blinding is performed after the verifier pass, there
>>> are certain ALU32 instructions inserted which don't have a corresponding
>>> zext instruction inserted after. This is causing a kernel oops on
>>> powerpc and can be reproduced by running 'test_cgroup_storage' with
>>> bpf_jit_harden=2.
>>>
>>> Fix this by emitting BPF_ZEXT during constant blinding if
>>> prog->aux->verifier_zext is set.
>>>
>>> Fixes: a4b1d3c1ddf6cb ("bpf: verifier: insert zero extension according to analysis result")
>>> Reported-by: Michael Ellerman <mpe@ellerman.id.au>
>>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>>> ---
>>> This approach (the location where zext is being introduced below, in
>>> particular) works for powerpc, but I am not entirely sure if this is
>>> sufficient for other architectures as well. This is broken on v5.3-rc4.
>>
>> Any comment on this?
>
> Have commented on https://marc.info/?l=linux-netdev&m=156637836024743&w=2
>
> The fix looks correct to me on "BPF_LD | BPF_IMM | BPF_DW", but looks
> unnecessary on two other places. It would be great if you or Naveen could
> confirm it.
Jiong,
Thanks for the review. I can now see why the other two changes are not
necessary. I will post a follow-on patch.
Thanks!
- Naveen
^ permalink raw reply
* Re: [PATCH 31/38] cls_flower: Use XArray marks instead of separate list
From: Vlad Buslov @ 2019-08-21 19:12 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190820223259.22348-32-willy@infradead.org>
On Wed 21 Aug 2019 at 01:32, Matthew Wilcox <willy@infradead.org> wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Remove the hw_filter list in favour of using one of the XArray mark
> bits which lets us iterate more efficiently than walking a linked list.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> net/sched/cls_flower.c | 47 ++++++++++--------------------------------
> 1 file changed, 11 insertions(+), 36 deletions(-)
>
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index 2a1999d2b507..4625de5e29a7 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -85,11 +85,12 @@ struct fl_flow_tmplt {
> struct tcf_chain *chain;
> };
>
> +#define HW_FILTER XA_MARK_1
> +
> struct cls_fl_head {
> struct rhashtable ht;
> spinlock_t masks_lock; /* Protect masks list */
> struct list_head masks;
> - struct list_head hw_filters;
> struct rcu_work rwork;
> struct xarray filters;
> };
> @@ -102,7 +103,6 @@ struct cls_fl_filter {
> struct tcf_result res;
> struct fl_flow_key key;
> struct list_head list;
> - struct list_head hw_list;
> u32 handle;
> u32 flags;
> u32 in_hw_count;
> @@ -332,7 +332,6 @@ static int fl_init(struct tcf_proto *tp)
>
> spin_lock_init(&head->masks_lock);
> INIT_LIST_HEAD_RCU(&head->masks);
> - INIT_LIST_HEAD(&head->hw_filters);
> rcu_assign_pointer(tp->root, head);
> xa_init_flags(&head->filters, XA_FLAGS_ALLOC1);
>
> @@ -421,7 +420,6 @@ static void fl_hw_destroy_filter(struct tcf_proto *tp, struct cls_fl_filter *f,
>
> tc_setup_cb_call(block, TC_SETUP_CLSFLOWER, &cls_flower, false);
> spin_lock(&tp->lock);
> - list_del_init(&f->hw_list);
> tcf_block_offload_dec(block, &f->flags);
> spin_unlock(&tp->lock);
>
> @@ -433,7 +431,6 @@ static int fl_hw_replace_filter(struct tcf_proto *tp,
> struct cls_fl_filter *f, bool rtnl_held,
> struct netlink_ext_ack *extack)
> {
> - struct cls_fl_head *head = fl_head_dereference(tp);
> struct tcf_block *block = tp->chain->block;
> struct flow_cls_offload cls_flower = {};
> bool skip_sw = tc_skip_sw(f->flags);
> @@ -485,9 +482,6 @@ static int fl_hw_replace_filter(struct tcf_proto *tp,
> goto errout;
> }
>
> - spin_lock(&tp->lock);
> - list_add(&f->hw_list, &head->hw_filters);
> - spin_unlock(&tp->lock);
> errout:
> if (!rtnl_held)
> rtnl_unlock();
> @@ -1581,7 +1575,6 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> err = -ENOBUFS;
> goto errout_tb;
> }
> - INIT_LIST_HEAD(&fnew->hw_list);
> refcount_set(&fnew->refcnt, 1);
>
> err = tcf_exts_init(&fnew->exts, net, TCA_FLOWER_ACT, 0);
> @@ -1698,6 +1691,11 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
>
> *arg = fnew;
>
> + if (!tc_skip_hw(fnew->flags))
> + xa_set_mark(&head->filters, fnew->handle, HW_FILTER);
> + else if (fold)
> + xa_clear_mark(&head->filters, fnew->handle, HW_FILTER);
> +
I like how xa mark simplifies reoffload handling, but this wouldn't
work anymore because without rtnl protection fl_change()/fl_delete() can
be called concurrently with fl_reoffload(). My original implementation
of unlocked flower classifier relied on idr in fl_reoffload() and we had
to introduce hw_list due to following race conditions:
- fl_reoffload() can miss fnew if it runs after fnew was provisioned to
hardware with fl_hw_replace_filter() but before it is marked with
HW_FILTER.
- Another race condition would be in __fl_delete() when filter is
removed from xarray, then shared block is detached concurrently which
causes fl_reoffload() that misses the filter, then the block callback
is no longer present when fl_hw_destroy_filter() calls
tc_setup_cb_call() and we have a dangling filter that can't be removed
from hardware anymore.
That is why filter must be added to hw_list where it is done now - in
fl_hw*() functions while holding rtnl lock to prevent concurrent
reoffload (block bind/unbind always take rtnl). I guess
marking/unmarking filters as HW_FILTER in exactly the same places where
it is inserted/removed from hw_list would also work.
> kfree(tb);
> tcf_queue_work(&mask->rwork, fl_uninit_mask_free_work);
> return 0;
> @@ -1770,37 +1768,14 @@ static void fl_walk(struct tcf_proto *tp, struct tcf_walker *arg,
> arg->cookie = id;
> }
>
> -static struct cls_fl_filter *
> -fl_get_next_hw_filter(struct tcf_proto *tp, struct cls_fl_filter *f, bool add)
> -{
> - struct cls_fl_head *head = fl_head_dereference(tp);
> -
> - spin_lock(&tp->lock);
> - if (list_empty(&head->hw_filters)) {
> - spin_unlock(&tp->lock);
> - return NULL;
> - }
> -
> - if (!f)
> - f = list_entry(&head->hw_filters, struct cls_fl_filter,
> - hw_list);
> - list_for_each_entry_continue(f, &head->hw_filters, hw_list) {
> - if (!(add && f->deleted) && refcount_inc_not_zero(&f->refcnt)) {
> - spin_unlock(&tp->lock);
> - return f;
> - }
> - }
> -
> - spin_unlock(&tp->lock);
> - return NULL;
> -}
> -
> static int fl_reoffload(struct tcf_proto *tp, bool add, flow_setup_cb_t *cb,
> void *cb_priv, struct netlink_ext_ack *extack)
> {
> + struct cls_fl_head *head = fl_head_dereference(tp);
> struct tcf_block *block = tp->chain->block;
> struct flow_cls_offload cls_flower = {};
> - struct cls_fl_filter *f = NULL;
> + struct cls_fl_filter *f;
> + unsigned long handle;
> int err;
>
> /* hw_filters list can only be changed by hw offload functions after
> @@ -1809,7 +1784,7 @@ static int fl_reoffload(struct tcf_proto *tp, bool add, flow_setup_cb_t *cb,
> */
> ASSERT_RTNL();
>
> - while ((f = fl_get_next_hw_filter(tp, f, add))) {
> + xa_for_each_marked(&head->filters, handle, f, HW_FILTER) {
> cls_flower.rule =
> flow_rule_alloc(tcf_exts_num_actions(&f->exts));
> if (!cls_flower.rule) {
^ permalink raw reply
* Re: [PATCH bpf-next 0/2] tools: bpftool: work with frozen maps
From: Daniel Borkmann @ 2019-08-21 19:19 UTC (permalink / raw)
To: Quentin Monnet, Alexei Starovoitov; +Cc: bpf, netdev, oss-drivers
In-Reply-To: <20190821085219.30387-1-quentin.monnet@netronome.com>
On 8/21/19 10:52 AM, Quentin Monnet wrote:
> Hi,
> This is a simple set to add support for BPF map freezing to bpftool. First
> patch makes bpftool indicate if a map is frozen when listing BPF maps.
> Second patch adds a command to freeze a map loaded on the system.
>
> Quentin Monnet (2):
> tools: bpftool: show frozen status for maps
> tools: bpftool: add "bpftool map freeze" subcommand
>
> .../bpf/bpftool/Documentation/bpftool-map.rst | 9 +++
> tools/bpf/bpftool/bash-completion/bpftool | 4 +-
> tools/bpf/bpftool/map.c | 64 +++++++++++++++++--
> 3 files changed, 71 insertions(+), 6 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [GIT PULL] Keys: Set 4 - Key ACLs for 5.3
From: David Howells @ 2019-08-21 19:22 UTC (permalink / raw)
To: Mimi Zohar
Cc: dhowells, Linus Torvalds, James Morris, keyrings, Netdev,
linux-nfs, CIFS, linux-afs, linux-fsdevel, linux-integrity,
LSM List, Linux List Kernel Mailing
In-Reply-To: <1566402203.5162.12.camel@linux.ibm.com>
I added a bunch of tests to the keyutils testsuite, currently on my -next
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/log/?h=next
See:
Add a keyctl command for granting a permit on a key
Handle kernel having key/keyring ACLs
I've added manpages to describe the new bits, but I wonder whether I should
add a manpage specifically to detail the permissions system. It'll probably
be useful when more advanced subjects become available, such as for specific
UIDs and for containers-as-a-whole.
David
^ permalink raw reply
* [PATCH] bpf: handle 32-bit zext during constant blinding
From: Naveen N. Rao @ 2019-08-21 19:23 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Jiong Wang
Cc: Michael Ellerman, bpf, linuxppc-dev, netdev, linux-kernel
Since BPF constant blinding is performed after the verifier pass, the
ALU32 instructions inserted for doubleword immediate loads don't have a
corresponding zext instruction. This is causing a kernel oops on powerpc
and can be reproduced by running 'test_cgroup_storage' with
bpf_jit_harden=2.
Fix this by emitting BPF_ZEXT during constant blinding if
prog->aux->verifier_zext is set.
Fixes: a4b1d3c1ddf6cb ("bpf: verifier: insert zero extension according to analysis result")
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
Changes since RFC:
- Removed changes to ALU32 and JMP32 ops since those don't alter program
execution, and the verifier would have already accounted for them.
kernel/bpf/core.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 8191a7db2777..66088a9e9b9e 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -890,7 +890,8 @@ int bpf_jit_get_func_addr(const struct bpf_prog *prog,
static int bpf_jit_blind_insn(const struct bpf_insn *from,
const struct bpf_insn *aux,
- struct bpf_insn *to_buff)
+ struct bpf_insn *to_buff,
+ bool emit_zext)
{
struct bpf_insn *to = to_buff;
u32 imm_rnd = get_random_int();
@@ -1005,6 +1006,8 @@ static int bpf_jit_blind_insn(const struct bpf_insn *from,
case 0: /* Part 2 of BPF_LD | BPF_IMM | BPF_DW. */
*to++ = BPF_ALU32_IMM(BPF_MOV, BPF_REG_AX, imm_rnd ^ aux[0].imm);
*to++ = BPF_ALU32_IMM(BPF_XOR, BPF_REG_AX, imm_rnd);
+ if (emit_zext)
+ *to++ = BPF_ZEXT_REG(BPF_REG_AX);
*to++ = BPF_ALU64_REG(BPF_OR, aux[0].dst_reg, BPF_REG_AX);
break;
@@ -1088,7 +1091,8 @@ struct bpf_prog *bpf_jit_blind_constants(struct bpf_prog *prog)
insn[1].code == 0)
memcpy(aux, insn, sizeof(aux));
- rewritten = bpf_jit_blind_insn(insn, aux, insn_buff);
+ rewritten = bpf_jit_blind_insn(insn, aux, insn_buff,
+ clone->aux->verifier_zext);
if (!rewritten)
continue;
--
2.22.0
^ permalink raw reply related
* Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
From: Alexei Starovoitov @ 2019-08-21 19:26 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Stephen Hemminger, Daniel Borkmann, Alexei Starovoitov,
Martin KaFai Lau, Song Liu, Yonghong Song, David Miller,
Jesper Dangaard Brouer, netdev, bpf
In-Reply-To: <20190820114706.18546-1-toke@redhat.com>
On Tue, Aug 20, 2019 at 01:47:01PM +0200, Toke Høiland-Jørgensen wrote:
> iproute2 uses its own bpf loader to load eBPF programs, which has
> evolved separately from libbpf. Since we are now standardising on
> libbpf, this becomes a problem as iproute2 is slowly accumulating
> feature incompatibilities with libbpf-based loaders. In particular,
> iproute2 has its own (expanded) version of the map definition struct,
> which makes it difficult to write programs that can be loaded with both
> custom loaders and iproute2.
>
> This series seeks to address this by converting iproute2 to using libbpf
> for all its bpf needs. This version is an early proof-of-concept RFC, to
> get some feedback on whether people think this is the right direction.
>
> What this series does is the following:
>
> - Updates the libbpf map definition struct to match that of iproute2
> (patch 1).
> - Adds functionality to libbpf to support automatic pinning of maps when
> loading an eBPF program, while re-using pinned maps if they already
> exist (patches 2-3).
> - Modifies iproute2 to make it possible to compile it against libbpf
> without affecting any existing functionality (patch 4).
> - Changes the iproute2 eBPF loader to use libbpf for loading XDP
> programs (patch 5).
>
>
> As this is an early PoC, there are still a few missing pieces before
> this can be merged. Including (but probably not limited to):
>
> - Consolidate the map definition struct in the bpf_helpers.h file in the
> kernel tree. This contains a different, and incompatible, update to
> the struct. Since the iproute2 version has actually been released for
> use outside the kernel tree (and thus is subject to API stability
> constraints), I think it makes the most sense to keep that, and port
> the selftests to use it.
It sounds like you're implying that existing libbpf format is not uapi.
It is and we cannot break it.
If patch 1 means breakage for existing pre-compiled .o that won't load
with new libbpf then we cannot use this method.
Recompiling .o with new libbpf definition of bpf_map_def isn't an option.
libbpf has to be smart before/after and recognize both old and iproute2 format.
^ permalink raw reply
* [PATCH] can: Delete unnecessary checks before the macro call “dev_kfree_skb”
From: Markus Elfring @ 2019-08-21 19:30 UTC (permalink / raw)
To: linux-can, netdev, Allison Randal, David S. Miller,
Enrico Weigelt, Greg Kroah-Hartman, Gustavo A. R. Silva,
Lukas Wunner, Marc Kleine-Budde, Sean Nyekjaer, Thomas Gleixner,
Weitao Hou, Wolfgang Grandegger
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 21 Aug 2019 21:16:15 +0200
The dev_kfree_skb() function performs also input parameter validation.
Thus the test around the shown calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/can/spi/hi311x.c | 3 +--
drivers/net/can/spi/mcp251x.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c
index 03a711c3221b..7c7c7e78214c 100644
--- a/drivers/net/can/spi/hi311x.c
+++ b/drivers/net/can/spi/hi311x.c
@@ -184,8 +184,7 @@ static void hi3110_clean(struct net_device *net)
if (priv->tx_skb || priv->tx_len)
net->stats.tx_errors++;
- if (priv->tx_skb)
- dev_kfree_skb(priv->tx_skb);
+ dev_kfree_skb(priv->tx_skb);
if (priv->tx_len)
can_free_echo_skb(priv->net, 0);
priv->tx_skb = NULL;
diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index 12358f06d194..1c496d2adb45 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -274,8 +274,7 @@ static void mcp251x_clean(struct net_device *net)
if (priv->tx_skb || priv->tx_len)
net->stats.tx_errors++;
- if (priv->tx_skb)
- dev_kfree_skb(priv->tx_skb);
+ dev_kfree_skb(priv->tx_skb);
if (priv->tx_len)
can_free_echo_skb(priv->net, 0);
priv->tx_skb = NULL;
--
2.23.0
^ permalink raw reply related
* Re: [PATCH 33/38] act_api: Convert action_idr to XArray
From: Vlad Buslov @ 2019-08-21 19:41 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190820223259.22348-34-willy@infradead.org>
On Wed 21 Aug 2019 at 01:32, Matthew Wilcox <willy@infradead.org> wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Replace the mutex protecting the IDR with the XArray spinlock.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> include/net/act_api.h | 6 +-
> net/sched/act_api.c | 127 +++++++++++++++++-------------------------
> 2 files changed, 53 insertions(+), 80 deletions(-)
>
> diff --git a/include/net/act_api.h b/include/net/act_api.h
[...]
> @@ -290,10 +283,8 @@ static int tcf_del_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
> struct nlattr *nest;
> int n_i = 0;
> int ret = -EINVAL;
> - struct idr *idr = &idrinfo->action_idr;
> struct tc_action *p;
> - unsigned long id = 1;
> - unsigned long tmp;
> + unsigned long index;
>
> nest = nla_nest_start_noflag(skb, 0);
> if (nest == NULL)
> @@ -301,18 +292,18 @@ static int tcf_del_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
> if (nla_put_string(skb, TCA_KIND, ops->kind))
> goto nla_put_failure;
>
> - mutex_lock(&idrinfo->lock);
> - idr_for_each_entry_ul(idr, p, tmp, id) {
> + xa_lock(&idrinfo->actions);
> + xa_for_each(&idrinfo->actions, index, p) {
> ret = tcf_idr_release_unsafe(p);
I like the simplification of reusing builtin xarray spinlock for this,
but the reason we are using mutex here is because the following call
chain: tcf_idr_release_unsafe() -> tcf_action_cleanup() -> free_tcf() ->
tcf_chain_put_by_act() -> __tcf_chain_put() -> mutex_lock(&block->lock);
^ permalink raw reply
* RE: net: micrel: confusion about phyids used in driver
From: Woojung.Huh @ 2019-08-21 19:53 UTC (permalink / raw)
To: Allan.Nielsen, f.fainelli
Cc: u.kleine-koenig, Nicolas.Ferre, netdev, andrew, kernel,
hkallweit1, Ravi.Hegde, Tristram.Ha, Yuiko.Oshino
In-Reply-To: <20190821184947.43iilefgrjn4zrtl@lx-anielsen.microsemi.net>
Hi Allan & Florian,
> > > So we're in need of someone who can get their hands on some more
> > > detailed documentation than publicly available to allow to make the
> > > driver handle the KSZ8051MLL correctly without breaking other stuff.
> > >
> > > I assume you are in a different department of Microchip than the people
> > > caring for PHYs, but maybe you can still help finding someone who cares?
> >
> > Allan, is this something you could help with? Thanks!
> Sorry, I'm new in Microchip (was aquired through Microsemi), and I know next to
> nothing about the Micrel stuff.
>
> Woojung: Can you comment on this, or try to direct this to someone who knows
> something...
Forwarded to Yuiko. Will do follow-up.
Thanks.
Woojung
^ permalink raw reply
* Re: [PATCH net-next 0/7] mlxsw: Add devlink-trap support
From: David Miller @ 2019-08-21 19:59 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, dsahern, mlxsw, idosch
In-Reply-To: <20190821071937.13622-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Wed, 21 Aug 2019 10:19:30 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> This patchset adds devlink-trap support in mlxsw.
>
> Patches #1-#4 add the necessary APIs and defines in mlxsw.
>
> Patch #5 implements devlink-trap support for layer 2 drops. More drops
> will be added in the future.
>
> Patches #6-#7 add selftests to make sure that all the new code paths are
> exercised and that the feature is working as expected.
Series applied, although that rate should really be configurable somehow.
10Kpps seems quite arbitrary...
^ permalink raw reply
* [PATCH] hamradio: Delete unnecessary checks before the macro call “dev_kfree_skb”
From: Markus Elfring @ 2019-08-21 20:00 UTC (permalink / raw)
To: linux-hams, netdev, Allison Randal, David S. Miller,
Greg Kroah-Hartman, Kate Stewart, Richard Fontana,
Thomas Gleixner, Thomas Sailer
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 21 Aug 2019 21:48:46 +0200
The dev_kfree_skb() function performs also input parameter validation.
Thus the test around the shown calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/hamradio/baycom_epp.c | 3 +--
drivers/net/hamradio/hdlcdrv.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c
index 9303aeb2595f..4476491b58f9 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -961,8 +961,7 @@ static int epp_close(struct net_device *dev)
parport_write_control(pp, 0); /* reset the adapter */
parport_release(bc->pdev);
parport_unregister_device(bc->pdev);
- if (bc->skb)
- dev_kfree_skb(bc->skb);
+ dev_kfree_skb(bc->skb);
bc->skb = NULL;
printk(KERN_INFO "%s: close epp at iobase 0x%lx irq %u\n",
bc_drvname, dev->base_addr, dev->irq);
diff --git a/drivers/net/hamradio/hdlcdrv.c b/drivers/net/hamradio/hdlcdrv.c
index c6f83e0df0a3..df495b5595f5 100644
--- a/drivers/net/hamradio/hdlcdrv.c
+++ b/drivers/net/hamradio/hdlcdrv.c
@@ -475,8 +475,7 @@ static int hdlcdrv_close(struct net_device *dev)
if (s->ops && s->ops->close)
i = s->ops->close(dev);
- if (s->skb)
- dev_kfree_skb(s->skb);
+ dev_kfree_skb(s->skb);
s->skb = NULL;
s->opened = 0;
return i;
--
2.23.0
^ permalink raw reply related
* Re: pull-request: mac80211 2019-08-21
From: David Miller @ 2019-08-21 20:01 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190821100005.13393-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 21 Aug 2019 12:00:03 +0200
> I have here for you a few fixes; three, to be specific. Nothing that
> warrants real discussion or urgency though.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: pull-request: mac80211-next 2019-08-21
From: David Miller @ 2019-08-21 20:02 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190821100424.13682-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 21 Aug 2019 12:04:23 +0200
> For -next, we have more changes, but as described in the tag
> they really just fall into a few groups of changes :-)
>
> Please pull and let me know if there's any problem.
Also pulled, thanks.
^ permalink raw reply
* Re: [PATCH] trivial: netns: fix typo in 'struct net.passive' description
From: David Miller @ 2019-08-21 20:08 UTC (permalink / raw)
To: rppt; +Cc: netdev
In-Reply-To: <1566386969-6813-1-git-send-email-rppt@linux.ibm.com>
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Wed, 21 Aug 2019 14:29:29 +0300
> Replace 'decided' with 'decide' so that comment would be
>
> /* To decide when the network namespace should be freed. */
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Applied.
^ permalink raw reply
* [net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2019-08-21
From: Jeff Kirsher @ 2019-08-21 20:16 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to i40e driver only.
Arnd Bergmann reduces the stack usage which was causing warnings on
32-bit architectures due to large structure sizes for 2 functions
getting inlined, so use noinline_for_stack to prevent the compilers from
combining the 2 functions.
Mauro S. M. Rodrigues fixes an issue when reading an EEPROM from SFP
modules that comply with SFF-8472 but do not implement the Digital
Diagnostic Monitoring (DDM) interface for i40e.
Huhai found we were not checking the return value for configuring the
transmit ring and continuing with XDP configuration of the transmit
ring.
Beilei fixes an issue of shifting signed 32-bit integers.
Sylwia adds support for "packet drop mode" to the MAC configuration for
admin queue command. This bit controls the behavior when a no-drop
packet is blocking a TC queue. Adds support for persistent LLDP by
checking the LLDP flag and reading the LLDP from the NVM when enabled.
Adrian fixes the "recovery mode" check to take into account which device
we are on, since x710 devices have 4 register values to check for status
and x722 devices only have 2 register values to check.
Piotr Azarewicz bumps the supported firmware API version to 1.9 which
extends the PHY access admin queue command support.
Jake makes sure the traffic class stats for a VEB are reset when the VEB
stats are reset.
Slawomir fixes a NULL pointer dereference where the VSI pointer was not
updated before passing it to the i40e_set_vf_mac() when the VF is in a
reset state, so wait for the reset to complete.
Grzegorz removes the i40e_update_dcb_config() which was not using the
correct NVM reads, so call i40e_init_dcb() in its place to correctly
update the DCB configuration.
Piotr Kwapulinski expands the scope of i40e_set_mac_type() since this is
needed during probe to determine if we are in recovery mode. Fixed the
driver reset path when in recovery mode.
Marcin fixed an issue where we were breaking out of a loop too early
when trying to get the PHY capabilities.
The following are changes since commit 8c40f3b212a373be843a29db608b462af5c3ed5d:
Merge tag 'mlx5-updates-2019-08-15' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE
Adrian Podlawski (1):
i40e: check_recovery_mode had wrong if statement
Arnd Bergmann (1):
i40e: reduce stack usage in i40e_set_fc
Beilei Xing (1):
i40e: fix shifts of signed values
Grzegorz Siwik (1):
i40e: Remove function i40e_update_dcb_config()
Jacob Keller (1):
i40e: reset veb.tc_stats when resetting veb.stats
Marcin Formela (1):
i40e: fix retrying in i40e_aq_get_phy_capabilities
Mauro S. M. Rodrigues (1):
i40e: Check if transceiver implements DDM before access
Piotr Azarewicz (2):
i40e: Update x710 FW API version to 1.9
i40e: Update x722 FW API version to 1.9
Piotr Kwapulinski (2):
i40e: make i40e_set_mac_type() public
i40e: allow reset in recovery mode
Slawomir Laba (1):
i40e: Fix crash caused by stress setting of VF MAC addresses
Sylwia Wnuczko (2):
i40e: Add drop mode parameter to set mac config
i40e: Persistent LLDP support
huhai (1):
i40e: add check on i40e_configure_tx_ring() return value
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 4 +-
.../net/ethernet/intel/i40e/i40e_adminq_cmd.h | 33 ++---
drivers/net/ethernet/intel/i40e/i40e_common.c | 110 +++++++-------
drivers/net/ethernet/intel/i40e/i40e_dcb.c | 18 ++-
drivers/net/ethernet/intel/i40e/i40e_dcb.h | 2 +
.../net/ethernet/intel/i40e/i40e_ethtool.c | 6 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 136 ++++++++++--------
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 101 +++++++++++++
.../net/ethernet/intel/i40e/i40e_prototype.h | 8 ++
.../net/ethernet/intel/i40e/i40e_register.h | 30 ++--
drivers/net/ethernet/intel/i40e/i40e_type.h | 3 +
.../ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 +-
12 files changed, 323 insertions(+), 135 deletions(-)
--
2.21.0
^ permalink raw reply
* [net-next 03/15] i40e: add check on i40e_configure_tx_ring() return value
From: Jeff Kirsher @ 2019-08-21 20:16 UTC (permalink / raw)
To: davem; +Cc: huhai, netdev, nhorman, sassmann, Andrew Bowers, Jeff Kirsher
In-Reply-To: <20190821201623.5506-1-jeffrey.t.kirsher@intel.com>
From: huhai <huhai@kylinos.cn>
When i40e_configure_tx_ring(vsi->tx_rings[i]) returns an error, we should
exit from i40e_vsi_configure_tx and return the error, instead of continuing
to check whether xdp is enable, and configure the xdp transmit ring.
Signed-off-by: huhai <huhai@kylinos.cn>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 6d456e579314..b807dd6b1417 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -3364,7 +3364,7 @@ static int i40e_vsi_configure_tx(struct i40e_vsi *vsi)
for (i = 0; (i < vsi->num_queue_pairs) && !err; i++)
err = i40e_configure_tx_ring(vsi->tx_rings[i]);
- if (!i40e_enabled_xdp_vsi(vsi))
+ if (err || !i40e_enabled_xdp_vsi(vsi))
return err;
for (i = 0; (i < vsi->num_queue_pairs) && !err; i++)
--
2.21.0
^ permalink raw reply related
* [net-next 04/15] i40e: fix shifts of signed values
From: Jeff Kirsher @ 2019-08-21 20:16 UTC (permalink / raw)
To: davem
Cc: Beilei Xing, netdev, nhorman, sassmann, Ferruh Yigit,
Andrew Bowers, Jeff Kirsher
In-Reply-To: <20190821201623.5506-1-jeffrey.t.kirsher@intel.com>
From: Beilei Xing <beilei.xing@intel.com>
This patch fixes following error reported by cppcheck:
(error) Shifting signed 32-bit value by 31 bits is undefined behaviour
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
.../net/ethernet/intel/i40e/i40e_register.h | 24 +++++++++----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_register.h b/drivers/net/ethernet/intel/i40e/i40e_register.h
index 52e3680c57f8..330ac19a5dae 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_register.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_register.h
@@ -58,7 +58,7 @@
#define I40E_PF_ARQLEN_ARQCRIT_SHIFT 30
#define I40E_PF_ARQLEN_ARQCRIT_MASK I40E_MASK(0x1, I40E_PF_ARQLEN_ARQCRIT_SHIFT)
#define I40E_PF_ARQLEN_ARQENABLE_SHIFT 31
-#define I40E_PF_ARQLEN_ARQENABLE_MASK I40E_MASK(0x1, I40E_PF_ARQLEN_ARQENABLE_SHIFT)
+#define I40E_PF_ARQLEN_ARQENABLE_MASK I40E_MASK(0x1u, I40E_PF_ARQLEN_ARQENABLE_SHIFT)
#define I40E_PF_ARQT 0x00080480 /* Reset: EMPR */
#define I40E_PF_ARQT_ARQT_SHIFT 0
#define I40E_PF_ARQT_ARQT_MASK I40E_MASK(0x3FF, I40E_PF_ARQT_ARQT_SHIFT)
@@ -81,7 +81,7 @@
#define I40E_PF_ATQLEN_ATQCRIT_SHIFT 30
#define I40E_PF_ATQLEN_ATQCRIT_MASK I40E_MASK(0x1, I40E_PF_ATQLEN_ATQCRIT_SHIFT)
#define I40E_PF_ATQLEN_ATQENABLE_SHIFT 31
-#define I40E_PF_ATQLEN_ATQENABLE_MASK I40E_MASK(0x1, I40E_PF_ATQLEN_ATQENABLE_SHIFT)
+#define I40E_PF_ATQLEN_ATQENABLE_MASK I40E_MASK(0x1u, I40E_PF_ATQLEN_ATQENABLE_SHIFT)
#define I40E_PF_ATQT 0x00080400 /* Reset: EMPR */
#define I40E_PF_ATQT_ATQT_SHIFT 0
#define I40E_PF_ATQT_ATQT_MASK I40E_MASK(0x3FF, I40E_PF_ATQT_ATQT_SHIFT)
@@ -108,7 +108,7 @@
#define I40E_VF_ARQLEN_ARQCRIT_SHIFT 30
#define I40E_VF_ARQLEN_ARQCRIT_MASK I40E_MASK(0x1, I40E_VF_ARQLEN_ARQCRIT_SHIFT)
#define I40E_VF_ARQLEN_ARQENABLE_SHIFT 31
-#define I40E_VF_ARQLEN_ARQENABLE_MASK I40E_MASK(0x1, I40E_VF_ARQLEN_ARQENABLE_SHIFT)
+#define I40E_VF_ARQLEN_ARQENABLE_MASK I40E_MASK(0x1u, I40E_VF_ARQLEN_ARQENABLE_SHIFT)
#define I40E_VF_ARQT(_VF) (0x00082C00 + ((_VF) * 4)) /* _i=0...127 */ /* Reset: EMPR */
#define I40E_VF_ARQT_MAX_INDEX 127
#define I40E_VF_ARQT_ARQT_SHIFT 0
@@ -136,7 +136,7 @@
#define I40E_VF_ATQLEN_ATQCRIT_SHIFT 30
#define I40E_VF_ATQLEN_ATQCRIT_MASK I40E_MASK(0x1, I40E_VF_ATQLEN_ATQCRIT_SHIFT)
#define I40E_VF_ATQLEN_ATQENABLE_SHIFT 31
-#define I40E_VF_ATQLEN_ATQENABLE_MASK I40E_MASK(0x1, I40E_VF_ATQLEN_ATQENABLE_SHIFT)
+#define I40E_VF_ATQLEN_ATQENABLE_MASK I40E_MASK(0x1u, I40E_VF_ATQLEN_ATQENABLE_SHIFT)
#define I40E_VF_ATQT(_VF) (0x00082800 + ((_VF) * 4)) /* _i=0...127 */ /* Reset: EMPR */
#define I40E_VF_ATQT_MAX_INDEX 127
#define I40E_VF_ATQT_ATQT_SHIFT 0
@@ -259,7 +259,7 @@
#define I40E_PRTDCB_RETSTCC_UPINTC_MODE_SHIFT 30
#define I40E_PRTDCB_RETSTCC_UPINTC_MODE_MASK I40E_MASK(0x1, I40E_PRTDCB_RETSTCC_UPINTC_MODE_SHIFT)
#define I40E_PRTDCB_RETSTCC_ETSTC_SHIFT 31
-#define I40E_PRTDCB_RETSTCC_ETSTC_MASK I40E_MASK(0x1, I40E_PRTDCB_RETSTCC_ETSTC_SHIFT)
+#define I40E_PRTDCB_RETSTCC_ETSTC_MASK I40E_MASK(0x1u, I40E_PRTDCB_RETSTCC_ETSTC_SHIFT)
#define I40E_PRTDCB_RPPMC 0x001223A0 /* Reset: CORER */
#define I40E_PRTDCB_RPPMC_LANRPPM_SHIFT 0
#define I40E_PRTDCB_RPPMC_LANRPPM_MASK I40E_MASK(0xFF, I40E_PRTDCB_RPPMC_LANRPPM_SHIFT)
@@ -503,7 +503,7 @@
#define I40E_GLGEN_MSCA_MDICMD_SHIFT 30
#define I40E_GLGEN_MSCA_MDICMD_MASK I40E_MASK(0x1, I40E_GLGEN_MSCA_MDICMD_SHIFT)
#define I40E_GLGEN_MSCA_MDIINPROGEN_SHIFT 31
-#define I40E_GLGEN_MSCA_MDIINPROGEN_MASK I40E_MASK(0x1, I40E_GLGEN_MSCA_MDIINPROGEN_SHIFT)
+#define I40E_GLGEN_MSCA_MDIINPROGEN_MASK I40E_MASK(0x1u, I40E_GLGEN_MSCA_MDIINPROGEN_SHIFT)
#define I40E_GLGEN_MSRWD(_i) (0x0008819C + ((_i) * 4)) /* _i=0...3 */ /* Reset: POR */
#define I40E_GLGEN_MSRWD_MAX_INDEX 3
#define I40E_GLGEN_MSRWD_MDIWRDATA_SHIFT 0
@@ -1242,14 +1242,14 @@
#define I40E_GLLAN_TXPRE_QDIS_SET_QDIS_SHIFT 30
#define I40E_GLLAN_TXPRE_QDIS_SET_QDIS_MASK I40E_MASK(0x1, I40E_GLLAN_TXPRE_QDIS_SET_QDIS_SHIFT)
#define I40E_GLLAN_TXPRE_QDIS_CLEAR_QDIS_SHIFT 31
-#define I40E_GLLAN_TXPRE_QDIS_CLEAR_QDIS_MASK I40E_MASK(0x1, I40E_GLLAN_TXPRE_QDIS_CLEAR_QDIS_SHIFT)
+#define I40E_GLLAN_TXPRE_QDIS_CLEAR_QDIS_MASK I40E_MASK(0x1u, I40E_GLLAN_TXPRE_QDIS_CLEAR_QDIS_SHIFT)
#define I40E_PFLAN_QALLOC 0x001C0400 /* Reset: CORER */
#define I40E_PFLAN_QALLOC_FIRSTQ_SHIFT 0
#define I40E_PFLAN_QALLOC_FIRSTQ_MASK I40E_MASK(0x7FF, I40E_PFLAN_QALLOC_FIRSTQ_SHIFT)
#define I40E_PFLAN_QALLOC_LASTQ_SHIFT 16
#define I40E_PFLAN_QALLOC_LASTQ_MASK I40E_MASK(0x7FF, I40E_PFLAN_QALLOC_LASTQ_SHIFT)
#define I40E_PFLAN_QALLOC_VALID_SHIFT 31
-#define I40E_PFLAN_QALLOC_VALID_MASK I40E_MASK(0x1, I40E_PFLAN_QALLOC_VALID_SHIFT)
+#define I40E_PFLAN_QALLOC_VALID_MASK I40E_MASK(0x1u, I40E_PFLAN_QALLOC_VALID_SHIFT)
#define I40E_QRX_ENA(_Q) (0x00120000 + ((_Q) * 4)) /* _i=0...1535 */ /* Reset: PFR */
#define I40E_QRX_ENA_MAX_INDEX 1535
#define I40E_QRX_ENA_QENA_REQ_SHIFT 0
@@ -1658,7 +1658,7 @@
#define I40E_GLNVM_SRCTL_START_SHIFT 30
#define I40E_GLNVM_SRCTL_START_MASK I40E_MASK(0x1, I40E_GLNVM_SRCTL_START_SHIFT)
#define I40E_GLNVM_SRCTL_DONE_SHIFT 31
-#define I40E_GLNVM_SRCTL_DONE_MASK I40E_MASK(0x1, I40E_GLNVM_SRCTL_DONE_SHIFT)
+#define I40E_GLNVM_SRCTL_DONE_MASK I40E_MASK(0x1u, I40E_GLNVM_SRCTL_DONE_SHIFT)
#define I40E_GLNVM_SRDATA 0x000B6114 /* Reset: POR */
#define I40E_GLNVM_SRDATA_WRDATA_SHIFT 0
#define I40E_GLNVM_SRDATA_WRDATA_MASK I40E_MASK(0xFFFF, I40E_GLNVM_SRDATA_WRDATA_SHIFT)
@@ -3025,7 +3025,7 @@
#define I40E_PF_VT_PFALLOC_LASTVF_SHIFT 8
#define I40E_PF_VT_PFALLOC_LASTVF_MASK I40E_MASK(0xFF, I40E_PF_VT_PFALLOC_LASTVF_SHIFT)
#define I40E_PF_VT_PFALLOC_VALID_SHIFT 31
-#define I40E_PF_VT_PFALLOC_VALID_MASK I40E_MASK(0x1, I40E_PF_VT_PFALLOC_VALID_SHIFT)
+#define I40E_PF_VT_PFALLOC_VALID_MASK I40E_MASK(0x1u, I40E_PF_VT_PFALLOC_VALID_SHIFT)
#define I40E_VP_MDET_RX(_VF) (0x0012A000 + ((_VF) * 4)) /* _i=0...127 */ /* Reset: CORER */
#define I40E_VP_MDET_RX_MAX_INDEX 127
#define I40E_VP_MDET_RX_VALID_SHIFT 0
@@ -3161,7 +3161,7 @@
#define I40E_VF_ARQLEN1_ARQCRIT_SHIFT 30
#define I40E_VF_ARQLEN1_ARQCRIT_MASK I40E_MASK(0x1, I40E_VF_ARQLEN1_ARQCRIT_SHIFT)
#define I40E_VF_ARQLEN1_ARQENABLE_SHIFT 31
-#define I40E_VF_ARQLEN1_ARQENABLE_MASK I40E_MASK(0x1, I40E_VF_ARQLEN1_ARQENABLE_SHIFT)
+#define I40E_VF_ARQLEN1_ARQENABLE_MASK I40E_MASK(0x1u, I40E_VF_ARQLEN1_ARQENABLE_SHIFT)
#define I40E_VF_ARQT1 0x00007000 /* Reset: EMPR */
#define I40E_VF_ARQT1_ARQT_SHIFT 0
#define I40E_VF_ARQT1_ARQT_MASK I40E_MASK(0x3FF, I40E_VF_ARQT1_ARQT_SHIFT)
@@ -3184,7 +3184,7 @@
#define I40E_VF_ATQLEN1_ATQCRIT_SHIFT 30
#define I40E_VF_ATQLEN1_ATQCRIT_MASK I40E_MASK(0x1, I40E_VF_ATQLEN1_ATQCRIT_SHIFT)
#define I40E_VF_ATQLEN1_ATQENABLE_SHIFT 31
-#define I40E_VF_ATQLEN1_ATQENABLE_MASK I40E_MASK(0x1, I40E_VF_ATQLEN1_ATQENABLE_SHIFT)
+#define I40E_VF_ATQLEN1_ATQENABLE_MASK I40E_MASK(0x1u, I40E_VF_ATQLEN1_ATQENABLE_SHIFT)
#define I40E_VF_ATQT1 0x00008400 /* Reset: EMPR */
#define I40E_VF_ATQT1_ATQT_SHIFT 0
#define I40E_VF_ATQT1_ATQT_MASK I40E_MASK(0x3FF, I40E_VF_ATQT1_ATQT_SHIFT)
--
2.21.0
^ permalink raw reply related
* [net-next 07/15] i40e: Update x710 FW API version to 1.9
From: Jeff Kirsher @ 2019-08-21 20:16 UTC (permalink / raw)
To: davem
Cc: Piotr Azarewicz, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190821201623.5506-1-jeffrey.t.kirsher@intel.com>
From: Piotr Azarewicz <piotr.azarewicz@intel.com>
Upcoming x710 FW increment API version to 1.9 due to Extend PHY access AQ
command support. SW is ready for that support as well.
Signed-off-by: Piotr Azarewicz <piotr.azarewicz@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
index 4d966d80305f..360f0cb83b2d 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
@@ -12,7 +12,7 @@
#define I40E_FW_API_VERSION_MAJOR 0x0001
#define I40E_FW_API_VERSION_MINOR_X722 0x0008
-#define I40E_FW_API_VERSION_MINOR_X710 0x0008
+#define I40E_FW_API_VERSION_MINOR_X710 0x0009
#define I40E_FW_MINOR_VERSION(_h) ((_h)->mac.type == I40E_MAC_XL710 ? \
I40E_FW_API_VERSION_MINOR_X710 : \
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox