* Re: [PATCH net-next RFC 7/8] udp: gro behind static key
From: Steffen Klassert @ 2018-09-17 9:03 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, pabeni, davem, Willem de Bruijn
In-Reply-To: <20180914175941.213950-8-willemdebruijn.kernel@gmail.com>
On Fri, Sep 14, 2018 at 01:59:40PM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> Avoid the socket lookup cost in udp_gro_receive if no socket has a
> gro callback configured.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
...
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 4f6aa95a9b12..f44fe328aa0f 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -405,7 +405,7 @@ static struct sk_buff *udp4_gro_receive(struct list_head *head,
> {
> struct udphdr *uh = udp_gro_udphdr(skb);
>
> - if (unlikely(!uh))
> + if (unlikely(!uh) || !static_branch_unlikely(&udp_encap_needed_key))
> goto flush;
If you use udp_encap_needed_key to enalbe UDP GRO, then a UDP
encapsulation socket will enable it too. Not sure if this is
intentional.
That said, enabling UDP GRO on a UDP encapsulation socket
(ESP in UPD etc.) will fail badly as then encrypted ESP
packets might be merged together. So we somehow should
make sure that this does not happen.
Anyway, this reminds me that we can support GRO for
UDP encapsulation. It just requires separate GRO
callbacks for the different encapsulation types.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: add missing GENERIC_ALLOCATOR dependency
From: David Miller @ 2018-09-17 14:49 UTC (permalink / raw)
To: clabbe; +Cc: linux-kernel, netdev
In-Reply-To: <1536924007-2440-1-git-send-email-clabbe@baylibre.com>
From: Corentin Labbe <clabbe@baylibre.com>
Date: Fri, 14 Sep 2018 11:20:07 +0000
> This patch mades TI_DAVINCI_CPDMA select GENERIC_ALLOCATOR.
> without that, the following sparc64 build failure happen
>
> drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_check_free_tx_desc':
> (.text+0x278): undefined reference to `gen_pool_avail'
> drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_chan_submit':
> (.text+0x340): undefined reference to `gen_pool_alloc'
> (.text+0x5c4): undefined reference to `gen_pool_free'
> drivers/net/ethernet/ti/davinci_cpdma.o: In function `__cpdma_chan_free':
> davinci_cpdma.c:(.text+0x64c): undefined reference to `gen_pool_free'
> drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_desc_pool_destroy.isra.6':
> davinci_cpdma.c:(.text+0x17ac): undefined reference to `gen_pool_size'
> davinci_cpdma.c:(.text+0x17b8): undefined reference to `gen_pool_avail'
> davinci_cpdma.c:(.text+0x1824): undefined reference to `gen_pool_size'
> davinci_cpdma.c:(.text+0x1830): undefined reference to `gen_pool_avail'
> drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_ctlr_create':
> (.text+0x19f8): undefined reference to `devm_gen_pool_create'
> (.text+0x1a90): undefined reference to `gen_pool_add_virt'
> Makefile:1011: recipe for target 'vmlinux' failed
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Andy Lutomirski @ 2018-09-17 14:51 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andy Lutomirski, David S. Miller, Andrew Lunn, Jason A. Donenfeld,
Eric Biggers, Greg KH, LKML, Network Development, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CAKv+Gu8QgRo-Oex2Sk5unET3FMq+1Cp2btAWXCB8xsALxjatHg@mail.gmail.com>
> On Sep 16, 2018, at 10:26 PM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> As far as I can tell (i.e., as a user not a network dev), WireGuard is
> an excellent piece of code, and I would like to see it merged. I also
> think there is little disagreement about the quality of the proposed
> algorithm implementations and the usefulness of having a set of easy
> to use solid crypto primitives in addition to or complementing the
> current crypto API.
>
> I do have some concerns over how the code is organized though:
>
> * simd_relax() is currently not called by the crypto routines
> themselves. This means that the worst case scheduling latency is
> unbounded, which is unacceptable for the -rt kernel. The worst case
> scheduling latency should never be proportional to the input size.
> (Apologies for not spotting that earlier)
>
> * Using a cute name for the crypto library [that will end up being the
> preferred choice for casual use only] may confuse people, given that
> we have lots of code in crypto/ already. I'd much prefer using, e.g.,
> crypto/lib and crypto/api (regardless of where the arch specific
> pieces live)
>
> * I'd prefer the arch specific pieces to live under arch, but I can
> live with keeping them in a single place, as long as the arch
> maintainers have some kind of jurisdiction over them. I also think
> there should be some overlap between the maintainership
> responsibilities of the two generic pieces (api and lib).
>
> * (Nit) The GCC command line -include'd .h files contain variable and
> function definitions so they are actually .c files.
Hmm. I would suggest just getting rid of the -include magic entirely. The resulting ifdef will be more comprehensible.
> * The current organization of the code puts all available (for the
> arch) versions of all routines into a single module, which can only be
> built in once we update random.c to use Zinc's chacha20 routines. This
> bloats the core kernel (which is a huge deal for embedded systems that
> have very strict boot requirements). It also makes it impossible to
> simply blacklist a module if you, for instance, prefer to use the
> [potentially more power efficient] scalar code over the SIMD code when
> using a distro kernel.
I think the module organization needs to change. It needs to be possible to have chacha20 built in but AES or whatever as a module.
>
> [To summarize the 4 points above, I'd much rather see a more
> conventional organization where different parts are provided by
> different modules. I don't think the argument that inlining is needed
> for performance is actually valid, given that we have branch
> predictors and static keys, and the arch SIMD code is built as
> separate object files anyway]
I might have agreed before Spectre :(. Unfortunately, unless we do some magic, I think the code would look something like:
if (static_branch_likely(have_simd)) arch_chacha20();
...where arch_chacha20 is a *pointer*. And that will generate a retpoline and run very, very slowly. (I just rewrote some of the x86 entry code to eliminate one retpoline. I got a 5% speedup on some tests according to the kbuild bot.)
So, if we really wanted modules, we’d need a new dynamic patching mechanism.
I would suggest instead adding two boot (or debugfs) options:
simd=off: disables simd_get using a static branch.
crypto_chacha20_nosimd: Does what it sounds like.
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Andy Lutomirski @ 2018-09-17 14:53 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Andrew Lutomirski, David Miller, Andrew Lunn, Eric Biggers,
Greg Kroah-Hartman, Ard Biesheuvel, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <CAHmME9ohGPTX-fkhP6zaWdx3SbkiqO5kWkWE-bDk=pm-nUqYvw@mail.gmail.com>
> On Sep 16, 2018, at 10:07 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hey Andy,
>
> Thanks a lot for your feedback.
>
>> On Mon, Sep 17, 2018 at 6:09 AM Andy Lutomirski <luto@kernel.org> wrote:
>> 1. Zinc conflates the addition of a new API with the replacement of
>> some algorithm implementations. This is problematic. Look at the
>> recent benchmarks of ipsec before and after this series. Apparently
>> big packets get faster and small packets get slower. It would be
>> really nice to bisect the series to narrow down *where* the regression
>> came from, but, as currently structured, you can't.
>>
>> The right way to do this is to rearrange the series. First, the new
>> Zinc APIs should be added, and they should be backed with the
>> *existing* crypto code. (If the code needs to be moved or copied to a
>> new location, so be it. The patch will be messy because somehow the
>> Zinc API is going to have to dispatch to the arch-specific code, and
>> the way that the crypto API handles it is not exactly friendly to this
>> type of use. So be it.) Then another patch should switch the crypto
>> API to use the Zinc interface. That patch, *by itself*, can be
>> benchmarked. If it causes a regression for small ipsec packets, then
>> it can be tracked down relatively easily. Once this is all done, the
>> actual crypto implementation can be changed, and that changed can be
>> reviewed on its own merits.
>
> That ipsec regression was less related to the implementation and more
> related to calling kernel_fpu_begin() unnecessarily, something I've
> now fixed. So I'm not sure that's such a good example. However, I can
> try to implement Zinc over the existing assembly (Martin's and Ard's),
> first, as you've described. This will be a pretty large amount of
> work, but if you think it's worth it for the commit history, then I'll
> do it.
Ard, what do you think? I think it would
be nice, but if the authors of that assembly are convinced it should be replaced, then this step is optional IMO.
>
>> 2. The new Zinc crypto implementations look like they're brand new. I
>> realize that they have some history, some of them are derived from
>> OpenSSL, etc, but none of this is really apparent in the patches
>> themselves.
>
> The whole point of going with these is that they _aren't_ brand new,
> yet they are very fast. Eyeballs and fuzzer hours are important, and
> AndyP's seems to get the most eyeballs and fuzzer hours, generally.
>
>> it would be nice if
>> the patches made it more clear how the code differs from its origin.
>> At the very least, though, if the replacement of the crypto code were,
>> as above, a patch that just replaced the crypto code, it would be much
>> easier to review and benchmark intelligently.
>
> You seem to have replied to the v3 thread, not the v4 thread. I've
> already started to include lots of detail about the origins of the
> code and [any] important differences in v4, and I'll continue to add
> more detail for v5.
This is indeed better. Ard’s reply covers this better.
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Andy Lutomirski @ 2018-09-17 14:55 UTC (permalink / raw)
To: David Miller, herbert
Cc: luto, andrew, Jason, ebiggers, gregkh, ard.biesheuvel,
linux-kernel, netdev, sneves, jeanphilippe.aumasson, linux-crypto
In-Reply-To: <20180916.214549.234387075817326903.davem@davemloft.net>
> On Sep 16, 2018, at 9:45 PM, David Miller <davem@davemloft.net> wrote:
>
> From: Andy Lutomirski <luto@kernel.org>
> Date: Sun, 16 Sep 2018 21:09:11 -0700
>
>> CRYPTO API
>> M: Herbert Xu <herbert@gondor.apana.org.au>
>> M: "David S. Miller" <davem@davemloft.net>
>> L: linux-crypto@vger.kernel.org
>>
>> Herbert hasn't replied to any of these submissions. You're the other
>> maintainer :)
>
> Herbert is the primary crypto maintainer, I haven't done a serious
> review of crypto code in ages.
>
> So yes, Herbert review is what is important here.
Would you accept Ard’s (and/or Eric Biggers’, perhaps, as an alternative)? Or, if you really want Herbert’s review, can you ask him to review it? (Hi Herbert!)
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: let phylink manage the carrier state
From: David Miller @ 2018-09-17 14:57 UTC (permalink / raw)
To: antoine.tenart
Cc: linux, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180914145635.21813-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 14 Sep 2018 16:56:35 +0200
> Net drivers using phylink shouldn't mess with the link carrier
> themselves and should let phylink manage it. The mvpp2 driver wasn't
> following this best practice as the mac_config() function made calls to
> change the link carrier state. This led to wrongly reported carrier link
> state which then triggered other issues. This patch fixes this
> behaviour.
>
> But the PPv2 driver relied on this misbehaviour in two cases: for fixed
> links and when not using phylink (ACPI mode). The later was fixed by
> adding an explicit call to link_up(), which when the ACPI mode will use
> phylink should be removed.
>
> The fixed link case was relying on the mac_config() function to set the
> link up, as we found an issue in phylink_start() which assumes the
> carrier is off. If not, the link_up() function is never called. To fix
> this, a call to netif_carrier_off() is added just before phylink_start()
> so that we do not introduce a regression in the driver.
>
> Fixes: 4bb043262878 ("net: mvpp2: phylink support")
> Reported-by: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: add new compatibility string for macb on sama5d3
From: David Miller @ 2018-09-17 14:57 UTC (permalink / raw)
To: nicolas.ferre
Cc: netdev, linux-kernel, linux-arm-kernel, claudiu.beznea,
alexandre.belloni, ludovic.desroches, devicetree
In-Reply-To: <20180914154811.12090-2-nicolas.ferre@microchip.com>
From: Nicolas Ferre <nicolas.ferre@microchip.com>
Date: Fri, 14 Sep 2018 17:48:11 +0200
> We need this new compatibility string as we experienced different behavior
> for this 10/100Mbits/s macb interface on this particular SoC.
> Backward compatibility is preserved as we keep the alternative strings.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: macb: disable scatter-gather for macb on sama5d3
From: David Miller @ 2018-09-17 14:58 UTC (permalink / raw)
To: nicolas.ferre
Cc: netdev, linux-kernel, linux-arm-kernel, claudiu.beznea,
alexandre.belloni, ludovic.desroches, devicetree
In-Reply-To: <20180914154811.12090-1-nicolas.ferre@microchip.com>
From: Nicolas Ferre <nicolas.ferre@microchip.com>
Date: Fri, 14 Sep 2018 17:48:10 +0200
> Create a new configuration for the sama5d3-macb new compatibility string.
> This configuration disables scatter-gather because we experienced lock down
> of the macb interface of this particular SoC under very high load.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Applied, but are you really sure it isn't just some bug in the driver
or somesuch?
^ permalink raw reply
* Re: [PATCH] net: hp100: fix always-true check for link up state
From: David Miller @ 2018-09-17 14:58 UTC (permalink / raw)
To: colin.king; +Cc: perex, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180914163953.20734-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 14 Sep 2018 17:39:53 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> The operation ~(p100_inb(VG_LAN_CFG_1) & HP100_LINK_UP) returns a value
> that is always non-zero and hence the wait for the link to drop always
> terminates prematurely. Fix this by using a logical not operator instead
> of a bitwise complement. This issue has been in the driver since
> pre-2.6.12-rc2.
>
> Detected by CoverityScan, CID#114157 ("Logical vs. bitwise operator")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library
From: Jason A. Donenfeld @ 2018-09-17 14:59 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Andrew Lutomirski, David Miller, Andrew Lunn, Eric Biggers,
Greg Kroah-Hartman, Ard Biesheuvel, LKML, Netdev, Samuel Neves,
Jean-Philippe Aumasson, Linux Crypto Mailing List
In-Reply-To: <8937D6B1-D21C-4C47-8A89-A466CDB6FB04@amacapital.net>
On Mon, Sep 17, 2018 at 4:54 PM Andy Lutomirski <luto@amacapital.net> wrote:
> Ard, what do you think? I think it would
> be nice, but if the authors of that assembly are convinced it should be replaced, then this step is optional IMO.
I just spent several hours reworking everything for ChaCha. That was
the easy one. Poly1305 will be much harder. Work in progress, I guess,
but erf it's rough.
^ permalink raw reply
* Re: [PATCH net-next] net: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-17 15:09 UTC (permalink / raw)
To: yuehaibing; +Cc: linux-kernel, netdev, dev
In-Reply-To: <20180915081906.23816-1-yuehaibing@huawei.com>
Please don't do this.
The hard part of fixing this is not what you are doing, changing the
return type.
The hard part is fixing each and every function to actually return
values which are members of the netdev_tx_t enumeration.
Please fix each and every function properly.
Thank you.
^ permalink raw reply
* [PATCH net] net/ipv4: defensive cipso option parsing
From: Stefan Nuernberger @ 2018-09-17 15:11 UTC (permalink / raw)
To: netdev; +Cc: aams, yujuan.qi, paul, Stefan Nuernberger, stable
commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
a possible infinite loop in the IP option parsing of CIPSO. The fix
assumes that ip_options_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
While this assumption currently holds true, add explicit checks for zero
length and invalid length options to be safe for the future. Even though
ip_options_compile should have validated the options, the introduction of
new one-byte options can still confuse this code without the additional
checks.
Signed-off-by: Stefan Nuernberger <snu@amazon.com>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Simon Veith <sveith@amazon.de>
Cc: stable@vger.kernel.org
---
net/ipv4/cipso_ipv4.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 82178cc69c96..f291b57b8474 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1512,7 +1512,7 @@ static int cipso_v4_parsetag_loc(const struct cipso_v4_doi *doi_def,
*
* Description:
* Parse the packet's IP header looking for a CIPSO option. Returns a pointer
- * to the start of the CIPSO option on success, NULL if one if not found.
+ * to the start of the CIPSO option on success, NULL if one is not found.
*
*/
unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
@@ -1522,9 +1522,11 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
int optlen;
int taglen;
- for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
+ for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 1; ) {
switch (optptr[0]) {
case IPOPT_CIPSO:
+ if (!optptr[1] || optptr[1] > optlen)
+ return NULL;
return optptr;
case IPOPT_END:
return NULL;
@@ -1534,6 +1536,10 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
default:
taglen = optptr[1];
}
+
+ if (!taglen || taglen > optlen)
+ break;
+
optlen -= taglen;
optptr += taglen;
}
--
2.19.0
^ permalink raw reply related
* Re: [PATH RFC net-next 1/8] net: phy: Move linkmode helpers to somewhere public
From: Maxime Chevallier @ 2018-09-17 9:48 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-2-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:49 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>phylink has some useful helpers to working with linkmode bitmaps.
>Move them to there own header so other code can use them.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATCH net-next] selftests/tls: Add MSG_WAITALL in recv() syscall
From: David Miller @ 2018-09-17 15:15 UTC (permalink / raw)
To: vakul.garg
Cc: netdev, linux-kselftest, linux-kernel, shuah, davejwatson,
doronrk
In-Reply-To: <20180916043428.24329-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Sun, 16 Sep 2018 10:04:28 +0530
> A number of tls selftests rely upon recv() to return an exact number of
> data bytes. When tls record crypto is done using an async accelerator,
> it is possible that recv() returns lesser than expected number bytes.
> This leads to failure of many test cases. To fix it, MSG_WAITALL has
> been used in flags passed to recv() syscall.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATH RFC net-next 2/8] net: phy: Add phydev_warn()
From: Maxime Chevallier @ 2018-09-17 9:49 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-3-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:50 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>Not all new style LINK_MODE bits can be converted into old style
>SUPPORTED bits. We need to warn when such a conversion is attempted.
>Add a helper for this.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [RFC/fix] Re: libbpf build broken on musl libc (Alpine Linux)
From: Arnaldo Carvalho de Melo @ 2018-09-17 15:16 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo, Jakub Kicinski, Daniel Borkmann,
Thomas Richter, Hendrik Brueckner, Jiri Olsa, Namhyung Kim,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180913185629.su22fnimluoezntg@ast-mbp>
Em Thu, Sep 13, 2018 at 11:56:31AM -0700, Alexei Starovoitov escreveu:
> On Thu, Sep 13, 2018 at 03:32:40PM -0300, Arnaldo Carvalho de Melo wrote:
> > Please do some testing with my perf/libbpf+str_error_r branch, it has
> > two patches to get this fixed, the one I sent and a prep one making
> > libbpf link against libapi.
> > [acme@jouet perf]$ git log --oneline -2
> > a7ab924b7fec (HEAD -> perf/urgent, acme.korg/perf/libbpf+str_error_r) tools lib bpf: Use str_error_r() to fix the build in Alpine Linux
> > fb4a79e04c2b tools lib bpf: Build and link to tools/lib/api/
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/commit/?h=perf/libbpf%2bstr_error_r&id=fb4a79e04c2b37ee873a3b31a3250925cf466fff
> we cannot do this.
> lib/api is GPL we cannot use it in LGPL library.
So, look at this second attempt, are you ok with it?
Builds with all the Alpine Linux test build containers and some more,
still building with all the others:
1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0
2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822
3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0
4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0
5 alpine:3.8 : Ok gcc (Alpine 6.4.0) 6.4.0
6 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0
7 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
8 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
9 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
10 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
11 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
12 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
13 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
14 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
15 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
16 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
17 debian:experimental : Ok gcc (Debian 8.2.0-4) 8.2.0
18 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 8.2.0-4) 8.2.0
19 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 8.2.0-4) 8.2.0
commit 1ca0d8249e5bd335b1c33a33569e4ed94025128e
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Fri Sep 14 16:47:14 2018 -0300
tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systems
Same problem that got fixed in a similar fashion in tools/perf/ in
c8b5f2c96d1b ("tools: Introduce str_error_r()"), fix it in the same
way, licensing needs to be sorted out to libbpf to use libapi, so,
for this simple case, just get the same wrapper in tools/lib/bpf.
This makes libbpf and its users (bpftool, selftests, perf) to build
again in Alpine Linux 3.[45678] and edge.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@gmail.com>
Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Quentin Monnet <quentin.monnet@netronome.com>
Cc: Thomas Richter <tmricht@linux.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: Yonghong Song <yhs@fb.com>
Fixes: 1ce6a9fc1549 ("bpf: fix build error in libbpf with EXTRA_CFLAGS="-Wp, -D_FORTIFY_SOURCE=2 -O2"")
Link: https://lkml.kernel.org/n/tip-i8ckf6s06e7tayw7xxhhhkux@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
index 13a861135127..6eb9bacd1948 100644
--- a/tools/lib/bpf/Build
+++ b/tools/lib/bpf/Build
@@ -1 +1 @@
-libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o
+libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o str_error.o
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 2abd0f112627..bdb94939fd60 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -50,6 +50,7 @@
#include "libbpf.h"
#include "bpf.h"
#include "btf.h"
+#include "str_error.h"
#ifndef EM_BPF
#define EM_BPF 247
@@ -469,7 +470,7 @@ static int bpf_object__elf_init(struct bpf_object *obj)
obj->efile.fd = open(obj->path, O_RDONLY);
if (obj->efile.fd < 0) {
char errmsg[STRERR_BUFSIZE];
- char *cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ char *cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to open %s: %s\n", obj->path, cp);
return -errno;
@@ -810,8 +811,7 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
data->d_size, name, idx);
if (err) {
char errmsg[STRERR_BUFSIZE];
- char *cp = strerror_r(-err, errmsg,
- sizeof(errmsg));
+ char *cp = str_error(-err, errmsg, sizeof(errmsg));
pr_warning("failed to alloc program %s (%s): %s",
name, obj->path, cp);
@@ -1140,7 +1140,7 @@ bpf_object__create_maps(struct bpf_object *obj)
*pfd = bpf_create_map_xattr(&create_attr);
if (*pfd < 0 && create_attr.btf_key_type_id) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
map->name, cp, errno);
create_attr.btf_fd = 0;
@@ -1155,7 +1155,7 @@ bpf_object__create_maps(struct bpf_object *obj)
size_t j;
err = *pfd;
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to create map (name: '%s'): %s\n",
map->name, cp);
for (j = 0; j < i; j++)
@@ -1339,7 +1339,7 @@ load_program(enum bpf_prog_type type, enum bpf_attach_type expected_attach_type,
}
ret = -LIBBPF_ERRNO__LOAD;
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("load bpf program failed: %s\n", cp);
if (log_buf && log_buf[0] != '\0') {
@@ -1654,7 +1654,7 @@ static int check_path(const char *path)
dir = dirname(dname);
if (statfs(dir, &st_fs)) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to statfs %s: %s\n", dir, cp);
err = -errno;
}
@@ -1690,7 +1690,7 @@ int bpf_program__pin_instance(struct bpf_program *prog, const char *path,
}
if (bpf_obj_pin(prog->instances.fds[instance], path)) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to pin program: %s\n", cp);
return -errno;
}
@@ -1708,7 +1708,7 @@ static int make_dir(const char *path)
err = -errno;
if (err) {
- cp = strerror_r(-err, errmsg, sizeof(errmsg));
+ cp = str_error(-err, errmsg, sizeof(errmsg));
pr_warning("failed to mkdir %s: %s\n", path, cp);
}
return err;
@@ -1770,7 +1770,7 @@ int bpf_map__pin(struct bpf_map *map, const char *path)
}
if (bpf_obj_pin(map->fd, path)) {
- cp = strerror_r(errno, errmsg, sizeof(errmsg));
+ cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to pin map: %s\n", cp);
return -errno;
}
diff --git a/tools/lib/bpf/str_error.c b/tools/lib/bpf/str_error.c
new file mode 100644
index 000000000000..b8798114a357
--- /dev/null
+++ b/tools/lib/bpf/str_error.c
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: LGPL-2.1
+#undef _GNU_SOURCE
+#include <string.h>
+#include <stdio.h>
+#include "str_error.h"
+
+/*
+ * Wrapper to allow for building in non-GNU systems such as Alpine Linux's musl
+ * libc, while checking strerror_r() return to avoid having to check this in
+ * all places calling it.
+ */
+char *str_error(int err, char *dst, int len)
+{
+ int ret = strerror_r(err, dst, len);
+ if (ret)
+ snprintf(dst, len, "ERROR: strerror_r(%d)=%d", err, ret);
+ return dst;
+}
diff --git a/tools/lib/bpf/str_error.h b/tools/lib/bpf/str_error.h
new file mode 100644
index 000000000000..b9a22564ddc6
--- /dev/null
+++ b/tools/lib/bpf/str_error.h
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.1
+#ifndef BPF_STR_ERROR
+#define BPF_STR_ERROR
+
+char *str_error(int err, char *dst, int len);
+#endif // BPF_STR_ERROR
^ permalink raw reply related
* Re: [PATH RFC net-next 3/8] net: phy: Add helper to convert MII ADV register to a linkmode
From: Maxime Chevallier @ 2018-09-17 9:50 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-4-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:51 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>The phy_mii_ioctl can be used to write a value into the MII_ADVERTISE
>register in the PHY. Since this changes the state of the PHY, we need
>to make the same change to phydev->advertising. Add a helper which can
>convert the register value to a linkmode.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATH RFC net-next 4/8] net: phy: Add helper for advertise to lcl value
From: Maxime Chevallier @ 2018-09-17 9:51 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-5-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:52 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>Add a helper to convert the local advertising to an LCL capabilities,
>which is then used to resolve pause flow control settings.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATH RFC net-next 5/8] net: phy: Add limkmode equivalents to some of the MII ethtool helpers
From: Maxime Chevallier @ 2018-09-17 9:53 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli
In-Reply-To: <1536961136-30453-6-git-send-email-andrew@lunn.ch>
On Fri, 14 Sep 2018 23:38:53 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
>Add helpers which take a linkmode rather than a u32 ethtool for
>advertising settings.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATCH] net: ethernet: remove redundant null pointer check before of_node_put
From: David Miller @ 2018-09-17 15:20 UTC (permalink / raw)
To: zhongjiang; +Cc: fugang.duan, netdev, linux-kernel
In-Reply-To: <1537103622-63482-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Sun, 16 Sep 2018 21:13:42 +0800
> of_node_put has taken the null pinter check into account. So it is
> safe to remove the duplicated check before of_node_put.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied.
^ permalink raw reply
* Re: iproute2: Debian 9 No ELF support
From: Daniel Borkmann @ 2018-09-17 9:57 UTC (permalink / raw)
To: yuzibode; +Cc: netdev
In-Reply-To: <20180917082353.ebtapq7oxirrzrcu@yubo-2>
On 09/17/2018 10:23 AM, Bo YU wrote:
> Hello,
> I have followed the instructions from:
>
> https://cilium.readthedocs.io/en/latest/bpf/#bpftool
>
> to test xdp program.
> But i can not enable elf support.
>
> ./configure --prefix=/usr
> ```output
> TC schedulers
> ATM no
>
> libc has setns: yes
> SELinux support: no
> ELF support: no
> libmnl support: yes
> Berkeley DB: yes
> need for strlcpy: yes
> libcap support: yes
> ```
> And i have installed libelf-dev :
> ```output
> sudo apt show libelf-dev
> Package: libelf-dev
> Version: 0.168-1
> Priority: optional
> Section: libdevel
> Source: elfutils
> Maintainer: Kurt Roeckx <kurt@roeckx.be>
> Installed-Size: 353 kB
> Depends: libelf1 (= 0.168-1)
> Conflicts: libelfg0-dev
> Homepage: https://sourceware.org/elfutils/
> Tag: devel::library, role::devel-lib
> ```
>
> And gcc version:
> gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
>
> uname -a:
> Linux debian 4.18.0-rc1+ #2 SMP Sun Jun 24 16:53:57 HKT 2018 x86_64 GNU/Linux
>
> Any help is appreciate.
Debian's official iproute2 packaging build says 'libelf-dev' [0], and having
libelf-dev installed should work ...
[...]
Build-Depends: bison,
debhelper (>= 10~),
flex,
iptables-dev,
libatm1-dev,
libcap-dev,
libdb-dev,
libelf-dev,
libmnl-dev,
libselinux1-dev,
linux-libc-dev,
pkg-config,
po-debconf,
zlib1g-dev,
[...]
Did you ran into this one perhaps [1]? Do you have zlib1g-dev installed?
[0] https://salsa.debian.org/debian/iproute2/blob/master/debian/control
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885071
^ permalink raw reply
* [PATCH v2 1/2] netlink: add NLA_REJECT policy type
From: Johannes Berg @ 2018-09-17 9:57 UTC (permalink / raw)
To: netdev; +Cc: Marcelo Ricardo Leitner, Michal Kubecek, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
In some situations some netlink attributes may be used for output
only (kernel->userspace) or may be reserved for future use. It's
then helpful to be able to prevent userspace from using them in
messages sent to the kernel, since they'd otherwise be ignored and
any future will become impossible if this happens.
Add NLA_REJECT to the policy which does nothing but reject (with
EINVAL) validation of any messages containing this attribute.
Allow for returning a specific extended ACK error message in the
validation_data pointer.
While at it clear up the documentation a bit - the NLA_BITFIELD32
documentation was added to the list of len field descriptions.
Also, use NL_SET_BAD_ATTR() in one place where it's open-coded.
The specific case I have in mind now is a shared nested attribute
containing request/response data, and it would be pointless and
potentially confusing to have userspace include response data in
the messages that actually contain a request.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
v2: preserve behaviour of overwriting the extack message, with
either the generic or the specific one now
---
include/net/netlink.h | 13 ++++++++++++-
lib/nlattr.c | 23 ++++++++++++++++-------
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 0c154f98e987..b318b0a9f6c3 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -180,6 +180,7 @@ enum {
NLA_S32,
NLA_S64,
NLA_BITFIELD32,
+ NLA_REJECT,
__NLA_TYPE_MAX,
};
@@ -208,9 +209,19 @@ enum {
* NLA_MSECS Leaving the length field zero will verify the
* given type fits, using it verifies minimum length
* just like "All other"
- * NLA_BITFIELD32 A 32-bit bitmap/bitselector attribute
+ * NLA_BITFIELD32 Unused
+ * NLA_REJECT Unused
* All other Minimum length of attribute payload
*
+ * Meaning of `validation_data' field:
+ * NLA_BITFIELD32 This is a 32-bit bitmap/bitselector attribute and
+ * validation data must point to a u32 value of valid
+ * flags
+ * NLA_REJECT This attribute is always rejected and validation data
+ * may point to a string to report as the error instead
+ * of the generic one in extended ACK.
+ * All other Unused
+ *
* Example:
* static const struct nla_policy my_policy[ATTR_MAX+1] = {
* [ATTR_FOO] = { .type = NLA_U16 },
diff --git a/lib/nlattr.c b/lib/nlattr.c
index e335bcafa9e4..36d74b079151 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -69,7 +69,8 @@ static int validate_nla_bitfield32(const struct nlattr *nla,
}
static int validate_nla(const struct nlattr *nla, int maxtype,
- const struct nla_policy *policy)
+ const struct nla_policy *policy,
+ const char **error_msg)
{
const struct nla_policy *pt;
int minlen = 0, attrlen = nla_len(nla), type = nla_type(nla);
@@ -87,6 +88,11 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
}
switch (pt->type) {
+ case NLA_REJECT:
+ if (pt->validation_data && error_msg)
+ *error_msg = pt->validation_data;
+ return -EINVAL;
+
case NLA_FLAG:
if (attrlen > 0)
return -ERANGE;
@@ -180,11 +186,10 @@ int nla_validate(const struct nlattr *head, int len, int maxtype,
int rem;
nla_for_each_attr(nla, head, len, rem) {
- int err = validate_nla(nla, maxtype, policy);
+ int err = validate_nla(nla, maxtype, policy, NULL);
if (err < 0) {
- if (extack)
- extack->bad_attr = nla;
+ NL_SET_BAD_ATTR(extack, nla);
return err;
}
}
@@ -250,11 +255,15 @@ int nla_parse(struct nlattr **tb, int maxtype, const struct nlattr *head,
u16 type = nla_type(nla);
if (type > 0 && type <= maxtype) {
+ static const char _msg[] = "Attribute failed policy validation";
+ const char *msg = _msg;
+
if (policy) {
- err = validate_nla(nla, maxtype, policy);
+ err = validate_nla(nla, maxtype, policy, &msg);
if (err < 0) {
- NL_SET_ERR_MSG_ATTR(extack, nla,
- "Attribute failed policy validation");
+ NL_SET_BAD_ATTR(extack, nla);
+ if (extack)
+ extack->_msg = msg;
goto errout;
}
}
--
2.14.4
^ permalink raw reply related
* [PATCH v2 2/2] netlink: add ethernet address policy types
From: Johannes Berg @ 2018-09-17 9:57 UTC (permalink / raw)
To: netdev; +Cc: Marcelo Ricardo Leitner, Michal Kubecek, Johannes Berg
In-Reply-To: <20180917095729.11185-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Commonly, ethernet addresses are just using a policy of
{ .len = ETH_ALEN }
which leaves userspace free to send more data than it should,
which may hide bugs.
Introduce NLA_EXACT_LEN which checks for exact size, rejecting
the attribute if it's not exactly that length. Also add
NLA_EXACT_LEN_WARN which requires the minimum length and will
warn on longer attributes, for backward compatibility.
Use these to define NLA_POLICY_ETH_ADDR (new strict policy) and
NLA_POLICY_ETH_ADDR_COMPAT (compatible policy with warning);
these are used like this:
static const struct nla_policy <name>[...] = {
[NL_ATTR_NAME] = NLA_POLICY_ETH_ADDR,
...
};
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
v2: add only NLA_EXACT_LEN/NLA_EXACT_LEN_WARN and build on top
of that for ethernet address validation, so it can be extended
for other types (e.g. IPv6 addresses)
---
include/net/netlink.h | 13 +++++++++++++
lib/nlattr.c | 8 +++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index b318b0a9f6c3..318b1ded3833 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -181,6 +181,8 @@ enum {
NLA_S64,
NLA_BITFIELD32,
NLA_REJECT,
+ NLA_EXACT_LEN,
+ NLA_EXACT_LEN_WARN,
__NLA_TYPE_MAX,
};
@@ -211,6 +213,10 @@ enum {
* just like "All other"
* NLA_BITFIELD32 Unused
* NLA_REJECT Unused
+ * NLA_EXACT_LEN Attribute must have exactly this length, otherwise
+ * it is rejected.
+ * NLA_EXACT_LEN_WARN Attribute should have exactly this length, a warning
+ * is logged if it is longer, shorter is rejected.
* All other Minimum length of attribute payload
*
* Meaning of `validation_data' field:
@@ -236,6 +242,13 @@ struct nla_policy {
void *validation_data;
};
+#define NLA_POLICY_EXACT_LEN(_len) { .type = NLA_EXACT_LEN, .len = _len }
+#define NLA_POLICY_EXACT_LEN_WARN(_len) { .type = NLA_EXACT_LEN_WARN, \
+ .len = _len }
+
+#define NLA_POLICY_ETH_ADDR NLA_POLICY_EXACT_LEN(ETH_ALEN)
+#define NLA_POLICY_ETH_ADDR_COMPAT NLA_POLICY_EXACT_LEN_WARN(ETH_ALEN)
+
/**
* struct nl_info - netlink source information
* @nlh: Netlink message header of original request
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 36d74b079151..bb6fe5ed4ecf 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -82,12 +82,18 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
BUG_ON(pt->type > NLA_TYPE_MAX);
- if (nla_attr_len[pt->type] && attrlen != nla_attr_len[pt->type]) {
+ if ((nla_attr_len[pt->type] && attrlen != nla_attr_len[pt->type]) ||
+ (pt->type == NLA_EXACT_LEN_WARN && attrlen != pt->len)) {
pr_warn_ratelimited("netlink: '%s': attribute type %d has an invalid length.\n",
current->comm, type);
}
switch (pt->type) {
+ case NLA_EXACT_LEN:
+ if (attrlen != pt->len)
+ return -ERANGE;
+ break;
+
case NLA_REJECT:
if (pt->validation_data && error_msg)
*error_msg = pt->validation_data;
--
2.14.4
^ permalink raw reply related
* Re: [PATCH 0/2] add Ethernet driver support for mt2712
From: Andrew Lunn @ 2018-09-17 15:24 UTC (permalink / raw)
To: Biao Huang, peppe.cavallaro, alexandre.torgue, joabreu
Cc: davem, robh+dt, honghui.zhang, yt.shen, liguo.zhang, mark.rutland,
sean.wang, nelson.chang, matthias.bgg, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <1537165763-13112-1-git-send-email-biao.huang@mediatek.com>
On Mon, Sep 17, 2018 at 02:29:21PM +0800, Biao Huang wrote:
Adding in the STMMAC driver maintainers.
> Ethernet in mt2712 is totally different from that in
> drivers/net/ethernet/mediatek/*, so we add new folder for mt2712 SoC.
>
> The mt2712 Ethernet IP is from Synopsys, and we notice that there is a
> reference driver in drivers/net/ethernet/synopsys/*. But
> 1. our version is only for 10/100/1000Mbps, not for 2.5/4/5Gbps.
> mt2712 Ethernet design is differnet from that in synopsys folder in many
> aspects, and some key features are not included in mt2712, such as rss
> and split header. At the same time, some features we need have not been
> implenmented in synopsys folder.
In general, we don't have two very similar drivers. We try to have one
driver. If the problem was just missing features in the stmmac driver,
you can add them. I doubt not supporting 2.5/4/5Gbps in your silicon
is an issue, since very few STMMAC devices have this. By split header,
do you mean support for TSO? That seems to be a gmac4 or newer
feature, but the driver supports not having tso support in hardware.
Giuseppe, Alexandre, Jose: Please can you look at the proposed driver
and see how much it really differs from the STMMAC driver. How easy
would it be to extend stmmac it to support the mt2712?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH] net: ethernet: Fix a unused function warning.
From: David Miller @ 2018-09-17 15:24 UTC (permalink / raw)
To: zhongjiang; +Cc: bryan.whitehead, UNGLinuxDriver, netdev, linux-kernel
In-Reply-To: <1537181059-53563-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Mon, 17 Sep 2018 18:44:19 +0800
> Fix the following compile warning:
>
> drivers/net/ethernet/microchip/lan743x_main.c:2964:12: warning: ‘lan743x_pm_suspend’ defined but not used [-Wunused-function]
> static int lan743x_pm_suspend(struct device *dev)
> drivers/net/ethernet/microchip/lan743x_main.c:2987:12: warning: ‘lan743x_pm_resume’ defined but not used [-Wunused-function]
> static int lan743x_pm_resume(struct device *dev)
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied.
^ 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