| Message ID | 1232395910.13386.4.camel@brick |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, 2009-01-19 at 12:12 -0800, Harvey Harrison wrote: > It looks like the locking is OK as the locks were being taken before the > various phy setup functions, add the annotations as they release and > reacquire the phy_lock. > > Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> > --- Whoops, bnx2 != bnx2x....that driver needs serious help in the endianess department, but it doesn't actually lok to hard to sort out as it seems most of the warnings come about as the hardware structs are just not annotated, but the correct accessors seem to be in place in the code. In addition, there are piles of macros in the driver that really shouldn't be. I'll have a look this afternoon at some of the low-hanging fruit. Harvey -- 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
From: Harvey Harrison <harvey.harrison@gmail.com> Date: Mon, 19 Jan 2009 12:11:50 -0800 > It looks like the locking is OK as the locks were being taken before the > various phy setup functions, add the annotations as they release and > reacquire the phy_lock. > > Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Queued up for 2.6.30, thanks Harvey. -- 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
On Mon, 2009-01-19 at 12:29 -0800, Harvey Harrison wrote: [...] > Whoops, bnx2 != bnx2x....that driver needs serious help in the endianess > department, but it doesn't actually lok to hard to sort out as it seems > most of the warnings come about as the hardware structs are just not > annotated, but the correct accessors seem to be in place in the code. > > In addition, there are piles of macros in the driver that really shouldn't > be. I'll have a look this afternoon at some of the low-hanging fruit. > > Harvey Thanks Harvey, I appreciate the help Eilon -- 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
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c index d4a3dac..d86a8f2 100644 --- a/drivers/net/bnx2.c +++ b/drivers/net/bnx2.c @@ -1497,6 +1497,8 @@ static int bnx2_fw_sync(struct bnx2 *, u32, int, int); static int bnx2_setup_remote_phy(struct bnx2 *bp, u8 port) +__releases(&bp->phy_lock) +__acquires(&bp->phy_lock) { u32 speed_arg = 0, pause_adv; @@ -1554,6 +1556,8 @@ bnx2_setup_remote_phy(struct bnx2 *bp, u8 port) static int bnx2_setup_serdes_phy(struct bnx2 *bp, u8 port) +__releases(&bp->phy_lock) +__acquires(&bp->phy_lock) { u32 adv, bmcr; u32 new_adv = 0; @@ -1866,6 +1870,8 @@ bnx2_set_remote_link(struct bnx2 *bp) static int bnx2_setup_copper_phy(struct bnx2 *bp) +__releases(&bp->phy_lock) +__acquires(&bp->phy_lock) { u32 bmcr; u32 new_bmcr; @@ -1963,6 +1969,8 @@ bnx2_setup_copper_phy(struct bnx2 *bp) static int bnx2_setup_phy(struct bnx2 *bp, u8 port) +__releases(&bp->phy_lock) +__acquires(&bp->phy_lock) { if (bp->loopback == MAC_LOOPBACK) return 0; @@ -2176,6 +2184,8 @@ bnx2_init_copper_phy(struct bnx2 *bp, int reset_phy) static int bnx2_init_phy(struct bnx2 *bp, int reset_phy) +__releases(&bp->phy_lock) +__acquires(&bp->phy_lock) { u32 val; int rc = 0;
It looks like the locking is OK as the locks were being taken before the various phy setup functions, add the annotations as they release and reacquire the phy_lock. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- drivers/net/bnx2.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)