This patch adds a helper function BPF_FUNC_tcp_sock and it
is currently available for cg_skb and sched_(cls|act):
struct bpf_tcp_sock *bpf_tcp_sock(struct bpf_sock *sk);
int cg_skb_foo(struct __sk_buff *skb) {
struct bpf_tcp_sock *tp;
struct bpf_sock *sk;
__u32 snd_cwnd;
This series adds __sk_buff->sk, "struct bpf_tcp_sock",
BPF_FUNC_sk_fullsock and BPF_FUNC_tcp_sock. Together, they provide
a common way to expose the members of "struct tcp_sock" and
"struct bpf_sock" for the bpf_prog to access.
The patch series first adds a bpf_sock pointer to __sk_buff
and a new
The next patch will introduce a new "struct bpf_tcp_sock" which
exposes the same tcp_sock's fields already exposed in
"struct bpf_sock_ops".
This patch refactor the existing convert_ctx_access() codes for
"struct bpf_sock_ops" to get them ready to be reused for
"struct bpf_tcp_sock". The "rtt_min
This patch sync the uapi bpf.h to tools/.
Acked-by: Alexei Starovoitov
Signed-off-by: Martin KaFai Lau
---
tools/include/uapi/linux/bpf.h | 72 ++
1 file changed, 65 insertions(+), 7 deletions(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/l
This patch adds "state", "dst_ip4", "dst_ip6" and "dst_port" to the
bpf_sock. The userspace has already been using "state",
e.g. inet_diag (ss -t) and getsockopt(TCP_INFO).
This patch also allows narrow load on the following existing fields:
"family", "type", "protocol" and "src_port". Unlike IP
In kernel, it is common to check "skb->sk && sk_fullsock(skb->sk)"
before accessing the fields in sock. For example, in __netdev_pick_tx:
static u16 __netdev_pick_tx(struct net_device *dev, struct sk_buff *skb,
struct net_device *sb_dev)
{
/* ... */
st
This patch adds a C program to show the usage on
skb->sk and bpf_tcp_sock.
Acked-by: Alexei Starovoitov
Signed-off-by: Martin KaFai Lau
---
tools/testing/selftests/bpf/Makefile | 6 +-
tools/testing/selftests/bpf/bpf_helpers.h | 4 +
.../testing/selftests/bpf/test_sock_fields.c
This patch tests accessing the skb->sk and the new helpers,
bpf_sk_fullsock and bpf_tcp_sock.
The errstr of some existing "reference tracking" tests is changed
with s/bpf_sock/sock/ and s/socket/sock/ where "sock" is from the
verifier's reg_type_str[].
Acked-by: Alexei Starovoitov
Signed-off-by:
On Sat, Feb 09, 2019 at 08:02:43PM -0800, Alexei Starovoitov wrote:
> On Fri, Feb 08, 2019 at 10:25:54PM -0800, Martin KaFai Lau wrote:
> > By adding this test to test_verifier:
> > {
> > "reference tracking: access sk->src_ip4 (narrow load)",
> > .insns = {
> > BPF_SK_LOOKUP,
> > B
In "net/unix/af_unix.c: Set ATIME on socket inode" (back in
2002) we'd grown something rather odd in unix_find_other(). In the
original patch it was
u=unix_find_socket_byname(sunname, len, type, hash);
- if (!u)
+ if (u) {
+
Le 2/9/19 à 10:21 AM, Jiri Pirko a écrit :
> Sat, Feb 09, 2019 at 01:32:42AM CET, f.faine...@gmail.com wrote:
>> Following patches will change the way we communicate getting or setting
>
> Just "setting", no "getting".
>
>
>> a port's attribute and use a blocking notifier to perform those tasks.
On Fri, Feb 08, 2019 at 10:25:54PM -0800, Martin KaFai Lau wrote:
> By adding this test to test_verifier:
> {
> "reference tracking: access sk->src_ip4 (narrow load)",
> .insns = {
> BPF_SK_LOOKUP,
> BPF_MOV64_REG(BPF_REG_6, BPF_REG_0),
> BPF_JMP_IMM(BPF_JEQ, BPF_REG_0
From: Heiner Kallweit
Date: Fri, 8 Feb 2019 20:56:55 +0100
> Add support for the AQCS109. From software point of view,
> it should be almost equivalent to AQR107.
>
> Signed-off-by: Nikita Yushchenko
> Signed-off-by: Andrew Lunn
> Signed-off-by: Heiner Kallweit
Applied, thanks.
From: Heiner Kallweit
Date: Fri, 8 Feb 2019 22:25:44 +0100
> From: Andrew Lunn
> By using an external PHY, ports 9 and 10 can support 2500BaseT.
> So set this link mode in the mask when validating.
>
> Signed-off-by: Andrew Lunn
> Signed-off-by: Heiner Kallweit
Applied.
From: Kal Conley
Date: Sat, 9 Feb 2019 21:37:00 +0100
> When calculating rb->frames_per_block * req->tp_block_nr the result
> can overflow. Check it for overflow without limiting the total buffer
> size to UINT_MAX.
>
> This change fixes support for packet ring buffers >= UINT_MAX.
Please resu
From: yupeng
Date: Sat, 9 Feb 2019 14:46:18 -0800
> add document for tcp retransmission, tcp fast open, syn cookies,
> challenge ack, prune and several general counters
>
> Signed-off-by: yupeng
Applied.
On Fri, 8 Feb 2019 at 22:27, Martin KaFai Lau wrote:
>
> By adding this test to test_verifier:
> {
> "reference tracking: access sk->src_ip4 (narrow load)",
> .insns = {
> BPF_SK_LOOKUP,
> BPF_MOV64_REG(BPF_REG_6, BPF_REG_0),
> BPF_JMP_IMM(BPF_JEQ, BPF_REG_0
From: Marcelo Ricardo Leitner
Date: Wed, 6 Feb 2019 18:37:54 -0200
> On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote:
>> Make sctp_setsockopt_events() able to accept sctp_event_subscribe
>> structures longer than the current definitions.
>>
>> This should prevent unjustified setsock
add document for tcp retransmission, tcp fast open, syn cookies,
challenge ack, prune and several general counters
Signed-off-by: yupeng
---
Documentation/networking/snmp_counter.rst | 184 +-
1 file changed, 181 insertions(+), 3 deletions(-)
diff --git a/Documentati
Sat, Feb 09, 2019 at 01:36:18AM CET, f.faine...@gmail.com wrote:
>On 2/8/19 4:32 PM, Florian Fainelli wrote:
>> Drop switchdev_ops.switchdev_port_attr_set. Drop the uses of this field
>> from all clients, which were migrated to use switchdev notification in
>> the previous patches.
>>
>> Add a new
When calculating rb->frames_per_block * req->tp_block_nr the result
can overflow. Check it for overflow without limiting the total buffer
size to UINT_MAX.
This change fixes support for packet ring buffers >= UINT_MAX.
---
net/packet/af_packet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Hi,
Working with iproute2 for a task with Wireshark. I don't see the
command in 'ip' to put an Ethernet port into promiscuous mode. A reply
from the openSuse forum (below) tells me how.
I'm wondering if this should be in the 'MAN ip' page.
Regards,
Bill Flanagan
Forwarded Me
On 09.02.2019 20:50, Heiner Kallweit wrote:
> On 09.02.2019 20:42, Andrew Lunn wrote:
>>> I know, it's patch 15 in your series ;) And I'm aware that usually new
>>> core functionality is acceptable only if it comes together with a user,
>>> to avoid having billions of orphaned good ideas in the cod
On 09.02.2019 20:42, Andrew Lunn wrote:
>> I know, it's patch 15 in your series ;) And I'm aware that usually new
>> core functionality is acceptable only if it comes together with a user,
>> to avoid having billions of orphaned good ideas in the code.
>> I focused on the core here to not get lost
> I know, it's patch 15 in your series ;) And I'm aware that usually new
> core functionality is acceptable only if it comes together with a user,
> to avoid having billions of orphaned good ideas in the code.
> I focused on the core here to not get lost in all the new stuff, and to
> provide Maxim
> So we I see two possible solutions:
>
> 1) having both ds->slave_mii_bus and ds->ops->phy_read already defined is an
> error, then it must be signaled to the calling code, or
I don't think we can do that. mv88e6xxx optionally instantiates the
MDIO busses, depending on what is in device tree. If
On 02/08/2019 09:55 PM, Sergei Shtylyov wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> Notice that, in this particular case, the /* fall through */
>> comments are placed at the bottom of the case statement, which
>>
On 09.02.2019 17:35, Andrew Lunn wrote:
> On Sat, Feb 09, 2019 at 03:24:47PM +0100, Heiner Kallweit wrote:
>> From: Andrew Lunn
>> Add support for runtime determination of what the PHY supports, by
>> adding a new function to the phy driver. The get_features call should
>> set the phydev->supporte
Sat, Feb 09, 2019 at 07:21:47PM CET, j...@resnulli.us wrote:
[...]
>>+static int
>>+rocker_switchdev_port_attr_event(unsigned long event, struct net_device
>>*netdev,
>>+ struct switchdev_notifier_port_attr_info
>>+ *port_attr_info)
>>+{
Sat, Feb 09, 2019 at 01:32:42AM CET, f.faine...@gmail.com wrote:
>Following patches will change the way we communicate getting or setting
Just "setting", no "getting".
>a port's attribute and use a blocking notifier to perform those tasks.
>
>Prepare rocker to support receiving notifier events t
Sat, Feb 09, 2019 at 01:32:41AM CET, f.faine...@gmail.com wrote:
>In preparation for allowing switchdev enabled drivers to veto specific
>attribute settings from within the context of the caller, introduce a
>new switchdev notifier type for port attributes.
>
>Suggested-by: Ido Schimmel
>Signed-of
Sat, Feb 09, 2019 at 01:32:40AM CET, f.faine...@gmail.com wrote:
>With the bridge no longer calling switchdev_port_attr_get() to obtain
>the supported bridge port flags from a driver but instead trying to set
>the bridge port flags directly and relying on driver to reject
>unsupported configuration
Sat, Feb 09, 2019 at 01:32:39AM CET, f.faine...@gmail.com wrote:
>Now that we have converted the bridge code and the drivers to check for
>bridge port(s) flags at the time we try to set them, there is no need
>for a get() -> set() sequence anymore and
>SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT th
Sat, Feb 09, 2019 at 01:32:36AM CET, f.faine...@gmail.com wrote:
>In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
>add support for a function that processes the
>SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute and returns not supported
>for any flag set, since DSA does not cu
Sat, Feb 09, 2019 at 01:32:38AM CET, f.faine...@gmail.com wrote:
>Now that all switchdev drivers have been converted to checking the
>bridge port flags during the prepare phase of the
>switchdev_port_attr_set(), we can move straight to trying to set the
>desired flag through SWITCHDEV_ATTR_ID_PORT_
Sat, Feb 09, 2019 at 01:32:37AM CET, f.faine...@gmail.com wrote:
>In preparation for getting rid of switchdev_port_attr_get(), have rocker
>check for the bridge flags being set through switchdev_port_attr_set()
>with the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute identifier.
>
>Signed-off-by: Fl
Sat, Feb 09, 2019 at 01:32:35AM CET, f.faine...@gmail.com wrote:
>In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
>have ethsw check that the bridge port flags that are being set are
>supported.
>
>Signed-off-by: Florian Fainelli
Acked-by: Jiri Pirko
Sat, Feb 09, 2019 at 01:32:34AM CET, f.faine...@gmail.com wrote:
>In preparation for getting rid of switchdev_port_attr_get(), have mlxsw
>check for the bridge flags being set through switchdev_port_attr_set()
>with the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute identifier.
>
>Signed-off-by: Flo
On 2019-02-08 5:26 a.m., Edward Cree wrote:
On 06/02/19 02:20, Jamal Hadi Salim wrote:
tc match using flower blah \
action vlan push tag ... \
action redirect to egress of eth0
And you submited a packet of size x bytes,
then the "match" would record x bytes.
>
Sorry, where would it record t
From: "Yavuz, Tuba"
Date: Sat, 9 Feb 2019 16:24:20 +
>
>
> On an error path inside the hso_create_net_device function of the hso
> driver, hso_free_net_device gets called. This causes potentially a
> negative reference count in the net device if register_netdev has not
> been called yet as
From: Russell King
Date: Sat, 09 Feb 2019 16:06:51 +
> When mvpp2 configures the flow control modes in mvpp2_xlg_config() for
> 10G mode, it only ever set the flow control enable bits. There is no
> mechanism to clear these bits, which means that userspace is unable to
> use standard APIs to
From: Russell King - ARM Linux admin
Date: Sat, 9 Feb 2019 16:07:08 +
> Please ignore this one - subject line is not correct. Thanks.
Aha, ok I'll apply the correct one.
From: Heiner Kallweit
Date: Sat, 9 Feb 2019 14:46:30 +0100
> From: Andrew Lunn
> We will soon support asking the PHY at runtime to determine what
> features it supports, rather than forcing it to be compile time.
> But we should probe the PHY first. So probe the phy driver earlier.
>
> Signed-o
From: Heiner Kallweit
Date: Sat, 9 Feb 2019 15:24:47 +0100
> From: Andrew Lunn
> Add support for runtime determination of what the PHY supports, by
> adding a new function to the phy driver. The get_features call should
> set the phydev->supported member with the features the PHY supports.
> It
Sat, Feb 09, 2019 at 01:32:33AM CET, f.faine...@gmail.com wrote:
>Update the section about switchdev drivers having to implement a
>switchdev_port_attr_get() function to return
>SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
>commit bccb30254a4a ("net: Get rid of
>SWITCHDEV_AT
From: Heiner Kallweit
Date: Sat, 9 Feb 2019 09:46:53 +0100
> PHY registers are only 16 bits wide, therefore, if the read was
> successful, there's no need to mask out the higher 16 bits.
>
> Signed-off-by: Heiner Kallweit
> Reviewed-by: Andrew Lunn
Applied, thanks Heiner.
From: Vakul Garg
Date: Sat, 9 Feb 2019 07:53:28 +
> Function tls_sw_recvmsg() dequeues multiple records from stream parser
> and decrypts them. In case the decryption is done by async accelerator,
> the records may get submitted for decryption while the previous ones may
> not have been decry
On Thu, Feb 07, 2019 at 08:07:07PM -0800, tristram...@microchip.com wrote:
> From: Tristram Ha
>
> Add MIB counter reading support.
>
> Signed-off-by: Tristram Ha
> ---
> drivers/net/dsa/microchip/ksz9477.c| 139
> +++--
> drivers/net/dsa/microchip/ksz_common.c
On Thu, Feb 07, 2019 at 08:07:08PM -0800, tristram...@microchip.com wrote:
> From: Tristram Ha
>
> Replace register polling functions using timeout with readx_poll_time call.
>
> Signed-off-by: Tristram Ha
> ---
> drivers/net/dsa/microchip/ksz9477.c | 91
> +++-
On Thu, Feb 07, 2019 at 08:07:09PM -0800, tristram...@microchip.com wrote:
> From: Tristram Ha
>
> Remove unnecessary header include lines.
>
> Signed-off-by: Tristram Ha
Reviewed-by: Andrew Lunn
Andrew
Jakub Kicinski writes:
> On Sat, 9 Feb 2019 00:18:31 +, Saeed Mahameed wrote:
>> On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote:
>> > On Thu, 2019-02-07 at 19:08 +, Saeed Mahameed wrote:
>> > >
>> > > So
>> > > 1) on dev_map_update_elem() we will call
>> > > dev->dev->ndo_bpf
Saeed Mahameed writes:
> On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote:
>> On Thu, 2019-02-07 at 19:08 +, Saeed Mahameed wrote:
>> >
>> > So
>> > 1) on dev_map_update_elem() we will call
>> > dev->dev->ndo_bpf() to notify the device on the intention to
>> > start/stop
>> > redirec
> +static void ksz9477_phy_setup(struct ksz_device *dev, int port,
> + struct phy_device *phy)
> +{
> + /* ETHTOOL_LINK_MODE_Pause_BIT and ETHTOOL_LINK_MODE_Asym_Pause_BIT
> + * can be removed to disable flow control when rate limiting is used.
> + */
> +
On Sat, Feb 09, 2019 at 03:24:47PM +0100, Heiner Kallweit wrote:
> From: Andrew Lunn
> Add support for runtime determination of what the PHY supports, by
> adding a new function to the phy driver. The get_features call should
> set the phydev->supported member with the features the PHY supports.
>
On 09.02.2019 17:25, Andrew Lunn wrote:
>> I'd propose that you extract generic patches being submission-ready
>> and split the patch series into two. I think the following patches
>> would be candidates for the first series: 2, 3, 5, 6
>> (provided they have no dependency on the other patches)
>>
> I'd propose that you extract generic patches being submission-ready
> and split the patch series into two. I think the following patches
> would be candidates for the first series: 2, 3, 5, 6
> (provided they have no dependency on the other patches)
> Based on that both of us can go on with our w
On an error path inside the hso_create_net_device function of the hso
driver, hso_free_net_device gets called. This causes potentially a
negative reference count in the net device if register_netdev has not
been called yet as hso_free_net_device calls unregister_netdev
regardless. I think the dr
When mvpp2 configures the flow control modes in mvpp2_xlg_config() for
10G mode, it only ever set the flow control enable bits. There is no
mechanism to clear these bits, which means that userspace is unable to
use standard APIs to disable flow control (the only way is to poke the
register directl
Please ignore this one - subject line is not correct. Thanks.
On Sat, Feb 09, 2019 at 04:06:13PM +, Russell King wrote:
> When mvpp2 configures the flow control modes in mvpp2_xlg_config() for
> 10G mode, it only ever set the flow control enable bits. There is no
> mechanism to clear these b
When mvpp2 configures the flow control modes in mvpp2_xlg_config() for
10G mode, it only ever set the flow control enable bits. There is no
mechanism to clear these bits, which means that userspace is unable to
use standard APIs to disable flow control (the only way is to poke the
register directl
On Fri, Feb 8, 2019 at 5:29 PM Ian Kumlien wrote
> On Thu, Feb 7, 2019 at 11:01 PM Ian Kumlien wrote:
> > On Thu, Feb 7, 2019 at 7:43 PM Saeed Mahameed
> > wrote:
> > > On Thu, Feb 7, 2019 at 2:17 AM Ian Kumlien wrote:
> > > > On Thu, Feb 7, 2019 at 2:01 AM Saeed Mahameed
> > > > wrote:
> >
From: Andrew Lunn
Add support for runtime determination of what the PHY supports, by
adding a new function to the phy driver. The get_features call should
set the phydev->supported member with the features the PHY supports.
It is only called if phydrv->features is NULL.
This requires minor change
From: Andrew Lunn
We will soon support asking the PHY at runtime to determine what
features it supports, rather than forcing it to be compile time.
But we should probe the PHY first. So probe the phy driver earlier.
Signed-off-by: Andrew Lunn
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/
On 07.02.2019 10:49, Maxime Chevallier wrote:
> Hello everyone,
>
> This is the second iteration of the series introducing support for
> 2.5GBASET and 5GBASET to the network PHY infrastructure.
>
> These 2 modes are described in the 802.3bz specifications, and allow to
> use 2.5G and 5G speeds on
On 09.02.2019 11:07, Sander Eikelenboom wrote:
> On 09/02/2019 10:59, Heiner Kallweit wrote:
>> On 09.02.2019 10:34, Sander Eikelenboom wrote:
>>> On 09/02/2019 10:02, Heiner Kallweit wrote:
On 09.02.2019 00:09, Eric Dumazet wrote:
>
>
> On 02/08/2019 01:50 PM, Heiner Kallweit wrot
Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
extensions has only 8 bits. Thus extensions starting from DCTCPINFO
cannot be requested directly. Some of them included into response
unconditionally or hook into some of lower 8 bits.
Extension INET_DIAG_CLASS_ID has not way t
On 09/02/2019 10:59, Heiner Kallweit wrote:
> On 09.02.2019 10:34, Sander Eikelenboom wrote:
>> On 09/02/2019 10:02, Heiner Kallweit wrote:
>>> On 09.02.2019 00:09, Eric Dumazet wrote:
On 02/08/2019 01:50 PM, Heiner Kallweit wrote:
> On 08.02.2019 22:45, Sander Eikelenboom wrote:
On 09.02.2019 10:34, Sander Eikelenboom wrote:
> On 09/02/2019 10:02, Heiner Kallweit wrote:
>> On 09.02.2019 00:09, Eric Dumazet wrote:
>>>
>>>
>>> On 02/08/2019 01:50 PM, Heiner Kallweit wrote:
On 08.02.2019 22:45, Sander Eikelenboom wrote:
> On 08/02/2019 22:22, Heiner Kallweit wrote:
>
On 2/8/19 6:34 PM, Jens Axboe wrote:
We need this functionality for the io_uring file registration, but
we cannot rely on it since CONFIG_UNIX can be modular. Move the helpers
to a separate file, that's always builtin to the kernel if CONFIG_UNIX is
m/y.
No functional changes in this patch, just
On 09/02/2019 10:02, Heiner Kallweit wrote:
> On 09.02.2019 00:09, Eric Dumazet wrote:
>>
>>
>> On 02/08/2019 01:50 PM, Heiner Kallweit wrote:
>>> On 08.02.2019 22:45, Sander Eikelenboom wrote:
On 08/02/2019 22:22, Heiner Kallweit wrote:
> On 08.02.2019 21:55, Sander Eikelenboom wrote:
>>>
On 09.02.2019 00:09, Eric Dumazet wrote:
>
>
> On 02/08/2019 01:50 PM, Heiner Kallweit wrote:
>> On 08.02.2019 22:45, Sander Eikelenboom wrote:
>>> On 08/02/2019 22:22, Heiner Kallweit wrote:
On 08.02.2019 21:55, Sander Eikelenboom wrote:
> On 08/02/2019 19:52, Heiner Kallweit wrote:
>>>
On 09.02.2019 00:34, Sander Eikelenboom wrote:
> On 08/02/2019 22:50, Heiner Kallweit wrote:
>> On 08.02.2019 22:45, Sander Eikelenboom wrote:
>>> On 08/02/2019 22:22, Heiner Kallweit wrote:
On 08.02.2019 21:55, Sander Eikelenboom wrote:
> On 08/02/2019 19:52, Heiner Kallweit wrote:
>>
PHY registers are only 16 bits wide, therefore, if the read was
successful, there's no need to mask out the higher 16 bits.
Signed-off-by: Heiner Kallweit
Reviewed-by: Andrew Lunn
---
drivers/net/phy/phy_device.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/d
Sat, Feb 09, 2019 at 04:16:10AM CET, jakub.kicin...@netronome.com wrote:
>Vendor may sound ambiguous, let's rename the fab string to
>"board.manufacture".
>
>Signed-off-by: Jakub Kicinski
>Reviewed-by: Dirk van der Merwe
>---
> drivers/net/ethernet/netronome/nfp/nfp_devlink.c | 2 +-
> 1 file chan
Sat, Feb 09, 2019 at 04:16:09AM CET, jakub.kicin...@netronome.com wrote:
>Number of devlink attributes has grown over 128, causing the
>following warning:
>
>../net/core/devlink.c: In function ‘devlink_nl_cmd_region_read_dumpit’:
>../net/core/devlink.c:3740:1: warning: the frame size of 1064 bytes
Sat, Feb 09, 2019 at 04:16:08AM CET, jakub.kicin...@netronome.com wrote:
>We need the port to be both ethernet and have the rigth netdev,
>not one or the other.
>
>Fixes: ddb6e99e2db1 ("ethtool: add compat for devlink info")
>Signed-off-by: Jakub Kicinski
Acked-by: Jiri Pirko
On 09.02.2019 08:11, David Miller wrote:
> From: Heiner Kallweit
> Date: Fri, 8 Feb 2019 19:25:22 +0100
>
>> Bit 0 in register 1.5 doesn't represent a device but is a flag that
>> Clause 22 registers are present. Therefore disregard this bit when
>> populating the device list. If code needs this
Hello,
I'm working with EPRESSObin and DSA2 where I added the ability to dynamically
load and unload switch configurations by using DT-overlay (a patchwork from here
https://lore.kernel.org/patchwork/patch/468129/). During my tests I notice that
when I remove the overlay in order to disable th
78 matches
Mail list logo
