Sorry, I should have included this in the original message.
Gnu C 3.3.1
Gnu make 3.80
util-linux 2.11z
mount 2.11x
e2fsprogs 1.32
pcmcia-cs 3.2.3
PPP 2.4.1
nfs-utils 1.0.5
Linux C Library 2.3.1
Dynamic linker (ldd) 2.3.1
Procps 3.1.6
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0
GNU ld version 2.14 20030612
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=y
CONFIG_IDE_TASK_IOCTL=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_SL82C105=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_IDE_PMAC=y
CONFIG_BLK_DEV_IDEDMA_PMAC=y
CONFIG_BLK_DEV_IDEDMA_PMAC_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_IVB=y
CONFIG_IDEDMA_AUTO=y
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sun, 2003-08-10 at 17:51, Miles Lane wrote:
CC drivers/ide/ppc/pmac.o
drivers/ide/ppc/pmac.c: In function `pmac_ide_build_sglist':
drivers/ide/ppc/pmac.c:1198: warning: passing arg 1 of `blk_rq_map_sg' from
incompatible pointer type
drivers/ide/ppc/pmac.c: In function `pmac_ide_dma_test_irq':
drivers/ide/ppc/pmac.c:1673: warning: comparison is always false due to
limited range of data type
drivers/ide/ppc/pmac.c: In function `idepmac_wake_device':
drivers/ide/ppc/pmac.c:1843: error: request for member `queue_head' in
something not a structure or union
drivers/ide/ppc/pmac.c: In function `idepmac_wake_drive':
drivers/ide/ppc/pmac.c:1927: error: request for member `queue_head' in
something not a structure or union
I sent an updated version of this driver to linus today
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sun August 10 2003 1:38 pm, Benjamin Herrenschmidt wrote:
On Sun, 2003-08-10 at 17:51, Miles Lane wrote:
quoted
CC drivers/ide/ppc/pmac.o
drivers/ide/ppc/pmac.c: In function `idepmac_wake_device':
drivers/ide/ppc/pmac.c:1843: error: request for member `queue_head' in
something not a structure or union
drivers/ide/ppc/pmac.c: In function `idepmac_wake_drive':
drivers/ide/ppc/pmac.c:1927: error: request for member `queue_head' in
something not a structure or union
I sent an updated version of this driver to linus today
When you send patches to Linus to fix problems that show up in
the linuxppc-2.5 tree, you don't also apply the patch directly to
the linuxppc-2.5 tree? If you and Paul use BK, couldn't you have
Paul pull the changeset? Is our current process the most efficient
we could use?
I am curious, why do you and Paul not use a system more like Russell's
(changes move into Linus' tree as soon as they are fairly well tested
and he maintains the ARM patches in
http://www.kernel.org/pub/linux/kernel/people/rmk/arm/v2.5/)?
Thanks,
Miles
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Sun, 2003-08-10 at 22:51, Miles Lane wrote:
On Sun August 10 2003 1:38 pm, Benjamin Herrenschmidt wrote:
quoted
On Sun, 2003-08-10 at 17:51, Miles Lane wrote:
quoted
CC drivers/ide/ppc/pmac.o
drivers/ide/ppc/pmac.c: In function `idepmac_wake_device':
drivers/ide/ppc/pmac.c:1843: error: request for member `queue_head' in
something not a structure or union
drivers/ide/ppc/pmac.c: In function `idepmac_wake_drive':
drivers/ide/ppc/pmac.c:1927: error: request for member `queue_head' in
something not a structure or union
I sent an updated version of this driver to linus today
When you send patches to Linus to fix problems that show up in
the linuxppc-2.5 tree, you don't also apply the patch directly to
the linuxppc-2.5 tree? If you and Paul use BK, couldn't you have
Paul pull the changeset? Is our current process the most efficient
we could use?
Right now, I'm sending massive PowerMac driver updates directly
to Linus. Typically, all of this is available from my linuxppc-2.5-benh
tree, though I don't really recommend for non-hackers to use that.
I am curious, why do you and Paul not use a system more like Russell's
(changes move into Linus' tree as soon as they are fairly well tested
and he maintains the ARM patches in
I'm trying to completely avoid having a "ppc" or "powermac" tree with
2.6, at least once all the "pending" bits from mine have been in Linus.
I want to keep as close as Linus tree as I can, not reproduce what I did
for 2.4 where I had megabytes of diffs piling up.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/