* [PATCH v4 1/2] PTP: introduce new versions of IOCTLs
From: Felipe Balbi @ 2019-09-11 6:16 UTC (permalink / raw)
To: Richard Cochran; +Cc: Christopher S Hall, netdev, linux-kernel, Felipe Balbi
The current version of the IOCTL have a small problem which prevents us
from extending the API by making use of reserved fields. In these new
IOCTLs, we are now making sure that flags and rsv fields are zero which
will allow us to extend the API in the future.
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
---
Changes since v3:
- Remove bogus bitwise negation
Changes since v2:
- Define PTP_{PEROUT,EXTTS}_VALID_FLAGS
- Fix comment above PTP_*_FLAGS
Changes since v1:
- Add a blank line after memset()
- Move memset(req) to the three places where it's needed
- Fix the accidental removal of GETFUNC and SETFUNC
drivers/ptp/ptp_chardev.c | 63 ++++++++++++++++++++++++++++++++++
include/uapi/linux/ptp_clock.h | 24 ++++++++++++-
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
index 18ffe449efdf..9c18476d8d10 100644
--- a/drivers/ptp/ptp_chardev.c
+++ b/drivers/ptp/ptp_chardev.c
@@ -126,7 +126,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
switch (cmd) {
case PTP_CLOCK_GETCAPS:
+ case PTP_CLOCK_GETCAPS2:
memset(&caps, 0, sizeof(caps));
+
caps.max_adj = ptp->info->max_adj;
caps.n_alarm = ptp->info->n_alarm;
caps.n_ext_ts = ptp->info->n_ext_ts;
@@ -139,11 +141,24 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_EXTTS_REQUEST:
+ case PTP_EXTTS_REQUEST2:
+ memset(&req, 0, sizeof(req));
+
if (copy_from_user(&req.extts, (void __user *)arg,
sizeof(req.extts))) {
err = -EFAULT;
break;
}
+ if (((req.extts.flags & ~PTP_EXTTS_VALID_FLAGS) ||
+ req.extts.rsv[0] || req.extts.rsv[1]) &&
+ cmd == PTP_EXTTS_REQUEST2) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_EXTTS_REQUEST) {
+ req.extts.flags &= ~PTP_EXTTS_VALID_FLAGS;
+ req.extts.rsv[0] = 0;
+ req.extts.rsv[1] = 0;
+ }
if (req.extts.index >= ops->n_ext_ts) {
err = -EINVAL;
break;
@@ -154,11 +169,27 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_PEROUT_REQUEST:
+ case PTP_PEROUT_REQUEST2:
+ memset(&req, 0, sizeof(req));
+
if (copy_from_user(&req.perout, (void __user *)arg,
sizeof(req.perout))) {
err = -EFAULT;
break;
}
+ if (((req.perout.flags & ~PTP_PEROUT_VALID_FLAGS) ||
+ req.perout.rsv[0] || req.perout.rsv[1] ||
+ req.perout.rsv[2] || req.perout.rsv[3]) &&
+ cmd == PTP_PEROUT_REQUEST2) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_PEROUT_REQUEST) {
+ req.perout.flags &= ~PTP_PEROUT_VALID_FLAGS;
+ req.perout.rsv[0] = 0;
+ req.perout.rsv[1] = 0;
+ req.perout.rsv[2] = 0;
+ req.perout.rsv[3] = 0;
+ }
if (req.perout.index >= ops->n_per_out) {
err = -EINVAL;
break;
@@ -169,6 +200,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_ENABLE_PPS:
+ case PTP_ENABLE_PPS2:
+ memset(&req, 0, sizeof(req));
+
if (!capable(CAP_SYS_TIME))
return -EPERM;
req.type = PTP_CLK_REQ_PPS;
@@ -177,6 +211,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_SYS_OFFSET_PRECISE:
+ case PTP_SYS_OFFSET_PRECISE2:
if (!ptp->info->getcrosststamp) {
err = -EOPNOTSUPP;
break;
@@ -201,6 +236,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_SYS_OFFSET_EXTENDED:
+ case PTP_SYS_OFFSET_EXTENDED2:
if (!ptp->info->gettimex64) {
err = -EOPNOTSUPP;
break;
@@ -232,6 +268,7 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_SYS_OFFSET:
+ case PTP_SYS_OFFSET2:
sysoff = memdup_user((void __user *)arg, sizeof(*sysoff));
if (IS_ERR(sysoff)) {
err = PTR_ERR(sysoff);
@@ -266,10 +303,23 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_PIN_GETFUNC:
+ case PTP_PIN_GETFUNC2:
if (copy_from_user(&pd, (void __user *)arg, sizeof(pd))) {
err = -EFAULT;
break;
}
+ if ((pd.rsv[0] || pd.rsv[1] || pd.rsv[2]
+ || pd.rsv[3] || pd.rsv[4])
+ && cmd == PTP_PIN_GETFUNC2) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_PIN_GETFUNC) {
+ pd.rsv[0] = 0;
+ pd.rsv[1] = 0;
+ pd.rsv[2] = 0;
+ pd.rsv[3] = 0;
+ pd.rsv[4] = 0;
+ }
pin_index = pd.index;
if (pin_index >= ops->n_pins) {
err = -EINVAL;
@@ -285,10 +335,23 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd, unsigned long arg)
break;
case PTP_PIN_SETFUNC:
+ case PTP_PIN_SETFUNC2:
if (copy_from_user(&pd, (void __user *)arg, sizeof(pd))) {
err = -EFAULT;
break;
}
+ if ((pd.rsv[0] || pd.rsv[1] || pd.rsv[2]
+ || pd.rsv[3] || pd.rsv[4])
+ && cmd == PTP_PIN_SETFUNC2) {
+ err = -EINVAL;
+ break;
+ } else if (cmd == PTP_PIN_SETFUNC) {
+ pd.rsv[0] = 0;
+ pd.rsv[1] = 0;
+ pd.rsv[2] = 0;
+ pd.rsv[3] = 0;
+ pd.rsv[4] = 0;
+ }
pin_index = pd.index;
if (pin_index >= ops->n_pins) {
err = -EINVAL;
diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
index 1bc794ad957a..9a0af3511b68 100644
--- a/include/uapi/linux/ptp_clock.h
+++ b/include/uapi/linux/ptp_clock.h
@@ -25,10 +25,20 @@
#include <linux/ioctl.h>
#include <linux/types.h>
-/* PTP_xxx bits, for the flags field within the request structures. */
+/*
+ * Bits of the ptp_extts_request.flags field:
+ */
#define PTP_ENABLE_FEATURE (1<<0)
#define PTP_RISING_EDGE (1<<1)
#define PTP_FALLING_EDGE (1<<2)
+#define PTP_EXTTS_VALID_FLAGS (PTP_ENABLE_FEATURE | \
+ PTP_RISING_EDGE | \
+ PTP_FALLING_EDGE)
+
+/*
+ * Bits of the ptp_perout_request.flags field:
+ */
+#define PTP_PEROUT_VALID_FLAGS (0)
/*
* struct ptp_clock_time - represents a time value
@@ -149,6 +159,18 @@ struct ptp_pin_desc {
#define PTP_SYS_OFFSET_EXTENDED \
_IOWR(PTP_CLK_MAGIC, 9, struct ptp_sys_offset_extended)
+#define PTP_CLOCK_GETCAPS2 _IOR(PTP_CLK_MAGIC, 10, struct ptp_clock_caps)
+#define PTP_EXTTS_REQUEST2 _IOW(PTP_CLK_MAGIC, 11, struct ptp_extts_request)
+#define PTP_PEROUT_REQUEST2 _IOW(PTP_CLK_MAGIC, 12, struct ptp_perout_request)
+#define PTP_ENABLE_PPS2 _IOW(PTP_CLK_MAGIC, 13, int)
+#define PTP_SYS_OFFSET2 _IOW(PTP_CLK_MAGIC, 14, struct ptp_sys_offset)
+#define PTP_PIN_GETFUNC2 _IOWR(PTP_CLK_MAGIC, 15, struct ptp_pin_desc)
+#define PTP_PIN_SETFUNC2 _IOW(PTP_CLK_MAGIC, 16, struct ptp_pin_desc)
+#define PTP_SYS_OFFSET_PRECISE2 \
+ _IOWR(PTP_CLK_MAGIC, 17, struct ptp_sys_offset_precise)
+#define PTP_SYS_OFFSET_EXTENDED2 \
+ _IOWR(PTP_CLK_MAGIC, 18, struct ptp_sys_offset_extended)
+
struct ptp_extts_event {
struct ptp_clock_time t; /* Time event occured. */
unsigned int index; /* Which channel produced the event. */
--
2.23.0
^ permalink raw reply related
* Re: [patch net-next v2 3/3] net: devlink: move reload fail indication to devlink core and expose to user
From: Jiri Pirko @ 2019-09-11 6:17 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev@vger.kernel.org, davem@davemloft.net, dsahern@gmail.com,
jakub.kicinski@netronome.com, Tariq Toukan, mlxsw
In-Reply-To: <20190908103928.GA21777@splinter>
Sun, Sep 08, 2019 at 12:39:32PM CEST, idosch@mellanox.com wrote:
>On Sat, Sep 07, 2019 at 10:54:00PM +0200, Jiri Pirko wrote:
>> diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
>> index 546e75dd74ac..7cb5e8c5ae0d 100644
>> --- a/include/uapi/linux/devlink.h
>> +++ b/include/uapi/linux/devlink.h
>> @@ -410,6 +410,8 @@ enum devlink_attr {
>> DEVLINK_ATTR_TRAP_METADATA, /* nested */
>> DEVLINK_ATTR_TRAP_GROUP_NAME, /* string */
>>
>> + DEVLINK_ATTR_RELOAD_FAILED, /* u8 0 or 1 */
>> +
>> /* add new attributes above here, update the policy in devlink.c */
>>
>> __DEVLINK_ATTR_MAX,
>> diff --git a/net/core/devlink.c b/net/core/devlink.c
>> index 1e3a2288b0b2..e00a4a643d17 100644
>> --- a/net/core/devlink.c
>> +++ b/net/core/devlink.c
>> @@ -471,6 +471,8 @@ static int devlink_nl_fill(struct sk_buff *msg, struct devlink *devlink,
>>
>> if (devlink_nl_put_handle(msg, devlink))
>> goto nla_put_failure;
>> + if (nla_put_u8(msg, DEVLINK_ATTR_RELOAD_FAILED, devlink->reload_failed))
>
>Why not use NLA_FLAG for this?
Bacause older kernel does not return this. So the user would not know if
everything is fine or if the kernel does not support the attribute.
Using u8 instead allows it.
>
>> + goto nla_put_failure;
>>
>> genlmsg_end(msg, hdr);
>> return 0;
>> @@ -2677,6 +2679,21 @@ static bool devlink_reload_supported(struct devlink *devlink)
>> return devlink->ops->reload_down && devlink->ops->reload_up;
>> }
^ permalink raw reply
* Re: [patch net-next v2 3/3] net: devlink: move reload fail indication to devlink core and expose to user
From: Jiri Pirko @ 2019-09-11 6:17 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev@vger.kernel.org, davem@davemloft.net, dsahern@gmail.com,
jakub.kicinski@netronome.com, Tariq Toukan, mlxsw
In-Reply-To: <20190908112534.GA27998@splinter>
Sun, Sep 08, 2019 at 01:25:36PM CEST, idosch@mellanox.com wrote:
>On Sat, Sep 07, 2019 at 10:54:00PM +0200, Jiri Pirko wrote:
>> +bool devlink_is_reload_failed(struct devlink *devlink)
>
>Forgot to mention that this can be 'const'
ok.
>
>> +{
>> + return devlink->reload_failed;
>> +}
>> +EXPORT_SYMBOL_GPL(devlink_is_reload_failed);
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
From: Shawn Guo @ 2019-09-11 6:33 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Mark Brown, linux-spi, lkml, devicetree, netdev, Rob Herring
In-Reply-To: <CA+h21hqMVdsUjBdtiHKtKGpyvuaOf25tc4h-GdDEBQqa3EB7tw@mail.gmail.com>
On Tue, Aug 27, 2019 at 09:16:39PM +0300, Vladimir Oltean wrote:
> On Tue, 27 Aug 2019 at 21:13, Mark Brown <broonie@kernel.org> wrote:
> >
> > On Tue, Aug 27, 2019 at 09:06:14PM +0300, Vladimir Oltean wrote:
> > > On Tue, 27 Aug 2019 at 21:05, Mark Brown <broonie@kernel.org> wrote:
> > > > On Mon, Aug 26, 2019 at 04:10:51PM +0300, Vladimir Oltean wrote:
> >
> > > > > I noticed you skipped applying this patch, and I'm not sure that Shawn
> > > > > will review it/take it.
> > > > > Do you have a better suggestion how I can achieve putting the DSPI
> > > > > driver in poll mode for this board? A Kconfig option maybe?
> >
> > > > DT changes go through the relevant platform trees, not the
> > > > subsystem trees, so it's not something I'd expect to apply.
> >
> > > But at least is it something that you expect to see done through a
> > > device tree change?
> >
> > Well, it's not ideal - if it performs better all the time the
> > driver should probably just do it unconditionally. If there's
> > some threashold where it tends to perform better then the driver
> > should check for that but IIRC it sounds like the interrupt just
> > isn't at all helpful here.
>
> I can't seem to find any situation where it performs worse. Hence my
> question on whether it's a better idea to condition this behavior on a
> Kconfig option rather than a DT blob which may or may not be in sync.
DT is a description of hardware not condition for software behavior,
where module parameter is usually used for.
Shawn
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
From: Geert Uytterhoeven @ 2019-09-11 7:00 UTC (permalink / raw)
To: Shawn Guo
Cc: Vladimir Oltean, Mark Brown, linux-spi, lkml,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
netdev, Rob Herring
In-Reply-To: <20190911063350.GB17142@dragon>
On Wed, Sep 11, 2019 at 8:34 AM Shawn Guo <shawnguo@kernel.org> wrote:
> On Tue, Aug 27, 2019 at 09:16:39PM +0300, Vladimir Oltean wrote:
> > On Tue, 27 Aug 2019 at 21:13, Mark Brown <broonie@kernel.org> wrote:
> > > On Tue, Aug 27, 2019 at 09:06:14PM +0300, Vladimir Oltean wrote:
> > > > On Tue, 27 Aug 2019 at 21:05, Mark Brown <broonie@kernel.org> wrote:
> > > > > On Mon, Aug 26, 2019 at 04:10:51PM +0300, Vladimir Oltean wrote:
> > >
> > > > > > I noticed you skipped applying this patch, and I'm not sure that Shawn
> > > > > > will review it/take it.
> > > > > > Do you have a better suggestion how I can achieve putting the DSPI
> > > > > > driver in poll mode for this board? A Kconfig option maybe?
> > >
> > > > > DT changes go through the relevant platform trees, not the
> > > > > subsystem trees, so it's not something I'd expect to apply.
> > >
> > > > But at least is it something that you expect to see done through a
> > > > device tree change?
> > >
> > > Well, it's not ideal - if it performs better all the time the
> > > driver should probably just do it unconditionally. If there's
> > > some threashold where it tends to perform better then the driver
> > > should check for that but IIRC it sounds like the interrupt just
> > > isn't at all helpful here.
> >
> > I can't seem to find any situation where it performs worse. Hence my
> > question on whether it's a better idea to condition this behavior on a
> > Kconfig option rather than a DT blob which may or may not be in sync.
>
> DT is a description of hardware not condition for software behavior,
> where module parameter is usually used for.
+1
DT says the interrupt line is wired.
The driver should know if it should make use of the interrupt, or not.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: ixgbe: driver drops packets routed from an IPSec interface with a "bad sa_idx" error
From: Shannon Nelson @ 2019-09-11 7:17 UTC (permalink / raw)
To: Steffen Klassert, Michael Marley; +Cc: netdev, Jeff Kirsher
In-Reply-To: <20190911061547.GR2879@gauss3.secunet.de>
On 9/10/19 11:15 PM, Steffen Klassert wrote:
> On Tue, Sep 10, 2019 at 06:53:30PM -0400, Michael Marley wrote:
>> StrongSwan has hardware offload disabled by default, and I didn't enable
>> it explicitly. I also already tried turning off all those switches with
>> ethtool and it has no effect. This doesn't surprise me though, because
>> as I said, I don't actually have the IPSec connection running over the
>> ixgbe device. The IPSec connection runs over another network adapter
>> that doesn't support IPSec offload at all. The problem comes when
>> traffic received over the IPSec interface is then routed back out
>> (unencrypted) through the ixgbe device into the local network.
>
> Seems like the ixgbe driver tries to use the sec_path
> from RX to setup an offload at the TX side.
>
> Can you please try this (completely untested) patch?
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 9bcae44e9883..ae31bd57127c 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -36,6 +36,7 @@
> #include <net/vxlan.h>
> #include <net/mpls.h>
> #include <net/xdp_sock.h>
> +#include <net/xfrm.h>
>
> #include "ixgbe.h"
> #include "ixgbe_common.h"
> @@ -8696,7 +8697,7 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
> #endif /* IXGBE_FCOE */
>
> #ifdef CONFIG_IXGBE_IPSEC
> - if (secpath_exists(skb) &&
> + if (xfrm_offload(skb) &&
> !ixgbe_ipsec_tx(tx_ring, first, &ipsec_tx))
> goto out_drop;
> #endif
Thanks, Steffen, that looks right to me.
sln
^ permalink raw reply
* Re: Q: fixed link
From: Ranran @ 2019-09-11 7:25 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190908090551.GC28580@lunn.ch>
On Sun, Sep 8, 2019 at 12:05 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Sun, Sep 08, 2019 at 10:30:51AM +0300, Ranran wrote:
> > Hello,
> >
> > In documentation of fixed-link it is said:"
> > Some Ethernet MACs have a "fixed link", and are not connected to a
> > normal MDIO-managed PHY device. For those situations, a Device Tree
> > binding allows to describe a "fixed link".
> > "
> > Does it mean, that on using unmanaged switch ("no cpu" mode), it is
> > better be used with fixed-link ?
>
> Hi Ranran
>
> Is there a MAC to MAC connection, or PHY to PHY connection?
>
> If the interface MAC is directly connected to the switch MAC, fixed
> link is what you should use. The fixed link will then tell the
> interface MAC what speed it should use.
>
> If you have back to back PHYs, you need a PHY driver for the PHY
> connected to the interface MAC, to configure its speed, duplex
> etc. The dumb switch should be controlling its PHY, and auto-neg will
> probably work.
>
> Andrew
Hi,
We are using RGMII mode with the switch, which probably means
mac-to-mac (as far as I understand).
Does it mean we can choose between these 2 options:
1. configure dsa switch in device tree
2. configure fixed link in device tree
Thanks,
ranran
^ permalink raw reply
* Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled
From: Yonghong Song @ 2019-09-11 7:42 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, Martin Lau,
Song Liu, netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, Toke Høiland-Jørgensen,
Björn Töpel
In-Reply-To: <20190910172253.GA164966@google.com>
On 9/10/19 6:22 PM, Sami Tolvanen wrote:
> On Tue, Sep 10, 2019 at 08:37:19AM +0000, Yonghong Song wrote:
>> You did not mention BPF_BINARY_HEADER_MAGIC and added member
>> of `magic` in bpf_binary_header. Could you add some details
>> on what is the purpose for this `magic` member?
>
> Sure, I'll add a description to the next version.
>
> The magic is a random number used to identify bpf_binary_header in
> memory. The purpose of this patch is to limit the possible call
> targets for the function pointer and checking for the magic helps
> ensure we are jumping to a page that contains a jited function,
> instead of allowing calls to arbitrary targets.
>
> This is particularly useful when combined with the compiler-based
> Control-Flow Integrity (CFI) mitigation, which Google started shipping
> in Pixel kernels last year. The compiler injects checks to all
> indirect calls, but cannot obviously validate jumps to dynamically
> generated code.
>
>>> +unsigned int bpf_call_func(const struct bpf_prog *prog, const void *ctx)
>>> +{
>>> + const struct bpf_binary_header *hdr = bpf_jit_binary_hdr(prog);
>>> +
>>> + if (!IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) && !prog->jited)
>>> + return prog->bpf_func(ctx, prog->insnsi);
>>> +
>>> + if (unlikely(hdr->magic != BPF_BINARY_HEADER_MAGIC ||
>>> + !arch_bpf_jit_check_func(prog))) {
>>> + WARN(1, "attempt to jump to an invalid address");
>>> + return 0;
>>> + }
>>> +
>>> + return prog->bpf_func(ctx, prog->insnsi);
>>> +}
>
>> The above can be rewritten as
>> if (IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) || prog->jited ||
>> hdr->magic != BPF_BINARY_HEADER_MAGIC ||
>> !arch_bpf_jit_check_func(prog))) {
>> WARN(1, "attempt to jump to an invalid address");
>> return 0;
>> }
>
> That doesn't look quite equivalent, but yes, this can be rewritten as a
Indeed, I made a mistake. Your below change is correct.
> single if statement like this:
>
> if ((IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) ||
> prog->jited) &&
> (hdr->magic != BPF_BINARY_HEADER_MAGIC ||
> !arch_bpf_jit_check_func(prog)))
>
> I think splitting the interpreter and JIT paths would be more readable,
> but I can certainly change this if you prefer.
How about this:
if (!IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) && !prog->jited)
goto out;
if (unlikely(hdr->magic != BPF_BINARY_HEADER_MAGIC ||
!arch_bpf_jit_check_func(prog))) {
WARN(1, "attempt to jump to an invalid address");
return 0;
}
out:
return prog->bpf_func(ctx, prog->insnsi);
>
>> BPF_PROG_RUN() will be called during xdp fast path.
>> Have you measured how much slowdown the above change could
>> cost for the performance?
>
> I have not measured the overhead, but it shouldn't be significant. Is
> there a particular benchmark you'd like me to run?
I am not an expert in XDP testing. Toke, Björn, could you give some
suggestions what to test for XDP performance here?
>
> Sami
>
^ permalink raw reply
* [PATCH 04/11] net: phylink: switch to using fwnode_gpiod_get_index()
From: Dmitry Torokhov @ 2019-09-11 7:52 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, Mika Westerberg, linux-kernel, linux-gpio,
Andrew Lunn, David S. Miller, Florian Fainelli, Heiner Kallweit,
Russell King, netdev
In-Reply-To: <20190911075215.78047-1-dmitry.torokhov@gmail.com>
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit
works with arbitrary firmware node.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/net/phy/phylink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index a45c5de96ab1..14b608991445 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -168,8 +168,8 @@ static int phylink_parse_fixedlink(struct phylink *pl,
pl->link_config.pause |= MLO_PAUSE_ASYM;
if (ret == 0) {
- desc = fwnode_get_named_gpiod(fixed_node, "link-gpios",
- 0, GPIOD_IN, "?");
+ desc = fwnode_gpiod_get_index(fixed_node, "link", 0,
+ GPIOD_IN, "?");
if (!IS_ERR(desc))
pl->link_gpio = desc;
--
2.23.0.162.g0b9fbb3734-goog
^ permalink raw reply related
* [PATCH 05/11] net: mdio: switch to using fwnode_gpiod_get_index()
From: Dmitry Torokhov @ 2019-09-11 7:52 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, Mika Westerberg, linux-kernel, linux-gpio,
Andrew Lunn, David S. Miller, Florian Fainelli, Heiner Kallweit,
netdev
In-Reply-To: <20190911075215.78047-1-dmitry.torokhov@gmail.com>
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit
works with arbitrary firmware node.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/net/phy/mdio_bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index ce940871331e..9ca51d678123 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -46,8 +46,8 @@ static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
/* Deassert the optional reset signal */
if (mdiodev->dev.of_node)
- gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
- "reset-gpios", 0, GPIOD_OUT_LOW,
+ gpiod = fwnode_gpiod_get_index(&mdiodev->dev.of_node->fwnode,
+ "reset", 0, GPIOD_OUT_LOW,
"PHY reset");
if (IS_ERR(gpiod)) {
if (PTR_ERR(gpiod) == -ENOENT || PTR_ERR(gpiod) == -ENOSYS)
--
2.23.0.162.g0b9fbb3734-goog
^ permalink raw reply related
* [PATCH 00/11] Add support for software nodes to gpiolib
From: Dmitry Torokhov @ 2019-09-11 7:52 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, Mika Westerberg, linux-kernel, linux-gpio,
Andrew Lunn, Andrzej Hajda, Bartosz Golaszewski, Daniel Vetter,
David Airlie, David S. Miller, Florian Fainelli, Heiner Kallweit,
Jernej Skrabec, Jonas Karlman, Laurent Pinchart, Neil Armstrong,
Russell King, dri-devel, linux-acpi, netdev
This series attempts to add support for software nodes to gpiolib, using
software node references that were introduced recently. This allows us
to convert more drivers to the generic device properties and drop
support for custom platform data:
static const struct software_node gpio_bank_b_node = {
|-------.name = "B",
};
static const struct property_entry simone_key_enter_props[] = {
|-------PROPERTY_ENTRY_U32("linux,code", KEY_ENTER),
|-------PROPERTY_ENTRY_STRING("label", "enter"),
|-------PROPERTY_ENTRY_REF("gpios", &gpio_bank_b_node, 123, GPIO_ACTIVE_LOW),
|-------{ }
};
If we agree in principle, I would like to have the very first 3 patches
in an immutable branch off maybe -rc8 so that it can be pulled into
individual subsystems so that patches switching various drivers to
fwnode_gpiod_get_index() could be applied.
Thanks,
Dmitry
Dmitry Torokhov (11):
gpiolib: of: add a fallback for wlf,reset GPIO name
gpiolib: introduce devm_fwnode_gpiod_get_index()
gpiolib: introduce fwnode_gpiod_get_index()
net: phylink: switch to using fwnode_gpiod_get_index()
net: mdio: switch to using fwnode_gpiod_get_index()
drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
gpliolib: make fwnode_get_named_gpiod() static
gpiolib: of: tease apart of_find_gpio()
gpiolib: of: tease apart acpi_find_gpio()
gpiolib: consolidate fwnode GPIO lookups
gpiolib: add support for software nodes
drivers/gpio/Makefile | 1 +
drivers/gpio/gpiolib-acpi.c | 153 ++++++++++++++----------
drivers/gpio/gpiolib-acpi.h | 21 ++--
drivers/gpio/gpiolib-devres.c | 33 ++----
drivers/gpio/gpiolib-of.c | 159 ++++++++++++++-----------
drivers/gpio/gpiolib-of.h | 26 ++--
drivers/gpio/gpiolib-swnode.c | 92 +++++++++++++++
drivers/gpio/gpiolib-swnode.h | 13 ++
drivers/gpio/gpiolib.c | 184 ++++++++++++++++-------------
drivers/gpu/drm/bridge/ti-tfp410.c | 4 +-
drivers/net/phy/mdio_bus.c | 4 +-
drivers/net/phy/phylink.c | 4 +-
include/linux/gpio/consumer.h | 53 ++++++---
13 files changed, 471 insertions(+), 276 deletions(-)
create mode 100644 drivers/gpio/gpiolib-swnode.c
create mode 100644 drivers/gpio/gpiolib-swnode.h
--
2.23.0.162.g0b9fbb3734-goog
^ permalink raw reply
* Re: [PATCH] net: Remove the source address setting in connect() for UDP
From: David Miller @ 2019-09-11 7:57 UTC (permalink / raw)
To: enkechen; +Cc: kuznet, yoshfuji, netdev, linux-kernel, xe-linux-external
In-Reply-To: <324B00C3-4526-4026-809B-299634E49368@cisco.com>
From: "Enke Chen (enkechen)" <enkechen@cisco.com>
Date: Tue, 10 Sep 2019 23:55:59 +0000
> Do you still have concerns about backward compatibility of the fix?
I'm not convinced by your arguments and I am also completely swamped at
LPC2019 running the networking track this week.
^ permalink raw reply
* Re: [PATCH V2 net-next 0/7] net: hns3: add a feature & bugfixes & cleanups
From: David Miller @ 2019-09-11 8:09 UTC (permalink / raw)
To: tanhuazhong
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski
In-Reply-To: <1568169639-43658-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Wed, 11 Sep 2019 10:40:32 +0800
> This patch-set includes a VF feature, bugfixes and cleanups for the HNS3
> ethernet controller driver.
Series applied.
^ permalink raw reply
* Re: [PATCH] wimax: i2400: fix memory leak
From: David Miller @ 2019-09-11 8:10 UTC (permalink / raw)
To: navid.emamdoost
Cc: emamd001, smccaman, kjlu, inaky.perez-gonzalez, linux-wimax,
netdev, linux-kernel
In-Reply-To: <20190910230210.19012-1-navid.emamdoost@gmail.com>
From: Navid Emamdoost <navid.emamdoost@gmail.com>
Date: Tue, 10 Sep 2019 18:01:40 -0500
> In i2400m_op_rfkill_sw_toggle cmd buffer should be released along with
> skb response.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Applied.
Good thing nobody uses wimax.
^ permalink raw reply
* [PATCH iproute2-next] rdma: Check comm string before print in print_comm()
From: Leon Romanovsky @ 2019-09-11 8:12 UTC (permalink / raw)
To: David Ahern
Cc: Mark Zhang, netdev, RDMA mailing list, Stephen Hemminger,
Leon Romanovsky
From: Mark Zhang <markz@mellanox.com>
Broken kernels (not-upstream) can provide wrong empty "comm" field.
It causes to segfault while printing in JSON format.
Fixes: 8ecac46a60ff ("rdma: Add QP resource tracking information")
Signed-off-by: Mark Zhang <markz@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/res.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/rdma/res.c b/rdma/res.c
index 97a7b964..6003006e 100644
--- a/rdma/res.c
+++ b/rdma/res.c
@@ -161,6 +161,9 @@ void print_comm(struct rd *rd, const char *str, struct nlattr **nla_line)
{
char tmp[18];
+ if (!str)
+ return;
+
if (rd->json_output) {
/* Don't beatify output in JSON format */
jsonw_string_field(rd->jw, "comm", str);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: qrtr: fix memort leak in qrtr_tun_write_iter
From: David Miller @ 2019-09-11 8:13 UTC (permalink / raw)
To: navid.emamdoost; +Cc: emamd001, smccaman, kjlu, netdev, linux-kernel
In-Reply-To: <20190911003748.26841-1-navid.emamdoost@gmail.com>
From: Navid Emamdoost <navid.emamdoost@gmail.com>
Date: Tue, 10 Sep 2019 19:37:45 -0500
> In qrtr_tun_write_iter the allocated kbuf should be release in case of
> error happening.
>
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Shouldn't it also be freed in case of success too?
^ permalink raw reply
* Re: [PATCH v2 net] net: sonic: replace dev_kfree_skb in sonic_send_packet
From: David Miller @ 2019-09-11 8:14 UTC (permalink / raw)
To: maowenan; +Cc: tsbogend, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20190911013623.36897-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Wed, 11 Sep 2019 09:36:23 +0800
> sonic_send_packet will be processed in irq or non-irq
> context, so it would better use dev_kfree_skb_any
> instead of dev_kfree_skb.
>
> Fixes: d9fb9f384292 ("*sonic/natsemi/ns83829: Move the National Semi-conductor drivers")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 5/5] sctp: add spt_pathcpthld in struct sctp_paddrthlds
From: Xin Long @ 2019-09-11 8:14 UTC (permalink / raw)
To: David Miller
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Neil Horman
In-Reply-To: <20190910.192755.717621354475214603.davem@davemloft.net>
On Wed, Sep 11, 2019 at 1:27 AM David Miller <davem@davemloft.net> wrote:
>
> From: Xin Long <lucien.xin@gmail.com>
> Date: Mon, 9 Sep 2019 15:56:51 +0800
>
> > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> > index a15cc28..dfd81e1 100644
> > --- a/include/uapi/linux/sctp.h
> > +++ b/include/uapi/linux/sctp.h
> > @@ -1069,6 +1069,7 @@ struct sctp_paddrthlds {
> > struct sockaddr_storage spt_address;
> > __u16 spt_pathmaxrxt;
> > __u16 spt_pathpfthld;
> > + __u16 spt_pathcpthld;
> > };
> >
> > /*
>
> As pointed out you can't add things to this structure without breaking existing
> binaries.
we had the same problem when adding:
spp_ipv6_flowlabel and spp_dscp into struct sctp_paddrparams. in:
commit 0b0dce7a36fb9f1a9dd8245ea82d3a268c6943fe
Author: Xin Long <lucien.xin@gmail.com>
Date: Mon Jul 2 18:21:13 2018 +0800
sctp: add spp_ipv6_flowlabel and spp_dscp for sctp_paddrparams
the solution was:
if (optlen == sizeof(params)) {
if (copy_from_user(¶ms, optval, optlen))
return -EFAULT;
} else if (optlen == ALIGN(offsetof(struct sctp_paddrparams,
spp_ipv6_flowlabel), 4)) {
if (copy_from_user(¶ms, optval, optlen))
return -EFAULT;
if (params.spp_flags & (SPP_DSCP | SPP_IPV6_FLOWLABEL))
return -EINVAL;
} else {
return -EINVAL;
}
I will do the same for this patch. Thanks.
^ permalink raw reply
* Re: [PATCH bpf-next v10 2/4] bpf: new helper to obtain namespace data from current task New bpf helper bpf_get_current_pidns_info.
From: Eric W. Biederman @ 2019-09-11 8:16 UTC (permalink / raw)
To: Al Viro
Cc: Yonghong Song, Carlos Antonio Neira Bustos,
netdev@vger.kernel.org, brouer@redhat.com, bpf@vger.kernel.org
In-Reply-To: <20190910231506.GL1131@ZenIV.linux.org.uk>
Al Viro <viro@zeniv.linux.org.uk> writes:
> On Tue, Sep 10, 2019 at 10:35:09PM +0000, Yonghong Song wrote:
>>
>> Carlos,
>>
>> Discussed with Eric today for what is the best way to get
>> the device number for a namespace. The following patch seems
>> a reasonable start although Eric would like to see
>> how the helper is used in order to decide whether the
>> interface looks right.
>>
>> commit bb00fc36d5d263047a8bceb3e51e969d7fbce7db (HEAD -> fs2)
>> Author: Yonghong Song <yhs@fb.com>
>> Date: Mon Sep 9 21:50:51 2019 -0700
>>
>> nsfs: add an interface function ns_get_inum_dev()
>>
>> This patch added an interface function
>> ns_get_inum_dev(). Given a ns_common structure,
>> the function returns the inode and device
>> numbers. The function will be used later
>> by a newly added bpf helper.
>>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>>
>> diff --git a/fs/nsfs.c b/fs/nsfs.c
>> index a0431642c6b5..a603c6fc3f54 100644
>> --- a/fs/nsfs.c
>> +++ b/fs/nsfs.c
>> @@ -245,6 +245,14 @@ struct file *proc_ns_fget(int fd)
>> return ERR_PTR(-EINVAL);
>> }
>>
>> +/* Get the device number for the current task pidns.
>> + */
>> +void ns_get_inum_dev(struct ns_common *ns, u32 *inum, dev_t *dev)
>> +{
>> + *inum = ns->inum;
>> + *dev = nsfs_mnt->mnt_sb->s_dev;
>> +}
>
> Umm... Where would it get the device number once we get (hell knows
> what for) multiple nsfs instances? I still don't understand what
> would that be about, TBH... Is it really per-userns? Or something
> else entirely? Eric, could you give some context?
My goal is not to paint things into a corner, with future changes.
Right now it is possible to stat a namespace file descriptor and
get a device and inode number. Then compare that.
I don't want people using the inode number in nsfd as some magic
namespace id.
We have had times in the past where there was more than one superblock
and thus more than one device number. Further if userspace ever uses
this heavily there may be times in the future where for
checkpoint/restart purposes we will want multiple nsfd's so we can
preserve the inode number accross a migration.
Realistically there will probably just some kind of hotplug notification
to userspace to say we have hotplugged your operatining system as
a migration notification.
Now the halway discussion did not quite capture everything I was trying
to say but it at least got to the right ballpark.
The helper in fs/nsfs.c should be:
bool ns_match(const struct ns_common *ns, dev_t dev, ino_t ino)
{
return ((ns->inum == ino) && (nsfs_mnt->mnt_sb->s_dev == dev));
}
That way if/when there are multiple inodes identifying the same
namespace the bpf programs don't need to change.
Up farther in the stack it should be something like:
> BPF_CALL_2(bpf_current_pidns_match, dev_t *dev, ino_t *ino)
> {
> return ns_match(&task_active_pid_ns(current)->ns, *dev, *ino);
> }
>
> const struct bpf_func_proto bpf_current_pidns_match_proto = {
> .func = bpf_current_pins_match,
> .gpl_only = true,
> .ret_type = RET_INTEGER
> .arg1_type = ARG_PTR_TO_DEVICE_NUMBER,
> .arg2_type = ARG_PTR_TO_INODE_NUMBER,
> };
That allows comparing what the bpf came up with with whatever value
userspace generated by stating the file descriptor.
That is the least bad suggestion I currently have for that
functionality. It really would be better to not have that filter in the
bpf program itself but in the infrastructure that binds a program to a
set of tasks.
The problem with this approach is whatever device/inode you have when
the namespace they refer to exits there is the possibility that the
inode will be reused. So your filter will eventually start matching on
the wrong thing.
Eric
^ permalink raw reply
* Re: [PATCH v7 5/7] nfc: pn533: add UART phy driver
From: David Miller @ 2019-09-11 8:17 UTC (permalink / raw)
To: poeschel
Cc: gregkh, tglx, kstewart, swinslow, allison, linux-kernel, netdev,
johan, Claudiu.Beznea
In-Reply-To: <20190910093359.2110-1-poeschel@lemonage.de>
From: Lars Poeschel <poeschel@lemonage.de>
Date: Tue, 10 Sep 2019 11:33:50 +0200
> +static int pn532_uart_send_ack(struct pn533 *dev, gfp_t flags)
> +{
> + struct pn532_uart_phy *pn532 = dev->phy;
> + /* spec 7.1.1.3: Preamble, SoPC (2), ACK Code (2), Postamble */
> + static const u8 ack[PN533_STD_FRAME_ACK_SIZE] = {
> + 0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> + int err;
Reverse christmas tree ordering for the local variables please.
> +static int pn532_uart_rx_is_frame(struct sk_buff *skb)
> +{
> + int i;
> + u16 frame_len;
> + struct pn533_std_frame *std;
> + struct pn533_ext_frame *ext;
Likewise.
^ permalink raw reply
* Re: [PATCH bpf-next v10 2/4] bpf: new helper to obtain namespace data from current task New bpf helper bpf_get_current_pidns_info.
From: Eric W. Biederman @ 2019-09-11 8:17 UTC (permalink / raw)
To: Carlos Antonio Neira Bustos
Cc: Yonghong Song, Al Viro, netdev@vger.kernel.org, brouer@redhat.com,
bpf@vger.kernel.org
In-Reply-To: <20190911043225.GA22183@frodo.byteswizards.com>
Carlos Antonio Neira Bustos <cneirabustos@gmail.com> writes:
> On Tue, Sep 10, 2019 at 10:35:09PM +0000, Yonghong Song wrote:
> Thanks a lot Yonghong.
> I'll include this patch when submitting changes for version 11 of
> this patch.
Please see my reply to Al.
Eric
^ permalink raw reply
* Re: [PATCH v7 6/7] nfc: pn533: Add autopoll capability
From: David Miller @ 2019-09-11 8:17 UTC (permalink / raw)
To: poeschel
Cc: allison, keescook, opensource, swinslow, gregkh, gustavo, tglx,
kstewart, netdev, linux-kernel, johan
In-Reply-To: <20190910093415.2186-1-poeschel@lemonage.de>
From: Lars Poeschel <poeschel@lemonage.de>
Date: Tue, 10 Sep 2019 11:34:12 +0200
> +static int pn533_autopoll_complete(struct pn533 *dev, void *arg,
> + struct sk_buff *resp)
> +{
> + u8 nbtg;
> + int rc;
> + struct pn532_autopoll_resp *apr;
> + struct nfc_target nfc_tgt;
Need reverse christmas tree here.
> @@ -1534,6 +1655,7 @@ static int pn533_start_poll(struct nfc_dev *nfc_dev,
> struct pn533_poll_modulations *cur_mod;
> u8 rand_mod;
> int rc;
> + struct sk_buff *skb;
Likewise.
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: stmmac: Improvements for -next
From: David Miller @ 2019-09-11 8:21 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 10 Sep 2019 16:41:21 +0200
> Misc patches for -next. It includes:
> - Two fixes for features in -next only
> - New features support for GMAC cores (which includes GMAC4 and GMAC5)
Series applied, but what exactly does "ARP offload" even do?
^ permalink raw reply
* Re: [net-next 11/14] ixgbe: Prevent u8 wrapping of ITR value to something less than 10us
From: David Miller @ 2019-09-11 8:24 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: alexander.h.duyck, netdev, nhorman, sassmann, gleventhal,
andrewx.bowers
In-Reply-To: <20190910163434.2449-12-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 10 Sep 2019 09:34:31 -0700
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> There were a couple cases where the ITR value generated via the adaptive
> ITR scheme could exceed 126. This resulted in the value becoming either 0
> or something less than 10. Switching back and forth between a value less
> than 10 and a value greater than 10 can cause issues as certain hardware
> features such as RSC to not function well when the ITR value has dropped
> that low.
>
> Reported-by: Gregg Leventhal <gleventhal@janestreet.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Please remove this from the series, add the Fixes: tag, and submit for 'net'
since Alexander says it is -stable material.
Thanks.
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 build cleanup 2019-09-10
From: David Miller @ 2019-09-11 8:27 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190910214542.8433-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 10 Sep 2019 21:45:57 +0000
> This series provides three build warnings cleanup patches for mlx5,
> Originally i wanted to wait a bit more and attach more patches to this
> series, but apparently this can't wait since already 3 different patches
> for the same fix were submitted this week :).
>
> For more information please see tag log below.
>
> Please pull and let me know if there is any problem.
Pulled, thanks.
^ 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