] sock_sendmsg+0x2d/0x40
> [ 820.077999][T10805] sys_sendmsg+0x1a2/0x1d0
> [ 820.694928][T10805] ? import_iovec+0x13/0x20
> [ 821.220194][T10805] ___sys_sendmsg+0x98/0xd0
> [ 821.927886][T10805] ? file_update_time+0x4b/0x130
> [ 822.458245][T10805] ? vfs_write+0x32c/0x3f0
On 4/12/2021 6:48 PM, Jason Gunthorpe wrote:
On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
So the issue is only in testing all the providers and platforms,
to be sure this new behavior isn't tickling anything that went
unnoticed all along, because no RDMA provider ever issu
On 4/12/2021 2:32 PM, Haakon Bugge wrote:
On 10 Apr 2021, at 15:30, David Laight wrote:
From: Tom Talpey
Sent: 09 April 2021 18:49
On 4/9/2021 12:27 PM, Haakon Bugge wrote:
On 9 Apr 2021, at 17:32, Tom Talpey wrote:
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10
On 4/9/2021 12:27 PM, Haakon Bugge wrote:
On 9 Apr 2021, at 17:32, Tom Talpey wrote:
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote
On 4/9/2021 12:40 PM, Jason Gunthorpe wrote:
On Fri, Apr 09, 2021 at 10:26:21AM -0400, Tom Talpey wrote:
My belief is that the biggest risk is from situations where completions
are batched, and therefore polling is used to detect them without
interrupts (which explicitly).
We don't do
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
We need to get a better idea what correctness testing has been done,
and whether
e should test on the platforms they have.
Yes, and "test" be taken seriously with focus on ULP data integrity.
Speedups will mean nothing if the data is ever damaged.
Tom.
Never mind. In case anyone was wondering, PACKET_ADD_MEMBERSHIP is a
SOL_PACKET option, not SOL_SOCKET. Only took me two days to spot!
On Tue, Apr 6, 2021 at 8:13 PM Tom Cook wrote:
>
> Can someone please suggest why the code below doesn't do as expected?
> I expect it to bin
pe to be ETH_P_ALL instead (and
re-instate the bind() call), then it receives all ethernet frames
received on eth0.
Is this a bug? Or is it as expected and I have to use some other
mechanism (BPF?) to filter the frames?
Thanks for any assistance,
Tom
Code:
#include
#include
#include
#in
gest making this the default behavior
without extensive testing.
Tom.
if (acc & ~IB_ACCESS_LOCAL_WRITE) {
dev_warn(&dev->pdev->dev,
"unsupported dma mr access flags %#x\n", acc);
Why does the pvrdma driver require relaxed ordering to be off?
Tom.
c095 ("amd-xgbe: Adjust register settings to improve
> performance")
> Signed-off-by: Shyam Sundar S K
Acked-by: Tom Lendacky
> ---
>
> Please queue this patch up for stable, 4.14 and higher.
>
> drivers/net/ethernet/amd/xgbe/xgbe.h | 6 +++---
> 1 file changed,
(status == SUCCESS) {
> - if (ai->rssi || (ai->rssi = kmalloc(512, GFP_KERNEL))
> != NULL)
> - memcpy(ai->rssi, (u8*)&rssi_rid + 2, 512); /*
> Skip RID length member */
Here is the temp being copi
On Mon, Mar 15, 2021 at 13:18:24 +0100, Guillaume Nault wrote:
> On Fri, Mar 12, 2021 at 10:47:53PM +0800, lyl2...@mail.ustc.edu.cn wrote:
> >
> >
> >
> > > -原始邮件-
> > > 发件人: "Tom Parkin"
> > > 发送时间: 2021-03-12 18:12:
On Fri, Mar 12, 2021 at 22:47:53 +0800, lyl2...@mail.ustc.edu.cn wrote:
>
>
>
> > -原始邮件-----
> > 发件人: "Tom Parkin"
> > 发送时间: 2021-03-12 18:12:58 (星期五)
> > 收件人: lyl2...@mail.ustc.edu.cn
> > 抄送: pau...@samba.org, da...@davemloft.net, linux
Thanks for the report!
On Thu, Mar 11, 2021 at 20:34:44 +0800, lyl2...@mail.ustc.edu.cn wrote:
> File: drivers/net/ppp/ppp_generic.c
>
> In ppp_unregister_channel, pch could be freed in ppp_unbridge_channels()
> but after that pch is still in use. Inside the function ppp_unbridge_channels,
> if
> 24 files changed, 71 insertions(+), 59 deletions(-)
> create mode 100644 drivers/clk/socfpga/Kconfig
>
Thanks for changing the config name.
Please review checkpatch --strict on this set, the typical complaint is
clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs (and compile
test)
WARNING: please write a paragraph that describes the config symbol fully
#35: FILE: drivers/clk/socfpg/Kconfig:11:
+config CLK_INTEL_SOCFPGA32
Tom
me:
>
> Acked-by: Lee Jones
I think the name is too broad, from the description in the config
+ bool "Intel's SoCFPGA ARMv8 Families"
A better name would be ARCH_INTEL_SOCFPGA64
So other vendors like Xilinx could do their own thing.
Tom
>
>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 4 ++--
>> drivers/reset/Kconfig | 2 +-
>> 12 files changed, 21 insertions(+), 20 deletions(-)
On Wed, Mar 03, 2021 at 16:50:49 +0100, Matthias Schiffer wrote:
> Commit 5ee759cda51b ("l2tp: use standard API for warning log messages")
> changed a number of warnings about invalid packets in the receive path
> so that they are always shown, instead of only when a special L2TP debug
> flag is s
Never mind, I found commit b3bdc3acbb44d74d0b7ba4d97169577a2b46dc88
that fixed this in 4.10-rc9 or so. Sorry for wasting your time.
Regards,
Tom Cook
On Mon, Mar 1, 2021 at 3:00 PM Tom Cook wrote:
>
> I'm trying to use MACSEC on an arm64 embedded platform; I'm trying to
>
The SOC is a cavium cn8030. This part is equipped with a crypto
accelerator but support for it is not compiled into the kernel.
Thanks for any help,
Tom Cook
On Mon, Feb 22, 2021 at 14:31:38 -0800, Jakub Kicinski wrote:
> On Mon, 22 Feb 2021 17:40:16 +0100 Matthias Schiffer wrote:
> > >> This will not be sufficient for my usecase: To stay compatible with older
> > >> versions of fastd, I can't set the T flag in the first packet of the
> > >> handshake,
On Mon, Feb 22, 2021 at 17:40:16 +0100, Matthias Schiffer wrote:
> On 2/22/21 12:49 PM, Tom Parkin wrote:
> > On Sat, Feb 20, 2021 at 10:56:33 +0100, Matthias Schiffer wrote:
> > > On 2/19/21 9:12 PM, Tom Parkin wrote:
> > > > On Fri, Feb 19, 2021 at 20:06:15
On Sat, Feb 20, 2021 at 10:56:33 +0100, Matthias Schiffer wrote:
> On 2/19/21 9:12 PM, Tom Parkin wrote:
> > On Fri, Feb 19, 2021 at 20:06:15 +0100, Matthias Schiffer wrote:
> > > Before commit 5ee759cda51b ("l2tp: use standard API for warning log
> > > messages&
in the igb driver.
Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver")
Signed-off-by: Tom Seewald
---
drivers/net/ethernet/intel/igb/e1000_hw.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h
b/
the e1000e driver by renaming it.
Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for
ICH9 devices only)")
Signed-off-by: Tom Seewald
---
drivers/net/ethernet/intel/e1000e/hw.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e
Hi Matthias,
Thanks for your patch!
On Fri, Feb 19, 2021 at 20:06:15 +0100, Matthias Schiffer wrote:
> Before commit 5ee759cda51b ("l2tp: use standard API for warning log
> messages"), it was possible for userspace applications to use their own
> control protocols on the backing sockets of an L2
: Shyam Sundar S K
Same comment about Co-developed-by: tag as previous patch.
With that addressed,
Acked-by: Tom Lendacky
---
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c
b/drivers/net
ethtool to recognize the
link down and get the link change message.
Signed-off-by: Sudheesh Mavila
Signed-off-by: Shyam Sundar S K
Same comment about Co-developed-by: as previous patch.
With those addressed,
Acked-by: Tom Lendacky
---
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 2 +-
d
-developed-by: here as previous patch.
With the above comments addressed,
Acked-by: Tom Lendacky
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 1 +
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe
- if (XP_IOREAD_BITS(pdata, XP_DRIVER_INT_RO, STATUS))
+ if (XP_IOREAD_BITS(pdata, XP_DRIVER_INT_RO, STATUS)) {
netif_dbg(pdata, link, pdata->netdev,
"firmware mailbox not ready for command\n");
+ xgbe_phy_rx_re
Fix this typo by simply removing the duplicate 'and'.
Signed-off-by: Tom Seewald
---
drivers/staging/qlge/qlge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c
index dfe8cdf38ce0..5516be3af
t;ddp_crc != nskb->ddp_crc)
> + goto end;
> #endif
> }
> }
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 777306b5bc22..b114fc870513 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1810,6 +1810,9 @@ bool tcp_add_backlog(struct sock *sk, struct sk_buff
> *skb)
> TCP_SKB_CB(skb)->tcp_flags) & (TCPHDR_ECE | TCPHDR_CWR)) ||
> #ifdef CONFIG_TLS_DEVICE
> tail->decrypted != skb->decrypted ||
> +#endif
> +#ifdef CONFIG_TCP_DDP
> + tail->ddp_crc != skb->ddp_crc ||
> #endif
> thtail->doff != th->doff ||
> memcmp(thtail + 1, th + 1, hdrlen - sizeof(*th)))
> diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c
> index e09147ac9a99..3ce196375d94 100644
> --- a/net/ipv4/tcp_offload.c
> +++ b/net/ipv4/tcp_offload.c
> @@ -262,6 +262,9 @@ struct sk_buff *tcp_gro_receive(struct list_head *head,
> struct sk_buff *skb)
> #ifdef CONFIG_TLS_DEVICE
> flush |= p->decrypted ^ skb->decrypted;
> #endif
> +#ifdef CONFIG_TCP_DDP
> + flush |= p->ddp_crc ^ skb->ddp_crc;
> +#endif
>
> if (flush || skb_gro_receive(p, skb)) {
> mss = 1;
> --
> 2.24.1
>
--
Tom Parkin
Katalix Systems Ltd
https://katalix.com
Catalysts for your Embedded Linux software development
signature.asc
Description: PGP signature
pplies after it
receives the packets from the queue.
Thanks again,
Tom Cook
On Fri, Jan 08, 2021 at 21:57:50 +0100, Guillaume Nault wrote:
> On Thu, Jan 07, 2021 at 06:13:15PM +0000, Tom Parkin wrote:
> > When setting up a channel bridge, ppp_bridge_channels sets the
> > pch->bridge field before taking the associated reference on the bridge
before it is unset by the error path, it will erroneously drop the
reference on the bridged channel and cause a refcount underflow.
To avoid this, ensure that ppp_bridge_channels holds a reference on
each channel in advance of setting the bridge pointers.
Signed-off-by: Tom Parkin
Fixes: 4cf4
On 1/6/21 1:09 PM, David Howells wrote:
> Tom Rix wrote:
>
>> On 1/6/21 11:44 AM, David Howells wrote:
>>> Tom Rix wrote:
>>>
>>>> These two loops iterate over the same data, i believe returning here is all
>>>> that is needed.
>>&g
On 1/6/21 11:44 AM, David Howells wrote:
> Tom Rix wrote:
>
>> These two loops iterate over the same data, i believe returning here is all
>> that is needed.
> But if the first loop is made to support a new type, but the second loop is
> missed, it will then likely oops
ing both loops log a message and return an error in this
> case. This should only happen if a new token type is incompletely
> implemented, so it should normally be impossible to trigger this.
>
> Fixes: 9a059cd5ca7d ("rxrpc: Downgrade the BUG() for unsupported t
When setting up a channel bridge, ppp_bridge_channels sets the
pch->bridge field before taking the associated reference on the bridge
file instance.
This opens up a refcount underflow bug if ppp_bridge_channels called
via. iotcl runs concurrently with ppp_unbridge_channels executing via.
file rele
TY_RXKAD:
> These switches need to be kept. There's another security type on the way.
> See:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk
>
> for example. I'll have a look later.
Yes, looks like more stuff is coming.
Thanks!
Tom
> David
>
On 12/25/20 9:06 AM, Joe Perches wrote:
> On Fri, 2020-12-25 at 06:56 -0800, Tom Rix wrote:
>> On 12/24/20 2:39 PM, Joe Perches wrote:
> []
>>> Kernel code doesn't use a signed char or short with %hx or %hu very often
>>> but in case you didn't already
On 12/24/20 2:39 PM, Joe Perches wrote:
> On Thu, 2020-12-24 at 14:14 -0800, Tom Rix wrote:
>> On 12/24/20 12:21 PM, Simon Horman wrote:
>>> On Wed, Dec 23, 2020 at 12:20:53PM -0800, t...@redhat.com wrote:
>>>> From: Tom Rix
>>>>
>>>> This
On 12/24/20 12:21 PM, Simon Horman wrote:
> On Wed, Dec 23, 2020 at 12:20:53PM -0800, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> This change fixes the checkpatch warning described in this commit
>> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouragin
On Thu, Dec 24, 2020 at 11:28:18 +0100, Guillaume Nault wrote:
> On Wed, Dec 23, 2020 at 06:47:30PM +0000, Tom Parkin wrote:
> > Channels are bridged using the PPPIOCBRIDGECHAN ioctl, which executes
> > with the ppp_mutex held.
> >
> > Unbridging may occur in two code
On 12/23/20 12:14 PM, Joe Perches wrote:
> On Wed, 2020-12-23 at 11:43 -0800, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> This change fixes the checkpatch warning described in this commit
>> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
underflow.
To avoid this, hold the ppp_mutex while calling ppp_unbridge_channels in
the shutdown path. This serialises the unbridge operation with any
concurrently executing ioctl.
Signed-off-by: Tom Parkin
---
drivers/net/ppp/ppp_generic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/driv
On 12/17/20 9:28 AM, Jakub Kicinski wrote:
> On Thu, 17 Dec 2020 05:17:24 -0800 Tom Rix wrote:
>> On 12/16/20 4:45 PM, Jakub Kicinski wrote:
>>> On Tue, 15 Dec 2020 06:22:28 -0800 t...@redhat.com wrote:
>>>> From: Tom Rix
>>>>
>>>> See Do
On 12/16/20 4:45 PM, Jakub Kicinski wrote:
> On Tue, 15 Dec 2020 06:22:28 -0800 t...@redhat.com wrote:
>> From: Tom Rix
>>
>> See Documentation/core-api/printk-formats.rst.
>> h should no longer be used in the format specifier for printk.
>>
>> Signed-o
On 12/13/20 3:25 PM, Joe Perches wrote:
> On Sun, 2020-12-13 at 11:21 -0800, Tom Rix wrote:
>> On 12/2/20 2:34 PM, Nick Desaulniers wrote:
>>> On Tue, Nov 10, 2020 at 2:04 PM Joe Perches wrote:
>>>> On Tue, 2020-11-10 at 14:00 -0800, Nick Desaulniers wrote:
>&g
gt;
>> I think one of the checkpatch improvement mentees is adding
>> some suggestion and I hope an automated fix mechanism for that.
>>
>> https://lore.kernel.org/lkml/5e3265c241602bb54286fbaae9222070daa4768e.ca...@perches.com/
> + Tom, who's been looking at leveraging cl
On Thu, Dec 10, 2020 at 14:21:34 -0800, David Miller wrote:
> From: Tom Parkin
> Date: Thu, 10 Dec 2020 17:16:45 +
>
> > On Thu, Dec 10, 2020 at 18:13:09 +0100, Guillaume Nault wrote:
> >> On Thu, Dec 10, 2020 at 03:50:56PM +, Tom Parkin wrote:
> >> &g
On Thu, Dec 10, 2020 at 18:13:09 +0100, Guillaume Nault wrote:
> On Thu, Dec 10, 2020 at 03:50:56PM +0000, Tom Parkin wrote:
> > Following on from my previous RFC[1], this series adds two ioctl calls
> > to the ppp code to implement "channel bridging".
> >
> &
rather than adding a new lock.
The 'upl' lock is used to protect the existing unit pointer. Since the
bridge effectively replaces the unit (they're mutually exclusive for a
channel) it makes coding easier to use the same lock to cover them
both.
Signed-off-by: Tom Park
Add documentation of the newly-added PPPIOCBRIDGECHAN and
PPPIOCUNBRIDGECHAN ioctls.
Signed-off-by: Tom Parkin
---
Documentation/networking/ppp_generic.rst | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/networking/ppp_generic.rst
b/Documentation/networking
ppp_disconnect_channel.
* Improve docs update by including information on ioctl arguments
and error return codes.
Tom Parkin (2):
ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls
docs: update ppp_generic.rst to document new ioctls
Documentation/networking/ppp_generi
On Mon, Dec 07, 2020 at 17:22:28 +0100, Guillaume Nault wrote:
> On Fri, Dec 04, 2020 at 04:36:55PM +0000, Tom Parkin wrote:
> > + case PPPIOCBRIDGECHAN:
> > + if (get_user(unit, p))
> > + break;
> > +
rather than adding a new lock.
The 'upl' lock is used to protect the existing unit pointer. Since the
bridge effectively replaces the unit (they're mutually exclusive for a
channel) it makes coding easier to use the same lock to cover them
both.
Signed-off-by: Tom Park
Add documentation of the newly-added PPPIOCBRIDGECHAN and
PPPIOCUNBRIDGECHAN ioctls.
Signed-off-by: Tom Parkin
---
Documentation/networking/ppp_generic.rst | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/networking/ppp_generic.rst
b/Documentation/networking
part of a bridge: this better aligns with the return code from
ppp_disconnect_channel.
* Improve docs update by including information on ioctl arguments
and error return codes.
Tom Parkin (2):
ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls
docs: update ppp_gen
On Thu, Dec 03, 2020 at 01:23:18 +0100, Guillaume Nault wrote:
> On Tue, Dec 01, 2020 at 11:52:49AM +0000, Tom Parkin wrote:
> > +static int ppp_bridge_channels(struct channel *pch, struct channel *pchb)
> > +{
> > + write_lock_bh(&pch->upl);
> > + if (pch
gt;
>> I think one of the checkpatch improvement mentees is adding
>> some suggestion and I hope an automated fix mechanism for that.
>>
>> https://lore.kernel.org/lkml/5e3265c241602bb54286fbaae9222070daa4768e.ca...@perches.com/
> + Tom, who's been looking at leveraging cl
On 11/30/20 7:01 PM, Jakub Kicinski wrote:
> On Fri, 27 Nov 2020 08:55:50 -0800 t...@redhat.com wrote:
>> From: Tom Rix
>>
>> The macro use will already have a semicolon.
>>
>> Signed-off-by: Tom Rix
>> ---
>> drivers/net/ethernet/brocade/bna
Add documentation of the newly-added PPPIOCBRIDGECHAN and
PPPIOCUNBRIDGECHAN ioctls.
Signed-off-by: Tom Parkin
---
Documentation/networking/ppp_generic.rst | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/networking/ppp_generic.rst
b/Documentation/networking
rather than adding a new lock.
The 'upl' lock is used to protect the existing unit pointer. Since the
bridge effectively replaces the unit (they're mutually exclusive for a
channel) it makes coding easier to use the same lock to cover them
both.
Signed-off-by: Tom Park
27;t
part of a bridge: this better aligns with the return code from
ppp_disconnect_channel.
* Improve docs update by including information on ioctl arguments
and error return codes.
Tom Parkin (2):
ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls
docs: update ppp_g
On Fri, Nov 27, 2020 at 20:31:34 +0100, Guillaume Nault wrote:
> On Thu, Nov 26, 2020 at 12:24:25PM +0000, Tom Parkin wrote:
> > This new ioctl pair allows two ppp channels to be bridged together:
> > frames arriving in one channel are transmitted in the other channel
>
On 11/27/20 4:54 PM, Daniel Borkmann wrote:
> On 11/27/20 8:27 PM, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> The macro use will already have a semicolon.
>>
>> Signed-off-by: Tom Rix
>> ---
>> include/trace/events/xdp.h | 4 ++--
>
On 11/29/20 8:50 AM, Trond Myklebust wrote:
> On Sun, 2020-11-29 at 16:42 +, Trond Myklebust wrote:
>> Hi Tom,
>>
>> On Fri, 2020-11-27 at 11:43 -0800, t...@redhat.com wrote:
>>> From: Tom Rix
>>>
>>> The macro use will already
Add documentation of the newly-added PPPIOCBRIDGECHAN and
PPPIOCUNBRIDGECHAN ioctls.
Signed-off-by: Tom Parkin
---
Documentation/networking/ppp_generic.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/networking/ppp_generic.rst
b/Documentation/networking
(rather than adding a new lock).
Order of lock acquisition is maintained: i.e. the channel 'upl' lock is
always acquired before 'downl' in code paths that need to hold both.
Signed-off-by: Tom Parkin
---
drivers/net/ppp/ppp_generic.c | 147 -
inclu
p_ac_pppoe_tests_2
Tom Parkin (2):
ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls
docs: update ppp_generic.rst to document new ioctls
Documentation/networking/ppp_generic.rst | 9 ++
drivers/net/ppp/ppp_generic.c| 143 ++-
include/uapi
eaner manner.
I am having problems applying the patchset to today's linux-next.
Which kernel should I be using ?
Thanks,
Tom
On 11/22/20 10:22 AM, Joe Perches wrote:
> On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
>> On 11/21/20 9:10 AM, Joe Perches wrote:
>>> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>>>> A difficult part of automating commits is composing the subsyst
Detect inclusion cycles in headers'
>> @echo ' coccicheck - Check with Coccinelle'
>> @echo ' clang-analyzer - Check with clang static analyzer'
>> @echo ' clang-tidy - Check with clang-tidy'
>> +@echo ' clang-tidy-fix - Check and fix with clang-tidy'
> A pity the ordering of the code below isn't the same as the above.
Taken care thanks!
Tom
On 11/22/20 6:56 AM, Matthew Wilcox wrote:
> On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote:
>> On 11/21/20 7:23 PM, Matthew Wilcox wrote:
>>> On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
>>>> The fixer review is
>>>> https
;s all very well to enable
> stricter warnings, but if they don't fix any bugs, they're just churn.
>
While enabling additional warnings may be a side effect of this effort
the primary goal is to set up a cleaning robot. After that a refactoring robot.
Tom
ed reference to `tls_validate_xmit_skb'
Fix this by ensuring that if TLS is set to be a module, CHELSIO_T4 will
also be compiled as a module. As otherwise the cxgb4 driver will not be
able to access TLS' symbols.
Fixes: 9d2e5e9eeb59 ("cxgb4/ch_ktls: decrypted bit is not enoug
On Thu, Nov 19, 2020 at 11:37 AM Jakub Kicinski wrote:
>
> On Wed, 18 Nov 2020 23:40:40 -0600 Tom Seewald wrote:
> > On Tue, Nov 17, 2020 at 4:26 PM Jakub Kicinski wrote:
> > >
> > > On Sun, 15 Nov 2020 20:31:40 -0600 Tom Seewald wrote:
> > > >
looks like
the defauly behavior allows changing the hash. Am I missing something?
Thanks,
Tom
On Wed, Nov 18, 2020 at 16:44:11 +0530, siddhant gupta wrote:
> On Wed, 18 Nov 2020 at 15:53, Tom Parkin wrote:
> >
> > On Tue, Nov 17, 2020 at 15:22:07 +0530, Siddhant Gupta wrote:
> > > Fix Column span alignment problem warnings in the file
> > >
>
On Tue, Nov 17, 2020 at 4:26 PM Jakub Kicinski wrote:
>
> On Sun, 15 Nov 2020 20:31:40 -0600 Tom Seewald wrote:
> > After commit 9d2e5e9eeb59 ("cxgb4/ch_ktls: decrypted bit is not enough")
> > building the kernel with CHELSIO_T4=y and CHELSIO_TLS_DEVICE=n result
On Tue, Nov 17, 2020 at 15:22:07 +0530, Siddhant Gupta wrote:
> Fix Column span alignment problem warnings in the file
>
Thanks for the patch, Siddhant.
Could you provide some information on how these warnings were
triggered? Using Sphinx 2.4.4 I can't reproduce any warnings for
l2tp.rst using
On Tue, Nov 10, 2020 at 08:47:40 -0800, Jakub Kicinski wrote:
> On Tue, 10 Nov 2020 10:28:34 +0100 Guillaume Nault wrote:
> > On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> > > On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > > > This
On Sun, Nov 15, 2020 at 17:28:38 +0100, Guillaume Nault wrote:
> On Tue, Nov 10, 2020 at 12:04:29PM +0000, Tom Parkin wrote:
> > On Tue, Nov 10, 2020 at 00:24:01 +0100, Guillaume Nault wrote:
> > > On Fri, Nov 06, 2020 at 06:16:46PM +
On Sun, Nov 15, 2020 at 12:59:59 +0100, Guillaume Nault wrote:
> On Tue, Nov 10, 2020 at 11:54:07AM +0000, Tom Parkin wrote:
> > On Mon, Nov 09, 2020 at 23:51:53 +0100, Guillaume Nault wrote:
> > > BTW, shouldn't we have an "UNBRIDGE" command to remove the
it is not enough")
Signed-off-by: Tom Seewald
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 7fd264a6d085..8e8783a
; For instance: scripts/coccinelle/misc/semicolon.cocci
>
> Perhaps some tool coordination can be done here as
> coccinelle/checkpatch/clang/Lindent call all be used
> to do some facet or another of these cleanup issues.
Thanks for pointing this out.
I will take a look at it.
Tom
>
>
On Tue, Nov 10, 2020 at 10:28:34 +0100, Guillaume Nault wrote:
> On Mon, Nov 09, 2020 at 03:52:37PM -0800, Jakub Kicinski wrote:
> > On Fri, 6 Nov 2020 18:16:45 + Tom Parkin wrote:
> > > This small RFC series implements a suggestion from Guillaume Nault in
> > &
On Tue, Nov 10, 2020 at 00:24:01 +0100, Guillaume Nault wrote:
> On Fri, Nov 06, 2020 at 06:16:46PM +0000, Tom Parkin wrote:
> > + case PPPIOCBRIDGECHAN:
> > + if (get_user(unit, p))
> > + break;
> > +
On Mon, Nov 09, 2020 at 23:51:53 +0100, Guillaume Nault wrote:
> > * I believe that the fact we're not explicitly locking anything in the
> >ppp_input path for access to the channel bridge field is OK since:
> >
> > - ppp_input is called from the socket backlog recv
> >
> > - ppp
---
Documentation/networking/ppp_generic.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/networking/ppp_generic.rst
b/Documentation/networking/ppp_generic.rst
index e60504377900..aea950ce953f 100644
--- a/Documentation/networking/ppp_generic.rst
+++ b/Documentation/netw
This new ioctl allows two ppp channels to be bridged together: frames
arriving in one channel are transmitted in the other channel and vice
versa.
The practical use for this is primarily to support the L2TP Access
Concentrator use-case. The end-user session is presented as a ppp
channel (typicall
branch:
https://github.com/katalix/go-l2tp/tree/tp_002_pppoe_2
[3]. l2tp-ktest: a test suite for the Linux Kernel L2TP subsystem
https://github.com/katalix/l2tp-ktest
Tom Parkin (2):
ppp: add PPPIOCBRIDGECHAN ioctl
docs: update ppp_generic.rst to describe ioctl PPPIOCBRIDGECHAN
Documentation/netwo
ink_callback *cb)
> if (!dev)
> return skb->len;
>
> - parent = tcm->tcm_parent;
> - if (!parent) {
> + if (!tcm->tcm_parent)
> q = dev->qdisc;
> - p
quite similar with 25G.
Yes, it looks like functions only differ by a #defined register.
So 25 & 10 should be refactored to have a common base functions.
Tom
>
> Signed-off-by: Xu Yilun
> Signed-off-by: Russ Weight
> ---
> drivers/net/ethernet/intel/Makefile | 2
On 10/24/20 9:39 AM, Andrew Lunn wrote:
> On Sat, Oct 24, 2020 at 08:03:51AM -0700, Tom Rix wrote:
>> On 10/23/20 1:45 AM, Xu Yilun wrote:
>>> This driver supports the ethernet retimers (Parkvale) for the Intel PAC
>>> (Programmable Acceleration Card) N3000, whic
+ !egroup->ops->lineside_init || !egroup->ops->lineside_remove)
> + return -EINVAL;
> +
> + eth_group_devs_disable(egroup);
> +
> + phy_bus = eth_group_get_phy_bus(egroup);
> + if (IS_ERR(phy_bus))
> + return PTR_ERR(phy_bus);
p that could be used on other cards,
I think the generic parts should be split out of intel-m10-bmc-retimer.c
into a separate file, maybe retimer-c827.c
Tom
>
> Parkvale is an Intel(R) Ethernet serdes transceiver chip that supports up
> to 100G transfer. On Intel PAC N3000 there are 2
lit out of the patchset.
I believe the generic changes would have an easier time being accepted and
could be done in parallel as the harder part of the private features is worked
out.
Tom
>
> /*
> * use a macro to avoid include chaining to get THIS_MODULE.
1 - 100 of 2446 matches
Mail list logo
