* 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
* 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: 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 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: [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: 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: [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: [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/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 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-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: [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: 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: [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 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 1/2 net-next] af_netlink: cleanups
From: David Miller @ 2012-04-24 4:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1335166221.3293.13.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 23 Apr 2012 09:30:21 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> netlink_destroy_callback() move to avoid forward reference
>
> CodingStyle cleanups
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [patch 0/2] s390: qeth bug fixes for net
From: David Miller @ 2012-04-24 4:33 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20120423072140.297458261@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Mon, 23 Apr 2012 09:21:40 +0200
> here are two small qeth bug fixes for net.
>
> shortlog:
>
> Ursula Braun (1)
> qeth: allow change of blkt default values
>
> Stefan Raspl (1)
> qeth: Use blkt defaults for OSA Express 4
Both applied, thanks Frank.
^ permalink raw reply
* Re: [PATCH] net: usb: smsc95xx: fix mtu
From: David Miller @ 2012-04-24 4:29 UTC (permalink / raw)
To: fillods; +Cc: netdev, steve.glendinning
In-Reply-To: <20120420193923.GQ5277@charybde.local>
From: Stephane Fillod <fillods@users.sf.net>
Date: Fri, 20 Apr 2012 21:39:23 +0200
> Make smsc95xx recalculate the hard_mtu after adjusting the
> hard_header_len.
>
> Without this, usbnet adjusts the MTU down to 1488 bytes, and the host is
> unable to receive standard 1500-byte frames from the device.
>
> Inspired by same fix on cdc_eem 78fb72f7936c01d5b426c03a691eca082b03f2b9.
>
> Tested on ARM/Beagle.
>
> Signed-off-by: Stephane Fillod <fillods@users.sf.net>
Applied, thanks.
Ok, now we've made this fix to 2 or 3 USB net drivers, can someone
audit to see if any more remain?
^ permalink raw reply
* Re: [PATCH] Fix tx transfer padding for full-speed USB
From: David Miller @ 2012-04-24 4:28 UTC (permalink / raw)
To: inguin; +Cc: netdev
In-Reply-To: <1334916021-9124-1-git-send-email-inguin@gmx.de>
From: Ingo van Lil <inguin@gmx.de>
Date: Fri, 20 Apr 2012 12:00:21 +0200
> - padlen = ((skb->len + 4) % 512) ? 0 : 4;
> + padlen = ((skb->len + 4) % dev->maxpacket) ? 0 : 4;
This is now an expensive modulus operation, instead of
a cheap mask.
Since you know that dev->maxpacket is always a power of two, tell the
compiler this so it can still optimize the expression by changing this
to "& (dev->maxpacket - 1)" and we'll thus avoid the costly modulus.
^ permalink raw reply
* Re: [PATCH] smsc95xx: mark link down on startup and let PHY interrupt deal with carrier changes
From: David Miller @ 2012-04-24 4:25 UTC (permalink / raw)
To: paolo.pisati; +Cc: netdev, steve.glendinning
In-Reply-To: <1334914521-5990-1-git-send-email-paolo.pisati@canonical.com>
From: Paolo Pisati <paolo.pisati@canonical.com>
Date: Fri, 20 Apr 2012 11:35:21 +0200
> 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
>
> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
I suspect Steve didn't set the FLAG_LINK_INTR bit intentionally, and
that the link status IRQ is not reliable on all smsc95xx chips.
Steve?
^ permalink raw reply
* Re: [PATCH net-next] net: skb_can_coalesce returns a boolean
From: David Miller @ 2012-04-24 4:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1335239307.5205.125.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Apr 2012 05:48:27 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v4] set fake_rtable's dst to NULL to avoid kernel Oops
From: David Miller @ 2012-04-24 4:17 UTC (permalink / raw)
To: peter.huangpeng
Cc: shemminger, netdev, eric.dumazet, peter.huangpeng, linux-kernel,
harry.majun, ctrix+debianbugs
In-Reply-To: <4F90FE63.9060800@huawei.com>
From: "Peter Huang(Peng)" <peter.huangpeng@huawei.com>
Date: Fri, 20 Apr 2012 14:12:51 +0800
> bridge: set fake_rtable's dst to NULL to avoid kernel Oops
>
> when bridge is deleted before tap/vif device's delete, kernel may
> encounter an oops because of NULL reference to fake_rtable's dst.
> Set fake_rtable's dst to NULL before sending packets out can solve
> this problem.
>
> v4 reformat, change br_drop_fake_rtable(skb) to {}
>
> v3 enrich commit header
>
> v2 introducing new flag DST_FAKE_RTABLE to dst_entry struct.
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Peter Huang <peter.huangpeng@huawei.com>
Applied, although I changed to nop br_drop_fake_rtable() implementation
to use "do { } while (0)" instead of just plain "{ }".
^ permalink raw reply
* Re: [PATCH v1 6/8] dmaengine: enhance network subsystem to support DMA device hotplug
From: Jiang Liu @ 2012-04-24 3:56 UTC (permalink / raw)
To: Dan Williams
Cc: Jiang Liu, Vinod Koul, Keping Chen, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, linux-pci, linux-kernel
In-Reply-To: <CABE8wwvW9MUWaqSUCPMr7_yj7XGtSj+X9VE1-xWrEusZ3TMaqQ@mail.gmail.com>
On 2012-4-24 11:09, Dan Williams wrote:
> On Mon, Apr 23, 2012 at 7:30 PM, Jiang Liu<jiang.liu@huawei.com> wrote:
>>> If you are going to hotplug the entire IOH, then you are probably ok
>>> with network links going down, so could you just down the links and
>>> remove the driver with the existing code?
>>
>> I feel it's a little risky to shut down/restart all network interfaces
>> for hot-removal of IOH, that may disturb the applications.
>
> I guess I'm confused... wouldn't the removal of an entire domain of
> pci devices disturb userspace applications?
Here I mean removing an IOH shouldn't affect devices under other IOHs
if possible.
With current dmaengine implementation, a DMA device/channel may be used
by clients in other PCI domains. So to safely remove a DMA device, we
need to return dmaengine_ref_count to zero by stopping all DMA clients.
For network, that means we need to stop all network interfaces, seems
a little heavy:)
>
>> And there
>> are also other kinds of clients, such as ASYNC_TX, seems we can't
>> adopt this method to reclaim DMA channels from ASYNC_TX subsystem.
>
> I say handle this like block device hotplug. I.e. the driver stays
> loaded but the channel is put into an 'offline' state. So the driver
> hides the fact that the hardware went away. Similar to how you can
> remove a disk but /dev/sda sticks around until the last reference is
> gone (and the driver 'sd' sticks around until all block devices are
> gone).
Per my understanding, this mechanism could be used to stop driver from
accessing surprisingly removed devices, but it still needs a reference
count mechanism to finish the driver unbinding operation eventually.
For IOH hotplug, we need to wait for the completion of driver unbinding
operations before destroying the PCI device nodes of IOAT, so still need
reference count to track channel usage.
Another way is to notify all clients to release all channels when IOAT
device hotplug happens, but that may need heavy modification to the
DMA clients.
>
> I expect the work will be in making sure existing clients are prepared
> to handle NULL returns from ->device_prep_dma_*. In some cases the
> channel is treated more like a cpu, so a NULL return from
> ->device_prep_dma_memcpy() has been interpreted as "device is
> temporarily busy, it is safe to try again". We would need to change
> that to a permanent indication that the device is gone and not attempt
> retry.
Yes, some ASYNC_TX clients interpret NULL return as EBUSY and keep on
retry when doing context aware computations. Will try to investigate
on this direction.
>
> --
> Dan
>
> .
>
^ permalink raw reply
* [PATCH net-next] net: skb_can_coalesce returns a boolean
From: Eric Dumazet @ 2012-04-24 3:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/skbuff.h | 6 +++---
net/ipv4/tcp.c | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f25795c..4a656b5 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1963,8 +1963,8 @@ static inline int skb_add_data(struct sk_buff *skb,
return -EFAULT;
}
-static inline int skb_can_coalesce(struct sk_buff *skb, int i,
- const struct page *page, int off)
+static inline bool skb_can_coalesce(struct sk_buff *skb, int i,
+ const struct page *page, int off)
{
if (i) {
const struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i - 1];
@@ -1972,7 +1972,7 @@ static inline int skb_can_coalesce(struct sk_buff *skb, int i,
return page == skb_frag_page(frag) &&
off == frag->page_offset + skb_frag_size(frag);
}
- return 0;
+ return false;
}
static inline int __skb_linearize(struct sk_buff *skb)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index bcc4eab..de6a238 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -848,9 +848,10 @@ static ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffse
while (psize > 0) {
struct sk_buff *skb = tcp_write_queue_tail(sk);
struct page *page = pages[poffset / PAGE_SIZE];
- int copy, i, can_coalesce;
+ int copy, i;
int offset = poffset % PAGE_SIZE;
int size = min_t(size_t, psize, PAGE_SIZE - offset);
+ bool can_coalesce;
if (!tcp_send_head(sk) || (copy = size_goal - skb->len) <= 0) {
new_segment:
^ permalink raw reply related
* Re: [PATCH net-next] tcp: tcp_try_coalesce returns a boolean
From: David Miller @ 2012-04-24 3:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: ncardwell, netdev, therbert, maze, ilpo.jarvinen
In-Reply-To: <1335238476.5205.122.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Apr 2012 05:34:36 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> This clarifies code intention, as suggested by David.
>
> Suggested-by: David Miller <davem@davemloft.net>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ 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