[PATCH 00/02] pull request for 'upstream-jeff' branch

[PATCH 00/02] pull request for 'upstream-jeff' branch

[Francois Romieu]

Please pull from branch 'upstream-jeff' in repository

git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git upstream-jeff

to get the changes below.

Distance from 'master' (f2511f13daaf00fdd206bee7b108f75923a613c6)
-----------------------------------------------------------------

69b4d070ea49bd7f589776ea471a6988345eeee5
db1470271c581050dcacc6ed681b9166d30bdba0

Diffstat
--------

 drivers/net/r8169.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Shortlog
--------

Ciaran McCreesh (1):
      r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

Francois Romieu (1):
      r8169: do not enable the TBI for the 8168 and the 81x0

Patch
-----

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..9dbab3f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
 	{ PCI_DEVICE(0x16ec,			0x0116), 0, 0, RTL_CFG_0 },
 	{ PCI_VENDOR_ID_LINKSYS,		0x1032,
 		PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+	{ 0x0001,				0x8168,
+		PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
 	{0,},
 };
 
@@ -1739,7 +1741,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	tp->features |= rtl_try_msi(pdev, ioaddr, cfg);
 	RTL_W8(Cfg9346, Cfg9346_Lock);
 
-	if (RTL_R8(PHYstatus) & TBI_Enable) {
+	if ((tp->mac_version <= RTL_GIGA_MAC_VER_06) &&
+	    (RTL_R8(PHYstatus) & TBI_Enable)) {
 		tp->set_speed = rtl8169_set_speed_tbi;
 		tp->get_settings = rtl8169_gset_tbi;
 		tp->phy_reset_enable = rtl8169_tbi_reset_enable;
-- 
Ueimor

[PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

[Francois Romieu]

Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
 drivers/net/r8169.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..702334e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
 	{ PCI_DEVICE(0x16ec,			0x0116), 0, 0, RTL_CFG_0 },
 	{ PCI_VENDOR_ID_LINKSYS,		0x1032,
 		PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+	{ 0x0001,				0x8168,
+		PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
 	{0,},
 };
 
-- 
1.5.3.3

Re: [PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

[Stephen Hemminger]

On Tue, 6 Nov 2007 23:23:54 +0100
Francois Romieu <romieu@fr.zoreil.com> wrote:

> Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Edward Hsu <edward_hsu@realtek.com.tw>
> ---
>  drivers/net/r8169.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index b94fa7e..702334e 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -171,6 +171,8 @@ static struct pci_device_id rtl8169_pci_tbl[] = {
>  	{ PCI_DEVICE(0x16ec,			0x0116), 0, 0, RTL_CFG_0 },
>  	{ PCI_VENDOR_ID_LINKSYS,		0x1032,
>  		PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
> +	{ 0x0001,				0x8168,
> +		PCI_ANY_ID, 0x2410, 0, 0, RTL_CFG_2 },
>  	{0,},
>  };
>  

Really, vendor_id is 1?  How about a comment about which board this is.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

[Francois Romieu]

Stephen Hemminger <shemminger@linux-foundation.org> :
[...]
> Really, vendor_id is 1 ?

Yes, the bug seems to be commonly set in hardware.

> How about a comment about which board this is.

B3w4r3 0f Th3 3v1l Fatal1ty M0b0 ?

Imho 'git log/blame' will provide enough information for this hack.

-- 
Ueimor

Re: [PATCH 01/02] r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

[Stephen Hemminger]

On Wed, 7 Nov 2007 00:19:08 +0100
Francois Romieu <romieu@fr.zoreil.com> wrote:

> Stephen Hemminger <shemminger@linux-foundation.org> :
> [...]
> > Really, vendor_id is 1 ?
> 
> Yes, the bug seems to be commonly set in hardware.
> 
> > How about a comment about which board this is.
> 
> B3w4r3 0f Th3 3v1l Fatal1ty M0b0 ?
> 
> Imho 'git log/blame' will provide enough information for this hack.
> 

0k F1ne

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

[PATCH 02/02] r8169: do not enable the TBI for the 8168 and the 81x0

[Francois Romieu]

The 8168c and the 8100e choke on it. I have not seen an indication
nor received a report that the TBI is being actively used on the
remaining 8168b and 8110. Let's disable it for now until someone
complains.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Matthias Winkler <m.winkler@unicon-ka.de>
Cc: Maarten Vanraes <maarten.vanraes@gmail.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
---
 drivers/net/r8169.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 702334e..9dbab3f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1741,7 +1741,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	tp->features |= rtl_try_msi(pdev, ioaddr, cfg);
 	RTL_W8(Cfg9346, Cfg9346_Lock);
 
-	if (RTL_R8(PHYstatus) & TBI_Enable) {
+	if ((tp->mac_version <= RTL_GIGA_MAC_VER_06) &&
+	    (RTL_R8(PHYstatus) & TBI_Enable)) {
 		tp->set_speed = rtl8169_set_speed_tbi;
 		tp->get_settings = rtl8169_gset_tbi;
 		tp->phy_reset_enable = rtl8169_tbi_reset_enable;
-- 
1.5.3.3

[PATCH 00/05] ipv6: RFC4214 Support

[Templin, Fred L]

From: Fred L. Templin <fred.l.templin@boeing.com>

The following diffs are specific to the Linux 2.6.23
kernel distribution and implement RFC4214 (Intra-Site
Automatic Tunnel Addressing Protocol - ISATAP). The
affected modules are:

  linux2.6.23/include/linux/if.h
  linux2.6.23/include/net/addrconf.h
  linux2.6.23/net/ipv6/addrconf.c
  linux2.6.23/net/ipv6/sit.c
  linux2.6.23/net/ipv6/Kconfig

and the diffs for each file are included in the following
messages as [PATCH 01/05] through [PATCH 05/05].

The code has been tested under Fedora Core 6 running the
modified 2.6.23 and has been verified in both ISATAP
client and ISATAP router configurations. (The ISATAP
router configuration uses the 'radvd' package.)
Interoperability testing with Windows Vista has also
been performed.

Please advise as to next steps.

Signed-off-by: Fred L. Templin <fred.l.templin@boeing.com>

Re: [PATCH 00/05] ipv6: RFC4214 Support

[David Miller]

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Date: Tue, 6 Nov 2007 17:15:54 -0800

> Please advise as to next steps.

Your email client has mangles the patches, adding line breaks.  This
makes the patches not apply at all.

Please correct this and resubmit, thank you.

Re: [PATCH 00/05] ipv6: RFC4214 Support

[David Stevens]

Last I heard, there are Intellectual Property claims with ISATAP,
which is why the RFC is not standards track and which makes it
effectively a proprietary protocol.

Unless that's been resolved, I think the claim by the IP owner is
that it can't be distributed without a license from them. So, maybe
not worth the effort for an experimental RFC.

                                        +-DLS

Re: [PATCH 00/05] ipv6: RFC4214 Support

[David Miller]

From: David Stevens <dlstevens@us.ibm.com>
Date: Tue, 6 Nov 2007 21:26:15 -0800

> Last I heard, there are Intellectual Property claims with ISATAP,
> which is why the RFC is not standards track and which makes it
> effectively a proprietary protocol.
> 
> Unless that's been resolved, I think the claim by the IP owner is
> that it can't be distributed without a license from them. So, maybe
> not worth the effort for an experimental RFC.

If this is the case, I agree, we cannot include ISATAP
support in the kernel.

Re: [PATCH 00/05] ipv6: RFC4214 Support

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20071106.213750.91637349.davem@davemloft.net> (at Tue, 06 Nov 2007 21:37:50 -0800 (PST)), David Miller <davem@davemloft.net> says:

> From: David Stevens <dlstevens@us.ibm.com>
> Date: Tue, 6 Nov 2007 21:26:15 -0800
> 
> > Last I heard, there are Intellectual Property claims with ISATAP,
> > which is why the RFC is not standards track and which makes it
> > effectively a proprietary protocol.
> > 
> > Unless that's been resolved, I think the claim by the IP owner is
> > that it can't be distributed without a license from them. So, maybe
> > not worth the effort for an experimental RFC.
> 
> If this is the case, I agree, we cannot include ISATAP
> support in the kernel.

I guess license is no longer required for implementers of ISATAP.
Is it right, Fred?

https://datatracker.ietf.org/ipr/550/

--yoshfuji

Re: [PATCH 00/05] ipv6: RFC4214 Support

[David Stevens]

> I guess license is no longer required for implementers of ISATAP.
> Is it right, Fred?
> 
> https://datatracker.ietf.org/ipr/550/

Does this also allow license-free redistribution?

I'm certainly no lawyer, but I don't see the point of
having a patent that doesn't restrict *something*. :-)

                                                +-DLS

Re: [PATCH 00/05] ipv6: RFC4214 Support

[David Miller]

From: David Stevens <dlstevens@us.ibm.com>
Date: Tue, 6 Nov 2007 22:07:44 -0800

> > I guess license is no longer required for implementers of ISATAP.
> > Is it right, Fred?
> > 
> > https://datatracker.ietf.org/ipr/550/
> 
> Does this also allow license-free redistribution?
> 
> I'm certainly no lawyer, but I don't see the point of
> having a patent that doesn't restrict *something*. :-)

That is my interpretation as well.  It allows
license free implementation, but not distribution
of said implementation.

Re: [PATCH 00/05] ipv6: RFC4214 Support

[Pekka Savola]

On Tue, 6 Nov 2007, David Miller wrote:
> From: David Stevens <dlstevens@us.ibm.com>
> Date: Tue, 6 Nov 2007 22:07:44 -0800
>
>>> I guess license is no longer required for implementers of ISATAP.
>>> Is it right, Fred?
>>>
>>> https://datatracker.ietf.org/ipr/550/
>>
>> Does this also allow license-free redistribution?
>>
>> I'm certainly no lawyer, but I don't see the point of
>> having a patent that doesn't restrict *something*. :-)

DavidS, the history here is that first the IPR holder did not grant 
license-free implementation.  After considerable time (and I suspect 
energy spent by Fred), the company was convinced that license-free 
implementation did not hurt their interests and they were willing to 
give it away on this specific instance.  I'm not sure if you should 
attribute to hidden agendas what you can explain by "doing the right 
thing" (granted, very few companies do this which may make it suspect, 
but still..).

> That is my interpretation as well.  It allows license free 
> implementation, but not distribution of said implementation.

This may be a fine point.  When submitting the IPR notice, the IPR 
holder is asked whether it can be implemented without a license.  No 
questions about redistribution are asked -- maybe nobody thought that 
asking that would be necessary if a positive answer is received on the 
first one.  I'd guess that the owner that grants license-free 
implementation would also be fine with license-free (re-)distribution.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH 00/05] ipv6: RFC4214 Support

[David Stevens]

> give it away on this specific instance.  I'm not sure if you should 
> attribute to hidden agendas what you can explain by "doing the right 
> thing" (granted, very few companies do this which may make it suspect, 
> but still..).

Pekka,
        I'm not assuming hidden agendas here; I simply don't know what
they mean by "no license for implementers."  It doesn't say they
relinquish *all* licensing, which would be clearer if that's what they
mean. If implementers, distributors, and users are included, then
who's left that does need licensing? If that answer really is nobody,
then why bother with "for implementers."?
        So, I don't think it's a hidden agenda, I think they said what
they mean. I just don't know what they mean. :-)

                                                                +-DLS

RE: [PATCH 00/05] ipv6: RFC4214 Support

[Templin, Fred L]

I think I can clear this up. The patent office rejected
SRI's patent application, therefore there are no valid
claims that could prevent ISATAP from being included
in public domain software releases. Indeed, Microsoft,
cisco, and FreeBSD/KAME are shipping ISATAP and have
been doing so for a long time, and I believe there are
also several others.

Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: David Stevens [mailto:dlstevens@us.ibm.com] 
> Sent: Tuesday, November 06, 2007 11:54 PM
> To: Pekka Savola
> Cc: David Miller; Templin, Fred L; netdev@vger.kernel.org; 
> netdev-owner@vger.kernel.org; yoshfuji@linux-ipv6.org
> Subject: Re: [PATCH 00/05] ipv6: RFC4214 Support
> 
> > give it away on this specific instance.  I'm not sure if you should 
> > attribute to hidden agendas what you can explain by "doing 
> the right 
> > thing" (granted, very few companies do this which may make 
> it suspect, 
> > but still..).
> 
> Pekka,
>         I'm not assuming hidden agendas here; I simply don't know what
> they mean by "no license for implementers."  It doesn't say they
> relinquish *all* licensing, which would be clearer if that's what they
> mean. If implementers, distributors, and users are included, then
> who's left that does need licensing? If that answer really is nobody,
> then why bother with "for implementers."?
>         So, I don't think it's a hidden agenda, I think they said what
> they mean. I just don't know what they mean. :-)
> 
>                                                                 +-DLS
> 
> 

RE: [PATCH 00/05] ipv6: RFC4214 Support

[Templin, Fred L]

As further clarification, here is the US patent office
transaction history for the SRI application, which shows
that the application was rejected on 8/02/04:

http://portal.uspto.gov/external/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnM
z0vM0Y_QjzKLN4gPMATJgFieAfqRqCLGpugijnABX4_83FT9IKBEpDlQxNDCRz8qJzU9MblS
P1jfWz9AvyA3NDSi3NsRAHxEBJg!/delta/base64xml/L0lJSk03dWlDU1lKSi9vQXd3QUF
NWWdBQ0VJUWhDRUVJaEZLQSEvNEZHZ2RZbktKMEZSb1hmckNIZGgvN18wXzE4TC81L3NhLmd
ldEJpYg!!?selectedTab=fileHistorytab&isSubmitted=isSubmitted&dosnum=0972
8253&public_selectedSearchOption=

and here is the 12/01/04 "IPR Status" summary from KAME
stating the basis for including ISATAP in their product: 

http://www.kame.net/newsletter/20041201/

Fred
fred.l.templin@boeing.com 

> -----Original Message-----
> From: Templin, Fred L 
> Sent: Wednesday, November 07, 2007 6:42 AM
> To: David Stevens; Pekka Savola
> Cc: David Miller; netdev@vger.kernel.org; 
> netdev-owner@vger.kernel.org; yoshfuji@linux-ipv6.org
> Subject: RE: [PATCH 00/05] ipv6: RFC4214 Support
> 
> I think I can clear this up. The patent office rejected
> SRI's patent application, therefore there are no valid
> claims that could prevent ISATAP from being included
> in public domain software releases. Indeed, Microsoft,
> cisco, and FreeBSD/KAME are shipping ISATAP and have
> been doing so for a long time, and I believe there are
> also several others.
> 
> Fred
> fred.l.templin@boeing.com
> 
> > -----Original Message-----
> > From: David Stevens [mailto:dlstevens@us.ibm.com] 
> > Sent: Tuesday, November 06, 2007 11:54 PM
> > To: Pekka Savola
> > Cc: David Miller; Templin, Fred L; netdev@vger.kernel.org; 
> > netdev-owner@vger.kernel.org; yoshfuji@linux-ipv6.org
> > Subject: Re: [PATCH 00/05] ipv6: RFC4214 Support
> > 
> > > give it away on this specific instance.  I'm not sure if 
> you should 
> > > attribute to hidden agendas what you can explain by "doing 
> > the right 
> > > thing" (granted, very few companies do this which may make 
> > it suspect, 
> > > but still..).
> > 
> > Pekka,
> >         I'm not assuming hidden agendas here; I simply 
> don't know what
> > they mean by "no license for implementers."  It doesn't say they
> > relinquish *all* licensing, which would be clearer if 
> that's what they
> > mean. If implementers, distributors, and users are included, then
> > who's left that does need licensing? If that answer really 
> is nobody,
> > then why bother with "for implementers."?
> >         So, I don't think it's a hidden agenda, I think 
> they said what
> > they mean. I just don't know what they mean. :-)
> > 
> >                                                             
>     +-DLS
> > 
> > 
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 00/05] ipv6: RFC4214 Support

[Pekka Savola]

On Tue, 6 Nov 2007, David Stevens wrote:
>> give it away on this specific instance.  I'm not sure if you should
>> attribute to hidden agendas what you can explain by "doing the right
>> thing" (granted, very few companies do this which may make it suspect,
>> but still..).
>
> Pekka,
>        I'm not assuming hidden agendas here; I simply don't know what
> they mean by "no license for implementers."  It doesn't say they
> relinquish *all* licensing, which would be clearer if that's what they
> mean. If implementers, distributors, and users are included, then
> who's left that does need licensing? If that answer really is nobody,
> then why bother with "for implementers."?
>        So, I don't think it's a hidden agenda, I think they said what
> they mean. I just don't know what they mean. :-)

If you look at the page they used to file the disclosure:

https://datatracker.ietf.org/ipr/new-specific/

You'll notice that they chose the most relaxed option available, and 
all the options only discuss implementers not distributors.

Now, if you look at the background commentary of the subject:

http://tools.ietf.org/html/rfc3905

.. the comment about that particular option is:

    a) No License Required for Implementers: The Patent Holder does not
       require parties to acquire any license to its Necessary Patent
       Claims in order to make, have made, use, import, offer to sell,
       sell, or distribute technology that implements such an IETF
       specification.

Seems clear to me, though someone could argue whether RFC 3905 is 
normative in this context, i.e., whether the person who submitted the 
disclosure understood the comment quoted above and that that's the way 
"no license required for implementers" must be interpreted.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [PATCH 00/05] ipv6: RFC4214 Support

[David Stevens]

Pekka,
        Thanks! That answers the question I had (i.e., you believe the 
legal
issues are resolved).

                                                +-DLS