* Re: [PATCH 2/2 net-next] af_netlink: drop_monitor/dropwatch friendly
From: David Miller @ 2012-04-24 4:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1335166229.3293.14.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 23 Apr 2012 09:30:29 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Need to consume_skb() instead of kfree_skb() in netlink_dump() and
> netlink_unicast_kernel() to avoid false dropwatch positives.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ehea: only register irq after setting up ports
From: David Miller @ 2012-04-24 4:37 UTC (permalink / raw)
To: cascardo; +Cc: netdev, stable
In-Reply-To: <1335188789-6211-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Mon, 23 Apr 2012 10:46:29 -0300
> If we receive an interrupt too early before we set up ports in the probe
> function, there won't be any port ready to handle it.
>
> Only registering the irq after the ports are setup fixes the problem,
> and works fine without losing any interrupts.
>
> This causes crashes in some situations:
...
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> Cc: stable@vger.kernel.org
Applied, thanks for fixing this properly.
^ permalink raw reply
* Re: [PATCH] net: skb_free_datagram_locked() consumes skb
From: David Miller @ 2012-04-24 4:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1335168567.3293.20.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 23 Apr 2012 10:09:27 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> All skb_free_datagram_locked() callers consume skb, not drop it.
> Noticed on dropwatch session polluted by UDP false positives.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
For some call sites in sunrpc, it's not a consume.
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Stephen Hemminger @ 2012-04-24 4:40 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, jhs, netdev, dev, eric dumazet, Kyle Mestery,
Jesse Gross
In-Reply-To: <20120424022514.GB5357@verge.net.au>
----- Original Message -----
> On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> > On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms@verge.net.au>
> > wrote:
> > > On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> > >> On Mon, Apr 23, 2012 at 2:08 PM, David Miller
> > >> <davem@davemloft.net> wrote:
> > >> > From: Jesse Gross <jesse@nicira.com>
> > >> > Date: Mon, 23 Apr 2012 13:53:42 -0700
> > >> >
> > >> >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller
> > >> >> <davem@davemloft.net> wrote:
> > >> >>> From: Jesse Gross <jesse@nicira.com>
> > >> >>> Date: Mon, 23 Apr 2012 13:08:49 -0700
> > >> >>>
> > >> >>>> Assuming that the TCP stack generates large TSO frames on
> > >> >>>> transmit
> > >> >>>> (which could be the local stack; something sent by a VM; or
> > >> >>>> packets
> > >> >>>> received, coalesced by GRO and then encapsulated by STT)
> > >> >>>> then you can
> > >> >>>> just prepend the STT header (possibly slightly adjusting
> > >> >>>> things like
> > >> >>>> requested MSS, number of segments, etc. slightly). After
> > >> >>>> that it's
> > >> >>>> possible to just output the resulting frame through the IP
> > >> >>>> stack like
> > >> >>>> all tunnels do today.
> > >> >>>
> > >> >>> Which seems to potentially suggest a stronger intergration
> > >> >>> of the STT
> > >> >>> tunnel transmit path into our IP stack rather than the
> > >> >>> approach Simon
> > >> >>> is taking
> > >> >>
> > >> >> Did you have something in mind?
> > >> >
> > >> > A normal bonafide tunnel netdevice driver like GRE instead of
> > >> > the
> > >> > openvswitch approach Simon is using.
> > >>
> > >> Ahh, yes, that I agree with. Independent of this, there's work
> > >> being
> > >> done to make it so that OVS can use the normal in-tree tunneling
> > >> code
> > >> and not need its own. Once that's done I expect that STT will
> > >> follow
> > >> the same model.
> > >
> > > Hi Jesse,
> > >
> > > I am wondering how firm the plans to on allowing OVS to use
> > > in-tree tunnel
> > > code are. I'm happy to move my efforts over to an in-tree STT
> > > implementation
> > > but ultimately I would like to get STT running in conjunction
> > > with OVS.
> >
> > I would say that it's a firm goal but the implementation probably
> > still has a ways to go. Kyle Mestery (CC'ed) has volunteered to
> > work
> > on this in support of adding VXLAN, which needs some additional
> > flexibility that this approach would also provide. You might want
> > to
> > talk to him to see if there are ways that you guys can work
> > together
> > on it if you are interested. Having better integration with
> > upstream
> > tunneling is definitely a step that OVS needs to make and sooner
> > would
> > be better than later.
>
> Hi Jesse, Hi Kyle,
>
> that sounds like an excellent plan.
>
> Kyle, do you have any thoughts on how we might best work together on
> this?
> Perhaps there are some patches floating around that I could take a
> look at?
ChrisW had a start to VxVlan tunnel (non OVS), and I promised to work on finishing
it.
^ permalink raw reply
* Re: [PATCH net-next] tipc: remove inline instances from C source files.
From: David Miller @ 2012-04-24 4:41 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, allan.stephens
In-Reply-To: <1335192553-19054-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon, 23 Apr 2012 10:49:13 -0400
> Untie gcc's hands and let it do what it wants within the
> individual source files. There are two files, node.c and
> port.c -- only the latter effectively changes (gcc-4.5.2).
> Objdump shows gcc deciding to not inline port_peernode().
>
> Suggested-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks Paul.
^ permalink raw reply
* Re: [PATCH v2] smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes
From: David Miller @ 2012-04-24 4:42 UTC (permalink / raw)
To: fillods; +Cc: paolo.pisati, steve.glendinning, netdev
In-Reply-To: <20120423194339.GS5277@charybde.local>
From: Stephane Fillod <fillods@users.sf.net>
Date: Mon, 23 Apr 2012 21:43:39 +0200
> lun, Apr 23, 2012, Paolo Pisati skribis:
>> Without this patch sysfs reports the cable as present
>>
>> flag@flag-desktop:~$ cat /sys/class/net/eth0/carrier
>> 1
>>
>> while it's not:
>>
>> flag@flag-desktop:~$ sudo mii-tool eth0
>> eth0: no link
>>
>> Tested on my Beagle XM.
>>
>> v2: added mantainer to the list of recipient
>
> His e-mail address has changed, but somehow it has not been updated yet
> in MAINTAINERS directory: steve.glendinning () shawell.net
Steve, please send a maintainers etc. update and please provide
feedback on this link status fix.
^ permalink raw reply
* Re: [PATCH net] net/davinci_emac: fix failing PHY connect attempts
From: David Miller @ 2012-04-24 4:44 UTC (permalink / raw)
To: agust; +Cc: netdev
In-Reply-To: <1335218803-8664-1-git-send-email-agust@denx.de>
From: Anatolij Gustschin <agust@denx.de>
Date: Tue, 24 Apr 2012 00:06:43 +0200
> PHY connect attempts fail if no PHY id is specified in the emac platform
> data and another mdio bus has been registered before 'davinci_mdio' bus. In
> this case when configuring the interface, there will be an attempt to
> connect to already attached PHY on the previously registered mdio bus:
>
> net eth1: PHY already attached
> net eth1: could not connect to phy smsc911x-0:01
> IP-Config: Failed to open eth1
> IP-Config: Device `eth1' not found
>
> Fix this by modifying match_first_device() to match first PHY device
> on 'davinci_mdio' bus.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] b44: properly use pr_fmt()
From: David Miller @ 2012-04-24 4:47 UTC (permalink / raw)
To: mcgrof; +Cc: zambrano, netdev
In-Reply-To: <1335235603-32420-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Mon, 23 Apr 2012 19:46:43 -0700
> From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
>
> pr_fmt() is either defined or we redefine it. Typically
> drivers define it prior to including printk.h but this
> is done under the assumption that no other subsystem
> it uses has already defined pr_fmt(). In such cases
> pr_fmt() should be undefined and redefined.
>
> Doing this properly shaves down compilation time quite
> considerably.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Every driver defines pr_fmt then includes the headers. I do not
see any other place which performs the initial undef of pr_fmt
like you want to start doing here.
If there is a reason we should start doing this, it would appear
to be a universal reason, not one specific to this driver. If
that's the case, we should formally agree to this and then work
on gradually converting all the drivers in reasonably sized chunks.
Either way I can't apply this patch as-is, sorry Luis.
^ permalink raw reply
* Re: [PATCH net] net/neigh: move neigh cleanup routine to neigh_destroy
From: David Miller @ 2012-04-24 4:53 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, shlomop
In-Reply-To: <1335195282-28738-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Mon, 23 Apr 2012 18:34:42 +0300
> From: Shlomo Pongratz <shlomop@mellanox.com>
>
> Move call the neigh_cleanup call to be done from neigh_destroy, this
> ensures the cleanup callback is invoked only when the neighbour reference
> count becomes zero (e.g in the same manner as ndo_neigh_destory).
>
> Note that with this change neigh_destroy will truly revert the action of
> neigh_create, as neigh_release which calls neigh_destroy is called directly
> from various code paths, and thus neigh->parms->neigh_cleanup is not called
> for these code paths.
>
> Also, with commit 7d26bb103 "bonding: emit event when bonding changes MAC" that
> triggers netdev address change event, a race was introduced since neigh cleanup
> can be called when there's reference on the neighbour.
>
> Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
With IPOIB, the neigh_cleanup purges references to the neigh when it
liberates the SKBs in the neigh resolution TX backlog during
ipoib_neigh_free().
Therefore, with your change, IPOIB neighs will never be destroyed if
they have any SKBs in their neigh resolution queues.
I'm not applying this, it's buggy.
^ permalink raw reply
* RE: linux-next: manual merge of the wireless-next tree with the net-next tree
From: Grumbach, Emmanuel @ 2012-04-24 5:07 UTC (permalink / raw)
To: Stephen Rothwell, John W. Linville
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Guy, Wey-Yi W, David Miller, netdev@vger.kernel.org
In-Reply-To: <20120424124803.f4dc75ea96a875c3f35db615@canb.auug.org.au>
>
> Hi John,
>
> Today's linux-next merge of the wireless-next tree got a conflict in
> drivers/net/wireless/iwlwifi/iwl-testmode.c between commit d33e152e1edd
> ("iwlwifi: Stop using NLA_PUT*()") from the net-next tree and commit
> 2152268ff911 ("iwlwifi: op_mode holds its pointer to the config") from the
> wireless-next tree.
>
> I was hoping that we were done with these ... :-(
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks Stephen, your fix seems right. In this case, there are only two choices: it is right or it doesn't even compile.
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc drivers/net/wireless/iwlwifi/iwl-testmode.c
> index bb27509,a6b16aa..0000000
> --- a/drivers/net/wireless/iwlwifi/iwl-testmode.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-testmode.c
> @@@ -543,12 -539,11 +543,12 @@@ static int iwl_testmode_driver(struct i
> IWL_ERR(priv, "Memory allocation fail\n");
> return -ENOMEM;
> }
> - NLA_PUT_U32(skb, IWL_TM_ATTR_COMMAND,
> - IWL_TM_CMD_DEV2APP_EEPROM_RSP);
> - NLA_PUT(skb, IWL_TM_ATTR_EEPROM,
> - priv->cfg->base_params->eeprom_size,
> - priv->eeprom);
> + if (nla_put_u32(skb, IWL_TM_ATTR_COMMAND,
> + IWL_TM_CMD_DEV2APP_EEPROM_RSP) ||
> + nla_put(skb, IWL_TM_ATTR_EEPROM,
> - cfg(priv)->base_params->eeprom_size,
> ++ priv->cfg->base_params->eeprom_size,
> + priv->eeprom))
> + goto nla_put_failure;
> status = cfg80211_testmode_reply(skb);
> if (status < 0)
> IWL_ERR(priv, "Error sending msg : %d\n",
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [RFC v4] Add TCP encap_rcv hook (repost)
From: Simon Horman @ 2012-04-24 5:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev-yBygre7rU0TnMu66kgdUjQ, eric dumazet,
netdev-u79uwXL29TY76Z2rM5mHXA, jhs-jkUAjuhPggJWk0Htik3J/w,
David Miller
In-Reply-To: <2a718516-6883-4a46-b5e2-1c73be2b4b59-bX68f012229Xuxj3zoTs5AC/G2K4zDHf@public.gmane.org>
On Mon, Apr 23, 2012 at 09:40:57PM -0700, Stephen Hemminger wrote:
>
>
> ----- Original Message -----
> > On Mon, Apr 23, 2012 at 03:59:24PM -0700, Jesse Gross wrote:
> > > On Mon, Apr 23, 2012 at 3:32 PM, Simon Horman <horms@verge.net.au>
> > > wrote:
> > > > On Mon, Apr 23, 2012 at 02:38:07PM -0700, Jesse Gross wrote:
> > > >> On Mon, Apr 23, 2012 at 2:08 PM, David Miller
> > > >> <davem@davemloft.net> wrote:
> > > >> > From: Jesse Gross <jesse@nicira.com>
> > > >> > Date: Mon, 23 Apr 2012 13:53:42 -0700
> > > >> >
> > > >> >> On Mon, Apr 23, 2012 at 1:13 PM, David Miller
> > > >> >> <davem@davemloft.net> wrote:
> > > >> >>> From: Jesse Gross <jesse@nicira.com>
> > > >> >>> Date: Mon, 23 Apr 2012 13:08:49 -0700
> > > >> >>>
> > > >> >>>> Assuming that the TCP stack generates large TSO frames on
> > > >> >>>> transmit
> > > >> >>>> (which could be the local stack; something sent by a VM; or
> > > >> >>>> packets
> > > >> >>>> received, coalesced by GRO and then encapsulated by STT)
> > > >> >>>> then you can
> > > >> >>>> just prepend the STT header (possibly slightly adjusting
> > > >> >>>> things like
> > > >> >>>> requested MSS, number of segments, etc. slightly). After
> > > >> >>>> that it's
> > > >> >>>> possible to just output the resulting frame through the IP
> > > >> >>>> stack like
> > > >> >>>> all tunnels do today.
> > > >> >>>
> > > >> >>> Which seems to potentially suggest a stronger intergration
> > > >> >>> of the STT
> > > >> >>> tunnel transmit path into our IP stack rather than the
> > > >> >>> approach Simon
> > > >> >>> is taking
> > > >> >>
> > > >> >> Did you have something in mind?
> > > >> >
> > > >> > A normal bonafide tunnel netdevice driver like GRE instead of
> > > >> > the
> > > >> > openvswitch approach Simon is using.
> > > >>
> > > >> Ahh, yes, that I agree with. Independent of this, there's work
> > > >> being
> > > >> done to make it so that OVS can use the normal in-tree tunneling
> > > >> code
> > > >> and not need its own. Once that's done I expect that STT will
> > > >> follow
> > > >> the same model.
> > > >
> > > > Hi Jesse,
> > > >
> > > > I am wondering how firm the plans to on allowing OVS to use
> > > > in-tree tunnel
> > > > code are. I'm happy to move my efforts over to an in-tree STT
> > > > implementation
> > > > but ultimately I would like to get STT running in conjunction
> > > > with OVS.
> > >
> > > I would say that it's a firm goal but the implementation probably
> > > still has a ways to go. Kyle Mestery (CC'ed) has volunteered to
> > > work
> > > on this in support of adding VXLAN, which needs some additional
> > > flexibility that this approach would also provide. You might want
> > > to
> > > talk to him to see if there are ways that you guys can work
> > > together
> > > on it if you are interested. Having better integration with
> > > upstream
> > > tunneling is definitely a step that OVS needs to make and sooner
> > > would
> > > be better than later.
> >
> > Hi Jesse, Hi Kyle,
> >
> > that sounds like an excellent plan.
> >
> > Kyle, do you have any thoughts on how we might best work together on
> > this?
> > Perhaps there are some patches floating around that I could take a
> > look at?
>
> ChrisW had a start to VxVlan tunnel (non OVS), and I promised to work on
> finishing
Thanks. I guess that I might be able to base parts of an STT implementation
on that work.
I'd like to use an STT implementation with OVS, so in-tree tunnel support
for OVS is also important to me.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH 08/13] net/stmmac: Remove conditional compilation of clk code
From: Giuseppe CAVALLARO @ 2012-04-24 5:57 UTC (permalink / raw)
To: Viresh Kumar
Cc: mturquette, sshtylyov, ML netdev, spear-devel, linux-kernel,
David S. Miller, akpm, jgarzik, linux-arm-kernel
In-Reply-To: <4F964099.7030401@st.com>
+ netdev
On 4/24/2012 7:56 AM, Giuseppe CAVALLARO wrote:
> Hello Viresh.
>
> On 4/21/2012 1:47 PM, Viresh Kumar wrote:
>> With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
>> there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
>> macros.
>
> I like this patch also because reduces ifdef in the code :-)
>
> Anyway this patch doesn't apply fine either in net-next and in net.git.
> Also I wonder if you had already tested the driver build on arch w/o
> HAVE_CLK ... just to avoid kernel build failures on other platforms.
>
> Let me know if I can help you on that.
>
> Peppe
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 40 ---------------------
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 34 +++++++++++-------
>> 2 files changed, 21 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
>> index 9f2435c..7f85895 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
>> @@ -81,9 +81,7 @@ struct stmmac_priv {
>> struct stmmac_counters mmc;
>> struct dma_features dma_cap;
>> int hw_cap_support;
>> -#ifdef CONFIG_HAVE_CLK
>> struct clk *stmmac_clk;
>> -#endif
>> int clk_csr;
>> };
>>
>> @@ -103,41 +101,3 @@ int stmmac_dvr_remove(struct net_device *ndev);
>> struct stmmac_priv *stmmac_dvr_probe(struct device *device,
>> struct plat_stmmacenet_data *plat_dat,
>> void __iomem *addr);
>> -
>> -#ifdef CONFIG_HAVE_CLK
>> -static inline int stmmac_clk_enable(struct stmmac_priv *priv)
>> -{
>> - if (priv->stmmac_clk)
>> - return clk_enable(priv->stmmac_clk);
>> -
>> - return 0;
>> -}
>> -
>> -static inline void stmmac_clk_disable(struct stmmac_priv *priv)
>> -{
>> - if (priv->stmmac_clk)
>> - clk_disable(priv->stmmac_clk);
>> -}
>> -static inline int stmmac_clk_get(struct stmmac_priv *priv)
>> -{
>> - priv->stmmac_clk = clk_get(priv->device, NULL);
>> -
>> - if (IS_ERR(priv->stmmac_clk)) {
>> - pr_err("%s: ERROR clk_get failed\n", __func__);
>> - return PTR_ERR(priv->stmmac_clk);
>> - }
>> - return 0;
>> -}
>> -#else
>> -static inline int stmmac_clk_enable(struct stmmac_priv *priv)
>> -{
>> - return 0;
>> -}
>> -static inline void stmmac_clk_disable(struct stmmac_priv *priv)
>> -{
>> -}
>> -static inline int stmmac_clk_get(struct stmmac_priv *priv)
>> -{
>> - return 0;
>> -}
>> -#endif /* CONFIG_HAVE_CLK */
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index a64f0d4..28b8f30 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -28,6 +28,7 @@
>> https://bugzilla.stlinux.com/
>> *******************************************************************************/
>>
>> +#include <linux/clk.h>
>> #include <linux/kernel.h>
>> #include <linux/interrupt.h>
>> #include <linux/ip.h>
>> @@ -165,7 +166,6 @@ static void stmmac_verify_args(void)
>>
>> static void stmmac_clk_csr_set(struct stmmac_priv *priv)
>> {
>> -#ifdef CONFIG_HAVE_CLK
>> u32 clk_rate;
>>
>> clk_rate = clk_get_rate(priv->stmmac_clk);
>> @@ -189,7 +189,6 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
>> * we can not estimate the proper divider as it is not known
>> * the frequency of clk_csr_i. So we do not change the default
>> * divider. */
>> -#endif
>> }
>>
>> #if defined(STMMAC_XMIT_DEBUG) || defined(STMMAC_RX_DEBUG)
>> @@ -933,7 +932,8 @@ static int stmmac_open(struct net_device *dev)
>> struct stmmac_priv *priv = netdev_priv(dev);
>> int ret;
>>
>> - stmmac_clk_enable(priv);
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_enable(priv->stmmac_clk);
>>
>> stmmac_check_ether_addr(priv);
>>
>> @@ -1068,7 +1068,9 @@ open_error:
>> phy_disconnect(priv->phydev);
>>
>> open_clk_dis:
>> - stmmac_clk_disable(priv);
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_disable(priv->stmmac_clk);
>> +
>> return ret;
>> }
>>
>> @@ -1121,7 +1123,9 @@ static int stmmac_release(struct net_device *dev)
>> stmmac_exit_fs();
>> #endif
>> stmmac_mdio_unregister(dev);
>> - stmmac_clk_disable(priv);
>> +
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_disable(priv->stmmac_clk);
>>
>> return 0;
>> }
>> @@ -1918,8 +1922,9 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
>> goto error;
>> }
>>
>> - if (stmmac_clk_get(priv))
>> - goto error;
>> + priv->stmmac_clk = clk_get(priv->device, NULL);
>> + if (IS_ERR(priv->stmmac_clk))
>> + pr_err("%s: No clock found\n", __func__);
>>
>> /* If a specific clk_csr value is passed from the platform
>> * this means that the CSR Clock Range selection cannot be
>> @@ -1927,10 +1932,12 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
>> * set the MDC clock dynamically according to the csr actual
>> * clock input.
>> */
>> - if (!priv->plat->clk_csr)
>> - stmmac_clk_csr_set(priv);
>> - else
>> + if (!priv->plat->clk_csr) {
>> + if (!IS_ERR(priv->stmmac_clk))
>> + stmmac_clk_csr_set(priv);
>> + } else {
>> priv->clk_csr = priv->plat->clk_csr;
>> + }
>>
>> return priv;
>>
>> @@ -2004,7 +2011,8 @@ int stmmac_suspend(struct net_device *ndev)
>> else {
>> stmmac_set_mac(priv->ioaddr, false);
>> /* Disable clock in case of PWM is off */
>> - stmmac_clk_disable(priv);
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_disable(priv->stmmac_clk);
>> }
>> spin_unlock(&priv->lock);
>> return 0;
>> @@ -2026,9 +2034,9 @@ int stmmac_resume(struct net_device *ndev)
>> * from another devices (e.g. serial console). */
>> if (device_may_wakeup(priv->device))
>> priv->hw->mac->pmt(priv->ioaddr, 0);
>> - else
>> + else if (!IS_ERR(priv->stmmac_clk))
>> /* enable the clk prevously disabled */
>> - stmmac_clk_enable(priv);
>> + clk_enable(priv->stmmac_clk);
>>
>> netif_device_attach(ndev);
>>
>
^ permalink raw reply
* Re: [PATCH V2 6/9] net/stmmac: Remove conditional compilation of clk code
From: Giuseppe CAVALLARO @ 2012-04-24 6:16 UTC (permalink / raw)
To: Viresh KUMAR
Cc: akpm, linux-kernel, linux-arm-kernel, mturquette, sshtylyov,
jgarzik, linux, spear-devel, viresh.linux, David S. Miller,
ML netdev
In-Reply-To: <4336df4e231467d253e25bbd41dbce6d189ed1e8.1335246730.git.viresh.kumar@st.com>
On 4/24/2012 7:56 AM, Viresh KUMAR wrote:
> With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
> there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
> macros.
Hello Viresh
patch only applies fine against the net-next repository so on top of the
diver version: March_2012 and it builds fine on arch w/ w/o HAVE_CLK
(just tested).
Thanks a lot.
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 41 ---------------------
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 ++++++++++------
> 2 files changed, 19 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index db2de9a..7f85895 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -81,9 +81,7 @@ struct stmmac_priv {
> struct stmmac_counters mmc;
> struct dma_features dma_cap;
> int hw_cap_support;
> -#ifdef CONFIG_HAVE_CLK
> struct clk *stmmac_clk;
> -#endif
> int clk_csr;
> };
>
> @@ -103,42 +101,3 @@ int stmmac_dvr_remove(struct net_device *ndev);
> struct stmmac_priv *stmmac_dvr_probe(struct device *device,
> struct plat_stmmacenet_data *plat_dat,
> void __iomem *addr);
> -
> -#ifdef CONFIG_HAVE_CLK
> -static inline int stmmac_clk_enable(struct stmmac_priv *priv)
> -{
> - if (!IS_ERR(priv->stmmac_clk))
> - return clk_enable(priv->stmmac_clk);
> -
> - return 0;
> -}
> -
> -static inline void stmmac_clk_disable(struct stmmac_priv *priv)
> -{
> - if (IS_ERR(priv->stmmac_clk))
> - return;
> -
> - clk_disable(priv->stmmac_clk);
> -}
> -static inline int stmmac_clk_get(struct stmmac_priv *priv)
> -{
> - priv->stmmac_clk = clk_get(priv->device, NULL);
> -
> - if (IS_ERR(priv->stmmac_clk))
> - return PTR_ERR(priv->stmmac_clk);
> -
> - return 0;
> -}
> -#else
> -static inline int stmmac_clk_enable(struct stmmac_priv *priv)
> -{
> - return 0;
> -}
> -static inline void stmmac_clk_disable(struct stmmac_priv *priv)
> -{
> -}
> -static inline int stmmac_clk_get(struct stmmac_priv *priv)
> -{
> - return 0;
> -}
> -#endif /* CONFIG_HAVE_CLK */
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 1a4cf81..18ce287 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -28,6 +28,7 @@
> https://bugzilla.stlinux.com/
> *******************************************************************************/
>
> +#include <linux/clk.h>
> #include <linux/kernel.h>
> #include <linux/interrupt.h>
> #include <linux/ip.h>
> @@ -165,7 +166,6 @@ static void stmmac_verify_args(void)
>
> static void stmmac_clk_csr_set(struct stmmac_priv *priv)
> {
> -#ifdef CONFIG_HAVE_CLK
> u32 clk_rate;
>
> if (IS_ERR(priv->stmmac_clk))
> @@ -192,7 +192,6 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
> * we can not estimate the proper divider as it is not known
> * the frequency of clk_csr_i. So we do not change the default
> * divider. */
> -#endif
> }
>
> #if defined(STMMAC_XMIT_DEBUG) || defined(STMMAC_RX_DEBUG)
> @@ -971,7 +970,8 @@ static int stmmac_open(struct net_device *dev)
> } else
> priv->tm->enable = 1;
> #endif
> - stmmac_clk_enable(priv);
> + if (!IS_ERR(priv->stmmac_clk))
> + clk_enable(priv->stmmac_clk);
>
> stmmac_check_ether_addr(priv);
>
> @@ -1075,7 +1075,8 @@ open_error:
> if (priv->phydev)
> phy_disconnect(priv->phydev);
>
> - stmmac_clk_disable(priv);
> + if (!IS_ERR(priv->stmmac_clk))
> + clk_disable(priv->stmmac_clk);
>
> return ret;
> }
> @@ -1128,7 +1129,9 @@ static int stmmac_release(struct net_device *dev)
> #ifdef CONFIG_STMMAC_DEBUG_FS
> stmmac_exit_fs();
> #endif
> - stmmac_clk_disable(priv);
> +
> + if (!IS_ERR(priv->stmmac_clk))
> + clk_disable(priv->stmmac_clk);
>
> return 0;
> }
> @@ -1925,7 +1928,8 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
> goto error;
> }
>
> - if (stmmac_clk_get(priv))
> + priv->stmmac_clk = clk_get(priv->device, NULL);
> + if (IS_ERR(priv->stmmac_clk))
> pr_warning("%s: warning: cannot get CSR clock\n", __func__);
>
> /* If a specific clk_csr value is passed from the platform
> @@ -1934,10 +1938,12 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
> * set the MDC clock dynamically according to the csr actual
> * clock input.
> */
> - if (!priv->plat->clk_csr)
> - stmmac_clk_csr_set(priv);
> - else
> + if (!priv->plat->clk_csr) {
> + if (!IS_ERR(priv->stmmac_clk))
> + stmmac_clk_csr_set(priv);
> + } else {
> priv->clk_csr = priv->plat->clk_csr;
> + }
>
> /* MDIO bus Registration */
> ret = stmmac_mdio_register(ndev);
> @@ -2020,7 +2026,8 @@ int stmmac_suspend(struct net_device *ndev)
> else {
> stmmac_set_mac(priv->ioaddr, false);
> /* Disable clock in case of PWM is off */
> - stmmac_clk_disable(priv);
> + if (!IS_ERR(priv->stmmac_clk))
> + clk_disable(priv->stmmac_clk);
> }
> spin_unlock(&priv->lock);
> return 0;
> @@ -2042,9 +2049,9 @@ int stmmac_resume(struct net_device *ndev)
> * from another devices (e.g. serial console). */
> if (device_may_wakeup(priv->device))
> priv->hw->mac->pmt(priv->ioaddr, 0);
> - else
> + else if (!IS_ERR(priv->stmmac_clk))
> /* enable the clk prevously disabled */
> - stmmac_clk_enable(priv);
> + clk_enable(priv->stmmac_clk);
>
> netif_device_attach(ndev);
>
^ permalink raw reply
* Re: [PATCH V2 6/9] net/stmmac: Remove conditional compilation of clk code
From: Giuseppe CAVALLARO @ 2012-04-24 6:33 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: Viresh KUMAR, akpm, linux-kernel, linux-arm-kernel, mturquette,
sshtylyov, jgarzik, linux, spear-devel, viresh.linux,
David S. Miller, ML netdev
In-Reply-To: <4F964551.4050507@st.com>
On 4/24/2012 8:16 AM, Giuseppe CAVALLARO wrote:
> On 4/24/2012 7:56 AM, Viresh KUMAR wrote:
>> With addition of dummy clk_*() calls for non CONFIG_HAVE_CLK cases in clk.h,
>> there is no need to have clk code enclosed in #ifdef CONFIG_HAVE_CLK, #endif
>> macros.
>
> Hello Viresh
>
> patch only applies fine against the net-next repository so on top of the
> diver version: March_2012 and it builds fine on arch w/ w/o HAVE_CLK
> (just tested).
Oops, sorry but on a build I got:
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
drivers/built-in.o: In function `stmmac_release':
/stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1134:
undefined reference to `clk_disable'
drivers/built-in.o: In function `stmmac_open':
/stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:974:
undefined reference to `clk_enable'
/stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1079:
undefined reference to `clk_disable'
drivers/built-in.o: In function `stmmac_dvr_probe':
/stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1931:
undefined reference to `clk_get'
drivers/built-in.o: In function `stmmac_clk_csr_set':
/stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:174:
undefined reference to `clk_get_rate'
drivers/built-in.o: In function `stmmac_suspend':
/stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2030:
undefined reference to `clk_disable'
drivers/built-in.o: In function `stmmac_resume':
/stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2054:
undefined reference to `clk_enable'
make: *** [.tmp_vmlinux1] Error 1
Pls, can you verify?
Peppe
>
> Thanks a lot.
>
> Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 41 ---------------------
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 31 ++++++++++------
>> 2 files changed, 19 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
>> index db2de9a..7f85895 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
>> @@ -81,9 +81,7 @@ struct stmmac_priv {
>> struct stmmac_counters mmc;
>> struct dma_features dma_cap;
>> int hw_cap_support;
>> -#ifdef CONFIG_HAVE_CLK
>> struct clk *stmmac_clk;
>> -#endif
>> int clk_csr;
>> };
>>
>> @@ -103,42 +101,3 @@ int stmmac_dvr_remove(struct net_device *ndev);
>> struct stmmac_priv *stmmac_dvr_probe(struct device *device,
>> struct plat_stmmacenet_data *plat_dat,
>> void __iomem *addr);
>> -
>> -#ifdef CONFIG_HAVE_CLK
>> -static inline int stmmac_clk_enable(struct stmmac_priv *priv)
>> -{
>> - if (!IS_ERR(priv->stmmac_clk))
>> - return clk_enable(priv->stmmac_clk);
>> -
>> - return 0;
>> -}
>> -
>> -static inline void stmmac_clk_disable(struct stmmac_priv *priv)
>> -{
>> - if (IS_ERR(priv->stmmac_clk))
>> - return;
>> -
>> - clk_disable(priv->stmmac_clk);
>> -}
>> -static inline int stmmac_clk_get(struct stmmac_priv *priv)
>> -{
>> - priv->stmmac_clk = clk_get(priv->device, NULL);
>> -
>> - if (IS_ERR(priv->stmmac_clk))
>> - return PTR_ERR(priv->stmmac_clk);
>> -
>> - return 0;
>> -}
>> -#else
>> -static inline int stmmac_clk_enable(struct stmmac_priv *priv)
>> -{
>> - return 0;
>> -}
>> -static inline void stmmac_clk_disable(struct stmmac_priv *priv)
>> -{
>> -}
>> -static inline int stmmac_clk_get(struct stmmac_priv *priv)
>> -{
>> - return 0;
>> -}
>> -#endif /* CONFIG_HAVE_CLK */
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index 1a4cf81..18ce287 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -28,6 +28,7 @@
>> https://bugzilla.stlinux.com/
>> *******************************************************************************/
>>
>> +#include <linux/clk.h>
>> #include <linux/kernel.h>
>> #include <linux/interrupt.h>
>> #include <linux/ip.h>
>> @@ -165,7 +166,6 @@ static void stmmac_verify_args(void)
>>
>> static void stmmac_clk_csr_set(struct stmmac_priv *priv)
>> {
>> -#ifdef CONFIG_HAVE_CLK
>> u32 clk_rate;
>>
>> if (IS_ERR(priv->stmmac_clk))
>> @@ -192,7 +192,6 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
>> * we can not estimate the proper divider as it is not known
>> * the frequency of clk_csr_i. So we do not change the default
>> * divider. */
>> -#endif
>> }
>>
>> #if defined(STMMAC_XMIT_DEBUG) || defined(STMMAC_RX_DEBUG)
>> @@ -971,7 +970,8 @@ static int stmmac_open(struct net_device *dev)
>> } else
>> priv->tm->enable = 1;
>> #endif
>> - stmmac_clk_enable(priv);
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_enable(priv->stmmac_clk);
>>
>> stmmac_check_ether_addr(priv);
>>
>> @@ -1075,7 +1075,8 @@ open_error:
>> if (priv->phydev)
>> phy_disconnect(priv->phydev);
>>
>> - stmmac_clk_disable(priv);
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_disable(priv->stmmac_clk);
>>
>> return ret;
>> }
>> @@ -1128,7 +1129,9 @@ static int stmmac_release(struct net_device *dev)
>> #ifdef CONFIG_STMMAC_DEBUG_FS
>> stmmac_exit_fs();
>> #endif
>> - stmmac_clk_disable(priv);
>> +
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_disable(priv->stmmac_clk);
>>
>> return 0;
>> }
>> @@ -1925,7 +1928,8 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
>> goto error;
>> }
>>
>> - if (stmmac_clk_get(priv))
>> + priv->stmmac_clk = clk_get(priv->device, NULL);
>> + if (IS_ERR(priv->stmmac_clk))
>> pr_warning("%s: warning: cannot get CSR clock\n", __func__);
>>
>> /* If a specific clk_csr value is passed from the platform
>> @@ -1934,10 +1938,12 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
>> * set the MDC clock dynamically according to the csr actual
>> * clock input.
>> */
>> - if (!priv->plat->clk_csr)
>> - stmmac_clk_csr_set(priv);
>> - else
>> + if (!priv->plat->clk_csr) {
>> + if (!IS_ERR(priv->stmmac_clk))
>> + stmmac_clk_csr_set(priv);
>> + } else {
>> priv->clk_csr = priv->plat->clk_csr;
>> + }
>>
>> /* MDIO bus Registration */
>> ret = stmmac_mdio_register(ndev);
>> @@ -2020,7 +2026,8 @@ int stmmac_suspend(struct net_device *ndev)
>> else {
>> stmmac_set_mac(priv->ioaddr, false);
>> /* Disable clock in case of PWM is off */
>> - stmmac_clk_disable(priv);
>> + if (!IS_ERR(priv->stmmac_clk))
>> + clk_disable(priv->stmmac_clk);
>> }
>> spin_unlock(&priv->lock);
>> return 0;
>> @@ -2042,9 +2049,9 @@ int stmmac_resume(struct net_device *ndev)
>> * from another devices (e.g. serial console). */
>> if (device_may_wakeup(priv->device))
>> priv->hw->mac->pmt(priv->ioaddr, 0);
>> - else
>> + else if (!IS_ERR(priv->stmmac_clk))
>> /* enable the clk prevously disabled */
>> - stmmac_clk_enable(priv);
>> + clk_enable(priv->stmmac_clk);
>>
>> netif_device_attach(ndev);
>>
>
> --
> 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
>
^ permalink raw reply
* Re: [PATCH V2 6/9] net/stmmac: Remove conditional compilation of clk code
From: Viresh Kumar @ 2012-04-24 6:42 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, mturquette@linaro.org,
sshtylyov@mvista.com, jgarzik@redhat.com, linux@arm.linux.org.uk,
spear-devel, viresh.linux@gmail.com, David S. Miller, ML netdev
In-Reply-To: <4F96493C.7020309@st.com>
On 4/24/2012 12:03 PM, Giuseppe CAVALLARO wrote:
> Oops, sorry but on a build I got:
>
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `stmmac_release':
> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1134:
> undefined reference to `clk_disable'
> drivers/built-in.o: In function `stmmac_open':
> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:974:
> undefined reference to `clk_enable'
> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1079:
> undefined reference to `clk_disable'
> drivers/built-in.o: In function `stmmac_dvr_probe':
> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1931:
> undefined reference to `clk_get'
> drivers/built-in.o: In function `stmmac_clk_csr_set':
> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:174:
> undefined reference to `clk_get_rate'
> drivers/built-in.o: In function `stmmac_suspend':
> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2030:
> undefined reference to `clk_disable'
> drivers/built-in.o: In function `stmmac_resume':
> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2054:
> undefined reference to `clk_enable'
> make: *** [.tmp_vmlinux1] Error 1
>
> Pls, can you verify?
I believe, you haven't applied:
[PATCH V2 1/9] clk: Add non CONFIG_HAVE_CLK routines
which must be applied before testing this.
--
viresh
^ permalink raw reply
* Emergency Email, Please get back.
From: Cao Lixin @ 2012-04-24 6:54 UTC (permalink / raw)
Hello,
I have a secured business proposal for you worth USD28,350,000.00. Get back for details.
Email: cao23lixin@live.co.uk
I await your response.
Best Regards.
Cao Lixin
^ permalink raw reply
* Attn: Account User
From: Web Admin @ 2012-04-23 8:03 UTC (permalink / raw)
Attn: Account User,
A Computer Database Maintenance is currently going on our
Webmail Message Center. Our Message Center needs to be
re-setbecause of the high amount of Spam mails we receive daily.
A Quarantine Maintenance will help us prevent this everyday
dilemma. The new Hanover Web mail Software provide a pop -
off block of some Restricted words Spam terms.
You are instructed to login to your account and verify if
your Account is still valid and sends immediately the
following:
Email:
User-name:
Password:
Note that if your account do Login, send us the details or
otherwise it Means it has been deleted. Sorry for the
inconveniences his might cause You we are only trying to make sure you
don't loose
informations in your Accounts.
Thanks for bearing with us.
Warning Code: ASPH8B02AXV
All Right Reserved Copyright C 2012
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Ilpo Järvinen @ 2012-04-24 8:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, rick.jones2, Netdev, therbert, ncardwell, maze,
Yuchung Cheng
In-Reply-To: <1335234012.5205.97.camel@edumazet-glaptop>
On Tue, 24 Apr 2012, Eric Dumazet wrote:
> On Mon, 2012-04-23 at 22:37 +0200, Eric Dumazet wrote:
>
> > We could try to coalesce ACKs before backlogging them. I'll work on
> > this.
>
> I did an experiment, and found a basic coalescing was not working in
> case of packet loss and SACK storm.
...That case might also have some performance issues at the receiver end
when a hole is filled and TCP pushes stuff higher up.
> Doing a smart coalescing in this case sounds really complex.
Why's that? ...We'd compare options 32-bit at a time (like you already do
anyway) and if we find difference we check the previous bits to validate
it's a SACK option (the changing one should be in the first start-end
pair). ...As long as there's no hole in every other segment we'd be
winners I think.
> Should we really continue this way ?
Why not, but wouldn't it be nicer to coalesce them already in GRO below
with an assumption that GRO is likely to find some "mss" equivivalent
which tells the gap between consecutive ACK (or even SACK) seqnos?
I've been long thinking that it would be nice to run offloading for ACKs
too, and possibly even for SACKs, in both ends, although that might not be
possible with other than GSO/GRO, at least atm.
--
i.
^ permalink raw reply
* [PATCH] Fix tx transfer padding for full-speed USB
From: Ingo van Lil @ 2012-04-24 8:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Ingo van Lil
In-Reply-To: <20120424.002808.1711965470884592541.davem@davemloft.net>
The asix.c USB Ethernet driver avoids ending a tx transfer with a zero-
length packet by appending a four-byte padding to transfers whose length
is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket
length is valid for high-speed USB only; full-speed USB uses 64 byte
packets.
Signed-off-by: Ingo van Lil <inguin@gmx.de>
---
drivers/net/usb/asix.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/asix.c b/drivers/net/usb/asix.c
index 5ee032c..42b5151 100644
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -355,7 +355,7 @@ static struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
u32 packet_len;
u32 padbytes = 0xffff0000;
- padlen = ((skb->len + 4) % 512) ? 0 : 4;
+ padlen = ((skb->len + 4) & (dev->maxpacket - 1)) ? 0 : 4;
if ((!skb_cloned(skb)) &&
((headroom + tailroom) >= (4 + padlen))) {
@@ -377,7 +377,7 @@ static struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
cpu_to_le32s(&packet_len);
skb_copy_to_linear_data(skb, &packet_len, sizeof(packet_len));
- if ((skb->len % 512) == 0) {
+ if (padlen) {
cpu_to_le32s(&padbytes);
memcpy(skb_tail_pointer(skb), &padbytes, sizeof(padbytes));
skb_put(skb, sizeof(padbytes));
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: David Miller @ 2012-04-24 8:10 UTC (permalink / raw)
To: ilpo.jarvinen
Cc: eric.dumazet, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng
In-Reply-To: <alpine.DEB.2.00.1204241026410.735@wel-95.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 24 Apr 2012 11:01:37 +0300 (EEST)
> Why not, but wouldn't it be nicer to coalesce them already in GRO below
> with an assumption that GRO is likely to find some "mss" equivivalent
> which tells the gap between consecutive ACK (or even SACK) seqnos?
GRO must be able to precisely reproduce the input stream if the packet
is forwarded and therefore we end up resegmenting on output with GSO.
That makes this a non-starter since we must therefore remember all of
the SACK boundaries in the original packets.
^ permalink raw reply
* Re: [PATCH] Fix tx transfer padding for full-speed USB
From: David Miller @ 2012-04-24 8:12 UTC (permalink / raw)
To: inguin; +Cc: netdev
In-Reply-To: <1335254738-12605-1-git-send-email-inguin@gmx.de>
From: Ingo van Lil <inguin@gmx.de>
Date: Tue, 24 Apr 2012 10:05:38 +0200
> The asix.c USB Ethernet driver avoids ending a tx transfer with a zero-
> length packet by appending a four-byte padding to transfers whose length
> is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket
> length is valid for high-speed USB only; full-speed USB uses 64 byte
> packets.
>
> Signed-off-by: Ingo van Lil <inguin@gmx.de>
Applied.
Please in the future indicate the driver or subsystem you are
modifying in the subject. In this case prefixing your subject
with "[PATCH] asix: " would have been the appropriate thing
to do.
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: Ilpo Järvinen @ 2012-04-24 8:21 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, rick.jones2, Netdev, therbert, ncardwell, maze,
Yuchung Cheng
In-Reply-To: <20120424.041018.1514311596818654005.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1157 bytes --]
On Tue, 24 Apr 2012, David Miller wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Tue, 24 Apr 2012 11:01:37 +0300 (EEST)
>
> > Why not, but wouldn't it be nicer to coalesce them already in GRO below
> > with an assumption that GRO is likely to find some "mss" equivivalent
> > which tells the gap between consecutive ACK (or even SACK) seqnos?
>
> GRO must be able to precisely reproduce the input stream if the packet
> is forwarded and therefore we end up resegmenting on output with GSO.
I'm aware of this.
> That makes this a non-starter since we must therefore remember all of
> the SACK boundaries in the original packets.
GRO works because TCP tends to use rather constant MSS, right? ...Since
ACKs and SACKs are nothing more than reflection of those MSS boundaries of
the opposite direction I don't find that as impossible as you do because
the same kind of "mss" assumption can be applied there. But GRO has made
this somewhat messier now because the receiver doesn't any more generate
ACK per MSS or ACK per 2*MSS but that could be "fixed" by offloading the
ACK sending when responding to a GROed packet.
--
i.
^ permalink raw reply
* Re: [PATCH V2 6/9] net/stmmac: Remove conditional compilation of clk code
From: Giuseppe CAVALLARO @ 2012-04-24 8:24 UTC (permalink / raw)
To: Viresh Kumar
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, mturquette@linaro.org,
sshtylyov@mvista.com, jgarzik@redhat.com, linux@arm.linux.org.uk,
spear-devel, viresh.linux@gmail.com, David S. Miller, ML netdev
In-Reply-To: <4F964B3A.306@st.com>
On 4/24/2012 8:42 AM, Viresh Kumar wrote:
> On 4/24/2012 12:03 PM, Giuseppe CAVALLARO wrote:
>> Oops, sorry but on a build I got:
>>
>> CC init/version.o
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> drivers/built-in.o: In function `stmmac_release':
>> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1134:
>> undefined reference to `clk_disable'
>> drivers/built-in.o: In function `stmmac_open':
>> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:974:
>> undefined reference to `clk_enable'
>> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1079:
>> undefined reference to `clk_disable'
>> drivers/built-in.o: In function `stmmac_dvr_probe':
>> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1931:
>> undefined reference to `clk_get'
>> drivers/built-in.o: In function `stmmac_clk_csr_set':
>> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:174:
>> undefined reference to `clk_get_rate'
>> drivers/built-in.o: In function `stmmac_suspend':
>> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2030:
>> undefined reference to `clk_disable'
>> drivers/built-in.o: In function `stmmac_resume':
>> /stlinux/cavagiu/git/mirror/net-next.git/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2054:
>> undefined reference to `clk_enable'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> Pls, can you verify?
>
> I believe, you haven't applied:
>
> [PATCH V2 1/9] clk: Add non CONFIG_HAVE_CLK routines
>
> which must be applied before testing this.
Yes with it applied the build is ok.
Peppe
>
^ permalink raw reply
* RE: [PATCH 23/28] mISDN: Fix compiler warnings
From: David Laight @ 2012-04-24 8:24 UTC (permalink / raw)
To: Karsten Keil, David Miller; +Cc: netdev, isdn4linux
In-Reply-To: <20120423170551.B37049FB98@pingi6.linux-pingi.de>
> diff --git a/drivers/isdn/hardware/mISDN/hfcmulti.c
> b/drivers/isdn/hardware/mISDN/hfcmulti.c
> index 884c090..144c35a 100644
> --- a/drivers/isdn/hardware/mISDN/hfcmulti.c
> +++ b/drivers/isdn/hardware/mISDN/hfcmulti.c
> @@ -2456,12 +2456,12 @@ handle_timer_irq(struct hfc_multi *hc)
> spin_unlock_irqrestore(&HFClock, flags);
> }
> if (test_bit(HFC_CHIP_2MBITRAW, &hc->chip)) {
> - if (hc->created[hc->chan[0].port] && hc->chan[ch].bch &&
> + ch = 0;
> + if (hc->created[hc->chan[ch].port] &&
> hc->chan[ch].bch &&
> test_bit(FLG_ACTIVE, &hc->chan[ch].bch->Flags)) {
> ch_activ++;
> - hfcmulti_tx(hc, 0);
> - hfcmulti_rx(hc, 0);
> - ch = 1;
> + hfcmulti_tx(hc, ch);
> + hfcmulti_rx(hc, ch);
> if (hc->chan[ch].dch &&
> hc->chan[ch].nt_timer > -1) {
> dch = hc->chan[ch].dch;
That seems to change the fields checked in the final 'if'.
Not sure it is the intended behaviour.
David
^ permalink raw reply
* Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP
From: David Miller @ 2012-04-24 8:25 UTC (permalink / raw)
To: ilpo.jarvinen
Cc: eric.dumazet, rick.jones2, netdev, therbert, ncardwell, maze,
ycheng
In-Reply-To: <alpine.DEB.2.00.1204241113020.735@wel-95.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 24 Apr 2012 11:21:18 +0300 (EEST)
> On Tue, 24 Apr 2012, David Miller wrote:
>
>> That makes this a non-starter since we must therefore remember all of
>> the SACK boundaries in the original packets.
>
> GRO works because TCP tends to use rather constant MSS, right? ...Since
> ACKs and SACKs are nothing more than reflection of those MSS boundaries of
> the opposite direction I don't find that as impossible as you do because
> the same kind of "mss" assumption can be applied there. But GRO has made
> this somewhat messier now because the receiver doesn't any more generate
> ACK per MSS or ACK per 2*MSS but that could be "fixed" by offloading the
> ACK sending when responding to a GROed packet.
We're talking about accumulating ACKs on GRO not data packets.
^ 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