* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Benjamin Herrenschmidt @ 2011-12-07 7:34 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev, devicetree-discuss, linux-can, linuxppc-dev,
socketcan-users
In-Reply-To: <1322732481-2255-5-git-send-email-wg@grandegger.com>
On Thu, 2011-12-01 at 10:41 +0100, Wolfgang Grandegger wrote:
> This patch enables or updates support for the CC770 and AN82527
> CAN controller on the TQM8548 and TQM8xx boards.
I'm a bit confused by the net-next prefix here. Those patches seem to
be only touching arch/powerpc and seem to be sent primarily toward
netdev with a net-next prefix.
Also there have been at least 3 versions in a couple of days already
without comments nor indication of what was changed...
Can you clarify things a bit please ? It looks like they really should
go to linuxppc-dev (and you can probably drop a bunch of other lists) or
am I missing an important piece of the puzzle ? (Such as patch 1/4 and
2/4 ...)
Let me know if I should just remove them from powerpc patchwork.
Cheers,
Ben.
> CC: devicetree-discuss@lists.ozlabs.org
> CC: linuxppc-dev@ozlabs.org
> CC: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
> arch/powerpc/boot/dts/tqm8548-bigflash.dts | 19 ++++++++++++++-----
> arch/powerpc/boot/dts/tqm8548.dts | 19 ++++++++++++++-----
> arch/powerpc/boot/dts/tqm8xx.dts | 25 +++++++++++++++++++++++++
> 3 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
> index 9452c3c..d918752 100644
> --- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
> +++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
> @@ -352,7 +352,7 @@
> ranges = <
> 0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
> 1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
> - 2 0x0 0xa3000000 0x00008000 // CAN (2 x i82527)
> + 2 0x0 0xa3000000 0x00008000 // CAN (2 x CC770)
> 3 0x0 0xa3010000 0x00008000 // NAND FLASH
>
> >;
> @@ -393,18 +393,27 @@
> };
>
> /* Note: CAN support needs be enabled in U-Boot */
> - can0@2,0 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,0 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x0 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + bosch,clock-out-frequency = <16000000>;
> };
>
> - can1@2,100 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,100 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x100 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> };
>
> /* Note: NAND support needs to be enabled in U-Boot */
> diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
> index 619776f..988d887 100644
> --- a/arch/powerpc/boot/dts/tqm8548.dts
> +++ b/arch/powerpc/boot/dts/tqm8548.dts
> @@ -352,7 +352,7 @@
> ranges = <
> 0 0x0 0xfc000000 0x04000000 // NOR FLASH bank 1
> 1 0x0 0xf8000000 0x08000000 // NOR FLASH bank 0
> - 2 0x0 0xe3000000 0x00008000 // CAN (2 x i82527)
> + 2 0x0 0xe3000000 0x00008000 // CAN (2 x CC770)
> 3 0x0 0xe3010000 0x00008000 // NAND FLASH
>
> >;
> @@ -393,18 +393,27 @@
> };
>
> /* Note: CAN support needs be enabled in U-Boot */
> - can0@2,0 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,0 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x0 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + bosch,clock-out-frequency = <16000000>;
> };
>
> - can1@2,100 {
> - compatible = "intel,82527"; // Bosch CC770
> + can@2,100 {
> + compatible = "bosch,cc770"; // Bosch CC770
> reg = <2 0x100 0x100>;
> interrupts = <4 1>;
> interrupt-parent = <&mpic>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> };
>
> /* Note: NAND support needs to be enabled in U-Boot */
> diff --git a/arch/powerpc/boot/dts/tqm8xx.dts b/arch/powerpc/boot/dts/tqm8xx.dts
> index f6da7ec..c3dba25 100644
> --- a/arch/powerpc/boot/dts/tqm8xx.dts
> +++ b/arch/powerpc/boot/dts/tqm8xx.dts
> @@ -57,6 +57,7 @@
>
> ranges = <
> 0x0 0x0 0x40000000 0x800000
> + 0x3 0x0 0xc0000000 0x200
> >;
>
> flash@0,0 {
> @@ -67,6 +68,30 @@
> bank-width = <4>;
> device-width = <2>;
> };
> +
> + /* Note: CAN support needs be enabled in U-Boot */
> + can@3,0 {
> + compatible = "intc,82527";
> + reg = <3 0x0 0x80>;
> + interrupts = <8 1>;
> + interrupt-parent = <&PIC>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + bosch,clock-out-frequency = <16000000>;
> + };
> +
> + can@3,100 {
> + compatible = "intc,82527";
> + reg = <3 0x100 0x80>;
> + interrupts = <8 1>;
> + interrupt-parent = <&PIC>;
> + bosch,external-clock-frequency = <16000000>;
> + bosch,disconnect-rx1-input;
> + bosch,disconnect-tx1-output;
> + bosch,iso-low-speed-mux;
> + };
> };
>
> soc@fff00000 {
^ permalink raw reply
* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: David Miller @ 2011-12-07 7:39 UTC (permalink / raw)
To: benh
Cc: wg, netdev, devicetree-discuss, linux-can, linuxppc-dev,
socketcan-users
In-Reply-To: <1323243268.660.71.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 07 Dec 2011 18:34:28 +1100
> Let me know if I should just remove them from powerpc patchwork.
These are DT entries for CAN devices for which drivers only exist in
the net-next tree, I already included this patch into the net-next
tree so you do not have to.
^ permalink raw reply
* Re: [PATCH v2] e1000e: Assign true and false to bool type variable instead of 1 and 0
From: Joe Perches @ 2011-12-07 7:39 UTC (permalink / raw)
To: Al Viro
Cc: Michael Wang, jeffrey.t.kirsher,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
wangyunlinux@gmail.com, Brandeburg, Jesse
In-Reply-To: <20111207072050.GC2203@ZenIV.linux.org.uk>
On Wed, 2011-12-07 at 07:20 +0000, Al Viro wrote:
> On Wed, Dec 07, 2011 at 02:36:20PM +0800, Michael Wang wrote:
> > On 12/07/2011 02:19 PM, Joe Perches wrote:
>
> [snip]
> > > if (*i2cctl & IXGBE_I2C_DATA_IN)
> > > - data = 1;
> > > + data = true;
> > > else
> > > - data = 0;
> > > + data = false;
> > >
> > > return data;
>
> Yuck...
>
> bool f(whatever)
> {
> bool data;
> if (expression)
> data = true;
> else
> data = false;
> return data;
> }
>
> is amazingly unidiomatic. Hell, if nothing else it's
> bool data = expression;
> return data;
> if not an outright
> return expression;
> or
> return (bool)expression;
> if you want to underline that it's treated as boolean... What tool
> has produced that patch?
tool has multiple meanings... :)
In this case though it's spatch (coccinelle)
I looked at it and thought the same thing as you.
The point though was not to do the idiomatic
transform that you correctly describe, but to
get Michael Wang to look at spatch as a tool
to do those transforms.
cheers, Joe
^ permalink raw reply
* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Benjamin Herrenschmidt @ 2011-12-07 7:42 UTC (permalink / raw)
To: David Miller
Cc: wg, netdev, devicetree-discuss, linux-can, linuxppc-dev,
socketcan-users
In-Reply-To: <20111207.023916.980093028693181777.davem@davemloft.net>
On Wed, 2011-12-07 at 02:39 -0500, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Wed, 07 Dec 2011 18:34:28 +1100
>
> > Let me know if I should just remove them from powerpc patchwork.
>
> These are DT entries for CAN devices for which drivers only exist in
> the net-next tree, I already included this patch into the net-next
> tree so you do not have to.
Thanks.
Cheers,
Ben.
^ permalink raw reply
* [GIT PULL nf-next] IPVS
From: Simon Horman @ 2011-12-07 8:07 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
Hi Pablo,
please consider pulling
git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
to obtain and enhancement to the SH scheduelr from Michael Maixim.
Michael Maxim (1):
IPVS: Modify the SH scheduler to use weights
net/netfilter/ipvs/Kconfig | 15 +++++++++++++++
net/netfilter/ipvs/ip_vs_sh.c | 20 ++++++++++++++++++--
2 files changed, 33 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH] IPVS: Modify the SH scheduler to use weights
From: Simon Horman @ 2011-12-07 8:07 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Michael Maxim, Simon Horman
In-Reply-To: <1323245223-13646-1-git-send-email-horms@verge.net.au>
From: Michael Maxim <mike@okcupid.com>
Modify the algorithm to build the source hashing hash table to add
extra slots for destinations with higher weight. This has the effect
of allowing an IPVS SH user to give more connections to hosts that
have been configured to have a higher weight.
Signed-off-by: Michael Maxim <mike@okcupid.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/Kconfig | 15 +++++++++++++++
net/netfilter/ipvs/ip_vs_sh.c | 20 ++++++++++++++++++--
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
index 70bd1d0..af4c0b8 100644
--- a/net/netfilter/ipvs/Kconfig
+++ b/net/netfilter/ipvs/Kconfig
@@ -232,6 +232,21 @@ config IP_VS_NQ
If you want to compile it in kernel, say Y. To compile it as a
module, choose M here. If unsure, say N.
+comment 'IPVS SH scheduler'
+
+config IP_VS_SH_TAB_BITS
+ int "IPVS source hashing table size (the Nth power of 2)"
+ range 4 20
+ default 8
+ ---help---
+ The source hashing scheduler maps source IPs to destinations
+ stored in a hash table. This table is tiled by each destination
+ until all slots in the table are filled. When using weights to
+ allow destinations to receive more connections, the table is
+ tiled an amount proportional to the weights specified. The table
+ needs to be large enough to effectively fit all the destinations
+ multiplied by their respective weights.
+
comment 'IPVS application helper'
config IP_VS_FTP
diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
index 33815f4..e0ca520 100644
--- a/net/netfilter/ipvs/ip_vs_sh.c
+++ b/net/netfilter/ipvs/ip_vs_sh.c
@@ -30,6 +30,11 @@
* server is dead or overloaded, the load balancer can bypass the cache
* server and send requests to the original server directly.
*
+ * The weight destination attribute can be used to control the
+ * distribution of connections to the destinations in servernode. The
+ * greater the weight, the more connections the destination
+ * will receive.
+ *
*/
#define KMSG_COMPONENT "IPVS"
@@ -99,9 +104,11 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
struct ip_vs_sh_bucket *b;
struct list_head *p;
struct ip_vs_dest *dest;
+ int d_count;
b = tbl;
p = &svc->destinations;
+ d_count = 0;
for (i=0; i<IP_VS_SH_TAB_SIZE; i++) {
if (list_empty(p)) {
b->dest = NULL;
@@ -113,14 +120,23 @@ ip_vs_sh_assign(struct ip_vs_sh_bucket *tbl, struct ip_vs_service *svc)
atomic_inc(&dest->refcnt);
b->dest = dest;
- p = p->next;
+ IP_VS_DBG_BUF(6, "assigned i: %d dest: %s weight: %d\n",
+ i, IP_VS_DBG_ADDR(svc->af, &dest->addr),
+ atomic_read(&dest->weight));
+
+ /* Don't move to next dest until filling weight */
+ if (++d_count >= atomic_read(&dest->weight)) {
+ p = p->next;
+ d_count = 0;
+ }
+
}
b++;
}
+
return 0;
}
-
/*
* Flush all the hash buckets of the specified table.
*/
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Wolfgang Grandegger @ 2011-12-07 8:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: netdev, devicetree-discuss, linux-can, linuxppc-dev,
socketcan-users
In-Reply-To: <1323243268.660.71.camel@pasglop>
On 12/07/2011 08:34 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2011-12-01 at 10:41 +0100, Wolfgang Grandegger wrote:
>> This patch enables or updates support for the CC770 and AN82527
>> CAN controller on the TQM8548 and TQM8xx boards.
>
> I'm a bit confused by the net-next prefix here. Those patches seem to
> be only touching arch/powerpc and seem to be sent primarily toward
> netdev with a net-next prefix.
These patches are part of a series implementing a new netdev CAN driver
with device-tree support for CC770/i82527 CAN controllers. The
device-tree support and bindings are properly documented and some DTS
files have been updated accordingly. The relevant maintainers and
mailing list have been addressed.
> Also there have been at least 3 versions in a couple of days already
> without comments nor indication of what was changed...
Unfortunately, no response from those sub-system guys.
> Can you clarify things a bit please ? It looks like they really should
> go to linuxppc-dev (and you can probably drop a bunch of other lists) or
> am I missing an important piece of the puzzle ? (Such as patch 1/4 and
> 2/4 ...)
I have not sent the whole series. The changes are documented in the
cover-letter, which I have not sent for those patches. Well, I think
it's better to sent the whole series to all parties instead?
> Let me know if I should just remove them from powerpc patchwork.
Dave has already applied all patches.
Sorry for the confusion. Any advice on how to handle multi subsystem
series of patches properly is welcome.
Wolfgang.
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: misc cleanups
From: Shawn Guo @ 2011-12-07 8:25 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, linux-kernel, Shawn Guo, linux-arm-kernel
In-Reply-To: <bd4415514fa0b40ece04d56b3ac4f549e79d87d7.1323163127.git.LW@KARO-electronics.de>
On Tue, Dec 06, 2011 at 11:27:09AM +0100, Lothar Waßmann wrote:
> - remove some bogus whitespace
> - remove line wraps from printk messages
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Other than subject,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: set con_id in clk_get() call to NULL
From: Shawn Guo @ 2011-12-07 8:26 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, linux-kernel, Shawn Guo, linux-arm-kernel
In-Reply-To: <6c28f25c5c6d2f88d0985ce361c5e16f19db27d0.1323163127.git.LW@KARO-electronics.de>
On Tue, Dec 06, 2011 at 11:27:10AM +0100, Lothar Waßmann wrote:
> The con_id is actually not needed for clk_get().
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Other than subject,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: don't request invalid IRQ
From: Shawn Guo @ 2011-12-07 8:27 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <6d1e5cdcbfc48df864ec9e0939645c0e95389d2a.1323163127.git.LW@KARO-electronics.de>
On Tue, Dec 06, 2011 at 11:27:12AM +0100, Lothar Waßmann wrote:
> prevent calling request_irq() with a known invalid IRQ number and
> preserve the return value of the platform_get_irq() function
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Other than subject,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH] SUNRPC: create svc_xprt in proper network namespace
From: Stanislav Kinsbursky @ 2011-12-07 8:45 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, James Bottomley,
davem@davemloft.net, devel@openvz.org
In-Reply-To: <20111206204851.GB12640@fieldses.org>
07.12.2011 00:48, J. Bruce Fields пишет:
> On Tue, Dec 06, 2011 at 02:19:10PM +0300, Stanislav Kinsbursky wrote:
>> This patch makes svc_xprt inherit network namespace link from it's socket.
>
> And poor rdma gets left out.
Sorry, but this is not a part of my interest.
> OK. Applying for 3.3 (with changelog typo
> fixed).
>
Good, thanks.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: don't munge MAC address from platform data
From: Lothar Waßmann @ 2011-12-07 8:47 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20111207084953.GD5550@S2100-06.ap.freescale.net>
Hi,
Shawn Guo writes:
> On Tue, Dec 06, 2011 at 11:27:13AM +0100, Lothar Waßmann wrote:
> > When the MAC address is supplied via platform_data it should be OK as
> > it is and should not be modified in case of a dual FEC setup.
> > Also copying the MAC from platform_data to the single 'macaddr'
> > variable will overwrite the MAC for the first interface in case of a
> > dual FEC setup.
>
> Hmm, I do not follow that. If 'macaddr' holds a valid mac address,
> the code path has no chance to be hit at all. Otherwise, 'macaddr'
> is just a place holder for copying mac address from pdata, in which
> case the mac address will be fixed up at the end of the function for
> dual FEC setup.
>
In case of dual FEC and MAC address provided by platform_data the
first mac address will be copied to the 'macaddr' variable with no
chance for the second interface to get its mac address assigned from
platform_data too.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: don't munge MAC address from platform data
From: Lothar Waßmann @ 2011-12-07 8:47 UTC (permalink / raw)
To: Shawn Guo; +Cc: Baruch Siach, netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20111207085702.GE5550@S2100-06.ap.freescale.net>
Hi,
Shawn Guo writes:
> On Tue, Dec 06, 2011 at 02:44:44PM +0100, Lothar Waßmann wrote:
> > Hi,
> >
> > Baruch Siach writes:
> > > Hi Lothar,
> > >
> > > On Tue, Dec 06, 2011 at 11:27:13AM +0100, Lothar Waßmann wrote:
> > > > When the MAC address is supplied via platform_data it should be OK as
> > > > it is and should not be modified in case of a dual FEC setup.
> > > > Also copying the MAC from platform_data to the single 'macaddr'
> > > > variable will overwrite the MAC for the first interface in case of a
> > > > dual FEC setup.
> > > >
> > > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > > > ---
> > > > drivers/net/ethernet/freescale/fec.c | 2 +-
> > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > > > index e2b5ce6..11534b9 100644
> > > > --- a/drivers/net/ethernet/freescale/fec.c
> > > > +++ b/drivers/net/ethernet/freescale/fec.c
> > > > @@ -818,7 +818,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> > > > iap = (unsigned char *)FEC_FLASHMAC;
> > > > #else
> > > > if (pdata)
> > > > - memcpy(iap, pdata->mac, ETH_ALEN);
> > > > + iap = (unsigned char *)&pdata->mac;
> > >
> > > Since pdata might point to __initdata struct, you must hold a copy of its
> > > content.
> > >
>
> As iap will anyway be copied to ndev->dev_addr after that, it may still
> be fine to take this patch, for obviously for different reason.
>
> > No. platform_data must be present during the life time of a driver
> > using it and thus must never be __initdata!
> >
> Then we need to fix a lot of imx/mxc platform codes, mach-mx28evk.c
> is the one for this case.
>
Nope. The platform_data provided there is only a template that is
copied to kmalloc'ed memory by the mxs_add...() functions.
With actual platform_data in init memory no driver built as module
would work.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: don't munge MAC address from platform data
From: Shawn Guo @ 2011-12-07 8:49 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <55b78c1766da5b0d0d679f5eae3fb9fc74a6ceef.1323163127.git.LW@KARO-electronics.de>
On Tue, Dec 06, 2011 at 11:27:13AM +0100, Lothar Waßmann wrote:
> When the MAC address is supplied via platform_data it should be OK as
> it is and should not be modified in case of a dual FEC setup.
> Also copying the MAC from platform_data to the single 'macaddr'
> variable will overwrite the MAC for the first interface in case of a
> dual FEC setup.
Hmm, I do not follow that. If 'macaddr' holds a valid mac address,
the code path has no chance to be hit at all. Otherwise, 'macaddr'
is just a place holder for copying mac address from pdata, in which
case the mac address will be fixed up at the end of the function for
dual FEC setup.
Regards,
Shawn
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> ---
> drivers/net/ethernet/freescale/fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> index e2b5ce6..11534b9 100644
> --- a/drivers/net/ethernet/freescale/fec.c
> +++ b/drivers/net/ethernet/freescale/fec.c
> @@ -818,7 +818,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> iap = (unsigned char *)FEC_FLASHMAC;
> #else
> if (pdata)
> - memcpy(iap, pdata->mac, ETH_ALEN);
> + iap = (unsigned char *)&pdata->mac;
> #endif
> }
>
> --
> 1.5.6.5
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: don't munge MAC address from platform data
From: Shawn Guo @ 2011-12-07 8:57 UTC (permalink / raw)
To: Lothar Waßmann
Cc: Baruch Siach, netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20190.7244.156557.313315@ipc1.ka-ro>
On Tue, Dec 06, 2011 at 02:44:44PM +0100, Lothar Waßmann wrote:
> Hi,
>
> Baruch Siach writes:
> > Hi Lothar,
> >
> > On Tue, Dec 06, 2011 at 11:27:13AM +0100, Lothar Waßmann wrote:
> > > When the MAC address is supplied via platform_data it should be OK as
> > > it is and should not be modified in case of a dual FEC setup.
> > > Also copying the MAC from platform_data to the single 'macaddr'
> > > variable will overwrite the MAC for the first interface in case of a
> > > dual FEC setup.
> > >
> > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > > ---
> > > drivers/net/ethernet/freescale/fec.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> > > index e2b5ce6..11534b9 100644
> > > --- a/drivers/net/ethernet/freescale/fec.c
> > > +++ b/drivers/net/ethernet/freescale/fec.c
> > > @@ -818,7 +818,7 @@ static void __inline__ fec_get_mac(struct net_device *ndev)
> > > iap = (unsigned char *)FEC_FLASHMAC;
> > > #else
> > > if (pdata)
> > > - memcpy(iap, pdata->mac, ETH_ALEN);
> > > + iap = (unsigned char *)&pdata->mac;
> >
> > Since pdata might point to __initdata struct, you must hold a copy of its
> > content.
> >
As iap will anyway be copied to ndev->dev_addr after that, it may still
be fine to take this patch, for obviously for different reason.
> No. platform_data must be present during the life time of a driver
> using it and thus must never be __initdata!
>
Then we need to fix a lot of imx/mxc platform codes, mach-mx28evk.c
is the one for this case.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH net-next] remove an outdated reference to T/TCP
From: Eric Dumazet @ 2011-12-07 8:58 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, rick.jones2, netdev
In-Reply-To: <CAK6E8=cne1UbOEcZ6ZfsJw-=qwUsO=yMEi3LNNsTpM_5crv0fg@mail.gmail.com>
Le mardi 06 décembre 2011 à 15:00 -0800, Yuchung Cheng a écrit :
> I am fine keeping the comment as is. This does remind me to put more
> comments on this part of the code in our upcoming Fast Open patch :)
This sounds great.
Is TFO patch using inetpeer cache to store cookies ?
(I ask this because TFO paper I read mentions linux-2.6.34, I presume
you couldnt use inetpeer at that time since it was IPv4 only)
^ permalink raw reply
* Re: [PATCH v2] e1000e: Assign true and false to bool type variable instead of 1 and 0
From: Jeff Kirsher @ 2011-12-07 9:04 UTC (permalink / raw)
To: Michael Wang
Cc: Joe Perches, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, wangyunlinux@gmail.com, Brandeburg, Jesse
In-Reply-To: <4EDF0964.3080509@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
On Tue, 2011-12-06 at 22:36 -0800, Michael Wang wrote:
> On 12/07/2011 02:19 PM, Joe Perches wrote:
>
> > On Wed, 2011-12-07 at 14:08 +0800, Michael Wang wrote:
> >> I'm not good at script, if you are interested, we can work together
> to
> >> fix all the remain cases, and send out some patches.
> >
> > You should try coccinelle and spatch.
> >
>
> Hi, Joe
>
> I have not used coccinelle and spatch before, I will study on them
> later.
>
> > If you run the script, this is the intel output.
> >
> > drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++++-----
> > drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
> > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
> > drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 4 ++--
> > 4 files changed, 9 insertions(+), 9 deletions(-)
>
>
> We can try to fix them, thanks for the suggestion.
>
> Regards,
> Michael Wang
So should I expect a v3 of this patch?
Also I am fine with lumping all the changes for all our drivers in one
patch as long as the changes for each driver are somewhat small. If the
changes for a particular driver gets too extensive, please create a
separate patch.
Cheers,
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [net-next RFC PATCH 5/5] virtio-net: flow director support
From: Stefan Hajnoczi @ 2011-12-07 9:08 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, kvm, mst, netdev, virtualization, levinsasha928,
bhutchings
In-Reply-To: <4EDED785.80804@redhat.com>
On Wed, Dec 7, 2011 at 3:03 AM, Jason Wang <jasowang@redhat.com> wrote:
> On 12/06/2011 09:15 PM, Stefan Hajnoczi wrote:
>>
>> On Tue, Dec 6, 2011 at 10:21 AM, Jason Wang<jasowang@redhat.com> wrote:
>>>
>>> On 12/06/2011 05:18 PM, Stefan Hajnoczi wrote:
>>>>
>>>> On Tue, Dec 6, 2011 at 6:33 AM, Jason Wang<jasowang@redhat.com>
>>>> wrote:
>>>>>
>>>>> On 12/05/2011 06:55 PM, Stefan Hajnoczi wrote:
>>>>>>
>>>>>> On Mon, Dec 5, 2011 at 8:59 AM, Jason Wang<jasowang@redhat.com>
>>>>>> wrote:
>>>>
>>>> The vcpus are just threads and may not be bound to physical CPUs, so
>>>> what is the big picture here? Is the guest even in the position to
>>>> set the best queue mappings today?
>>>
>>>
>>> Not sure it could publish the best mapping but the idea is to make sure
>>> the
>>> packets of a flow were handled by the same guest vcpu and may be the same
>>> vhost thread in order to eliminate the packet reordering and lock
>>> contention. But this assumption does not take the bouncing of vhost or
>>> vcpu
>>> threads which would also affect the result.
>>
>> Okay, this is why I'd like to know what the big picture here is. What
>> solution are you proposing? How are we going to have everything from
>> guest application, guest kernel, host threads, and host NIC driver
>> play along so we get the right steering up the entire stack. I think
>> there needs to be an answer to that before changing virtio-net to add
>> any steering mechanism.
>
>
> Consider the complexity of the host nic each with their own steering
> features, this series make the first step with minimal effort to try to let
> guest driver and host tap/macvtap co-operate like what physical nic does.
> There may be other method, but performance numbers is also needed to give
> the answer.
I agree that performance results for this need to be shown.
My original point is really that it's not a good idea to take
individual steps without a good big picture because this will change
the virtio-net device specification. If this turns out to be a dead
end then hosts will need to continue to support the interface forever
(legacy guests could still try to use it). So please first explain
what the full stack picture is going to look like and how you think it
will lead to better performance. You don't need to have all the code
or evidence, but just enough explanation so we see where this is all
going.
Stefan
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: don't munge MAC address from platform data
From: Shawn Guo @ 2011-12-07 9:14 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <20191.10281.826050.193987@ipc1.ka-ro>
On Wed, Dec 07, 2011 at 09:47:37AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
> > On Tue, Dec 06, 2011 at 11:27:13AM +0100, Lothar Waßmann wrote:
> > > When the MAC address is supplied via platform_data it should be OK as
> > > it is and should not be modified in case of a dual FEC setup.
> > > Also copying the MAC from platform_data to the single 'macaddr'
> > > variable will overwrite the MAC for the first interface in case of a
> > > dual FEC setup.
> >
> > Hmm, I do not follow that. If 'macaddr' holds a valid mac address,
> > the code path has no chance to be hit at all. Otherwise, 'macaddr'
> > is just a place holder for copying mac address from pdata, in which
> > case the mac address will be fixed up at the end of the function for
> > dual FEC setup.
> >
> In case of dual FEC and MAC address provided by platform_data the
> first mac address will be copied to the 'macaddr' variable with no
> chance for the second interface to get its mac address assigned from
> platform_data too.
>
Indeed. So again other than subject,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v2] e1000e: Assign true and false to bool type variable instead of 1 and 0
From: Michael Wang @ 2011-12-07 9:15 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Joe Perches, e1000-devel@lists.sourceforge.net, Brandeburg, Jesse,
wangyunlinux@gmail.com, netdev@vger.kernel.org
In-Reply-To: <1323248664.2415.28.camel@jtkirshe-mobl>
On 12/07/2011 05:04 PM, Jeff Kirsher wrote:
> On Tue, 2011-12-06 at 22:36 -0800, Michael Wang wrote:
>> On 12/07/2011 02:19 PM, Joe Perches wrote:
>>
>>> On Wed, 2011-12-07 at 14:08 +0800, Michael Wang wrote:
>>>> I'm not good at script, if you are interested, we can work together
>> to
>>>> fix all the remain cases, and send out some patches.
>>>
>>> You should try coccinelle and spatch.
>>>
>>
>> Hi, Joe
>>
>> I have not used coccinelle and spatch before, I will study on them
>> later.
>>
>>> If you run the script, this is the intel output.
>>>
>>> drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++++-----
>>> drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
>>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
>>> drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 4 ++--
>>> 4 files changed, 9 insertions(+), 9 deletions(-)
>>
>>
>> We can try to fix them, thanks for the suggestion.
>>
>> Regards,
>> Michael Wang
>
> So should I expect a v3 of this patch?
>
Hi, Jeff
Please use the v2 first, because what Joe described will have a
different meaning and edit different files.
> Also I am fine with lumping all the changes for all our drivers in one
> patch as long as the changes for each driver are somewhat small. If the
> changes for a particular driver gets too extensive, please create a
> separate patch.
I think separate such patch according to files will be better.
Thanks,
Michael Wang
>
> Cheers,
> Jeff
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH v2] e1000e: Assign true and false to bool type variable instead of 1 and 0
From: Jeff Kirsher @ 2011-12-07 9:19 UTC (permalink / raw)
To: Michael Wang
Cc: Joe Perches, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, wangyunlinux@gmail.com, Brandeburg, Jesse
In-Reply-To: <4EDF2EBE.2060708@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
On Wed, 2011-12-07 at 01:15 -0800, Michael Wang wrote:
> On 12/07/2011 05:04 PM, Jeff Kirsher wrote:
>
> > On Tue, 2011-12-06 at 22:36 -0800, Michael Wang wrote:
> >> On 12/07/2011 02:19 PM, Joe Perches wrote:
> >>
> >>> On Wed, 2011-12-07 at 14:08 +0800, Michael Wang wrote:
> >>>> I'm not good at script, if you are interested, we can work together
> >> to
> >>>> fix all the remain cases, and send out some patches.
> >>>
> >>> You should try coccinelle and spatch.
> >>>
> >>
> >> Hi, Joe
> >>
> >> I have not used coccinelle and spatch before, I will study on them
> >> later.
> >>
> >>> If you run the script, this is the intel output.
> >>>
> >>> drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++++-----
> >>> drivers/net/ethernet/intel/ixgb/ixgb_main.c | 2 +-
> >>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
> >>> drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 4 ++--
> >>> 4 files changed, 9 insertions(+), 9 deletions(-)
> >>
> >>
> >> We can try to fix them, thanks for the suggestion.
> >>
> >> Regards,
> >> Michael Wang
> >
> > So should I expect a v3 of this patch?
> >
>
> Hi, Jeff
>
> Please use the v2 first, because what Joe described will have a
> different meaning and edit different files.
Ok sounds fine to me.
>
> > Also I am fine with lumping all the changes for all our drivers in one
> > patch as long as the changes for each driver are somewhat small. If the
> > changes for a particular driver gets too extensive, please create a
> > separate patch.
>
>
> I think separate such patch according to files will be better.
>
> Thanks,
> Michael Wang
>
> >
> > Cheers,
> > Jeff
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH][NET] several cleanups and bugfixes for fec.c: preserve MII/RMII setting in fec_stop()
From: Shawn Guo @ 2011-12-07 9:41 UTC (permalink / raw)
To: Lothar Waßmann; +Cc: netdev, Shawn Guo, linux-kernel, linux-arm-kernel
In-Reply-To: <d6f4de9e4cfb393754b42815a2ef1a59c96eab83.1323163127.git.LW@KARO-electronics.de>
On Tue, Dec 06, 2011 at 11:27:14AM +0100, Lothar Waßmann wrote:
> Additionally to setting the ETHER_EN bit in FEC_ECNTRL the MII/RMII
> setting in FEC_R_CNTRL needs to be preserved to keep the MII interface
s/MII/RMII? From what I see from imx28 and imx6q RM, the reset state
for this setting is MII mode.
> functional.
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> ---
> drivers/net/ethernet/freescale/fec.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
I assume this is fixing a problem you are seeing on imx28 only.
Do you see the problem on imx53/51?
>
> diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
> index 11534b9..ab0afb5 100644
> --- a/drivers/net/ethernet/freescale/fec.c
> +++ b/drivers/net/ethernet/freescale/fec.c
> @@ -515,6 +515,7 @@ fec_stop(struct net_device *ndev)
> struct fec_enet_private *fep = netdev_priv(ndev);
> const struct platform_device_id *id_entry =
> platform_get_device_id(fep->pdev);
> + u32 rmii_mode = readl(fep->hwp + FEC_R_CNTRL) & (1 << 8);
This bit is only available on ENET (imx28 and imx6q). Do we want to
do the same thing for FEC (imx25/27/35/51/53)?
>
> /* We cannot expect a graceful transmit stop without link !!! */
> if (fep->link) {
> @@ -531,8 +532,10 @@ fec_stop(struct net_device *ndev)
> writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
>
> /* We have to keep ENET enabled to have MII interrupt stay working */
> - if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
> + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> writel(2, fep->hwp + FEC_ECNTRL);
> + writel(rmii_mode, fep->hwp + FEC_R_CNTRL);
> + }
> }
On imx6q, we have two bits, bit 6 and 8 of FEC_R_CNTRL, to select MII
interface among MII, RMII and RGMII modes. I'm not sure if we will
run into the same problem for RGMII mode. What's your test setup?
I would try to reproduce it here.
--
Regards,
Shawn
^ permalink raw reply
* Re: Time in Queue, bufferbloat, and... our accidentally interplanetary network
From: Dave Taht @ 2011-12-07 9:59 UTC (permalink / raw)
To: Adrian Chadd
Cc: Eric Dumazet, bloat, bloat-devel, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless
In-Reply-To: <CAJ-VmomuA7u5=zRGMK2Jd3WG+HWTRTZNST4JDVWU9kUEcfE91Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 6, 2011 at 3:03 AM, Adrian Chadd <adrian-h+KGxgPPiopAfugRpC6u6w@public.gmane.org> wrote:
> Hi,
>
> For what it's worth, I've also been tinkering with time-in-queue for
> the wifi queue management in FreeBSD. I don't have anything public
> yet. What I have done actually seems to work quite well, when doing TX
> queue time-in-queue management. (I'm ignoring RX queue management for
> now.)
>
> Yes, I think a weighted random drop with both time-in-queue and queue
> depth would work well. I haven't sat down to model what it'd look like
> given some traffic profiles.
>
> I'll be sure to post some patches and results when I have them. :)
Well, if there is a way to add BQL sanely to the mac80211 or driver
layers and then apply some time in queue techniques at some edge
of some layer(s) down there in Linux, I'd love to know what and where
is good.
It might be simpler to discuss design ideas etc, in a more generic
and less noisy forum than netdev and linux-wireless, at least
for a while, getting to actual patches seems kind of hard at this point.
(at least to me. For all I know eric is finished already, and me, I haven't
finished grokking the paper he's leveraging some ideas on)
The little I understand about Linux's networking stack dwarfs the
little I know about BSD's, so I look forward to hearing about your
results as you get them, and that said, if you could provide some
pointers and insight into BSD's traffic shaping methods over on
bloat-devel, we do try to be all-architecture embracing in our
attempts to beat the bloat.
>
>
> Adrian
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Daughterboard Jetway JAD3RTLANG with three RTL-8110SC/8169SC Gigabit Ethernet is curious
From: Markus Feldmann @ 2011-12-07 10:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <jb0d7u$bbb$1@dough.gmane.org>
Today i had some problems with the ethernet card at the mid of my
daughterboard. I tested all 3 ethernet ports more than one time by plug
in and out the cable again and again. The eth2 made trouble, the orange
LED blinked slowly. eth1 and eth3 worked correctly (the orange LED
shined permanently). After some tries with eth2 this ethernet port
worked at last too.
Here is a output from /var/log/kern.log:
http://pastebin.com/raw.php?i=wtbqMXZd
And /var/log/syslog:
http://pastebin.com/raw.php?i=2tjLWENE
In /var/log/syslog you can see, that only eth2 made trouble, the other
ports let me connect really fast to my server/router.
regards Markus
^ permalink raw reply
* Re: Time in Queue, bufferbloat, and... our accidentally interplanetary network
From: Hagen Paul Pfeifer @ 2011-12-07 10:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: bloat-devel, netdev-u79uwXL29TY76Z2rM5mHXA, linux-wireless, bloat
In-Reply-To: <1323082774.2670.40.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 05 Dec 2011 11:59:34 +0100, Eric Dumazet wrote:
> Adding a time limit is possible, all we need is a proper design and
> implementation :)
>
> Here is my suggestion :
>
> Design a new tfifo/tred qdisc, with following properties :
>
> Adaptative RED, (ECN enabled + head drop), but instead of using
> bytes/packet qlen average, use time_in_queue average.
Question one: is anything wrong with sfb or choke as the basis, instead of
RED?
Question two: I submitted pfast_head_drop to drop more outdated data
instead of new data. Back in time I thought TCP _may_ experience benefits
because more up-to-date SACK data packets are saved. Are there any other
TCP advantages with head drop policy?
Hagen
^ 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