>>>
>>> Signed-off-by: R. Parameswaran
>> Just use the IPv4/IPv6 header size for now, just like the VXLAN
>> driver does.
>>
> Actually, that's how the original posting was - it was changed in
> response to a review comment from James Chapman requesting
owned_by_user);
> + if (optv6)
> + overhead += (optv6->opt_flen + optv6->opt_nflen);
> + return overhead;
> +#endif /* IS_ENABLED(CONFIG_IPV6) */
> + default: /* Returns 0 overhead if the socket is not ipv4 or ipv6 */
> + return overhead;
> + }
> +}
> +EXPORT_SYMBOL(kernel_sock_ip_overhead);
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
> dev_net_set(dev, net);
> - if (session->mtu == 0)
> - session->mtu = dev->mtu - session->hdr_len;
> - dev->mtu = session->mtu;
> - dev->needed_headroom += session->hdr_len;
> dev->min_mtu = 0;
> dev->max_mtu = ETH_MAX_MTU;
>
> + l2tp_eth_adjust_mtu(tunnel, session, dev);
> priv = netdev_priv(dev);
> priv->dev = dev;
> priv->session = session;
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
On 11/10/16 02:54, R Parameswaran wrote:
>
>
> Hi James,
>
> Please see inline:
>
> On Tue, Oct 4, 2016 at 12:53 AM, James Chapman <mailto:jchap...@katalix.com>> wrote:
>
> On 04/10/16 04:12, R. Parameswaran wrote:
> >
> > Hi James,
&
On 04/10/16 04:12, R. Parameswaran wrote:
>
> Hi James,
>
> Please see inline, thanks for the reply:
>
> On Sat, 1 Oct 2016, James Chapman wrote:
>
>> On 30/09/16 03:39, R. Parameswaran wrote:
>>>>> + /* Adjust MTU, factor overhead - underlay L3 hdr,
On 30/09/16 03:39, R. Parameswaran wrote:
>
>>> + /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/
>>> + if (tunnel->sock->sk_family == AF_INET)
>>> + overhead += (ETH_HLEN + sizeof(struct iphdr));
>>> + else if (tunnel->sock->sk_family == AF_INET6)
>>> +
On 29/09/16 03:36, R. Parameswaran wrote:
> I agree that something like 2. below would be needed in the long run (it
> will need some effort and redesign -e.g. how do I lookup the parent tunnel
> from the socket when receiving a PMTU update, existing pointer chain runs
> from tunnel to socket).
On 22/09/16 21:52, R. Parameswaran wrote:
> From ed585bdd6d3d2b3dec58d414f514cd764d89159d Mon Sep 17 00:00:00 2001
> From: "R. Parameswaran"
> Date: Thu, 22 Sep 2016 13:19:25 -0700
> Subject: [PATCH] L2TP:Adjust intf MTU,factor underlay L3,overlay L2
>
> Take into account all of the tunnel encapsu
Please send the complete oops message.
Is this a regression? If so, do you know what the last kernel version
was that worked?
Thanks
James
On 14/04/14 14:33, Zhan Jianyu wrote:
> When I tried to connect my VPN, I got a panic, saying
> a NULL poiter dereference at 0x02c0
>
> I came a
Acked-by: James Chapman <[EMAIL PROTECTED]>
Rami Rosen wrote:
Hi,
When CONFIG_PROC_FS is not set and CONFIG_PPPOL2TP is set,
we have the following warning in build:
drivers/net/pppol2tp.c: In function 'pppol2tp_init':
drivers/net/pppol2tp.c:2472: warning: label
'out_u
2 root RT 0 000 S 0.0 0.0 0:00.01 migration/0
> 3 root 15 0 000 S 0.0 0.0 0:00.55 ksoftirqd/0
> 4 root RT 0 000 S 0.0 0.0 0:00.01 migration/1
> 5 root 15 0 000 S 0.0 0.0 0:00.43 kso
eally be done in userspace. And ripped from the kernel.
The output is useful when debugging boot problems on systems whose
rootfs is on the network. So I think the patch is ok.
However, it would be useful to make the parameters available to
userspace for use by boot scripts etc. A proc f
or review / feedback from the NAPI experts here. What do you think?
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Jan-Bernd Themann wrote:
On Tuesday 28 August 2007 11:22, James Chapman wrote:
So in this scheme what runs ->poll() to process incoming packets?
The hrtimer?
No, the regular NAPI networking core calls ->poll() as usual; no timers
are involved. This scheme simply delays the napi_complete(
David Miller wrote:
From: James Chapman <[EMAIL PROTECTED]>
Date: Mon, 27 Aug 2007 22:41:43 +0100
I don't recall saying anything in previous posts about this. Are you
confusing my posts with Jan-Bernd's?
Yes, my bad.
Jan-Bernd has been talking about using hrtimers to _resc
David Miller wrote:
From: James Chapman <[EMAIL PROTECTED]>
Date: Mon, 27 Aug 2007 16:51:29 +0100
To implement this, there's no need for timers, hrtimers or generic NAPI
support that others have suggested. A driver's poll() would set an
internal flag and record the current ji
Jan-Bernd Themann wrote:
On Monday 27 August 2007 17:51, James Chapman wrote:
In the second half of my previous reply (which seems to have been
deleted), I suggest a way to avoid this problem without using hardware
interrupt mitigation / coalescing. Original text is quoted below.
>>
David Miller wrote:
From: James Chapman <[EMAIL PROTECTED]>
Date: Sun, 26 Aug 2007 20:36:20 +0100
David Miller wrote:
From: James Chapman <[EMAIL PROTECTED]>
Date: Fri, 24 Aug 2007 18:16:45 +0100
Does hardware interrupt mitigation really interact well with NAPI?
It int
David Miller wrote:
From: James Chapman <[EMAIL PROTECTED]>
Date: Fri, 24 Aug 2007 18:16:45 +0100
Does hardware interrupt mitigation really interact well with NAPI?
It interacts quite excellently.
If NAPI disables interrupts and keeps them disabled while there are more
packets arriv
her particular system. Perhaps a
tool using pktgen and network device phy internal loopback could be
developed?
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
-
To unsubscribe from this list: send the line "unsubscribe
Al Viro wrote:
Address of auto variable is not a userland pointer. A good thing, too,
since if pppol2tp_tunnel_getsockopt() would _really_ get a userland pointer
as argument, it would be an instant roothole...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: James Chapman &
You're asking the wrong list. Try the uClibc list at uclibc.org.
glibc and uClibc provide C APIs to kernel system calls. uClibc doesn't
implement all features that glibc supports - there are several kernel
APIs that uClibc doesn't expose. Ask the uClibc folk for advice.
-
I don't have access to my ds1337 hardware right now (working away from
my office). Is someone else able to test this?
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
David Brownell wrote:
On Saturday 02 December 2006 5:
Ladislav Michl wrote:
On Tue, Apr 12, 2005 at 07:10:55PM +0100, James Chapman wrote:
[snip]
It is used by the Radstone ppc7d platform, arch/ppc/radstone_ppc7d.c
but wasn't added until very recently (2.6.12-rc2 I think).
To be honest, I meant to remove the 'id' thing before submit
Jean Delvare wrote:
Based on your and Jean's input, following so far sounds reasonable:
Create "charge" sysfs entry for ds1339 when it is detected. Do not
write any value to Trickle Charge register, until its value is written
to this entry.
While I admit I had this in mind in the first place, the m
Ladislav Michl wrote:
On Fri, Apr 08, 2005 at 01:08:46PM +0200, Jean Delvare wrote:
Add support for DS1339. The only difference against DS1337 is Trickle
Charge register at address 10h, which is used to enable battery or gold
cap charging. Please note that value may vary for different batteries,
so
Sorry for joining this thread late.
Patches 1-3 are fine with me.
/james
Ladislav Michl wrote:
On Thu, Apr 07, 2005 at 04:36:29PM -0700, Greg KH wrote:
Oops, you forgot to add a Signed-off-by: line for every patch, as per
Documentation/SubmittingPatches. Care to redo them?
Here it is (I'm sorry a
))
I don't this it is correct. You are using master_xfer, not
i2c_smbus_{read,write}_i2c_block_data. Adapter which declare themselves
I2C_FUNC_SMBUS_I2C_BLOCK-capable may not implement master_xfer. You
really need to check for I2C_FUNC_I2C.
i2c: add ds1337 RTC chip support
Signed-off-by: Jam
A revised adt7461 patch addressing all of Jean's comments is
attached.
This driver will detect the adt7461 chip only if boot firmware
has left the chip in its default lm90-compatible mode.
i2c: add adt7461 chip support
Signed-off-by: James Chapman <[EMAIL PROTECTED]>
The Analog Devi
A revised ds1337 patch addressing all of Jean's comments is attached.
i2c: add ds1337 RTC chip support
Signed-off-by: James Chapman <[EMAIL PROTECTED]>
Index: linux-2.6.i2c/drivers/i2c/chips/ds1337.c
===
--- /dev/null
Revised ds1337 chip driver patch.
Signed-off-by: James Chapman <[EMAIL PROTECTED]>
- change all driver log messages to use dev_dbg() or dev_err()
- remove debug module parameter
Greg KH wrote:
On Mon, Feb 28, 2005 at 05:14:25PM +, James Chapman wrote:
+/* Define to compile in pr_debug()
Add DS1337 RTC chip driver.
Signed-off-by: James Chapman <[EMAIL PROTECTED]>
diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-02-27 20:42:22 +00:00
+++ b/drivers/i2c/chips/Kconfig 2005-02-27 20:42:22 +00:00
@@ -62,6 +62,17 @@
Add ADT7461 (temperature sensor) support to LM90 driver.
Signed-off-by: James Chapman <[EMAIL PROTECTED]>
diff -Nru a/drivers/i2c/chips/lm90.c b/drivers/i2c/chips/lm90.c
--- a/drivers/i2c/chips/lm90.c 2005-02-27 13:24:11 +00:00
+++ b/drivers/i2c/chips/lm90.c 2005-02-27 13:24:11 +00:00
@@
33 matches
Mail list logo
