* Re: problem in creation of .ko file while compiling the kernel
From: Misbah khan @ 2007-12-05 6:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20071205060957.GA17391@lixom.net>
I need to know what could be the reason that .ko files are not been generated
while selecting as Module in menuconfig
----misbah
Olof Johansson-2 wrote:
>
> On Tue, Dec 04, 2007 at 08:46:21PM -0800, Misbah khan wrote:
>
>> I need to select USB support in the kernel for PPC8272 board. Source code
>> is
>> already present and montavista provides the support for it .
>
> Sounds like a question you should ask montavista support then?
>
>
> -Olof
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/problem-in-creation-of-.ko-file-while-compiling-the-kernel-tf4947452.html#a14165890
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: zImage.initrd.ebony image /ramdisk Image
From: Olof Johansson @ 2007-12-05 6:13 UTC (permalink / raw)
To: vinay kumar; +Cc: linuxppc-embedded
In-Reply-To: <e8e184520712032315s345679abu150461ead188f33e@mail.gmail.com>
On Tue, Dec 04, 2007 at 12:45:47PM +0530, vinay kumar wrote:
> I am trying to boot linux on ebony.
> Can any one please help me in either sharing a ready made image of
> kernel and ramdisk or united image.
>
> How do we build a fresh image ourselves.?
There's a few different projects out there for building simple ramdisk images.
I think ELDK might have it (not sure): http://denx.de/
buildroot: http://buildroot.uclibc.org/
OpenEmbedded: http://openembedded.org/
LTIB: http://savannah.nongnu.org/projects/ltib/
-Olof
^ permalink raw reply
* Re: problem in creation of .ko file while compiling the kernel
From: Olof Johansson @ 2007-12-05 6:09 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <14165265.post@talk.nabble.com>
On Tue, Dec 04, 2007 at 08:46:21PM -0800, Misbah khan wrote:
> I need to select USB support in the kernel for PPC8272 board. Source code is
> already present and montavista provides the support for it .
Sounds like a question you should ask montavista support then?
-Olof
^ permalink raw reply
* problem in creation of .ko file while compiling the kernel
From: Misbah khan @ 2007-12-05 4:46 UTC (permalink / raw)
To: linuxppc-embedded
Hi ...
I am using Montavista kernel which has USB driver support. In make
menuconfig i am making the driver to selected as module but after compiling
and installing on the board i could not be able to find the .ko file .
Even if i am selecting the USB driver (not as module)i could not find the
driver presence.
what could be the probable reason and the solution to it ???
I need to select USB support in the kernel for PPC8272 board. Source code is
already present and montavista provides the support for it .
-----Misbah <><
--
View this message in context: http://www.nabble.com/problem-in-creation-of-.ko-file-while-compiling-the-kernel-tf4947452.html#a14165265
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
From: Benjamin Herrenschmidt @ 2007-12-05 4:34 UTC (permalink / raw)
To: David Gibson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071205042126.GE12855@localhost.localdomain>
On Wed, 2007-12-05 at 15:21 +1100, David Gibson wrote:
> On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> > > It occurred to me the other day. Instead of using a new "unused"
> > > property for this, should we be using the OF standard "status"
> > > property.
> >
> > Dunno... it's really not wired. Probably not even clocked.
>
> status = "fail-notconnected"; ?
Bah, that's fugly.. jeff, don't hold the patches, we may sort that out
later.
Ben.
^ permalink raw reply
* Re: Merge dtc
From: Olof Johansson @ 2007-12-05 4:37 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras, David Woodhouse, David Gibson
In-Reply-To: <20071204220012.1b91c27c@zod.rchland.ibm.com>
On Tue, Dec 04, 2007 at 10:00:12PM -0600, Josh Boyer wrote:
> So if mkimage is going to be put in-kernel, I'd rather it be in a more
> generic place. Arguably, dtc should go there as well seeing as how
> microblaze could probably use it too.
Well, kconfig is in scripts/ in spite of not being a script. Maybe
dtc and mkimage should go there too?
-Olof
^ permalink raw reply
* Re: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
From: David Gibson @ 2007-12-05 4:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <1196828329.13230.356.camel@pasglop>
On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> > It occurred to me the other day. Instead of using a new "unused"
> > property for this, should we be using the OF standard "status"
> > property.
>
> Dunno... it's really not wired. Probably not even clocked.
status = "fail-notconnected"; ?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
From: Benjamin Herrenschmidt @ 2007-12-05 4:18 UTC (permalink / raw)
To: David Gibson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071205035345.GA12855@localhost.localdomain>
On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> It occurred to me the other day. Instead of using a new "unused"
> property for this, should we be using the OF standard "status"
> property.
Dunno... it's really not wired. Probably not even clocked.
Ben.
^ permalink raw reply
* Re: Merge dtc
From: Josh Boyer @ 2007-12-05 4:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Woodhouse, David Gibson
In-Reply-To: <20071204202625.05367103@zod.rchland.ibm.com>
On Tue, 4 Dec 2007 20:26:25 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Wed, 5 Dec 2007 13:22:46 +1100
> Paul Mackerras <paulus@samba.org> wrote:
>
> > Josh Boyer writes:
> >
> > > Using that same reasoning, should we merge a mkimage patch for the
> > > boards that use U-Boot?
> >
> > I think so. It's fairly small and it would mean that people could
> > cross-compile all the defconfigs easily.
>
> I'll try to work up a patch tonight.
OK so it won't be tonight.
The problem we have with mkimage, unlike DTC at the moment, is that it
_is_ used on other architectures. There's already a mkuboot.sh script,
which calls mkimage, in scripts/ right now. Adding mkimage to
arch/powerpc only seems pretty wrong.
So if mkimage is going to be put in-kernel, I'd rather it be in a more
generic place. Arguably, dtc should go there as well seeing as how
microblaze could probably use it too.
josh
^ permalink raw reply
* Re: [PATCH 7/11] ibm_newemac: Skip EMACs that are marked unused by the firmware
From: David Gibson @ 2007-12-05 3:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071205001539.97730DE091@ozlabs.org>
On Wed, Dec 05, 2007 at 11:14:30AM +1100, Benjamin Herrenschmidt wrote:
> From: Hugh Blemings <hugh@blemings.org>
>
> Depending on how the 44x processors are wired, some EMAC cells
> might not be useable (and not connected to a PHY). However, some
> device-trees may choose to still expose them (since their registers
> are present in the MMIO space) but with an "unused" property in
> them.
It occurred to me the other day. Instead of using a new "unused"
property for this, should we be using the OF standard "status"
property.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
From: Olof Johansson @ 2007-12-05 3:26 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-ide, Jeff Garzik, Arnd Bergmann, linuxppc-dev
In-Reply-To: <20071205004841.GA25905@linux-sh.org>
On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote:
> On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > > tristate "Generic platform device PATA support"
> > > - depends on EMBEDDED || ARCH_RPC
> > > + depends on EMBEDDED || ARCH_PPC
> >
> > It needs to be || PPC, not || ARCH_PPC.
> >
> Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC.
>
> ARCH_RPC is not a typo, it's an ARM platform. Please grep first :-)
I'm sorry, but seeing ARCH_RPC and not having an arch/rpc made me
suspect it being a typo. It surprises me that the ARM guys chose such
a generic prefix as ARCH_ for their specific platforms. (powerpc uses
PPC_<platform>).
Anyway, thanks for catching it.
-Olof
^ permalink raw reply
* Re: [PATCH] pci: Fix bus resource assignment on 32 bits with 64b resources
From: Benjamin Herrenschmidt @ 2007-12-05 2:37 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, linux-pci, linux-kernel
In-Reply-To: <20071204060911.EA82BDDE19@ozlabs.org>
On Tue, 2007-12-04 at 17:08 +1100, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes it, along with some tricks to avoid casting to 64 bits on
> platforms that don't need it in every printk around.
>
> This is a pre-requisite for making powerpc use the generic code instead of
> its own half-useful implementation.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Drop it for now, stupid warnings without 64 bits resources... I'll fix
that.
Ben.
^ permalink raw reply
* Re: Merge dtc
From: Josh Boyer @ 2007-12-05 2:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Gibson, David Woodhouse, David
In-Reply-To: <18262.2934.447856.686438@cargo.ozlabs.ibm.com>
On Wed, 5 Dec 2007 13:22:46 +1100
Paul Mackerras <paulus@samba.org> wrote:
> Josh Boyer writes:
>
> > Using that same reasoning, should we merge a mkimage patch for the
> > boards that use U-Boot?
>
> I think so. It's fairly small and it would mean that people could
> cross-compile all the defconfigs easily.
I'll try to work up a patch tonight.
josh
^ permalink raw reply
* Re: Merge dtc
From: Paul Mackerras @ 2007-12-05 2:22 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Gibson, David Woodhouse, David
In-Reply-To: <20071204163409.6d03c7a5@zod.rchland.ibm.com>
Josh Boyer writes:
> Using that same reasoning, should we merge a mkimage patch for the
> boards that use U-Boot?
I think so. It's fairly small and it would mean that people could
cross-compile all the defconfigs easily.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] pasemi: Register i2c_board_info
From: Olof Johansson @ 2007-12-05 2:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Woodhouse
In-Reply-To: <18261.62414.418162.450330@cargo.ozlabs.ibm.com>
On Wed, Dec 05, 2007 at 11:41:50AM +1100, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Yep, I realized that after (re)asking Paul to pull though, and didn't
> > want to do a third request before he's done it. :)
> >
> > If he doesn't pull in the next few days I might just keep adding new
> > patches as they come in though, and add it back.
>
> I haven't pulled yet; sounds like I need to wait a few more days
> first. :)
Heh, nah, just pull now, I'll have more going in before 2.6.25 as but it's
good to get current contents into -mm sooner rather than later. :)
Thanks,
-Olof
^ permalink raw reply
* Re: Merge dtc
From: Josh Boyer @ 2007-12-05 1:49 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1196816078.13978.411.camel@pmac.infradead.org>
On Wed, 05 Dec 2007 00:54:38 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Tue, 2007-12-04 at 22:33 +0000, David Woodhouse wrote:
> > Make vmlinux the default target instead of zImage would seem like a
> > better answer. I'm surprised that it isn't like that already, in fact --
> > and I'm only inferring that it isn't from your message. I always thought
> > that if I typed 'make' I got the vmlinux and not a zImage.
>
> Ooh, no -- I don't. I get an error, and I never even noticed...
>
> WRAP arch/powerpc/boot/zImage.chrp
> WRAP arch/powerpc/boot/zImage.pmac
> WRAP arch/powerpc/boot/cuImage.52xx
> /pmac/git/libertas-2.6/arch/powerpc/boot/wrapper: line 257: mkimage: command not found
> make[1]: *** [arch/powerpc/boot/cuImage.52xx] Error 127
>
>
> I'd be perfectly happy with 'make vmlinux then' as a response to anyone
> who complains. And in fact since it'll correctly make the vmlinux and
> _then_ fail to create the zImage, I would have thought that anyone with
> even a modicum of common sense will _notice_ that, and start using
> 'make vmlinux' all by themselves without prompting.
People build what the default is. You don't boot a vmlinux, you boot a
zImage (in most cases).
(Nevermind the fact that for the 'build patch on all arches' part Paul
mentioned earlier it doesn't really matter since they probably aren't
going to actually boot it anyway.)
josh
^ permalink raw reply
* Re: Fix Firmware class name collision
From: Timur Tabi @ 2007-12-05 1:28 UTC (permalink / raw)
To: Scott Wood; +Cc: PowerPC dev list, Greg Kroah-Hartman, Markus Rechberger
In-Reply-To: <4755E835.6070704@freescale.com>
Scott Wood wrote:
> The physical address certainly is useful when you have more than one
> device of the same name.
What I meant was that the physical address isn't helpful by itself.
> So then you'd get "firmware-ucc.e01024". What if there's another ucc at
> e0102480? For devices with longer names, you'd have even less
> precision in the address.
Maybe we need to consider a more sophisticated algorithm, one that guarantees
that the device name in its entirety is preserved? Either that, or replace
the physical address with something shorter, like the offset to the root node
only? That way, ucc.e0102400 because just ucc.2400.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layer functionality
From: Vitaly Bordug @ 2007-12-05 1:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-kernel, netdev
In-Reply-To: <4755B395.6070104@garzik.org>
On Tue, 04 Dec 2007 15:07:49 -0500
Jeff Garzik wrote:
> Vitaly Bordug wrote:
> > With that patch fixed.c now fully emulates MDIO bus, thus no need
> > to duplicate PHY layer functionality. That, in turn, drastically
> > simplifies the code, and drops down line count.
> >
> > As an additional bonus, now there is no need to register MDIO bus
> > for each PHY, all emulated PHYs placed on the platform fixed MDIO
> > bus. There is also no more need to pre-allocate PHYs via .config
> > option, this is all now handled dynamically.
> >
> > p.s. Don't even try to understand patch content! Better: apply patch
> > and look into resulting drivers/net/phy/fixed.c.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>
> ACK, I presume this will go via the ppc tree?
>
Yes, I'll add your ack in next respin and will ask Paul to consider it,
if you don't mind.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Make QSpan PCI work
From: Vitaly Bordug @ 2007-12-05 1:11 UTC (permalink / raw)
To: John Tyner; +Cc: linuxppc-dev
In-Reply-To: <20071203210500.GB22557@cs.ucr.edu>
On Mon, 3 Dec 2007 13:05:00 -0800
John Tyner wrote:
> The following patch makes the QSpan PCI code compile and work on my
> hardware. The patch is against 2.4, but I'm hoping it will still be
> viewed as useful since the code currently does not even compile (2.6
> is the same). I had to make a change to move the PCI setup later in
> the m8xx_setup code as well because the kernel would crash during the
> pcibios_alloc_controller because the bootmem stuff had not come up
> yet.
>
This looks interesting, but again would make a lot of sense for powerpc and 2.6.
Is that possible to have your patches rebased against 2.6, arch/ppc at least?
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Merge dtc
From: Paul Mackerras @ 2007-12-05 1:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1196807633.13978.383.camel@pmac.infradead.org>
David Woodhouse writes:
> Make vmlinux the default target instead of zImage would seem like a
> better answer. I'm surprised that it isn't like that already, in fact --
> and I'm only inferring that it isn't from your message. I always thought
> that if I typed 'make' I got the vmlinux and not a zImage.
You're obviously an old-timer. :) Plain "make" has made the zImage
since at least 2002 in 32-bit and since January 2004 in 64-bit.
The alternative to including dtc is to include compiled versions of
all the .dts files. The difficulty with that is that .dtb files are
binary blobs which can't be updated with a patch. The shipped
versions could possibly be shipped as .S versions, or I (and everyone
else who has a tree that I pull from) could have something in my/their
patch-applying scripts that updates the .dtbs if necessary, but in
both cases things could get out of sync for one reason or another
without it being obvious.
In contrast, if the version of dtc in the kernel tree gets out of
date, it will become obvious pretty quickly because compiles will
start failing. And anyway, the kernel dtc only needs to be recent
enough to compile the .dts files in the kernel tree.
Paul.
^ permalink raw reply
* Re: [PATCH] Fix 8xx compile errors
From: Vitaly Bordug @ 2007-12-05 1:09 UTC (permalink / raw)
To: John Tyner; +Cc: linuxppc-dev
In-Reply-To: <20071203205837.GA22557@cs.ucr.edu>
On Mon, 3 Dec 2007 12:58:38 -0800
John Tyner wrote:
> Building for 8xx fails to compile due to errors in a couple of
> places. The first is due to the casting of an lvalue (if I remember
> correctly), and the second was due to the cpmp variable being
> declared static even though the headers previously defined it as
> extern. The following patch corrects these errors. The patch is
> against 2.4 since that's what I'm working with. (I've been unable to
> get 2.6 to run properly on my hardware so far.)
>
> Please CC me on any responses since I'm not subscribed.
>
You don't need these quirks with 2.6 and arch/powerpc... It does not use 8xx_io
and arch/powerpc/boot/* having a bit different meaning.
What is your platform btw? Adding something to 8xx camp should not be huge effort with powerpc...
--
Sincerely, Vitaly
^ permalink raw reply
* Re: ucc_uart: add support for Freescale QUICCEngine UART
From: Vitaly Bordug @ 2007-12-05 0:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <200712050056.40543.arnd@arndb.de>
On Wed, 5 Dec 2007 00:56:39 +0100
Arnd Bergmann wrote:
> On Wednesday 05 December 2007, Timur Tabi wrote:
> > Arnd Bergmann wrote:
> >=20
> > > You can argue that the QS is really a DMA device, but in that
> > > case you should convert the driver to use the DMA mapping
> > > interfaces correctly, which I would consider overkill.
> >=20
> > I'm confused. =C2=A0I'm already calling dma_alloc_coherent() and getting
> > a dma_addr_t back. =C2=A0Why do I need to use mapping functions to
> > convert between virtual and physical/bus addresses?
>=20
> No, I'm sorry but I'm the one who was confused. The problem I saw was
> that you return something offset from "bd_phys" as a dma_addr_t. This
> would be a lot easier if you had called it bd_bus or bd_dma instead
> of bd_phys, but your code looks absolutely correct upon closer
> inspection.
>=20
Adding my 2 cents, we already have very similar thing in cpm_uart driver...
> Arnd <><
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--=20
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH v2 4/4] [libata] pata_platform: s/ioport_shift/reg_shift/g
From: Paul Mundt @ 2007-12-05 0:56 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Jeff Garzik, Arnd Bergmann, linux-ide, linuxppc-dev,
Olof Johansson
In-Reply-To: <20071204170745.GD15599@localhost.localdomain>
On Tue, Dec 04, 2007 at 08:07:45PM +0300, Anton Vorontsov wrote:
> This patch renames ioport_shift member of pata_platform_info
> structure to reg_shift. Users of pata_platform are followed
> appropriately.
>
> Rationale of that change is: shifting applies to the whole memory
> mapped region, not only to the command block of the ATA registers,
> despite the fact that shifting is meaningless for ctl register.
>
It's called ioport_shift because of the fact it shifts an ioport, namely
a struct ata_ioport *. We could rename it, but I really don't see the
point. If you don't like the choice of name on your platform, add a
comment to your platform-specific code noting this particular outrage so
it can be grepped for by future generations ;-)
Nacked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* Re: Merge dtc
From: David Woodhouse @ 2007-12-05 0:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1196807633.13978.383.camel@pmac.infradead.org>
On Tue, 2007-12-04 at 22:33 +0000, David Woodhouse wrote:
> Make vmlinux the default target instead of zImage would seem like a
> better answer. I'm surprised that it isn't like that already, in fact --
> and I'm only inferring that it isn't from your message. I always thought
> that if I typed 'make' I got the vmlinux and not a zImage.
Ooh, no -- I don't. I get an error, and I never even noticed...
WRAP arch/powerpc/boot/zImage.chrp
WRAP arch/powerpc/boot/zImage.pmac
WRAP arch/powerpc/boot/cuImage.52xx
/pmac/git/libertas-2.6/arch/powerpc/boot/wrapper: line 257: mkimage: command not found
make[1]: *** [arch/powerpc/boot/cuImage.52xx] Error 127
I'd be perfectly happy with 'make vmlinux then' as a response to anyone
who complains. And in fact since it'll correctly make the vmlinux and
_then_ fail to create the zImage, I would have thought that anyone with
even a modicum of common sense will _notice_ that, and start using
'make vmlinux' all by themselves without prompting.
--
dwmw2
^ permalink raw reply
* [RFC/PATCH 6/6] powerpc: pci32: 4xx embedded platforms want to reassign all PCI resources
From: Benjamin Herrenschmidt @ 2007-12-05 0:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1196815980.72143.899704305870.qpush@grosgo>
This makes 4xx embedded platforms re-assign all PCI resources as we
pretty much never care about what the various firmwares have done on
these, it's generally not compatible with the way the kernel will map
the bridges.
We still need to also enable bus renumbering on some of them, but I
will do that from a separate patch after I've fixed 4xx PCIe to handle
all bus numbers.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/40x/ep405.c | 2 ++
arch/powerpc/platforms/40x/kilauea.c | 3 +++
arch/powerpc/platforms/40x/walnut.c | 3 +++
arch/powerpc/platforms/44x/bamboo.c | 4 ++++
arch/powerpc/platforms/44x/ebony.c | 3 +++
arch/powerpc/platforms/44x/katmai.c | 3 +++
arch/powerpc/platforms/44x/sequoia.c | 5 ++++-
arch/powerpc/platforms/44x/taishan.c | 2 ++
8 files changed, 24 insertions(+), 1 deletion(-)
Index: linux-work/arch/powerpc/platforms/44x/bamboo.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/44x/bamboo.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/44x/bamboo.c 2007-12-05 11:23:35.000000000 +1100
@@ -21,6 +21,8 @@
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
+#include <asm/pci-bridge.h>
+
#include "44x.h"
static struct of_device_id bamboo_of_bus[] = {
@@ -48,6 +50,8 @@ static int __init bamboo_probe(void)
if (!of_flat_dt_is_compatible(root, "amcc,bamboo"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/40x/ep405.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/40x/ep405.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/40x/ep405.c 2007-12-05 11:23:35.000000000 +1100
@@ -102,6 +102,8 @@ static void __init ep405_setup_arch(void
{
/* Find & init the BCSR CPLD */
ep405_init_bcsr();
+
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
}
static int __init ep405_probe(void)
Index: linux-work/arch/powerpc/platforms/40x/kilauea.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/40x/kilauea.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/40x/kilauea.c 2007-12-05 11:24:41.000000000 +1100
@@ -19,6 +19,7 @@
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
+#include <asm/pci-bridge.h>
static struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -45,6 +46,8 @@ static int __init kilauea_probe(void)
if (!of_flat_dt_is_compatible(root, "amcc,kilauea"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/40x/walnut.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/40x/walnut.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/40x/walnut.c 2007-12-05 11:24:47.000000000 +1100
@@ -24,6 +24,7 @@
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
+#include <asm/pci-bridge.h>
static struct of_device_id walnut_of_bus[] = {
{ .compatible = "ibm,plb3", },
@@ -51,6 +52,8 @@ static int __init walnut_probe(void)
if (!of_flat_dt_is_compatible(root, "ibm,walnut"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/44x/ebony.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/44x/ebony.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/44x/ebony.c 2007-12-05 11:24:13.000000000 +1100
@@ -24,6 +24,7 @@
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
+#include <asm/pci-bridge.h>
#include "44x.h"
@@ -55,6 +56,8 @@ static int __init ebony_probe(void)
if (!of_flat_dt_is_compatible(root, "ibm,ebony"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/44x/katmai.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/44x/katmai.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/44x/katmai.c 2007-12-05 11:24:00.000000000 +1100
@@ -21,6 +21,7 @@
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
+#include <asm/pci-bridge.h>
#include "44x.h"
@@ -49,6 +50,8 @@ static int __init katmai_probe(void)
if (!of_flat_dt_is_compatible(root, "amcc,katmai"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/44x/sequoia.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/44x/sequoia.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/44x/sequoia.c 2007-12-05 11:24:53.000000000 +1100
@@ -21,7 +21,8 @@
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
-#include "44x.h"
+#include <asm/pci-bridge.h>
+
static struct of_device_id sequoia_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -48,6 +49,8 @@ static int __init sequoia_probe(void)
if (!of_flat_dt_is_compatible(root, "amcc,sequoia"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
Index: linux-work/arch/powerpc/platforms/44x/taishan.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/44x/taishan.c 2007-12-05 11:22:15.000000000 +1100
+++ linux-work/arch/powerpc/platforms/44x/taishan.c 2007-12-05 11:23:35.000000000 +1100
@@ -60,6 +60,8 @@ static int __init taishan_probe(void)
if (!of_flat_dt_is_compatible(root, "ibm,taishan"))
return 0;
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
return 1;
}
^ 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