* [PATCH 00/08] [TIPC]: Initial patch set for TIPC 1.6.3
From: Stephens, Allan @ 2008-02-22 19:58 UTC (permalink / raw)
To: netdev
This is a patch set containing TIPC code developed as part of the TIPC
1.7
development project. This first set contains small enhancements and bug
fixes
only, and is thus being integrated under the current TIPC 1.6
designation.
Patch set summary:
01 Update version to 1.6.3
02 Add argument validation for shutdown
03 Eliminate sparse warning in socket code
04 Minor cleanup of message header code
05 Use correct bitmask when setting version in
06 Enhancements to message header field writing
07 Removal of obsolete message header option co
08 TIPC network address handling cleanup
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
^ permalink raw reply
* [PATCH 04/08] [TIPC]: Minor cleanup of message header code
From: Stephens, Allan @ 2008-02-22 19:59 UTC (permalink / raw)
To: netdev
This patch eliminates some unused or duplicate message header
symbols, and fixes up the comments and/or location of a few
other symbols.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
---
net/tipc/link.c | 16 ++++++++--------
net/tipc/msg.c | 16 ++++++++--------
net/tipc/msg.h | 19 ++++++++-----------
net/tipc/port.c | 4 ++--
4 files changed, 26 insertions(+), 29 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 1b17fec..9d6b315 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -2832,15 +2832,15 @@ static void link_set_supervision_props(struct
link *l_ptr, u32 tolerance)
void tipc_link_set_queue_limits(struct link *l_ptr, u32 window)
{
/* Data messages from this node, inclusive FIRST_FRAGM */
- l_ptr->queue_limit[DATA_LOW] = window;
- l_ptr->queue_limit[DATA_MEDIUM] = (window / 3) * 4;
- l_ptr->queue_limit[DATA_HIGH] = (window / 3) * 5;
- l_ptr->queue_limit[DATA_CRITICAL] = (window / 3) * 6;
+ l_ptr->queue_limit[TIPC_LOW_IMPORTANCE] = window;
+ l_ptr->queue_limit[TIPC_MEDIUM_IMPORTANCE] = (window / 3) * 4;
+ l_ptr->queue_limit[TIPC_HIGH_IMPORTANCE] = (window / 3) * 5;
+ l_ptr->queue_limit[TIPC_CRITICAL_IMPORTANCE] = (window / 3) * 6;
/* Transiting data messages,inclusive FIRST_FRAGM */
- l_ptr->queue_limit[DATA_LOW + 4] = 300;
- l_ptr->queue_limit[DATA_MEDIUM + 4] = 600;
- l_ptr->queue_limit[DATA_HIGH + 4] = 900;
- l_ptr->queue_limit[DATA_CRITICAL + 4] = 1200;
+ l_ptr->queue_limit[TIPC_LOW_IMPORTANCE + 4] = 300;
+ l_ptr->queue_limit[TIPC_MEDIUM_IMPORTANCE + 4] = 600;
+ l_ptr->queue_limit[TIPC_HIGH_IMPORTANCE + 4] = 900;
+ l_ptr->queue_limit[TIPC_CRITICAL_IMPORTANCE + 4] = 1200;
l_ptr->queue_limit[CONN_MANAGER] = 1200;
l_ptr->queue_limit[ROUTE_DISTRIBUTOR] = 1200;
l_ptr->queue_limit[CHANGEOVER_PROTOCOL] = 2500;
diff --git a/net/tipc/msg.c b/net/tipc/msg.c
index 7824854..696a863 100644
--- a/net/tipc/msg.c
+++ b/net/tipc/msg.c
@@ -73,10 +73,10 @@ void tipc_msg_print(struct print_buf *buf, struct
tipc_msg *msg, const char *str
tipc_printf(buf, "NO(%u/%u):",msg_long_msgno(msg),
msg_fragm_no(msg));
break;
- case DATA_LOW:
- case DATA_MEDIUM:
- case DATA_HIGH:
- case DATA_CRITICAL:
+ case TIPC_LOW_IMPORTANCE:
+ case TIPC_MEDIUM_IMPORTANCE:
+ case TIPC_HIGH_IMPORTANCE:
+ case TIPC_CRITICAL_IMPORTANCE:
tipc_printf(buf, "DAT%u:", msg_user(msg));
if (msg_short(msg)) {
tipc_printf(buf, "CON:");
@@ -229,10 +229,10 @@ void tipc_msg_print(struct print_buf *buf, struct
tipc_msg *msg, const char *str
switch (usr) {
case CONN_MANAGER:
case NAME_DISTRIBUTOR:
- case DATA_LOW:
- case DATA_MEDIUM:
- case DATA_HIGH:
- case DATA_CRITICAL:
+ case TIPC_LOW_IMPORTANCE:
+ case TIPC_MEDIUM_IMPORTANCE:
+ case TIPC_HIGH_IMPORTANCE:
+ case TIPC_CRITICAL_IMPORTANCE:
if (msg_short(msg))
break; /* No error */
switch (msg_errcode(msg)) {
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index e9ef6df..282e916 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -40,18 +40,16 @@
#include "core.h"
#define TIPC_VERSION 2
-#define DATA_LOW TIPC_LOW_IMPORTANCE
-#define DATA_MEDIUM TIPC_MEDIUM_IMPORTANCE
-#define DATA_HIGH TIPC_HIGH_IMPORTANCE
-#define DATA_CRITICAL TIPC_CRITICAL_IMPORTANCE
-#define SHORT_H_SIZE 24 /* Connected,in cluster */
+
+#define SHORT_H_SIZE 24 /* Connected, in-cluster
messages */
#define DIR_MSG_H_SIZE 32 /* Directly addressed messages
*/
-#define CONN_MSG_H_SIZE 36 /* Routed connected msgs*/
-#define LONG_H_SIZE 40 /* Named Messages */
+#define LONG_H_SIZE 40 /* Named messages */
#define MCAST_H_SIZE 44 /* Multicast messages */
-#define MAX_H_SIZE 60 /* Inclusive full options */
+#define INT_H_SIZE 40 /* Internal messages */
+#define MIN_H_SIZE 24 /* Smallest legal TIPC header
size */
+#define MAX_H_SIZE 60 /* Largest possible TIPC header
size */
+
#define MAX_MSG_SIZE (MAX_H_SIZE + TIPC_MAX_USER_MSG_SIZE)
-#define LINK_CONFIG 13
/*
@@ -97,7 +95,7 @@ static inline u32 msg_user(struct tipc_msg *m)
static inline u32 msg_isdata(struct tipc_msg *m)
{
- return (msg_user(m) <= DATA_CRITICAL);
+ return (msg_user(m) <= TIPC_CRITICAL_IMPORTANCE);
}
static inline void msg_set_user(struct tipc_msg *m, u32 n)
@@ -388,7 +386,6 @@ static inline void msg_expand(struct tipc_msg *m,
u32 destnode)
#define NAME_DISTRIBUTOR 11
#define MSG_FRAGMENTER 12
#define LINK_CONFIG 13
-#define INT_H_SIZE 40
#define DSC_H_SIZE 40
/*
diff --git a/net/tipc/port.c b/net/tipc/port.c
index f508614..25b6967 100644
--- a/net/tipc/port.c
+++ b/net/tipc/port.c
@@ -242,7 +242,7 @@ u32 tipc_createport_raw(void *usr_handle,
p_ptr->publ.max_pkt = MAX_PKT_DEFAULT;
p_ptr->publ.ref = ref;
msg = &p_ptr->publ.phdr;
- msg_init(msg, DATA_LOW, TIPC_NAMED_MSG, TIPC_OK, LONG_H_SIZE,
0);
+ msg_init(msg, TIPC_LOW_IMPORTANCE, TIPC_NAMED_MSG, TIPC_OK,
LONG_H_SIZE, 0);
msg_set_orignode(msg, tipc_own_addr);
msg_set_prevnode(msg, tipc_own_addr);
msg_set_origport(msg, ref);
@@ -632,7 +632,7 @@ void tipc_port_recv_proto_msg(struct sk_buff *buf)
msg_orignode(msg),
msg_destport(msg),
tipc_own_addr,
- DATA_HIGH,
+ TIPC_HIGH_IMPORTANCE,
TIPC_CONN_MSG,
err,
0,
--
1.5.3.2
^ permalink raw reply related
* [PATCH 01/08] [TIPC]: Update version to 1.6.3
From: Stephens, Allan @ 2008-02-22 19:59 UTC (permalink / raw)
To: netdev
This patch updates TIPC's version number to 1.6.3.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
---
net/tipc/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/tipc/core.c b/net/tipc/core.c
index d2d7d32..9b9429e 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -57,7 +57,7 @@ void tipc_socket_stop(void);
int tipc_netlink_start(void);
void tipc_netlink_stop(void);
-#define TIPC_MOD_VER "1.6.2"
+#define TIPC_MOD_VER "1.6.3"
#ifndef CONFIG_TIPC_ZONES
#define CONFIG_TIPC_ZONES 3
--
1.5.3.2
^ permalink raw reply related
* [2.6 patch] unexport ip6_find_1stfragopt
From: Adrian Bunk @ 2008-02-22 19:58 UTC (permalink / raw)
To: Herbert Xu, davem; +Cc: netdev
This patch removes the no longer used
EXPORT_SYMBOL_GPL(ip6_find_1stfragopt).
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
This patch has been sent on:
- 30 Jan 2008
961bcbf7370019e35920a75d2d34c91b71708dfe
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 15c4f6c..ca707c0 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -595,7 +595,6 @@ int ip6_find_1stfragopt(struct sk_buff *skb, u8 **nexthdr)
return offset;
}
-EXPORT_SYMBOL_GPL(ip6_find_1stfragopt);
static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
{
^ permalink raw reply related
* [PATCH 3/3][BNX2]: Update version to 1.7.4.
From: Michael Chan @ 2008-02-22 19:50 UTC (permalink / raw)
To: davem, netdev
[BNX2]: Update version to 1.7.4.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 35356fb..15853be 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -56,8 +56,8 @@
#define DRV_MODULE_NAME "bnx2"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "1.7.3"
-#define DRV_MODULE_RELDATE "January 29, 2008"
+#define DRV_MODULE_VERSION "1.7.4"
+#define DRV_MODULE_RELDATE "February 18, 2008"
#define RUN_AT(x) (jiffies + (x))
^ permalink raw reply related
* [PATCH 2/3][BNX2]: Disable parallel detect on an HP blade.
From: Michael Chan @ 2008-02-22 19:50 UTC (permalink / raw)
To: davem, netdev
[BNX2]: Disable parallel detect on an HP blade.
Because of some board issues, we need to disable parallel detect on
an HP blade. Without this patch, the link state can become stuck
when it goes into parallel detect mode.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 2fa2580..35356fb 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -5362,11 +5362,15 @@ bnx2_test_intr(struct bnx2 *bp)
return -ENODEV;
}
+/* Determining link for parallel detection. */
static int
bnx2_5706_serdes_has_link(struct bnx2 *bp)
{
u32 mode_ctl, an_dbg, exp;
+ if (bp->phy_flags & BNX2_PHY_FLAG_NO_PARALLEL)
+ return 0;
+
bnx2_write_phy(bp, MII_BNX2_MISC_SHADOW, MISC_SHDW_MODE_CTL);
bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, &mode_ctl);
@@ -7328,7 +7332,15 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
bp->flags |= BNX2_FLAG_NO_WOL;
bp->wol = 0;
}
- if (CHIP_NUM(bp) != CHIP_NUM_5706) {
+ if (CHIP_NUM(bp) == CHIP_NUM_5706) {
+ /* Don't do parallel detect on this board because of
+ * some board problems. The link will not go down
+ * if we do parallel detect.
+ */
+ if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP &&
+ pdev->subsystem_device == 0x310c)
+ bp->phy_flags |= BNX2_PHY_FLAG_NO_PARALLEL;
+ } else {
bp->phy_addr = 2;
if (reg & BNX2_SHARED_HW_CFG_PHY_2_5G)
bp->phy_flags |= BNX2_PHY_FLAG_2_5G_CAPABLE;
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 3aa0364..1eaf5bb 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6673,6 +6673,7 @@ struct bnx2 {
#define BNX2_PHY_FLAG_DIS_EARLY_DAC 0x00000400
#define BNX2_PHY_FLAG_REMOTE_PHY_CAP 0x00000800
#define BNX2_PHY_FLAG_FORCED_DOWN 0x00001000
+#define BNX2_PHY_FLAG_NO_PARALLEL 0x00002000
u32 mii_bmcr;
u32 mii_bmsr;
^ permalink raw reply related
* [PATCH 1/3][BNX2]: More 5706S link down workaround.
From: Michael Chan @ 2008-02-22 19:49 UTC (permalink / raw)
To: davem, netdev
[BNX2]: More 5706S link down workaround.
The previous patches to workaround the 5706S on an HP blade were not
sufficient. The link state still does not change properly in some
cases. This patch adds polling to make it completely reliable.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 471c7f3..2fa2580 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1273,14 +1273,20 @@ bnx2_set_link(struct bnx2 *bp)
if ((bp->phy_flags & BNX2_PHY_FLAG_SERDES) &&
(CHIP_NUM(bp) == CHIP_NUM_5706)) {
- u32 val;
+ u32 val, an_dbg;
if (bp->phy_flags & BNX2_PHY_FLAG_FORCED_DOWN) {
bnx2_5706s_force_link_dn(bp, 0);
bp->phy_flags &= ~BNX2_PHY_FLAG_FORCED_DOWN;
}
val = REG_RD(bp, BNX2_EMAC_STATUS);
- if (val & BNX2_EMAC_STATUS_LINK)
+
+ bnx2_write_phy(bp, MII_BNX2_MISC_SHADOW, MISC_SHDW_AN_DBG);
+ bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, &an_dbg);
+ bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, &an_dbg);
+
+ if ((val & BNX2_EMAC_STATUS_LINK) &&
+ !(an_dbg & MISC_SHDW_AN_DBG_NOSYNC))
bmsr |= BMSR_LSTATUS;
else
bmsr &= ~BMSR_LSTATUS;
@@ -5390,13 +5396,6 @@ bnx2_5706_serdes_timer(struct bnx2 *bp)
int check_link = 1;
spin_lock(&bp->phy_lock);
- if (bp->phy_flags & BNX2_PHY_FLAG_FORCED_DOWN) {
- bnx2_5706s_force_link_dn(bp, 0);
- bp->phy_flags &= ~BNX2_PHY_FLAG_FORCED_DOWN;
- spin_unlock(&bp->phy_lock);
- return;
- }
-
if (bp->serdes_an_pending) {
bp->serdes_an_pending--;
check_link = 0;
@@ -5420,7 +5419,6 @@ bnx2_5706_serdes_timer(struct bnx2 *bp)
(bp->phy_flags & BNX2_PHY_FLAG_PARALLEL_DETECT)) {
u32 phy2;
- check_link = 0;
bnx2_write_phy(bp, 0x17, 0x0f01);
bnx2_read_phy(bp, 0x15, &phy2);
if (phy2 & 0x20) {
@@ -5435,17 +5433,21 @@ bnx2_5706_serdes_timer(struct bnx2 *bp)
} else
bp->current_interval = bp->timer_interval;
- if (bp->link_up && (bp->autoneg & AUTONEG_SPEED) && check_link) {
+ if (check_link) {
u32 val;
bnx2_write_phy(bp, MII_BNX2_MISC_SHADOW, MISC_SHDW_AN_DBG);
bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, &val);
bnx2_read_phy(bp, MII_BNX2_MISC_SHADOW, &val);
- if (val & MISC_SHDW_AN_DBG_NOSYNC) {
- bnx2_5706s_force_link_dn(bp, 1);
- bp->phy_flags |= BNX2_PHY_FLAG_FORCED_DOWN;
- }
+ if (bp->link_up && (val & MISC_SHDW_AN_DBG_NOSYNC)) {
+ if (!(bp->phy_flags & BNX2_PHY_FLAG_FORCED_DOWN)) {
+ bnx2_5706s_force_link_dn(bp, 1);
+ bp->phy_flags |= BNX2_PHY_FLAG_FORCED_DOWN;
+ } else
+ bnx2_set_link(bp);
+ } else if (!bp->link_up && !(val & MISC_SHDW_AN_DBG_NOSYNC))
+ bnx2_set_link(bp);
}
spin_unlock(&bp->phy_lock);
}
^ permalink raw reply related
* Re: [PATCH] tg3: ethtool phys_id default (rev2)
From: Michael Chan @ 2008-02-22 19:16 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Jeff Garzik, netdev
In-Reply-To: <20080222102429.7e48f1f1@extreme>
On Fri, 2008-02-22 at 10:24 -0800, Stephen Hemminger wrote:
> When asked to blink LEDs the tg3 driver behaves when using:
> ethtool -p ethX
> The default value for data is zero, and other drivers interpret this
> as blink forever (or at least a really long time). The tg3 driver
> interprets this as blink once. All drivers should have the same
> behaviour.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Michael Chan <mchan@broadcom.com>
We should do this across the board for bnx2, bnx2x, and niu as well.
^ permalink raw reply
* Re: [PATCH RFC] phylib: fix forced mode misbehaviour for aneg off case
From: Anton Vorontsov @ 2008-02-22 18:28 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev
In-Reply-To: <B1C15E4A-AA44-46E4-831A-698317E5F677@freescale.com>
On Fri, Feb 22, 2008 at 11:40:04AM -0600, Andy Fleming wrote:
>
> On Feb 22, 2008, at 09:55, Anton Vorontsov wrote:
>
> >When user disabled autonegotiation via ethtool, and no link is
> >detected,
> >phylib will place phy into forcing mode, and then will start calling
> >phy_force_reduction(). This will break user expectations. For example,
> >user asks for fixed speed 1000:
> >
> >ethtool -s eth0 autoneg off speed 1000
> >
> >Without link attached what will actually happen is:
> >
> >Trying 100/FULL
> >Trying 100/HALF
> >Trying 10/FULL
> >Trying 10/HALF
> >...
>
>
> The intent of phy_force_reduction() was to provide a fallback in case
> the user unknowingly selects a speed that is not possible with the
> current link partner. For instance, if you try to select gigabit on
> a 100MB link, it wouldn't work, but because of the way the code was
> designed, the phylib will find a link configuration that works.
Yup, with this patch phylib will not able to find suitable speed for
PHYs without hw angeg capability. The question is: do we have such
hardware or this feature was actually unused and we'll not break
anything.
We can think out something for this case, but it will be still
incompatible with old behaviour. For example, for such setups
we might introduce kernel command line option, specifying
softaneg=eth0, that will force softaneg for PHYs without hw aneg
capability.
> However, I agree that it's not ideal to have the phylib spending a
> lot of time looking for a link if there's not one there. On the
> other hand, why is the user trying to force the link to a certain
> speed if there's no link?
To set up fixed speed for the link, thus to not re-setup it when link
is gone down... This is how all drivers [not using phylib] are
behaving.
> I'm not really opposed to it, though.
>
>
> >
> >This patch implements "software autonegotiation" that is equivalent to
> >current behaviour, but enabled only when hardware autonegotiation was
> >enabled and failed afterwards. With aneg disabled, phylib will not try
> >other link setups.
> >
> >Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >---
>
>
> >
> >@@ -447,7 +451,8 @@ int phy_start_aneg(struct phy_device *phydev)
> > phydev->link_timeout = PHY_AN_TIMEOUT;
> > } else {
> > phydev->state = PHY_FORCING;
> >- phydev->link_timeout = PHY_FORCE_TIMEOUT;
> >+ if (AUTONEG_SOFT == phydev->autoneg)
> >+ phydev->link_timeout = PHY_FORCE_TIMEOUT;
> > }
> > }
>
>
> I'm worried that phydev->link_timeout may end up being left in an
> unknown state here. Are you expecting it to be 0? If so, I think it
> would be best to set it to 0 in an if clause.
Um.. I though about it when I wrote this, and to me it seems we
really don't use link_timeout with AUTONEG_DISABLED...
We use it for PHY_AN, PHY_FORCING && AUTONEG_SOFT, and
PHY_RESUMING && AUTONEG_ENABLED.
But as a matter of safety, I probably indeed add link_timeout
zeroing...
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* (unknown),
From: 内藤 賢司 @ 2008-02-22 17:50 UTC (permalink / raw)
To: netdev
majordomo@vger.kernel.org
^ permalink raw reply
* Re: [PATCH RFC] phylib: fix forced mode misbehaviour for aneg off case
From: Andy Fleming @ 2008-02-22 17:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev
In-Reply-To: <20080222155524.GA6623@localhost.localdomain>
On Feb 22, 2008, at 09:55, Anton Vorontsov wrote:
> When user disabled autonegotiation via ethtool, and no link is
> detected,
> phylib will place phy into forcing mode, and then will start calling
> phy_force_reduction(). This will break user expectations. For example,
> user asks for fixed speed 1000:
>
> ethtool -s eth0 autoneg off speed 1000
>
> Without link attached what will actually happen is:
>
> Trying 100/FULL
> Trying 100/HALF
> Trying 10/FULL
> Trying 10/HALF
> ...
The intent of phy_force_reduction() was to provide a fallback in case
the user unknowingly selects a speed that is not possible with the
current link partner. For instance, if you try to select gigabit on
a 100MB link, it wouldn't work, but because of the way the code was
designed, the phylib will find a link configuration that works.
However, I agree that it's not ideal to have the phylib spending a
lot of time looking for a link if there's not one there. On the
other hand, why is the user trying to force the link to a certain
speed if there's no link?
I'm not really opposed to it, though.
>
> This patch implements "software autonegotiation" that is equivalent to
> current behaviour, but enabled only when hardware autonegotiation was
> enabled and failed afterwards. With aneg disabled, phylib will not try
> other link setups.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> @@ -447,7 +451,8 @@ int phy_start_aneg(struct phy_device *phydev)
> phydev->link_timeout = PHY_AN_TIMEOUT;
> } else {
> phydev->state = PHY_FORCING;
> - phydev->link_timeout = PHY_FORCE_TIMEOUT;
> + if (AUTONEG_SOFT == phydev->autoneg)
> + phydev->link_timeout = PHY_FORCE_TIMEOUT;
> }
> }
I'm worried that phydev->link_timeout may end up being left in an
unknown state here. Are you expecting it to be 0? If so, I think it
would be best to set it to 0 in an if clause.
>
>
> @@ -904,7 +909,7 @@ static void phy_state_machine(struct
> work_struct *work)
> if (phydev->link) {
> phydev->state = PHY_RUNNING;
> netif_carrier_on(phydev->attached_dev);
> - } else {
> + } else if (AUTONEG_SOFT == phydev->autoneg) {
> if (0 == phydev->link_timeout--) {
> phy_force_reduction(phydev);
> needs_aneg = 1;
Especially since this will, I believe, leave link_timeout at -1
Andy
^ permalink raw reply
* Re: Marvell PHY driver fix
From: Andy Fleming @ 2008-02-22 17:25 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: netdev, Vitaly Bordug, Mark A. Greer
In-Reply-To: <20080222143409.GA1477@ru.mvista.com>
On Feb 22, 2008, at 08:34, Alexandr Smirnov wrote:
> Marvell PHY m88e1111 (not sure about other models, but think they
> too) works in
> two modes: fiber and copper. In Marvell PHY driver (that we have in
> current
> community kernels) code supported only copper mode, and this is not
> configurable,
> bits for copper mode are simply written in registers during PHY
> initialization. This patch adds support for both modes.
Excellent. I've known about this problem for a while, but haven't
been able to look into it.
However, some comments below
>
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
>
> diff -pruN powerpc.orig/drivers/net/phy/marvell.c powerpc/drivers/
> net/phy/marvell.c
> --- powerpc.orig/drivers/net/phy/marvell.c 2008-02-07
> 14:59:32.000000000 +0300
> +++ powerpc/drivers/net/phy/marvell.c 2008-02-19 21:47:34.000000000
> +0300
> @@ -58,9 +58,28 @@
>
> +#define MII_M1111_PHY_CR 0
> +#define MII_M1111_SOFTWARE_RESET 0x8000
You don't need to do this. There are already constants for both of
those values. That's a standard register.
>
>
> MODULE_DESCRIPTION("Marvell PHY driver");
> MODULE_AUTHOR("Andy Fleming");
> @@ -141,12 +160,22 @@ static int marvell_config_aneg(struct ph
> static int m88e1111_config_init(struct phy_device *phydev)
> {
> int err;
> + int temp;
> + int mode;
> +
> + /* Enable Fiber/Copper auto selection */
> + temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
> + temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
> + phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
> +
> + temp = phy_read(phydev, MII_M1111_PHY_CR);
> + temp |= MII_M1111_SOFTWARE_RESET;
> + phy_write(phydev, MII_M1111_PHY_CR, temp);
Use the standard constants from mii.h (MII_BMCR, and BMCR_RESET)
>
>
>
> temp &= ~(MII_M1111_HWCFG_MODE_MASK);
> - temp |= MII_M1111_HWCFG_MODE_RGMII;
> +
> + mode = phy_read(phydev, MII_M1111_PHY_EXT_CR);
> + mode = (mode & MII_M1111_HWCFG_FIBER_COPPER_RES) >> 13;
> +
> + switch (mode) {
> + case MII_M1111_COPPER:
> + temp |= MII_M1111_HWCFG_MODE_COPPER_RGMII;
> + break;
> + case MII_M1111_FIBER:
> + temp |= MII_M1111_HWCFG_MODE_FIBER_RGMII;
> + }
I think using a switch statement on a single bit is probably
overkill. Much clearer, I think, if you do:
mode = phy_read(phydev, MII_M1111_PHY_EXT_CR);
if (mode & MII_M1111_HWCFG_FIBER_COPPER_RES)
temp |= MII_M1111_HWCFG_MODE_FIBER_RGMII;
else
temp |= MII_M1111_HWCFG_MODE_COPPER_RGMII;
>
> +/* marvell_read_status
> + *
> + * Generic status code does not detect Fiber correctly!
After looking at the manual for the 88e1111, I think there may be a
way to continue using the generic code, rather than replicating the
generic code with slightly different values. It looks like the
problem isn't that Fiber disobeys the MIIM standard, but that it uses
a paging mechanism to determine whether it's the Fiber Status/Control
or the Copper Status/Control. Many of the registers exist in both
pages, but those two don't. However, based on this, it seems
reasonable to use the detected mode (fiber/copper) to determine
whether we should be operating out of page 0 or 1.
Could you try making sure that register 22[7:0] = 0x1 for fiber, and
see if you can then just use the standard genphy_read_status()?
Andy
^ permalink raw reply
* Re: 2.6.25-rc2-mm1 - several bugs and a crash
From: Paul E. McKenney @ 2008-02-22 17:09 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Patrick McHardy, Andrew Morton, linux-kernel, netdev,
netfilter-devel
In-Reply-To: <47BE1CE5.1030001@imap.cc>
On Fri, Feb 22, 2008 at 01:52:53AM +0100, Tilman Schmidt wrote:
> Am 22.02.2008 01:40 schrieb Tilman Schmidt:
> >>
> >> [NETFILTER]: nf_conntrack: fix smp_processor_id() in preemptible code warning
> >
> > Yes, it does; and the system also survives substantially longer.
> > (IOW, it hasn't crashed on me so far.)
>
> Which of course it did the second after I sent off that mail. :-(
> No message at all this time at the time of the crash, even though
> I had "tail -f /var/log/messages" running in an ssh session.
>
> So the nf_conntrack BUG is fixed, but the crash (and of course the
> swapper "spinlock bad magic" BUG) persists.
Do you have CONFIG_DEBUG_PREEMPT set? That would help find any other
bugs similar to nf_conntrack.
Thanx, Paul
^ permalink raw reply
* Re: lockdep warning
From: Jiri Kosina @ 2008-02-22 17:01 UTC (permalink / raw)
To: Anders Eriksson, davem; +Cc: linux-kernel, netdev
In-Reply-To: <20080222163213.5BDE293C12F@tippex.mynet.homeunix.org>
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> > > Any chance that
> > > git revert 69cc64d8d92
> > > makes this report go away?
> I've tested the patch and I no longer get that lock thing in my syslog.
Thanks for verification.
Hmm, I don't immediately see how this patch could make neigh->lock owner
to change between lock and unlock ... I have skimmed through the solicit
methods, and they don't seem to be doing anything nasty to neigh ...
The scenario I was thinking about is that before 69cc64d8d92, if any of
the _solicit methods could do anything bad to neigh struct, this warning
wouldn't trigger, because the lock has been dropped before calling
_solicit() and reacquired later, so no mismatch on ->current could happen,
but now as long as the lock is held during _solicit() call, this would
trigger on the next unlock.
But I am not able to see anything like that in the code. Dave, do you have
any idea? (the thread started at http://lkml.org/lkml/2008/2/22/105).
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: lockdep warning
From: Anders Eriksson @ 2008-02-22 16:32 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Anders Eriksson, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.64.0802221420250.30955@jikos.suse.cz>
jkosina@suse.cz said:
> > Any chance that
> > git revert 69cc64d8d92
> > makes this report go away?
I've tested the patch and I no longer get that lock thing in my syslog.
/A
^ permalink raw reply
* Re: [NETFILTER]: Introduce nf_inet_address
From: Patrick McHardy @ 2008-02-22 16:12 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Woodhouse, netdev, Jan Engelhardt, David S. Miller,
varekova, twoerner, Netfilter Development Mailinglist
In-Reply-To: <47BEF36F.1020802@netfilter.org>
Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> Pablo Neira Ayuso wrote:
>>> Patrick McHardy wrote:
>>>> Yes, that was a bug in the lastest release. We need to
>>>> release a 1.4.1 version or something like that, but I'm
>>>> not too familiar with the release process, so I haven't
>>>> done this so far.
>>> I can schedule one for this weekend, just send me an ACK.
>>
>> That would be great. I think we had another issue in 1.4.0 with
>> some header files, but I can't remeber the details.
>>
>> Jan, I recall we talked about this some time ago, do you remember?
>
> Was it related with kernel 2.4.x compilation?
Yes, I just found the old mail, the error was:
In file included from include/linux/netfilter/nf_nat.h:4,
from extensions/libipt_DNAT.c:9:
include/linux/netfilter/nf_conntrack_tuple.h:29: error: syntax error
before "__be32"
^ permalink raw reply
* Re: [NETFILTER]: Introduce nf_inet_address
From: Pablo Neira Ayuso @ 2008-02-22 16:08 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Woodhouse, netdev, Jan Engelhardt, David S. Miller,
varekova, twoerner, Netfilter Development Mailinglist
In-Reply-To: <47BEEDEF.5060503@trash.net>
Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>>> Yes, that was a bug in the lastest release. We need to
>>> release a 1.4.1 version or something like that, but I'm
>>> not too familiar with the release process, so I haven't
>>> done this so far.
>>
>> I can schedule one for this weekend, just send me an ACK.
>
>
> That would be great. I think we had another issue in 1.4.0 with
> some header files, but I can't remeber the details.
>
> Jan, I recall we talked about this some time ago, do you remember?
Was it related with kernel 2.4.x compilation?
--
"Los honestos son inadaptados sociales" -- Les Luthiers
^ permalink raw reply
* Re: [NETFILTER]: Introduce nf_inet_address
From: Jan Engelhardt @ 2008-02-22 16:03 UTC (permalink / raw)
To: Patrick McHardy
Cc: Pablo Neira Ayuso, David Woodhouse, netdev, David S. Miller,
varekova, twoerner, Netfilter Development Mailinglist
In-Reply-To: <47BEEDEF.5060503@trash.net>
On Feb 22 2008 16:44, Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>> > Yes, that was a bug in the lastest release. We need to
>> > release a 1.4.1 version or something like that, but I'm
>> > not too familiar with the release process, so I haven't
>> > done this so far.
>>
>> I can schedule one for this weekend, just send me an ACK.
>
>
> That would be great. I think we had another issue in 1.4.0 with
> some header files, but I can't remeber the details.
>
> Jan, I recall we talked about this some time ago, do you remember?
I dunno, in Xtables 1.5.1 all header problems (minus
the "uint32_t all" in nf_inet_addr) are resolved I believe.
The thing even compiles without a kernel source now.
^ permalink raw reply
* [PATCH RFC] phylib: fix forced mode misbehaviour for aneg off case
From: Anton Vorontsov @ 2008-02-22 15:55 UTC (permalink / raw)
To: netdev; +Cc: Andy Fleming
When user disabled autonegotiation via ethtool, and no link is detected,
phylib will place phy into forcing mode, and then will start calling
phy_force_reduction(). This will break user expectations. For example,
user asks for fixed speed 1000:
ethtool -s eth0 autoneg off speed 1000
Without link attached what will actually happen is:
Trying 100/FULL
Trying 100/HALF
Trying 10/FULL
Trying 10/HALF
...
This patch implements "software autonegotiation" that is equivalent to
current behaviour, but enabled only when hardware autonegotiation was
enabled and failed afterwards. With aneg disabled, phylib will not try
other link setups.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
This is of course post-2.6.25 material and highly RFC, as it changes
current behaviour. Please review carefully.
Thanks.
drivers/net/phy/phy.c | 19 ++++++++++++-------
include/linux/ethtool.h | 4 ++++
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 12fccb1..35ad91f 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -264,7 +264,8 @@ void phy_sanitize_settings(struct phy_device *phydev)
int idx;
/* Sanitize settings based on PHY capabilities */
- if ((features & SUPPORTED_Autoneg) == 0)
+ if ((features & SUPPORTED_Autoneg) == 0 &&
+ AUTONEG_SOFT != phydev->autoneg)
phydev->autoneg = AUTONEG_DISABLE;
idx = phy_find_valid(phy_find_setting(phydev->speed, phydev->duplex),
@@ -297,13 +298,15 @@ int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd)
cmd->advertising &= phydev->supported;
/* Verify the settings we care about. */
- if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE)
+ if (cmd->autoneg != AUTONEG_ENABLE &&
+ cmd->autoneg != AUTONEG_DISABLE &&
+ cmd->autoneg != AUTONEG_SOFT)
return -EINVAL;
if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0)
return -EINVAL;
- if (cmd->autoneg == AUTONEG_DISABLE
+ if ((cmd->autoneg == AUTONEG_DISABLE || cmd->autoneg == AUTONEG_SOFT)
&& ((cmd->speed != SPEED_1000
&& cmd->speed != SPEED_100
&& cmd->speed != SPEED_10)
@@ -433,7 +436,8 @@ int phy_start_aneg(struct phy_device *phydev)
mutex_lock(&phydev->lock);
- if (AUTONEG_DISABLE == phydev->autoneg)
+ if (AUTONEG_DISABLE == phydev->autoneg ||
+ AUTONEG_SOFT == phydev->autoneg)
phy_sanitize_settings(phydev);
err = phydev->drv->config_aneg(phydev);
@@ -447,7 +451,8 @@ int phy_start_aneg(struct phy_device *phydev)
phydev->link_timeout = PHY_AN_TIMEOUT;
} else {
phydev->state = PHY_FORCING;
- phydev->link_timeout = PHY_FORCE_TIMEOUT;
+ if (AUTONEG_SOFT == phydev->autoneg)
+ phydev->link_timeout = PHY_FORCE_TIMEOUT;
}
}
@@ -875,7 +880,7 @@ static void phy_state_machine(struct work_struct *work)
phydev->speed = settings[idx].speed;
phydev->duplex = settings[idx].duplex;
- phydev->autoneg = AUTONEG_DISABLE;
+ phydev->autoneg = AUTONEG_SOFT;
pr_info("Trying %d/%s\n", phydev->speed,
DUPLEX_FULL ==
@@ -904,7 +909,7 @@ static void phy_state_machine(struct work_struct *work)
if (phydev->link) {
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
- } else {
+ } else if (AUTONEG_SOFT == phydev->autoneg) {
if (0 == phydev->link_timeout--) {
phy_force_reduction(phydev);
needs_aneg = 1;
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index fcbe8b6..446f78b 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -517,6 +517,10 @@ struct ethtool_ops {
*/
#define AUTONEG_DISABLE 0x00
#define AUTONEG_ENABLE 0x01
+/* "Software autonegotiation": will try several link variants in this
+ * order -- 1000/FULL, 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF.
+ */
+#define AUTONEG_SOFT 0x02
/* Wake-On-Lan options. */
#define WAKE_PHY (1 << 0)
--
1.5.2.2
^ permalink raw reply related
* Re: [NETFILTER]: Introduce nf_inet_address
From: Patrick McHardy @ 2008-02-22 15:44 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Woodhouse, netdev, Jan Engelhardt, David S. Miller,
varekova, twoerner, Netfilter Development Mailinglist
In-Reply-To: <47BEEC5C.4060201@netfilter.org>
Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> Yes, that was a bug in the lastest release. We need to
>> release a 1.4.1 version or something like that, but I'm
>> not too familiar with the release process, so I haven't
>> done this so far.
>
> I can schedule one for this weekend, just send me an ACK.
That would be great. I think we had another issue in 1.4.0 with
some header files, but I can't remeber the details.
Jan, I recall we talked about this some time ago, do you remember?
^ permalink raw reply
* Re: [NETFILTER]: Introduce nf_inet_address
From: Pablo Neira Ayuso @ 2008-02-22 15:38 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Woodhouse, netdev, Jan Engelhardt, David S. Miller,
varekova, twoerner, Netfilter Development Mailinglist
In-Reply-To: <47BEE31D.7020003@trash.net>
Patrick McHardy wrote:
> Yes, that was a bug in the lastest release. We need to
> release a 1.4.1 version or something like that, but I'm
> not too familiar with the release process, so I haven't
> done this so far.
I can schedule one for this weekend, just send me an ACK.
--
"Los honestos son inadaptados sociales" -- Les Luthiers
^ permalink raw reply
* Marvell PHY driver fix
From: Alexandr Smirnov @ 2008-02-22 14:34 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, afleming, vbordug, mgreer
Marvell PHY m88e1111 (not sure about other models, but think they too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in current
community kernels) code supported only copper mode, and this is not configurable,
bits for copper mode are simply written in registers during PHY
initialization. This patch adds support for both modes.
Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
diff -pruN powerpc.orig/drivers/net/phy/marvell.c powerpc/drivers/net/phy/marvell.c
--- powerpc.orig/drivers/net/phy/marvell.c 2008-02-07 14:59:32.000000000 +0300
+++ powerpc/drivers/net/phy/marvell.c 2008-02-19 21:47:34.000000000 +0300
@@ -58,9 +58,28 @@
#define MII_M1111_RX_DELAY 0x80
#define MII_M1111_TX_DELAY 0x2
#define MII_M1111_PHY_EXT_SR 0x1b
-#define MII_M1111_HWCFG_MODE_MASK 0xf
-#define MII_M1111_HWCFG_MODE_RGMII 0xb
+
+#define MII_M1111_HWCFG_MODE_MASK 0xf
+#define MII_M1111_HWCFG_MODE_COPPER_RGMII 0xb
+#define MII_M1111_HWCFG_MODE_FIBER_RGMII 0x3
#define MII_M1111_HWCFG_MODE_SGMII_NO_CLK 0x4
+#define MII_M1111_HWCFG_FIBER_COPPER_AUTO 0x8000
+#define MII_M1111_HWCFG_FIBER_COPPER_RES 0x2000
+
+#define MII_M1111_PHY_CR 0
+#define MII_M1111_SOFTWARE_RESET 0x8000
+
+#define MII_M1111_COPPER 0
+#define MII_M1111_FIBER 1
+
+#define MII_M1011_PHY_STATUS 0x11
+#define MII_M1011_PHY_STATUS_1000 0x8000
+#define MII_M1011_PHY_STATUS_100 0x4000
+#define MII_M1011_PHY_STATUS_SPD_MASK 0xc000
+#define MII_M1011_PHY_STATUS_FULLDUPLEX 0x2000
+#define MII_M1011_PHY_STATUS_RESOLVED 0x0800
+#define MII_M1011_PHY_STATUS_LINK 0x0400
+
MODULE_DESCRIPTION("Marvell PHY driver");
MODULE_AUTHOR("Andy Fleming");
@@ -141,12 +160,22 @@ static int marvell_config_aneg(struct ph
static int m88e1111_config_init(struct phy_device *phydev)
{
int err;
+ int temp;
+ int mode;
+
+ /* Enable Fiber/Copper auto selection */
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
+ temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
+ phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
+
+ temp = phy_read(phydev, MII_M1111_PHY_CR);
+ temp |= MII_M1111_SOFTWARE_RESET;
+ phy_write(phydev, MII_M1111_PHY_CR, temp);
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
- int temp;
temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
if (temp < 0)
@@ -171,7 +200,17 @@ static int m88e1111_config_init(struct p
return temp;
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
- temp |= MII_M1111_HWCFG_MODE_RGMII;
+
+ mode = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ mode = (mode & MII_M1111_HWCFG_FIBER_COPPER_RES) >> 13;
+
+ switch (mode) {
+ case MII_M1111_COPPER:
+ temp |= MII_M1111_HWCFG_MODE_COPPER_RGMII;
+ break;
+ case MII_M1111_FIBER:
+ temp |= MII_M1111_HWCFG_MODE_FIBER_RGMII;
+ }
err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
if (err < 0)
@@ -262,6 +301,93 @@ static int m88e1145_config_init(struct p
return 0;
}
+/* marvell_read_status
+ *
+ * Generic status code does not detect Fiber correctly!
+ * Description:
+ * Check the link, then figure out the current state
+ * by comparing what we advertise with what the link partner
+ * advertises. Start by checking the gigabit possibilities,
+ * then move on to 10/100.
+ */
+static int marvell_read_status(struct phy_device *phydev)
+{
+ int adv;
+ int err;
+ int lpa;
+ int status = 0;
+
+ /* Update the link, but return if there
+ * was an error */
+ err = genphy_update_link(phydev);
+ if (err)
+ return err;
+
+ if (AUTONEG_ENABLE == phydev->autoneg) {
+ status = phy_read(phydev, MII_M1011_PHY_STATUS);
+ if (status < 0)
+ return status;
+
+ lpa = phy_read(phydev, MII_LPA);
+ if (lpa < 0)
+ return lpa;
+
+ adv = phy_read(phydev, MII_ADVERTISE);
+ if (adv < 0)
+ return adv;
+
+ lpa &= adv;
+
+ if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ status = status & MII_M1011_PHY_STATUS_SPD_MASK;
+ phydev->pause = phydev->asym_pause = 0;
+
+ switch (status) {
+ case MII_M1011_PHY_STATUS_1000:
+ phydev->speed = SPEED_1000;
+ break;
+
+ case MII_M1011_PHY_STATUS_100:
+ phydev->speed = SPEED_100;
+ break;
+
+ default:
+ phydev->speed = SPEED_10;
+ break;
+ }
+
+ if (phydev->duplex == DUPLEX_FULL) {
+ phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
+ phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
+ }
+ } else {
+ int bmcr = phy_read(phydev, MII_BMCR);
+
+ if (bmcr < 0)
+ return bmcr;
+
+ if (bmcr & BMCR_FULLDPLX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ if (bmcr & BMCR_SPEED1000)
+ phydev->speed = SPEED_1000;
+ else if (bmcr & BMCR_SPEED100)
+ phydev->speed = SPEED_100;
+ else
+ phydev->speed = SPEED_10;
+
+ phydev->pause = phydev->asym_pause = 0;
+ }
+
+ return 0;
+}
+
static struct phy_driver marvell_drivers[] = {
{
.phy_id = 0x01410c60,
@@ -296,7 +422,7 @@ static struct phy_driver marvell_drivers
.flags = PHY_HAS_INTERRUPT,
.config_init = &m88e1111_config_init,
.config_aneg = &marvell_config_aneg,
- .read_status = &genphy_read_status,
+ .read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.driver = { .owner = THIS_MODULE },
^ permalink raw reply
* [PATCH] ssb: Add CHIPCO IRQ access functions
From: Michael Buesch @ 2008-02-22 15:14 UTC (permalink / raw)
To: John Linville; +Cc: netdev, Aurelien Jarno
From: Aurelien Jarno <aurelien@aurel32.net>
This patch adds functions to setup and read the CHIPCO IRQ.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
For 2.6.26.
drivers/ssb/driver_chipcommon.c | 10 ++++++++++
include/linux/ssb/ssb_driver_chipcommon.h | 4 ++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/ssb/driver_chipcommon.c b/drivers/ssb/driver_chipcommon.c
index e586321..45b672a 100644
--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -353,6 +353,16 @@ void ssb_chipco_watchdog_timer_set(struct ssb_chipcommon *cc, u32 ticks)
chipco_write32(cc, SSB_CHIPCO_WATCHDOG, ticks);
}
+void ssb_chipco_irq_mask(struct ssb_chipcommon *cc, u32 mask, u32 value)
+{
+ chipco_write32_masked(cc, SSB_CHIPCO_IRQMASK, mask, value);
+}
+
+u32 ssb_chipco_irq_status(struct ssb_chipcommon *cc, u32 mask)
+{
+ return chipco_read32(cc, SSB_CHIPCO_IRQSTAT) & mask;
+}
+
u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask)
{
return chipco_read32(cc, SSB_CHIPCO_GPIOIN) & mask;
diff --git a/include/linux/ssb/ssb_driver_chipcommon.h b/include/linux/ssb/ssb_driver_chipcommon.h
index 536851b..b548a54 100644
--- a/include/linux/ssb/ssb_driver_chipcommon.h
+++ b/include/linux/ssb/ssb_driver_chipcommon.h
@@ -390,6 +390,10 @@ extern void ssb_chipco_set_clockmode(struct ssb_chipcommon *cc,
extern void ssb_chipco_watchdog_timer_set(struct ssb_chipcommon *cc,
u32 ticks);
+void ssb_chipco_irq_mask(struct ssb_chipcommon *cc, u32 mask, u32 value);
+
+u32 ssb_chipco_irq_status(struct ssb_chipcommon *cc, u32 mask);
+
/* Chipcommon GPIO pin access. */
u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask);
u32 ssb_chipco_gpio_out(struct ssb_chipcommon *cc, u32 mask, u32 value);
--
1.5.4.1
--
Greetings Michael.
^ permalink raw reply related
* Re: [NETFILTER]: Introduce nf_inet_address
From: Patrick McHardy @ 2008-02-22 14:59 UTC (permalink / raw)
To: David Woodhouse
Cc: netdev, Jan Engelhardt, David S. Miller, varekova, twoerner,
Netfilter Development Mailinglist
In-Reply-To: <1203667290.5771.38.camel@shinybook.infradead.org>
David Woodhouse wrote:
> On Fri, 2008-02-22 at 16:52 +0900, David Woodhouse wrote:
>> It looks like iptables is fairly broken anyway:
>>
>> make[1]: Entering directory
>> `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
>> Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
>
> And if I move away the contents of the local include/linux/ directory
> and replace it with proper headers generated by 'make
> headers_install' (which won't be trying to include compiler.h), then I
> get more failures:
>
> Unable to resolve dependency on ../include/linux/netfilter/xt_u32.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter/xt_time.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter/xt_quota.h. Try 'make clean'.
> Unable to resolve dependency on ../include/linux/netfilter/xt_connlimit.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter_ipv6/ip6t_mh.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter/nf_nat.h. Try 'make clean'.
Yes, the dependency tracking has always been a bit strange/broken.
The next release will use autoconf, which will hopefully behave
better.
^ permalink raw reply
* Re: [NETFILTER]: Introduce nf_inet_address
From: Patrick McHardy @ 2008-02-22 14:58 UTC (permalink / raw)
To: David Woodhouse
Cc: netdev, Jan Engelhardt, David S. Miller, varekova, twoerner,
Netfilter Development Mailinglist
In-Reply-To: <1203666762.5771.35.camel@shinybook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
David Woodhouse wrote:
> On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
>> That would break iptables compilation, which already includes
>> linux/in.h in some files. I guess the best fix for now is to
>> include netinet/in.h in busybox and long-term clean this up
>> properly.
>
> It looks like iptables is fairly broken anyway:
>
> make[1]: Entering directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
> Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
> Extensions found:
> make[1]: Leaving directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
> error: Bad exit status from /var/tmp/rpm-tmp.32057 (%build)
Yes, that was a bug in the lastest release. We need to
release a 1.4.1 version or something like that, but I'm
not too familiar with the release process, so I haven't
done this so far.
Anyway, I just committed this patch to iptables to remove
the compiler.h inclusions.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1192 bytes --]
Index: include/linux/netfilter_ipv6/ip6_tables.h
===================================================================
--- include/linux/netfilter_ipv6/ip6_tables.h (Revision 7376)
+++ include/linux/netfilter_ipv6/ip6_tables.h (Arbeitskopie)
@@ -15,7 +15,6 @@
#ifndef _IP6_TABLES_H
#define _IP6_TABLES_H
-#include <linux/compiler.h>
#include <linux/netfilter_ipv6.h>
#include <linux/netfilter/x_tables.h>
Index: include/linux/netfilter.h
===================================================================
--- include/linux/netfilter.h (Revision 7376)
+++ include/linux/netfilter.h (Arbeitskopie)
@@ -1,8 +1,6 @@
#ifndef __LINUX_NETFILTER_H
#define __LINUX_NETFILTER_H
-#include <linux/compiler.h>
-
/* Responses from hook functions. */
#define NF_DROP 0
#define NF_ACCEPT 1
Index: include/linux/netfilter_ipv4/ip_tables.h
===================================================================
--- include/linux/netfilter_ipv4/ip_tables.h (Revision 7376)
+++ include/linux/netfilter_ipv4/ip_tables.h (Arbeitskopie)
@@ -15,7 +15,6 @@
#ifndef _IPTABLES_H
#define _IPTABLES_H
-#include <linux/compiler.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netfilter/x_tables.h>
^ 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