* [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Linas Vepstas @ 2006-08-11 17:11 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
This patch adds version information as reported by
ethtool -i to the Spidernet driver.
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
----
drivers/net/spider_net.c | 3 +++
drivers/net/spider_net.h | 2 ++
drivers/net/spider_net_ethtool.c | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-11 11:34:16.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-11 11:38:48.000000000 -0500
@@ -55,6 +55,7 @@ MODULE_AUTHOR("Utz Bacher <utz.bacher@de
"<Jens.Osterkamp@de.ibm.com>");
MODULE_DESCRIPTION("Spider Southbridge Gigabit Ethernet driver");
MODULE_LICENSE("GPL");
+MODULE_VERSION(VERSION);
static int rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_DEFAULT;
static int tx_descriptors = SPIDER_NET_TX_DESCRIPTORS_DEFAULT;
@@ -2293,6 +2294,8 @@ static struct pci_driver spider_net_driv
*/
static int __init spider_net_init(void)
{
+ printk("spidernet Version %s.\n",VERSION);
+
if (rx_descriptors < SPIDER_NET_RX_DESCRIPTORS_MIN) {
rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_MIN;
pr_info("adjusting rx descriptors to %i.\n", rx_descriptors);
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-11 11:19:47.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-11 11:38:48.000000000 -0500
@@ -24,6 +24,8 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
+#define VERSION "1.1 A"
+
#include "sungem_phy.h"
extern int spider_net_stop(struct net_device *netdev);
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net_ethtool.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net_ethtool.c 2006-06-17 20:49:35.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net_ethtool.c 2006-08-11 11:38:48.000000000 -0500
@@ -55,7 +55,7 @@ spider_net_ethtool_get_drvinfo(struct ne
/* clear and fill out info */
memset(drvinfo, 0, sizeof(struct ethtool_drvinfo));
strncpy(drvinfo->driver, spider_net_driver_name, 32);
- strncpy(drvinfo->version, "0.1", 32);
+ strncpy(drvinfo->version, VERSION, 32);
strcpy(drvinfo->fw_version, "no information");
strncpy(drvinfo->bus_info, pci_name(card->pdev), 32);
}
^ permalink raw reply
* Re: Reg. Serial and Virtual consoles
From: Linas Vepstas @ 2006-08-11 17:18 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <3115522870674b0dc514.719885386.miltonm@bga.com>
On Thu, Aug 10, 2006 at 11:51:46AM -0500, Milton Miller wrote:
> It sounds to me that you want all input and output on the serial line to be echoed to the vga screen both user and kernel. Do you also require keyboard input?
I missed the start of the conversation, so the following suggestion may
be irrelevent. However, if the goal is to get kernel messages displayed
in lots of different places, this is easily done by running syslogd, and
adding the following to /etc/syslog.conf:
kern.*;*.err *
If you don' want them slatered everywhere, but only on
the console, then:
kern.*;*.err |/dev/console
--linas
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: jschopp @ 2006-08-11 17:42 UTC (permalink / raw)
To: Linas Vepstas
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
Linas Vepstas wrote:
> The following series of patches implement some fixes and performance
> improvements for the Spedernet ethernet device driver. The high point
> of the patch series is some code to implement a low-watermark interrupt
> on the transmit queue. The bundle of patches raises transmit performance
> from some embarassingly low value to a reasonable 730 Megabits per
> second for 1500 byte packets.
>
> Please note that the spider is an ethernet controller that is
> integrated into the south bridge, and is thus available only on
> Cell-based platforms.
>
> These have been well-tested over the last few weeks. Please apply.
With these patches the spidernet driver performance goes from bad to usable. They are all
good changes. I'd expect some more bottlnecks to be identified now that these are
cleared. Maybe Jim and Linas can get the driver performance up from usable to good next.
Acked-by: Joel Schopp <jschopp@austin.ibm.com>
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Sam Ravnborg @ 2006-08-11 17:44 UTC (permalink / raw)
To: Linas Vepstas
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
On Fri, Aug 11, 2006 at 12:03:37PM -0500, Linas Vepstas wrote:
>
> The following series of patches implement some fixes and performance
> improvements for the Spedernet ethernet device driver. The high point
> of the patch series is some code to implement a low-watermark interrupt
> on the transmit queue. The bundle of patches raises transmit performance
> from some embarassingly low value to a reasonable 730 Megabits per
> second for 1500 byte packets.
>
> Please note that the spider is an ethernet controller that is
> integrated into the south bridge, and is thus available only on
> Cell-based platforms.
>
> These have been well-tested over the last few weeks. Please apply.
Hi Linas.
Just noticed a nit-pick detail.
The general rule is to add your Signed-off-by: at the bottom of the
patch, so the top-most Signed-of-by: is also the original author whereas
the last Signed-of-by: is the one that added this patch to the kernel.
Likewise you add Cc: before your Signed-off-by: line.
See patches from for example Andrew Morton for examples.
Sam
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: john stultz @ 2006-08-11 17:56 UTC (permalink / raw)
To: Tsutomu OWA; +Cc: linuxppc-dev, mingo, Paul Mackerras, linux-kernel, tglx
In-Reply-To: <yyiac6biz3c.wl@forest.swc.toshiba.co.jp>
On Fri, 2006-08-11 at 15:08 +0900, Tsutomu OWA wrote:
> > On Fri, 11 Aug 2006 15:11:47 +1000
> > Paul Mackerras <paulus@samba.org> said:
>
> > I would be very surprised if this is all that is required for
> > CONFIG_GENERIC_TIME to work correctly on powerpc. Have you verified
> > that the CONFIG_GENERIC_TIME stuff works correctly on powerpc and
> > provides all the features provided by the current implementation?
>
> Well, probably no as you say so.
>
> What I did for CONFIG_GENERIC_TIME is just to fix a compile
> error and to see if the kernel boots or not. As I mentioned,
> it's experimental and is posted to see whether I'm moving in the
> right direction or not.
>
> I'm afraid I have not yet looked into any generic time related
> features/implementations. Looks like generic time related things
> should be on the ToDo list.
You might take a peek at the patch set here:
http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
CONFIG_GENERIC_TIME.
thanks
-john
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Olof Johansson @ 2006-08-11 18:00 UTC (permalink / raw)
To: Linas Vepstas
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811171117.GL10638@austin.ibm.com>
On Fri, Aug 11, 2006 at 12:11:17PM -0500, Linas Vepstas wrote:
> This patch adds version information as reported by
> ethtool -i to the Spidernet driver.
Why does a driver that's in the mainline kernel need to have a version
number besides the kernel version?
I can understand it for drivers like e1000 that Intel maintain outside
of the kernel as well. But spidernet is a fully mainline maintained
driver, right?
-Olof
^ permalink raw reply
* RE: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : differentoutputs
From: Haruki Dai-r35557 @ 2006-08-11 18:08 UTC (permalink / raw)
To: Kumar Gala, Prashant Yendigeri; +Cc: linuxppc-embedded
In-Reply-To: <CFF33627-951D-495D-8DBB-B0AC7F9D13D7@kernel.crashing.org>
Why there are three TSEC on the MPC8540??=20
Dai
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+dai.haruki=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+dai.haruki=3Dfreescale.com@ozl
> abs.org] On Behalf Of Kumar Gala
> Sent: Friday, August 11, 2006 7:38 AM
> To: Prashant Yendigeri
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6=20
> : differentoutputs
>=20
>=20
> On Aug 11, 2006, at 6:21 AM, Prashant Yendigeri wrote:
>=20
> >
> > Hi,
> >
> > Downloaded 2.6.16.26 and booted up and got this :
> >
> > / # ifconfig eth0 172.28.8.254 up
> > [ 34.034596] 0:00 not found
> > [ 34.037330] eth0: Could not attach to PHY
> > [ 34.041809] 0:00 not found
> > SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to PHY
> > such device
> > SIOCSIFFLAGS: No such device
> >
> > I had enabled all the PHY devices in .config and also tried only =20
> > with Marvell phy enabled.
>=20
>=20
> Are you doing this on a custom board? If so what is the PHY address =20
> for the Marvell phy you are using?
>=20
> - k
>=20
> >
> > Kernel boot messages :
> > [ 2.296555] Gianfar MII Bus: probed
> > [ 2.301789] eth0: Gianfar Ethernet Controller Version 1.2, =20
> > 00:01:af:07:9b:8a
> >
> > [ 2.309039] eth0: Running with NAPI disabled
> > [ 2.313307] eth0: 64/64 RX/TX BD ring size
> > [ 2.318498] eth1: Gianfar Ethernet Controller Version 1.2, =20
> > 00:00:00:00:72:6f
> >
> > [ 2.325738] eth1: Running with NAPI disabled
> > [ 2.330006] eth1: 64/64 RX/TX BD ring size
> > [ 2.335198] eth2: Gianfar Ethernet Controller Version 1.2, 6f:=20
> > 74:3d:2f:64:65
> >
> > [ 2.342377] eth2: Running with NAPI disabled
> > [ 2.346662] eth2: 64/64 RX/TX BD ring size
> > [ 2.351586] Marvell 88E1101: Registered new driver
> > [ 2.357010] Davicom DM9161E: Registered new driver
> > [ 2.362443] Davicom DM9131: Registered new driver
> > [ 2.367775] Cicada Cis8204: Registered new driver
> > [ 2.373136] LXT970: Registered new driver
> > [ 2.377794] LXT971: Registered new driver
> > [ 2.382461] QS6612: Registered new driver
> >
> >
> > Regards,
> > Prashant
> >
> >
> >
> >
> >
> > Kumar Gala <galak@kernel.crashing.org>
> > 08/11/2006 09:40 AM
> >
> > To
> > Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
> > cc
> > linuxppc-embedded@ozlabs.org
> > Subject
> > Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different =20
> > outputs
> >
> >
> >
> >
> >
> >
> > On Aug 10, 2006, at 6:18 AM, Prashant Yendigeri wrote:
> >
> > >
> > > Hi,
> > >
> > > The gianfar driver of 2.6.12 and 2.4.20 give different outputs on
> > > the same PPC 8540 board.
> > >
> > > What could be the reason ?
> > >
> > > Output on 2.4.20 :
> > > /root # ifconfig eth0 172.28.8.254 up
> > > eth0: PHY is Marvell 88E1011S (1410c62)
> > > eth0: Auto-negotiation done
> > > eth0: Half Duplex
> > > eth0: Speed 10BT
> > > eth0: Link is up
> > >
> > > Output on 2.6.12
> > > / # ifconfig eth0 172.28.8.254 up
> > > eth0: PHY is Generic MII (ffffffff)
> >
> > It looks like your 2.6.12 kernel isn't handling the PHY correctly.
> > I'd recommend upgrading to something newer which has the phylib
> > (can't remember which 2.6 that went into).
> >
> > - kumar
> >
> >=20
> ______________________________________________________________________
> >
> >
> >=20
> ______________________________________________________________________
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: [RFC] asm code for Hypervisor Call Instrumentation
From: Mike Kravetz @ 2006-08-11 18:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17622.56592.41532.206800@cargo.ozlabs.ibm.com>
On Mon, Aug 07, 2006 at 04:26:24PM +1000, Paul Mackerras wrote:
> Hmmm, doing the update in assembly would avoid the need to create a
> stack frame, which would be nice... Maybe we need to add some macros
> to include/asm-powerpc/percpu.h to make it easier to access per-cpu
> variables from assembly code.
>
> Alternatively, we could put a pointer to the hcall_stats array for
> each cpu in its paca. That's very easily accessed from assembly code.
I finally got around to doing the update in assembly. I have attached
the code in question below. Macros were added (elsewhere) for things like
stat structure and offsets within the structure. No macros for per-cpu
data. Rather, I just used some existing definitions and based code on
descriptions in asm-powerpc/percpu.h. Let me know if this introduces too
many (unchecked at compile time assumptions) into the code.
The many comments are mostly for my benefit. :)
Thanks,
--
Mike
#define STK_PARM(i) (48 + ((i)-3)*8)
#ifdef CONFIG_HCALL_STATS
/*
* precall must preserve all registers. use unused STK_PARM()
* areas to save snapshots and opcode.
*/
#define HCALL_INST_PRECALL \
std r3,STK_PARM(r3)(r1); /* save opcode */ \
mftb r3; /* get timebase and */ \
std r3,STK_PARM(r5)(r1); /* save for later */ \
BEGIN_FTR_SECTION; \
mfspr r3,SPRN_PURR; /* get PURR and */ \
END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
std r3,STK_PARM(r6)(r1); /* save for later */ \
ld r3,STK_PARM(r3)(r1); /* opcode back in r3 */
/*
* postcall is performed immediately before function return which
* allows liberal use of non-volital registers.
*/
#define HCALL_INST_POSTCALL \
/* get time and PURR snapshots after hcall */ \
mftb r7; /* timebase after */ \
BEGIN_FTR_SECTION; \
mfspr r8,SPRN_PURR; /* PURR after */ \
END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
\
/* calculate time and PURR deltas for call */ \
ld r5,STK_PARM(r5)(r1); /* timebase before */ \
subf r5,r5,r7; \
ld r6,STK_PARM(r6)(r1); /* PURR before */ \
subf r6,r6,r8; \
\
/* calculate address of stat structure */ \
ld r4,STK_PARM(r3)(r1); /* use opcode as */ \
rldicl r4,r4,62,2; /* index into array */ \
mulli r4,r4,HCALL_STAT_SIZE; \
LOAD_REG_ADDR(r7, per_cpu__hcall_stats); \
add r4,r4,r7; \
ld r7,PACA_DATA_OFFSET(r13); /* per cpu offset */ \
add r4,r4,r7; \
\
/* update stats */ \
ld r7,HCALL_STAT_CALLS(r4); /* count */ \
addi r7,r7,1; \
std r7,HCALL_STAT_CALLS(r4); \
ld r7,HCALL_STAT_TB(r4); /* timebase */ \
add r7,r7,r5; \
std r7,HCALL_STAT_TB(r4); \
ld r7,HCALL_STAT_PURR(r4); /* PURR */ \
add r7,r7,r6; \
std r7,HCALL_STAT_PURR(r4);
#else
#define HCALL_INST_PRECALL
#define HCALL_INST_POSTCALL
#endif
^ permalink raw reply
* Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : differentoutputs
From: Matt Porter @ 2006-08-11 18:35 UTC (permalink / raw)
To: Haruki Dai-r35557; +Cc: Prashant Yendigeri, linuxppc-embedded
In-Reply-To: <18AEF66AFDF06F4CAAA1D419D000FD3380B85B@az33exm24.fsl.freescale.net>
On Fri, Aug 11, 2006 at 11:08:59AM -0700, Haruki Dai-r35557 wrote:
> Why there are three TSEC on the MPC8540??
There aren't. There are two TSECs and one FEC on the MPC8540.
gianfar drives them all (all the non-CPM enets, that is).
-Matt
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: James K Lewis @ 2006-08-11 18:50 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Jens Osterkamp, linux-kernel, linuxppc-dev, netdev
In-Reply-To: <20060811180013.GB6550@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
Hi Olof,
There are several reasons why an Ethernet driver should have an up to
date version number:
1. Customers like to see they are really getting a new version.
2. It makes it easier for support personnel (me in this case) to see which
driver they have. Sure, sometimes I can talk them thru doing a "sum" on
the .ko and all that, but why not just use the version number? That's what
it is for. And no, you can't just assume they have the version that came
with the kernel they are running. It doesn't work that way.
3. It makes bug reporting easier.
4. I have already run into too many problems and wasted too much time
working with drivers when the number was NOT getting updated.
Jim Lewis
Advisory Software Engineer
IBM Linux Technology Center
512-838-7754
Olof Johansson <olof@lixom.net>
08/11/2006 01:00 PM
To
Linas Vepstas <linas@austin.ibm.com>
cc
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Jens Osterkamp <Jens.Osterkamp@de.ibm.com>, James
K Lewis/Austin/IBM@ibmus, Arnd Bergmann <arnd@arndb.de>
Subject
Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
On Fri, Aug 11, 2006 at 12:11:17PM -0500, Linas Vepstas wrote:
> This patch adds version information as reported by
> ethtool -i to the Spidernet driver.
Why does a driver that's in the mainline kernel need to have a version
number besides the kernel version?
I can understand it for drivers like e1000 that Intel maintain outside
of the kernel as well. But spidernet is a fully mainline maintained
driver, right?
-Olof
[-- Attachment #2: Type: text/html, Size: 2701 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Linas Vepstas @ 2006-08-11 19:31 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811174439.GA30191@mars.ravnborg.org>
On Fri, Aug 11, 2006 at 07:44:39PM +0200, Sam Ravnborg wrote:
> >
> > These have been well-tested over the last few weeks. Please apply.
> Hi Linas.
> Just noticed a nit-pick detail.
> The general rule is to add your Signed-off-by: at the bottom of the
> patch, so the top-most Signed-of-by: is also the original author whereas
> the last Signed-of-by: is the one that added this patch to the kernel.
I put my name at the top when I was the primary author.
I put Jim's name at the top when he was the primary author.
Both names are there because I sat in Jim's office and used
his keyboard. I got him to compile and run the tests on
his hardware, and we'd then debate the results.
> Likewise you add Cc: before your Signed-off-by: line.
The patches I ave from akpm have the CC's after the
signed-off by line, not before.
--linas
^ permalink raw reply
* Re: [RFC] consolidated libdt proposal
From: Jon Loeliger @ 2006-08-11 19:33 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Cc: linuxppc-embedded, xen-ppc-devel@lists.xensource.com
In-Reply-To: <1155064370.5572.11.camel@localhost>
On Tue, 2006-08-08 at 14:12, Matthew McClintock wrote:
> This is a patch to u-boot with the changes.
>
> * Patch to modify ft_build.c to update flat device trees in place
> Patch by Matthew McClintock 26-June-2006
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
Also FYI, I have assembled all Matt's 85xx related U-Boot patches,
along with the corresponding 86xx updates, into the u-boot-86xx.git
tree on:
http://jdl.com/git_repos/
This U-Boot separates out the DTS files, but allows the DTB
to be downloaded. It can then update it and hand it off to
either an 85xx or 86xx linux kernel.
I use these commands, roughly:
# build U-boot and Linux as usual
$ dtc -f -V 0x10 -I dts -O dtb \
linux-2.6-86xx/arch/powerpc/boot/dts/mpc8641_hpcn.dts \
mpc8641_hpcn.dtb
In U-boot now:
> tftp 1000000 loeliger/uImage.8641
> tftp 900000 loeliger/mpc8641_hpcn.dtb
> bootm 1000000 - 900000
Enjoy,
jdl
^ permalink raw reply
* Re: [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Linas Vepstas @ 2006-08-11 19:46 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Jens Osterkamp, James K Lewis, linux-kernel,
linuxppc-dev, netdev
In-Reply-To: <OF934FE4E3.EEC44FDD-ON872571C7.00668651-862571C7.00677A44@us.ibm.com>
Hi Olof,
Olof Johansson <olof@lixom.net> writes:
> On Fri, Aug 11, 2006 at 12:11:17PM -0500, Linas Vepstas wrote:
>
> > This patch adds version information as reported by
> > ethtool -i to the Spidernet driver.
>
> Why does a driver that's in the mainline kernel need to have a version
> number besides the kernel version?
I'll let Jim be the primary defender. From what I can tell, "that's the
way its done". For example:
linux-2.6.18-rc3-mm2 $ grep MODULE_VERSION */*/*.c |wc
164 245 9081
> I can understand it for drivers like e1000 that Intel maintain outside
> of the kernel as well. But spidernet is a fully mainline maintained
> driver, right?
Yes, the spidernet is a Linux-kernel only driver.
--linas
p.s. very strange, but I did not see your original email;
only saw Jim's reply.
^ permalink raw reply
* Re: [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Arnd Bergmann @ 2006-08-11 20:27 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, James K Lewis, linux-kernel, linuxppc-dev, Sam Ravnborg,
Jens Osterkamp
In-Reply-To: <20060811193102.GN10638@austin.ibm.com>
On Friday 11 August 2006 21:31, Linas Vepstas wrote:
> I put my name at the top when I was the primary author.
> I put Jim's name at the top when he was the primary author.
>
> Both names are there because I sat in Jim's office and used
> his keyboard. I got him to compile and run the tests on
> his hardware, and we'd then debate the results.
When the patch gets added to a git repository, they end up
having your name on it, because the author is determined
from the person who sent the patch.
For the patches where Jim is the main author, you should put a
From: James K Lewis <jklewis@us.ibm.com>
into the first line of the email body. That will make the
scripts do the right thing. The order of the Signed-off-by:
lines is used is independant from authorship and should
list the name of the submitter last.
Arnd <><
^ permalink raw reply
* [PATCH] fix gettimeofday vs. update_gtod race
From: Nathan Lynch @ 2006-08-11 20:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Userspace can (very, very) occasionally get bogus time values due to
a tiny race between powerpc's do_gettimeofday and timer interrupt:
1. do_gettimeofday does get_tb()
2. decrementer exception on boot cpu which runs timer_recalc_offset,
which also samples the timebase and updates the do_gtod structure
with a greater timebase value.
3. do_gettimeofday calls __do_gettimeofday, which leads to the
negative result from tb_val - temp_varp->tb_orig_stamp.
The fix is to ensure that do_gettimeofday samples the timebase only
after loading do_gtod.varp.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 774c0a3..6b690df 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -417,7 +417,7 @@ static __inline__ void timer_check_rtc(v
/*
* This version of gettimeofday has microsecond resolution.
*/
-static inline void __do_gettimeofday(struct timeval *tv, u64 tb_val)
+static inline void __do_gettimeofday(struct timeval *tv)
{
unsigned long sec, usec;
u64 tb_ticks, xsec;
@@ -431,7 +431,12 @@ static inline void __do_gettimeofday(str
* without a divide (and in fact, without a multiply)
*/
temp_varp = do_gtod.varp;
- tb_ticks = tb_val - temp_varp->tb_orig_stamp;
+
+ /* Sampling the time base must be done after loading
+ * do_gtod.varp in order to avoid racing with update_gtod.
+ */
+ rmb();
+ tb_ticks = get_tb() - temp_varp->tb_orig_stamp;
temp_tb_to_xs = temp_varp->tb_to_xs;
temp_stamp_xsec = temp_varp->stamp_xsec;
xsec = temp_stamp_xsec + mulhdu(tb_ticks, temp_tb_to_xs);
@@ -464,7 +469,7 @@ void do_gettimeofday(struct timeval *tv)
tv->tv_usec = usec;
return;
}
- __do_gettimeofday(tv, get_tb());
+ __do_gettimeofday(tv);
}
EXPORT_SYMBOL(do_gettimeofday);
^ permalink raw reply related
* Re: [PATCH 1/6] ehea: interface to network stack
From: Anton Blanchard @ 2006-08-11 20:56 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99EFC.3000105@de.ibm.com>
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c 1969-12-31
> +#define DEB_PREFIX "main"
Doesnt appear to be used.
> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
...
> + cb2 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
I cant see where this gets freed.
> +
> + skb_index = ((index - i
> + + port_res->skb_arr_sq_len)
> + % port_res->skb_arr_sq_len);
This is going to force an expensive divide. Its much better to change
this to the simpler and quicker:
i++;
if (i > max)
i = 0;
There are a few places in the driver can be changed to do this.
> +static int ehea_setup_single_port(struct ehea_adapter *adapter,A
> + int portnum, struct device_node *dn)
...
> + cb4 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
I cant see where this is freed.
Anton
^ permalink raw reply
* Re: [RFC] Adding MTD to device tree
From: Arnd Bergmann @ 2006-08-11 21:10 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <44DCA2BF.1030002@ru.mvista.com>
On Friday 11 August 2006 17:31, Sergei Shtylyov wrote:
> + =A0 h) MTD nodes
> +
> + =A0 Memory Technology Devices are flash, ROM, and similar chips, often =
used
> + =A0 for solid state file systems on embedded devices.
> +
> + =A0 Required properties:
> +
> + =A0 =A0- device_type : has to be "mtd"
> + =A0 =A0- compatible : Should be the name of the MTD driver. Currently, =
this is
> + =A0 =A0 =A0most likely to be "physmap".
> + =A0 =A0- reg : Offset and length of the register set for the device.
I would prefer to call them something different in the device tree.
The name 'mtd' is very specific to Linux, but the device tree
is a more generic concept.
I understand that the booting-without-of.txt file is by definition
Linux specific as well, but we should be prepared for making parts
of it a OS independent binding at the point where we put the same
device nodes into actual OF implementations that able to boot
different operating systems.
I would prefer a naming that has=20
Required properties:
- device_type : one of "nand-flash", "nor-flash", or "rom".
- model : an identifier for the actual controller chip used.
- compatible : Should be the name of the MTD driver. For
type "rom", this is most likely "physmap".
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Anton Blanchard @ 2006-08-11 21:13 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_phyp.c 1969-12-31 16:00:00.000000000 -0800
> +u64 ehea_h_alloc_resource_eq(const u64 hcp_adapter_handle,
...
> +u64 hipz_h_reregister_pmr(const u64 adapter_handle,
...
> +static inline int hcp_galpas_ctor(struct h_galpas *galpas,
Be nice to have some consistent names, hipz_ and hcp_ is kind of
cryptic.
> +#define H_QP_CR_STATE_RESET 0x0000010000000000 /* Reset */
Probably want ULL on here and the other 64bit constants.
Anton
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Nathan Lynch @ 2006-08-11 21:19 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
Hi-
Jan-Bernd Themann wrote:
> +static inline long ehea_hcall_9arg_9ret(unsigned long opcode,
> + unsigned long arg1,
> + unsigned long arg2,
> + unsigned long arg3,
> + unsigned long arg4,
> + unsigned long arg5,
> + unsigned long arg6,
> + unsigned long arg7,
> + unsigned long arg8,
> + unsigned long arg9,
> + unsigned long *out1,
> + unsigned long *out2,
> + unsigned long *out3,
> + unsigned long *out4,
> + unsigned long *out5,
> + unsigned long *out6,
> + unsigned long *out7,
> + unsigned long *out8,
> + unsigned long *out9)
> +{
> + long hret = H_SUCCESS;
> + int i, sleep_msecs;
> +
> + EDEB_EN(7, "opcode=%lx arg1=%lx arg2=%lx arg3=%lx arg4=%lx "
> + "arg5=%lx arg6=%lx arg7=%lx arg8=%lx arg9=%lx",
> + opcode, arg1, arg2, arg3, arg4, arg5, arg6, arg7,
> + arg8, arg9);
> +
> +
> + for (i = 0; i < 5; i++) {
> + hret = plpar_hcall_9arg_9ret(opcode,
> + arg1, arg2, arg3, arg4,
> + arg5, arg6, arg7, arg8,
> + arg9,
> + out1, out2, out3, out4,
> + out5, out6, out7, out8,
> + out9);
> +
> + if (H_IS_LONG_BUSY(hret)) {
> + sleep_msecs = get_longbusy_msecs(hret);
> + msleep_interruptible(sleep_msecs);
> + continue;
> + }
Looping five times before giving up seems arbitrary and failure-prone
on busy systems.
Is msleep_interruptible (as opposed to msleep) really appropriate?
Hope all the callers of this function are in non-atomic context (but I
wasn't able to find any callers?).
And this function is too big to be inline.
^ permalink raw reply
* RE: MTD Flash Howto ?
From: Lee Revell @ 2006-08-11 21:26 UTC (permalink / raw)
To: Ned W. Rhodes; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <001a01c6b7d1$17dd6130$6201eed0@ssgpoweredge>
On Fri, 2006-08-04 at 10:20 -0400, Ned W. Rhodes wrote:
> The book Building Embedded Linux Systems has a good section on the use of
> flash file systems.
>
> When you boot, you will see something like this, depending on the type of
> flash driver you have. Make sure you have defined your mtd map in
> kernel/drivers/mtd/map.
>
> JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> JFS: nTxBlock = 965, nTxLock = 7720
>
Is JFFS2 required to mount MTD devices?
Everything seems to be set up correctly here:
S29GL512N MirrorBit Flash: probing 16-bit flash bus
S29GL512N MirrorBit Flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
S29GL512N MirrorBit Flash: CFI does not contain boot bank location.
Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 2 MTD partitions on "S29GL512N MirrorBit Flash":
0x00000000-0x02a00000 : "Raw Area"
ftl_cs: FTL header not found.
0x02a00000-0x02b80000 : "User FS"
ftl_cs: FTL header not found.
blkmtd: version $Revision: 1.24 $
blkmtd: error: missing `device' name
cat /proc/mtd:
dev: size erasesize name
mtd0: 02a00000 00020000 "Raw Area"
mtd1: 00180000 00020000 "User FS"
cat /proc/partitions:
major minor #blocks name
31 0 43008 mtdblock0
31 1 1536 mtdblock1
~ # ls -al /dev/mtdblock[01]
brw-r--r-- 1 root 0 31, 0 Aug 11 14:27 /dev/mtdblock0
brw-r--r-- 1 root 0 31, 1 Aug 11 14:27 /dev/mtdblock1
As you can see the major and minor numbers are correct, but I cannot
mount the MTD partitions:
~ # mount -t minix /dev/mtdblock1 foo
mount: Mounting /dev/mtdblock1 on /foo failed: No such device
What am I doing wrong?
Lee
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Nathan Lynch @ 2006-08-11 21:26 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <20060811211915.GL3233@localdomain>
Nathan Lynch wrote:
> Hope all the callers of this function are in non-atomic context (but I
> wasn't able to find any callers?).
Never mind, I somehow missed the users of ehea_hcall_9arg_9ret in this
patch, sorry.
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Anton Blanchard @ 2006-08-11 21:40 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F56.7010201@de.ibm.com>
Hi,
> drivers/net/ehea/ehea.h | 452
> +#define EHEA_DRIVER_NAME "IBM eHEA"
You are using this for ethtool get_drvinfo. Im not sure if it should
match the module name, and I worry about having a space in the name. Any
ideas on what we should be doing here?
> +#define NET_IP_ALIGN 0
Shouldnt override this in your driver.
> +#define EDEB_P_GENERIC(level, idstring, format, args...) \
> +#define EDEB_P_GENERIC(level,idstring,format,args...) \
> +#define EDEB(level, format, args...) \
> +#define EDEB_ERR(level, format, args...) \
> +#define EDEB_EN(level, format, args...) \
> +#define EDEB_EX(level, format, args...) \
> +#define EDEB_DMP(level, adr, len, format, args...) \
There are a lot of debug statements in the driver. When doing a review
I stripped them all out to make it easier to read. As suggested by
others, using the standard debug macros (where still required) would be
a good idea.
Anton
^ permalink raw reply
* Re: [PATCH 3/6] ehea: queue management
From: Anton Blanchard @ 2006-08-11 21:52 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F38.8010306@de.ibm.com>
Hi,
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_ethtool.c 1969-12-31
> +static void netdev_get_pauseparam(struct net_device *dev,
> + struct ethtool_pauseparam *pauseparam)
> +{
> + printk("get pauseparam\n");
> +}
There are a number of stubbed out ethtool functions like this. Best not
to implement them and allow the upper layers to return a correct error.
Anton
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Anton Blanchard @ 2006-08-11 22:07 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F56.7010201@de.ibm.com>
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31
> +extern void exit(int);
Should be able to remove that prototype :)
Anton
^ permalink raw reply
* Re: Realtime preemption patch on PPC
From: Roger Larsson @ 2006-08-11 22:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200608110938.45385.bcook@bpointsys.com>
On Friday 11 August 2006 16:38, Brent Cook wrote:
> On Thursday 10 August 2006 18:04, Ben Weintraub wrote:
> > Howdy,
> >
> > I'm wondering if anyone has had success getting Ingo Molnar's realtime
> > preemption patch (the one here:
> > http://people.redhat.com/mingo/realtime-preempt/ ) working on the ppc
> > arch.
>
> I have gotten them to work with MPC7448 boards, but it has hardware
> floating point, so no math-emu problems.
>
> > Anyhow, when I boot on an MPC8555 with my hack, I get an endless stream
> > of:
> >
> > BUG: sleeping function called from invalid context init(1) at
> > arch/powerpc/math-emu/math.c:226
> > in_atomic():0 [00000000], irqs_disabled():1
> > Call Trace:
> > [A0BB3E90] [A000934C] show_stack+0x48/0x194 (unreliable)
> > [A0BB3EC0] [A001B7DC] __might_sleep+0xe8/0xf4
> > [A0BB3EE0] [A00136C0] do_mathemu+0x30/0x8c8
> > [A0BB3F00] [A00036AC] program_check_exception+0x1ac/0x514
> > [A0BB3F40] [A0002A08] ret_from_except_full+0x0/0x4c
> >
> > Line 226 in arch/powerpc/math-emu/math.c is part of the do_mathemu()
> > function, and contains a call to get_user(), which calls
> > __might_sleep(), causing this problem.
It is not the might sleep that is the problem. Nor the get_user.
It is that the irqs are DISABLED.
If the thread goes to sleep it might never wake up! (With interrupts disabled
what HW can not notify SW that it is live...)
1) Floating point in kernel is difficult to handle due to lazy register saving
2) When using a processor without hardware floating point, compile with
library (to avoid taking exceptions due to unimplemented instructions with
emulation)
My guess is that you have a driver that disables interrupts, does floating
point calculations expecting that it has floating point support, takes an
exception, exception code does not expect to get an exception from kernel
space and absolutely not when having interrupts disabled...
Recompile with soft float, or even better use fixed point calculations!
/RogerL
^ 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