* Re: [PATCH net-next 0/6] DSA cross-chip notifier cleanups
From: patchwork-bot+netdevbpf @ 2022-04-20 9:40 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev, kuba, davem, pabeni, f.fainelli, andrew, vivien.didelot,
olteanv
In-Reply-To: <20220415154626.345767-1-vladimir.oltean@nxp.com>
Hello:
This series was applied to netdev/net-next.git (master)
by David S. Miller <davem@davemloft.net>:
On Fri, 15 Apr 2022 18:46:20 +0300 you wrote:
> This patch set makes the following improvements:
>
> - Cross-chip notifiers pass a switch index, port index, sometimes tree
> index, all as integers. Sometimes we need to recover the struct
> dsa_port based on those integers. That recovery involves traversing a
> list. By passing directly a pointer to the struct dsa_port we can
> avoid that, and the indices passed previously can still be obtained
> from the passed struct dsa_port.
>
> [...]
Here is the summary with links:
- [net-next,1/6] net: dsa: move reset of VLAN filtering to dsa_port_switchdev_unsync_attrs
https://git.kernel.org/netdev/net-next/c/8e9e678e4758
- [net-next,2/6] net: dsa: make cross-chip notifiers more efficient for host events
https://git.kernel.org/netdev/net-next/c/726816a129cb
- [net-next,3/6] net: dsa: use dsa_tree_for_each_user_port in dsa_slave_change_mtu
https://git.kernel.org/netdev/net-next/c/b2033a05a719
- [net-next,4/6] net: dsa: avoid one dsa_to_port() in dsa_slave_change_mtu
https://git.kernel.org/netdev/net-next/c/cf1c39d3b3a5
- [net-next,5/6] net: dsa: drop dsa_slave_priv from dsa_slave_change_mtu
https://git.kernel.org/netdev/net-next/c/4715029fa7e9
- [net-next,6/6] net: dsa: don't emit targeted cross-chip notifiers for MTU change
https://git.kernel.org/netdev/net-next/c/be6ff9665d64
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] doc/ip-sysctl: add bc_forwarding
From: patchwork-bot+netdevbpf @ 2022-04-20 9:40 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: davem, kuba, pabeni, corbet, lucien.xin, netdev, linux-doc
In-Reply-To: <20220413140000.23648-1-nicolas.dichtel@6wind.com>
Hello:
This patch was applied to netdev/net.git (master)
by David S. Miller <davem@davemloft.net>:
On Wed, 13 Apr 2022 16:00:00 +0200 you wrote:
> Let's describe this sysctl.
>
> Fixes: 5cbf777cfdf6 ("route: add support for directed broadcast forwarding")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> Documentation/networking/ip-sysctl.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
Here is the summary with links:
- [net] doc/ip-sysctl: add bc_forwarding
https://git.kernel.org/netdev/net/c/c6a4254c18c6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFCv6 PATCH net-next 01/19] net: introduce operation helpers for netdev features
From: shenjian (K) @ 2022-04-20 9:24 UTC (permalink / raw)
To: Alexander Lobakin
Cc: davem, kuba, andrew, ecree.xilinx, hkallweit1, saeed, leon,
netdev, linuxarm, lipeng321
In-Reply-To: <20220419144045.1664765-1-alexandr.lobakin@intel.com>
在 2022/4/19 22:40, Alexander Lobakin 写道:
> From: Jian Shen <shenjian15@huawei.com>
> Date: Tue, 19 Apr 2022 10:21:48 +0800
>
>> Introduce a set of bitmap operation helpers for netdev features,
>> then we can use them to replace the logical operation with them.
>> As the nic driversare not supposed to modify netdev_features
>> directly, it also introduces wrappers helpers to this.
>>
>> The implementation of these helpers are based on the old prototype
>> of netdev_features_t is still u64. I will rewrite them on the last
>> patch, when the prototype changes.
>>
>> To avoid interdependencies between netdev_features_helper.h and
>> netdevice.h, put the helpers for testing feature is set in the
>> netdevice.h, and move advandced helpers like
>> netdev_get_wanted_features() and netdev_intersect_features() to
>> netdev_features_helper.h.
>>
>> Signed-off-by: Jian Shen <shenjian15@huawei.com>
>> ---
>> .../net/ethernet/netronome/nfp/nfp_net_repr.c | 1 +
>> include/linux/netdev_features.h | 12 +
>> include/linux/netdev_features_helper.h | 604 ++++++++++++++++++
>> include/linux/netdevice.h | 45 +-
>> net/8021q/vlan_dev.c | 1 +
>> net/core/dev.c | 1 +
>> 6 files changed, 646 insertions(+), 18 deletions(-)
>> create mode 100644 include/linux/netdev_features_helper.h
>>
>> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
>> index ba3fa7eac98d..08f2c54e0a11 100644
>> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
>> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
>> @@ -4,6 +4,7 @@
>> #include <linux/etherdevice.h>
>> #include <linux/io-64-nonatomic-hi-lo.h>
>> #include <linux/lockdep.h>
>> +#include <linux/netdev_features_helper.h>
>> #include <net/dst_metadata.h>
>>
>> #include "nfpcore/nfp_cpp.h"
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 2c6b9e416225..e2b66fa3d7d6 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -11,6 +11,18 @@
>>
>> typedef u64 netdev_features_t;
>>
>> +struct netdev_feature_set {
>> + unsigned int cnt;
>> + unsigned short feature_bits[];
>> +};
>> +
>> +#define DECLARE_NETDEV_FEATURE_SET(name, features...) \
>> + static unsigned short __##name##_s[] = {features}; \
>> + struct netdev_feature_set name = { \
> I suggest using `const` here. Those sets are needed only to
> initialize bitmaps, that's it. They are not supposed to be
> modified. This would be one more hardening here to avoid some weird
> usages of sets, and also would place them in .rodata instead of just
> .data.
>
> Function old new delta
> main 35 33 -2
> Total: Before=78, After=76, chg -2.56%
> add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-14 (-14)
> Data old new delta
> arr1 6 - -6
> arr2 8 - -8
> Total: Before=15, After=1, chg -93.33%
> add/remove: 2/0 grow/shrink: 0/0 up/down: 14/0 (14)
> RO Data old new delta
> arr1 - 8 +8
> arr2 - 6 +6
> Total: Before=36, After=50, chg +38.89%
>
> As you can see, there's a 2-byte code optimization. And that was
> just a simpliest oneliner. The gains will be much bigger from the
> real usages.
thanks, will add it.
>> + .cnt = ARRAY_SIZE(__##name##_s), \
>> + .feature_bits = {features}, \
>> + }
> The problem with the current macro is that it doesn't allow to
> declare feature sets as static. Because the temporary array for
> counting the number of bits goes first, and doing
>
> static DECLARE_NETDEV_FEATURE_SET();
>
> wouldn't change anything.
Yes, it bothered me.
> But we want to have most feature sets static as they will be needed
> only inside one file. Making every of them global would hurt
> optimization.
>
> At the end, I came to
>
> #define DECLARE_NETDEV_FEATURE_SET(name, features...) \
> const struct netdev_feature_set name = { \
> .feature_bits = { features }, \
> .cnt = sizeof((u16 []){ features }) / sizeof(u16), \
> }
>
> because ARRAY_SIZE() can be taken only from a variable, not from
> a compound literal.
> But this one is actually OK. We don't need ARRAY_SIZE() in here
> since we define an unnamed array of an explicit type that we know
> for sure inline. So there's no chance to do it wrong as long as
> the @features argument is correct.
>
> The ability to make it static is important. For example, when I
> marked them both static, I got
>
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Function old new delta
> Total: Before=76, After=76, chg +0.00%
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Data old new delta
> Total: Before=1, After=1, chg +0.00%
> add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-14 (-14)
> RO Data old new delta
> arr1 6 - -6
> arr2 8 - -8
> Total: Before=50, After=36, chg -28.00%
>
> i.e. both of the sets were removed, because my main() was:
>
> printf("cnt1: %u, cnt2: %u\n", arr1.cnt, arr2.cnt);
>
> The compiler saw that I don't use them, except for printing values
> which are actually compile-time constants, and wiped them.
> Previously, they were global so it didn't have a clue if they're
> used anywhere else.
> This was a simple stupid example, but it will bring a lot more value
> in real use cases. So please consider my variant :D
Make sense. I will fix it.
Thanks a lot!
>> +
>> enum {
>> NETIF_F_SG_BIT, /* Scatter/gather IO. */
>> NETIF_F_IP_CSUM_BIT, /* Can checksum TCP/UDP over IPv4. */
> --- 8< ---
>
>> --
>> 2.33.0
> Thanks,
> Al
> .
>
^ permalink raw reply
* [PATCH] wl12xx: scan: using pm_runtime_resume_and_get instead of pm_runtime_get_sync
From: cgel.zte @ 2022-04-20 9:02 UTC (permalink / raw)
To: kvalo
Cc: davem, kuba, linux-wireless, netdev, linux-kernel, Minghao Chi,
Zeal Robot
From: Minghao Chi <chi.minghao@zte.com.cn>
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
pm_runtime_put_noidle. This change is just to simplify the code, no
actual functional changes.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
---
drivers/net/wireless/ti/wlcore/scan.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/scan.c b/drivers/net/wireless/ti/wlcore/scan.c
index 29fa51c37e88..b414305acc32 100644
--- a/drivers/net/wireless/ti/wlcore/scan.c
+++ b/drivers/net/wireless/ti/wlcore/scan.c
@@ -53,11 +53,9 @@ void wl1271_scan_complete_work(struct work_struct *work)
wl->scan.req = NULL;
wl->scan_wlvif = NULL;
- ret = pm_runtime_get_sync(wl->dev);
- if (ret < 0) {
- pm_runtime_put_noidle(wl->dev);
+ ret = pm_runtime_resume_and_get(wl->dev);
+ if (ret < 0)
goto out;
- }
if (test_bit(WLVIF_FLAG_STA_ASSOCIATED, &wlvif->flags)) {
/* restore hardware connection monitoring template */
--
2.25.1
^ permalink raw reply related
* [PATCH] wl12xx: using pm_runtime_resume_and_get instead of pm_runtime_get_sync
From: cgel.zte @ 2022-04-20 9:02 UTC (permalink / raw)
To: kvalo
Cc: davem, kuba, linux-wireless, netdev, linux-kernel, Minghao Chi,
Zeal Robot
From: Minghao Chi <chi.minghao@zte.com.cn>
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
pm_runtime_put_noidle. This change is just to simplify the code, no
actual functional changes.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
---
drivers/net/wireless/ti/wlcore/tx.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/tx.c b/drivers/net/wireless/ti/wlcore/tx.c
index e20e18cd04ae..7bd3ce2f0804 100644
--- a/drivers/net/wireless/ti/wlcore/tx.c
+++ b/drivers/net/wireless/ti/wlcore/tx.c
@@ -855,11 +855,9 @@ void wl1271_tx_work(struct work_struct *work)
int ret;
mutex_lock(&wl->mutex);
- ret = pm_runtime_get_sync(wl->dev);
- if (ret < 0) {
- pm_runtime_put_noidle(wl->dev);
+ ret = pm_runtime_resume_and_get(wl->dev);
+ if (ret < 0)
goto out;
- }
ret = wlcore_tx_work_locked(wl);
if (ret < 0) {
--
2.25.1
^ permalink raw reply related
* [PATCH] wlcore: cmd: using pm_runtime_resume_and_get instead of pm_runtime_get_sync
From: cgel.zte @ 2022-04-20 9:01 UTC (permalink / raw)
To: kvalo
Cc: davem, kuba, linux-wireless, netdev, linux-kernel, Minghao Chi,
Zeal Robot
From: Minghao Chi <chi.minghao@zte.com.cn>
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
pm_runtime_put_noidle. This change is just to simplify the code, no
actual functional changes.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
---
drivers/net/wireless/ti/wlcore/cmd.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c
index 8b798b5fcaf5..62388ee8febc 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -178,11 +178,9 @@ int wlcore_cmd_wait_for_event_or_timeout(struct wl1271 *wl,
timeout_time = jiffies + msecs_to_jiffies(WL1271_EVENT_TIMEOUT);
- ret = pm_runtime_get_sync(wl->dev);
- if (ret < 0) {
- pm_runtime_put_noidle(wl->dev);
+ ret = pm_runtime_resume_and_get(wl->dev);
+ if (ret < 0)
goto free_vector;
- }
do {
if (time_after(jiffies, timeout_time)) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: mailbox: qcom-ipcc: simplify the example
From: Krzysztof Kozlowski @ 2022-04-20 8:42 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bjorn Andersson, Jassi Brar,
Krzysztof Kozlowski, Paolo Abeni, linux-arm-msm, linux-kernel,
devicetree, Andy Gross, netdev
Cc: Rob Herring, Alex Elder, Jakub Kicinski, David S. Miller,
Rob Herring
In-Reply-To: <20220402155551.16509-1-krzysztof.kozlowski@linaro.org>
On 02/04/2022 17:55, Krzysztof Kozlowski wrote:
> Consumer examples in the bindings of resource providers are trivial,
> useless and duplicating code. Additionally the incomplete qcom,smp2p
> example triggers DT schema warnings.
>
> Cleanup the example by removing the consumer part and fixing the
> indentation to DT schema convention.
>
> Reported-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Jassi,
Do you plan to pick this mailbox patch?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net-next] net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO
From: Hangbin Liu @ 2022-04-20 8:27 UTC (permalink / raw)
To: netdev
Cc: Michael S . Tsirkin, Jason Wang, David S . Miller, Jakub Kicinski,
Paolo Abeni, Maxim Mikityanskiy, Willem de Bruijn, virtualization,
Balazs Nemeth, Mike Pattrick, Eric Dumazet, Hangbin Liu
Currently, the kernel drops GSO VLAN tagged packet if it's created with
socket(AF_PACKET, SOCK_RAW, 0) plus virtio_net_hdr.
The reason is AF_PACKET doesn't adjust the skb network header if there is
a VLAN tag. Then after virtio_net_hdr_set_proto() called, the skb->protocol
will be set to ETH_P_IP/IPv6. And in later inet/ipv6_gso_segment() the skb
is dropped as network header position is invalid.
Let's handle VLAN packets by adjusting network header position in
packet_parse_headers(), and move the function in packet_snd() before
calling virtio_net_hdr_set_proto().
No need to update tpacket_snd() as it calls packet_parse_headers() in
tpacket_fill_skb(), which is already before calling virtio_net_hdr_*
functions.
skb->no_fcs setting is also moved upper to make all skb settings together
and keep consistence with function packet_sendmsg_spkt().
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/packet/af_packet.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 002d2b9c69dd..cfdbda28ef82 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1924,12 +1924,20 @@ static int packet_rcv_spkt(struct sk_buff *skb, struct net_device *dev,
static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)
{
+ int depth;
+
if ((!skb->protocol || skb->protocol == htons(ETH_P_ALL)) &&
sock->type == SOCK_RAW) {
skb_reset_mac_header(skb);
skb->protocol = dev_parse_header_protocol(skb);
}
+ /* Move network header to the right position for VLAN tagged packets */
+ if (likely(skb->dev->type == ARPHRD_ETHER) &&
+ eth_type_vlan(skb->protocol) &&
+ __vlan_get_protocol(skb, skb->protocol, &depth) != 0)
+ skb_set_network_header(skb, depth);
+
skb_probe_transport_header(skb);
}
@@ -3047,6 +3055,11 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
skb->mark = sockc.mark;
skb->tstamp = sockc.transmit_time;
+ if (unlikely(extra_len == 4))
+ skb->no_fcs = 1;
+
+ packet_parse_headers(skb, sock);
+
if (has_vnet_hdr) {
err = virtio_net_hdr_to_skb(skb, &vnet_hdr, vio_le());
if (err)
@@ -3055,11 +3068,6 @@ static int packet_snd(struct socket *sock, struct msghdr *msg, size_t len)
virtio_net_hdr_set_proto(skb, &vnet_hdr);
}
- packet_parse_headers(skb, sock);
-
- if (unlikely(extra_len == 4))
- skb->no_fcs = 1;
-
err = po->xmit(skb);
if (unlikely(err != 0)) {
if (err > 0)
--
2.35.1
^ permalink raw reply related
* Re: [PATCH net-next 08/12] net: dsa: rzn1-a5psw: add FDB support
From: Clément Léger @ 2022-04-20 8:16 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S . Miller,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Geert Uytterhoeven, Magnus Damm, Heiner Kallweit, Russell King,
Thomas Petazzoni, Herve Codina, Miquèl Raynal,
Milan Stevanovic, Jimmy Lalande, linux-kernel, devicetree,
linux-renesas-soc, netdev
In-Reply-To: <20220414175140.p2vyy7f7yk6vlomi@skbuf>
Le Thu, 14 Apr 2022 20:51:40 +0300,
Vladimir Oltean <olteanv@gmail.com> a écrit :
> > +
> > +static int a5psw_port_fdb_add(struct dsa_switch *ds, int port,
> > + const unsigned char *addr, u16 vid,
> > + struct dsa_db db)
>
> This isn't something that is documented because I haven't had time to
> update that, but new drivers should comply to the requirements for FDB
> isolation (not ignore the passed "db" here) and eventually set
> ds->fdb_isolation = true. Doing so would allow your switch to behave
> correctly when
> - there is more than one bridge spanning its ports,
> - some ports are standalone and some ports are bridged
> - standalone ports are looped back via an external cable with bridged
> ports
> - unrecognized upper interfaces (bond, team) are used, and those are
> bridged directly with some other switch ports
>
> The most basic thing you need to do to satisfy the requirements is to
> figure out what mechanism for FDB partitioning does your hardware have.
> If the answer is "none", then we'll have to use VLANs for that: all
> standalone ports to share a VLAN, each VLAN-unaware bridge to share a
> VLAN across all member ports, each VLAN of a VLAN-aware bridge to
> reserve its own VLAN. Up to a total of 32 VLANs, since I notice that's
> what the limit for your hardware is.
Ok, I see the idea. In the mean time, could we make a first step with a
single bridge and without VLAN support ? This is expected to come later
anyway.
>
> But I see this patch set doesn't include VLAN functionality (and also
> ignores the "vid" from FDB entries), so I can't really say more right now.
> But if you could provide more information about the hardware
> capabilities we can discuss implementation options.
That's indeed the problem. The FDB table does not seems to have
partitionning at all (except for ports) and entries (such as seen below)
do not contain any VLAN information.
> > diff --git a/drivers/net/dsa/rzn1_a5psw.h b/drivers/net/dsa/rzn1_a5psw.h
> > index b34ea549e936..37aa89383e70 100644
> > --- a/drivers/net/dsa/rzn1_a5psw.h
> > +++ b/drivers/net/dsa/rzn1_a5psw.h
> > @@ -167,6 +167,22 @@
> > #define A5PSW_CTRL_TIMEOUT 1000
> > #define A5PSW_TABLE_ENTRIES 8192
> >
> > +struct fdb_entry {
>
> Shouldn't this contain something along the lines of a VID, FID, something?
This is extracted directly from the datasheet [1]. The switch FDB table
does not seems to store the VID with the entries (See page 300).
[1]
https://www.renesas.com/us/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-r-engine-and-ethernet-peripherals
>
> > + u8 mac[ETH_ALEN];
> > + u8 valid:1;
> > + u8 is_static:1;
> > + u8 prio:3;
> > + u8 port_mask:5;
> > +} __packed;
> > +
> > +union lk_data {
> > + struct {
> > + u32 lo;
> > + u32 hi;
> > + };
> > + struct fdb_entry entry;
> > +};
> > +
> > /**
> > * struct a5psw - switch struct
> > * @base: Base address of the switch
> > --
> > 2.34.1
> >
>
--
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH net-next 0/2] net: phy: Extend sysfs to adjust PHY latency.
From: Horatiu Vultur @ 2022-04-20 7:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, hkallweit1, linux, davem, kuba, pabeni,
UNGLinuxDriver, richardcochran
In-Reply-To: <Yl6oZLIaBnPVkeqN@lunn.ch>
The 04/19/2022 14:17, Andrew Lunn wrote:
Hi Andrew,
>
> On Tue, Apr 19, 2022 at 10:37:02AM +0200, Horatiu Vultur wrote:
> > The previous try of setting the PHY latency was here[1]. But this approach
> > could not work for multiple reasons:
> > - the interface was not generic enough so it would be hard to be extended
> > in the future
> > - if there were multiple time stamper in the system then it was not clear
> > to which one should adjust these values.
> >
> > So the next try is to extend sysfs and configure exactly the desired PHY.
>
> What about timestampers which are not PHYs? Ideally you want one
> interface which will work for any sort of stamper, be it MAC, PHY, or
> a bump in the wire between the MAC and the PHY.
My initial idea was that each of the timestampers will need to extend
the sysfs to add this file or multiple files. But from what I can see
this approach will not fly.
If we want an interface to be used by any sort of stamper, we could
create a new generic class (eth_tunable/eth_obj). Then each driver will
register a device that will use this generic class.
We will continue to use sysfs to expose all the modes supported by the
driver. But this time create a file for each mode.
The entire approach should be something similar with the ptp clocks.
What do you think, is this the right approach?
>
> Andrew
--
/Horatiu
^ permalink raw reply
* Re: [PATCH bpf-next v2 5/6] bpf, arm64: bpf trampoline for arm64
From: Xu Kuohai @ 2022-04-20 7:43 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, linux-arm-kernel, open list, Networking,
open list:KERNEL SELFTEST FRAMEWORK, Catalin Marinas, Will Deacon,
Steven Rostedt, Ingo Molnar, Daniel Borkmann, Alexei Starovoitov,
Zi Shen Lim, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, David S . Miller,
Hideaki YOSHIFUJI, David Ahern, Thomas Gleixner, Borislav Petkov,
Dave Hansen, X86 ML, hpa, Shuah Khan, Mark Rutland,
Ard Biesheuvel, Pasha Tatashin, Peter Collingbourne, Daniel Kiss,
Sudeep Holla, Steven Price, Marc Zyngier, Mark Brown,
Kumar Kartikeya Dwivedi, Delyan Kratunov
In-Reply-To: <6c18a27f-c983-58f3-1dc0-5192f7df232a@huawei.com>
On 4/16/2022 9:57 AM, Xu Kuohai wrote:
> On 4/16/2022 1:12 AM, Andrii Nakryiko wrote:
>> On Thu, Apr 14, 2022 at 9:10 AM Xu Kuohai <xukuohai@huawei.com> wrote:
>>>
>>> Add bpf trampoline support for arm64. Most of the logic is the same as
>>> x86.
>>>
>>> fentry before bpf trampoline hooked:
>>> mov x9, x30
>>> nop
>>>
>>> fentry after bpf trampoline hooked:
>>> mov x9, x30
>>> bl <bpf_trampoline>
>>>
>>> Tested on qemu, result:
>>> #55 fentry_fexit:OK
>>> #56 fentry_test:OK
>>> #58 fexit_sleep:OK
>>> #59 fexit_stress:OK
>>> #60 fexit_test:OK
>>> #67 get_func_args_test:OK
>>> #68 get_func_ip_test:OK
>>> #101 modify_return:OK
>>>
>>> Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
>>> Acked-by: Song Liu <songliubraving@fb.com>
>>> ---
>>
>> Can you please also take a look at [0], which is an ongoing work to
>> add support for BPF cookie to BPF trampoline-based BPF programs. It's
>> very close to being done, so it would be good if you can implement
>> that at the same time.
>
> OK, I'll take a look and try to implemnt it.
already implemented, but there are some conflicts between these two
series, will send v3 after trampoline cookie are merged.
^ permalink raw reply
* Re: [PATCH net-next] PCI: add Corigine vendor ID into pci_ids.h
From: Yinjun Zhang @ 2022-04-20 7:42 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Andrew Lunn, davem, kuba, netdev, Bjorn Helgaas, linux-pci,
Simon Horman
In-Reply-To: <Yl+kUqyMUTIadDMz@unreal>
On Wed, Apr 20, 2022 at 09:12:34AM +0300, Leon Romanovsky wrote:
> On Wed, Apr 20, 2022 at 09:59:52AM +0800, Yinjun Zhang wrote:
> > On Wed, Apr 20, 2022 at 12:00:05AM +0200, Andrew Lunn wrote:
> > > On Tue, Apr 19, 2022 at 06:02:48PM +0800, Yinjun Zhang wrote:
> > > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > > Cc: linux-pci@vger.kernel.org
> > > > Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
> > > > Signed-off-by: Simon Horman <simon.horman@corigine.com>
> > > > ---
> > > > include/linux/pci_ids.h | 2 ++
> > >
> > > The very top of this file says:
> > >
> > > * Do not add new entries to this file unless the definitions
> > > * are shared between multiple drivers.
> > >
> > > Please add to the commit messages the two or more drivers which share
> > > this definition.
> >
> > It will be used by ethernet and infiniband driver as we can see now,
> > I'll update the commit message if you think it's a good practice.
>
> Are you going to submit completely separated infiniband driver that has
> PCI logic in drivers/infiniband without connection todrivers/net/ethernet ...?
>
> If yes, it is very uncommon in infiniband world.
No, we'll follow the convention, the connection with driver/net/ethernet
is necessary. We've discussed internally that direct ref to VID/DID is not
a good way.
I'll move the VID macro into driver header files for now.
Also thanks for pointing this out, Andrew.
Cc: Bjorn Helgaas
>
> I would like to see this PCI patch submitted when it is actually used.
>
> Thanks
>
> >
> > >
> > > Thanks
> > >
> > > Andrew
^ permalink raw reply
* [RFC Patch net-next] net: dsa: ksz: added the generic port_stp_state_set function
From: Arun Ramadoss @ 2022-04-20 7:26 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Paolo Abeni, Jakub Kicinski, David S. Miller, Vladimir Oltean,
Florian Fainelli, Vivien Didelot, Andrew Lunn, UNGLinuxDriver,
Woojung Huh
The ksz8795 and ksz9477 uses the same algorithm for the
port_stp_state_set function except the register address is different. So
moved the algorithm to the ksz_common.c and used the dev_ops for
register read and write. This function can also used for the lan937x
part. Hence making it generic for all the parts.
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
---
drivers/net/dsa/microchip/ksz8795.c | 37 ++++---------------------
drivers/net/dsa/microchip/ksz8795_reg.h | 3 --
drivers/net/dsa/microchip/ksz9477.c | 36 ++++--------------------
drivers/net/dsa/microchip/ksz9477_reg.h | 4 ---
drivers/net/dsa/microchip/ksz_common.c | 37 +++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz_common.h | 8 ++++++
6 files changed, 55 insertions(+), 70 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz8795.c b/drivers/net/dsa/microchip/ksz8795.c
index b2752978cb09..0873b668913d 100644
--- a/drivers/net/dsa/microchip/ksz8795.c
+++ b/drivers/net/dsa/microchip/ksz8795.c
@@ -1025,42 +1025,14 @@ static void ksz8_cfg_port_member(struct ksz_device *dev, int port, u8 member)
ksz_pwrite8(dev, port, P_MIRROR_CTRL, data);
}
-static void ksz8_port_stp_state_set(struct dsa_switch *ds, int port, u8 state)
+static void ksz8_cfg_stp_state(struct ksz_device *dev, int port, u8 val)
{
- struct ksz_device *dev = ds->priv;
- struct ksz_port *p;
u8 data;
ksz_pread8(dev, port, P_STP_CTRL, &data);
data &= ~(PORT_TX_ENABLE | PORT_RX_ENABLE | PORT_LEARN_DISABLE);
-
- switch (state) {
- case BR_STATE_DISABLED:
- data |= PORT_LEARN_DISABLE;
- break;
- case BR_STATE_LISTENING:
- data |= (PORT_RX_ENABLE | PORT_LEARN_DISABLE);
- break;
- case BR_STATE_LEARNING:
- data |= PORT_RX_ENABLE;
- break;
- case BR_STATE_FORWARDING:
- data |= (PORT_TX_ENABLE | PORT_RX_ENABLE);
- break;
- case BR_STATE_BLOCKING:
- data |= PORT_LEARN_DISABLE;
- break;
- default:
- dev_err(ds->dev, "invalid STP state: %d\n", state);
- return;
- }
-
+ data |= val;
ksz_pwrite8(dev, port, P_STP_CTRL, data);
-
- p = &dev->ports[port];
- p->stp_state = state;
-
- ksz_update_port_member(dev, port);
}
static void ksz8_flush_dyn_mac_table(struct ksz_device *dev, int port)
@@ -1385,7 +1357,7 @@ static void ksz8_config_cpu_port(struct dsa_switch *ds)
for (i = 0; i < dev->phy_port_cnt; i++) {
p = &dev->ports[i];
- ksz8_port_stp_state_set(ds, i, BR_STATE_DISABLED);
+ ksz_port_stp_state_set(ds, i, BR_STATE_DISABLED);
/* Last port may be disabled. */
if (i == dev->phy_port_cnt)
@@ -1542,7 +1514,7 @@ static const struct dsa_switch_ops ksz8_switch_ops = {
.get_sset_count = ksz_sset_count,
.port_bridge_join = ksz_port_bridge_join,
.port_bridge_leave = ksz_port_bridge_leave,
- .port_stp_state_set = ksz8_port_stp_state_set,
+ .port_stp_state_set = ksz_port_stp_state_set,
.port_fast_age = ksz_port_fast_age,
.port_vlan_filtering = ksz8_port_vlan_filtering,
.port_vlan_add = ksz8_port_vlan_add,
@@ -1761,6 +1733,7 @@ static const struct ksz_dev_ops ksz8_dev_ops = {
.cfg_port_member = ksz8_cfg_port_member,
.flush_dyn_mac_table = ksz8_flush_dyn_mac_table,
.port_setup = ksz8_port_setup,
+ .cfg_stp_state = ksz8_cfg_stp_state,
.r_phy = ksz8_r_phy,
.w_phy = ksz8_w_phy,
.r_dyn_mac_table = ksz8_r_dyn_mac_table,
diff --git a/drivers/net/dsa/microchip/ksz8795_reg.h b/drivers/net/dsa/microchip/ksz8795_reg.h
index d74defcd86b4..4109433b6b6c 100644
--- a/drivers/net/dsa/microchip/ksz8795_reg.h
+++ b/drivers/net/dsa/microchip/ksz8795_reg.h
@@ -160,9 +160,6 @@
#define PORT_DISCARD_NON_VID BIT(5)
#define PORT_FORCE_FLOW_CTRL BIT(4)
#define PORT_BACK_PRESSURE BIT(3)
-#define PORT_TX_ENABLE BIT(2)
-#define PORT_RX_ENABLE BIT(1)
-#define PORT_LEARN_DISABLE BIT(0)
#define REG_PORT_1_CTRL_3 0x13
#define REG_PORT_2_CTRL_3 0x23
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 8222c8a6c5ec..96248de95749 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -514,41 +514,14 @@ static void ksz9477_cfg_port_member(struct ksz_device *dev, int port,
ksz_pwrite32(dev, port, REG_PORT_VLAN_MEMBERSHIP__4, member);
}
-static void ksz9477_port_stp_state_set(struct dsa_switch *ds, int port,
- u8 state)
+static void ksz9477_cfg_stp_state(struct ksz_device *dev, int port, u8 val)
{
- struct ksz_device *dev = ds->priv;
- struct ksz_port *p = &dev->ports[port];
u8 data;
ksz_pread8(dev, port, P_STP_CTRL, &data);
data &= ~(PORT_TX_ENABLE | PORT_RX_ENABLE | PORT_LEARN_DISABLE);
-
- switch (state) {
- case BR_STATE_DISABLED:
- data |= PORT_LEARN_DISABLE;
- break;
- case BR_STATE_LISTENING:
- data |= (PORT_RX_ENABLE | PORT_LEARN_DISABLE);
- break;
- case BR_STATE_LEARNING:
- data |= PORT_RX_ENABLE;
- break;
- case BR_STATE_FORWARDING:
- data |= (PORT_TX_ENABLE | PORT_RX_ENABLE);
- break;
- case BR_STATE_BLOCKING:
- data |= PORT_LEARN_DISABLE;
- break;
- default:
- dev_err(ds->dev, "invalid STP state: %d\n", state);
- return;
- }
-
+ data |= val;
ksz_pwrite8(dev, port, P_STP_CTRL, data);
- p->stp_state = state;
-
- ksz_update_port_member(dev, port);
}
static void ksz9477_flush_dyn_mac_table(struct ksz_device *dev, int port)
@@ -1404,7 +1377,7 @@ static void ksz9477_config_cpu_port(struct dsa_switch *ds)
continue;
p = &dev->ports[i];
- ksz9477_port_stp_state_set(ds, i, BR_STATE_DISABLED);
+ ksz_port_stp_state_set(ds, i, BR_STATE_DISABLED);
p->on = 1;
if (i < dev->phy_port_cnt)
p->phy = 1;
@@ -1481,7 +1454,7 @@ static const struct dsa_switch_ops ksz9477_switch_ops = {
.get_sset_count = ksz_sset_count,
.port_bridge_join = ksz_port_bridge_join,
.port_bridge_leave = ksz_port_bridge_leave,
- .port_stp_state_set = ksz9477_port_stp_state_set,
+ .port_stp_state_set = ksz_port_stp_state_set,
.port_fast_age = ksz_port_fast_age,
.port_vlan_filtering = ksz9477_port_vlan_filtering,
.port_vlan_add = ksz9477_port_vlan_add,
@@ -1682,6 +1655,7 @@ static const struct ksz_dev_ops ksz9477_dev_ops = {
.cfg_port_member = ksz9477_cfg_port_member,
.flush_dyn_mac_table = ksz9477_flush_dyn_mac_table,
.port_setup = ksz9477_port_setup,
+ .cfg_stp_state = ksz9477_cfg_stp_state,
.r_mib_cnt = ksz9477_r_mib_cnt,
.r_mib_pkt = ksz9477_r_mib_pkt,
.r_mib_stat64 = ksz9477_r_mib_stats64,
diff --git a/drivers/net/dsa/microchip/ksz9477_reg.h b/drivers/net/dsa/microchip/ksz9477_reg.h
index 0bd58467181f..7a2c8d4767af 100644
--- a/drivers/net/dsa/microchip/ksz9477_reg.h
+++ b/drivers/net/dsa/microchip/ksz9477_reg.h
@@ -1586,10 +1586,6 @@
#define REG_PORT_LUE_MSTP_STATE 0x0B04
-#define PORT_TX_ENABLE BIT(2)
-#define PORT_RX_ENABLE BIT(1)
-#define PORT_LEARN_DISABLE BIT(0)
-
/* C - PTP */
#define REG_PTP_PORT_RX_DELAY__2 0x0C00
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 8014b18d9391..08e8f09b6bc0 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -372,6 +372,43 @@ int ksz_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
}
EXPORT_SYMBOL_GPL(ksz_enable_port);
+void ksz_port_stp_state_set(struct dsa_switch *ds, int port,
+ u8 state)
+{
+ struct ksz_device *dev = ds->priv;
+ struct ksz_port *p;
+ u8 data;
+
+ switch (state) {
+ case BR_STATE_DISABLED:
+ data = PORT_LEARN_DISABLE;
+ break;
+ case BR_STATE_LISTENING:
+ data = (PORT_RX_ENABLE | PORT_LEARN_DISABLE);
+ break;
+ case BR_STATE_LEARNING:
+ data = PORT_RX_ENABLE;
+ break;
+ case BR_STATE_FORWARDING:
+ data = (PORT_TX_ENABLE | PORT_RX_ENABLE);
+ break;
+ case BR_STATE_BLOCKING:
+ data = PORT_LEARN_DISABLE;
+ break;
+ default:
+ dev_err(ds->dev, "invalid STP state: %d\n", state);
+ return;
+ }
+
+ dev->dev_ops->cfg_stp_state(dev, port, data);
+
+ p = &dev->ports[port];
+ p->stp_state = state;
+
+ ksz_update_port_member(dev, port);
+}
+EXPORT_SYMBOL_GPL(ksz_port_stp_state_set);
+
struct ksz_device *ksz_switch_alloc(struct device *base, void *priv)
{
struct dsa_switch *ds;
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 485d4a948c38..360b98c7b0d2 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -119,6 +119,7 @@ struct ksz_dev_ops {
void (*flush_dyn_mac_table)(struct ksz_device *dev, int port);
void (*port_cleanup)(struct ksz_device *dev, int port);
void (*port_setup)(struct ksz_device *dev, int port, bool cpu_port);
+ void (*cfg_stp_state)(struct ksz_device *dev, int port, u8 state);
void (*r_phy)(struct ksz_device *dev, u16 phy, u16 reg, u16 *val);
void (*w_phy)(struct ksz_device *dev, u16 phy, u16 reg, u16 val);
int (*r_dyn_mac_table)(struct ksz_device *dev, u16 addr, u8 *mac_addr,
@@ -165,6 +166,8 @@ int ksz_port_bridge_join(struct dsa_switch *ds, int port,
struct netlink_ext_ack *extack);
void ksz_port_bridge_leave(struct dsa_switch *ds, int port,
struct dsa_bridge bridge);
+void ksz_port_stp_state_set(struct dsa_switch *ds, int port,
+ u8 state);
void ksz_port_fast_age(struct dsa_switch *ds, int port);
int ksz_port_fdb_dump(struct dsa_switch *ds, int port, dsa_fdb_dump_cb_t *cb,
void *data);
@@ -292,6 +295,11 @@ static inline void ksz_regmap_unlock(void *__mtx)
mutex_unlock(mtx);
}
+/* STP State Defines */
+#define PORT_TX_ENABLE BIT(2)
+#define PORT_RX_ENABLE BIT(1)
+#define PORT_LEARN_DISABLE BIT(0)
+
/* Regmap tables generation */
#define KSZ_SPI_OP_RD 3
#define KSZ_SPI_OP_WR 2
base-commit: cc4bdef26ecd56de16a04bc6d99aa10ff9076498
--
2.33.0
^ permalink raw reply related
* Re: [PATCH] driver: usb: nullify dangling pointer in cdc_ncm_free
From: Johan Hovold @ 2022-04-20 6:56 UTC (permalink / raw)
To: Oliver Neukum
Cc: Andy Shevchenko, Oleksij Rempel, Dongliang Mu, Oliver Neukum,
David S. Miller, Jakub Kicinski, Paolo Abeni, Dongliang Mu,
syzbot+eabbf2aaa999cc507108, USB, netdev,
Linux Kernel Mailing List
In-Reply-To: <d851497f-7960-b606-2f87-eb9bff89c8ac@suse.com>
On Tue, Apr 19, 2022 at 01:47:40PM +0200, Oliver Neukum wrote:
> On 14.04.22 17:01, Andy Shevchenko wrote:
> >
> > Good question. Isn't it the commit 2c9d6c2b871d ("usbnet: run unbind()
> > before unregister_netdev()") which changed the ordering of the
> > interface shutdown and basically makes this race happen? I don't see
> > how we can guarantee that IOCTL won't be called until we quiescence
> > the network device — my understanding that on device surprise removal
> True. The best we could do is introduce a mutex for ioctl() and
> disconnect(). That seems the least preferable solution to me.
> > we have to first shutdown what it created and then unbind the device.
Yes, indeed, commit 2c9d6c2b871d ("usbnet: run unbind() before
unregister_netdev()") is fundamentally broken. You can't just start
freeing driver private data before deregistering the device.
> > If I understand the original issue correctly then the problem is in
> > usbnet->unbind and it should actually be split to two hooks, otherwise
> > it seems every possible IOCTL callback must have some kind of
> > reference counting and keep an eye on the surprise removal.
> >
> > Johan, can you correct me if my understanding is wrong?
That sounds correct. I only noticed that the proposed patch looked
insufficient at best and didn't really look into the backstory until
just now.
> It seems to me that fundamentally the order of actions to handle
> a hotunplug must mirror the order in a hotplug. We can add more hooks
> if that turns out to be necessary for some drivers, but the basic
> reverse mirrored order must be supported and I very much favor
> restoring it as default.
I agree, we need to strive to maintain symmetry. Anything else is likely
broken and at least makes things harder to reason about and maintenance
a pain.
> So I am afraid I have to ask again, whether anybody sees a fundamental
> issue with the attached patch, as opposed to it not being an elegant
> solution?
> It looks to me that we are in a fundamental disagreement on the correct
> order in this question and there is no productive way forward other than
> offering both ways.
>
> Regards
> Oliver
> From 2e07ccbd1769889963d129ec474909bdcaa4c64a Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oneukum@suse.com>
> Date: Thu, 10 Mar 2022 13:18:38 +0100
> Subject: [PATCH] usbnet: split unbind callback
>
> Some devices need to be informed of a disconnect before
> the generic layer is informed, others need their notification
> later to avoid race conditions. Hence we provide two callbacks.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
> drivers/net/usb/asix_devices.c | 8 ++++----
> drivers/net/usb/smsc95xx.c | 4 ++--
> drivers/net/usb/usbnet.c | 7 +++++--
> include/linux/usb/usbnet.h | 3 +++
> 4 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
> index 6ea44e53713a..e6cfa9a39a87 100644
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -808,7 +808,7 @@ static int ax88772_stop(struct usbnet *dev)
> return 0;
> }
>
> -static void ax88772_unbind(struct usbnet *dev, struct usb_interface *intf)
> +static void ax88772_disable(struct usbnet *dev, struct usb_interface *intf)
> {
> struct asix_common_private *priv = dev->driver_priv;
>
> @@ -1214,7 +1214,7 @@ static const struct driver_info hawking_uf200_info = {
> static const struct driver_info ax88772_info = {
> .description = "ASIX AX88772 USB 2.0 Ethernet",
> .bind = ax88772_bind,
> - .unbind = ax88772_unbind,
> + .unbind = ax88772_disable,
These should all be
.disable = ...
but you probably need to split the callback and keep unbind as well for
the actual clean up (freeing resources etc).
> .status = asix_status,
> .reset = ax88772_reset,
> .stop = ax88772_stop,
> @@ -1226,7 +1226,7 @@ static const struct driver_info ax88772_info = {
> static const struct driver_info ax88772b_info = {
> .description = "ASIX AX88772B USB 2.0 Ethernet",
> .bind = ax88772_bind,
> - .unbind = ax88772_unbind,
> + .unbind = ax88772_disable,
> .status = asix_status,
> .reset = ax88772_reset,
> .stop = ax88772_stop,
> @@ -1262,7 +1262,7 @@ static const struct driver_info ax88178_info = {
> static const struct driver_info hg20f9_info = {
> .description = "HG20F9 USB 2.0 Ethernet",
> .bind = ax88772_bind,
> - .unbind = ax88772_unbind,
> + .unbind = ax88772_disable,
> .status = asix_status,
> .reset = ax88772_reset,
> .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_LINK_INTR |
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 5567220e9d16..62db57021f5f 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -1211,7 +1211,7 @@ static int smsc95xx_bind(struct usbnet *dev, struct usb_interface *intf)
> return ret;
> }
>
> -static void smsc95xx_unbind(struct usbnet *dev, struct usb_interface *intf)
> +static void smsc95xx_disable(struct usbnet *dev, struct usb_interface *intf)
> {
> struct smsc95xx_priv *pdata = dev->driver_priv;
>
> @@ -1985,7 +1985,7 @@ static int smsc95xx_manage_power(struct usbnet *dev, int on)
> static const struct driver_info smsc95xx_info = {
> .description = "smsc95xx USB 2.0 Ethernet",
> .bind = smsc95xx_bind,
> - .unbind = smsc95xx_unbind,
> + .unbind = smsc95xx_disable,
> .link_reset = smsc95xx_link_reset,
> .reset = smsc95xx_reset,
> .check_connect = smsc95xx_start_phy,
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index b1f93810a6f3..5249a7d7efa5 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -1641,8 +1641,8 @@ void usbnet_disconnect (struct usb_interface *intf)
> xdev->bus->bus_name, xdev->devpath,
> dev->driver_info->description);
>
> - if (dev->driver_info->unbind)
> - dev->driver_info->unbind(dev, intf);
> + if (dev->driver_info->disable)
> + dev->driver_info->disable(dev, intf);
>
> net = dev->net;
> unregister_netdev (net);
> @@ -1651,6 +1651,9 @@ void usbnet_disconnect (struct usb_interface *intf)
>
> usb_scuttle_anchored_urbs(&dev->deferred);
>
> + if (dev->driver_info->unbind)
> + dev->driver_info->unbind (dev, intf);
> +
> usb_kill_urb(dev->interrupt);
Don't you need to quiesce all I/O, including stopping the interrupt URB,
before unbind?
> usb_free_urb(dev->interrupt);
> kfree(dev->padding_pkt);
> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> index 8336e86ce606..4d2407f1ae93 100644
> --- a/include/linux/usb/usbnet.h
> +++ b/include/linux/usb/usbnet.h
> @@ -129,6 +129,9 @@ struct driver_info {
> /* cleanup device ... can sleep, but can't fail */
> void (*unbind)(struct usbnet *, struct usb_interface *);
>
> + /* disable device ... can sleep, but can't fail */
> + void (*disable)(struct usbnet *, struct usb_interface *);
> +
> /* reset device ... can sleep */
> int (*reset)(struct usbnet *);
Johan
^ permalink raw reply
* Re: [PATCH 0/1] add support for enum module parameters
From: Greg Kroah-Hartman @ 2022-04-20 6:38 UTC (permalink / raw)
To: Kalle Valo
Cc: Jani Nikula, linux-kernel, intel-gfx, dri-devel, Andrew Morton,
Lucas De Marchi, linux-wireless, netdev
In-Reply-To: <87sfq8qqus.fsf@tynnyri.adurom.net>
On Wed, Apr 20, 2022 at 08:13:47AM +0300, Kalle Valo wrote:
> + linux-wireless, netdev
>
> Jani Nikula <jani.nikula@intel.com> writes:
>
> > On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >>> Hey, I've sent this before, ages ago, but haven't really followed
> >>> through with it. I still think it would be useful for many scenarios
> >>> where a plain number is a clumsy interface for a module param.
> >>>
> >>> Thoughts?
> >>
> >> We should not be adding new module parameters anyway (they operate on
> >> code, not data/devices), so what would this be used for?
> >
> > I think it's just easier to use names than random values, and this also
> > gives you range check on the input.
> >
> > I also keep telling people not to add new module parameters, but it's
> > not like they're going away anytime soon.
> >
> > If there's a solution to being able to pass device specific debug
> > parameters at probe time, I'm all ears. At least i915 has a bunch of
> > things which can't really be changed after probe, when debugfs for the
> > device is around. Module parameters aren't ideal, but debugfs doesn't
> > work for this.
>
> Wireless drivers would also desperately need to pass device specific
> parameters at (or before) probe time. And not only debug parameters but
> also configuration parameters, for example firmware memory allocations
> schemes (optimise for features vs number of clients etc) and whatnot.
>
> Any ideas how to implement that? Is there any prior work for anything
> like this? This is pretty hard limiting usability of upstream wireless
> drivers and I really want to find a proper solution.
Again, configfs? That should be what that subsystem was designed for...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net] ice: Fix race during aux device (un)plugging
From: Leon Romanovsky @ 2022-04-20 6:36 UTC (permalink / raw)
To: Ivan Vecera
Cc: Michal Schmidt, netdev, Petr Oros, Jesse Brandeburg, Tony Nguyen,
David S. Miller, Jakub Kicinski, Paolo Abeni, Shiraz Saleem,
Dave Ertman, moderated list:INTEL ETHERNET DRIVERS, open list
In-Reply-To: <20220415174932.6c85d5ab@ceranb>
On Fri, Apr 15, 2022 at 05:49:32PM +0200, Ivan Vecera wrote:
> On Fri, 15 Apr 2022 13:12:03 +0200
> Michal Schmidt <mschmidt@redhat.com> wrote:
>
> > On Thu, Apr 14, 2022 at 6:39 PM Ivan Vecera <ivecera@redhat.com> wrote:
> >
> > > Function ice_plug_aux_dev() assigns pf->adev field too early prior
> > > aux device initialization and on other side ice_unplug_aux_dev()
> > > starts aux device deinit and at the end assigns NULL to pf->adev.
> > > This is wrong and can causes a crash when ice_send_event_to_aux()
> > > call occurs during these operations because that function depends
> > > on non-NULL value of pf->adev and does not assume that aux device
> > > is half-initialized or half-destroyed.
> > >
> > > Modify affected functions so pf->adev field is set after aux device
> > > init and prior aux device destroy.
> > >
> > [...]
> >
> > > @@ -320,12 +319,14 @@ int ice_plug_aux_dev(struct ice_pf *pf)
> > > */
> > > void ice_unplug_aux_dev(struct ice_pf *pf)
> > > {
> > > - if (!pf->adev)
> > > + struct auxiliary_device *adev = pf->adev;
> > > +
> > > + if (!adev)
> > > return;
> > >
> > > - auxiliary_device_delete(pf->adev);
> > > - auxiliary_device_uninit(pf->adev);
> > > pf->adev = NULL;
> > > + auxiliary_device_delete(adev);
> > > + auxiliary_device_uninit(adev);
> > > }
> > >
> >
> > Hi Ivan,
> > What prevents ice_unplug_aux_dev() from running immediately after
> > ice_send_event_to_aux() gets past its "if (!pf->adev)" test ?
> > Michal
>
> ice_send_event_to_aux() takes aux device lock. ice_unplug_aux_dev()
> calls auxiliary_device_delete() that calls device_del(). device_del()
> takes device_lock() prior kill_device(). So if ice_send_event_to_aux()
> is in progress then device_del() waits for its completion.
Not really, you nullify pf->adev without any lock protection and
ice_send_event_to_aux() will simply crash.
CPU#1 | CPU#2
| ice_send_event_to_aux
ice_unplug_aux_dev() | ...
... |
pf->adev = NULL; |
| device_lock(&pf->adev->dev); <--- crash here.
Thanks
>
> Thanks,
> Ivan
>
^ permalink raw reply
* Re: [PATCH net-next] PCI: add Corigine vendor ID into pci_ids.h
From: Leon Romanovsky @ 2022-04-20 6:12 UTC (permalink / raw)
To: Yinjun Zhang
Cc: Andrew Lunn, davem, kuba, netdev, Bjorn Helgaas, linux-pci,
Simon Horman
In-Reply-To: <20220420015952.GB4636@nj-rack01-04.nji.corigine.com>
On Wed, Apr 20, 2022 at 09:59:52AM +0800, Yinjun Zhang wrote:
> On Wed, Apr 20, 2022 at 12:00:05AM +0200, Andrew Lunn wrote:
> > On Tue, Apr 19, 2022 at 06:02:48PM +0800, Yinjun Zhang wrote:
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Cc: linux-pci@vger.kernel.org
> > > Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
> > > Signed-off-by: Simon Horman <simon.horman@corigine.com>
> > > ---
> > > include/linux/pci_ids.h | 2 ++
> >
> > The very top of this file says:
> >
> > * Do not add new entries to this file unless the definitions
> > * are shared between multiple drivers.
> >
> > Please add to the commit messages the two or more drivers which share
> > this definition.
>
> It will be used by ethernet and infiniband driver as we can see now,
> I'll update the commit message if you think it's a good practice.
Are you going to submit completely separated infiniband driver that has
PCI logic in drivers/infiniband without connection todrivers/net/ethernet ...?
If yes, it is very uncommon in infiniband world.
I would like to see this PCI patch submitted when it is actually used.
Thanks
>
> >
> > Thanks
> >
> > Andrew
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/2] Support riscv libbpf USDT arg parsing logic
From: patchwork-bot+netdevbpf @ 2022-04-20 5:50 UTC (permalink / raw)
To: Pu Lehui
Cc: bpf, linux-kernel, netdev, linux-riscv, andrii, ast, daniel,
kafai, songliubraving, yhs, john.fastabend, kpsingh,
paul.walmsley, palmer, aou
In-Reply-To: <20220419145238.482134-1-pulehui@huawei.com>
Hello:
This series was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <andrii@kernel.org>:
On Tue, 19 Apr 2022 22:52:36 +0800 you wrote:
> patch 1 fix a minor issue where usdt_cookie is cast to 32 bits.
> patch 2 add support riscv libbpf USDT argument parsing logic,
> both RV32 and RV64 tests have been passed as like follow:
>
> # ./test_progs -t usdt
> #169 usdt:OK
> Summary: 1/4 PASSED, 0 SKIPPED, 0 FAILED
>
> [...]
Here is the summary with links:
- [v2,bpf-next,1/2] libbpf: Fix usdt_cookie being cast to 32 bits
https://git.kernel.org/bpf/bpf-next/c/5af25a410acb
- [v2,bpf-next,2/2] libbpf: Support riscv USDT argument parsing logic
https://git.kernel.org/bpf/bpf-next/c/58ca8b0572cd
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf-next 01/11] bpf, perf: fix bpftool compilation with !CONFIG_PERF_EVENTS
From: Andrii Nakryiko @ 2022-04-20 5:30 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Alexander Lobakin, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
Björn Töpel, Magnus Karlsson, Jonathan Lemon,
Nathan Chancellor, Nick Desaulniers, Dmitrii Dolgov,
Quentin Monnet, Tiezhu Yang, Kumar Kartikeya Dwivedi, Chenbo Feng,
Willem de Bruijn, Daniel Wagner, Thomas Graf, Ong Boon Leong,
linux-perf-use., open list, Networking, bpf, llvm
In-Reply-To: <20220419090355.GP2731@worktop.programming.kicks-ass.net>
On Tue, Apr 19, 2022 at 2:04 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Apr 14, 2022 at 10:44:48PM +0000, Alexander Lobakin wrote:
> > When CONFIG_PERF_EVENTS is not set, struct perf_event remains empty.
> > However, the structure is being used by bpftool indirectly via BTF.
> > This leads to:
> >
> > skeleton/pid_iter.bpf.c:49:30: error: no member named 'bpf_cookie' in 'struct perf_event'
> > return BPF_CORE_READ(event, bpf_cookie);
> > ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
> >
> > ...
> >
> > skeleton/pid_iter.bpf.c:49:9: error: returning 'void' from a function with incompatible result type '__u64' (aka 'unsigned long long')
> > return BPF_CORE_READ(event, bpf_cookie);
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Tools and samples can't use any CONFIG_ definitions, so the fields
> > used there should always be present.
> > Move CONFIG_BPF_SYSCALL block out of the CONFIG_PERF_EVENTS block
> > to make it available unconditionally.
>
> Urgh, this is nasty.. did you verify nothing relies on that structure
> actually being empty?
>
> Also, why are we changing kernel headers to fix some daft userspace
> issue?
>
I agree, this is quite ugly. And I think it's not necessary at all.
BPF CO-RE, which bpftool relies on here, allows to have bpftool's own
minimal definition of struct perf_event with bpf_cookie field and not
rely on UAPI headers having full definition. Something like this:
struct perf_event___local {
u64 bpf_cookie;
} __attribute__((preserve_access_index));
Then use `struct perf_event___local` (note the three underscores, they
are important) instead of struct perf_event in BPF code.
And we'll have to do the same for struct bpf_perf_link, I presume?
> > Fixes: cbdaf71f7e65 ("bpftool: Add bpf_cookie to link output")
> > Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> > ---
> > include/linux/perf_event.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index af97dd427501..b1d5715b8b34 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -762,12 +762,14 @@ struct perf_event {
> > u64 (*clock)(void);
> > perf_overflow_handler_t overflow_handler;
> > void *overflow_handler_context;
> > +#endif /* CONFIG_PERF_EVENTS */
> > #ifdef CONFIG_BPF_SYSCALL
> > perf_overflow_handler_t orig_overflow_handler;
> > struct bpf_prog *prog;
> > u64 bpf_cookie;
> > #endif
> >
> > +#ifdef CONFIG_PERF_EVENTS
> > #ifdef CONFIG_EVENT_TRACING
> > struct trace_event_call *tp_event;
> > struct event_filter *filter;
> > --
> > 2.35.2
> >
> >
^ permalink raw reply
* Re: [PATCH net 1/1] net: stmmac: add fsleep() in HW Rx timestamp checking loop
From: Tan Tee Min @ 2022-04-20 5:15 UTC (permalink / raw)
To: Richard Cochran
Cc: Jakub Kicinski, Tan Tee Min, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S . Miller, Paolo Abeni, Maxime Coquelin,
Rayagond Kokatanur, netdev, linux-stm32, linux-arm-kernel,
linux-kernel, stable, Voon Wei Feng, Wong Vee Khee,
Song Yoong Siang, Alexandre Torgue
In-Reply-To: <20220419132853.GA19386@hoboy.vegasvil.org>
On Tue, Apr 19, 2022 at 06:28:53AM -0700, Richard Cochran wrote:
> On Tue, Apr 19, 2022 at 08:52:20AM +0800, Tan Tee Min wrote:
>
> > I agree that the fsleep(1) (=1us) is a big hammer.
> > Thus in order to improve this, I’ve figured out a smaller delay
> > time that is enough for the context descriptor to be ready which
> > is ndelay(500) (=500ns).
>
> Why isn't the context descriptor ready?
>
> I mean, the frame already belongs to the CPU, right?
No. The context descriptor (frame) is possibly still owned by the
DMA controller in this situation.
This is why a looping in the original code to wait for the descriptor
to be owned by the application CPU. However, when NAPI is busy polling,
the context descriptor might be still owned by the DMA controller even
after the looping.
Thus, we are adding an additional nanosecond delay inside the loop,
so that the DMA controller can get a short moment to breathe and
complete the context descriptor.
Thanks,
Tee Min
>
> Thanks,
> Richard
^ permalink raw reply
* Re: [PATCH 0/1] add support for enum module parameters
From: Kalle Valo @ 2022-04-20 5:13 UTC (permalink / raw)
To: Jani Nikula
Cc: Greg Kroah-Hartman, linux-kernel, intel-gfx, dri-devel,
Andrew Morton, Lucas De Marchi, linux-wireless, netdev
In-Reply-To: <87a6cneoco.fsf@intel.com>
+ linux-wireless, netdev
Jani Nikula <jani.nikula@intel.com> writes:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>> Hey, I've sent this before, ages ago, but haven't really followed
>>> through with it. I still think it would be useful for many scenarios
>>> where a plain number is a clumsy interface for a module param.
>>>
>>> Thoughts?
>>
>> We should not be adding new module parameters anyway (they operate on
>> code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
>
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
Wireless drivers would also desperately need to pass device specific
parameters at (or before) probe time. And not only debug parameters but
also configuration parameters, for example firmware memory allocations
schemes (optimise for features vs number of clients etc) and whatnot.
Any ideas how to implement that? Is there any prior work for anything
like this? This is pretty hard limiting usability of upstream wireless
drivers and I really want to find a proper solution.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next] selftests: net: vrf_strict_mode_test: add support to select a test to run
From: Jaehee @ 2022-04-20 5:01 UTC (permalink / raw)
To: Outreachy Linux Kernel, Julia Denham, Roopa Prabhu,
Stefano Brivio, netdev, Jaehee Park
In-Reply-To: <20220420045512.GA1289782@jaehee-ThinkPad-X1-Extreme>
Sorry, I sent two of the same patch by accident. Please ignore this one.
On Wed, Apr 20, 2022 at 12:55 AM Jaehee Park <jhpark1013@gmail.com> wrote:
>
> Add a boilerplate test loop to run all tests in
> vrf_strict_mode_test.sh.
>
> Signed-off-by: Jaehee Park <jhpark1013@gmail.com>
> ---
> .../testing/selftests/net/vrf_strict_mode_test.sh | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/net/vrf_strict_mode_test.sh b/tools/testing/selftests/net/vrf_strict_mode_test.sh
> index 865d53c1781c..116ca43381b5 100755
> --- a/tools/testing/selftests/net/vrf_strict_mode_test.sh
> +++ b/tools/testing/selftests/net/vrf_strict_mode_test.sh
> @@ -14,6 +14,8 @@ INIT_NETNS_NAME="init"
>
> PAUSE_ON_FAIL=${PAUSE_ON_FAIL:=no}
>
> +TESTS="vrf_strict_mode_tests_init vrf_strict_mode_tests_testns vrf_strict_mode_tests_mix"
> +
> log_test()
> {
> local rc=$1
> @@ -391,7 +393,17 @@ fi
> cleanup &> /dev/null
>
> setup
> -vrf_strict_mode_tests
> +for t in $TESTS
> +do
> + case $t in
> + vrf_strict_mode_tests_init|vrf_strict_mode_init) vrf_strict_mode_tests_init;;
> + vrf_strict_mode_tests_testns|vrf_strict_mode_testns) vrf_strict_mode_tests_testns;;
> + vrf_strict_mode_tests_mix|vrf_strict_mode_mix) vrf_strict_mode_tests_mix;;
> +
> + help) echo "Test names: $TESTS"; exit 0;;
> +
> + esac
> +done
> cleanup
>
> print_log_test_results
> --
> 2.25.1
>
^ permalink raw reply
* [PATCH net-next] selftests: net: vrf_strict_mode_test: add support to select a test to run
From: Jaehee Park @ 2022-04-20 4:55 UTC (permalink / raw)
To: outreachy, Julia Denham, Roopa Prabhu, Stefano Brivio, netdev,
jhpark1013
Add a boilerplate test loop to run all tests in
vrf_strict_mode_test.sh.
Signed-off-by: Jaehee Park <jhpark1013@gmail.com>
---
.../testing/selftests/net/vrf_strict_mode_test.sh | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/vrf_strict_mode_test.sh b/tools/testing/selftests/net/vrf_strict_mode_test.sh
index 865d53c1781c..116ca43381b5 100755
--- a/tools/testing/selftests/net/vrf_strict_mode_test.sh
+++ b/tools/testing/selftests/net/vrf_strict_mode_test.sh
@@ -14,6 +14,8 @@ INIT_NETNS_NAME="init"
PAUSE_ON_FAIL=${PAUSE_ON_FAIL:=no}
+TESTS="vrf_strict_mode_tests_init vrf_strict_mode_tests_testns vrf_strict_mode_tests_mix"
+
log_test()
{
local rc=$1
@@ -391,7 +393,17 @@ fi
cleanup &> /dev/null
setup
-vrf_strict_mode_tests
+for t in $TESTS
+do
+ case $t in
+ vrf_strict_mode_tests_init|vrf_strict_mode_init) vrf_strict_mode_tests_init;;
+ vrf_strict_mode_tests_testns|vrf_strict_mode_testns) vrf_strict_mode_tests_testns;;
+ vrf_strict_mode_tests_mix|vrf_strict_mode_mix) vrf_strict_mode_tests_mix;;
+
+ help) echo "Test names: $TESTS"; exit 0;;
+
+ esac
+done
cleanup
print_log_test_results
--
2.25.1
^ permalink raw reply related
* [PATCH] [net-next] selftests: net: vrf_strict_mode_test: add support to select a test to run
From: Jaehee Park @ 2022-04-20 4:46 UTC (permalink / raw)
To: outreachy, Julia Denham, Roopa Prabhu, Stefano Brivio, netdev,
jhpark1013
Add a boilerplate test loop to run all tests in
vrf_strict_mode_test.sh.
Signed-off-by: Jaehee Park <jhpark1013@gmail.com>
---
.../testing/selftests/net/vrf_strict_mode_test.sh | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/vrf_strict_mode_test.sh b/tools/testing/selftests/net/vrf_strict_mode_test.sh
index 865d53c1781c..116ca43381b5 100755
--- a/tools/testing/selftests/net/vrf_strict_mode_test.sh
+++ b/tools/testing/selftests/net/vrf_strict_mode_test.sh
@@ -14,6 +14,8 @@ INIT_NETNS_NAME="init"
PAUSE_ON_FAIL=${PAUSE_ON_FAIL:=no}
+TESTS="vrf_strict_mode_tests_init vrf_strict_mode_tests_testns vrf_strict_mode_tests_mix"
+
log_test()
{
local rc=$1
@@ -391,7 +393,17 @@ fi
cleanup &> /dev/null
setup
-vrf_strict_mode_tests
+for t in $TESTS
+do
+ case $t in
+ vrf_strict_mode_tests_init|vrf_strict_mode_init) vrf_strict_mode_tests_init;;
+ vrf_strict_mode_tests_testns|vrf_strict_mode_testns) vrf_strict_mode_tests_testns;;
+ vrf_strict_mode_tests_mix|vrf_strict_mode_mix) vrf_strict_mode_tests_mix;;
+
+ help) echo "Test names: $TESTS"; exit 0;;
+
+ esac
+done
cleanup
print_log_test_results
--
2.25.1
^ permalink raw reply related
* [PATCH iproute2-next v2] ip-link: put types on man page in alphabetic order
From: Stephen Hemminger @ 2022-04-20 3:11 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Lets try and keep man pages using alpha order, it looks like
it started that way then drifted.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
man/man8/ip-link.8.in | 175 +++++++++++++++++++++---------------------
1 file changed, 89 insertions(+), 86 deletions(-)
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index ec3cc4297da5..fc214a10c4e7 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -209,43 +209,43 @@ ip-link \- network device configuration
.ti -8
.IR TYPE " := [ "
.BR amt " | "
-.BR bridge " | "
+.BR bareudp " |"
.BR bond " | "
+.BR bridge " | "
.BR can " | "
.BR dummy " | "
-.BR hsr " | "
-.BR ifb " | "
-.BR ipoib " |"
-.BR macvlan " | "
-.BR macvtap " | "
-.BR vcan " | "
-.BR vxcan " | "
-.BR veth " | "
-.BR vlan " | "
-.BR vxlan " |"
-.BR ip6tnl " |"
-.BR ipip " |"
-.BR sit " |"
+.BR erspan " |"
+.BR geneve " |"
.BR gre " |"
.BR gretap " |"
-.BR erspan " |"
+.BR gtp " |"
+.BR hsr " | "
+.BR ifb " | "
+.BR ip6erspan " |"
.BR ip6gre " |"
.BR ip6gretap " |"
-.BR ip6erspan " |"
-.BR vti " |"
-.BR nlmon " |"
+.BR ip6tnl " |"
+.BR ipip " |"
+.BR ipoib " |"
.BR ipvlan " |"
.BR ipvtap " |"
.BR lowpan " |"
-.BR geneve " |"
-.BR bareudp " |"
-.BR vrf " |"
.BR macsec " |"
+.BR macvlan " | "
+.BR macvtap " | "
.BR netdevsim " |"
+.BR nlmon " |"
.BR rmnet " |"
-.BR xfrm " |"
-.BR gtp " |"
-.BR virt_wifi " ]"
+.BR sit " |"
+.BR vcan " | "
+.BR veth " | "
+.BR virt_wifi " |"
+.BR vlan " | "
+.BR vrf " |"
+.BR vti " |"
+.BR vxcan " | "
+.BR vxlan " |"
+.BR xfrm " ]"
.ti -8
.IR ETYPE " := [ " TYPE " |"
@@ -290,44 +290,52 @@ specifies the type of the new device.
Link types:
.in +8
-.B bridge
-- Ethernet Bridge device
+.BR amt
+- Automatic Multicast Tunneling (AMT)
+.sp
+.BR bareudp
+- Bare UDP L3 encapsulation support
.sp
.B bond
- Bonding device
+.B bridge
+- Ethernet Bridge device
+.sp
+.B can
+- Controller Area Network
.sp
.B dummy
- Dummy network interface
.sp
-.B hsr
-- High-availability Seamless Redundancy device
+.BR erspan
+- Encapsulated Remote SPAN over GRE and IPv4
.sp
-.B ifb
-- Intermediate Functional Block device
+.B geneve
+- GEneric NEtwork Virtualization Encapsulation
.sp
-.B ipoib
-- IP over Infiniband device
+.B gre
+- Virtual tunnel interface GRE over IPv4
.sp
-.B macvlan
-- Virtual interface base on link layer address (MAC)
+.BR gretap
+- Virtual L2 tunnel interface GRE over IPv4
.sp
-.B macvtap
-- Virtual interface based on link layer address (MAC) and TAP.
+.BR gtp
+- GPRS Tunneling Protocol
.sp
-.B vcan
-- Virtual Controller Area Network interface
+.B hsr
+- High-availability Seamless Redundancy device
.sp
-.B vxcan
-- Virtual Controller Area Network tunnel interface
+.B ifb
+- Intermediate Functional Block device
.sp
-.B veth
-- Virtual ethernet interface
+.BR ip6erspan
+- Encapsulated Remote SPAN over GRE and IPv6
.sp
-.BR vlan
-- 802.1q tagged virtual LAN interface
+.BR ip6gre
+- Virtual tunnel interface GRE over IPv6
.sp
-.BR vxlan
-- Virtual eXtended LAN
+.BR ip6gretap
+- Virtual L2 tunnel interface GRE over IPv6
.sp
.BR ip6tnl
- Virtual tunnel interface IPv4|IPv6 over IPv6
@@ -335,71 +343,66 @@ Link types:
.BR ipip
- Virtual tunnel interface IPv4 over IPv4
.sp
-.BR sit
-- Virtual tunnel interface IPv6 over IPv4
+.B ipoib
+- IP over Infiniband device
.sp
-.BR gre
-- Virtual tunnel interface GRE over IPv4
+.BR ipvlan
+- Interface for L3 (IPv6/IPv4) based VLANs
.sp
-.BR gretap
-- Virtual L2 tunnel interface GRE over IPv4
+.BR ipvtap
+- Interface for L3 (IPv6/IPv4) based VLANs and TAP
.sp
-.BR erspan
-- Encapsulated Remote SPAN over GRE and IPv4
+.BR lowpan
+- Interface for 6LoWPAN (IPv6) over IEEE 802.15.4 / Bluetooth
.sp
-.BR ip6gre
-- Virtual tunnel interface GRE over IPv6
+.BR macsec
+- Interface for IEEE 802.1AE MAC Security (MACsec)
.sp
-.BR ip6gretap
-- Virtual L2 tunnel interface GRE over IPv6
+.B macvlan
+- Virtual interface base on link layer address (MAC)
.sp
-.BR ip6erspan
-- Encapsulated Remote SPAN over GRE and IPv6
+.B macvtap
+- Virtual interface based on link layer address (MAC) and TAP.
.sp
-.BR vti
-- Virtual tunnel interface
+.BR netdevsim
+- Interface for netdev API tests
.sp
.BR nlmon
- Netlink monitoring device
.sp
-.BR ipvlan
-- Interface for L3 (IPv6/IPv4) based VLANs
-.sp
-.BR ipvtap
-- Interface for L3 (IPv6/IPv4) based VLANs and TAP
+.BR rmnet
+- Qualcomm rmnet device
.sp
-.BR lowpan
-- Interface for 6LoWPAN (IPv6) over IEEE 802.15.4 / Bluetooth
+.BR sit
+- Virtual tunnel interface IPv6 over IPv4
.sp
-.BR geneve
-- GEneric NEtwork Virtualization Encapsulation
+.B vcan
+- Virtual Controller Area Network interface
.sp
-.BR bareudp
-- Bare UDP L3 encapsulation support
+.B veth
+- Virtual ethernet interface
.sp
-.BR amt
-- Automatic Multicast Tunneling (AMT)
+.BR virt_wifi
+- rtnetlink wifi simulation device
.sp
-.BR macsec
-- Interface for IEEE 802.1AE MAC Security (MACsec)
+.BR vlan
+- 802.1q tagged virtual LAN interface
.sp
.BR vrf
- Interface for L3 VRF domains
.sp
-.BR netdevsim
-- Interface for netdev API tests
+.BR vti
+- Virtual tunnel interface
.sp
-.BR rmnet
-- Qualcomm rmnet device
+.B vxcan
+- Virtual Controller Area Network tunnel interface
+.sp
+.BR vxlan
+- Virtual eXtended LAN
.sp
.BR xfrm
- Virtual xfrm interface
.sp
-.BR gtp
-- GPRS Tunneling Protocol
-.sp
-.BR virt_wifi
-- rtnetlink wifi simulation device
.in -8
.TP
--
2.35.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox