linux-stable.git/drivers/net/wan, branch v5.11

net: hdlc_x25: Return meaningful error code in x25_open

2021-02-05T02:13:25+00:00

It's not meaningful to pass on LAPB error codes to HDLC code or other
parts of the system, because they will not understand the error codes.

Instead, use system-wide recognizable error codes.

Fixes: f362e5fe0f1f ("wan/hdlc_x25: make lapb params configurable")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xie He 
Acked-by: Martin Schiller 
Link: https://lore.kernel.org/r/20210203071541.86138-1-xie.he.0141@gmail.com
Signed-off-by: Jakub Kicinski

wan: ds26522: select CONFIG_BITREVERSE

2021-01-05T23:50:36+00:00

Without this, the driver runs into a link failure

arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_ds26522_probe':
slic_ds26522.c:(.text+0x100c): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: slic_ds26522.c:(.text+0x1cdc): undefined reference to `byte_rev_table'
arm-linux-gnueabi-ld: drivers/net/wan/slic_ds26522.o: in function `slic_write':
slic_ds26522.c:(.text+0x1e4c): undefined reference to `byte_rev_table'

Fixes: c37d4a0085c5 ("Maxim/driver: Add driver for maxim ds26522")
Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller

net: hdlc_ppp: Fix issues when mod_timer is called while timer is running

2020-12-28T23:09:04+00:00

ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
held. It may call mod_timer to add a new timer. However, at the same time
ppp_timer may be already running and waiting for "ppp->lock". In this
case, there's no need for ppp_timer to continue running and it can just
exit.

If we let ppp_timer continue running, it may call add_timer. This causes
kernel panic because add_timer can't be called with a timer pending.
This patch fixes this problem.

Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic HDLC.")
Cc: Krzysztof Halasa 
Signed-off-by: Xie He 
Signed-off-by: David S. Miller

net: lapbether: Consider it successful if (dis)connecting when already (dis)connected

2020-12-10T21:18:28+00:00

When the upper layer instruct us to connect (or disconnect), but we have
already connected (or disconnected), consider this operation successful
rather than failed.

This can help the upper layer to correct its record about whether we are
connected or not here in layer 2.

The upper layer may not have the correct information about whether we are
connected or not. This can happen if this driver has already been running
for some time when the "x25" module gets loaded.

Another X.25 driver (hdlc_x25) is already doing this, so we make this
driver do this, too.

Cc: Martin Schiller 
Signed-off-by: Xie He 
Acked-by: Martin Schiller 
Signed-off-by: David S. Miller

net: hdlc_x25: Remove unnecessary skb_reset_network_header calls

2020-12-10T03:22:48+00:00

1. In x25_xmit, skb_reset_network_header is not necessary before we call
lapb_data_request. The lapb module doesn't need skb->network_header.
So there is no need to set skb->network_header before calling
lapb_data_request.

2. In x25_data_indication (called by the lapb module after data have
been received), skb_reset_network_header is not necessary before we
call netif_rx. After we call netif_rx, the code in net/core/dev.c will
call skb_reset_network_header before handing the skb to upper layers
(in __netif_receive_skb_core, called by __netif_receive_skb_one_core,
called by __netif_receive_skb, called by process_backlog). So we don't
need to call skb_reset_network_header by ourselves.

Cc: Martin Schiller 
Signed-off-by: Xie He 
Signed-off-by: David S. Miller

net: wan: remove trailing semicolon in macro definition

2020-12-01T02:58:31+00:00

The macro use will already have a semicolon.

Signed-off-by: Tom Rix 
Link: https://lore.kernel.org/r/20201127165734.2694693-1-trix@redhat.com
Signed-off-by: Jakub Kicinski

net: wan: Delete the DLCI / SDLA drivers

2020-11-17T21:33:29+00:00

The DLCI driver (dlci.c) implements the Frame Relay protocol. However,
we already have another newer and better implementation of Frame Relay
provided by the HDLC_FR driver (hdlc_fr.c).

The DLCI driver's implementation of Frame Relay is used by only one
hardware driver in the kernel - the SDLA driver (sdla.c).

The SDLA driver provides Frame Relay support for the Sangoma S50x devices.
However, the vendor provides their own driver (along with their own
multi-WAN-protocol implementations including Frame Relay), called WANPIPE.
I believe most users of the hardware would use the vendor-provided WANPIPE
driver instead.

(The WANPIPE driver was even once in the kernel, but was deleted in
commit 8db60bcf3021 ("[WAN]: Remove broken and unmaintained Sangoma
drivers.") because the vendor no longer updated the in-kernel WANPIPE
driver.)

Cc: Mike McLagan 
Signed-off-by: Xie He 
Link: https://lore.kernel.org/r/20201114150921.685594-1-xie.he.0141@gmail.com
Signed-off-by: Jakub Kicinski

Merge https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-11-13T00:54:48+00:00

Signed-off-by: Jakub Kicinski

cosa: Add missing kfree in error path of cosa_write

2020-11-12T01:52:01+00:00

If memory allocation for 'kbuf' succeed, cosa_write() doesn't have a
corresponding kfree() in exception handling. Thus add kfree() for this
function implementation.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Hulk Robot 
Signed-off-by: Wang Hai 
Acked-by: Jan "Yenya" Kasprzak 
Link: https://lore.kernel.org/r/20201110144614.43194-1-wanghai38@huawei.com
Signed-off-by: Jakub Kicinski

net: x25_asy: Delete the x25_asy driver

2020-11-07T22:13:44+00:00

This driver transports LAPB (X.25 link layer) frames over TTY links.

I can safely say that this driver has no actual user because it was
not working at all until:
commit 8fdcabeac398 ("drivers/net/wan/x25_asy: Fix to make it work")

The code in its current state still has problems:

1.
The uses of "struct x25_asy" in x25_asy_unesc (when receiving) and in
x25_asy_write_wakeup (when sending) are not protected by locks against
x25_asy_change_mtu's changing of the transmitting/receiving buffers.
Also, all "netif_running" checks in this driver are not protected by
locks against the ndo_stop function.

2.
The driver stops all TTY read/write when the netif is down.
I think this is not right because this may cause the last outgoing frame
before the netif goes down to be incompletely transmitted, and the first
incoming frame after the netif goes up to be incompletely received.

And there may also be other problems.

I was planning to fix these problems but after recent discussions about
deleting other old networking code, I think we may just delete this
driver, too.

Signed-off-by: Xie He 
Acked-by: Martin Schiller 
Link: https://lore.kernel.org/r/20201105073434.429307-1-xie.he.0141@gmail.com
Signed-off-by: Jakub Kicinski