* Re: [PATCH] ARM: mxs: pass fec device name via platform data
From: Uwe Kleine-König @ 2011-01-14 8:38 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <1294988000-20232-1-git-send-email-shawn.guo@freescale.com>
On Fri, Jan 14, 2011 at 02:53:20PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> arch/arm/mach-mxs/devices/platform-fec.c | 11 ++++++-----
> arch/arm/mach-mxs/include/mach/devices-common.h | 1 +
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/devices/platform-fec.c b/arch/arm/mach-mxs/devices/platform-fec.c
> index c42dff7..75eb26b 100644
> --- a/arch/arm/mach-mxs/devices/platform-fec.c
> +++ b/arch/arm/mach-mxs/devices/platform-fec.c
> @@ -10,20 +10,21 @@
> #include <mach/mx28.h>
> #include <mach/devices-common.h>
>
> -#define mxs_fec_data_entry_single(soc, _id) \
> +#define mxs_fec_data_entry_single(soc, _devid, _id) \
> { \
> + .devid = _devid, \
> .id = _id, \
> .iobase = soc ## _ENET_MAC ## _id ## _BASE_ADDR, \
> .irq = soc ## _INT_ENET_MAC ## _id, \
> }
>
> -#define mxs_fec_data_entry(soc, _id) \
> - [_id] = mxs_fec_data_entry_single(soc, _id)
> +#define mxs_fec_data_entry(soc, _devid, _id) \
> + [_id] = mxs_fec_data_entry_single(soc, _devid, _id)
>
> #ifdef CONFIG_SOC_IMX28
> const struct mxs_fec_data mx28_fec_data[] __initconst = {
> #define mx28_fec_data_entry(_id) \
> - mxs_fec_data_entry(MX28, _id)
> + mxs_fec_data_entry(MX28, "imx28-fec", _id)
> mx28_fec_data_entry(0),
> mx28_fec_data_entry(1),
> };
> @@ -45,6 +46,6 @@ struct platform_device *__init mxs_add_fec(
> },
> };
>
> - return mxs_add_platform_device("imx28-fec", data->id,
> + return mxs_add_platform_device(data->devid, data->id,
> res, ARRAY_SIZE(res), pdata, sizeof(*pdata));
> }
> diff --git a/arch/arm/mach-mxs/include/mach/devices-common.h b/arch/arm/mach-mxs/include/mach/devices-common.h
> index 6c3d1a1..10fbcfd 100644
> --- a/arch/arm/mach-mxs/include/mach/devices-common.h
> +++ b/arch/arm/mach-mxs/include/mach/devices-common.h
> @@ -33,6 +33,7 @@ int __init mxs_add_duart(const struct amba_device *dev);
> /* fec */
> #include <linux/fec.h>
> struct mxs_fec_data {
> + const char *devid;
> int id;
> resource_size_t iobase;
> resource_size_t iosize;
> --
> 1.7.1
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v4 08/10] ARM: mxs: add ocotp read function
From: Sascha Hauer @ 2011-01-14 8:33 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Shawn Guo, gerg, B32542, netdev, jamie, baruch, w.sang, r64343,
eric, bryan.wu, jamie, davem, linux-arm-kernel, lw
In-Reply-To: <20110113151939.GX24920@pengutronix.de>
On Thu, Jan 13, 2011 at 04:19:39PM +0100, Uwe Kleine-König wrote:
> On Thu, Jan 06, 2011 at 03:13:16PM +0800, Shawn Guo wrote:
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > Changes for v4:
> > - Call cpu_relax() during polling
> >
> > Changes for v2:
> > - Add mutex locking for mxs_read_ocotp()
> > - Use type size_t for count and i
> > - Add comment for clk_enable/disable skipping
> > - Add ERROR bit clearing and polling step
> >
> > arch/arm/mach-mxs/Makefile | 2 +-
> > arch/arm/mach-mxs/include/mach/common.h | 1 +
> > arch/arm/mach-mxs/ocotp.c | 79 +++++++++++++++++++++++++++++++
> > 3 files changed, 81 insertions(+), 1 deletions(-)
> > create mode 100644 arch/arm/mach-mxs/ocotp.c
> >
> > diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
> > index 39d3f9c..f23ebbd 100644
> > --- a/arch/arm/mach-mxs/Makefile
> > +++ b/arch/arm/mach-mxs/Makefile
> > @@ -1,5 +1,5 @@
> > # Common support
> > -obj-y := clock.o devices.o gpio.o icoll.o iomux.o system.o timer.o
> > +obj-y := clock.o devices.o gpio.o icoll.o iomux.o ocotp.o system.o timer.o
> is it worth to make ocotp optional? (and let evk select
> CONFIG_MXS_OCOTP)
I think not.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH net-next] net: cleanup unused macros in net directory
From: Shan Wei @ 2011-01-14 8:19 UTC (permalink / raw)
To: David Miller, sjur.brandeland, andy.grover, ericvh, jvrao,
aneesh.kumar, joe, Chang
Clean up some unused macros in net/*.
1. be left for code change. e.g. PGV_FROM_VMALLOC, PGV_FROM_VMALLOC, KMEM_SAFETYZONE.
2. never be used since introduced to kernel.
e.g. P9_RDMA_MAX_SGE, UTIL_CTRL_PKT_SIZE.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
net/9p/trans_rdma.c | 1 -
net/caif/cfcnfg.c | 2 --
net/caif/cfdgml.c | 1 -
net/caif/cfserl.c | 1 -
net/caif/cfutill.c | 2 +-
net/caif/cfveil.c | 2 +-
net/decnet/dn_table.c | 1 -
net/packet/af_packet.c | 1 -
net/rds/rds.h | 1 -
net/wanrouter/wanmain.c | 2 --
10 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
index 17c5ba7..29a54cc 100644
--- a/net/9p/trans_rdma.c
+++ b/net/9p/trans_rdma.c
@@ -59,7 +59,6 @@
* safely advertise a maxsize
* of 64k */
-#define P9_RDMA_MAX_SGE (P9_RDMA_MAXSIZE >> PAGE_SHIFT)
/**
* struct p9_trans_rdma - RDMA transport instance
*
diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index 21ede14..ed3cfda 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -23,10 +23,8 @@
#include <asm/atomic.h>
#define MAX_PHY_LAYERS 7
-#define PHY_NAME_LEN 20
#define container_obj(layr) container_of(layr, struct cfcnfg, layer)
-#define RFM_FRAGMENT_SIZE 4030
/* Information about CAIF physical interfaces held by Config Module in order
* to manage physical interfaces
diff --git a/net/caif/cfdgml.c b/net/caif/cfdgml.c
index d3ed264..27dab26 100644
--- a/net/caif/cfdgml.c
+++ b/net/caif/cfdgml.c
@@ -18,7 +18,6 @@
#define DGM_CMD_BIT 0x80
#define DGM_FLOW_OFF 0x81
#define DGM_FLOW_ON 0x80
-#define DGM_CTRL_PKT_SIZE 1
#define DGM_MTU 1500
static int cfdgml_receive(struct cflayer *layr, struct cfpkt *pkt);
diff --git a/net/caif/cfserl.c b/net/caif/cfserl.c
index 9297f7d..8303fe3 100644
--- a/net/caif/cfserl.c
+++ b/net/caif/cfserl.c
@@ -25,7 +25,6 @@ struct cfserl {
spinlock_t sync;
bool usestx;
};
-#define STXLEN(layr) (layr->usestx ? 1 : 0)
static int cfserl_receive(struct cflayer *layr, struct cfpkt *pkt);
static int cfserl_transmit(struct cflayer *layr, struct cfpkt *pkt);
diff --git a/net/caif/cfutill.c b/net/caif/cfutill.c
index efad410..315c0d6 100644
--- a/net/caif/cfutill.c
+++ b/net/caif/cfutill.c
@@ -20,7 +20,7 @@
#define UTIL_REMOTE_SHUTDOWN 0x82
#define UTIL_FLOW_OFF 0x81
#define UTIL_FLOW_ON 0x80
-#define UTIL_CTRL_PKT_SIZE 1
+
static int cfutill_receive(struct cflayer *layr, struct cfpkt *pkt);
static int cfutill_transmit(struct cflayer *layr, struct cfpkt *pkt);
diff --git a/net/caif/cfveil.c b/net/caif/cfveil.c
index 3b425b1..c3b1dec 100644
--- a/net/caif/cfveil.c
+++ b/net/caif/cfveil.c
@@ -17,7 +17,7 @@
#define VEI_FLOW_OFF 0x81
#define VEI_FLOW_ON 0x80
#define VEI_SET_PIN 0x82
-#define VEI_CTRL_PKT_SIZE 1
+
#define container_obj(layr) container_of(layr, struct cfsrvl, layer)
static int cfvei_receive(struct cflayer *layr, struct cfpkt *pkt);
diff --git a/net/decnet/dn_table.c b/net/decnet/dn_table.c
index f2abd37..b66600b 100644
--- a/net/decnet/dn_table.c
+++ b/net/decnet/dn_table.c
@@ -59,7 +59,6 @@ struct dn_hash
};
#define dz_key_0(key) ((key).datum = 0)
-#define dz_prefix(key,dz) ((key).datum)
#define for_nexthops(fi) { int nhsel; const struct dn_fib_nh *nh;\
for(nhsel = 0, nh = (fi)->fib_nh; nhsel < (fi)->fib_nhs; nh++, nhsel++)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 91cb1d7..4b87237 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -164,7 +164,6 @@ struct packet_mreq_max {
static int packet_set_ring(struct sock *sk, struct tpacket_req *req,
int closing, int tx_ring);
-#define PGV_FROM_VMALLOC 1
struct pgv {
char *buffer;
};
diff --git a/net/rds/rds.h b/net/rds/rds.h
index 9542449..da8adac 100644
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -50,7 +50,6 @@ rdsdebug(char *fmt, ...)
#define RDS_FRAG_SIZE ((unsigned int)(1 << RDS_FRAG_SHIFT))
#define RDS_CONG_MAP_BYTES (65536 / 8)
-#define RDS_CONG_MAP_LONGS (RDS_CONG_MAP_BYTES / sizeof(unsigned long))
#define RDS_CONG_MAP_PAGES (PAGE_ALIGN(RDS_CONG_MAP_BYTES) / PAGE_SIZE)
#define RDS_CONG_MAP_PAGE_BITS (PAGE_SIZE * 8)
diff --git a/net/wanrouter/wanmain.c b/net/wanrouter/wanmain.c
index 74944a2..788a12c 100644
--- a/net/wanrouter/wanmain.c
+++ b/net/wanrouter/wanmain.c
@@ -59,8 +59,6 @@
#include <asm/uaccess.h> /* copy_to/from_user */
#include <linux/init.h> /* __initfunc et al. */
-#define KMEM_SAFETYZONE 8
-
#define DEV_TO_SLAVE(dev) (*((struct net_device **)netdev_priv(dev)))
/*
--
1.7.0.1
^ permalink raw reply related
* Re: [PATCH 04/10] GRETH: added greth_compat_mode module parameter
From: Daniel Hellstrom @ 2011-01-14 8:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kristoffer
In-Reply-To: <20110113.221454.149673942.davem@davemloft.net>
David Miller wrote:
>From: Daniel Hellstrom <daniel@gaisler.com>
>Date: Thu, 13 Jan 2011 09:25:29 +0100
>
>
>
>>The greth_compat_mode option can be used to set a GRETH GBit capable MAC
>>in operate as if the GRETH 10/100 device was found. The GRETH GBit supports
>>TCP/UDP checksum offloading, unaligned frame buffers, scatter gather etc.
>>Enabling this mode allows the developer to test the GRETH 10/100 device
>>without all features mentioned above on a GBit MAC capable of the above.
>>
>>Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
>>
>>
>
>No special device specific module parameters please.
>
>What if every single driver author added something like this and they
>all named it something different or made it behave in slightly differing
>ways?
>
>What kind of user experience would that result in?
>
>It would result in a sucky one, which is why we avoid adding all kinds
>of hacky driver specific module options.
>
>Find a generic way to provide this functionality.
>
>
I understand, it was not ment to be a user-experience, rather a
developer debugging option. I will probably need an option like this in
the future to avoid searching a very long time for very old hardware, I
will try to find an other solution for it in the future.
I will remove the 3 GRETH patches and resubmit the others.
Thanks,
Daniel
^ permalink raw reply
* Kernel 2.6.37-git10 build failure: cassini.c
From: Anca Emanuel @ 2011-01-14 8:09 UTC (permalink / raw)
To: LKML
Cc: netdev, Grant Likely, David S. Miller, Eric Dumazet, Joe Perches,
Christoph Egger, Jiri Pirko
drivers/net/cassini.c: In function ‘cas_get_vpd_info’:
drivers/net/cassini.c:3358: error: implicit declaration of function
‘of_get_property’
drivers/net/cassini.c:3358: warning: assignment makes pointer from
integer without a cast
drivers/net/cassini.c: In function ‘cas_init_one’:
drivers/net/cassini.c:5035: error: implicit declaration of function
‘pci_device_to_OF_node’
drivers/net/cassini.c:5035: warning: assignment makes pointer from
integer without a cast
make[3]: *** [drivers/net/cassini.o] Error 1
make[2]: *** [drivers/net] Error 2
The first part can be solved with:
diff --git a/drivers/net/cassini.c b/drivers/net/cassini.c
index 7206ab2..fe3795e 100644
--- a/drivers/net/cassini.c
+++ b/drivers/net/cassini.c
@@ -94,6 +94,7 @@
#include <linux/tcp.h>
#include <linux/mutex.h>
#include <linux/firmware.h>
+#include <linux/of.h>
#include <net/checksum.h>
^ permalink raw reply related
* Re: [PATCH v4 05/10] net/fec: add dual fec support for mx28
From: Uwe Kleine-König @ 2011-01-14 7:52 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <20110114054838.GA14491@freescale.com>
On Fri, Jan 14, 2011 at 01:48:40PM +0800, Shawn Guo wrote:
> Hi Uwe,
>
> On Thu, Jan 13, 2011 at 03:48:05PM +0100, Uwe Kleine-König wrote:
>
> [...]
>
> > > +/* Controller is ENET-MAC */
> > > +#define FEC_QUIRK_ENET_MAC (1 << 0)
> > does this really qualify to be a quirk?
> >
> My understanding is that ENET-MAC is a type of "quirky" FEC
> controller.
>
> > > +/* Controller needs driver to swap frame */
> > > +#define FEC_QUIRK_SWAP_FRAME (1 << 1)
> > IMHO this is a bit misnamed. FEC_QUIRK_NEEDS_BE_DATA or similar would
> > be more accurate.
> >
> When your make this change, you may want to pick a better name for
> function swap_buffer too.
>
> [...]
>
> > > +static void *swap_buffer(void *bufaddr, int len)
> > > +{
> > > + int i;
> > > + unsigned int *buf = bufaddr;
> > > +
> > > + for (i = 0; i < (len + 3) / 4; i++, buf++)
> > > + *buf = cpu_to_be32(*buf);
> > if len isn't a multiple of 4 this accesses bytes behind len. Is this
> > generally OK here? (E.g. because skbs always have a length that is a
> > multiple of 4?)
> The len may not be a multiple of 4. But I believe bufaddr is always
> a buffer allocated in a length that is a multiple of 4, and the 1~3
> bytes exceeding the len very likely has no data that matters. But
> yes, it deserves a safer implementation.
Did you test what happens if bufaddr isn't aligned? Does it work at all
then?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 03/10] GRETH: added no_gbit option
From: Daniel Hellstrom @ 2011-01-14 7:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kristoffer
In-Reply-To: <20110113.221324.82807816.davem@davemloft.net>
David Miller wrote:
>From: Daniel Hellstrom <daniel@gaisler.com>
>Date: Thu, 13 Jan 2011 09:25:28 +0100
>
>
>
>>For debug only. The driver does not report that it is GBit capable, instead
>>it will report 10/100 mode to the generic PHY layer.
>>
>>Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
>>
>>
>
>You may not add special purpose module parameters to your ethernet driver.
>
>Instead, users can use ethtool to control what speeds the device will
>try to advertise for during auto-negotiation, or use with a fixed
>link configuration.
>
>
Ok, I will remove this patch.
Daniel
^ permalink raw reply
* Re: [PATCH V9 08/13] posix clocks: cleanup the CLOCK_DISPTACH macro
From: Richard Cochran @ 2011-01-14 7:48 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti
In-Reply-To: <alpine.LFD.2.00.1101131745400.2678-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Thu, Jan 13, 2011 at 06:03:24PM +0100, Thomas Gleixner wrote:
> On Thu, 13 Jan 2011, Richard Cochran wrote:
> > int posix_cpu_clock_getres(const clockid_t which_clock, struct timespec *ts);
> > int posix_cpu_clock_get(const clockid_t which_clock, struct timespec *ts);
> > -int posix_cpu_clock_set(const clockid_t which_clock, const struct timespec *ts);
> > +int posix_cpu_clock_set(const clockid_t which_clock, struct timespec *ts);
>
> Shouldn't we change the clock_set function to have *ts const in all places ?
Yes, your are right.
> > @@ -293,6 +261,11 @@ static __init int init_posix_timers(void)
> > .clock_adj = do_posix_clock_noadjtime,
> > .timer_create = no_timer_create,
> > .nsleep = no_nsleep,
> > + /* defaults: */
> > + .nsleep_restart = common_nsleep_restart,
> > + .timer_del = common_timer_del,
> > + .timer_get = common_timer_get,
> > + .timer_set = common_timer_set,
>
> Hmm, we do not need to set functional entries for clocks which neither
> implement timer_create nor nsleep.
I know, but I wanted to be really pendantic about what the previous
code was, and what the new code does.
Before: By leaving the k_clock function pointer NULL, the clock
selects common_xyz. This common function may or may make
sense for that clock.
After: By leaving the k_clock function pointer NULL, the clock will
return EINVAL for that syscall.
Maybe it would be better to leave the cleaning up of the common crud
as a follow up patch. What do you think?
Richard
^ permalink raw reply
* [PATCH] net/irda/sh_irda: return to RX mode when TX error
From: Kuninori Morimoto @ 2011-01-14 7:47 UTC (permalink / raw)
To: netdev; +Cc: Samuel Ortiz, David S. Miller
sh_irda can not use RX/TX in same time,
but this driver didn't return to RX mode when TX error occurred.
This patch care xmit error case to solve this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/net/irda/sh_irda.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/irda/sh_irda.c b/drivers/net/irda/sh_irda.c
index 9e3f4f5..4488bd5 100644
--- a/drivers/net/irda/sh_irda.c
+++ b/drivers/net/irda/sh_irda.c
@@ -635,7 +635,7 @@ static int sh_irda_hard_xmit(struct sk_buff *skb, struct net_device *ndev)
ret = sh_irda_set_baudrate(self, speed);
if (ret < 0)
- return ret;
+ goto sh_irda_hard_xmit_end;
self->tx_buff.len = 0;
if (skb->len) {
@@ -652,11 +652,21 @@ static int sh_irda_hard_xmit(struct sk_buff *skb, struct net_device *ndev)
sh_irda_write(self, IRTFLR, self->tx_buff.len);
sh_irda_write(self, IRTCTR, ARMOD | TE);
- }
+ } else
+ goto sh_irda_hard_xmit_end;
dev_kfree_skb(skb);
return 0;
+
+sh_irda_hard_xmit_end:
+ sh_irda_set_baudrate(self, 9600);
+ netif_wake_queue(self->ndev);
+ sh_irda_rcv_ctrl(self, 1);
+ dev_kfree_skb(skb);
+
+ return ret;
+
}
static int sh_irda_ioctl(struct net_device *ndev, struct ifreq *ifreq, int cmd)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 02/10] GRETH: added option to disable a device node from bootloader.
From: Daniel Hellstrom @ 2011-01-14 7:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kristoffer
In-Reply-To: <20110113.221238.97339127.davem@davemloft.net>
David Miller wrote:
>From: Daniel Hellstrom <daniel@gaisler.com>
>Date: Thu, 13 Jan 2011 09:25:27 +0100
>
>
>
>>Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
>>
>>
>
>This is not how you do this.
>
>Simply not present the device in the OpenFirmware tree at all. If you
>can make this special properly appear, you can also toss the device
>node away completely.
>
>There is zero reason whatsoever to create a special hack-job
>non-standardized device node properly to do this.
>
>
I agree, I will remove it. The optional parameter should be a setting
for a particular device rather that a "disable device" parameter.
Thanks,
Daniel
^ permalink raw reply
* [PATCH v5 09/10] ARM: mxs/mx28evk: read fec mac address from ocotp
From: Shawn Guo @ 2011-01-14 7:25 UTC (permalink / raw)
To: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw; +Cc: Shawn Guo
In-Reply-To: <1294297998-26930-1-git-send-email-shawn.guo@freescale.com>
Read fec mac address from ocotp and save it into fec_platform_data
mac field for fec driver to use.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-mxs/mach-mx28evk.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
index 8e2c597..e8db99f 100644
--- a/arch/arm/mach-mxs/mach-mx28evk.c
+++ b/arch/arm/mach-mxs/mach-mx28evk.c
@@ -119,7 +119,7 @@ static void __init mx28evk_fec_reset(void)
gpio_set_value(MX28EVK_FEC_PHY_RESET, 1);
}
-static struct fec_platform_data mx28_fec_pdata[] = {
+static struct fec_platform_data mx28_fec_pdata[] __initdata = {
{
/* fec0 */
.phy = PHY_INTERFACE_MODE_RMII,
@@ -129,12 +129,45 @@ static struct fec_platform_data mx28_fec_pdata[] = {
},
};
+static int __init mx28evk_fec_get_mac(void)
+{
+ int i;
+ u32 val;
+ const u32 *ocotp = mxs_get_ocotp();
+
+ if (!ocotp)
+ goto error;
+
+ /*
+ * OCOTP only stores the last 4 octets for each mac address,
+ * so hard-code Freescale OUI (00:04:9f) here.
+ */
+ for (i = 0; i < 2; i++) {
+ val = ocotp[i * 4];
+ mx28_fec_pdata[i].mac[0] = 0x00;
+ mx28_fec_pdata[i].mac[1] = 0x04;
+ mx28_fec_pdata[i].mac[2] = 0x9f;
+ mx28_fec_pdata[i].mac[3] = (val >> 16) & 0xff;
+ mx28_fec_pdata[i].mac[4] = (val >> 8) & 0xff;
+ mx28_fec_pdata[i].mac[5] = (val >> 0) & 0xff;
+ }
+
+ return 0;
+
+error:
+ pr_err("%s: timeout when reading fec mac from OCOTP\n", __func__);
+ return -ETIMEDOUT;
+}
+
static void __init mx28evk_init(void)
{
mxs_iomux_setup_multiple_pads(mx28evk_pads, ARRAY_SIZE(mx28evk_pads));
mx28_add_duart();
+ if (mx28evk_fec_get_mac())
+ pr_warn("%s: failed on fec mac setup\n", __func__);
+
mx28evk_fec_reset();
mx28_add_fec(0, &mx28_fec_pdata[0]);
mx28_add_fec(1, &mx28_fec_pdata[1]);
--
1.7.1
^ permalink raw reply related
* [PATCH v5 08/10] ARM: mxs: add ocotp read function
From: Shawn Guo @ 2011-01-14 7:24 UTC (permalink / raw)
To: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw; +Cc: Shawn Guo
In-Reply-To: <1294297998-26930-1-git-send-email-shawn.guo@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-mxs/Kconfig | 4 ++
arch/arm/mach-mxs/Makefile | 3 +
arch/arm/mach-mxs/include/mach/common.h | 1 +
arch/arm/mach-mxs/ocotp.c | 90 +++++++++++++++++++++++++++++++
4 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mxs/ocotp.c
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 8bfc8df..cd2fbdf 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -2,6 +2,9 @@ if ARCH_MXS
source "arch/arm/mach-mxs/devices/Kconfig"
+config MXS_OCOTP
+ bool
+
config SOC_IMX23
bool
select CPU_ARM926T
@@ -26,6 +29,7 @@ config MACH_MX28EVK
select SOC_IMX28
select MXS_HAVE_AMBA_DUART
select MXS_HAVE_PLATFORM_FEC
+ select MXS_OCOTP
default y
help
Include support for MX28EVK platform. This includes specific
diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
index 39d3f9c..623899b 100644
--- a/arch/arm/mach-mxs/Makefile
+++ b/arch/arm/mach-mxs/Makefile
@@ -1,6 +1,9 @@
# Common support
obj-y := clock.o devices.o gpio.o icoll.o iomux.o system.o timer.o
+obj-$(CONFIG_PM) += pm.o
+obj-$(CONFIG_MXS_OCOTP) += ocotp.o
+
obj-$(CONFIG_SOC_IMX23) += clock-mx23.o mm-mx23.o
obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
diff --git a/arch/arm/mach-mxs/include/mach/common.h b/arch/arm/mach-mxs/include/mach/common.h
index 59133eb..635bb5d 100644
--- a/arch/arm/mach-mxs/include/mach/common.h
+++ b/arch/arm/mach-mxs/include/mach/common.h
@@ -13,6 +13,7 @@
struct clk;
+extern const u32 *mxs_get_ocotp(void);
extern int mxs_reset_block(void __iomem *);
extern void mxs_timer_init(struct clk *, int);
diff --git a/arch/arm/mach-mxs/ocotp.c b/arch/arm/mach-mxs/ocotp.c
new file mode 100644
index 0000000..eb2eab7
--- /dev/null
+++ b/arch/arm/mach-mxs/ocotp.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+
+#include <mach/mxs.h>
+
+#define OCOTP_WORD_OFFSET 0x20
+#define OCOTP_WORD_COUNT 0x20
+
+#define BM_OCOTP_CTRL_BUSY (1 << 8)
+#define BM_OCOTP_CTRL_ERROR (1 << 9)
+#define BM_OCOTP_CTRL_RD_BANK_OPEN (1 << 12)
+
+static DEFINE_MUTEX(ocotp_mutex);
+static u32 ocotp_words[OCOTP_WORD_COUNT];
+
+const u32 *mxs_get_ocotp(void)
+{
+ void __iomem *ocotp_base = MXS_IO_ADDRESS(MXS_OCOTP_BASE_ADDR);
+ int timeout = 0x400;
+ size_t i;
+ static int once = 0;
+
+ if (once)
+ return ocotp_words;
+
+ mutex_lock(&ocotp_mutex);
+
+ /*
+ * clk_enable(hbus_clk) for ocotp can be skipped
+ * as it must be on when system is running.
+ */
+
+ /* try to clear ERROR bit */
+ __mxs_clrl(BM_OCOTP_CTRL_ERROR, ocotp_base);
+
+ /* check both BUSY and ERROR cleared */
+ while ((__raw_readl(ocotp_base) &
+ (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
+ cpu_relax();
+
+ if (unlikely(!timeout))
+ goto error_unlock;
+
+ /* open OCOTP banks for read */
+ __mxs_setl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
+
+ /* approximately wait 32 hclk cycles */
+ udelay(1);
+
+ /* poll BUSY bit becoming cleared */
+ timeout = 0x400;
+ while ((__raw_readl(ocotp_base) & BM_OCOTP_CTRL_BUSY) && --timeout)
+ cpu_relax();
+
+ if (unlikely(!timeout))
+ goto error_unlock;
+
+ for (i = 0; i < OCOTP_WORD_COUNT; i++)
+ ocotp_words[i] = __raw_readl(ocotp_base + OCOTP_WORD_OFFSET +
+ i * 0x10);
+
+ /* close banks for power saving */
+ __mxs_clrl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
+
+ mutex_unlock(&ocotp_mutex);
+
+ once = 1;
+
+ return ocotp_words;
+
+error_unlock:
+ mutex_unlock(&ocotp_mutex);
+ pr_err("%s: timeout in reading OCOTP\n", __func__);
+ return NULL;
+}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v5] ARM: mx28: add the second fec device registration
From: Shawn Guo @ 2011-01-14 7:04 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: s.hauer, davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw,
w.sang, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <20110113144900.GT24920@pengutronix.de>
Hi Uwe,
On Thu, Jan 13, 2011 at 03:49:00PM +0100, Uwe Kleine-König wrote:
> On Tue, Jan 11, 2011 at 08:09:24PM +0800, Shawn Guo wrote:
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > Changes for v5:
> > - Do not use CONFIG_FEC2 which is a fec driver configration
> >
> > arch/arm/mach-mxs/mach-mx28evk.c | 26 +++++++++++++++++++++++---
> > 1 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> > index d162e95..8e2c597 100644
> > --- a/arch/arm/mach-mxs/mach-mx28evk.c
> > +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> > @@ -57,6 +57,19 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> > (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > MX28_PAD_ENET_CLK__CLKCTRL_ENET |
> > (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > + /* fec1 */
> > + MX28_PAD_ENET0_CRS__ENET1_RX_EN |
> > + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > + MX28_PAD_ENET0_RXD2__ENET1_RXD0 |
> > + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > + MX28_PAD_ENET0_RXD3__ENET1_RXD1 |
> > + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > + MX28_PAD_ENET0_COL__ENET1_TX_EN |
> > + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > + MX28_PAD_ENET0_TXD2__ENET1_TXD0 |
> > + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > + MX28_PAD_ENET0_TXD3__ENET1_TXD1 |
> > + (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
> > /* phy power line */
> > MX28_PAD_SSP1_DATA3__GPIO_2_15 |
> > (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> > @@ -106,8 +119,14 @@ static void __init mx28evk_fec_reset(void)
> > gpio_set_value(MX28EVK_FEC_PHY_RESET, 1);
> > }
> >
> > -static const struct fec_platform_data mx28_fec_pdata __initconst = {
> > - .phy = PHY_INTERFACE_MODE_RMII,
> > +static struct fec_platform_data mx28_fec_pdata[] = {
> this can still be initdata, doesn't it?
>
Sascha has merged the patch. This one line change may not deserve
a separate patch, so I will take care of it when updating the file
with new version of ocotp patch.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-14 6:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel, Po-Yu Chuang
In-Reply-To: <1294928559.3570.130.camel@edumazet-laptop>
Dear Eric,
On Thu, Jan 13, 2011 at 10:22 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 13 janvier 2011 à 19:49 +0800, Po-Yu Chuang a écrit :
>> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>>
>> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
>> MII. This driver has been working on some ARM/NDS32 SoC including
>> Faraday A320 and Andes AG101.
>>
>> Signed-off-by: Po-Yu Chuang <ratbert@faraday-tech.com>
> Hi
>
> 1) please use netdev_alloc_skb_ip_align() instead of dev_alloc_skb() +
> skb_reserve(skb, NET_IP_ALIGN);
OK, fixed.
> 2) Dont include a "struct net_device_stats stats" in struct ftmac100,
> you can use the one included in struct net_device
> (You can then remove ftmac100_get_stats())
OK, fixed.
> 3) Dont "netdev->last_rx = jiffies;" : This is not driver job.
> Ditto for trans_start
OK, fixed.
> 4) You must comment why wmb() is needed in ftmac100_xmit()
OK, comment added.
> 5) Why isnt NAPI used too for TX completions ?
> BTW, I am not sure we want a define. All new drivers must use NAPI.
I'll study how to do that
> 6) Use is_valid_ether_addr() instead of is_zero_ether_addr() in
> ftmac100_probe()
OK, fixed.
> 7) "static struct ethtool_ops ftmac100_ethtool_ops" should be const :
> "static const struct ethtool_ops ftmac100_ethtool_ops"
> Ditto for :
> "static struct net_device_ops ftmac100_netdev_ops"
OK, both fixed.
> 8) Why an interrupt handler (ftmac100_interrupt()) needs to block
> interrupts with spin_lock_irqsave(&priv->hw_lock, flags); ?
Fixed. Not a problem anymore since hw_lock is removed now.
> 9) Instead of dev_info(&netdev->dev ...) , please consider netdev_info()
OK, fixed.
Thanks a lot for your detailed review. I'll submit a new version ASAP.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Michael S. Tsirkin @ 2011-01-14 6:54 UTC (permalink / raw)
To: Simon Horman
Cc: Jesse Gross, Eric Dumazet, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110114063528.GB10957@verge.net.au>
On Fri, Jan 14, 2011 at 03:35:28PM +0900, Simon Horman wrote:
> On Fri, Jan 14, 2011 at 06:58:18AM +0200, Michael S. Tsirkin wrote:
> > On Fri, Jan 14, 2011 at 08:41:36AM +0900, Simon Horman wrote:
> > > On Thu, Jan 13, 2011 at 10:45:38AM -0500, Jesse Gross wrote:
> > > > On Thu, Jan 13, 2011 at 1:47 AM, Simon Horman <horms@verge.net.au> wrote:
> > > > > On Mon, Jan 10, 2011 at 06:31:55PM +0900, Simon Horman wrote:
> > > > >> On Fri, Jan 07, 2011 at 10:23:58AM +0900, Simon Horman wrote:
> > > > >> > On Thu, Jan 06, 2011 at 05:38:01PM -0500, Jesse Gross wrote:
> > > > >> >
> > > > >> > [ snip ]
> > > > >> > >
> > > > >> > > I know that everyone likes a nice netperf result but I agree with
> > > > >> > > Michael that this probably isn't the right question to be asking. I
> > > > >> > > don't think that socket buffers are a real solution to the flow
> > > > >> > > control problem: they happen to provide that functionality but it's
> > > > >> > > more of a side effect than anything. It's just that the amount of
> > > > >> > > memory consumed by packets in the queue(s) doesn't really have any
> > > > >> > > implicit meaning for flow control (think multiple physical adapters,
> > > > >> > > all with the same speed instead of a virtual device and a physical
> > > > >> > > device with wildly different speeds). The analog in the physical
> > > > >> > > world that you're looking for would be Ethernet flow control.
> > > > >> > > Obviously, if the question is limiting CPU or memory consumption then
> > > > >> > > that's a different story.
> > > > >> >
> > > > >> > Point taken. I will see if I can control CPU (and thus memory) consumption
> > > > >> > using cgroups and/or tc.
> > > > >>
> > > > >> I have found that I can successfully control the throughput using
> > > > >> the following techniques
> > > > >>
> > > > >> 1) Place a tc egress filter on dummy0
> > > > >>
> > > > >> 2) Use ovs-ofctl to add a flow that sends skbs to dummy0 and then eth1,
> > > > >> this is effectively the same as one of my hacks to the datapath
> > > > >> that I mentioned in an earlier mail. The result is that eth1
> > > > >> "paces" the connection.
> >
> > This is actually a bug. This means that one slow connection will affect
> > fast ones. I intend to change the default for qemu to sndbuf=0 : this
> > will fix it but break your "pacing". So pls do not count on this
> > behaviour.
>
> Do you have a patch I could test?
You can (and users already can) just run qemu with sndbuf=0. But if you
like, below.
> > > > > Further to this, I wonder if there is any interest in providing
> > > > > a method to switch the action order - using ovs-ofctl is a hack imho -
> > > > > and/or switching the default action order for mirroring.
> > > >
> > > > I'm not sure that there is a way to do this that is correct in the
> > > > generic case. It's possible that the destination could be a VM while
> > > > packets are being mirrored to a physical device or we could be
> > > > multicasting or some other arbitrarily complex scenario. Just think
> > > > of what a physical switch would do if it has ports with two different
> > > > speeds.
> > >
> > > Yes, I have considered that case. And I agree that perhaps there
> > > is no sensible default. But perhaps we could make it configurable somehow?
> >
> > The fix is at the application level. Run netperf with -b and -w flags to
> > limit the speed to a sensible value.
>
> Perhaps I should have stated my goals more clearly.
> I'm interested in situations where I don't control the application.
Well an application that streams UDP without any throttling
at the application level will break on a physical network, right?
So I am not sure why should one try to make it work on the virtual one.
But let's assume that you do want to throttle the guest
for reasons such as QOS. The proper approach seems
to be to throttle the sender, not have a dummy throttled
receiver "pacing" it. Place the qemu process in the
correct net_cls cgroup, set the class id and apply a rate limit?
---
diff --git a/net/tap-linux.c b/net/tap-linux.c
index f7aa904..0dbcdd4 100644
--- a/net/tap-linux.c
+++ b/net/tap-linux.c
@@ -87,7 +87,7 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr, int vnet_hdr_required
* Ethernet NICs generally have txqueuelen=1000, so 1Mb is
* a good default, given a 1500 byte MTU.
*/
-#define TAP_DEFAULT_SNDBUF 1024*1024
+#define TAP_DEFAULT_SNDBUF 0
int tap_set_sndbuf(int fd, QemuOpts *opts)
{
^ permalink raw reply related
* Re: [PATCH] r8169: keep firmware in memory.
From: Michael Tokarev @ 2011-01-14 6:52 UTC (permalink / raw)
To: Francois Romieu
Cc: David Miller, netdev, Jarek Kamiński, Hayes, Ben Hutchings,
Linus Torvalds
In-Reply-To: <20110113230753.GA2750@electric-eye.fr.zoreil.com>
14.01.2011 02:07, Francois Romieu wrote:
> The firmware agent is not available during resume. Loading the firmware
> during open() (see eee3a96c6368f47df8df5bd4ed1843600652b337) is not
> enough.
>
> close() is run during resume through rtl8169_reset_task(), whence the
> mildly natural release of firmware in the driver removal method instead.
>
> It will help with http://bugs.debian.org/609538. It will not avoid
> the 60 seconds delay when:
> - there is no firmware
> - the driver is loaded and the device is not up before a suspend/resume
Given all this I think this is somewhat clumsy still. How
does other NIC drivers handles this situation - e.g. tg3?
Maybe this needs to be a generic solution instead of per-driver?
/mjt
^ permalink raw reply
* [PATCH] ARM: mxs: pass fec device name via platform data
From: Shawn Guo @ 2011-01-14 6:53 UTC (permalink / raw)
To: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw; +Cc: Shawn Guo
In-Reply-To: <20110113150622.GV24920@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-mxs/devices/platform-fec.c | 11 ++++++-----
arch/arm/mach-mxs/include/mach/devices-common.h | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-mxs/devices/platform-fec.c b/arch/arm/mach-mxs/devices/platform-fec.c
index c42dff7..75eb26b 100644
--- a/arch/arm/mach-mxs/devices/platform-fec.c
+++ b/arch/arm/mach-mxs/devices/platform-fec.c
@@ -10,20 +10,21 @@
#include <mach/mx28.h>
#include <mach/devices-common.h>
-#define mxs_fec_data_entry_single(soc, _id) \
+#define mxs_fec_data_entry_single(soc, _devid, _id) \
{ \
+ .devid = _devid, \
.id = _id, \
.iobase = soc ## _ENET_MAC ## _id ## _BASE_ADDR, \
.irq = soc ## _INT_ENET_MAC ## _id, \
}
-#define mxs_fec_data_entry(soc, _id) \
- [_id] = mxs_fec_data_entry_single(soc, _id)
+#define mxs_fec_data_entry(soc, _devid, _id) \
+ [_id] = mxs_fec_data_entry_single(soc, _devid, _id)
#ifdef CONFIG_SOC_IMX28
const struct mxs_fec_data mx28_fec_data[] __initconst = {
#define mx28_fec_data_entry(_id) \
- mxs_fec_data_entry(MX28, _id)
+ mxs_fec_data_entry(MX28, "imx28-fec", _id)
mx28_fec_data_entry(0),
mx28_fec_data_entry(1),
};
@@ -45,6 +46,6 @@ struct platform_device *__init mxs_add_fec(
},
};
- return mxs_add_platform_device("imx28-fec", data->id,
+ return mxs_add_platform_device(data->devid, data->id,
res, ARRAY_SIZE(res), pdata, sizeof(*pdata));
}
diff --git a/arch/arm/mach-mxs/include/mach/devices-common.h b/arch/arm/mach-mxs/include/mach/devices-common.h
index 6c3d1a1..10fbcfd 100644
--- a/arch/arm/mach-mxs/include/mach/devices-common.h
+++ b/arch/arm/mach-mxs/include/mach/devices-common.h
@@ -33,6 +33,7 @@ int __init mxs_add_duart(const struct amba_device *dev);
/* fec */
#include <linux/fec.h>
struct mxs_fec_data {
+ const char *devid;
int id;
resource_size_t iobase;
resource_size_t iosize;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-14 6:49 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel, Po-Yu Chuang
In-Reply-To: <1294959948.4114.189.camel@Joe-Laptop>
Dear Joe,
On Fri, Jan 14, 2011 at 7:05 AM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2011-01-13 at 19:49 +0800, Po-Yu Chuang wrote:
>> From: Po-Yu Chuang <ratbert@faraday-tech.com>
> []
>> + if (is_zero_ether_addr(netdev->dev_addr)) {
>> + random_ether_addr(netdev->dev_addr);
>> + dev_info(&netdev->dev, "generated random MAC address "
>> + "%.2x:%.2x:%.2x:%.2x:%.2x:%.2x.\n",
>> + netdev->dev_addr[0], netdev->dev_addr[1],
>> + netdev->dev_addr[2], netdev->dev_addr[3],
>> + netdev->dev_addr[4], netdev->dev_addr[5]);
>
> Sorry, one other thing.
> There are kernel specific printf extensions for pointer types.
> (look at lib/vsprintf.c) There's one for mac addresses: "%pM".
> This could be done as:
>
> netdev_info(netdev, "Generated random MAC address: %pM\n",
> netdev->dev_addr);
Wow, this is pretty beautiful. Thanks.
best regards,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-14 6:44 UTC (permalink / raw)
To: Andres Salomon; +Cc: Eric Dumazet, netdev, linux-kernel, Po-Yu Chuang
In-Reply-To: <20110113082950.6747ebb8@queued.net>
Dear Andres,
On Fri, Jan 14, 2011 at 12:29 AM, Andres Salomon <dilinger@queued.net> wrote:
> On Thu, 13 Jan 2011 15:22:39 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Le jeudi 13 janvier 2011 à 19:49 +0800, Po-Yu Chuang a écrit :
> No one else mentioned it, so I'll add:
>
> Don't explicitly inline functions unless they're in a header, or you
> have a really good reason (and that reason should probably be described
> in a comment). Otherwise, just leave off the 'inline' keyword; the
> compiler is smart enough to decide whether a function should be inlined
> or not.
OK, fixed.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH v4 06/10] ARM: mx28: update clock and device name for dual fec support
From: Shawn Guo @ 2011-01-14 6:46 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, jamie, jamie, netdev, linux-arm-kernel
In-Reply-To: <20110113150622.GV24920@pengutronix.de>
Hi Uwe,
On Thu, Jan 13, 2011 at 04:06:22PM +0100, Uwe Kleine-König wrote:
> Hi Shawn,
>
> On Thu, Jan 06, 2011 at 03:13:14PM +0800, Shawn Guo wrote:
> > Change device name from "fec" to "imx28-fec", so that fec driver
> > can distinguish mx28.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > Changes for v4:
> > - Use "imx28-fec" as fec device name
> >
> > Changes for v3:
> > - Change device name to "enet-mac"
> >
> > arch/arm/mach-mxs/clock-mx28.c | 3 ++-
> > arch/arm/mach-mxs/devices/platform-fec.c | 2 +-
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-mxs/clock-mx28.c b/arch/arm/mach-mxs/clock-mx28.c
> > index f20b254..e2a8b0f 100644
> > --- a/arch/arm/mach-mxs/clock-mx28.c
> > +++ b/arch/arm/mach-mxs/clock-mx28.c
> > @@ -606,7 +606,8 @@ static struct clk_lookup lookups[] = {
> > _REGISTER_CLOCK("duart", "apb_pclk", xbus_clk)
> > /* for amba-pl011 driver */
> > _REGISTER_CLOCK("duart", NULL, uart_clk)
> > - _REGISTER_CLOCK("fec.0", NULL, fec_clk)
> > + _REGISTER_CLOCK("imx28-fec.0", NULL, fec_clk)
> > + _REGISTER_CLOCK("imx28-fec.1", NULL, fec_clk)
> > _REGISTER_CLOCK("rtc", NULL, rtc_clk)
> > _REGISTER_CLOCK("pll2", NULL, pll2_clk)
> > _REGISTER_CLOCK(NULL, "hclk", hbus_clk)
> > diff --git a/arch/arm/mach-mxs/devices/platform-fec.c b/arch/arm/mach-mxs/devices/platform-fec.c
> > index c08168c..c42dff7 100644
> > --- a/arch/arm/mach-mxs/devices/platform-fec.c
> > +++ b/arch/arm/mach-mxs/devices/platform-fec.c
> > @@ -45,6 +45,6 @@ struct platform_device *__init mxs_add_fec(
> > },
> > };
> >
> > - return mxs_add_platform_device("fec", data->id,
> > + return mxs_add_platform_device("imx28-fec", data->id,
> IMHO "imx28-fec" shouldn't be hard coded here but come from data. See
> imx-spi device registration for an example.
>
Sascha has merged the patch, so I will send a follow-up patch.
--
Regards,
Shawn
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Simon Horman @ 2011-01-14 6:35 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jesse Gross, Eric Dumazet, Rusty Russell, virtualization, dev,
virtualization, netdev, kvm
In-Reply-To: <20110114045818.GA29738@redhat.com>
On Fri, Jan 14, 2011 at 06:58:18AM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 14, 2011 at 08:41:36AM +0900, Simon Horman wrote:
> > On Thu, Jan 13, 2011 at 10:45:38AM -0500, Jesse Gross wrote:
> > > On Thu, Jan 13, 2011 at 1:47 AM, Simon Horman <horms@verge.net.au> wrote:
> > > > On Mon, Jan 10, 2011 at 06:31:55PM +0900, Simon Horman wrote:
> > > >> On Fri, Jan 07, 2011 at 10:23:58AM +0900, Simon Horman wrote:
> > > >> > On Thu, Jan 06, 2011 at 05:38:01PM -0500, Jesse Gross wrote:
> > > >> >
> > > >> > [ snip ]
> > > >> > >
> > > >> > > I know that everyone likes a nice netperf result but I agree with
> > > >> > > Michael that this probably isn't the right question to be asking. I
> > > >> > > don't think that socket buffers are a real solution to the flow
> > > >> > > control problem: they happen to provide that functionality but it's
> > > >> > > more of a side effect than anything. It's just that the amount of
> > > >> > > memory consumed by packets in the queue(s) doesn't really have any
> > > >> > > implicit meaning for flow control (think multiple physical adapters,
> > > >> > > all with the same speed instead of a virtual device and a physical
> > > >> > > device with wildly different speeds). The analog in the physical
> > > >> > > world that you're looking for would be Ethernet flow control.
> > > >> > > Obviously, if the question is limiting CPU or memory consumption then
> > > >> > > that's a different story.
> > > >> >
> > > >> > Point taken. I will see if I can control CPU (and thus memory) consumption
> > > >> > using cgroups and/or tc.
> > > >>
> > > >> I have found that I can successfully control the throughput using
> > > >> the following techniques
> > > >>
> > > >> 1) Place a tc egress filter on dummy0
> > > >>
> > > >> 2) Use ovs-ofctl to add a flow that sends skbs to dummy0 and then eth1,
> > > >> this is effectively the same as one of my hacks to the datapath
> > > >> that I mentioned in an earlier mail. The result is that eth1
> > > >> "paces" the connection.
>
> This is actually a bug. This means that one slow connection will affect
> fast ones. I intend to change the default for qemu to sndbuf=0 : this
> will fix it but break your "pacing". So pls do not count on this
> behaviour.
Do you have a patch I could test?
> > > > Further to this, I wonder if there is any interest in providing
> > > > a method to switch the action order - using ovs-ofctl is a hack imho -
> > > > and/or switching the default action order for mirroring.
> > >
> > > I'm not sure that there is a way to do this that is correct in the
> > > generic case. It's possible that the destination could be a VM while
> > > packets are being mirrored to a physical device or we could be
> > > multicasting or some other arbitrarily complex scenario. Just think
> > > of what a physical switch would do if it has ports with two different
> > > speeds.
> >
> > Yes, I have considered that case. And I agree that perhaps there
> > is no sensible default. But perhaps we could make it configurable somehow?
>
> The fix is at the application level. Run netperf with -b and -w flags to
> limit the speed to a sensible value.
Perhaps I should have stated my goals more clearly.
I'm interested in situations where I don't control the application.
^ permalink raw reply
* Re: [PATCH] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-14 6:35 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, linux-kernel, Po-Yu Chuang
In-Reply-To: <1294933197.4114.85.camel@Joe-Laptop>
Dear Joe,
On Thu, Jan 13, 2011 at 11:39 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2011-01-13 at 19:49 +0800, Po-Yu Chuang wrote:
>> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>>
>> FTMAC100 Ethernet Media Access Controller supports 10/100 Mbps and
>> MII. This driver has been working on some ARM/NDS32 SoC including
>> Faraday A320 and Andes AG101.
>
> A couple of trivial comments not already mentioned by others.
>
>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> []
>> @@ -2014,6 +2014,15 @@ config BCM63XX_ENET
>> This driver supports the ethernet MACs in the Broadcom 63xx
>> MIPS chipset family (BCM63XX).
>>
>> +config FTMAC100
>> + tristate "Faraday FTMAC100 10/100 Ethernet support"
>> + depends on ARM
>> + select MII
>> + help
>> + This driver supports the FTMAC100 Ethernet controller from
>> + Faraday. It is used on Faraday A320, Andes AG101, AG101P
>> + and some other ARM/NDS32 SoC's.
>> +
>
> ARM specific net drivers are for now in drivers/net/arm/
> Perhaps it's better to locate these files there?
This controller is used by not only ARM-base platforms, but also
NDS32-base ones.
NDS32 is an ISA designed by Andes tech. Although it is not yet in the mainline,
they plan to push their stuff to mainline and are working on that.
So... I don't know if it is better to put my driver to driver/net/arm/.
Should I leave my driver at driver/net/ or put it in drvier/net/arm/
and let Andes tech guys
move it out of driver/net/arm/ when they use it later?
>> + if (unlikely(ftmac100_rxdes_rx_error(rxdes))) {
>> + if (printk_ratelimit())
>> + dev_info(dev, "rx err\n");
>
> There are many printk_ratelimit() tests.
>
> It's better to use net_ratelimit() or a local ratelimit_state
> so there's less possible suppression of other subsystem
> messages.
OK, fixed.
Thanks a lot for your absolutely non-trivial review. :-)
I'll submit a new version ASAP.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH 04/10] GRETH: added greth_compat_mode module parameter
From: David Miller @ 2011-01-14 6:14 UTC (permalink / raw)
To: daniel; +Cc: netdev, kristoffer
In-Reply-To: <1294907135-24884-4-git-send-email-daniel@gaisler.com>
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Thu, 13 Jan 2011 09:25:29 +0100
> The greth_compat_mode option can be used to set a GRETH GBit capable MAC
> in operate as if the GRETH 10/100 device was found. The GRETH GBit supports
> TCP/UDP checksum offloading, unaligned frame buffers, scatter gather etc.
> Enabling this mode allows the developer to test the GRETH 10/100 device
> without all features mentioned above on a GBit MAC capable of the above.
>
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
No special device specific module parameters please.
What if every single driver author added something like this and they
all named it something different or made it behave in slightly differing
ways?
What kind of user experience would that result in?
It would result in a sucky one, which is why we avoid adding all kinds
of hacky driver specific module options.
Find a generic way to provide this functionality.
^ permalink raw reply
* Re: [PATCH 03/10] GRETH: added no_gbit option
From: David Miller @ 2011-01-14 6:13 UTC (permalink / raw)
To: daniel; +Cc: netdev, kristoffer
In-Reply-To: <1294907135-24884-3-git-send-email-daniel@gaisler.com>
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Thu, 13 Jan 2011 09:25:28 +0100
> For debug only. The driver does not report that it is GBit capable, instead
> it will report 10/100 mode to the generic PHY layer.
>
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
You may not add special purpose module parameters to your ethernet driver.
Instead, users can use ethtool to control what speeds the device will
try to advertise for during auto-negotiation, or use with a fixed
link configuration.
^ permalink raw reply
* Re: [PATCH 02/10] GRETH: added option to disable a device node from bootloader.
From: David Miller @ 2011-01-14 6:12 UTC (permalink / raw)
To: daniel; +Cc: netdev, kristoffer
In-Reply-To: <1294907135-24884-2-git-send-email-daniel@gaisler.com>
From: Daniel Hellstrom <daniel@gaisler.com>
Date: Thu, 13 Jan 2011 09:25:27 +0100
> Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
This is not how you do this.
Simply not present the device in the OpenFirmware tree at all. If you
can make this special properly appear, you can also toss the device
node away completely.
There is zero reason whatsoever to create a special hack-job
non-standardized device node properly to do this.
^ 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