Re: [PATCH 1/2] qemu platform, v2
Rob Landley writes: Just to correct a few misconceptions: > 2) PowerPC uses a device tree supplied by the hardware to identify the > available hardware, even for stuff living on PCI busses which it could > theoretically probe for but doesn't. The device tree doesn't have to include anything that can be probed for. On some platforms (e.g. pSeries) we choose to use the device tree rather than probing, but on most other platforms we probe. > I'd be following this more closely if compiling a device tree didn't > currently > require an external utility (dtc or some such) that doesn't come with the > Linux kernel. No other target platform I've built kernels for requires such > an environmental dependency. No? You haven't built kernels for other platforms that have external dependencies such as perl, gcc, make, binutils, etc.? :) > (This is a problem both for hardwiring the > device tree into the kernel and for building a new boot rom from the linux > kernel's ppc boot wrapper that would contain such a device tree to feed to > the kernel.) It's only really been a problem for ps3 so far, since the embedded guys don't seem to have any difficulty with installing dtc. We are looking at what to do for ps3 and prep, and the answer may well involve bundling dtc in the kernel source (it's not too big, around 3400 lines). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] usb: ehci ppc device-tree-aware driver
On Mon, 17 Sep 2007 16:50:39 +0400, Valentine Barshak wrote: > Some PowerPC systems have a built-in EHCI controller. > This is a device tree aware version of the EHCI controller driver. > Currently it's been tested on the PowerPC 440EPx Sequoia board. > Other platforms can be added later. > The code is based on the ehci-ppc-soc driver by Stefan Roese <[EMAIL > PROTECTED]>. We're having a strange issue on our Sequoia where the network stops functioning when USB is active. Jerone can supply more detail... Have you seen anything like that? -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Saturday 22 September 2007 4:55:46 am Christoph Hellwig wrote:
> On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
> > Here is the second rev of patches to boot a arch powerpc kernel on
> > qemu with the prep architecture.
>
> So if this is supposed to be prep why do you need additional kernel
> support? And if you really needed why isn't it under platforms/prep?
The device tree provided by qemu's open hackware violates some of the
assumptions the Linux kernel is making? (Although things like "the cpu cache
size is zero" are, technically speaking, probably correct. :)
There are three different problems here:
1) porting prep from arch=ppc to arch=powerpc so you can build it on an arch
that also supports make headers_install.
2) PowerPC uses a device tree supplied by the hardware to identify the
available hardware, even for stuff living on PCI busses which it could
theoretically probe for but doesn't.
3) The PPC firmware qemu comes with ("Open Hackware") sucks rocks, is hard to
modify, isn't quite being maintained. As mentioned above, the device tree it
passes in (including "prep residual data" from which more nodes in the device
tree can be constructed, and here my understanding goes all fuzzy) does not
make for a happy Linux kernel.
Proposed solutions to all this involve various combinations of creating a
target platform aimed directly at qemu and not pretending to be prep at all
(so it doesn't have to parse residual data), creating our own boot rom image
out of some of the wrapper code the linux kernel's already got and feeding
that to qemu instead of using open hackware at all, hard wiring a device tree
into the kernel and not looking at the one open hackware passes in...)
I'd be following this more closely if compiling a device tree didn't currently
require an external utility (dtc or some such) that doesn't come with the
Linux kernel. No other target platform I've built kernels for requires such
an environmental dependency. (This is a problem both for hardwiring the
device tree into the kernel and for building a new boot rom from the linux
kernel's ppc boot wrapper that would contain such a device tree to feed to
the kernel.)
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] pcmcia: Convert io_req_t to use kio_addr_t
On Sat, Sep 22, 2007 at 12:25:51AM -0600, Matthew Wilcox wrote:
> On Fri, Sep 21, 2007 at 11:39:36PM +0100, Alan Cox wrote:
> > On Fri, 21 Sep 2007 17:15:16 -0500
> > Olof Johansson <[EMAIL PROTECTED]> wrote:
> >
> > > Convert the io_req_t members to kio_addr_t, to allow use on machines with
> > > more than 16 bits worth of IO ports (i.e. secondary busses on ppc64, etc).
> >
> > What about the formatting and field widths ?
> >
> > ulong would probably be a lot saner than kio_addr_t and yet more type
> > obfuscation.
>
> I don't think anyone uses ioports > 32bit. Certainly i386 takes an int
> port as parameter to {in,out}[bwl] (and it really only uses 16-bits).
> parisc uses 24 bits. I don't know what the various ppcs do, but pci
> bars can only be 32-bit for ioports. So my opinion is that ioports
> should be uint, not ulong.
PPC would do just fine with 32-bit as well, which is what I wanted in
the first place. I just went with the local coding standard of pcmcia
and switched to kio_addr_t.
I suppose it's a janitorial todo item but with the maintainer MIA I
don't want to mess around with it too much, since I can't really test
much besides the PPC stuff I have.
As for the formatting/padding widths: Some platforms had ioaddr_t's
that were 32 bit already, so it was already broken on those, and the
only drawback is missing 0-padding. It'd look a bit silly to pad to 16
0:s anyway at the moment, so I think I'd prefer to keep it the way it is.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 04/28] Add cmpxchg64 and cmpxchg64_local to powerpc
* Paul Mackerras ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers writes: > > > Make sure that at least cmpxchg64_local is available on all architectures > > to use > > for unsigned long long values. > > > > Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> > > Acked-by: Paul Mackerras <[EMAIL PROTECTED]> Thanks Paul, Just make sure add-cmpxchg-local-to-generic-for-up.patch gets merged before this one, since it needs asm-generic/cmpxchg-local.h. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote: > Here is the second rev of patches to boot a arch powerpc kernel on > qemu with the prep architecture. So if this is supposed to be prep why do you need additional kernel support? And if you really needed why isn't it under platforms/prep? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] pcmcia: Convert io_req_t to use kio_addr_t
On Sat, Sep 22, 2007 at 12:25:51AM -0600, Matthew Wilcox wrote:
> > What about the formatting and field widths ?
> >
> > ulong would probably be a lot saner than kio_addr_t and yet more type
> > obfuscation.
>
> I don't think anyone uses ioports > 32bit. Certainly i386 takes an int
> port as parameter to {in,out}[bwl] (and it really only uses 16-bits).
> parisc uses 24 bits. I don't know what the various ppcs do, but pci
> bars can only be 32-bit for ioports. So my opinion is that ioports
> should be uint, not ulong.
The kernel seems to mostly use int, sometimes uint. I never quite got
why pcmcia had to have it's own strange typedef for them.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_ethtool.c)
[PATCH -mm] spider_net_ethtool: Keep up with recent netdev stats changes
Unbreak the following:
drivers/net/spider_net_ethtool.c: In function 'spider_net_get_ethtool_stats':
drivers/net/spider_net_ethtool.c:160: error: structure has no member named
'netdev_stats'
drivers/net/spider_net_ethtool.c:161: error: structure has no member named
'netdev_stats'
drivers/net/spider_net_ethtool.c:162: error: structure has no member named
'netdev_stats'
drivers/net/spider_net_ethtool.c:163: error: structure has no member named
'netdev_stats'
drivers/net/spider_net_ethtool.c:164: error: structure has no member named
'netdev_stats'
drivers/net/spider_net_ethtool.c:165: error: structure has no member named
'netdev_stats'
drivers/net/spider_net_ethtool.c:166: error: structure has no member named
'netdev_stats'
make[2]: *** [drivers/net/spider_net_ethtool.o] Error 1
Also do another ARRAY_SIZE() cleanup while at it.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/net/spider_net_ethtool.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff -ruNp a/drivers/net/spider_net_ethtool.c b/drivers/net/spider_net_ethtool.c
--- a/drivers/net/spider_net_ethtool.c 2007-09-22 06:26:39.0 +0530
+++ b/drivers/net/spider_net_ethtool.c 2007-09-22 12:43:51.0 +0530
@@ -28,8 +28,6 @@
#include "spider_net.h"
-#define SPIDER_NET_NUM_STATS 13
-
static struct {
const char str[ETH_GSTRING_LEN];
} ethtool_stats_keys[] = {
@@ -149,7 +147,7 @@ spider_net_ethtool_get_ringparam(struct
static int spider_net_get_stats_count(struct net_device *netdev)
{
- return SPIDER_NET_NUM_STATS;
+ return ARRAY_SIZE(ethtool_stats_keys);
}
static void spider_net_get_ethtool_stats(struct net_device *netdev,
@@ -157,13 +155,13 @@ static void spider_net_get_ethtool_stats
{
struct spider_net_card *card = netdev->priv;
- data[0] = card->netdev_stats.tx_packets;
- data[1] = card->netdev_stats.tx_bytes;
- data[2] = card->netdev_stats.rx_packets;
- data[3] = card->netdev_stats.rx_bytes;
- data[4] = card->netdev_stats.tx_errors;
- data[5] = card->netdev_stats.tx_dropped;
- data[6] = card->netdev_stats.rx_dropped;
+ data[0] = netdev->stats.tx_packets;
+ data[1] = netdev->stats.tx_bytes;
+ data[2] = netdev->stats.rx_packets;
+ data[3] = netdev->stats.rx_bytes;
+ data[4] = netdev->stats.tx_errors;
+ data[5] = netdev->stats.tx_dropped;
+ data[6] = netdev->stats.rx_dropped;
data[7] = card->spider_stats.rx_desc_error;
data[8] = card->spider_stats.tx_timeouts;
data[9] = card->spider_stats.alloc_rx_skb_error;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
