* Re: softirq warnings when calling dev_kfree_skb_irq - bug in conntrack?
From: Jeremy Fitzhardinge @ 2010-08-03 19:16 UTC (permalink / raw)
To: David Miller
Cc: johannes, netdev, dongxiao.xu, Xen-devel, Ian.Campbell, kaber,
eric.dumazet
In-Reply-To: <20100803.002318.209965574.davem@davemloft.net>
On 08/03/2010 12:23 AM, David Miller wrote:
> From: Johannes Berg<johannes@sipsolutions.net>
> Date: Tue, 03 Aug 2010 09:04:34 +0200
>
>> I had this too:
>> http://article.gmane.org/gmane.linux.network/167590
>>
>> But I'm not convinced it's conntrack, I'd think it's
>>
>> commit 15e83ed78864d0625e87a85f09b297c0919a4797
>> Author: Eric Dumazet<eric.dumazet@gmail.com>
>> Date: Wed May 19 23:16:03 2010 +0000
>>
>> net: remove zap_completion_queue
>>
>> which, from the looks of it, ought to be reverted because it failed to
>> take into account that dev_kfree_skb() can do more things that require
>> non-irq-context than just calling skb->destructor, like for instance the
>> conntrack thing we see here.
> Agreed. I'll revert this and queue that up for 2.6.35-stable
Reverting this change fixes the problem for me.
Thanks,
J
^ permalink raw reply
* Re: sunrpc: what prevents an xprt from being freed before task_cleanup runs?
From: J. Bruce Fields @ 2010-08-03 19:18 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Jeff Layton, linux-nfs, netdev
In-Reply-To: <1280861775.12283.7.camel@heimdal.trondhjem.org>
On Tue, Aug 03, 2010 at 02:56:15PM -0400, Trond Myklebust wrote:
> On Tue, 2010-08-03 at 14:48 -0400, J. Bruce Fields wrote:
> > On Tue, Aug 03, 2010 at 02:40:15PM -0400, Trond Myklebust wrote:
> > > On Tue, 2010-08-03 at 13:24 -0400, Jeff Layton wrote:
> > > > We got a report recently about a panic in RHEL5 (2.6.18 based kernel).
> > > > The problem appears to be that a task_cleanup workqueue job ran and got
> > > > passed a pointer to an xprt that had been freed. The bug is here in
> > > > case anyone is interested in the details:
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=611938
> > > >
> > > > The situation seems to be pretty difficult to reproduce, but I don't
> > > > see anything that's intended to ensure that this doesn't occur in RHEL5
> > > > or mainline. The task_cleanup workqueue job doesn't hold a reference to
> > > > the xprt, and the job isn't canceled when the xprt is torn down.
> > > >
> > > > Bruce had a look and suggested that we may need something like the
> > > > patch below (pasted in, so it probably won't apply correctly). I've
> > > > tested a backported version of it on RHEL5 and it seems to work fine.
> > > >
> > > > Is it reasonable to cancel task_cleanup when destroying the xprt? Or,
> > > > am I missing something that should prevent this situation in mainline
> > > > (and perhaps isn't in RHEL5's kernel).
> > > >
> > > > Any help is appreciated...
> > > >
> > > > -----------------------------[snip]---------------------------------
> > > > diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> > > > index dcd0132..2a1f664 100644
> > > > --- a/net/sunrpc/xprt.c
> > > > +++ b/net/sunrpc/xprt.c
> > > > @@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
> > > > rpc_destroy_wait_queue(&xprt->sending);
> > > > rpc_destroy_wait_queue(&xprt->resend);
> > > > rpc_destroy_wait_queue(&xprt->backlog);
> > > > + cancel_work_sync(&xprt->task_cleanup);
> > > > /*
> > > > * Tear down transport state and free the rpc_xprt
> > > > */
> > > > -----------------------------[snip]---------------------------------
> > > >
> > > > Thanks,
> > >
> > > How about doing a wait_on_bit_lock(&xprt->state, XPRT_LOCKED,...)
> > > instead?
> >
> > I'll believe you, but I don't get it: what guarantees that XPRT_LOCKED
> > isn't cleared while xprt_autoclose autoclose is still running?
>
> Look more closely: the callers that enqueue task_cleanup on the
> workqueue all ensure that XPRT_LOCKED is held, and it isn't released
> until the call to xprt_release_write() at the very end of
> xprt_autoclose().
I see that (assuming snd_task is always NULL--but, OK, I think I see why
that's true), but we still dereference the xprt after returning from
xprt_release_write(). Only to drop the transport_lock, but I don't see
why there isn't a race.
> The rpciod_workqueue deadlocking is an issue, though, so unfortunately,
> we won't be able to make use of the above.
Yeah, OK, it was just bugging me that I didn't feel like I understood
how XPRT_LOCKED is used.
--b.
^ permalink raw reply
* [PATCH net-next] drivers/net/enic: Use %pUB to format a UUID
From: Joe Perches @ 2010-08-03 19:32 UTC (permalink / raw)
To: Scott Feldman; +Cc: netdev, linux-kernel
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/enic/enic_main.c | 17 ++---------------
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 77a7f87..9aab853 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1087,10 +1087,7 @@ static int enic_set_port_profile(struct enic *enic, u8 *mac)
{
struct vic_provinfo *vp;
u8 oui[3] = VIC_PROVINFO_CISCO_OUI;
- u8 *uuid;
char uuid_str[38];
- static char *uuid_fmt = "%02X%02X%02X%02X-%02X%02X-%02X%02X-"
- "%02X%02X-%02X%02X%02X%02X%0X%02X";
int err;
err = enic_vnic_dev_deinit(enic);
@@ -1121,24 +1118,14 @@ static int enic_set_port_profile(struct enic *enic, u8 *mac)
ETH_ALEN, mac);
if (enic->pp.set & ENIC_SET_INSTANCE) {
- uuid = enic->pp.instance_uuid;
- sprintf(uuid_str, uuid_fmt,
- uuid[0], uuid[1], uuid[2], uuid[3],
- uuid[4], uuid[5], uuid[6], uuid[7],
- uuid[8], uuid[9], uuid[10], uuid[11],
- uuid[12], uuid[13], uuid[14], uuid[15]);
+ sprintf(uuid_str, "%pUB", enic->pp.instance_uuid);
vic_provinfo_add_tlv(vp,
VIC_LINUX_PROV_TLV_CLIENT_UUID_STR,
sizeof(uuid_str), uuid_str);
}
if (enic->pp.set & ENIC_SET_HOST) {
- uuid = enic->pp.host_uuid;
- sprintf(uuid_str, uuid_fmt,
- uuid[0], uuid[1], uuid[2], uuid[3],
- uuid[4], uuid[5], uuid[6], uuid[7],
- uuid[8], uuid[9], uuid[10], uuid[11],
- uuid[12], uuid[13], uuid[14], uuid[15]);
+ sprintf(uuid_str, "%pUB", enic->pp.host_uuid);
vic_provinfo_add_tlv(vp,
VIC_LINUX_PROV_TLV_HOST_UUID_STR,
sizeof(uuid_str), uuid_str);
^ permalink raw reply related
* Re: [Bugme-new] [Bug 16503] New: Upgrade to 2.6.34.2 breaks ethernet network
From: Andrew Morton @ 2010-08-03 20:27 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, Gary Zambrano, stable,
davemorgan353
In-Reply-To: <bug-16503-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 3 Aug 2010 20:14:34 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16503
>
> Summary: Upgrade to 2.6.34.2 breaks ethernet network
> Product: Networking
> Version: 2.5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: davemorgan353@btinternet.com
> Regression: No
>
>
> Using Arch Linux with fully up-to-date system.
>
> Upgrading kernel from 2.6.34.1 to 2.6.34.2 breaks my ethernet connection. I
> get dhcp timeouts but no errors in the logs regarding the kernel or the card.
>
> Dell Inspiron 1720.
>
> 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev
> 02)
>
> Downgrading the kernel fixes the issue.
>
There are no changes to b44.c in patch-2.6.34.2. Perhaps you could
generate the dmesg logs for 2.6.34.1 and 2.6.34.2 and run `diff -u'
against them, see if anything interesting pops out?
^ permalink raw reply
* [PATCH] SUNRPC: prevent task_cleanup running on freed xprt
From: J. Bruce Fields @ 2010-08-03 21:22 UTC (permalink / raw)
To: Trond Myklebust
Cc: Jeff Layton, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1280861363.12283.2.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
From: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
We saw a report of a NULL dereference in xprt_autoclose:
https://bugzilla.redhat.com/show_bug.cgi?id=611938
This appears to be the result of an xprt's task_cleanup running after
the xprt is destroyed. Nothing in the current code appears to prevent
that.
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
net/sunrpc/xprt.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
On Tue, Aug 03, 2010 at 02:49:23PM -0400, Trond Myklebust wrote:
> Hmm... On the other hand, since xprt_destroy() may get called from
> inside the rpciod_workqueue, the wait_on_bit_lock() may end up
> deadlocking.
>
> Nevermind, then. Let's go with the cancel_work_sync().
Here you are--only if you don't have something equivalent already queued
up.--b.
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index dcd0132..2a1f664 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1129,6 +1129,7 @@ static void xprt_destroy(struct kref *kref)
rpc_destroy_wait_queue(&xprt->sending);
rpc_destroy_wait_queue(&xprt->resend);
rpc_destroy_wait_queue(&xprt->backlog);
+ cancel_work_sync(&xprt->task_cleanup);
/*
* Tear down transport state and free the rpc_xprt
*/
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] SUNRPC: prevent task_cleanup running on freed xprt
From: Trond Myklebust @ 2010-08-03 21:32 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Jeff Layton, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100803212220.GI31579-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Tue, 2010-08-03 at 17:22 -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> We saw a report of a NULL dereference in xprt_autoclose:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=611938
>
> This appears to be the result of an xprt's task_cleanup running after
> the xprt is destroyed. Nothing in the current code appears to prevent
> that.
>
> Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
Thanks. Applied to nfs-for-2.6.36...
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-next-2.6 PATCH] e1000e: correct MAC-PHY interconnect register offset for 82579
From: Jeff Kirsher @ 2010-08-03 21:48 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
From: Bruce Allan <bruce.w.allan@intel.com>
The MAC-PHY interconnect register set on ICH/PCH parts is accessed through
a peephole mechanism by writing an offset to a CSR register. The offset
for the interconnect's half-duplex control register (which is used in a
jumbo frame workaround for 82579) is incorrect.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/hw.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
index a419b07..66ed08f 100644
--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -313,7 +313,7 @@ enum e1e_registers {
#define E1000_KMRNCTRLSTA_DIAG_NELPBK 0x1000 /* Nearend Loopback mode */
#define E1000_KMRNCTRLSTA_K1_CONFIG 0x7
#define E1000_KMRNCTRLSTA_K1_ENABLE 0x0002
-#define E1000_KMRNCTRLSTA_HD_CTRL 0x0002
+#define E1000_KMRNCTRLSTA_HD_CTRL 0x10 /* Kumeran HD Control */
#define IFE_PHY_EXTENDED_STATUS_CONTROL 0x10
#define IFE_PHY_SPECIAL_CONTROL 0x11 /* 100BaseTx PHY Special Control */
^ permalink raw reply related
* [net-next-2.6 PATCH] igb: Program MDICNFG register prior to PHY init
From: Jeff Kirsher @ 2010-08-03 21:50 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch addresses an issue seen on 82580 in which the MDICNFG
register will be reset during a single function reset and as a
result we will be unable to communicate with the PHY. To correct
the issue, added a call to reset_mdicnfg just prior to the first
access of the MDICNFG register in sgnii_uses_mdio.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/e1000_82575.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/igb/e1000_82575.c b/drivers/net/igb/e1000_82575.c
index cc58227..187622f 100644
--- a/drivers/net/igb/e1000_82575.c
+++ b/drivers/net/igb/e1000_82575.c
@@ -63,6 +63,7 @@ static bool igb_sgmii_active_82575(struct e1000_hw *);
static s32 igb_reset_init_script_82575(struct e1000_hw *);
static s32 igb_read_mac_addr_82575(struct e1000_hw *);
static s32 igb_set_pcie_completion_timeout(struct e1000_hw *hw);
+static s32 igb_reset_mdicnfg_82580(struct e1000_hw *hw);
static const u16 e1000_82580_rxpbs_table[] =
{ 36, 72, 144, 1, 2, 4, 8, 16,
@@ -159,20 +160,15 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
switch (ctrl_ext & E1000_CTRL_EXT_LINK_MODE_MASK) {
case E1000_CTRL_EXT_LINK_MODE_SGMII:
dev_spec->sgmii_active = true;
- ctrl_ext |= E1000_CTRL_I2C_ENA;
break;
case E1000_CTRL_EXT_LINK_MODE_1000BASE_KX:
case E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES:
hw->phy.media_type = e1000_media_type_internal_serdes;
- ctrl_ext |= E1000_CTRL_I2C_ENA;
break;
default:
- ctrl_ext &= ~E1000_CTRL_I2C_ENA;
break;
}
- wr32(E1000_CTRL_EXT, ctrl_ext);
-
/* Set mta register count */
mac->mta_reg_count = 128;
/* Set rar entry count */
@@ -250,11 +246,19 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
phy->autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
phy->reset_delay_us = 100;
+ ctrl_ext = rd32(E1000_CTRL_EXT);
+
/* PHY function pointers */
- if (igb_sgmii_active_82575(hw))
+ if (igb_sgmii_active_82575(hw)) {
phy->ops.reset = igb_phy_hw_reset_sgmii_82575;
- else
+ ctrl_ext |= E1000_CTRL_I2C_ENA;
+ } else {
phy->ops.reset = igb_phy_hw_reset;
+ ctrl_ext &= ~E1000_CTRL_I2C_ENA;
+ }
+
+ wr32(E1000_CTRL_EXT, ctrl_ext);
+ igb_reset_mdicnfg_82580(hw);
if (igb_sgmii_active_82575(hw) && !igb_sgmii_uses_mdio_82575(hw)) {
phy->ops.read_reg = igb_read_phy_reg_sgmii_82575;
^ permalink raw reply related
* Re: [PATCH] ixgbe: ixgbe_fcoe build break
From: Jeff Kirsher @ 2010-08-03 21:55 UTC (permalink / raw)
To: Jon Mason
Cc: Jesse Brandeburg, Bruce Allan, Alex Duyck, PJ Waskiewicz,
John Ronciak, David Miller, netdev, e1000-devel
In-Reply-To: <1280851078-4263-1-git-send-email-jon.mason@exar.com>
On Tue, Aug 3, 2010 at 08:57, Jon Mason <jon.mason@exar.com> wrote:
> struct ixgbe_fcoe has fields that are #ifdef'ed with CONFIG_IXGBE_DCB.
> However, not all references to those fields check for CONFIG_IXGBE_DCB.
> This patch adds the necessary check to allow for ixgbe to compile.
>
> Signed-off-by: Jon Mason <jon.mason@exar.com>
> ---
> drivers/net/ixgbe/ixgbe_main.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index 7d6a415..9ec3dfe 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -6155,9 +6155,11 @@ static u16 ixgbe_select_queue(struct net_device *dev, struct sk_buff *skb)
> txq &= (adapter->ring_feature[RING_F_FCOE].indices - 1);
> txq += adapter->ring_feature[RING_F_FCOE].mask;
> return txq;
> +#ifdef CONFIG_IXGBE_DCB
> } else if (adapter->flags & IXGBE_FLAG_DCB_ENABLED) {
> txq = adapter->fcoe.up;
> return txq;
> +#endif
> }
> }
> #endif
> @@ -6218,8 +6220,10 @@ static netdev_tx_t ixgbe_xmit_frame(struct sk_buff *skb,
> skb->protocol == htons(ETH_P_FIP))) {
> tx_flags &= ~(IXGBE_TX_FLAGS_VLAN_PRIO_MASK
> << IXGBE_TX_FLAGS_VLAN_SHIFT);
> +#ifdef CONFIG_IXGBE_DCB
> tx_flags |= ((adapter->fcoe.up << 13)
> << IXGBE_TX_FLAGS_VLAN_SHIFT);
> +#endif
> /* flag for FCoE offloads */
> if (skb->protocol == htons(ETH_P_FCOE))
> tx_flags |= IXGBE_TX_FLAGS_FCOE;
> --
Thanks Jon. I think I may already have a patch in my queue with this
fix, but if I do not, I make sure to add your patch.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH v3 1/2] core: Factor out flow calculation from get_rps_cpu
From: Sridhar Samudrala @ 2010-08-03 22:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Changli Gao, Krishna Kumar2, bhutchings, davem, mst, netdev,
therbert
In-Reply-To: <201008031032.16138.arnd@arndb.de>
On Tue, 2010-08-03 at 10:32 +0200, Arnd Bergmann wrote:
> On Tuesday 03 August 2010, Changli Gao wrote:
> > > I am confused by the call sites of macvlan_dev.receive and
> > > macvlan_dev.forward. They both are possible to be called in both
> > > RX(skb->data points to network header) and TX(skb->data points to
> > > ethernet) paths. The current code in macvtap shows that
> > > macvlan_dev.receive should be called in network layer, and
> > > macvlan_dev.forward should be called in dev layer. Am I correct?
> > >
> >
> > After checking the code carefully, I find macvlan_dev.receive is
> > called in network layer(RX path), and macvlan_dev.forward is called in
> > dev layer(TX path). The current code hasn't any issue. Your solution
> > won't work, as macvtap_forward is called in dev layer, when skb->data
> > points to ethernet header already.
>
> Yes, that is correct. Forward is used for "bridge" mode, where we
> can send data between two macvlan/macvtap endpoints directly, as
> opposed to the default "vepa" mode, where all data is always sent
> out to the lowerdev and may be returned by an adjacent switch in
> hairpin configuration.
macvtap_forward() is also used in the normal receive path as
macvtap_receive() has a direct call to macvtap_forward() after
updating skb->data to point to the ethernet header.
Thanks
Sridhar
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: David Miller @ 2010-08-03 23:28 UTC (permalink / raw)
To: socketcan
Cc: patrick.ohly, eric.dumazet, netdev, socketcan-core,
matthias.fuchs
In-Reply-To: <4C5856E3.3070606@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Tue, 03 Aug 2010 19:50:27 +0200
> On 03.08.2010 19:33, Patrick Ohly wrote:
>> On Tue, 2010-08-03 at 10:11 -0700, Oliver Hartkopp wrote:
>>>> I'm fine with using a simple u8. I'm not sure where I picked up the
>>>> union thing, it's not something that I usually do in my own code.
>>>>
>>>
>>> :-)
>>>
>>> Im currently busy until next week, would you like to provide a patch?
>>
>> Sorry, I have to pass. I'm busy elsewhere myself. MeeGo and
>> SyncEvolution plus real life consume all of my time nowadays.
>
> Working for MeeGo is a good excuse ;-)
>
> Will pick that task next week.
Thanks guys.
^ permalink raw reply
* RE: [PATCH 1/8] netdev: separate out davinci mdio controller code
From: Ramirez Luna, Omar @ 2010-08-03 23:29 UTC (permalink / raw)
To: Chemparathy, Cyril, netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com
Cc: Nori, Sekhar, Govindarajan, Sriramakrishnan, Chemparathy, Cyril
In-Reply-To: <1280842313-3743-2-git-send-email-cyril@ti.com>
Hi,
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Cyril
>Chemparathy
>
>Davinci's MDIO controller is present on other TI devices, without an
>accompanying EMAC. For example, on tnetv107x, the same MDIO module is used in
>conjunction with a 3-port switch hardware.
>
>By separating the MDIO controller code into its own platform driver, this
>patch allows common logic to be reused on such platforms.
>
>Signed-off-by: Cyril Chemparathy <cyril@ti.com>
>---
> drivers/net/Kconfig | 10 +
> drivers/net/Makefile | 1 +
> drivers/net/davinci_mdio.c | 386 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/davinci_emac.h | 4 +
> 4 files changed, 401 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/davinci_mdio.c
>
[...]
>diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
>new file mode 100644
>index 0000000..d34a53a
>--- /dev/null
>+++ b/drivers/net/davinci_mdio.c
[...]
>+
>+/* wait until hardware is ready for another user access */
>+static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
>+{
>+ struct davinci_mdio_regs __iomem *regs = data->regs;
>+ u32 reg;
>+
>+ while ((reg = __raw_readl(®s->user[0].access)) & USERACCESS_GO)
>+ ;
potential infinite loop? I saw another place in your series using time_after, might fit in here too.
>+
>+ return reg;
>+}
>+
>+/* wait until hardware state machine is idle */
>+static inline void wait_for_idle(struct davinci_mdio_data *data)
>+{
>+ struct davinci_mdio_regs __iomem *regs = data->regs;
>+
>+ while ((__raw_readl(®s->control) & CONTROL_IDLE) == 0)
>+ ;
Ditto
>+}
>+
[...]
Regards,
omar
^ permalink raw reply
* RE: [PATCH 6/8] netdev: separate out davinci cpdma controller code
From: Ramirez Luna, Omar @ 2010-08-03 23:30 UTC (permalink / raw)
To: Chemparathy, Cyril, netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com
Cc: Nori, Sekhar, Govindarajan, Sriramakrishnan
In-Reply-To: <1280842313-3743-7-git-send-email-cyril@ti.com>
Hi,
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of
>Chemparathy, Cyril
>
>In addition to being embedded into the EMAC controller, the CPDMA hardware
>block is used in TI's CPSW switch controller. Fortunately, the programming
>interface to this hardware block remains pretty nicely consistent across these
>devices.
>
>This patch adds a new CPDMA services layer, which can then be reused across
>EMAC and CPSW drivers.
>
>Signed-off-by: Cyril Chemparathy <cyril@ti.com>
>---
> drivers/net/Kconfig | 10 +
> drivers/net/Makefile | 1 +
> drivers/net/davinci_cpdma.c | 836 +++++++++++++++++++++++++++++++++++++++++++
> drivers/net/davinci_cpdma.h | 105 ++++++
> 4 files changed, 952 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/davinci_cpdma.c
> create mode 100644 drivers/net/davinci_cpdma.h
>
[...]
>diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
>new file mode 100644
>index 0000000..acce1c1
>--- /dev/null
>+++ b/drivers/net/davinci_cpdma.c
[...]
>+struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
>+ cpdma_handler_fn handler)
>+{
>+ struct cpdma_chan *chan;
>+ int ret, offset = (chan_num % CPDMA_MAX_CHANNELS) * 4;
>+ unsigned long flags;
>+
>+ if (__chan_linear(chan_num) >= ctlr->num_chan)
>+ return NULL;
>+
>+ ret = -ENOMEM;
>+ chan = kzalloc(sizeof(*chan), GFP_KERNEL);
>+ if (!chan)
>+ goto err_chan_alloc;
>+
>+ spin_lock_irqsave(&ctlr->lock, flags);
>+ ret = -EBUSY;
>+ if (ctlr->channels[chan_num])
>+ goto err_chan_busy;
Mem leaking 'chan'
>+
>+ chan->ctlr = ctlr;
>+ chan->state = CPDMA_STATE_IDLE;
>+ chan->chan_num = chan_num;
>+ chan->handler = handler;
>+
>+ if (is_rx_chan(chan)) {
>+ chan->hdp = ctlr->params.rxhdp + offset;
>+ chan->cp = ctlr->params.rxcp + offset;
>+ chan->rxfree = ctlr->params.rxfree + offset;
>+ chan->int_set = CPDMA_RXINTMASKSET;
>+ chan->int_clear = CPDMA_RXINTMASKCLEAR;
>+ chan->td = CPDMA_RXTEARDOWN;
>+ chan->dir = DMA_FROM_DEVICE;
>+ } else {
>+ chan->hdp = ctlr->params.txhdp + offset;
>+ chan->cp = ctlr->params.txcp + offset;
>+ chan->int_set = CPDMA_TXINTMASKSET;
>+ chan->int_clear = CPDMA_TXINTMASKCLEAR;
>+ chan->td = CPDMA_TXTEARDOWN;
>+ chan->dir = DMA_TO_DEVICE;
>+ }
>+ chan->mask = BIT(chan_linear(chan));
>+
>+ spin_lock_init(&chan->lock);
>+
>+ ctlr->channels[chan_num] = chan;
>+ spin_unlock_irqrestore(&ctlr->lock, flags);
>+ return chan;
>+
>+err_chan_busy:
>+ spin_unlock_irqrestore(&ctlr->lock, flags);
>+err_chan_alloc:
>+ return ERR_PTR(ret);
>+}
[...]
Regards,
omar
^ permalink raw reply
* [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-03 23:35 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-msm, linux-omap.vger.kernel.org, Greg Kroah-Hartman,
damm, lethal, rjw, dtor, eric.y.miao, netdev
Inspiration for this comes from:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
INTRO
As SOCs become more popular, the desire to quickly define a simple,
but functional, bus type with only a few unique properties becomes
desirable. As they become more complicated, the ability to nest these
simple busses and otherwise orchestrate them to match the actual
topology also becomes desirable.
EXAMPLE USAGE
/arch/ARCH/MY_ARCH/my_bus.c:
#include <linux/device.h>
#include <linux/platform_device.h>
struct bus_type my_bus_type = {
.name = "mybus",
};
EXPORT_SYMBOL_GPL(my_bus_type);
struct platform_device sub_bus1 = {
.name = "sub_bus1",
.id = -1,
.dev.bus = &my_bus_type,
}
EXPORT_SYMBOL_GPL(sub_bus1);
struct platform_device sub_bus2 = {
.name = "sub_bus2",
.id = -1,
.dev.bus = &my_bus_type,
}
EXPORT_SYMBOL_GPL(sub_bus2);
static int __init my_bus_init(void)
{
int error;
platform_bus_type_init(&my_bus_type);
error = bus_register(&my_bus_type);
if (error)
return error;
error = platform_device_register(&sub_bus1);
if (error)
goto fail_sub_bus1;
error = platform_device_register(&sub_bus2);
if (error)
goto fail_sub_bus2;
return error;
fail_sub_bus2:
platform_device_unregister(&sub_bus1);
fail_sub_bus2:
bus_unregister(&my_bus_type);
return error;
}
postcore_initcall(my_bus_init);
EXPORT_SYMBOL_CPY(my_bus_init);
/drivers/my_driver.c
static struct platform_driver my_driver = {
.driver = {
.name = "my-driver",
.owner = THIS_MODULE,
.bus = &my_bus_type,
},
};
/somewhere/my_device.c
static struct platform_device my_device = {
.name = "my-device",
.id = -1,
.dev.bus = &my_bus_type,
.dev.parent = &sub_bus_1.dev,
};
Notice that for a device / driver, only 3 lines were added to
switch from the platform bus to the new my_bus. This is
especially valuable if we consider supporting a legacy SOCs
and new SOCs where the same driver is used, but may need to
be on either the platform bus or the new my_bus. The above
code then becomes:
(possibly in a header)
#ifdef CONFIG_MY_BUS
#define MY_BUS_TYPE &my_bus_type
#else
#define MY_BUS_TYPE NULL
#endif
/drivers/my_driver.c
static struct platform_driver my_driver = {
.driver = {
.name = "my-driver",
.owner = THIS_MODULE,
.bus = MY_BUS_TYPE,
},
};
Which will allow the same driver to easily to used on either
the platform bus or the newly defined bus type.
This will build a device tree that mirrors the actual configuration:
/sys/bus
|-- my_bus
| |-- devices
| | |-- sub_bus1 -> ../../../devices/platform/sub_bus1
| | |-- sub_bus2 -> ../../../devices/platform/sub_bus2
| | |-- my-device -> ../../../devices/platform/sub_bus1/my-device
| |-- drivers
| | |-- my-driver
I believe this to be a fairly elegant and simple solution to the
problem, but humbly RFC
-Pat
Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
---
drivers/base/platform.c | 30 ++++++++++++++++++++++++++----
include/linux/platform_device.h | 2 ++
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..c86be03 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
@@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
- spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
- spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
@@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
};
EXPORT_SYMBOL_GPL(platform_bus_type);
+/** platform_bus_type_init - fill in a pseudo-platform-bus
+ * @bus: foriegn bus type
+ *
+ * This init is basically a selective memcpy that
+ * won't overwrite any user-defined attributes and
+ * only copies things that platform bus defines anyway
+ */
+void platform_bus_type_init(struct bus_type *bus)
+{
+ if (!bus->dev_attrs)
+ bus->dev_attrs = platform_bus_type.dev_attrs;
+ if (!bus->match)
+ bus->match = platform_bus_type.match;
+ if (!bus->uevent)
+ bus->uevent = platform_bus_type.uevent;
+ if (!bus->pm)
+ bus->pm = platform_bus_type.pm;
+}
+EXPORT_SYMBOL_GPL(platform_bus_type_init);
+
int __init platform_bus_init(void)
{
int error;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 5417944..fa8c35a 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -79,6 +79,8 @@ extern int platform_driver_probe(struct platform_driver *driver,
#define platform_get_drvdata(_dev) dev_get_drvdata(&(_dev)->dev)
#define platform_set_drvdata(_dev,data) dev_set_drvdata(&(_dev)->dev, (data))
+extern void platform_bus_type_init(struct bus_type *);
+
extern struct platform_device *platform_create_bundle(struct platform_driver *driver,
int (*probe)(struct platform_device *),
struct resource *res, unsigned int n_res,
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-03 23:36 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arm-msm, linux-omap, Greg Kroah-Hartman, damm, lethal, rjw,
dtor, eric.y.miao, netdev
In-Reply-To: <4C58A7AA.8020007@codeaurora.org>
Mis-typed omap's list; sorry for the resend
On 08/03/2010 04:35 PM, Patrick Pannuto wrote:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> INTRO
>
> As SOCs become more popular, the desire to quickly define a simple,
> but functional, bus type with only a few unique properties becomes
> desirable. As they become more complicated, the ability to nest these
> simple busses and otherwise orchestrate them to match the actual
> topology also becomes desirable.
>
> EXAMPLE USAGE
>
> /arch/ARCH/MY_ARCH/my_bus.c:
>
> #include <linux/device.h>
> #include <linux/platform_device.h>
>
> struct bus_type my_bus_type = {
> .name = "mybus",
> };
> EXPORT_SYMBOL_GPL(my_bus_type);
>
> struct platform_device sub_bus1 = {
> .name = "sub_bus1",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus1);
>
> struct platform_device sub_bus2 = {
> .name = "sub_bus2",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus2);
>
> static int __init my_bus_init(void)
> {
> int error;
> platform_bus_type_init(&my_bus_type);
>
> error = bus_register(&my_bus_type);
> if (error)
> return error;
>
> error = platform_device_register(&sub_bus1);
> if (error)
> goto fail_sub_bus1;
>
> error = platform_device_register(&sub_bus2);
> if (error)
> goto fail_sub_bus2;
>
> return error;
>
> fail_sub_bus2:
> platform_device_unregister(&sub_bus1);
> fail_sub_bus2:
> bus_unregister(&my_bus_type);
>
> return error;
> }
> postcore_initcall(my_bus_init);
> EXPORT_SYMBOL_CPY(my_bus_init);
>
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = &my_bus_type,
> },
> };
>
> /somewhere/my_device.c
> static struct platform_device my_device = {
> .name = "my-device",
> .id = -1,
> .dev.bus = &my_bus_type,
> .dev.parent = &sub_bus_1.dev,
> };
>
> Notice that for a device / driver, only 3 lines were added to
> switch from the platform bus to the new my_bus. This is
> especially valuable if we consider supporting a legacy SOCs
> and new SOCs where the same driver is used, but may need to
> be on either the platform bus or the new my_bus. The above
> code then becomes:
>
> (possibly in a header)
> #ifdef CONFIG_MY_BUS
> #define MY_BUS_TYPE &my_bus_type
> #else
> #define MY_BUS_TYPE NULL
> #endif
>
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = MY_BUS_TYPE,
> },
> };
>
> Which will allow the same driver to easily to used on either
> the platform bus or the newly defined bus type.
>
> This will build a device tree that mirrors the actual configuration:
> /sys/bus
> |-- my_bus
> | |-- devices
> | | |-- sub_bus1 -> ../../../devices/platform/sub_bus1
> | | |-- sub_bus2 -> ../../../devices/platform/sub_bus2
> | | |-- my-device -> ../../../devices/platform/sub_bus1/my-device
> | |-- drivers
> | | |-- my-driver
>
> I believe this to be a fairly elegant and simple solution to the
> problem, but humbly RFC
>
> -Pat
>
> Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
> ---
> drivers/base/platform.c | 30 ++++++++++++++++++++++++++----
> include/linux/platform_device.h | 2 ++
> 2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 4d99c8b..c86be03 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
> if (!pdev->dev.parent)
> pdev->dev.parent = &platform_bus;
>
> - pdev->dev.bus = &platform_bus_type;
> + if (!pdev->dev.bus)
> + pdev->dev.bus = &platform_bus_type;
>
> if (pdev->id != -1)
> dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
> @@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
> */
> int platform_driver_register(struct platform_driver *drv)
> {
> - drv->driver.bus = &platform_bus_type;
> + if (!drv->driver.bus)
> + drv->driver.bus = &platform_bus_type;
> if (drv->probe)
> drv->driver.probe = platform_drv_probe;
> if (drv->remove)
> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
> * if the probe was successful, and make sure any forced probes of
> * new devices fail.
> */
> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
> drv->probe = NULL;
> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
>
> if (code != retval)
> platform_driver_unregister(drv);
> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
> };
> EXPORT_SYMBOL_GPL(platform_bus_type);
>
> +/** platform_bus_type_init - fill in a pseudo-platform-bus
> + * @bus: foriegn bus type
> + *
> + * This init is basically a selective memcpy that
> + * won't overwrite any user-defined attributes and
> + * only copies things that platform bus defines anyway
> + */
> +void platform_bus_type_init(struct bus_type *bus)
> +{
> + if (!bus->dev_attrs)
> + bus->dev_attrs = platform_bus_type.dev_attrs;
> + if (!bus->match)
> + bus->match = platform_bus_type.match;
> + if (!bus->uevent)
> + bus->uevent = platform_bus_type.uevent;
> + if (!bus->pm)
> + bus->pm = platform_bus_type.pm;
> +}
> +EXPORT_SYMBOL_GPL(platform_bus_type_init);
> +
> int __init platform_bus_init(void)
> {
> int error;
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 5417944..fa8c35a 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -79,6 +79,8 @@ extern int platform_driver_probe(struct platform_driver *driver,
> #define platform_get_drvdata(_dev) dev_get_drvdata(&(_dev)->dev)
> #define platform_set_drvdata(_dev,data) dev_set_drvdata(&(_dev)->dev, (data))
>
> +extern void platform_bus_type_init(struct bus_type *);
> +
> extern struct platform_device *platform_create_bundle(struct platform_driver *driver,
> int (*probe)(struct platform_device *),
> struct resource *res, unsigned int n_res,
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [GIT PULL] xen-netfront driver updates for 2.6.36
From: David Miller @ 2010-08-03 23:37 UTC (permalink / raw)
To: jeremy; +Cc: linux-kernel, netdev, Xen-devel, dongxiao.xu
In-Reply-To: <4C586271.3010902@goop.org>
From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Tue, 03 Aug 2010 11:39:45 -0700
> Here's a git branch with some updates to the Xen netfront driver,
> which add a new "smartpoll" mode to the netfront backend protocol,
> which is basically equivalent to interrupt mitigation. This merges
> cleanly with current linux-next (it previously just had a small
> constification conflict).
>
> Do you want to take this via the net tree, or are you OK with me
> submitting them directly?
Well from my perspective:
1) It's too late to put into my tree because the merge window has
already started. If you want me to include this you should have
asked me to pull it in days if not weeks ago.
2) Your tree is absolutely not in a state I can pull it. It has lots
of completely unrelated commits which are not in net-next-2.6 which
in no way should I be pulling into my tree.
When you want me to take changes, your tree should be based upon mine.
And when I pull from your tree I should get only your specific
xen-netfront driver changes, and nothing more.
Thanks.
^ permalink raw reply
* Re: [PATCH v5] can: Add driver for esd CAN-USB/2 device
From: David Miller @ 2010-08-03 23:38 UTC (permalink / raw)
To: matthias.fuchs; +Cc: netdev, Socketcan-core, linux-usb
In-Reply-To: <201008031455.23255.matthias.fuchs@esd.eu>
From: Matthias Fuchs <matthias.fuchs@esd.eu>
Date: Tue, 3 Aug 2010 14:55:23 +0200
> This patch adds a driver for esd's USB high speed
> CAN interface. The driver supports devices with
> multiple CAN interfaces.
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs@esd.eu>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Applied, thank you.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000e: correct MAC-PHY interconnect register offset for 82579
From: David Miller @ 2010-08-03 23:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100803214827.5712.8674.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 03 Aug 2010 14:48:35 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The MAC-PHY interconnect register set on ICH/PCH parts is accessed through
> a peephole mechanism by writing an offset to a CSR register. The offset
> for the interconnect's half-duplex control register (which is used in a
> jumbo frame workaround for 82579) is incorrect.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] igb: Program MDICNFG register prior to PHY init
From: David Miller @ 2010-08-03 23:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, alexander.h.duyck
In-Reply-To: <20100803215005.5948.63055.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 03 Aug 2010 14:50:08 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch addresses an issue seen on 82580 in which the MDICNFG
> register will be reset during a single function reset and as a
> result we will be unable to communicate with the PHY. To correct
> the issue, added a call to reset_mdicnfg just prior to the first
> access of the MDICNFG register in sgnii_uses_mdio.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH] hso: Add new product ID
From: David Miller @ 2010-08-03 23:41 UTC (permalink / raw)
To: f.aben-x9gZzRpC1QbQT0dZR+AlfA
Cc: gregkh-l3A5Bk7waGM, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1280849801.5149.5.camel@filip-linux>
From: Filip Aben <f.aben-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
Date: Tue, 03 Aug 2010 17:36:41 +0200
> This patch adds a new product ID to the hso driver.
>
> Signed-off-by: Filip Aben <f.aben-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ipt_REJECT: can't work with bridges
From: Changli Gao @ 2010-08-03 23:54 UTC (permalink / raw)
To: Patrick McHardy
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, netfilter-devel, netdev,
Changli Gao
In-Reply-To: <1278314214-18469-1-git-send-email-xiaosuo@gmail.com>
On Mon, Jul 5, 2010 at 3:16 PM, Changli Gao <xiaosuo@gmail.com> wrote:
> ipt_REJECT: can't work with bridges
>
> ip_route_me_harder can't create the route cache when the outdev is the same with
> the indev for the skbs whichout a valid protocol set.
>
> __mkroute_input functions has this check:
> 1998 if (skb->protocol != htons(ETH_P_IP)) {
> 1999 /* Not IP (i.e. ARP). Do not create route, if it is
> 2000 * invalid for proxy arp. DNAT routes are always valid.
> 2001 *
> 2002 * Proxy arp feature have been extended to allow, ARP
> 2003 * replies back to the same interface, to support
> 2004 * Private VLAN switch technologies. See arp.c.
> 2005 */
> 2006 if (out_dev == in_dev &&
> 2007 IN_DEV_PROXY_ARP_PVLAN(in_dev) == 0) {
> 2008 err = -EINVAL;
> 2009 goto cleanup;
> 2010 }
> 2011 }
>
> This patch gives the new skb a valid protocol to bypass this check. In order to
> make ipt_REJECT work with bridges, you also need to enable ip_forward.
>
> This patch also fixes a regression. When we used skb_copy_expand(), we didn't
> have this issue stated above, as the protocol was properly set. In fact, the
> regression also affects TC classification and packet sockets.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
> net/ipv4/netfilter/ipt_REJECT.c | 1 +
> 1 file changed, 1 insertion(+)
> diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
> index bbbd273..60b8832 100644
> --- a/net/ipv4/netfilter/ipt_REJECT.c
> +++ b/net/ipv4/netfilter/ipt_REJECT.c
> @@ -111,6 +111,7 @@ static void send_reset(struct sk_buff *oldskb, int hook)
> /* ip_route_me_harder expects skb->dst to be set */
> skb_dst_set_noref(nskb, skb_dst(oldskb));
>
> + nskb->protocol = htons(ETH_P_IP);
> if (ip_route_me_harder(nskb, addr_type))
> goto free_nskb;
>
>
This bugfix patch seems missed, or I need to respin it? Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Greg KH @ 2010-08-03 23:56 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel, linux-arm-msm, linux-omap, damm, lethal, rjw, dtor,
eric.y.miao, netdev
In-Reply-To: <4C58A7AA.8020007@codeaurora.org>
On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
> Inspiration for this comes from:
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>
> INTRO
>
> As SOCs become more popular, the desire to quickly define a simple,
> but functional, bus type with only a few unique properties becomes
> desirable. As they become more complicated, the ability to nest these
> simple busses and otherwise orchestrate them to match the actual
> topology also becomes desirable.
>
> EXAMPLE USAGE
>
> /arch/ARCH/MY_ARCH/my_bus.c:
>
> #include <linux/device.h>
> #include <linux/platform_device.h>
>
> struct bus_type my_bus_type = {
> .name = "mybus",
> };
> EXPORT_SYMBOL_GPL(my_bus_type);
>
> struct platform_device sub_bus1 = {
> .name = "sub_bus1",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus1);
You really want a bus hanging off of a bus? Normally you need a device
to do that, which is what I think you have here, but the naming is a bit
odd to me.
What would you do with this "sub bus"? It's just a device, but you are
wanting it to be around for something.
>
> struct platform_device sub_bus2 = {
> .name = "sub_bus2",
> .id = -1,
> .dev.bus = &my_bus_type,
> }
> EXPORT_SYMBOL_GPL(sub_bus2);
>
> static int __init my_bus_init(void)
> {
> int error;
> platform_bus_type_init(&my_bus_type);
>
> error = bus_register(&my_bus_type);
> if (error)
> return error;
>
> error = platform_device_register(&sub_bus1);
> if (error)
> goto fail_sub_bus1;
>
> error = platform_device_register(&sub_bus2);
> if (error)
> goto fail_sub_bus2;
>
> return error;
>
> fail_sub_bus2:
> platform_device_unregister(&sub_bus1);
> fail_sub_bus2:
> bus_unregister(&my_bus_type);
>
> return error;
> }
> postcore_initcall(my_bus_init);
> EXPORT_SYMBOL_CPY(my_bus_init);
>
> /drivers/my_driver.c
> static struct platform_driver my_driver = {
> .driver = {
> .name = "my-driver",
> .owner = THIS_MODULE,
> .bus = &my_bus_type,
> },
> };
>
> /somewhere/my_device.c
> static struct platform_device my_device = {
> .name = "my-device",
> .id = -1,
> .dev.bus = &my_bus_type,
> .dev.parent = &sub_bus_1.dev,
> };
Ah, you put devices on this "sub bus". But why? Why not just put it on
your "normal" bus that you created? What's with the extra level of
nesting here?
Other than that, it looks like a nice idea, are there portions of kernel
code that can be simplified because of this?
> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
> * if the probe was successful, and make sure any forced probes of
> * new devices fail.
> */
> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
> drv->probe = NULL;
> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
> retval = -ENODEV;
> drv->driver.probe = platform_drv_probe_fail;
> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
>
> if (code != retval)
> platform_driver_unregister(drv);
I'm guessing that this chunk can be applied now, right?
> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
> };
> EXPORT_SYMBOL_GPL(platform_bus_type);
>
> +/** platform_bus_type_init - fill in a pseudo-platform-bus
> + * @bus: foriegn bus type
> + *
> + * This init is basically a selective memcpy that
> + * won't overwrite any user-defined attributes and
> + * only copies things that platform bus defines anyway
> + */
> +void platform_bus_type_init(struct bus_type *bus)
> +{
> + if (!bus->dev_attrs)
> + bus->dev_attrs = platform_bus_type.dev_attrs;
> + if (!bus->match)
> + bus->match = platform_bus_type.match;
> + if (!bus->uevent)
> + bus->uevent = platform_bus_type.uevent;
> + if (!bus->pm)
> + bus->pm = platform_bus_type.pm;
Watch out for things in "write only" memory here. That could cause
problems.
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-04 0:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, linux-arm-msm, linux-omap, damm, lethal, rjw, dtor,
eric.y.miao, netdev
In-Reply-To: <20100803235631.GA17759@suse.de>
On 08/03/2010 04:56 PM, Greg KH wrote:
> On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
>> Inspiration for this comes from:
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
>>
>> INTRO
>>
>> As SOCs become more popular, the desire to quickly define a simple,
>> but functional, bus type with only a few unique properties becomes
>> desirable. As they become more complicated, the ability to nest these
>> simple busses and otherwise orchestrate them to match the actual
>> topology also becomes desirable.
>>
>> EXAMPLE USAGE
>>
>> /arch/ARCH/MY_ARCH/my_bus.c:
>>
>> #include <linux/device.h>
>> #include <linux/platform_device.h>
>>
>> struct bus_type my_bus_type = {
>> .name = "mybus",
>> };
>> EXPORT_SYMBOL_GPL(my_bus_type);
>>
>> struct platform_device sub_bus1 = {
>> .name = "sub_bus1",
>> .id = -1,
>> .dev.bus = &my_bus_type,
>> }
>> EXPORT_SYMBOL_GPL(sub_bus1);
>
> You really want a bus hanging off of a bus? Normally you need a device
> to do that, which is what I think you have here, but the naming is a bit
> odd to me.
>
> What would you do with this "sub bus"? It's just a device, but you are
> wanting it to be around for something.
>
It's for power management stuff, basically, there are actual physical buses
involved that can be completely powered off IFF all of their devices are
not in use. Plus it actually matches bus topology this way.
>>
>> struct platform_device sub_bus2 = {
>> .name = "sub_bus2",
>> .id = -1,
>> .dev.bus = &my_bus_type,
>> }
>> EXPORT_SYMBOL_GPL(sub_bus2);
>>
>> static int __init my_bus_init(void)
>> {
>> int error;
>> platform_bus_type_init(&my_bus_type);
>>
>> error = bus_register(&my_bus_type);
>> if (error)
>> return error;
>>
>> error = platform_device_register(&sub_bus1);
>> if (error)
>> goto fail_sub_bus1;
>>
>> error = platform_device_register(&sub_bus2);
>> if (error)
>> goto fail_sub_bus2;
>>
>> return error;
>>
>> fail_sub_bus2:
>> platform_device_unregister(&sub_bus1);
>> fail_sub_bus2:
>> bus_unregister(&my_bus_type);
>>
>> return error;
>> }
>> postcore_initcall(my_bus_init);
>> EXPORT_SYMBOL_CPY(my_bus_init);
>>
>> /drivers/my_driver.c
>> static struct platform_driver my_driver = {
>> .driver = {
>> .name = "my-driver",
>> .owner = THIS_MODULE,
>> .bus = &my_bus_type,
>> },
>> };
>>
>> /somewhere/my_device.c
>> static struct platform_device my_device = {
>> .name = "my-device",
>> .id = -1,
>> .dev.bus = &my_bus_type,
>> .dev.parent = &sub_bus_1.dev,
>> };
>
> Ah, you put devices on this "sub bus". But why? Why not just put it on
> your "normal" bus that you created? What's with the extra level of
> nesting here?
>
> Other than that, it looks like a nice idea, are there portions of kernel
> code that can be simplified because of this?
See above.
>
>> @@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
>> * if the probe was successful, and make sure any forced probes of
>> * new devices fail.
>> */
>> - spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
>> + spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
>> drv->probe = NULL;
>> if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
>> retval = -ENODEV;
>> drv->driver.probe = platform_drv_probe_fail;
>> - spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
>> + spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
>>
>> if (code != retval)
>> platform_driver_unregister(drv);
>
> I'm guessing that this chunk can be applied now, right?
Probably; right now this will always work since anything that
is a platform_driver will have .driver.bus = &platform_bus_type,
but that does change with this patch.
There is no need (IMHO) for it to be a separate patch.
>
>> @@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
>> };
>> EXPORT_SYMBOL_GPL(platform_bus_type);
>>
>> +/** platform_bus_type_init - fill in a pseudo-platform-bus
>> + * @bus: foriegn bus type
>> + *
>> + * This init is basically a selective memcpy that
>> + * won't overwrite any user-defined attributes and
>> + * only copies things that platform bus defines anyway
>> + */
>> +void platform_bus_type_init(struct bus_type *bus)
>> +{
>> + if (!bus->dev_attrs)
>> + bus->dev_attrs = platform_bus_type.dev_attrs;
>> + if (!bus->match)
>> + bus->match = platform_bus_type.match;
>> + if (!bus->uevent)
>> + bus->uevent = platform_bus_type.uevent;
>> + if (!bus->pm)
>> + bus->pm = platform_bus_type.pm;
>
> Watch out for things in "write only" memory here. That could cause
> problems.
Pardon my ignorance (I'm quite new to kernel work), what do you mean
here? What memory could be "write only"?
>
> thanks,
>
> greg k-h
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC PATCH] platform: Faciliatate the creation of pseduo-platform busses
From: Greg KH @ 2010-08-04 0:09 UTC (permalink / raw)
To: Patrick Pannuto
Cc: linux-kernel, linux-arm-msm, linux-omap, damm, lethal, rjw, dtor,
eric.y.miao, netdev
In-Reply-To: <4C58AE15.6090900@codeaurora.org>
On Tue, Aug 03, 2010 at 05:02:29PM -0700, Patrick Pannuto wrote:
> On 08/03/2010 04:56 PM, Greg KH wrote:
> > On Tue, Aug 03, 2010 at 04:35:06PM -0700, Patrick Pannuto wrote:
> >> Inspiration for this comes from:
> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
> >>
> >> INTRO
> >>
> >> As SOCs become more popular, the desire to quickly define a simple,
> >> but functional, bus type with only a few unique properties becomes
> >> desirable. As they become more complicated, the ability to nest these
> >> simple busses and otherwise orchestrate them to match the actual
> >> topology also becomes desirable.
> >>
> >> EXAMPLE USAGE
> >>
> >> /arch/ARCH/MY_ARCH/my_bus.c:
> >>
> >> #include <linux/device.h>
> >> #include <linux/platform_device.h>
> >>
> >> struct bus_type my_bus_type = {
> >> .name = "mybus",
> >> };
> >> EXPORT_SYMBOL_GPL(my_bus_type);
For your question below, this could be in write-only memory. Well, I
guess it never is as we modify things in the bus structure, so nevermind
about that, false alarm.
> >>
> >> struct platform_device sub_bus1 = {
> >> .name = "sub_bus1",
> >> .id = -1,
> >> .dev.bus = &my_bus_type,
> >> }
> >> EXPORT_SYMBOL_GPL(sub_bus1);
> >
> > You really want a bus hanging off of a bus? Normally you need a device
> > to do that, which is what I think you have here, but the naming is a bit
> > odd to me.
> >
> > What would you do with this "sub bus"? It's just a device, but you are
> > wanting it to be around for something.
> >
>
> It's for power management stuff, basically, there are actual physical buses
> involved that can be completely powered off IFF all of their devices are
> not in use. Plus it actually matches bus topology this way.
Then create a real bus hanging off of a device, not another device that
"acts" like a bus here, right? Or am I missing the point?
> >> +void platform_bus_type_init(struct bus_type *bus)
> >> +{
> >> + if (!bus->dev_attrs)
> >> + bus->dev_attrs = platform_bus_type.dev_attrs;
> >> + if (!bus->match)
> >> + bus->match = platform_bus_type.match;
> >> + if (!bus->uevent)
> >> + bus->uevent = platform_bus_type.uevent;
> >> + if (!bus->pm)
> >> + bus->pm = platform_bus_type.pm;
> >
> > Watch out for things in "write only" memory here. That could cause
> > problems.
>
> Pardon my ignorance (I'm quite new to kernel work), what do you mean
> here? What memory could be "write only"?
See above. I was thinking that struct bus would be a constant or
something. Sorry.
greg k-h
^ permalink raw reply
* [PATCH 1/2] igb.txt: Add igb documentation
From: Jeff Kirsher @ 2010-08-04 0:15 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, gospo, bphilips, Jeff Kirsher
Add documentation for the igb networking driver.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
---
Documentation/networking/igb.txt | 134 ++++++++++++++++++++++++++++++++++++++
1 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/igb.txt
diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt
new file mode 100644
index 0000000..975023a
--- /dev/null
+++ b/Documentation/networking/igb.txt
@@ -0,0 +1,134 @@
+Linux* Base Driver for Intel(R) Network Connection
+==================================================
+
+Intel Gigabit Linux driver.
+Copyright(c) 1999 - 2010 Intel Corporation.
+
+Contents
+========
+
+- Identifying Your Adapter
+- Additional Configurations
+- Support
+
+Identifying Your Adapter
+========================
+
+This driver supports all 82575, 82576 and 82580-based Intel (R) gigabit network
+connections.
+
+For specific information on how to identify your adapter, go to the Adapter &
+Driver ID Guide at:
+
+ http://support.intel.com/support/go/network/adapter/idguide.htm
+
+Command Line Parameters
+=======================
+
+The default value for each parameter is generally the recommended setting,
+unless otherwise noted.
+
+max_vfs
+-------
+Valid Range: 0-7
+Default Value: 0
+
+This parameter adds support for SR-IOV. It causes the driver to spawn up to
+max_vfs worth of virtual function.
+
+Additional Configurations
+=========================
+
+ Jumbo Frames
+ ------------
+ Jumbo Frames support is enabled by changing the MTU to a value larger than
+ the default of 1500. Use the ifconfig command to increase the MTU size.
+ For example:
+
+ ifconfig eth<x> mtu 9000 up
+
+ This setting is not saved across reboots.
+
+ Notes:
+
+ - The maximum MTU setting for Jumbo Frames is 9216. This value coincides
+ with the maximum Jumbo Frames size of 9234 bytes.
+
+ - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
+ loss of link.
+
+ Ethtool
+ -------
+ The driver utilizes the ethtool interface for driver configuration and
+ diagnostics, as well as displaying statistical information. Ethtool
+ version 3.0 or later is required for this functionality, although we
+ strongly recommend downloading the latest version at:
+
+ http://sourceforge.net/projects/gkernel.
+
+ Enabling Wake on LAN* (WoL)
+ ---------------------------
+ WoL is configured through the Ethtool* utility.
+
+ For instructions on enabling WoL with Ethtool, refer to the Ethtool man page.
+
+ WoL will be enabled on the system during the next shut down or reboot.
+ For this driver version, in order to enable WoL, the igb driver must be
+ loaded when shutting down or rebooting the system.
+
+ Wake On LAN is only supported on port A of multi-port adapters.
+
+ Wake On LAN is not supported for the Intel(R) Gigabit VT Quad Port Server
+ Adapter.
+
+ Multiqueue
+ ----------
+ In this mode, a separate MSI-X vector is allocated for each queue and one
+ for "other" interrupts such as link status change and errors. All
+ interrupts are throttled via interrupt moderation. Interrupt moderation
+ must be used to avoid interrupt storms while the driver is processing one
+ interrupt. The moderation value should be at least as large as the expected
+ time for the driver to process an interrupt. Multiqueue is off by default.
+
+ REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not
+ found, the system will fallback to MSI or to Legacy interrupts.
+
+ LRO
+ ---
+ Large Receive Offload (LRO) is a technique for increasing inbound throughput
+ of high-bandwidth network connections by reducing CPU overhead. It works by
+ aggregating multiple incoming packets from a single stream into a larger
+ buffer before they are passed higher up the networking stack, thus reducing
+ the number of packets that have to be processed. LRO combines multiple
+ Ethernet frames into a single receive in the stack, thereby potentially
+ decreasing CPU utilization for receives.
+
+ NOTE: LRO requires 2.6.24 or later kernel version. You also need to have
+ inet_lro enabled via either the CONFIG_INET_LRO or CONFIG_INET_LRO_MODULE
+ kernel config option. Additionally, if CONFIG_INET_LRO_MODULE is used, the
+ inet_lro module needs to be loaded before the igb driver.
+
+ You can verify that the driver is using LRO by looking at these counters in
+ Ethtool:
+
+ lro_aggregated - count of total packets that were combined
+ lro_flushed - counts the number of packets flushed out of LRO
+ lro_no_desc - counts the number of times an LRO descriptor was not available
+ for the LRO packet
+
+ NOTE: IPv6 and UDP are not supported by LRO.
+
+Support
+=======
+
+For general information, go to the Intel support website at:
+
+ www.intel.com/support/
+
+or the Intel Wired Networking project hosted by Sourceforge at:
+
+ http://sourceforge.net/projects/e1000
+
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related
+to the issue to e1000-devel@lists.sf.net
^ permalink raw reply related
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