* Re: [PATCH] net: ipv4: tcp_probe: cleanup snprintf() use
From: David Miller @ 2010-11-17 20:30 UTC (permalink / raw)
To: segoon
Cc: kernel-janitors, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <1289754368-31660-1-git-send-email-segoon@openwall.com>
From: Vasiliy Kulikov <segoon@openwall.com>
Date: Sun, 14 Nov 2010 20:06:08 +0300
> snprintf() returns number of bytes that were copied if there is no overflow.
> This code uses return value as number of copied bytes. Theoretically format
> string '%lu.%09lu %pI4:%u %pI4:%u %d %#x %#x %u %u %u %u\n' may be expanded
> up to 163 bytes. In reality tv.tv_sec is just few bytes instead of 20, 2 ports
> are just 5 bytes each instead of 10, length is 5 bytes instead of 10. The rest
> is an unstrusted input. Theoretically if tv_sec is big then copy_to_user() would
> overflow tbuf.
>
> tbuf was increased to fit in 163 bytes. snprintf() is used to follow return
> value semantic.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] gianfar: fix signedness issue
From: David Miller @ 2010-11-17 20:40 UTC (permalink / raw)
To: nikai; +Cc: galak, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20101115215942.354b0394@absol.kitzblitz>
From: Nicolas Kaiser <nikai@nikai.net>
Date: Mon, 15 Nov 2010 21:59:42 +0100
> irq_of_parse_and_map() has an unsigned return type.
> Testing for a negative error value doesn't work here.
>
> Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
> ---
> I see that in numerous places the return value is tested
> for NO_IRQ. I hope it's the right thing to do here as well?
I think it is, applied, thank you.
^ permalink raw reply
* extended netdevice naming proposal
From: Matt Domsch @ 2010-11-17 22:06 UTC (permalink / raw)
To: linux-hotplug, netdev, narendra_k; +Cc: jcm, notting
While this _is_ the original bikeshedding problem, as long as I'm
going to use biosdevname to change names for embedded NICs, perhaps I
can be so bold as to change them for USB add-in cards too?
There are quite a few dimensions to the problem:
* device location (onboard, PCI, other bus)
* multiple ports on a single add-in card
* with Network Partitioning (NPAR) and SR-IOV, the OS sees multiple
network interfaces (physical or virtual interfaces) but a single external port
* the suffix .1234 currently used for vlans (ala vconfig)
* A single PCI device may drive multiple external ports
As such, here is a naming proposal, aimed to keep within 15
characters for most configurations.
(location)(slot)#(port)/(instance).(vlan)
location := NIC on Motherboard = net1, net2, net3, net4
(note: people hated the TLA collision with 'lom', so avoiding that here).
:= PCI slot = pci1, pci2, pci3, pci4
these correspond to chassis labels, information is available in
$PIRQ, SMBIOS or ACPI, which biosdevname retrieves and uses.
For single- or multi-port cards in PCI slots, append #(port):
pci1#1, pci1#2, pci1#3, pci1#4 for 4 ports on a card in PCI slot 1
There is currently no way to get this port info from BIOS. Several people
have suggested using adding a PCI capabilities field to expose this
info in a standard way, but that's a ways off. Until then, biosdevname
can guess (assume ascending MAC order on the single card).
For NPAR/SR-IOV where the physical port is shared by several
instances, append /(instance):
net1/1, net1/2 pci1#1/1, pci1#1/2,
pci1#1/2, pci1#1/3, ...
For each of the above where vconfig sets up a vlan:
pci1#/1.1000, pci1#1/2.1001, pci1#1/2.1003, pci1#1/3.1004, ...
vconfig simply appends .{vlan#} to the already named device when creating a new vlan netdevice.
BIOS definitely doesn't know about these, as they aren't exposed until
after the OS is running, so the mechanism that creates them (such as
following modprobe ixgbevf) would have to, and I think that can be
done with a udev rule, if we can somehow expose the port number of the
underlying PF when we throw the message to udev on creation of the VF.
And of course, BIOS knows nothing about vlans, so vconfig would add that.
If we have no more than 99 PCI slots, no more than 99 ports on a
single card, no more than 999 instances/virtual functions (we need at
least 128, perhaps more than 256 at some point, so hex vs decimal
doesn't buy us much here), no more than 4k VLANs, we get:
len("pci99#99/999.4095") = 17
If we really have that many, we're in trouble in other ways, so let's
hope that's good enough.
Thoughts? Overkill?
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH net-next 1/4] rtnetlink: Link address family API
From: Thomas Graf @ 2010-11-17 22:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101117.113035.229752488.davem@davemloft.net>
On Wed, Nov 17, 2010 at 11:30:35AM -0800, David Miller wrote:
> Applied, but note that as-implemented it has the "partial update"
> problem. When we can't get the af-specific ops for a "parse"
> operation, we just skip that AF yet we let the modifications of
> the other AF's succeed and make it appear to the user that
> everything got updated and all the attributes were consumed.
>
> I don't know what we can do about this with how things work
> right now.
I absolutely agree and this problem isn't limited to this specific
case at all. All netlink based implementations I am aware of will
silently skip over any unknown attribute type and thus only apply
updates partially.
What I can will do in this specific case is check if all af ops
can be looked up before starting to update things.
Some of the newer netlink interfaces are actually both atomic and
always leave a consistent state. For those which do not I strongly
believe that we should limit inconsistency to a minimum were
possible but leave any kind of fallback mechanism to userspace. I
am experimenting with this in userspace. By listening to
notifications and with the help of sequence numbers it is possible
to reliably switch back to a previous "version" of a link, address,
... even if there are multiple writers.
^ permalink raw reply
* [RFC PATCH] ethtool: allow setting MDI-X state
From: Jesse Brandeburg @ 2010-11-17 23:16 UTC (permalink / raw)
To: netdev, bhutchings
ethtool recently added support for reading MDI-X state, this
patch finishes the implementation, adding the complementary write
command.
Add support to ethtool for controlling the MDI-X (crossover)
state of a network port. Most adapters correctly negotiate
MDI-X, but some ill-behaved switches have trouble and end up
picking the wrong MDI setting, which results in complete loss of
link. Usually this error condition can be observed with multiple
ethtool -r ethX required before link is achieved.
usage is ethtool -s eth0 mdix [auto|on|off]
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
ethtool.8 | 8 ++++++++
ethtool.c | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/ethtool.8 b/ethtool.8
index 1760924..c96e35d 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -196,6 +196,7 @@ ethtool \- Display or change ethernet card settings
.BI speed \ N
.B2 duplex half full
.B4 port tp aui bnc mii fibre
+.B3 mdix auto on off
.B2 autoneg on off
.RB [ advertise
.IR N ]
@@ -452,6 +453,13 @@ Sets full or half duplex mode.
.A4 port tp aui bnc mii fibre
Selects device port.
.TP
+.A3 mdix auto on off
+Selects MDI-X mode for port. May be used to override the automatic detection
+feature of most adapters. Auto means automatic detection of MDI status, on
+forces MDI-X (crossover) mode, while off means MDI (straight through) mode.
+Depending on implementation an ethtool -r ethX command may be necessary to
+cause the change to take effect.
+.TP
.A2 autoneg on off
Specifies whether autonegotiation should be enabled. Autonegotiation
is enabled by deafult, but in some network devices may have trouble
diff --git a/ethtool.c b/ethtool.c
index 239912b..fcc7998 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -157,6 +157,7 @@ static struct option {
" [ speed %d ]\n"
" [ duplex half|full ]\n"
" [ port tp|aui|bnc|mii|fibre ]\n"
+ " [ mdix auto|on|off ]\n"
" [ autoneg on|off ]\n"
" [ advertise %x ]\n"
" [ phyad %d ]\n"
@@ -353,6 +354,7 @@ static s32 coal_tx_frames_high_wanted = -1;
static int speed_wanted = -1;
static int duplex_wanted = -1;
static int port_wanted = -1;
+static int mdix_wanted = -1;
static int autoneg_wanted = -1;
static int phyad_wanted = -1;
static int xcvr_wanted = -1;
@@ -1048,6 +1050,20 @@ static void parse_cmdline(int argc, char **argp)
else
show_usage(1);
break;
+ } else if (!strcmp(argp[i], "mdix")) {
+ gset_changed = 1;
+ i += 1;
+ if (i >= argc)
+ show_usage(1);
+ if (!strcmp(argp[i], "auto"))
+ mdix_wanted = ETH_TP_MDI_INVALID;
+ else if (!strcmp(argp[i], "on"))
+ mdix_wanted = ETH_TP_MDI_X;
+ else if (!strcmp(argp[i], "off"))
+ mdix_wanted = ETH_TP_MDI;
+ else
+ show_usage(1);
+ break;
} else if (!strcmp(argp[i], "autoneg")) {
i += 1;
if (i >= argc)
@@ -1124,6 +1140,20 @@ static void parse_cmdline(int argc, char **argp)
i = argc;
}
break;
+ } else if (!strcmp(argp[i], "mdix")) {
+ gset_changed = 1;
+ i += 1;
+ if (i >= argc)
+ show_usage(1);
+ if (!strcmp(argp[i], "auto"))
+ mdix_wanted = ETH_TP_MDI_INVALID;
+ else if (!strcmp(argp[i], "on"))
+ mdix_wanted = ETH_TP_MDI_X;
+ else if (!strcmp(argp[i], "off"))
+ mdix_wanted = ETH_TP_MDI;
+ else
+ show_usage(1);
+ break;
}
show_usage(1);
}
@@ -2525,6 +2555,8 @@ static int do_sset(int fd, struct ifreq *ifr)
ecmd.duplex = duplex_wanted;
if (port_wanted != -1)
ecmd.port = port_wanted;
+ if (mdix_wanted != -1)
+ ecmd.eth_tp_mdix = mdix_wanted;
if (autoneg_wanted != -1)
ecmd.autoneg = autoneg_wanted;
if (phyad_wanted != -1)
@@ -2566,6 +2598,8 @@ static int do_sset(int fd, struct ifreq *ifr)
fprintf(stderr, " not setting phy_address\n");
if (xcvr_wanted != -1)
fprintf(stderr, " not setting transceiver\n");
+ if (mdix_wanted != -1)
+ fprintf(stderr, " not setting mdix\n");
}
}
^ permalink raw reply related
* [RFC PATCH 0/3] e1000/e1000e/igb MDI-X control implementation
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
To: netdev
this patch series is RFC for implemenation, I've briefly tested
it to make sure I still get link after setting MDI-X and I see
the status change in ethtool.
The basic idea is to fill out the MDI-X read functionality with
some write functionality.
the e1000e patch is actually what drove this change as some users
have found wonky switches that must have MDI/MDI-X forced.
---
Jesse Brandeburg (3):
e1000: configure and read mdix settings
igb: update to allow reading/setting mdix
e1000e: implement MDI-X control
drivers/net/e1000/e1000.h | 1 -
drivers/net/e1000/e1000_ethtool.c | 13 +++++++++++++
drivers/net/e1000/e1000_main.c | 2 +-
drivers/net/e1000e/e1000.h | 1 -
drivers/net/e1000e/ethtool.c | 4 ++++
drivers/net/e1000e/netdev.c | 2 +-
drivers/net/igb/igb.h | 1 -
drivers/net/igb/igb_ethtool.c | 14 ++++++++++++++
drivers/net/igb/igb_main.c | 2 +-
9 files changed, 34 insertions(+), 6 deletions(-)
--
jesse.brandeburg@intel.com
^ permalink raw reply
* [RFC PATCH 1/3] e1000e: implement MDI-X control
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>
some users report issues with link failing when connected
to certain switches. This gives the user the ability to
control the MDI-X state from the driver.
This is in regards to the related ethtool patch and
bugzilla.kernel.org bug 11998
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: bruce.w.allan@intel.com
CC: n.poppelier@xs4all.nl
CC: bastien@durel.org
CC: jsveiga@it.eng.br
---
drivers/net/e1000e/e1000.h | 1 -
drivers/net/e1000e/ethtool.c | 4 ++++
drivers/net/e1000e/netdev.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index fdc67fe..10469b2 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -81,7 +81,6 @@ struct e1000_info;
/* How many Rx Buffers do we bundle into one write to the hardware ? */
#define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */
-#define AUTO_ALL_MODES 0
#define E1000_EEPROM_APME 0x0400
#define E1000_MNG_VLAN_NONE (-1)
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index 8984d16..f518c9b 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -285,6 +285,10 @@ static int e1000_set_settings(struct net_device *netdev,
}
}
+ /* MDI-X => 2; MDI =>1; Auto =>0 */
+ if (ecmd->eth_tp_mdix && (hw->phy.media_type == e1000_media_type_copper))
+ hw->phy.mdix = ecmd->eth_tp_mdix;
+
/* reset the link */
if (netif_running(adapter->netdev)) {
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 68e79c2..9e7d864 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -5842,7 +5842,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
/* Copper options */
if (adapter->hw.phy.media_type == e1000_media_type_copper) {
- adapter->hw.phy.mdix = AUTO_ALL_MODES;
+ adapter->hw.phy.mdix = ETH_TP_MDI_INVALID;
adapter->hw.phy.disable_polarity_correction = 0;
adapter->hw.phy.ms_type = e1000_ms_hw_default;
}
^ permalink raw reply related
* [RFC PATCH 3/3] e1000: configure and read mdix settings
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/e1000/e1000.h | 1 -
drivers/net/e1000/e1000_ethtool.c | 13 +++++++++++++
drivers/net/e1000/e1000_main.c | 2 +-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index a881dd0..e2767ab 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -130,7 +130,6 @@ struct e1000_adapter;
/* How many Rx Buffers do we bundle into one write to the hardware ? */
#define E1000_RX_BUFFER_WRITE 16 /* Must be power of 2 */
-#define AUTO_ALL_MODES 0
#define E1000_EEPROM_82544_APM 0x0004
#define E1000_EEPROM_APME 0x0400
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index f4d0922..5e2c83f 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -174,6 +174,14 @@ static int e1000_get_settings(struct net_device *netdev,
ecmd->autoneg = ((hw->media_type == e1000_media_type_fiber) ||
hw->autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE;
+
+ /* MDI-X => 2; MDI =>1; Invalid =>0 */
+ if ((hw->media_type == e1000_media_type_copper) &&
+ netif_carrier_ok(netdev))
+ ecmd->eth_tp_mdix = hw->mdix;
+ else
+ ecmd->eth_tp_mdix = ETH_TP_MDI_INVALID;
+
return 0;
}
@@ -203,6 +211,11 @@ static int e1000_set_settings(struct net_device *netdev,
return -EINVAL;
}
+ /* MDI-X => 2; MDI =>1; Auto =>0 */
+ if ((ecmd->eth_tp_mdix != -1) &&
+ (hw->media_type == e1000_media_type_copper))
+ hw->mdix = ecmd->eth_tp_mdix;
+
/* reset the link */
if (netif_running(adapter->netdev)) {
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4686c39..0252a01 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -860,7 +860,7 @@ static int e1000_init_hw_struct(struct e1000_adapter *adapter,
/* Copper options */
if (hw->media_type == e1000_media_type_copper) {
- hw->mdix = AUTO_ALL_MODES;
+ hw->mdix = ETH_TP_MDI_INVALID;
hw->disable_polarity_correction = false;
hw->master_slave = E1000_MASTER_SLAVE;
}
^ permalink raw reply related
* [RFC PATCH 2/3] igb: update to allow reading/setting mdix
From: Jesse Brandeburg @ 2010-11-17 23:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
---
drivers/net/igb/igb.h | 1 -
drivers/net/igb/igb_ethtool.c | 14 ++++++++++++++
drivers/net/igb/igb_main.c | 2 +-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/igb/igb.h b/drivers/net/igb/igb.h
index edab9c4..04f7a05 100644
--- a/drivers/net/igb/igb.h
+++ b/drivers/net/igb/igb.h
@@ -120,7 +120,6 @@ struct vf_data_storage {
/* How many Rx Buffers do we bundle into one write to the hardware ? */
#define IGB_RX_BUFFER_WRITE 16 /* Must be power of 2 */
-#define AUTO_ALL_MODES 0
#define IGB_EEPROM_APME 0x0400
#ifndef IGB_MASTER_SLAVE
diff --git a/drivers/net/igb/igb_ethtool.c b/drivers/net/igb/igb_ethtool.c
index a70e16b..bfeee01 100644
--- a/drivers/net/igb/igb_ethtool.c
+++ b/drivers/net/igb/igb_ethtool.c
@@ -191,6 +191,15 @@ static int igb_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
}
ecmd->autoneg = hw->mac.autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE;
+
+ /* MDI-X => 2; MDI =>1; Invalid =>0 */
+ if ((hw->phy.media_type == e1000_media_type_copper) &&
+ netif_carrier_ok(netdev))
+ ecmd->eth_tp_mdix = hw->phy.is_mdix ? ETH_TP_MDI_X :
+ ETH_TP_MDI;
+ else
+ ecmd->eth_tp_mdix = ETH_TP_MDI_INVALID;
+
return 0;
}
@@ -225,6 +234,11 @@ static int igb_set_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
}
}
+ /* MDI-X => 2; MDI =>1; Auto =>0 */
+ if ((ecmd->eth_tp_mdix != -1) &&
+ (hw->phy.media_type == e1000_media_type_copper))
+ hw->phy.mdix = ecmd->eth_tp_mdix;
+
/* reset the link */
if (netif_running(adapter->netdev)) {
igb_down(adapter);
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 892d196..338825f 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1838,7 +1838,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
/* Copper options */
if (hw->phy.media_type == e1000_media_type_copper) {
- hw->phy.mdix = AUTO_ALL_MODES;
+ hw->phy.mdix = ETH_TP_MDI_INVALID;
hw->phy.disable_polarity_correction = false;
hw->phy.ms_type = e1000_ms_hw_default;
}
^ permalink raw reply related
* Re: [RFC PATCH] ethtool: allow setting MDI-X state
From: Ben Hutchings @ 2010-11-17 23:53 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <20101117231655.30673.37157.stgit@jbrandeb-ich9b.jf.intel.com>
On Wed, 2010-11-17 at 15:16 -0800, Jesse Brandeburg wrote:
> ethtool recently added support for reading MDI-X state, this
> patch finishes the implementation, adding the complementary write
> command.
>
> Add support to ethtool for controlling the MDI-X (crossover)
> state of a network port. Most adapters correctly negotiate
> MDI-X, but some ill-behaved switches have trouble and end up
> picking the wrong MDI setting, which results in complete loss of
> link. Usually this error condition can be observed with multiple
> ethtool -r ethX required before link is achieved.
>
> usage is ethtool -s eth0 mdix [auto|on|off]
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> ---
>
> ethtool.8 | 8 ++++++++
> ethtool.c | 34 ++++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/ethtool.8 b/ethtool.8
> index 1760924..c96e35d 100644
> --- a/ethtool.8
> +++ b/ethtool.8
> @@ -196,6 +196,7 @@ ethtool \- Display or change ethernet card settings
> .BI speed \ N
> .B2 duplex half full
> .B4 port tp aui bnc mii fibre
> +.B3 mdix auto on off
> .B2 autoneg on off
> .RB [ advertise
> .IR N ]
> @@ -452,6 +453,13 @@ Sets full or half duplex mode.
> .A4 port tp aui bnc mii fibre
> Selects device port.
> .TP
> +.A3 mdix auto on off
> +Selects MDI-X mode for port. May be used to override the automatic detection
> +feature of most adapters. Auto means automatic detection of MDI status, on
> +forces MDI-X (crossover) mode, while off means MDI (straight through) mode.
> +Depending on implementation an ethtool -r ethX command may be necessary to
> +cause the change to take effect.
This is stupid, we should specify whether this should trigger
renegotiation or not. (And that should be done in ethtool.h as well,
since that's the specification that driver writers look at.)
> +.TP
> .A2 autoneg on off
> Specifies whether autonegotiation should be enabled. Autonegotiation
> is enabled by deafult, but in some network devices may have trouble
> diff --git a/ethtool.c b/ethtool.c
> index 239912b..fcc7998 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -157,6 +157,7 @@ static struct option {
> " [ speed %d ]\n"
> " [ duplex half|full ]\n"
> " [ port tp|aui|bnc|mii|fibre ]\n"
> + " [ mdix auto|on|off ]\n"
> " [ autoneg on|off ]\n"
> " [ advertise %x ]\n"
> " [ phyad %d ]\n"
> @@ -353,6 +354,7 @@ static s32 coal_tx_frames_high_wanted = -1;
> static int speed_wanted = -1;
> static int duplex_wanted = -1;
> static int port_wanted = -1;
> +static int mdix_wanted = -1;
> static int autoneg_wanted = -1;
> static int phyad_wanted = -1;
> static int xcvr_wanted = -1;
> @@ -1048,6 +1050,20 @@ static void parse_cmdline(int argc, char **argp)
> else
> show_usage(1);
> break;
> + } else if (!strcmp(argp[i], "mdix")) {
> + gset_changed = 1;
> + i += 1;
> + if (i >= argc)
> + show_usage(1);
> + if (!strcmp(argp[i], "auto"))
> + mdix_wanted = ETH_TP_MDI_INVALID;
> + else if (!strcmp(argp[i], "on"))
> + mdix_wanted = ETH_TP_MDI_X;
> + else if (!strcmp(argp[i], "off"))
> + mdix_wanted = ETH_TP_MDI;
> + else
> + show_usage(1);
> + break;
> } else if (!strcmp(argp[i], "autoneg")) {
> i += 1;
> if (i >= argc)
> @@ -1124,6 +1140,20 @@ static void parse_cmdline(int argc, char **argp)
> i = argc;
> }
> break;
> + } else if (!strcmp(argp[i], "mdix")) {
> + gset_changed = 1;
> + i += 1;
> + if (i >= argc)
> + show_usage(1);
> + if (!strcmp(argp[i], "auto"))
> + mdix_wanted = ETH_TP_MDI_INVALID;
> + else if (!strcmp(argp[i], "on"))
> + mdix_wanted = ETH_TP_MDI_X;
> + else if (!strcmp(argp[i], "off"))
> + mdix_wanted = ETH_TP_MDI;
> + else
> + show_usage(1);
> + break;
> }
> show_usage(1);
> }
I'm seeing double!
> @@ -2525,6 +2555,8 @@ static int do_sset(int fd, struct ifreq *ifr)
> ecmd.duplex = duplex_wanted;
> if (port_wanted != -1)
> ecmd.port = port_wanted;
> + if (mdix_wanted != -1)
> + ecmd.eth_tp_mdix = mdix_wanted;
There are two serious problems with this:
1. All existing drivers will silently ignore this.
2. If the user doesn't specify it, the MDI-X setting will be forced to
whatever was last automatically selected.
There needs to be some way for ethtool (or other client) to detect
whether the driver actually supports forcing MDI-X, and for the driver
to detect whether the client is trying to do it. And I would suggest
using a second field for this:
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -31,9 +31,9 @@ struct ethtool_cmd {
__u32 maxtxpkt; /* Tx pkts before generating tx int */
__u32 maxrxpkt; /* Rx pkts before generating rx int */
__u16 speed_hi;
- __u8 eth_tp_mdix;
- __u8 reserved2;
+ __u8 eth_tp_mdix; /* Twisted-pair MDI-X status */
+ __u8 eth_tp_mdix_ctrl; /* Twisted-pair MDI-X control */
__u32 lp_advertising; /* Features the link partner advertises */
__u32 reserved[2];
};
@@ -653,10 +653,11 @@ struct ethtool_ops {
#define AUTONEG_DISABLE 0x00
#define AUTONEG_ENABLE 0x01
-/* Mode MDI or MDI-X */
-#define ETH_TP_MDI_INVALID 0x00
-#define ETH_TP_MDI 0x01
-#define ETH_TP_MDI_X 0x02
+/* MDI or MDI-X status/control */
+#define ETH_TP_MDI_INVALID 0x00 /* status: unknown; control: unsupported */
+#define ETH_TP_MDI 0x01 /* status: MDI; control: force MDI */
+#define ETH_TP_MDI_X 0x02 /* status: MDI-X; control: force MDI-X */
+#define ETH_TP_MDI_AUTO 0x03 /* control: auto-select */
/* Wake-On-Lan options. */
#define WAKE_PHY (1 << 0)
--- END ---
ethtool should then fail if the user attempts to control MDI-X and
ETHTOOL_GSET yields eth_tp_mdix_ctrl == ETH_TP_MDI_INVALID.
Ben.
> if (autoneg_wanted != -1)
> ecmd.autoneg = autoneg_wanted;
> if (phyad_wanted != -1)
> @@ -2566,6 +2598,8 @@ static int do_sset(int fd, struct ifreq *ifr)
> fprintf(stderr, " not setting phy_address\n");
> if (xcvr_wanted != -1)
> fprintf(stderr, " not setting transceiver\n");
> + if (mdix_wanted != -1)
> + fprintf(stderr, " not setting mdix\n");
> }
> }
>
>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 0/2] of/phylib: Use device tree properties for PHY configuration.
From: David Daney @ 2010-11-17 23:54 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David Daney
Here is my first take at using the device tree to control PHY
configuration. This first set enables some Marvell PHYs. If the
scheme is deemed acceptable, I would probably do something similar for
Broadcom PHYs as well.
The first patch is the meat of the change. The second adds support
for the 88E1149R PHY that I have on one of my boards.
David Daney (2):
of/phylib: Use device tree properties to initialize Marvell PHYs.
phylib: Add support for Marvell 88E1149R devices.
drivers/net/phy/marvell.c | 135 +++++++++++++++++++++++++++++++++++++++++++
include/linux/marvell_phy.h | 1 +
2 files changed, 136 insertions(+), 0 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH 1/2] of/phylib: Use device tree properties to initialize Marvell PHYs.
From: David Daney @ 2010-11-17 23:54 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David Daney, Arnaud Patard, Cyril Chemparathy
In-Reply-To: <1290038071-13296-1-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Some aspects of PHY initialization are board dependent, things like
indicator LED connections and some clocking modes cannot be determined
by probing. The dev_flags element of struct phy_device can be used to
control these things if an appropriate value can be passed from the
Ethernet driver. We run into problems however if the PHY connections
are specified by the device tree. There is no way for the Ethernet
driver to know what flags it should pass.
If we are using the device tree, the struct phy_device will be
populated with the device tree node corresponding to the PHY, and we
can extract extra configuration information from there.
The next question is what should the format of that information be?
It is highly device specific, and the device tree representation
should not be tied to any arbitrary kernel defined constants. A
straight forward representation is just to specify the exact bits that
should be set using the "marvell,reg-init" property:
phy5: ethernet-phy@5 {
reg = <5>;
device_type = "ethernet-phy";
marvell,reg-init =
<0x00030010 0x5777>, /* Reg 3,16 <- 0x5777 */
<0x00030011 0x00aa>, /* Reg 3,17 <- 0x00aa */
<0x00030012 0x4105>, /* Reg 3,18 <- 0x4105 */
<0x00030013 0x0060>; /* Reg 3,19 <- 0x0060 */
<0x00020015 0x00300000>; /* clear bits 4..5 of Reg 2,21 */
};
The Marvell PHYs have a page select register at register 22 (0x16), we
can specify any register by its page and register number. These are
encoded in the high and low parts of the first word. The second word
contains a mask and value to be ORed in its high and low parts. The
new marvell_of_reg_init function leaves the page select register
unchanged, so a call to it can be dropped into the .config_init
functions without unduly affecting the state of the PHY.
If CONFIG_OF is not set, there is no of_node, or no "marvell,reg-init"
property, the PHY initialization is unchanged.
Signed-off-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Cyril Chemparathy <cyril-l0cyMroinI0@public.gmane.org>
Cc: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Cc: Arnaud Patard <arnaud.patard-dQbF7i+pzddAfugRpC6u6w@public.gmane.org>
Cc: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---
drivers/net/phy/marvell.c | 91 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index f0bd1a1..33ad654 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -30,6 +30,7 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/marvell_phy.h>
+#include <linux/of.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -186,6 +187,85 @@ static int marvell_config_aneg(struct phy_device *phydev)
return 0;
}
+#ifndef CONFIG_OF
+static int marvell_of_reg_init(struct phy_device *phydev)
+{
+ return 0;
+}
+#else
+/*
+ * Set and/or override some configuration registers based on the
+ * marvell,reg-init property stored in the of_node for the phydev.
+ *
+ * marvell,reg-init = <reg-spec val-spec>,...;
+ *
+ * There may be one or more pairs of <reg-spec val-spec>:
+ * reg-spec [16..31]: Page address.
+ * reg-spec [0..15]: Register address.
+ *
+ * val-spec [16..31]: Mask bits.
+ * val-spec [0..15]: Register bits.
+ */
+static int marvell_of_reg_init(struct phy_device *phydev)
+{
+ const __be32 *paddr;
+ int len, i, saved_page, current_page, page_changed, ret;
+
+ if (!phydev->dev.of_node)
+ return 0;
+
+ paddr = of_get_property(phydev->dev.of_node, "marvell,reg-init", &len);
+ if (!paddr || len < (2 * sizeof(u32)))
+ return 0;
+
+ saved_page = phy_read(phydev, 22);
+ if (saved_page < 0)
+ return saved_page;
+ page_changed = 0;
+ current_page = saved_page;
+
+ ret = 0;
+ len /= sizeof(u32);
+ for (i = 0; i < len / 2; i += 2) {
+ u32 reg_spec = be32_to_cpup(&paddr[i]);
+ u32 val_spec = be32_to_cpup(&paddr[i + 1]);
+ u16 reg = reg_spec & 0xffff;
+ u16 reg_page = reg_spec >> 16;
+ u16 val_bits = val_spec & 0xffff;
+ u16 mask = val_spec >> 16;
+ int val;
+
+ if (reg_page != current_page) {
+ ret = phy_write(phydev, 22, reg_page);
+ if (ret < 0)
+ goto err;
+ current_page = reg_page;
+ page_changed = 1;
+ }
+
+ val = 0;
+ if (mask) {
+ val = phy_read(phydev, reg);
+ if (val < 0) {
+ ret = val;
+ goto err;
+ }
+ val &= mask;
+ }
+ val |= val_bits;
+
+ ret = phy_write(phydev, reg, (u16)val);
+ if (ret < 0)
+ goto err;
+
+ }
+err:
+ if (page_changed)
+ ret = phy_write(phydev, 22, saved_page);
+ return ret;
+}
+#endif /* CONFIG_OF */
+
static int m88e1121_config_aneg(struct phy_device *phydev)
{
int err, oldpage, mscr;
@@ -368,6 +448,9 @@ static int m88e1111_config_init(struct phy_device *phydev)
return err;
}
+ err = marvell_of_reg_init(phydev);
+ if (err < 0)
+ return err;
err = phy_write(phydev, MII_BMCR, BMCR_RESET);
if (err < 0)
@@ -420,6 +503,10 @@ static int m88e1118_config_init(struct phy_device *phydev)
if (err < 0)
return err;
+ err = marvell_of_reg_init(phydev);
+ if (err < 0)
+ return err;
+
/* Reset address */
err = phy_write(phydev, 0x16, 0x0);
if (err < 0)
@@ -491,6 +578,10 @@ static int m88e1145_config_init(struct phy_device *phydev)
}
}
+ err = marvell_of_reg_init(phydev);
+ if (err < 0)
+ return err;
+
return 0;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] phylib: Add support for Marvell 88E1149R devices.
From: David Daney @ 2010-11-17 23:54 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: David Daney
In-Reply-To: <1290038071-13296-1-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
The 88E1149R is 10/100/1000 quad-gigabit Ethernet PHY. The
.config_aneg function can be shared with 88E1118, but it needs its own
.config_init.
Signed-off-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
---
drivers/net/phy/marvell.c | 44 +++++++++++++++++++++++++++++++++++++++++++
include/linux/marvell_phy.h | 1 +
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 33ad654..a0851c7 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -519,6 +519,36 @@ static int m88e1118_config_init(struct phy_device *phydev)
return 0;
}
+static int m88e1149_config_init(struct phy_device *phydev)
+{
+ int err;
+
+ /* Change address */
+ err = phy_write(phydev, 0x16, 0x0002);
+ if (err < 0)
+ return err;
+
+ /* Enable 1000 Mbit */
+ err = phy_write(phydev, 0x15, 0x1048);
+ if (err < 0)
+ return err;
+
+ err = marvell_of_reg_init(phydev);
+ if (err < 0)
+ return err;
+
+ /* Reset address */
+ err = phy_write(phydev, 0x16, 0x0);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, MII_BMCR, BMCR_RESET);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
static int m88e1145_config_init(struct phy_device *phydev)
{
int err;
@@ -776,6 +806,19 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
+ .phy_id = MARVELL_PHY_ID_88E1149R,
+ .phy_id_mask = MARVELL_PHY_ID_MASK,
+ .name = "Marvell 88E1149R",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &m88e1149_config_init,
+ .config_aneg = &m88e1118_config_aneg,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &marvell_ack_interrupt,
+ .config_intr = &marvell_config_intr,
+ .driver = { .owner = THIS_MODULE },
+ },
+ {
.phy_id = MARVELL_PHY_ID_88E1240,
.phy_id_mask = MARVELL_PHY_ID_MASK,
.name = "Marvell 88E1240",
@@ -826,6 +869,7 @@ static struct mdio_device_id __maybe_unused marvell_tbl[] = {
{ 0x01410e10, 0xfffffff0 },
{ 0x01410cb0, 0xfffffff0 },
{ 0x01410cd0, 0xfffffff0 },
+ { 0x01410e50, 0xfffffff0 },
{ 0x01410e30, 0xfffffff0 },
{ 0x01410e90, 0xfffffff0 },
{ }
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index 1ff81b5..dd3c34e 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -11,6 +11,7 @@
#define MARVELL_PHY_ID_88E1118 0x01410e10
#define MARVELL_PHY_ID_88E1121R 0x01410cb0
#define MARVELL_PHY_ID_88E1145 0x01410cd0
+#define MARVELL_PHY_ID_88E1149R 0x01410e50
#define MARVELL_PHY_ID_88E1240 0x01410e30
#define MARVELL_PHY_ID_88E1318S 0x01410e90
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 1/2] of/phylib: Use device tree properties to initialize Marvell PHYs.
From: David Daney @ 2010-11-18 0:01 UTC (permalink / raw)
To: David Daney
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cyril Chemparathy,
Arnaud Patard
In-Reply-To: <1290038071-13296-2-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On 11/17/2010 03:54 PM, David Daney wrote:
> Some aspects of PHY initialization are board dependent, things like
> indicator LED connections and some clocking modes cannot be determined
> by probing. The dev_flags element of struct phy_device can be used to
> control these things if an appropriate value can be passed from the
> Ethernet driver. We run into problems however if the PHY connections
> are specified by the device tree. There is no way for the Ethernet
> driver to know what flags it should pass.
>
> If we are using the device tree, the struct phy_device will be
> populated with the device tree node corresponding to the PHY, and we
> can extract extra configuration information from there.
>
> The next question is what should the format of that information be?
> It is highly device specific, and the device tree representation
> should not be tied to any arbitrary kernel defined constants. A
> straight forward representation is just to specify the exact bits that
> should be set using the "marvell,reg-init" property:
>
> phy5: ethernet-phy@5 {
> reg =<5>;
> device_type = "ethernet-phy";
> marvell,reg-init =
> <0x00030010 0x5777>, /* Reg 3,16<- 0x5777 */
> <0x00030011 0x00aa>, /* Reg 3,17<- 0x00aa */
> <0x00030012 0x4105>, /* Reg 3,18<- 0x4105 */
> <0x00030013 0x0060>; /* Reg 3,19<- 0x0060 */
> <0x00020015 0x00300000>; /* clear bits 4..5 of Reg 2,21 */
Well, of course these mask bits are reversed. That last line should
really be:
<0x00020015 0xffcf0000>; /* clear bits 4..5 of Reg 2,21 */
> };
>
> The Marvell PHYs have a page select register at register 22 (0x16), we
> can specify any register by its page and register number. These are
> encoded in the high and low parts of the first word. The second word
> contains a mask and value to be ORed in its high and low parts.
> property, the PHY initialization is unchanged.
[...]
David Daney
^ permalink raw reply
* [PATCH net-next-2.6] can: EG20T PCH: use BIT(X)
From: Tomoya MORINAGA @ 2010-11-18 0:06 UTC (permalink / raw)
To: Wolfgang Grandegger, Wolfram Sang, Christian Pellegrin,
Barry Song, Samuel Ortiz
Cc: qi.wang, yong.y.wang, andrew.chih.howe.khor, joel.clark,
kok.howg.ewe, margie.foster
Replace bit assignment value to BIT(X).
For easy to readable/identifiable, replace all bit assigned macros to BIT(X)
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/pch_can.c | 73 +++++++++++++++++++++++----------------------
1 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index c523e3d..238622a 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -38,50 +38,51 @@
#define PCH_ENABLE 1 /* The enable flag */
#define PCH_DISABLE 0 /* The disable flag */
-#define PCH_CTRL_INIT 0x0001 /* The INIT bit of CANCONT register. */
-#define PCH_CTRL_IE 0x0002 /* The IE bit of CAN control register */
-#define PCH_CTRL_IE_SIE_EIE 0x000e
-#define PCH_CTRL_CCE 0x0040
-#define PCH_CTRL_OPT 0x0080 /* The OPT bit of CANCONT register. */
-#define PCH_OPT_SILENT 0x0008 /* The Silent bit of CANOPT reg. */
-#define PCH_OPT_LBACK 0x0010 /* The LoopBack bit of CANOPT reg. */
+#define PCH_CTRL_INIT BIT(0) /* The INIT bit of CANCONT register. */
+#define PCH_CTRL_IE BIT(1) /* The IE bit of CAN control register */
+#define PCH_CTRL_IE_SIE_EIE (BIT(3) | BIT(2) | BIT(1))
+#define PCH_CTRL_CCE BIT(6)
+#define PCH_CTRL_OPT BIT(7) /* The OPT bit of CANCONT register. */
+#define PCH_OPT_SILENT BIT(3) /* The Silent bit of CANOPT reg. */
+#define PCH_OPT_LBACK BIT(4) /* The LoopBack bit of CANOPT reg. */
+
#define PCH_CMASK_RX_TX_SET 0x00f3
#define PCH_CMASK_RX_TX_GET 0x0073
#define PCH_CMASK_ALL 0xff
-#define PCH_CMASK_RDWR 0x80
-#define PCH_CMASK_ARB 0x20
-#define PCH_CMASK_CTRL 0x10
-#define PCH_CMASK_MASK 0x40
-#define PCH_CMASK_NEWDAT 0x04
-#define PCH_CMASK_CLRINTPND 0x08
-#define PCH_IF_MCONT_NEWDAT 0x8000
-#define PCH_IF_MCONT_INTPND 0x2000
-#define PCH_IF_MCONT_UMASK 0x1000
-#define PCH_IF_MCONT_TXIE 0x0800
-#define PCH_IF_MCONT_RXIE 0x0400
-#define PCH_IF_MCONT_RMTEN 0x0200
-#define PCH_IF_MCONT_TXRQXT 0x0100
-#define PCH_IF_MCONT_EOB 0x0080
-#define PCH_IF_MCONT_DLC 0x000f
-#define PCH_IF_MCONT_MSGLOST 0x4000
-#define PCH_MASK2_MDIR_MXTD 0xc000
-#define PCH_ID2_DIR 0x2000
-#define PCH_ID2_XTD 0x4000
-#define PCH_ID_MSGVAL 0x8000
-#define PCH_IF_CREQ_BUSY 0x8000
+#define PCH_CMASK_NEWDAT BIT(2)
+#define PCH_CMASK_CLRINTPND BIT(3)
+#define PCH_CMASK_CTRL BIT(4)
+#define PCH_CMASK_ARB BIT(5)
+#define PCH_CMASK_MASK BIT(6)
+#define PCH_CMASK_RDWR BIT(7)
+#define PCH_IF_MCONT_NEWDAT BIT(15)
+#define PCH_IF_MCONT_MSGLOST BIT(14)
+#define PCH_IF_MCONT_INTPND BIT(13)
+#define PCH_IF_MCONT_UMASK BIT(12)
+#define PCH_IF_MCONT_TXIE BIT(11)
+#define PCH_IF_MCONT_RXIE BIT(10)
+#define PCH_IF_MCONT_RMTEN BIT(9)
+#define PCH_IF_MCONT_TXRQXT BIT(8)
+#define PCH_IF_MCONT_EOB BIT(7)
+#define PCH_IF_MCONT_DLC (BIT(0) | BIT(1) | BIT(2) | BIT(3))
+#define PCH_MASK2_MDIR_MXTD (BIT(14) | BIT(15))
+#define PCH_ID2_DIR BIT(13)
+#define PCH_ID2_XTD BIT(14)
+#define PCH_ID_MSGVAL BIT(15)
+#define PCH_IF_CREQ_BUSY BIT(15)
#define PCH_STATUS_INT 0x8000
#define PCH_REC 0x00007f00
#define PCH_TEC 0x000000ff
-#define PCH_RX_OK 0x00000010
-#define PCH_TX_OK 0x00000008
-#define PCH_BUS_OFF 0x00000080
-#define PCH_EWARN 0x00000040
-#define PCH_EPASSIV 0x00000020
-#define PCH_LEC0 0x00000001
-#define PCH_LEC1 0x00000002
-#define PCH_LEC2 0x00000004
+#define PCH_TX_OK BIT(3)
+#define PCH_RX_OK BIT(4)
+#define PCH_EPASSIV BIT(5)
+#define PCH_EWARN BIT(6)
+#define PCH_BUS_OFF BIT(7)
+#define PCH_LEC0 BIT(0)
+#define PCH_LEC1 BIT(1)
+#define PCH_LEC2 BIT(2)
#define PCH_LEC_ALL (PCH_LEC0 | PCH_LEC1 | PCH_LEC2)
#define PCH_STUF_ERR PCH_LEC0
#define PCH_FORM_ERR PCH_LEC1
--
1.6.0.6
^ permalink raw reply related
* Re: [RFC PATCH 0/3] e1000/e1000e/igb MDI-X control implementation
From: Ben Hutchings @ 2010-11-18 0:14 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <20101117232645.3513.20655.stgit@jbrandeb-ich9b.jf.intel.com>
On Wed, 2010-11-17 at 15:29 -0800, Jesse Brandeburg wrote:
> this patch series is RFC for implemenation, I've briefly tested
> it to make sure I still get link after setting MDI-X and I see
> the status change in ethtool.
>
> The basic idea is to fill out the MDI-X read functionality with
> some write functionality.
>
> the e1000e patch is actually what drove this change as some users
> have found wonky switches that must have MDI/MDI-X forced.
[...]
I object to all these for the reasons explained in my comments on the
changes to the ethtool utility.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: extended netdevice naming proposal
From: Ben Hutchings @ 2010-11-18 0:39 UTC (permalink / raw)
To: Matt Domsch; +Cc: linux-hotplug, netdev, narendra_k, jcm, notting
In-Reply-To: <20101117220659.GA12177@auslistsprd01.us.dell.com>
On Wed, 2010-11-17 at 16:06 -0600, Matt Domsch wrote:
> While this _is_ the original bikeshedding problem, as long as I'm
> going to use biosdevname to change names for embedded NICs, perhaps I
> can be so bold as to change them for USB add-in cards too?
>
> There are quite a few dimensions to the problem:
> * device location (onboard, PCI, other bus)
> * multiple ports on a single add-in card
> * with Network Partitioning (NPAR) and SR-IOV, the OS sees multiple
> network interfaces (physical or virtual interfaces) but a single external port
> * the suffix .1234 currently used for vlans (ala vconfig)
> * A single PCI device may drive multiple external ports
>
> As such, here is a naming proposal, aimed to keep within 15
> characters for most configurations.
>
> (location)(slot)#(port)/(instance).(vlan)
>
> location := NIC on Motherboard = net1, net2, net3, net4
"net", really?! I can't say I care that much, but this just doesn't
seem like a helpful prefix.
> (note: people hated the TLA collision with 'lom', so avoiding that here).
> := PCI slot = pci1, pci2, pci3, pci4
> these correspond to chassis labels, information is available in
> $PIRQ, SMBIOS or ACPI, which biosdevname retrieves and uses.
>
> For single- or multi-port cards in PCI slots, append #(port):
> pci1#1, pci1#2, pci1#3, pci1#4 for 4 ports on a card in PCI slot 1
'#' might be problematic but I don't have any concrete evidence of that.
> There is currently no way to get this port info from BIOS. Several people
> have suggested using adding a PCI capabilities field to expose this
> info in a standard way, but that's a ways off. Until then, biosdevname
> can guess (assume ascending MAC order on the single card).
You could try using the dev_id attribute first; it's supposed to be a
0-based index of a net device on a board. It won't be unique in all
cases, e.g. if a NIC vendor has used a bridge chip to connect multiple
controllers on a single board or if the driver just doesn't set it. So
you would need to fall back to MAC order in tha tcase.
> For NPAR/SR-IOV where the physical port is shared by several
> instances, append /(instance):
> net1/1, net1/2 pci1#1/1, pci1#1/2,
> pci1#1/2, pci1#1/3, ...
[...]
Surely VFs are normally passed through to a guest, in which case:
1. The host/console/dom0 won't create a net device for them.
2. The guest won't (and shouldn't) have such information about the
physical location of the PCI function.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* ethtool 2.6.36 released
From: Ben Hutchings @ 2010-11-18 0:58 UTC (permalink / raw)
To: netdev; +Cc: Jeff Garzik
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
ethtool version 2.6.36 has been released.
Home page: https://sourceforge.net/projects/gkernel/
Download link:
https://sourceforge.net/projects/gkernel/files/ethtool/2.6.36/ethtool-2.6.36.tar.gz/download
This will be the last release via Sourceforge. A new home page will
shortly be created on kernel.org resources, probably at
<https://ftp.kernel.org/pub/software/network/ethtool/>.
Release notes:
* Fix: RX n-tuple masks and documentation
* Feature: Ethernet-level RX n-tuple filtering and 'clear' action
* Feature: stmmac register dump support
* Feature: get permanent address (-P) option
* Feature: VLAN acceleration control
Jeff Garzik has handed over ongoing maintenance to me. Jeff, thanks for
all your work on ethtool over the past 10 years and for your help with
making this release.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply
* ixgbe dump
From: Yinghai Lu @ 2010-11-18 1:21 UTC (permalink / raw)
To: Brandeburg, Jesse, David Miller; +Cc: NetDev
[ 1546.287521] md: stopping all md devices.
[ 1547.283729] kvm: exiting hardware virtualization
[ 1547.292876] sd 2:2:1:0: [sdb] Synchronizing SCSI cache
[ 1547.293831] sd 2:2:0:0: [sda] Synchronizing SCSI cache
[ 1547.299627] BUG: unable to handle kernel NULL pointer dereference at 0000000000000033
[ 1547.315819] IP: [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
[ 1547.316448] PGD 3ff4487067 PUD 3ff216b067 PMD 0
[ 1547.335626] Oops: 0000 [#1] SMP
[ 1547.335941] last sysfs file: /sys/kernel/kexec_loaded
[ 1547.336381] CPU 0
[ 1547.336548] Modules linked in:
[ 1547.355798]
[ 1547.355968] Pid: 25630, comm: kexec Not tainted 2.6.37-rc2-tip-yh-01961-g6034289-dirty #281 /Sun Fire X4800
[ 1547.375849] RIP: 0010:[<ffffffff81746273>] [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
[ 1547.395543] RSP: 0018:ffff881fb9d49ce8 EFLAGS: 00010287
[ 1547.396080] RAX: 0000000000000000 RBX: ffff88dffe5a0940 RCX: ffff88dffe5a0940
[ 1547.415635] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffc90077780000
[ 1547.416299] RBP: ffff881fb9d49d48 R08: 0000000000000000 R09: 0000000000000000
[ 1547.435860] R10: 000000000000a608 R11: 0000000000000000 R12: 0000000000000000
[ 1547.455516] R13: ffff88dffe5a0000 R14: 0000000000003400 R15: ffff881fb9d49db7
[ 1547.456257] FS: 00000000006e0850(0063) GS:ffff88207d600000(0000) knlGS:0000000000000000
[ 1547.475937] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1547.495330] CR2: 0000000000000033 CR3: 0000003ffa77e000 CR4: 00000000000006f0
[ 1547.496009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1547.515594] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1547.516229] Process kexec (pid: 25630, threadinfo ffff881fb9d48000, task ffff881f8a57a2d0)
[ 1547.536039] Stack:
[ 1547.536244] 0000000000000040 0000002b00000000 ffff881ffedc1000 0000000000000006
[ 1547.555894] ffff88dffe5a1b40 0b00000081454ec8 ffff881fb9d49d48 ffff88dffe5a0940
[ 1547.575411] ffff881ffedc1000 000000000000001e 0000000000000000 ffff881fb9d49db7
[ 1547.576131] Call Trace:
[ 1547.595251] [<ffffffff8174a8f4>] __ixgbe_shutdown+0x9d/0x153
[ 1547.595770] [<ffffffff8174a9c4>] ixgbe_shutdown+0x1a/0x43
[ 1547.615250] [<ffffffff814574bb>] pci_device_shutdown+0x2c/0x40
[ 1547.615887] [<ffffffff8151c5e9>] device_shutdown+0x75/0xb0
[ 1547.635268] [<ffffffff8108f461>] kernel_restart_prepare+0x2c/0x33
[ 1547.635927] [<ffffffff810bc821>] kernel_kexec+0x38/0x6b
[ 1547.655252] [<ffffffff8108f618>] sys_reboot+0x156/0x194
[ 1547.655765] [<ffffffff8114422a>] ? __d_free+0x59/0x5e
[ 1547.675145] [<ffffffff81144283>] ? d_free+0x54/0x66
[ 1547.675612] [<ffffffff8114439d>] ? d_kill+0x3b/0x43
[ 1547.695025] [<ffffffff81144a1c>] ? dput+0x40/0x140
[ 1547.695539] [<ffffffff811351a9>] ? fput+0x1d7/0x1e6
[ 1547.696045] [<ffffffff81036c0c>] ? sysret_check+0x27/0x62
[ 1547.715426] [<ffffffff81cd9772>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1547.734897] [<ffffffff81036bdb>] system_call_fastpath+0x16/0x1b
[ 1547.735428] Code: d2 e9 81 00 00 00 48 8b 83 00 12 00 00 8b 80 88 50 00 00 0d 00 00 00 80 e9 a7 00 00 00 48 8b 81 00 0a 00 00 48 8b bb 00 12 00 00 <0f> b6 40 33 83 f8 3f 7f 0d 89 c6 c1 e6 06 81 c6 28 10 00 00 eb
[ 1547.775262] RIP [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
[ 1547.775909] RSP <ffff881fb9d49ce8>
[ 1547.794997] CR2: 0000000000000033
[ 1547.795987] ---[ end trace 4ed9616adc45007c ]---
^ permalink raw reply
* Re: extended netdevice naming proposal
From: Bill Nottingham @ 2010-11-18 2:10 UTC (permalink / raw)
To: Matt Domsch; +Cc: linux-hotplug, netdev, narendra_k, jcm
In-Reply-To: <20101117220659.GA12177@auslistsprd01.us.dell.com>
Matt Domsch (Matt_Domsch@dell.com) said:
> (location)(slot)#(port)/(instance).(vlan)
AIUI, the kernel explicitly rejects '/' in the name (for fairly obvious
sysfs reasons.) So you'd at least need a different delimiter. There may
also be potential confusion with pci01#03:02.0001 with someone thinking
that's bus/dev/fn, if we're being really petty.
Bill
^ permalink raw reply
* Re: extended netdevice naming proposal
From: Ben Hutchings @ 2010-11-18 2:29 UTC (permalink / raw)
To: Bill Nottingham; +Cc: Matt Domsch, linux-hotplug, netdev, narendra_k, jcm
In-Reply-To: <20101118021039.GA18707@nostromo.devel.redhat.com>
On Wed, 2010-11-17 at 21:10 -0500, Bill Nottingham wrote:
> Matt Domsch (Matt_Domsch@dell.com) said:
> > (location)(slot)#(port)/(instance).(vlan)
>
> AIUI, the kernel explicitly rejects '/' in the name (for fairly obvious
> sysfs reasons.) So you'd at least need a different delimiter. There may
> also be potential confusion with pci01#03:02.0001 with someone thinking
> that's bus/dev/fn, if we're being really petty.
':' is also reserved for alias interfaces, the old way of assigning
multiple IP addresses.
I would say '-' is a good separator, but that might result in ambiguity
in IRQ names.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 2.6.37-rc2] Fix duplicate volatile warning.
From: Tetsuo Handa @ 2010-11-18 4:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
Commit 0ed8ddf4 "neigh: Protect neigh->ha[] with a seqlock" made gcc 3.x
to warn
include/net/neighbour.h: In function `neigh_event_send':
include/net/neighbour.h:306: warning: duplicate `volatile'
.
----------------------------------------
>From a391f571f21bfa81369599f03e86fa75589291a3 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Thu, 18 Nov 2010 12:44:26 +0900
Subject: [PATCH 2.6.37-rc2] Fix duplicate volatile warning.
jiffies is defined as "volatile".
extern unsigned long volatile __jiffy_data jiffies;
ACCESS_ONCE() uses "volatile".
As a result, some compilers warn duplicate `volatile' for ACCESS_ONCE(jiffies).
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
include/net/neighbour.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 55590ab..6beb1ff 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -303,7 +303,7 @@ static inline void neigh_confirm(struct neighbour *neigh)
static inline int neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
- unsigned long now = ACCESS_ONCE(jiffies);
+ unsigned long now = jiffies;
if (neigh->used != now)
neigh->used = now;
--
1.7.1
^ permalink raw reply related
* Re: [1/2] of/phylib: Use device tree properties to initialize Marvell PHYs.
From: Milton Miller @ 2010-11-18 5:38 UTC (permalink / raw)
To: David Daney
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Cyril Chemparathy,
Arnaud Patard
In-Reply-To: <1290038071-13296-2-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Wed, 17 Nov 2010 15:54:30 -0800, David Daney wrote:
> Some aspects of PHY initialization are board dependent, things like
> indicator LED connections and some clocking modes cannot be determined
> by probing. The dev_flags element of struct phy_device can be used to
> control these things if an appropriate value can be passed from the
> Ethernet driver. We run into problems however if the PHY connections
> are specified by the device tree. There is no way for the Ethernet
> driver to know what flags it should pass.
>
> If we are using the device tree, the struct phy_device will be
> populated with the device tree node corresponding to the PHY, and we
> can extract extra configuration information from there.
..
>
> ---
> drivers/net/phy/marvell.c | 91 +++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 91 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index f0bd1a1..33ad654 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -30,6 +30,7 @@
> #include <linux/ethtool.h>
> #include <linux/phy.h>
> #include <linux/marvell_phy.h>
> +#include <linux/of.h>
>
> #include <asm/io.h>
> #include <asm/irq.h>
> @@ -186,6 +187,85 @@ static int marvell_config_aneg(struct phy_device *phydev)
> return 0;
> }
>
> +#ifndef CONFIG_OF
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + return 0;
> +}
> +#else
> +/*
> + * Set and/or override some configuration registers based on the
> + * marvell,reg-init property stored in the of_node for the phydev.
> + *
> + * marvell,reg-init = <reg-spec val-spec>,...;
> + *
> + * There may be one or more pairs of <reg-spec val-spec>:
> + * reg-spec [16..31]: Page address.
> + * reg-spec [0..15]: Register address.
> + *
> + * val-spec [16..31]: Mask bits.
> + * val-spec [0..15]: Register bits.
> + */
> +static int marvell_of_reg_init(struct phy_device *phydev)
> +{
> + const __be32 *paddr;
> + int len, i, saved_page, current_page, page_changed, ret;
> +
> + if (!phydev->dev.of_node)
> + return 0;
> +
> + paddr = of_get_property(phydev->dev.of_node, "marvell,reg-init", &len);
> + if (!paddr || len < (2 * sizeof(u32)))
> + return 0;
> +
> + saved_page = phy_read(phydev, 22);
> + if (saved_page < 0)
> + return saved_page;
> + page_changed = 0;
> + current_page = saved_page;
> +
> + ret = 0;
> + len /= sizeof(u32);
> + for (i = 0; i < len / 2; i += 2) {
i < len - 1 would execute all the register inits specified in the property.
> + u32 reg_spec = be32_to_cpup(&paddr[i]);
> + u32 val_spec = be32_to_cpup(&paddr[i + 1]);
> + u16 reg = reg_spec & 0xffff;
> + u16 reg_page = reg_spec >> 16;
> + u16 val_bits = val_spec & 0xffff;
> + u16 mask = val_spec >> 16;
> + int val;
> +
While the outcome is the same, this code also mixes sizeof(u32)
with __be32 pointer math.
milton
^ permalink raw reply
* Re: 2.6.37-rc2 after KVM shutdown - unregister_netdevice: waiting for vmtst01eth0 to become free. Usage count = 1
From: Nikola Ciprich @ 2010-11-18 6:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: KVM list, netdev list, nikola.ciprich, Linux kernel list
In-Reply-To: <1289900812.5372.1.camel@edumazet-laptop>
> Yep, this is a known problem, thanks !
>
> fix is there :
>
> http://patchwork.ozlabs.org/patch/71354/
Thanks Eric, this indeed fixes the problem..
I noticed the fix didn't make it to 2.6.37-rc2-git3 though,
maybe it just got omited?
anyways, thanks for help!
n.
>
>
>
> --
> 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
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply
* Re: net-next-2.6 [PATCH 0/6]: dccp ccid-2: Ack Vector patch set second/concluding part II
From: Gerrit Renker @ 2010-11-18 6:42 UTC (permalink / raw)
To: David Miller; +Cc: dccp, netdev
In-Reply-To: <20101115.110459.68121782.davem@davemloft.net>
> Some of the new functions you added had some coding style quirks,
> for example the openning brace for dccp_ackvec_clear_state()
> has an unnecessary space before it on that line.
>
> Please fix those sorts of things up, thanks.
I am sorry, this glitch must have occurred since I last ran checkpatch.pl.
Please find a fix attached. I have checked all patches again, line-by-line
and using checkpatch.pl. I found only this one occurrence, checking twice.
It is also on top today's copy of net-next-2.6, on
git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
(I tried to put up the patches on top of this, but this did not work cleanly,
due to inter-dependencies. I apologize for this.)
>>>>>>>>>>>>>>>>>>>>>>>>>> Patch <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp ccid-2: whitespace fix-up
This fixes whitespace noise introduced in commit "dccp ccid-2: Algorithm to
update buffer state", 5753fdfe8bd8e9a2ff9e5af19b0ffc78bfcd502a, 14 Nov 2010.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
ackvec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/dccp/ackvec.c
+++ b/net/dccp/ackvec.c
@@ -282,7 +282,7 @@ void dccp_ackvec_input(struct dccp_ackvec *av, struct sk_buff *skb)
* packet of group (2) in 11.4.2.
*/
void dccp_ackvec_clear_state(struct dccp_ackvec *av, const u64 ackno)
- {
+{
struct dccp_ackvec_record *avr, *next;
u8 runlen_now, eff_runlen;
s64 delta;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox