* Re: [PATCH 4/4] dt-bindings: net: dsa: mediatek,mt7530: update json-schema
From: Arınç ÜNAL @ 2022-08-11 22:09 UTC (permalink / raw)
To: Krzysztof Kozlowski, Andrew Lunn, Vivien Didelot,
Florian Fainelli, Vladimir Oltean, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Matthias Brugger, Sean Wang, Landen Chao, DENG Qingfang,
Frank Wunderlich, Luiz Angelo Daros de Luca, Sander Vanheule,
René van Dorst, Daniel Golle, erkin.bozoglu,
Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <e5cf8a19-637c-95cf-1527-11980c73f6c0@linaro.org>
On 2.08.2022 11:46, Krzysztof Kozlowski wrote:
> On 30/07/2022 16:26, Arınç ÜNAL wrote:
>> Update the json-schema for compatible devices.
>>
>> - Define acceptable phy-mode values for CPU port of each compatible device.
>> - Remove requiring the "reg" property since the referred dsa-port.yaml
>> already does that.
>> - Require mediatek,mcm for the described MT7621 SoCs as the compatible
>> string is only used for MT7530 which is a part of the multi-chip module.
>
> 3 separate patches.
Roger.
>
>>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> ---
>> .../bindings/net/dsa/mediatek,mt7530.yaml | 220 +++++++++++++++---
>> 1 file changed, 191 insertions(+), 29 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
>> index a88e650e910b..a37a14fba9f6 100644
>> --- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
>> +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
>> @@ -135,35 +135,6 @@ properties:
>> the ethsys.
>> maxItems: 1
>>
>> -patternProperties:
>> - "^(ethernet-)?ports$":
>> - type: object
>
> Actually four patches...
>
> I don't find this change explained in commit msg. What is more, it looks
> incorrect. All properties and patternProperties should be explained in
> top-level part.
>
> Defining such properties (with big piece of YAML) in each if:then: is no
> readable.
I can't figure out another way. I need to require certain properties for
a compatible string AND certain enum/const for certain properties which
are inside patternProperties for "^(ethernet-)?port@[0-9]+$" by reading
the compatible string.
If I put allOf:if:then under patternProperties, I can't do the latter.
Other than readability to human eyes, binding check works as intended,
in case there's no other way to do it.
Arınç
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: net: dsa: mediatek,mt7530: make trivial changes
From: Arınç ÜNAL @ 2022-08-11 22:09 UTC (permalink / raw)
To: Krzysztof Kozlowski, Andrew Lunn, Vivien Didelot,
Florian Fainelli, Vladimir Oltean, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Matthias Brugger, Sean Wang, Landen Chao, DENG Qingfang,
Frank Wunderlich, Luiz Angelo Daros de Luca, Sander Vanheule,
René van Dorst, Daniel Golle, erkin.bozoglu,
Sergio Paracuellos
Cc: netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <cc60401b-ecb8-4907-af3e-bb437ae1421b@linaro.org>
On 2.08.2022 11:41, Krzysztof Kozlowski wrote:
> On 30/07/2022 16:26, Arınç ÜNAL wrote:
>> Make trivial changes on the binding.
>>
>> - Update title to include MT7531 switch.
>> - Add me as a maintainer. List maintainers in alphabetical order by first
>> name.
>> - Add description to compatible strings.
>> - Fix MCM description. mediatek,mcm is not used on MT7623NI.
>> - Add description for reset-gpios.
>> - Remove quotes from $ref: "dsa.yaml#".
>>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> ---
>> .../bindings/net/dsa/mediatek,mt7530.yaml | 27 ++++++++++++++-----
>> 1 file changed, 20 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
>> index 17ab6c69ecc7..541984a7d2d4 100644
>> --- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
>> +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml
>> @@ -4,12 +4,13 @@
>> $id: http://devicetree.org/schemas/net/dsa/mediatek,mt7530.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> -title: Mediatek MT7530 Ethernet switch
>> +title: Mediatek MT7530 and MT7531 Ethernet Switches
>>
>> maintainers:
>> - - Sean Wang <sean.wang@mediatek.com>
>> + - Arınç ÜNAL <arinc.unal@arinc9.com>
>> - Landen Chao <Landen.Chao@mediatek.com>
>> - DENG Qingfang <dqfext@gmail.com>
>> + - Sean Wang <sean.wang@mediatek.com>
>>
>> description: |
>> Port 5 of mt7530 and mt7621 switch is muxed between:
>> @@ -66,6 +67,14 @@ properties:
>> - mediatek,mt7531
>> - mediatek,mt7621
>>
>> + description: |
>> + mediatek,mt7530:
>> + For standalone MT7530 and multi-chip module MT7530 in MT7623AI SoC.
>> + mediatek,mt7531:
>> + For standalone MT7531.
>> + mediatek,mt7621:
>> + For multi-chip module MT7530 in MT7621AT, MT7621DAT and MT7621ST SoCs.
>
> If compatible: is changed to oneOf, you can use description for each
> item. Look at board compatibles (arm/fsl.yaml)
Will do, thanks for the example.
>
>> +
>> reg:
>> maxItems: 1
>>
>> @@ -79,7 +88,7 @@ properties:
>> gpio-controller:
>> type: boolean
>> description:
>> - if defined, MT7530's LED controller will run on GPIO mode.
>> + If defined, MT7530's LED controller will run on GPIO mode.
>>
>> "#interrupt-cells":
>> const: 1
>> @@ -98,11 +107,15 @@ properties:
>> mediatek,mcm:
>> type: boolean
>> description:
>> - if defined, indicates that either MT7530 is the part on multi-chip
>> - module belong to MT7623A has or the remotely standalone chip as the
>> - function MT7623N reference board provided for.
>> + Used for MT7621AT, MT7621DAT, MT7621ST and MT7623AI SoCs which the MT7530
>> + switch is a part of the multi-chip module.
>
> Does this mean it is valid only on these variants? If yes, this should
> have a "mediatek,mcm:false" in allOf:if:then as separate patch (with
> this change in description).
Only valid for those, yes. I'll make it false in allOf:if:then for
mediatek,mt7531. It either can or can't be used for mediatek,mt7530 so
nothing to do there.
>
>>
>> reset-gpios:
>> + description:
>> + GPIO to reset the switch. Use this if mediatek,mcm is not used.
>
> The same. Example:
> https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml#L155
Thanks, I'll make it false in allOf:if:then for mediatek,mcm.
Arınç
^ permalink raw reply
* [PATCH bpf-next v4 0/3] Add more bpf_*_ct_lookup() selftests
From: Daniel Xu @ 2022-08-11 21:55 UTC (permalink / raw)
To: bpf, ast, daniel, andrii, memxor
Cc: Daniel Xu, pablo, fw, netfilter-devel, netdev, linux-kernel
This patchset adds more bpf_*_ct_lookup() selftests. The goal is to test
interaction with netfilter subsystem as well as reading from `struct
nf_conn`. The first is important when migrating legacy systems towards
bpf. The latter is important in general to take full advantage of
connection tracking.
I'll follow this patchset up with support for writing to `struct nf_conn`.
Past discussion:
- v3: https://lore.kernel.org/bpf/cover.1660173222.git.dxu@dxuuu.xyz/
- v2: https://lore.kernel.org/bpf/cover.1660062725.git.dxu@dxuuu.xyz/
- v1: https://lore.kernel.org/bpf/cover.1659209738.git.dxu@dxuuu.xyz/
Changes since v3:
- Remove deprecated CHECK_FAIL() usage
- cc netfilter folks
Changes since v2:
- Add bpf-ci kconfig changes
Changes since v1:
- Reword commit message / cover letter to not mention connmark writing
Daniel Xu (3):
selftests/bpf: Add existing connection bpf_*_ct_lookup() test
selftests/bpf: Add connmark read test
selftests/bpf: Update CI kconfig
tools/testing/selftests/bpf/config | 2 +
.../testing/selftests/bpf/prog_tests/bpf_nf.c | 60 +++++++++++++++++++
.../testing/selftests/bpf/progs/test_bpf_nf.c | 21 +++++++
3 files changed, 83 insertions(+)
--
2.37.1
^ permalink raw reply
* [PATCH bpf-next v4 2/3] selftests/bpf: Add connmark read test
From: Daniel Xu @ 2022-08-11 21:55 UTC (permalink / raw)
To: bpf, ast, daniel, andrii, memxor
Cc: Daniel Xu, pablo, fw, netfilter-devel, netdev, linux-kernel
In-Reply-To: <cover.1660254747.git.dxu@dxuuu.xyz>
Test that the prog can read from the connection mark. This test is nice
because it ensures progs can interact with netfilter subsystem
correctly.
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
tools/testing/selftests/bpf/prog_tests/bpf_nf.c | 3 ++-
tools/testing/selftests/bpf/progs/test_bpf_nf.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_nf.c b/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
index 88a2c0bdefec..544bf90ac2a7 100644
--- a/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
@@ -44,7 +44,7 @@ static int connect_to_server(int srv_fd)
static void test_bpf_nf_ct(int mode)
{
- const char *iptables = "iptables -t raw %s PREROUTING -j CT";
+ const char *iptables = "iptables -t raw %s PREROUTING -j CONNMARK --set-mark 42/0";
int srv_fd = -1, client_fd = -1, srv_client_fd = -1;
struct sockaddr_in peer_addr = {};
struct test_bpf_nf *skel;
@@ -114,6 +114,7 @@ static void test_bpf_nf_ct(int mode)
/* expected status is IPS_SEEN_REPLY */
ASSERT_EQ(skel->bss->test_status, 2, "Test for ct status update ");
ASSERT_EQ(skel->data->test_exist_lookup, 0, "Test existing connection lookup");
+ ASSERT_EQ(skel->bss->test_exist_lookup_mark, 43, "Test existing connection lookup ctmark");
end:
if (srv_client_fd != -1)
close(srv_client_fd);
diff --git a/tools/testing/selftests/bpf/progs/test_bpf_nf.c b/tools/testing/selftests/bpf/progs/test_bpf_nf.c
index 84e0fd479794..2722441850cc 100644
--- a/tools/testing/selftests/bpf/progs/test_bpf_nf.c
+++ b/tools/testing/selftests/bpf/progs/test_bpf_nf.c
@@ -28,6 +28,7 @@ __be16 sport = 0;
__be32 daddr = 0;
__be16 dport = 0;
int test_exist_lookup = -ENOENT;
+u32 test_exist_lookup_mark = 0;
struct nf_conn;
@@ -174,6 +175,8 @@ nf_ct_test(struct nf_conn *(*lookup_fn)(void *, struct bpf_sock_tuple *, u32,
sizeof(opts_def));
if (ct) {
test_exist_lookup = 0;
+ if (ct->mark == 42)
+ test_exist_lookup_mark = 43;
bpf_ct_release(ct);
} else {
test_exist_lookup = opts_def.error;
--
2.37.1
^ permalink raw reply related
* [PATCH bpf-next v4 3/3] selftests/bpf: Update CI kconfig
From: Daniel Xu @ 2022-08-11 21:55 UTC (permalink / raw)
To: bpf, ast, daniel, andrii, memxor
Cc: Daniel Xu, pablo, fw, netfilter-devel, netdev, linux-kernel
In-Reply-To: <cover.1660254747.git.dxu@dxuuu.xyz>
The previous selftest changes require two kconfig changes in bpf-ci.
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
tools/testing/selftests/bpf/config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
index fabf0c014349..3fc46f9cfb22 100644
--- a/tools/testing/selftests/bpf/config
+++ b/tools/testing/selftests/bpf/config
@@ -50,9 +50,11 @@ CONFIG_NET_SCHED=y
CONFIG_NETDEVSIM=m
CONFIG_NETFILTER=y
CONFIG_NETFILTER_SYNPROXY=y
+CONFIG_NETFILTER_XT_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_TARGET_CT=y
CONFIG_NF_CONNTRACK=y
+CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_DEFRAG_IPV6=y
CONFIG_RC_CORE=y
--
2.37.1
^ permalink raw reply related
* [PATCH bpf-next v4 1/3] selftests/bpf: Add existing connection bpf_*_ct_lookup() test
From: Daniel Xu @ 2022-08-11 21:55 UTC (permalink / raw)
To: bpf, ast, daniel, andrii, memxor
Cc: Daniel Xu, pablo, fw, netfilter-devel, netdev, linux-kernel
In-Reply-To: <cover.1660254747.git.dxu@dxuuu.xyz>
Add a test where we do a conntrack lookup on an existing connection.
This is nice because it's a more realistic test than artifically
creating a ct entry and looking it up afterwards.
Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
.../testing/selftests/bpf/prog_tests/bpf_nf.c | 59 +++++++++++++++++++
.../testing/selftests/bpf/progs/test_bpf_nf.c | 18 ++++++
2 files changed, 77 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_nf.c b/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
index 7a74a1579076..88a2c0bdefec 100644
--- a/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_nf.c
@@ -24,10 +24,34 @@ enum {
TEST_TC_BPF,
};
+#define TIMEOUT_MS 3000
+
+static int connect_to_server(int srv_fd)
+{
+ int fd = -1;
+
+ fd = socket(AF_INET, SOCK_STREAM, 0);
+ if (!ASSERT_GE(fd, 0, "socket"))
+ goto out;
+
+ if (!ASSERT_EQ(connect_fd_to_fd(fd, srv_fd, TIMEOUT_MS), 0, "connect_fd_to_fd")) {
+ close(fd);
+ fd = -1;
+ }
+out:
+ return fd;
+}
+
static void test_bpf_nf_ct(int mode)
{
+ const char *iptables = "iptables -t raw %s PREROUTING -j CT";
+ int srv_fd = -1, client_fd = -1, srv_client_fd = -1;
+ struct sockaddr_in peer_addr = {};
struct test_bpf_nf *skel;
int prog_fd, err;
+ socklen_t len;
+ u16 srv_port;
+ char cmd[64];
LIBBPF_OPTS(bpf_test_run_opts, topts,
.data_in = &pkt_v4,
.data_size_in = sizeof(pkt_v4),
@@ -38,6 +62,32 @@ static void test_bpf_nf_ct(int mode)
if (!ASSERT_OK_PTR(skel, "test_bpf_nf__open_and_load"))
return;
+ /* Enable connection tracking */
+ snprintf(cmd, sizeof(cmd), iptables, "-A");
+ if (!ASSERT_OK(system(cmd), "iptables"))
+ goto end;
+
+ srv_port = (mode == TEST_XDP) ? 5005 : 5006;
+ srv_fd = start_server(AF_INET, SOCK_STREAM, "127.0.0.1", srv_port, TIMEOUT_MS);
+ if (!ASSERT_GE(srv_fd, 0, "start_server"))
+ goto end;
+
+ client_fd = connect_to_server(srv_fd);
+ if (!ASSERT_GE(client_fd, 0, "connect_to_server"))
+ goto end;
+
+ len = sizeof(peer_addr);
+ srv_client_fd = accept(srv_fd, (struct sockaddr *)&peer_addr, &len);
+ if (!ASSERT_GE(srv_client_fd, 0, "accept"))
+ goto end;
+ if (!ASSERT_EQ(len, sizeof(struct sockaddr_in), "sockaddr len"))
+ goto end;
+
+ skel->bss->saddr = peer_addr.sin_addr.s_addr;
+ skel->bss->sport = peer_addr.sin_port;
+ skel->bss->daddr = peer_addr.sin_addr.s_addr;
+ skel->bss->dport = htons(srv_port);
+
if (mode == TEST_XDP)
prog_fd = bpf_program__fd(skel->progs.nf_xdp_ct_test);
else
@@ -63,7 +113,16 @@ static void test_bpf_nf_ct(int mode)
ASSERT_LE(skel->bss->test_delta_timeout, 10, "Test for max ct timeout update");
/* expected status is IPS_SEEN_REPLY */
ASSERT_EQ(skel->bss->test_status, 2, "Test for ct status update ");
+ ASSERT_EQ(skel->data->test_exist_lookup, 0, "Test existing connection lookup");
end:
+ if (srv_client_fd != -1)
+ close(srv_client_fd);
+ if (client_fd != -1)
+ close(client_fd);
+ if (srv_fd != -1)
+ close(srv_fd);
+ snprintf(cmd, sizeof(cmd), iptables, "-D");
+ system(cmd);
test_bpf_nf__destroy(skel);
}
diff --git a/tools/testing/selftests/bpf/progs/test_bpf_nf.c b/tools/testing/selftests/bpf/progs/test_bpf_nf.c
index 196cd8dfe42a..84e0fd479794 100644
--- a/tools/testing/selftests/bpf/progs/test_bpf_nf.c
+++ b/tools/testing/selftests/bpf/progs/test_bpf_nf.c
@@ -23,6 +23,11 @@ int test_insert_entry = -EAFNOSUPPORT;
int test_succ_lookup = -ENOENT;
u32 test_delta_timeout = 0;
u32 test_status = 0;
+__be32 saddr = 0;
+__be16 sport = 0;
+__be32 daddr = 0;
+__be16 dport = 0;
+int test_exist_lookup = -ENOENT;
struct nf_conn;
@@ -160,6 +165,19 @@ nf_ct_test(struct nf_conn *(*lookup_fn)(void *, struct bpf_sock_tuple *, u32,
}
test_alloc_entry = 0;
}
+
+ bpf_tuple.ipv4.saddr = saddr;
+ bpf_tuple.ipv4.daddr = daddr;
+ bpf_tuple.ipv4.sport = sport;
+ bpf_tuple.ipv4.dport = dport;
+ ct = lookup_fn(ctx, &bpf_tuple, sizeof(bpf_tuple.ipv4), &opts_def,
+ sizeof(opts_def));
+ if (ct) {
+ test_exist_lookup = 0;
+ bpf_ct_release(ct);
+ } else {
+ test_exist_lookup = opts_def.error;
+ }
}
SEC("xdp")
--
2.37.1
^ permalink raw reply related
* Re: [PATCH bpf-next v3 0/3] Add more bpf_*_ct_lookup() selftests
From: Daniel Xu @ 2022-08-11 21:50 UTC (permalink / raw)
To: Kumar Kartikeya Dwivedi
Cc: bpf@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, linux-kernel, netdev, netfilter-devel, pablo, fw,
toke@redhat.com
In-Reply-To: <CAP01T74aWUW-iyPCV_VfASO6YqfAZmnkYQMN2B4L8ngMMgnAcw@mail.gmail.com>
Hi Kumar,
On Wed, Aug 10, 2022, at 6:25 PM, Kumar Kartikeya Dwivedi wrote:
> On Thu, 11 Aug 2022 at 01:16, Daniel Xu <dxu@dxuuu.xyz> wrote:
>>
>> This patchset adds more bpf_*_ct_lookup() selftests. The goal is to test
>> interaction with netfilter subsystem as well as reading from `struct
>> nf_conn`. The first is important when migrating legacy systems towards
>> bpf. The latter is important in general to take full advantage of
>> connection tracking.
>>
>
> Thank you for contributing these tests. Feel free to add:
> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>
> People often look at selftests for usage examples these days, so it's
> great to have coverage + examples for more use cases.
I also want this interaction to still work when I start using it later :).
>
>> I'll follow this patchset up with support for writing to `struct nf_conn`.
>>
>
> Please also cc netfilter-devel, netdev, Pablo, and Florian when you send it.
>
Ack.
> I think we can directly enable stores to ct->mark, since that is what
> ctnetlink is doing too, so adding another helper for this would be
> unnecessary overhead.
Ack.
[...]
Thanks,
Danel
^ permalink raw reply
* Re: [WIP v2] igc: fix deadlock caused by taking RTNL in RPM resume path
From: James Hogan @ 2022-08-11 21:41 UTC (permalink / raw)
To: Vinicius Costa Gomes
Cc: Vinicius Costa Gomes, Paul Menzel, Tony Nguyen, Jesse Brandeburg,
netdev, intel-wired-lan, Sasha Neftin, Aleksandr Loktionov
In-Reply-To: <20220811202524.78323-1-vinicius.gomes@intel.com>
On Thursday, 11 August 2022 21:25:24 BST Vinicius Costa Gomes wrote:
> It was reported a RTNL deadlock in the igc driver that was causing
> problems during suspend/resume.
>
> The solution is similar to commit ac8c58f5b535 ("igb: fix deadlock
> caused by taking RTNL in RPM resume path").
>
> Reported-by: James Hogan <jhogan@kernel.org>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
> ---
> Sorry for the noise earlier, my kernel config didn't have runtime PM
> enabled.
Thanks for looking into this.
This is identical to the patch I've been running for the last week. The
deadlock is avoided, however I now occasionally see an assertion from
netif_set_real_num_tx_queues due to the lock not being taken in some cases via
the runtime_resume path, and a suspicious rcu_dereference_protected() warning
(presumably due to the same issue of the lock not being taken). See here for
details:
https://lore.kernel.org/netdev/4765029.31r3eYUQgx@saruman/
Cheers
James
^ permalink raw reply
* Re: [PULL] Networking for 6.0-rc1
From: pr-tracker-bot @ 2022-08-11 21:32 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: torvalds, kuba, davem, netdev, linux-kernel, pabeni
In-Reply-To: <20220811185102.3253045-1-kuba@kernel.org>
The pull request you sent on Thu, 11 Aug 2022 11:51:02 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-6.0-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7ebfc85e2cd7b08f518b526173e9a33b56b3913b
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PULL] Networking for 6.0-rc1
From: Linus Torvalds @ 2022-08-11 21:25 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, linux-kernel, pabeni
In-Reply-To: <20220811124106.703917f8@kernel.org>
On Thu, Aug 11, 2022 at 12:41 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 11 Aug 2022 12:09:02 -0700 Jakub Kicinski wrote:
> > Let's put this one on hold, sorry. We got a report 2 minutes after
> > sending that one of the BT patches broke mips and csky builds :S
> > I'll try to get hold of Luiz and fix that up quickly.
>
> Can I take that back? I can't repro with the cross compiler
> from kernel.org. I'll follow up with the reported separately.
I've merged this, and don't see any new build issues, so please do
report separately.
Linus
^ permalink raw reply
* Re: build failure of next-20220811 due to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression")
From: Jakub Kicinski @ 2022-08-11 20:37 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Sudip Mukherjee (Codethink), Luiz Augusto von Dentz,
Johan Hedberg, Marcel Holtmann, David S. Miller, Eric Dumazet,
Paolo Abeni, Linux Kernel Mailing List,
open list:NETWORKING [GENERAL], linux-bluetooth@vger.kernel.org,
linux-next, Thomas Bogendoerfer, linux-mips
In-Reply-To: <CABBYNZKxM5Z2CUah1EB2uUDs=gEgDbrK0B9gbxeoyvtL6g=4+w@mail.gmail.com>
On Thu, 11 Aug 2022 13:20:52 -0700 Luiz Augusto von Dentz wrote:
> > +static inline int ba_is_any(const bdaddr_t *ba)
> > +{
> > + return memchr_inv(ba, sizeof(*ba), 0);
> > +}
>
> So we can't use something like BDADDR_ANY to compare? Anyway afaik
> these were already present before the patch so I do wonder what had
> trigger it show now or perhaps it was being suppressed before and
> since we change it now start showing again?
Yeah, I mentioned that in my previous reply as well, a quick grep
counts 70 instances, IDK what makes the l2cap code different :S
Then again I don't know how the compiler deals with passing a pointer
to a constant to an inline function.... so I figured memchr_inv()
could help us avoid hitting compiler bugs.
^ permalink raw reply
* [WIP v2] igc: fix deadlock caused by taking RTNL in RPM resume path
From: Vinicius Costa Gomes @ 2022-08-11 20:25 UTC (permalink / raw)
To: jhogan
Cc: Vinicius Costa Gomes, Paul Menzel, Tony Nguyen, Jesse Brandeburg,
netdev, intel-wired-lan, Sasha Neftin, Aleksandr Loktionov
In-Reply-To: <20220811151342.19059-1-vinicius.gomes@intel.com>
It was reported a RTNL deadlock in the igc driver that was causing
problems during suspend/resume.
The solution is similar to commit ac8c58f5b535 ("igb: fix deadlock
caused by taking RTNL in RPM resume path").
Reported-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
Sorry for the noise earlier, my kernel config didn't have runtime PM
enabled.
drivers/net/ethernet/intel/igc/igc_main.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index ebff0e04045d..9b0d4becfcfc 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -6600,7 +6600,7 @@ static void igc_deliver_wake_packet(struct net_device *netdev)
netif_rx(skb);
}
-static int __maybe_unused igc_resume(struct device *dev)
+static int __maybe_unused __igc_resume(struct device *dev, bool rpm)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct net_device *netdev = pci_get_drvdata(pdev);
@@ -6642,20 +6642,27 @@ static int __maybe_unused igc_resume(struct device *dev)
wr32(IGC_WUS, ~0);
- rtnl_lock();
+ if (!rpm)
+ rtnl_lock();
if (!err && netif_running(netdev))
err = __igc_open(netdev, true);
if (!err)
netif_device_attach(netdev);
- rtnl_unlock();
+ if (!rpm)
+ rtnl_unlock();
return err;
}
static int __maybe_unused igc_runtime_resume(struct device *dev)
{
- return igc_resume(dev);
+ return __igc_resume(dev, true);
+}
+
+static int __maybe_unused igc_resume(struct device *dev)
+{
+ return __igc_resume(dev, false);
}
static int __maybe_unused igc_suspend(struct device *dev)
@@ -6719,7 +6726,7 @@ static pci_ers_result_t igc_io_error_detected(struct pci_dev *pdev,
* @pdev: Pointer to PCI device
*
* Restart the card from scratch, as if from a cold-boot. Implementation
- * resembles the first-half of the igc_resume routine.
+ * resembles the first-half of the __igc_resume routine.
**/
static pci_ers_result_t igc_io_slot_reset(struct pci_dev *pdev)
{
@@ -6758,7 +6765,7 @@ static pci_ers_result_t igc_io_slot_reset(struct pci_dev *pdev)
*
* This callback is called when the error recovery driver tells us that
* its OK to resume normal operation. Implementation resembles the
- * second-half of the igc_resume routine.
+ * second-half of the __igc_resume routine.
*/
static void igc_io_resume(struct pci_dev *pdev)
{
--
2.37.1
^ permalink raw reply related
* Re: build failure of next-20220811 due to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression")
From: Luiz Augusto von Dentz @ 2022-08-11 20:20 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Sudip Mukherjee (Codethink), Luiz Augusto von Dentz,
Johan Hedberg, Marcel Holtmann, David S. Miller, Eric Dumazet,
Paolo Abeni, Linux Kernel Mailing List,
open list:NETWORKING [GENERAL], linux-bluetooth@vger.kernel.org,
linux-next, Thomas Bogendoerfer, linux-mips
In-Reply-To: <20220811124637.4cdb84f1@kernel.org>
Hi Jakub,
On Thu, Aug 11, 2022 at 12:59 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 11 Aug 2022 19:53:04 +0100 Sudip Mukherjee (Codethink) wrote:
> > Not sure if it has been reported, builds of csky and mips allmodconfig
> > failed to build next-20220811 with gcc-12.
>
> I can't repro with the cross compiler from kernel.org.
> Can you test something like this?
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index e72f3b247b5e..82bf8e01f7af 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -341,6 +341,11 @@ static inline bool bdaddr_type_is_le(u8 type)
> #define BDADDR_ANY (&(bdaddr_t) {{0, 0, 0, 0, 0, 0}})
> #define BDADDR_NONE (&(bdaddr_t) {{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}})
>
> +static inline int ba_is_any(const bdaddr_t *ba)
> +{
> + return memchr_inv(ba, sizeof(*ba), 0);
> +}
So we can't use something like BDADDR_ANY to compare? Anyway afaik
these were already present before the patch so I do wonder what had
trigger it show now or perhaps it was being suppressed before and
since we change it now start showing again?
> /* Copy, swap, convert BD Address */
> static inline int bacmp(const bdaddr_t *ba1, const bdaddr_t *ba2)
> {
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 77c0aac14539..a08ec272be4a 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -2001,8 +2001,8 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int state, __le16 psm,
> }
>
> /* Closest match */
> - src_any = !bacmp(&c->src, BDADDR_ANY);
> - dst_any = !bacmp(&c->dst, BDADDR_ANY);
> + src_any = !ba_is_any(&c->src);
> + dst_any = !ba_is_any(&c->dst);
> if ((src_match && dst_any) || (src_any && dst_match) ||
> (src_any && dst_any))
> c1 = c;
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [RFC net-next 1/4] ynl: add intro docs for the concept
From: Edward Cree @ 2022-08-11 20:17 UTC (permalink / raw)
To: Jakub Kicinski, netdev, davem, edumazet, pabeni
Cc: sdf, jacob.e.keller, vadfed, johannes, jiri, dsahern, stephen, fw,
linux-doc
In-Reply-To: <20220811022304.583300-2-kuba@kernel.org>
On 11/08/2022 03:23, Jakub Kicinski wrote:
> Short overview of the sections. I presume most people will start
> by copy'n'pasting existing schemas rather than studying the docs,
> but FWIW...
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
[...]
> +Operations describe the most common request - response communication. User
> +sends a request and kernel replies. Each operation may contain any combination
> +of the two modes familiar to netlink users - ``do`` and ``dump``.
> +``do`` and ``dump`` in turn contain a combination of ``request`` and ``response``
> +properties. If no explicit message with attributes is passed in a given
> +direction (e.g. a ``dump`` which doesn't not accept filter, or a ``do``
Double negative. I think you just meant "doesn't accept filter" here?
-ed
^ permalink raw reply
* Re: [RFC net-next 3/4] ynl: add a sample python library
From: Stephen Hemminger @ 2022-08-11 20:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, edumazet, pabeni, sdf, jacob.e.keller, vadfed,
johannes, jiri, dsahern, fw, linux-doc
In-Reply-To: <20220811022304.583300-4-kuba@kernel.org>
Looks interesting, you might want to consider running your code
through some of the existing Python checkers such as flake8 and pylint.
If you want this to be generally available in repos, best to follow the language conventions
For example flake8 noticed:
$ flake8 --max-line-length=120 ./tools/net/ynl/samples/ynl.py
./tools/net/ynl/samples/ynl.py:251:55: F821 undefined name 'file_name'
And pylint has more warnings
tools/net/ynl/samples/ynl.py:1:0: C0114: Missing module docstring (missing-module-docstring)
tools/net/ynl/samples/ynl.py:4:0: E0401: Unable to import 'jsonschema' (import-error)
tools/net/ynl/samples/ynl.py:16:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:16:0: R0903: Too few public methods (0/2) (too-few-public-methods)
tools/net/ynl/samples/ynl.py:49:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:57:4: C0116: Missing function or method docstring (missing-function-docstring)
tools/net/ynl/samples/ynl.py:60:4: C0116: Missing function or method docstring (missing-function-docstring)
tools/net/ynl/samples/ynl.py:63:4: C0116: Missing function or method docstring (missing-function-docstring)
tools/net/ynl/samples/ynl.py:70:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:70:0: R0903: Too few public methods (1/2) (too-few-public-methods)
tools/net/ynl/samples/ynl.py:84:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:84:0: R0902: Too many instance attributes (9/7) (too-many-instance-attributes)
tools/net/ynl/samples/ynl.py:84:0: R0903: Too few public methods (1/2) (too-few-public-methods)
tools/net/ynl/samples/ynl.py:109:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:109:0: R0903: Too few public methods (1/2) (too-few-public-methods)
tools/net/ynl/samples/ynl.py:123:0: C0103: Constant name "genl_family_name_to_id" doesn't conform to UPPER_CASE naming style (invalid-name)
tools/net/ynl/samples/ynl.py:147:8: W0603: Using the global statement (global-statement)
tools/net/ynl/samples/ynl.py:147:8: C0103: Constant name "genl_family_name_to_id" doesn't conform to UPPER_CASE naming style (invalid-name)
tools/net/ynl/samples/ynl.py:148:33: R1735: Consider using {} instead of dict() (use-dict-literal)
tools/net/ynl/samples/ynl.py:160:16: C0103: Variable name "gm" doesn't conform to snake_case naming style (invalid-name)
tools/net/ynl/samples/ynl.py:174:8: C0103: Attribute name "nl" doesn't conform to snake_case naming style (invalid-name)
tools/net/ynl/samples/ynl.py:172:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:186:12: C0103: Variable name "a" doesn't conform to snake_case naming style (invalid-name)
tools/net/ynl/samples/ynl.py:172:0: R0903: Too few public methods (1/2) (too-few-public-methods)
tools/net/ynl/samples/ynl.py:191:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:195:8: W0602: Using global for 'genl_family_name_to_id' but no assignment is done (global-variable-not-assigned)
tools/net/ynl/samples/ynl.py:195:8: C0103: Constant name "genl_family_name_to_id" doesn't conform to UPPER_CASE naming style (invalid-name)
tools/net/ynl/samples/ynl.py:191:0: R0903: Too few public methods (0/2) (too-few-public-methods)
tools/net/ynl/samples/ynl.py:206:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:207:31: W0621: Redefining name 'yaml' from outer scope (line 8) (redefined-outer-name)
tools/net/ynl/samples/ynl.py:210:21: R1735: Consider using {} instead of dict() (use-dict-literal)
tools/net/ynl/samples/ynl.py:207:23: W0613: Unused argument 'family' (unused-argument)
tools/net/ynl/samples/ynl.py:241:4: C0116: Missing function or method docstring (missing-function-docstring)
tools/net/ynl/samples/ynl.py:245:0: C0115: Missing class docstring (missing-class-docstring)
tools/net/ynl/samples/ynl.py:247:13: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
tools/net/ynl/samples/ynl.py:251:17: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
tools/net/ynl/samples/ynl.py:251:54: E0602: Undefined variable 'file_name' (undefined-variable)
tools/net/ynl/samples/ynl.py:259:20: R1735: Consider using {} instead of dict() (use-dict-literal)
tools/net/ynl/samples/ynl.py:260:23: R1735: Consider using {} instead of dict() (use-dict-literal)
tools/net/ynl/samples/ynl.py:302:14: R1735: Consider using {} instead of dict() (use-dict-literal)
tools/net/ynl/samples/ynl.py:317:8: C0103: Variable name "op" doesn't conform to snake_case naming style (invalid-name)
tools/net/ynl/samples/ynl.py:340:16: C0103: Variable name "gm" doesn't conform to snake_case naming style (invalid-name)
tools/net/ynl/samples/ynl.py:316:4: R1710: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)
tools/net/ynl/samples/ynl.py:245:0: R0903: Too few public methods (0/2) (too-few-public-methods)
tools/net/ynl/samples/ynl.py:5:0: C0411: standard import "import random" should be placed before "import jsonschema" (wrong-import-order)
tools/net/ynl/samples/ynl.py:6:0: C0411: standard import "import socket" should be placed before "import jsonschema" (wrong-import-order)
tools/net/ynl/samples/ynl.py:7:0: C0411: standard import "import struct" should be placed before "import jsonschema" (wrong-import-order)
tools/net/ynl/samples/ynl.py:9:0: C0411: standard import "import os" should be placed before "import jsonschema" (wrong-import-order)
------------------------------------------------------------------
Your code has been rated at 7.64/10 (previous run: 7.64/10, +0.00)
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igc: fix deadlock caused by taking RTNL in RPM resume path
From: kernel test robot @ 2022-08-11 19:59 UTC (permalink / raw)
To: Vinicius Costa Gomes, jhogan
Cc: kbuild-all, Paul Menzel, netdev, Jesse Brandeburg,
Aleksandr Loktionov, intel-wired-lan
In-Reply-To: <20220811151342.19059-1-vinicius.gomes@intel.com>
Hi Vinicius,
I love your patch! Yet something to improve:
[auto build test ERROR on tnguy-next-queue/dev-queue]
[also build test ERROR on linus/master v5.19 next-20220811]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Vinicius-Costa-Gomes/igc-fix-deadlock-caused-by-taking-RTNL-in-RPM-resume-path/20220811-232032
base: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue
config: x86_64-rhel-8.3-kselftests (https://download.01.org/0day-ci/archive/20220812/202208120359.pPxeIJNZ-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
# https://github.com/intel-lab-lkp/linux/commit/61ed7ed758f23a10549c5d4fdc82ef9356281cbf
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Vinicius-Costa-Gomes/igc-fix-deadlock-caused-by-taking-RTNL-in-RPM-resume-path/20220811-232032
git checkout 61ed7ed758f23a10549c5d4fdc82ef9356281cbf
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from arch/x86/include/asm/percpu.h:27,
from arch/x86/include/asm/nospec-branch.h:14,
from arch/x86/include/asm/paravirt_types.h:40,
from arch/x86/include/asm/ptrace.h:97,
from arch/x86/include/asm/math_emu.h:5,
from arch/x86/include/asm/processor.h:13,
from arch/x86/include/asm/timex.h:5,
from include/linux/timex.h:67,
from include/linux/time32.h:13,
from include/linux/time.h:60,
from include/linux/stat.h:19,
from include/linux/module.h:13,
from drivers/net/ethernet/intel/igc/igc_main.c:4:
>> drivers/net/ethernet/intel/igc/igc_main.c:6838:33: error: 'igc_suspend' undeclared here (not in a function); did you mean 'dpm_suspend'?
6838 | SET_SYSTEM_SLEEP_PM_OPS(igc_suspend, igc_resume)
| ^~~~~~~~~~~
include/linux/kernel.h:57:44: note: in definition of macro 'PTR_IF'
57 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL)
| ^~~
include/linux/pm.h:313:20: note: in expansion of macro 'pm_sleep_ptr'
313 | .suspend = pm_sleep_ptr(suspend_fn), \
| ^~~~~~~~~~~~
include/linux/pm.h:343:9: note: in expansion of macro 'SYSTEM_SLEEP_PM_OPS'
343 | SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
| ^~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/igc/igc_main.c:6838:9: note: in expansion of macro 'SET_SYSTEM_SLEEP_PM_OPS'
6838 | SET_SYSTEM_SLEEP_PM_OPS(igc_suspend, igc_resume)
| ^~~~~~~~~~~~~~~~~~~~~~~
vim +6838 drivers/net/ethernet/intel/igc/igc_main.c
bc23aa949aeba0 Sasha Neftin 2020-01-29 6835
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6836 #ifdef CONFIG_PM
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6837 static const struct dev_pm_ops igc_pm_ops = {
9513d2a5dc7f3f Sasha Neftin 2019-11-14 @6838 SET_SYSTEM_SLEEP_PM_OPS(igc_suspend, igc_resume)
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6839 SET_RUNTIME_PM_OPS(igc_runtime_suspend, igc_runtime_resume,
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6840 igc_runtime_idle)
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6841 };
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6842 #endif
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6843
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* Re: build failure of next-20220811 due to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression")
From: Jakub Kicinski @ 2022-08-11 19:46 UTC (permalink / raw)
To: Sudip Mukherjee (Codethink)
Cc: Luiz Augusto von Dentz, Johan Hedberg, Marcel Holtmann,
David S. Miller, Eric Dumazet, Paolo Abeni, linux-kernel, netdev,
linux-bluetooth, linux-next, Thomas Bogendoerfer, linux-mips
In-Reply-To: <YvVQEDs75pxSgxjM@debian>
On Thu, 11 Aug 2022 19:53:04 +0100 Sudip Mukherjee (Codethink) wrote:
> Not sure if it has been reported, builds of csky and mips allmodconfig
> failed to build next-20220811 with gcc-12.
I can't repro with the cross compiler from kernel.org.
Can you test something like this?
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index e72f3b247b5e..82bf8e01f7af 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -341,6 +341,11 @@ static inline bool bdaddr_type_is_le(u8 type)
#define BDADDR_ANY (&(bdaddr_t) {{0, 0, 0, 0, 0, 0}})
#define BDADDR_NONE (&(bdaddr_t) {{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}})
+static inline int ba_is_any(const bdaddr_t *ba)
+{
+ return memchr_inv(ba, sizeof(*ba), 0);
+}
+
/* Copy, swap, convert BD Address */
static inline int bacmp(const bdaddr_t *ba1, const bdaddr_t *ba2)
{
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 77c0aac14539..a08ec272be4a 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -2001,8 +2001,8 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int state, __le16 psm,
}
/* Closest match */
- src_any = !bacmp(&c->src, BDADDR_ANY);
- dst_any = !bacmp(&c->dst, BDADDR_ANY);
+ src_any = !ba_is_any(&c->src);
+ dst_any = !ba_is_any(&c->dst);
if ((src_match && dst_any) || (src_any && dst_match) ||
(src_any && dst_any))
c1 = c;
^ permalink raw reply related
* Re: ethernet<n> dt aliases implications in U-Boot and Linux
From: Sean Anderson @ 2022-08-11 19:43 UTC (permalink / raw)
To: Michal Suchánek, Andrew Lunn
Cc: Tim Harvey, Pali Rohár, Stephen Hemminger, netdev, u-boot,
Device Tree Mailing List
In-Reply-To: <20220810153510.GS17705@kitsune.suse.cz>
On 8/10/22 11:35 AM, Michal Suchánek wrote:
> On Wed, Aug 10, 2022 at 05:17:56PM +0200, Andrew Lunn wrote:
>> > > I guess you are new to the netdev list :-)
>> > >
>> > > This is one of those FAQ sort of things, discussed every
>> > > year. Anything like this is always NACKed. I don't see why this time
>> > > should be any different.
>> > >
>> > > DSA is somewhat special because it is very old. It comes from before
>> > > the times of DT. Its DT binding was proposed relatively earl in DT
>> > > times, and would be rejected in modern days. But the rules of ABI mean
>> > > the label property will be valid forever. But i very much doubt it
>> > > will spread to interfaces in general.
>> >
>> > And if this is a FAQ maybe you can point to a summary (perhaps in
>> > previous mail discusssion) that explains how to provide stable interface
>> > names for Ethernet devices on a DT based platform?
>>
>> As far so the kernel is concerned, interface names are unstable. They
>> have never been truly stable, but they have got more unstable in the
>> past decade with multiple busses being probed in parallel, which did
>> not happen before so much.
>>
>> > On x86 there is a name derived from the device location in the bus
>> > topology
>>
>> This is nothing to do with x86. That is userspace, e.g. systemd,
>> renaming the interfaces. This applies for any architecture for which
>> systemd runs on.
>>
>> > which may be somewhat stable but it is not clear that it
>> > cannot change, and there is an optional BIOS provided table that can
>> > asssign meaningful names to the interfaces.
>>
>> I doubt the kernel is looking at ACPI tables. It is user space which
>> does that.
>>
>> The kernel provides udev with a bunch of information about the
>> interface, its bus location, MAC address, etc. Userspace can then
>> decide what it wants to call it, and what its alternative names are,
>> etc.
>>
>> Also, this is not just a network interface name problem. Any device
>> with a number/letter in it is unstable. I2C bus devices: i2c0,
>> i2c1... SPI bus deviceS: spi0, spi1...,
>
> Thees do have numbered aliases in the DT. I don't know if the kernel
> uses them for anything.
This is an issue for serial devices IMO. The only way to specify a
stable console is to use its address! Things like /dev/ttyS0 can
easily be reordered just by plugging/unplugging a card. You can of
course add a udev rule to create some stable symlinks, but that's
too late.
>> Block devices, sda, sdb, sdc,
>
> These too, at least mmc.
Which I am very grateful exists. While the block device situation is
not as bad due to e.g. /dev/block/by-foo, it's still nice to be able
to have a consistent name.
--Sean
^ permalink raw reply
* Re: [RFC net-next 0/4] ynl: YAML netlink protocol descriptions
From: Jakub Kicinski @ 2022-08-11 19:42 UTC (permalink / raw)
To: sdf
Cc: Stephen Hemminger, netdev, davem, edumazet, pabeni,
jacob.e.keller, vadfed, johannes, jiri, dsahern, fw, linux-doc,
Michal Kubecek
In-Reply-To: <YvUuPU8dMSvv2tdJ@google.com>
On Thu, 11 Aug 2022 09:28:45 -0700 sdf@google.com wrote:
> Putting it into iproute2 will make it carry a 'networking' badge on it
> meaning no other subsystem would look into it.
Good point.
> I'd rather make netlink more generic (s/netlink/kernelink/?) and remove
> CONFIG_NET dependency to address https://lwn.net/Articles/897202/
I think people just use that as an excuse, TBH.
^ permalink raw reply
* Re: [PULL] Networking for 6.0-rc1
From: Jakub Kicinski @ 2022-08-11 19:41 UTC (permalink / raw)
To: torvalds; +Cc: davem, netdev, linux-kernel, pabeni
In-Reply-To: <20220811120902.7e82826a@kernel.org>
On Thu, 11 Aug 2022 12:09:02 -0700 Jakub Kicinski wrote:
> Let's put this one on hold, sorry. We got a report 2 minutes after
> sending that one of the BT patches broke mips and csky builds :S
> I'll try to get hold of Luiz and fix that up quickly.
Can I take that back? I can't repro with the cross compiler
from kernel.org. I'll follow up with the reported separately.
^ permalink raw reply
* Re: [RFC net-next 4/4] ynl: add a sample user for ethtool
From: Jakub Kicinski @ 2022-08-11 19:35 UTC (permalink / raw)
To: sdf
Cc: netdev, davem, edumazet, pabeni, jacob.e.keller, vadfed, johannes,
jiri, dsahern, stephen, fw, linux-doc
In-Reply-To: <YvUru3QvN/LuYgnq@google.com>
On Thu, 11 Aug 2022 09:18:03 -0700 sdf@google.com wrote:
> > +attr-cnt-suffix: CNT
>
> Is it a hack to make the generated header fit into existing
> implementation?
Yup.
> Should we #define ETHTOOL_XXX_CNT ETHTOOL_XXX in
> the implementation instead? (or s/ETHTOOL_XXX_CNT/ETHTOOL_XXX/ the
> source itself?)
We could, I guess. To be clear this controls the count, IOW:
enum {
PREFIX_A_BLA_ATTR = 1,
PREFIX_A_ANOTHER_ATTR,
PREFIX_A_AND_ONEMORE,
__PFREIX_A_CNT, // <--- This thing
};
#define PREFIX_A_MAX (__PFREIX_A_CNT - 1)
It's not used in the generated code, only if we codegen the uAPI,
AFAIR. So we'd need a way to tell the generator of the uAPI about
the situation, anyway. I could be misremembering.
> > +attribute-spaces:
>
> Are you open to bike shedding? :-)
I can't make promises that I'll change things but I'm curious
to hear it!
> I like how ethtool_netlink.h calls these 'message types'.
It calls operation types message types, not attr spaces.
I used ops because that's what genetlink calls things.
> > + -
> > + name: header
> > + name-prefix: ETHTOOL_A_HEADER_
>
> Any issue with name-prefix+name-suffix being non-greppable? Have you tried
> something like this instead:
>
> - name: ETHTOOL_A_HEADER # this is fake, for ynl reference only
> attributes:
> - name: ETHTOOL_A_HEADER_DEV_INDEX
> val:
> type:
> - name ETHTOOL_A_HEADER_DEV_NAME
> ..
>
> It seems a bit easier to map the spec into what it's going to produce.
> For example, it took me a while to translate 'channels_get' below into
> ETHTOOL_MSG_CHANNELS_GET.
>
> Or is it too much ETHTOOL_A_HEADER_?
Dunno, that'd mean that the Python method is called
ETHTOOL_MSG_CHANNELS_GET rather than just channels_get.
I don't want to force all languages to use the C naming.
The C naming just leads to silly copy'n'paste issues like
f329a0ebeab.
> > + len: ALTIFNAMSIZ - 1
>
> Not sure how strict you want to be here. ALTIFNAMSIZ is defined
> somewhere else it seems? (IOW, do we want to have implicit dependencies
> on external/uapi headers?)
Good catch, I'm aware. I was planning to add a "header constants"
section or some such. A section in "headers" which defines the
constants which C code will get from the headers.
For Python it does not matter, as we don't have to size arrays.
I was wondering if it will matter for other languages, like Rust?
> > + - header
> > + - rx_count
> > + - tx_count
> > + - other_count
> > + - combined_count
>
> My netlink is super rusty, might be worth mentioning in the spec: these
> are possible attributes, but are all of them required?
Right, will do, nothing is required, or rather requirements are kinda
hard to express and checked by the code in the kernel.
> You also mention the validation part in the cover letter, do you plan
> add some of these policy properties to the spec or everything is
> there already? (I'm assuming we care about the types which we have above and
> optional/required attribute indication?)
Yeah, my initial plan was to encode requirement in the policy but its
not trivial. So I left it as future extension. Besides things which are
required today may not be tomorrow, so its a bit of a strange thing.
Regarding policy properties I'm intending to support all of the stuff
that the kernel policies recognize... but somehow most families I
converted don't have validation (only mask and length :S).
Actually for DPLL I have a nice validation trick. You can define an
enum:
constants:
-
type: flags
name: genl_get_flags
value-prefix: DPLL_FLAG_
values: [ sources, outputs, status ]
Then for an attribute you link it:
-
name: flags
type: u32
flags-mask: genl_get_flags
And that will auto an enum:
enum dpll_genl_get_flags {
DPLL_FLAG_SOURCES = 1,
DPLL_FLAG_OUTPUTS = 2,
DPLL_FLAG_STATUS = 4,
};
And a policy with a mask:
[DPLLA_FLAGS] = NLA_POLICY_MASK(NLA_U32, 0x7),
^ permalink raw reply
* Re: [PULL] Networking for 6.0-rc1
From: Jakub Kicinski @ 2022-08-11 19:09 UTC (permalink / raw)
To: torvalds; +Cc: davem, netdev, linux-kernel, pabeni
In-Reply-To: <20220811185102.3253045-1-kuba@kernel.org>
On Thu, 11 Aug 2022 11:51:02 -0700 Jakub Kicinski wrote:
> The following changes since commit f86d1fbbe7858884d6754534a0afbb74fc30bc26:
>
> Merge tag 'net-next-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next (2022-08-03 16:29:08 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-6.0-rc1
>
> for you to fetch changes up to c2e75634cbe368065f140dd30bf8b1a0355158fd:
>
> net: atm: bring back zatm uAPI (2022-08-11 10:31:19 -0700)
Let's put this one on hold, sorry. We got a report 2 minutes after
sending that one of the BT patches broke mips and csky builds :S
I'll try to get hold of Luiz and fix that up quickly.
Speaking of build problems after merging with your tree I run into
-Werror,-Wframe-larger-than on the AMD GPU drivers (gcc and clang, both).
Quick search of lore does not show any hits.
^ permalink raw reply
* Re: build failure of next-20220811 due to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression")
From: Jakub Kicinski @ 2022-08-11 19:05 UTC (permalink / raw)
To: Sudip Mukherjee (Codethink)
Cc: Luiz Augusto von Dentz, Johan Hedberg, Marcel Holtmann,
David S. Miller, Eric Dumazet, Paolo Abeni, linux-kernel, netdev,
linux-bluetooth, linux-next, Thomas Bogendoerfer, linux-mips
In-Reply-To: <YvVQEDs75pxSgxjM@debian>
On Thu, 11 Aug 2022 19:53:04 +0100 Sudip Mukherjee (Codethink) wrote:
> Hi All,
>
> Not sure if it has been reported, builds of csky and mips allmodconfig
> failed to build next-20220811 with gcc-12.
Heh, 2 minutes after I submitted it to Linus :S
> mips error is:
>
> In function 'memcmp',
> inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9,
> inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:
> ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
Source is the second argument? memcmp does not really have src and dst..
Assuming it's the second one it appears to object to the:
#define BDADDR_ANY (&(bdaddr_t) {{0, 0, 0, 0, 0, 0}})
Which, well, kinda understandable but why does it not dislike the same
construct when used in the other 70 places in the tree?
My preferred fix would be to do the same thing as we do for ethernet
i.e. open code the helper, see is_zero_ether_addr().
> 44 | #define __underlying_memcmp __builtin_memcmp
> | ^
> ./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp'
> 420 | return __underlying_memcmp(p, q, size);
> | ^~~~~~~~~~~~~~~~~~~
> In function 'memcmp',
> inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9,
> inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2004:15:
> ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> 44 | #define __underlying_memcmp __builtin_memcmp
> | ^
> ./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp'
> 420 | return __underlying_memcmp(p, q, size);
> | ^~~~~~~~~~~~~~~~~~~
>
>
> csky error is:
>
> In file included from net/bluetooth/l2cap_core.c:37:
> In function 'bacmp',
> inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:
> ./include/net/bluetooth/bluetooth.h:347:16: error: 'memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> 347 | return memcmp(ba1, ba2, sizeof(bdaddr_t));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In function 'bacmp',
> inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2004:15:
> ./include/net/bluetooth/bluetooth.h:347:16: error: 'memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
> 347 | return memcmp(ba1, ba2, sizeof(bdaddr_t));
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> git bisect pointed to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression").
> And, reverting that commit has fixed the build failure.
>
> I will be happy to test any patch or provide any extra log if needed.
>
> --
> Regards
> Sudip
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igc: fix deadlock caused by taking RTNL in RPM resume path
From: kernel test robot @ 2022-08-11 18:58 UTC (permalink / raw)
To: Vinicius Costa Gomes, jhogan
Cc: llvm, kbuild-all, Paul Menzel, netdev, Jesse Brandeburg,
Aleksandr Loktionov, intel-wired-lan
In-Reply-To: <20220811151342.19059-1-vinicius.gomes@intel.com>
Hi Vinicius,
I love your patch! Yet something to improve:
[auto build test ERROR on tnguy-next-queue/dev-queue]
[also build test ERROR on linus/master v5.19 next-20220811]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Vinicius-Costa-Gomes/igc-fix-deadlock-caused-by-taking-RTNL-in-RPM-resume-path/20220811-232032
base: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue
config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20220812/202208120244.a7CKRiFy-lkp@intel.com/config)
compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 5f1c7e2cc5a3c07cbc2412e851a7283c1841f520)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/61ed7ed758f23a10549c5d4fdc82ef9356281cbf
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Vinicius-Costa-Gomes/igc-fix-deadlock-caused-by-taking-RTNL-in-RPM-resume-path/20220811-232032
git checkout 61ed7ed758f23a10549c5d4fdc82ef9356281cbf
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/net/ethernet/intel/igc/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/intel/igc/igc_main.c:6838:26: error: use of undeclared identifier 'igc_suspend'; did you mean '__igc_suspend'?
SET_SYSTEM_SLEEP_PM_OPS(igc_suspend, igc_resume)
^~~~~~~~~~~
__igc_suspend
include/linux/pm.h:343:22: note: expanded from macro 'SET_SYSTEM_SLEEP_PM_OPS'
SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
^
include/linux/pm.h:313:26: note: expanded from macro 'SYSTEM_SLEEP_PM_OPS'
.suspend = pm_sleep_ptr(suspend_fn), \
^
include/linux/pm.h:439:65: note: expanded from macro 'pm_sleep_ptr'
#define pm_sleep_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM_SLEEP), (_ptr))
^
include/linux/kernel.h:57:38: note: expanded from macro 'PTR_IF'
#define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL)
^
drivers/net/ethernet/intel/igc/igc_main.c:6706:27: note: '__igc_suspend' declared here
static int __maybe_unused __igc_suspend(struct device *dev)
^
>> drivers/net/ethernet/intel/igc/igc_main.c:6838:26: error: use of undeclared identifier 'igc_suspend'; did you mean '__igc_suspend'?
SET_SYSTEM_SLEEP_PM_OPS(igc_suspend, igc_resume)
^~~~~~~~~~~
__igc_suspend
include/linux/pm.h:343:22: note: expanded from macro 'SET_SYSTEM_SLEEP_PM_OPS'
SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
^
include/linux/pm.h:315:25: note: expanded from macro 'SYSTEM_SLEEP_PM_OPS'
.freeze = pm_sleep_ptr(suspend_fn), \
^
include/linux/pm.h:439:65: note: expanded from macro 'pm_sleep_ptr'
#define pm_sleep_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM_SLEEP), (_ptr))
^
include/linux/kernel.h:57:38: note: expanded from macro 'PTR_IF'
#define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL)
^
drivers/net/ethernet/intel/igc/igc_main.c:6706:27: note: '__igc_suspend' declared here
static int __maybe_unused __igc_suspend(struct device *dev)
^
>> drivers/net/ethernet/intel/igc/igc_main.c:6838:26: error: use of undeclared identifier 'igc_suspend'; did you mean '__igc_suspend'?
SET_SYSTEM_SLEEP_PM_OPS(igc_suspend, igc_resume)
^~~~~~~~~~~
__igc_suspend
include/linux/pm.h:343:22: note: expanded from macro 'SET_SYSTEM_SLEEP_PM_OPS'
SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
^
include/linux/pm.h:317:27: note: expanded from macro 'SYSTEM_SLEEP_PM_OPS'
.poweroff = pm_sleep_ptr(suspend_fn), \
^
include/linux/pm.h:439:65: note: expanded from macro 'pm_sleep_ptr'
#define pm_sleep_ptr(_ptr) PTR_IF(IS_ENABLED(CONFIG_PM_SLEEP), (_ptr))
^
include/linux/kernel.h:57:38: note: expanded from macro 'PTR_IF'
#define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL)
^
drivers/net/ethernet/intel/igc/igc_main.c:6706:27: note: '__igc_suspend' declared here
static int __maybe_unused __igc_suspend(struct device *dev)
^
3 errors generated.
vim +6838 drivers/net/ethernet/intel/igc/igc_main.c
bc23aa949aeba0 Sasha Neftin 2020-01-29 6835
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6836 #ifdef CONFIG_PM
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6837 static const struct dev_pm_ops igc_pm_ops = {
9513d2a5dc7f3f Sasha Neftin 2019-11-14 @6838 SET_SYSTEM_SLEEP_PM_OPS(igc_suspend, igc_resume)
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6839 SET_RUNTIME_PM_OPS(igc_runtime_suspend, igc_runtime_resume,
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6840 igc_runtime_idle)
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6841 };
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6842 #endif
9513d2a5dc7f3f Sasha Neftin 2019-11-14 6843
--
0-DAY CI Kernel Test Service
https://01.org/lkp
^ permalink raw reply
* build failure of next-20220811 due to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression")
From: Sudip Mukherjee (Codethink) @ 2022-08-11 18:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Johan Hedberg, Marcel Holtmann,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: linux-kernel, netdev, linux-bluetooth, linux-next,
Thomas Bogendoerfer, linux-mips
Hi All,
Not sure if it has been reported, builds of csky and mips allmodconfig
failed to build next-20220811 with gcc-12.
mips error is:
In function 'memcmp',
inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9,
inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:
./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
44 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp'
420 | return __underlying_memcmp(p, q, size);
| ^~~~~~~~~~~~~~~~~~~
In function 'memcmp',
inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9,
inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2004:15:
./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
44 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp'
420 | return __underlying_memcmp(p, q, size);
| ^~~~~~~~~~~~~~~~~~~
csky error is:
In file included from net/bluetooth/l2cap_core.c:37:
In function 'bacmp',
inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15:
./include/net/bluetooth/bluetooth.h:347:16: error: 'memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
347 | return memcmp(ba1, ba2, sizeof(bdaddr_t));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'bacmp',
inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2004:15:
./include/net/bluetooth/bluetooth.h:347:16: error: 'memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
347 | return memcmp(ba1, ba2, sizeof(bdaddr_t));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
git bisect pointed to 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression").
And, reverting that commit has fixed the build failure.
I will be happy to test any patch or provide any extra log if needed.
--
Regards
Sudip
^ 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