Re: [PATCH net-next v4 1/2] New kernel function to get IP overhead on a socket.

4 or IPv6 address families. >>> >>> Signed-off-by: R. Parameswaran <rpara...@brocade.com> >> 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 >

Re: [PATCH net-next v4 1/2] New kernel function to get IP overhead on a socket.

gt;> >>> 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 the IP >

Re: [PATCH net-next v4 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

np->opt, > + 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

Re: [PATCH net-next v4 1/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

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

Re: [PATCH net-next v4 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

_id, u32 p > } > > 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

Re: [PATCH net-next v4 2/2]L2TP:Adjust intf MTU, add underlay L3, L2 hdrs

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

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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 <jchap...@katalix.com > <mailto:jchap...@katalix.com>> wrote: > > On 04/10/16 04:12, R. Parameswaran wrote: > &

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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,

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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,

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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) >>> +

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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) >>> +

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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).

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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).

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

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

Re: [BUG] A panic caused by null pointer dereference aftering updating to

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

Re: [BUG] A panic caused by null pointer dereference aftering updating to

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

Re: [PATCH] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.

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_unregister_pppox

Re: [PATCH] [PPPOL2TP] Label unused warning when CONFIG_PROC_FS is not set.

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_unregister_pppox_proto

Re: questions on NAPI processing latency and dropped network packets

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 ksoftirqd/1 > > > 3) /proc/sys/n

Re: questions on NAPI processing latency and dropped network packets

/net/core/netdev_max_backlog is set to the default of 300 So...anyone have any ideas/suggestions? Thanks, Chris -- 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

Re: [PATCH] ipconfig.c: De-clutter IP configuration report

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

Re: [PATCH] ipconfig.c: De-clutter IP configuration report

the parameters available to userspace for use by boot scripts etc. A proc file listing variables and values in /bin/sh syntax would be easy to use. I've been meaning to do this for ages so I'll roll a patch. -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded

Re: RFC: issues concerning the next NAPI interface

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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org

Re: RFC: issues concerning the next NAPI interface

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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo

Re: RFC: issues concerning the next NAPI interface

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(

Re: RFC: issues concerning the next NAPI interface

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 _reschedule_ NA

Re: RFC: issues concerning the next NAPI interface

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 _reschedule_ NAPI. My

Re: RFC: issues concerning the next NAPI interface

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() from

Re: RFC: issues concerning the next NAPI interface

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 jiffies valu

Re: RFC: issues concerning the next NAPI interface

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. >>

Re: RFC: issues concerning the next NAPI interface

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

Re: RFC: issues concerning the next NAPI interface

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 interacts quite excellently

Re: RFC: issues concerning the next NAPI interface

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. I've

Re: RFC: issues concerning the next NAPI interface

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 jiffies value when

Re: RFC: issues concerning the next NAPI interface

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 ar

Re: RFC: issues concerning the next NAPI interface

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 arriving

Re: RFC: issues concerning the next NAPI interface

rhaps 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 linux-kernel" in th

Re: RFC: issues concerning the next NAPI interface

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 linux-kernel in the body of a message to [EMAIL PROTECTED

Re: [PATCH] misannotation in pppol2tp

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 &

Re: [PATCH] misannotation in pppol2tp

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 [EMAIL PROTECTED

Re: uClibc - waitid()

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. -- James Chapman

Re: uClibc - waitid()

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. -- James Chapman

Re: rtc-ds1307 driver (especially for DS1337, DS1339)

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:55 am

Re: rtc-ds1307 driver (especially for DS1337, DS1339)

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:55 am

Re: [PATCH] ds1337 4/4

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 submitting the driver

Re: [PATCH] ds1337 4/4

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 submitting the driver

Re: [PATCH] ds1337 4/4

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

Re: [PATCH] ds1337 4/4

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

Re: [PATCH] ds1337 4/4

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,

Re: [PATCH] ds1337 1/4

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

Re: [PATCH] ds1337 1/4

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

Re: [PATCH] ds1337 4/4

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,

Re: [PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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: James Chapman

Re: [PATCH: 2.6.11-rc5] i2c chips: add adt7461 support to lm90 driver

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 Devices A

Re: [PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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 1970

Re: [PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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 1970-01-01 00

Re: [PATCH: 2.6.11-rc5] i2c chips: add adt7461 support to lm90 driver

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 Devices ADT7461

Re: [PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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: James Chapman

Re: [PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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()

Re: [PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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() trace

[PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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

[PATCH: 2.6.11-rc5] i2c chips: add adt7461 support to lm90 driver

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 @@

[PATCH: 2.6.11-rc5] i2c chips: add adt7461 support to lm90 driver

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 @@ -85,7

[PATCH: 2.6.11-rc5] i2c chips: ds1337 RTC driver

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