* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:38 UTC (permalink / raw)
To: Badari Pulavarty
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH,
linux-kernel, apw, linuxppc-dev, Christoph Raisch, netdev, tklein
In-Reply-To: <1203010575.12312.6.camel@dyn9047017100.beaverton.ibm.com>
On Thu, 2008-02-14 at 09:36 -0800, Badari Pulavarty wrote:
>
> I am not sure what you are trying to do with walk_memory_resource().
> The
> behavior is different on ppc64. Hotplug memory usage assumes that all
> the memory resources (all system memory, not just IOMEM) are
> represented
> in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
> contains ONLY iomem related. Paulus didn't want to export all the
> system
> memory into /proc/iomem on ppc64. So I had to workaround by providing
> arch-specific walk_memory_resource() function for ppc64.
OK, let's use that one.
-- Dave
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Badari Pulavarty @ 2008-02-14 17:36 UTC (permalink / raw)
To: Dave Hansen
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH,
linux-kernel, apw, linuxppc-dev, Christoph Raisch, netdev, tklein
In-Reply-To: <1203009163.19205.42.camel@nimitz.home.sr71.net>
On Thu, 2008-02-14 at 09:12 -0800, Dave Hansen wrote:
..
> > > > - Use currently other not exported functions in kernel/resource.c, like
> > > > walk_memory_resource (where we would still need the maximum
> > > possible number
> > > > of pages NR_MEM_SECTIONS)
> > >
> > > It isn't the act of exporting that's the problem. It's making sure that
> > > the exports won't be prone to abuse and that people are using them
> > > properly. You should assume that you can export and use
> > > walk_memory_resource().
> >
> > So this seems to come down to a basic question:
> > New hardware seems to have a tendency to get "private MMUs",
> > which need private mappings from the kernel address space into a
> > "HW defined address space with potentially unique characteristics"
> > RDMA in Openfabrics with global MR is the most prominent example heading
> > there
>
> That's not a question. ;)
>
> Please explain to me why walk_memory_resource() is insufficient for your
> needs. I've now pointed it out to you at least 3 times.
I am not sure what you are trying to do with walk_memory_resource(). The
behavior is different on ppc64. Hotplug memory usage assumes that all
the memory resources (all system memory, not just IOMEM) are represented
in /proc/iomem. Its the case with i386 and ia64. But on ppc64 is
contains ONLY iomem related. Paulus didn't want to export all the system
memory into /proc/iomem on ppc64. So I had to workaround by providing
arch-specific walk_memory_resource() function for ppc64.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-14 17:12 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, ossthema, Jan-Bernd Themann, Greg KH, apw,
linux-kernel, linuxppc-dev, Badari Pulavarty, netdev, tklein
In-Reply-To: <OF64B9886B.CE795DED-ONC12573EF.002FFA8B-C12573EF.00301683@de.ibm.com>
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > > Constraints imposed by HW / FW:
> > > - eHEA has own MMU
> > > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
> virtual
> > > addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> > > - The number of MRs is limited (not enough to have one MR per packet)
> >
> > Are there enough to have one per 16MB section?
>
> Unfortunately this won't work. This was one of our first ideas we tossed
> out,
> but the number of MRs will not be sufficient.
Can you give a ballpark of how many there are to work with? 10? 100?
1000?
> We understand that the add/remove area is not as
> settled in the kernel like for example f_ops ;-)
> Are there already base working assumptions which are very unlikely to
> change?
If you use good interfaces, and someone changes them, they'll likely
also fix your driver.
If you use bad interfaces, people may not even notice when they break.
As I showed you with those compile failures, you're using bad interfaces
that don't even compile on some .configs.
> I'm a little confused here....
> ...the existing add/remove code depends on sparse mem.
> Other pieces on the POWER6 version of the architecture do as well.
> So we could either chose to disable add/remove if sparsemem is not there,
> or disable the driver by Kconfig in this case.
Technically, you can do this. But, it's not a sign of a professionally
written driver that is going to get its patches accepted into mainline.
Technically, you can also use lots of magic numbers and not obey
CodingStyle. But, you'll probably get review comments asking you to
change it.
> > > - a way to iterate over all kernel pages and a way to detect holes in
> the
> > > kernel memory layout in order to build up our own ehea_bmap.
> >
> > Look at kernel/resource.c
> >
> > But, I'm really not convinced that you can actually keep this map
> > yourselves. It's not as simple as you think. What happens if you get
> > on an LPAR with two sections, one 256MB@0x0 and another
> > 16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
> > array will eat all of memory.
> I'm glad you mention this part. There are many algorithms out there to
> handle this problem,
> hashes/trees/... all of these trade speed for smaller memory footprint.
> We based the table decission on the existing implementations of the
> architecture.
> Do you see such a case coming along for the next generation POWER systems?
Dude. It exists *TODAY*. Go take a machine, add tens of gigabytes of
memory to it. Then, remove all of the sections of memory in the middle.
You'll be left with a very sparse memory configuration that we *DO*
handle today in the core VM. We handle it quite well, actually.
The hypervisor does not shrink memory from the top down. It pulls
things out of the middle and shuffles things around. In fact, a NUMA
node's memory isn't even contiguous.
Your code will OOM the machine in this case. I consider the ehea driver
buggy in this regard.
> I would guess these drastic changes would also require changes in base
> kernel.
No, we actually solved those a couple years ago.
> Will you provide a generic mapping system with a contiguous virtual address
> space
> like the ehea_bmap we can query? This would need to be a "stable" part of
> the implementation,
> including translation functions from kernel to nextgen_ehea_generic_bmap
> like virt_to_abs.
Yes, that's a real possibility, especially if some other users for it
come forward. We could definitely add something like that to the
generic code. But, you'll have to be convincing that what we have now
is insufficient.
Does this requirement:
"- MRs cover a contiguous virtual memory block (no holes)"
come from the hardware?
Is that *EACH* MR? OR all MRs?
Where does EHEA_BUSMAP_START come from? Is that defined in the
hardware? Have you checked to ensure that no other users might want a
chunk of memory in that area?
Can you query the existing MRs? Not change them in place, but can you
query their contents?
> > That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
> > in the core, so that we can deal with these kinds of problems, once and
> > *NOT* in every single little driver out there.
> >
> > > Functions to use while building ehea_bmap + MRs:
> > > - Use either the functions that are used by the memory hotplug system
> as
> > > well, that means using the section defines + functions
> (section_nr_to_pfn,
> > > pfn_valid)
> >
> > Basically, you can't use anything related to sections outside of the
> > core code. You can use things like pfn_valid(), or you can create new
> > interfaces that are properly abstracted.
>
> We picked sections instead of PFNs because this keeps the ehea_bmap in a
> reasonable range
> on the existing systems.
> But if you provide a abstract method handling exactly the problem we
> mention
> we'll be happy to use that and dump our private implementation.
One thing you can guarantee today is that things are contiguous up to
MAX_ORDER_NR_PAGES. That's a symbol that is unlikely to change and is
much more appropriate than using sparsemem. We could also give you a
nice new #define like MINIMUM_CONTIGUOUS_PAGES or something. I think
that's what you really want.
> > > - Use currently other not exported functions in kernel/resource.c, like
> > > walk_memory_resource (where we would still need the maximum
> > possible number
> > > of pages NR_MEM_SECTIONS)
> >
> > It isn't the act of exporting that's the problem. It's making sure that
> > the exports won't be prone to abuse and that people are using them
> > properly. You should assume that you can export and use
> > walk_memory_resource().
>
> So this seems to come down to a basic question:
> New hardware seems to have a tendency to get "private MMUs",
> which need private mappings from the kernel address space into a
> "HW defined address space with potentially unique characteristics"
> RDMA in Openfabrics with global MR is the most prominent example heading
> there
That's not a question. ;)
Please explain to me why walk_memory_resource() is insufficient for your
needs. I've now pointed it out to you at least 3 times.
> > Do you know what other operating systems do with this hardware?
>
> We're not aware of another open source Operating system trying to address
> this topic.
What about AIX? Do you know who wrote its driver? Perhaps you should
go ask them.
-- Dave
^ permalink raw reply
* [PATCH] Fix ucc_geth MII master selection
From: Joakim Tjernlund @ 2008-02-14 17:11 UTC (permalink / raw)
To: 'linuxppc-dev Development'; +Cc: Joakim Tjernlund
Remove bogus UCC regs range test and correct
off by one error in call to ucc_set_qe_mux_mii_mng()
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
I am not 100% sure this is the correct fix, please ACK or NACK
drivers/net/ucc_geth_mii.c | 26 +++++++++++---------------
1 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index 6c257b8..472d5a1 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -200,21 +200,17 @@ static int uec_mdio_probe(struct of_device *ofdev, const struct of_device_id *ma
if (err)
goto bus_register_fail;
- /* if our mdio regs fall within this UCC regs range */
- if ((res.start >= tempres.start) &&
- (res.end <= tempres.end)) {
- /* set this UCC to be the MII master */
- const u32 *id = of_get_property(tempnp, "device-id", NULL);
- if (id == NULL)
- goto bus_register_fail;
-
- ucc_set_qe_mux_mii_mng(*id - 1);
-
- /* assign the TBI an address which won't
- * conflict with the PHYs */
- out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
- break;
- }
+ /* set this UCC to be the MII master */
+ const u32 *id = of_get_property(tempnp, "device-id", NULL);
+ if (id == NULL)
+ goto bus_register_fail;
+
+ ucc_set_qe_mux_mii_mng(*id);
+
+ /* assign the TBI an address which won't
+ * conflict with the PHYs */
+ out_be32(®s->utbipar, UTBIPAR_INIT_TBIPA);
+ break;
}
err = mdiobus_register(new_bus);
--
1.5.3.8
^ permalink raw reply related
* Re: reg Philips ISP 1562 usb controller support in linux2.6.23.11
From: Clemens Koller @ 2008-02-14 16:52 UTC (permalink / raw)
To: mahendra varman; +Cc: linuxppc-embedded
In-Reply-To: <4ac2955e0802140528i69fece47xa6d751200c5616f9@mail.gmail.com>
mahendra varman schrieb:
> Hello all
>
> If iam not using the open firmware architecture
> Then can u please help me what i need to enable in menuconfig for ISP
> 1562 pci based usb controller ...
According to it's datasheet, The ISP1562 integrates normal OHCI / EHCI
compliant USB cores. My ISP1563 works fine with these CONFIGs enabled.
> Please do reply
Please don't push anybody.
Regards,
Clemens Koller
^ permalink raw reply
* BUG: ucc_geth, MDIO only works for UCC3(ucc@2200) on MPC8321
From: Joakim Tjernlund @ 2008-02-14 16:36 UTC (permalink / raw)
To: 'linuxppc-dev Development', Kim Phillips, Li Yang
Trying to use other UCC2 or UCC4 for ethernet instead of UCC3 makes MDIO
unusable. UCC2 can not find its PHY if not UCC3 is present too. Seems
like only UCC3 is able to drive the MDIO bus.
Jocke
^ permalink raw reply
* [PATCH 04/14] arch/powerpc/platforms/iseries/pci.c: Use time_* macros
From: S.Çağlar Onur @ 2008-02-14 15:36 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, S.Çağlar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values.
So following patch implements usage of the time_after() macro, defined at linux/jiffies.h, which deals with wrapping correctly
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
---
arch/powerpc/platforms/iseries/pci.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/pci.c b/arch/powerpc/platforms/iseries/pci.c
index cc562e4..02a634f 100644
--- a/arch/powerpc/platforms/iseries/pci.c
+++ b/arch/powerpc/platforms/iseries/pci.c
@@ -23,6 +23,7 @@
#undef DEBUG
+#include <linux/jiffies.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/string.h>
@@ -586,7 +587,7 @@ static inline struct device_node *xlate_iomm_address(
static unsigned long last_jiffies;
static int num_printed;
- if ((jiffies - last_jiffies) > 60 * HZ) {
+ if (time_after(jiffies, last_jiffies + 60 * HZ)) {
last_jiffies = jiffies;
num_printed = 0;
}
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] emac/zmii link warnings
From: Josh Boyer @ 2008-02-14 15:30 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <47AA9251.5020007@pikatech.com>
On Thu, 07 Feb 2008 00:08:33 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Ok, here is my best shot at removing the warnings. It seems to me that
> functions called from a dev_init section should not be dev_exit.
This seems to fix those specific warnings, but there are others lurking
in some of the other files (rgmii, tah, etc). We should probably get
those fixed up too.
josh
^ permalink raw reply
* Re: [PATCH] remove unused CONFIG_WANT_DEVICE_TREE
From: Josh Boyer @ 2008-02-14 15:25 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080214041301.30383.5581.stgit@trillian.secretlab.ca>
On Wed, 13 Feb 2008 21:14:09 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> CONFIG_DEVICE_TREE was the only user of CONFIG_WANT_DEVICE_TREE but
> it was removed in commit id 25431333813686654907ab987fb5de10c10a16db
> (bootwrapper: Build multiple cuImages).
>
> This patch removes CONFIG_WANT_DEVICE_TREE from Kconfig and the defconfigs
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested on Ebony for 4xx. Seems Paul already has it queued up.
I have some other changes coming and I'll update the defconfigs for 4xx
to remove reference to it.
josh
^ permalink raw reply
* Re: [PATCH] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
From: Kumar Gala @ 2008-02-14 14:28 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: linuxppc-dev
In-Reply-To: <47B40573.1080203@ru.mvista.com>
On Feb 14, 2008, at 3:10 AM, Pavel Kiryukhin wrote:
> Kumar Gala wrote:
>>
>> On Feb 13, 2008, at 3:19 PM, Pavel Kiryukhin wrote:
>>
>>> Add regshift reading to serial drivers.
>>> This enables correct operation of serial ports with nonzero
>>> regshift.
>>
>> what device needs this?
>>
>> - k
>
> Xilinx opb 16550 uart
please add that info to the commit message so we know why this change
was made. Other it looks ok to me.
- k
^ permalink raw reply
* Re: libfdt: Fix NOP handling bug in fdt_add_subnode_namelen()
From: Jon Loeliger @ 2008-02-14 14:05 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080214055034.GA13137@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> fdt_add_subnode_namelen() has a bug if asked to add a subnode to a
> node which has NOP tags interspersed with its properties. In this
> case fdt_add_subnode_namelen() will put the new subnode before the
> first NOP tag, even if there are properties after it, which will
> result in an invalid blob.
>
> This patch fixes the bug, and adds a testcase for it.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* reg Philips ISP 1562 usb controller support in linux2.6.23.11
From: mahendra varman @ 2008-02-14 13:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 181 bytes --]
Hello all
If iam not using the open firmware architecture
Then can u please help me what i need to enable in menuconfig for ISP 1562
pci based usb controller ...
Please do reply
[-- Attachment #2: Type: text/html, Size: 204 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] [POWERPC] Add i2c pins to dts and board setup on 01-31-08
From: Jochen Friedrich @ 2008-02-14 11:39 UTC (permalink / raw)
To: Nima Montaser; +Cc: linuxppc-dev list
In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE1418A0B3@zcarhxm2.corp.nortel.com>
Hi Nima,
> I've got a couple of comments about the above patch - I'm not quite sure
> how to add my comments to the ozlab.org site.
simply replying to the original mail will add your comments.
> 1 -
> -- a/arch/powerpc/boot/dts/mpc8272ads.dts
> [snip]
> + i2c@11860 {
> + compatible = "fsl,mpc8248-i2c",
> [NIMA] Are you sure it should be mpc8248, or do you want 8272. I know
> they are essentially the same chip, but just to avoid confusion, it
> maybe better as 8272.
Good catch, thanks! As i don't have a CPM2 chip myself, i had a tester with
a MPC8248. I just took his dts parts.
> 2-
> +++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
> @@ -96,6 +96,11 @@ static struct cpm_pin mpc8272_ads_pins[] = {
> {1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
> {2, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
> {2, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
> +
> + /* I2C */
> + {3, 26, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
> + {3, 27, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
>
> [NIMA] The MPC8272 manual states that it should be pins 14/15 and not
> 26/27.
Ah thanks.
> However, in all my accesses,
> - 1st write is successful
> - 1st read fails (times out)
> - 2nd read succeeds
>
> Here is the debug log:
> i2c-adapter i2c-0: ioctl, cmd=0x703, arg=0x40
> i2c-dev: i2c-0 writing 2 bytes.
> i2c-adapter i2c-0: master_xfer[0] W, addr=0x40, len=2
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_iic_write(abyte=0x80)
> i2c-adapter i2c-0: tx sc 0 bc00
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: Interrupt: 2
> i2c-adapter i2c-0: Interrupt: 1
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: ready.
> i2c-adapter i2c-0: tx sc 0 3c00
> i2c-dev: i2c-0 reading 1 bytes.
> i2c-adapter i2c-0: master_xfer[0] R, addr=0x40, len=1
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_i2c_read(abyte=0x81)
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: I2C read: timeout!
> i2c-adapter i2c-0: cpm_i2c_force_close()
> i2c-dev: i2c-0 reading 1 bytes.
> i2c-adapter i2c-0: master_xfer[0] R, addr=0x40, len=1
> i2c-adapter i2c-0: i2c-algo-cpm.o: R: 0 T: 0
> i2c-adapter i2c-0: cpm_i2c_read(abyte=0x81)
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: not ready.
> i2c-adapter i2c-0: Interrupt: 1
> i2c-adapter i2c-0: test ready.
> i2c-adapter i2c-0: ready.
> i2c-adapter i2c-0: rx sc 2c00, rx sc 1800
>
> Any ideas?
What does you chip expect? Start-Write-Start-Read-Stop or Start-Write-Stop, Start-Read-Stop?
Did you try chaining the write and read request (put them into the same msg)?
Thanks,
Jochen
^ permalink raw reply
* Re: /proc/bus/pci and domains
From: Martin Mares @ 2008-02-14 9:40 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Linux-PCI Mailing List, paulus, anton
In-Reply-To: <20080214044323.GB1176@kroah.com>
Hi Greg!
> I have no idea, it sounds like a PPC specific thing, not anything the
> PCI core does, right? So I'll add the ppc list to the cc: and ask if
> anyone there has any ideas?
Unfortunately, this is not PPC specific at all -- proc_attach_device()
calls pci_proc_domain(bus), which is an arch-specific hook turning on
the weird behavior I described. This hook can return non-zero even on
x86 if there are buses outside domain 0.
I think that the hook itself is correct, it only should trigger more
consistent behavior of the generic code :)
Would it be acceptable for the PPC folks to modify the code to add
domain numbers to the device numbers in /proc/bus/pci/devices in the
same format as the bus directories already have?
If so, I will cook up a patch.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Dijkstra probably hates me." -- /usr/src/linux/kernel/sched.c
^ permalink raw reply
* Re: [BUG] 2.6.25-rc1-git1 softlockup while bootup on powerpc
From: Kamalesh Babulal @ 2008-02-14 9:59 UTC (permalink / raw)
To: Ingo Molnar
Cc: Dhaval Giani, Jens Axboe, Srivatsa Vaddagiri, LKML, linuxppc-dev,
Balbir Singh
In-Reply-To: <20080212075812.GC11775@elte.hu>
Ingo Molnar wrote:
> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> While booting with the 2.6.25-rc1-git1 kernel on the powerbox the
>> softlockup is seen, with following trace.
>
>> BUG: soft lockup - CPU#1 stuck for 61s! [insmod:377]
>> TASK = c00000077cb2f0e0[377] 'insmod' THREAD: c00000077cb28000 CPU: 1
>> NIP [c0000000001b172c] .radix_tree_gang_lookup+0xdc/0x1e4
>> LR [c0000000001a6f00] .call_for_each_cic+0x50/0x10c
>> Call Trace:
>> [c00000077cb2bb20] [c0000000001a6f60] .call_for_each_cic+0xb0/0x10c (unreliable)
>> [c00000077cb2bc60] [c00000000019ecd8] .exit_io_context+0xf0/0x110
>> [c00000077cb2bcf0] [c00000000006254c] .do_exit+0x820/0x850
>> [c00000077cb2bda0] [c000000000062648] .do_group_exit+0xcc/0xe8
>> [c00000077cb2be30] [c00000000000872c] syscall_exit+0x0/0x40
>
> this call_for_each_cic/radix_tree_gang_lookup locked up, and all other
> CPUs deadlocked in stopmachine, due to this one.
>
> call_for_each_cic is in ./block/cfq-iosched.c uses RCU, but you've got
> classic-RCU:
>
> CONFIG_CLASSIC_RCU=y
> # CONFIG_PREEMPT_RCU is not set
>
> so it's not related to the preempt-RCU changes either.
>
> It is this part that locks up:
>
> do {
> ...
> nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics,
> index, CIC_GANG_NR);
> ...
> } while (nr == CIC_GANG_NR);
> ...
>
> it seems the radix tree will yield new entries again and again. Either
> it got corrupted, or some other CPU is filling it faster than we can
> deplete it [unlikely i think].
>
> Ingo
This softlockup is seen with the 2.6.25-rc1-git3 also. Let me know if you
need more details.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
From: Pavel Kiryukhin @ 2008-02-14 9:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B8D9D613-441B-4A20-AE2D-D808D4B82F16@kernel.crashing.org>
Kumar Gala wrote:
>
> On Feb 13, 2008, at 3:19 PM, Pavel Kiryukhin wrote:
>
>> Add regshift reading to serial drivers.
>> This enables correct operation of serial ports with nonzero regshift.
>
> what device needs this?
>
> - k
Xilinx opb 16550 uart
--
Pavel
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Christoph Raisch @ 2008-02-14 8:46 UTC (permalink / raw)
To: ossthema
Cc: Thomas Q Klein, Jan-Bernd Themann, Greg KH, Dave Hansen, apw,
linux-kernel, linuxppc-dev, Badari Pulavarty, netdev, tklein
In-Reply-To: <200802131617.58646.ossthema@de.ibm.com>
Dave Hansen <haveblue@us.ibm.com> wrote on 13.02.2008 18:05:00:
> On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > Constraints imposed by HW / FW:
> > - eHEA has own MMU
> > - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate
virtual
> > addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> > - The number of MRs is limited (not enough to have one MR per packet)
>
> Are there enough to have one per 16MB section?
Unfortunately this won't work. This was one of our first ideas we tossed
out,
but the number of MRs will not be sufficient.
>
> > Our current understanding about the current Memory Hotplug System are
> > (please correct me if I'm wrong):
> >
> > - depends on sparse mem
>
> You're wrong ;). In mainline, this is true. There was a version of the
> SUSE kernel that did otherwise. But you can not and should not depend
> on this never changing. But, someone is perfectly free to go out an
> implement something better than sparsemem for memory hotplug. If they
> go and do this, your driver may get left behind.
We understand that the add/remove area is not as
settled in the kernel like for example f_ops ;-)
Are there already base working assumptions which are very unlikely to
change?
>
> > - only whole memory sections are added / removed
> > - for each section a memory resource is registered
>
> True, and true. (There might be exceptions to the whole sections one,
> but that's blatant abuse and should be fixed. :)
>
> > From the driver side we need:
> > - some kind of memory notification mechanism.
> > For memory add we can live without any external memory notification
> > event. For memory remove we do need an external trigger (see
explanation
> > above).
>
> You can export and use (un)register_memory_notifier. You just need to
> do it in a reasonable way that compiles for randconfig on your
> architecture. Believe me, we don't want to start teaching drivers about
> sparsemem.
I'm a little confused here....
...the existing add/remove code depends on sparse mem.
Other pieces on the POWER6 version of the architecture do as well.
So we could either chose to disable add/remove if sparsemem is not there,
or disable the driver by Kconfig in this case.
> > - a way to iterate over all kernel pages and a way to detect holes in
the
> > kernel memory layout in order to build up our own ehea_bmap.
>
> Look at kernel/resource.c
>
> But, I'm really not convinced that you can actually keep this map
> yourselves. It's not as simple as you think. What happens if you get
> on an LPAR with two sections, one 256MB@0x0 and another
> 16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
> array will eat all of memory.
I'm glad you mention this part. There are many algorithms out there to
handle this problem,
hashes/trees/... all of these trade speed for smaller memory footprint.
We based the table decission on the existing implementations of the
architecture.
Do you see such a case coming along for the next generation POWER systems?
I would guess these drastic changes would also require changes in base
kernel.
Will you provide a generic mapping system with a contiguous virtual address
space
like the ehea_bmap we can query? This would need to be a "stable" part of
the implementation,
including translation functions from kernel to nextgen_ehea_generic_bmap
like virt_to_abs.
>
> That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
> in the core, so that we can deal with these kinds of problems, once and
> *NOT* in every single little driver out there.
>
> > Functions to use while building ehea_bmap + MRs:
> > - Use either the functions that are used by the memory hotplug system
as
> > well, that means using the section defines + functions
(section_nr_to_pfn,
> > pfn_valid)
>
> Basically, you can't use anything related to sections outside of the
> core code. You can use things like pfn_valid(), or you can create new
> interfaces that are properly abstracted.
We picked sections instead of PFNs because this keeps the ehea_bmap in a
reasonable range
on the existing systems.
But if you provide a abstract method handling exactly the problem we
mention
we'll be happy to use that and dump our private implementation.
>
> > - Use currently other not exported functions in kernel/resource.c, like
> > walk_memory_resource (where we would still need the maximum
> possible number
> > of pages NR_MEM_SECTIONS)
>
> It isn't the act of exporting that's the problem. It's making sure that
> the exports won't be prone to abuse and that people are using them
> properly. You should assume that you can export and use
> walk_memory_resource().
So this seems to come down to a basic question:
New hardware seems to have a tendency to get "private MMUs",
which need private mappings from the kernel address space into a
"HW defined address space with potentially unique characteristics"
RDMA in Openfabrics with global MR is the most prominent example heading
there
>
> Do you know what other operating systems do with this hardware?
We're not aware of another open source Operating system trying to address
this topic.
>
> In the future, please make an effort to get review from knowledgeable
> people about these kinds of things before using them in your driver.
> Your company has many, many resources available, and all you need to do
> is ask. All that you have to do is look to the tops of the files of the
> functions you are calling.
>
So we're glad we finally found the right person who takes responsibility
for this topic!
> -- Dave
>
Gruss / Regards
Christoph Raisch + Jan-Bernd Themann
^ permalink raw reply
* a question on an error of building 2.6.24.2
From: Jingyu Liu @ 2008-02-14 8:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 844 bytes --]
Hi there,
I am using a cross-compiler gcc 4.1.2 and glibc 2.3.6 to build 2.6.24.2. At
the end of building, the ld gives the following error messages:
LD init/built-in.o
LD vmlinux
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o:
defined in discarded section `.exit.data' of drivers/built-in.o
make: *** [vmlinux] Error 1
.config file is also attached.
Is it gcc problem, or something else?
Jingyu
[-- Attachment #1.2: Type: text/html, Size: 1042 bytes --]
[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 14503 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24.2
# Wed Feb 13 23:52:29 2008
#
# CONFIG_PPC64 is not set
#
# Processor support
#
# CONFIG_6xx is not set
# CONFIG_PPC_85xx is not set
CONFIG_PPC_8xx=y
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_8xx=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_NOT_COHERENT_CACHE=y
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
# CONFIG_PPC_UDBG_16550 is not set
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
# CONFIG_SYSCTL_SYSCALL is not set
# CONFIG_KALLSYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
# CONFIG_EVENTFD is not set
# CONFIG_SHMEM is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_SLUB_DEBUG is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_TINY_SHMEM=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
# CONFIG_BLOCK is not set
#
# Platform support
#
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
CONFIG_CPM1=y
# CONFIG_MPC8XXFADS is not set
# CONFIG_MPC86XADS is not set
CONFIG_MPC885ADS=y
# CONFIG_PPC_EP88XC is not set
#
# MPC8xx CPM Options
#
#
# Generic MPC8xx Options
#
# CONFIG_8xx_COPYBACK is not set
# CONFIG_8xx_CPU6 is not set
CONFIG_8xx_CPU15=y
CONFIG_NO_UCODE_PATCH=y
# CONFIG_USB_SOF_UCODE_PATCH is not set
# CONFIG_I2C_SPI_UCODE_PATCH is not set
# CONFIG_I2C_SPI_SMC1_UCODE_PATCH is not set
# CONFIG_PQ2ADS is not set
# CONFIG_MPIC is not set
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
# CONFIG_GENERIC_IOMAP is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_CPM2 is not set
CONFIG_PPC_CPM_NEW_BINDING=y
# CONFIG_FSL_ULI1575 is not set
CONFIG_CPM=y
#
# Kernel options
#
# CONFIG_HIGHMEM is not set
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_8XX_MINIMAL_FPEMU is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_VIRT_TO_BUS=y
# CONFIG_PROC_DEVICETREE is not set
# CONFIG_CMDLINE_BOOL is not set
# CONFIG_PM is not set
CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_HIBERNATION_UP_POSSIBLE=y
# CONFIG_SECCOMP is not set
CONFIG_WANT_DEVICE_TREE=y
CONFIG_DEVICE_TREE=""
CONFIG_ISA_DMA_API=y
#
# Bus options
#
CONFIG_ZONE_DMA=y
CONFIG_FSL_SOC=y
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS is not set
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCI_QSPAN is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set
#
# Advanced setup
#
# CONFIG_ADVANCED_OPTIONS is not set
#
# Default settings for advanced configuration options are used
#
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START=0xfd000000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x00400000
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_FIB_RULES=y
#
# Wireless
#
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_EXT=y
CONFIG_IEEE80211=y
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=y
# CONFIG_IEEE80211_CRYPT_CCMP is not set
# CONFIG_IEEE80211_CRYPT_TKIP is not set
# CONFIG_RFKILL is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_OOPS is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0xfe000000
CONFIG_MTD_PHYSMAP_LEN=0x800000
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_CFI_FLAGADM is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
CONFIG_MTD_SLRAM=y
CONFIG_MTD_PHRAM=y
CONFIG_MTD_MTDRAM=y
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTDRAM_ABS_POS=0
#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=y
CONFIG_MTD_DOC2001=y
CONFIG_MTD_DOC2001PLUS=y
CONFIG_MTD_DOCPROBE=y
CONFIG_MTD_DOCECC=y
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0
# CONFIG_MTD_NAND is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_ONENAND is not set
#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
# CONFIG_MISC_DEVICES is not set
#
# SCSI device support
#
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_MACINTOSH_DRIVERS is not set
# CONFIG_NETDEVICES is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_MOXA_SMARTIO is not set
CONFIG_N_HDLC=y
# CONFIG_RISCOM8 is not set
CONFIG_SPECIALIX=y
# CONFIG_SPECIALIX_RTSCTS is not set
# CONFIG_RIO is not set
CONFIG_STALDRV=y
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=48
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_CPM is not set
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_IPMI_HANDLER=y
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=y
CONFIG_IPMI_SI=y
CONFIG_IPMI_WATCHDOG=y
CONFIG_IPMI_POWEROFF=y
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
# CONFIG_GEN_RTC is not set
CONFIG_R3964=y
# CONFIG_I2C is not set
#
# SPI support
#
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
#
# SPI Protocol Masters
#
CONFIG_SPI_AT25=y
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y
#
# Display hardware drivers
#
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
# CONFIG_HID_SUPPORT is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_RTC_CLASS is not set
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# File systems
#
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_DNOTIFY is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
#
# Miscellaneous filesystems
#
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_JFFS2_FS_WRITEBUFFER is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
# CONFIG_NLS is not set
# CONFIG_UCC_SLOW is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
# CONFIG_INSTRUMENTATION is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_SAMPLES is not set
# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_PPC_CLOCK is not set
CONFIG_PPC_LIB_RHEAP=y
^ permalink raw reply
* Re: Cannot mount root file system using nfs.
From: Wolfgang Grandegger @ 2008-02-14 7:30 UTC (permalink / raw)
To: rakesh bk; +Cc: linuxppc-embedded
In-Reply-To: <43455a600802130256h56c098b5k18e7a4e6507f774@mail.gmail.com>
rakesh bk wrote:
> Hi EveryOne,
>
> I am new to Xenomai , I have ported linux-2.6.14 to our custom board
> based on IBM750Cxe Iam unable to boot my kernel cross compiled with
> eldk-3.0 with
> enabled xenomai support.If i remove xenomai and ipipe support the
> kernel boots correctly , but if i enable CONFIG_IPIPE I get stuck in the
> before mounting the root file system .
I already told you that Xenomai related questions are off-topic on this
list and that's why you do not get any help. Please subscribed to and
re-post on the Xenomai-help mailing list
(https://mail.gna.org/listinfo/xenomai-help).
Wolfgang.
^ permalink raw reply
* libfdt: Fix NOP handling bug in fdt_add_subnode_namelen()
From: David Gibson @ 2008-02-14 5:50 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
fdt_add_subnode_namelen() has a bug if asked to add a subnode to a
node which has NOP tags interspersed with its properties. In this
case fdt_add_subnode_namelen() will put the new subnode before the
first NOP tag, even if there are properties after it, which will
result in an invalid blob.
This patch fixes the bug, and adds a testcase for it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2008-02-14 15:10:35.000000000 +1100
+++ dtc/tests/Makefile.tests 2008-02-14 15:10:43.000000000 +1100
@@ -10,7 +10,8 @@
move_and_save mangle-layout \
open_pack rw_tree1 set_name setprop del_property del_node \
string_escapes references path-references \
- dtbs_equal_ordered
+ dtbs_equal_ordered \
+ add_subnode_with_nops
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
LIBTREE_TESTS_L = truncated_property
Index: dtc/tests/add_subnode_with_nops.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/add_subnode_with_nops.c 2008-02-14 15:12:45.000000000 +1100
@@ -0,0 +1,85 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_nop_node()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <ctype.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+#define SPACE 65536
+
+#define CHECK(code) \
+ { \
+ err = (code); \
+ if (err) \
+ FAIL(#code ": %s", fdt_strerror(err)); \
+ }
+
+#define OFF_CHECK(off, code) \
+ { \
+ (off) = (code); \
+ if (off < 0) \
+ FAIL(#code ": %s", fdt_strerror(off)); \
+ }
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int err;
+ int offset;
+
+ test_init(argc, argv);
+
+ fdt = xmalloc(SPACE);
+
+ CHECK(fdt_create(fdt, SPACE));
+
+ CHECK(fdt_finish_reservemap(fdt));
+ CHECK(fdt_begin_node(fdt, ""));
+ CHECK(fdt_property_cell(fdt, "prop1", TEST_VALUE_1));
+ CHECK(fdt_property_cell(fdt, "prop2", TEST_VALUE_2));
+ CHECK(fdt_end_node(fdt));
+ CHECK(fdt_finish(fdt));
+
+ verbose_printf("Built empty tree, totalsize = %d\n",
+ fdt_totalsize(fdt));
+
+ CHECK(fdt_open_into(fdt, fdt, SPACE));
+
+ check_getprop_cell(fdt, 0, "prop1", TEST_VALUE_1);
+ check_getprop_cell(fdt, 0, "prop2", TEST_VALUE_2);
+
+ CHECK(fdt_nop_property(fdt, 0, "prop1"));
+
+ check_getprop_cell(fdt, 0, "prop2", TEST_VALUE_2);
+
+ OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode"));
+
+ check_getprop_cell(fdt, 0, "prop2", TEST_VALUE_2);
+
+ PASS();
+}
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2008-02-14 15:11:10.000000000 +1100
+++ dtc/tests/run_tests.sh 2008-02-14 15:11:25.000000000 +1100
@@ -128,6 +128,9 @@
# Tests for behaviour on various sorts of corrupted trees
run_test truncated_property
+
+ # Specific bug tests
+ run_test add_subnode_with_nops
}
dtc_tests () {
Index: dtc/libfdt/fdt_rw.c
===================================================================
--- dtc.orig/libfdt/fdt_rw.c 2008-02-14 15:15:29.000000000 +1100
+++ dtc/libfdt/fdt_rw.c 2008-02-14 15:15:40.000000000 +1100
@@ -333,7 +333,7 @@
do {
offset = nextoffset;
tag = fdt_next_tag(fdt, offset, &nextoffset);
- } while (tag == FDT_PROP);
+ } while ((tag == FDT_PROP) || (tag == FDT_NOP));
nh = _fdt_offset_ptr_w(fdt, offset);
nodelen = sizeof(*nh) + ALIGN(namelen+1, FDT_TAGSIZE) + FDT_TAGSIZE;
--
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: /proc/bus/pci and domains
From: Greg KH @ 2008-02-14 4:43 UTC (permalink / raw)
To: Martin Mares, paulus, anton; +Cc: linuxppc-dev, Linux-PCI Mailing List
In-Reply-To: <mj+md-20080213.154522.9237.albireo@ucw.cz>
On Wed, Feb 13, 2008 at 04:53:55PM +0100, Martin Mares wrote:
> Hi Greg et al.,
>
> I have noticed that lspci with the proc back-end does not work properly
> on ppc64. The problem turned out to be a strange hack in drivers/pci/proc.c
> causing the following behavior on machines with multiple PCI domains:
> The directory names under /proc/bus/pci/ have a domain number added (which
> is not backward compatible, but at least consistent), but on the other hand
> /proc/bus/pci/devices contains bus numbers without the domains, happily
> making multiple entries with the same bus and device number.
>
> Is there any serious reason for this behavior?
I have no idea, it sounds like a PPC specific thing, not anything the
PCI core does, right? So I'll add the ppc list to the cc: and ask if
anyone there has any ideas?
Rest of the original email follows...
>
> The original /proc/bus/pci/ (as I have designed it years ago) does not
> have any means of carrying the domain numbers, so it cannot be solved
> in a backward-compatible way, but the inconsistency between the list of
> devices and the actual directories leaves me puzzled.
>
> Wouldn't it be better to make the same backward-incompatible change
> in /proc/bus/pci/devices, so that at least new programs can use the
> thing?
>
> Of course, all this is of minor importance as all new programs know
> how to use the sysfs anyway (I have found the problem only because
> I forgot to mount sysfs to a chroot), but if we want to keep /proc/bus/pci/,
> we should fix it.
>
> Have a nice fortnight
> --
> Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
> Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
> Entropy isn't what it used to be.
^ permalink raw reply
* [PATCH] remove unused CONFIG_WANT_DEVICE_TREE
From: Grant Likely @ 2008-02-14 4:14 UTC (permalink / raw)
To: paulus, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
CONFIG_DEVICE_TREE was the only user of CONFIG_WANT_DEVICE_TREE but
it was removed in commit id 25431333813686654907ab987fb5de10c10a16db
(bootwrapper: Build multiple cuImages).
This patch removes CONFIG_WANT_DEVICE_TREE from Kconfig and the defconfigs
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Paul, this patch cleans up after a commit the multiple cuImage patch that
went in during the merge window. It should probably be merged for .25
Thanks,
g.
arch/powerpc/Kconfig | 4 ----
arch/powerpc/platforms/512x/Kconfig | 1 -
arch/powerpc/platforms/52xx/Kconfig | 2 --
arch/powerpc/platforms/Kconfig | 2 --
arch/powerpc/platforms/Kconfig.cputype | 4 ----
arch/powerpc/platforms/embedded6xx/Kconfig | 4 ----
6 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8dcac0b..53b0940 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -435,10 +435,6 @@ config SECCOMP
If unsure, say Y. Only embedded should say N here.
-config WANT_DEVICE_TREE
- bool
- default n
-
endmenu
config ISA_DMA_API
diff --git a/arch/powerpc/platforms/512x/Kconfig b/arch/powerpc/platforms/512x/Kconfig
index c6fa49e..4c0da0c 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -13,7 +13,6 @@ config MPC5121_ADS
bool "Freescale MPC5121E ADS"
depends on PPC_MULTIPLATFORM && PPC32
select DEFAULT_UIMAGE
- select WANT_DEVICE_TREE
select PPC_MPC5121
help
This option enables support for the MPC5121E ADS board.
diff --git a/arch/powerpc/platforms/52xx/Kconfig b/arch/powerpc/platforms/52xx/Kconfig
index 515f244..cf945d5 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -8,7 +8,6 @@ config PPC_MPC5200_SIMPLE
bool "Generic support for simple MPC5200 based boards"
depends on PPC_MPC52xx
select DEFAULT_UIMAGE
- select WANT_DEVICE_TREE
help
This option enables support for a simple MPC52xx based boards which
do not need a custom platform specific setup. Such boards are
@@ -35,7 +34,6 @@ config PPC_LITE5200
bool "Freescale Lite5200 Eval Board"
depends on PPC_MPC52xx
select DEFAULT_UIMAGE
- select WANT_DEVICE_TREE
config PPC_MPC5200_BUGFIX
bool "MPC5200 (L25R) bugfix support"
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index fcedbec..0afd225 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -15,7 +15,6 @@ config PPC_MULTIPLATFORM
config PPC_82xx
bool "Freescale 82xx"
depends on 6xx
- select WANT_DEVICE_TREE
config PPC_83xx
bool "Freescale 83xx"
@@ -23,7 +22,6 @@ config PPC_83xx
select FSL_SOC
select MPC83xx
select IPIC
- select WANT_DEVICE_TREE
select FSL_EMB_PERFMON
config PPC_86xx
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 69941ba..73d81ce 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -29,26 +29,22 @@ config PPC_85xx
bool "Freescale 85xx"
select E500
select FSL_SOC
- select WANT_DEVICE_TREE
select MPC85xx
config PPC_8xx
bool "Freescale 8xx"
select FSL_SOC
select 8xx
- select WANT_DEVICE_TREE
select PPC_LIB_RHEAP
config 40x
bool "AMCC 40x"
select PPC_DCR_NATIVE
- select WANT_DEVICE_TREE
select PPC_UDBG_16550
config 44x
bool "AMCC 44x"
select PPC_DCR_NATIVE
- select WANT_DEVICE_TREE
select PPC_UDBG_16550
config E200
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 6c80837..4290889 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -24,7 +24,6 @@ config STORCENTER
select MPIC
select FSL_SOC
select PPC_UDBG_16550 if SERIAL_8250
- select WANT_DEVICE_TREE
select MPC10X_OPENPIC
select MPC10X_BRIDGE
help
@@ -37,7 +36,6 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
- select WANT_DEVICE_TREE
select TSI108_BRIDGE
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
@@ -48,7 +46,6 @@ config PPC_HOLLY
depends on EMBEDDED6xx
select TSI108_BRIDGE
select PPC_UDBG_16550
- select WANT_DEVICE_TREE
select TSI108_BRIDGE
help
Select PPC_HOLLY if configuring for an IBM 750GX/CL Eval
@@ -59,7 +56,6 @@ config PPC_PRPMC2800
depends on EMBEDDED6xx
select MV64X60
select NOT_COHERENT_CACHE
- select WANT_DEVICE_TREE
help
This option enables support for the Motorola PrPMC2800 board
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Enable correct operation of serial ports with nonzero regshift.
From: Kumar Gala @ 2008-02-14 3:56 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: linuxppc-dev
In-Reply-To: <47B35ED8.7020404@ru.mvista.com>
On Feb 13, 2008, at 3:19 PM, Pavel Kiryukhin wrote:
> Add regshift reading to serial drivers.
> This enables correct operation of serial ports with nonzero regshift.
what device needs this?
- k
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Tony Breeds @ 2008-02-14 3:46 UTC (permalink / raw)
To: Manish Ahuja; +Cc: linuxppc-dev
In-Reply-To: <47B145E9.9020907@austin.ibm.com>
On Tue, Feb 12, 2008 at 01:08:25AM -0600, Manish Ahuja wrote:
>
> Initial patch for reserving memory in early boot, and freeing it later.
> If the previous boot had ended with a crash, the reserved memory would contain
> a copy of the crashed kernel data.
>
> Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> arch/powerpc/kernel/prom.c | 50 ++++++++++++++++++++
> arch/powerpc/kernel/rtas.c | 32 +++++++++++++
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/phyp_dump.c | 71 +++++++++++++++++++++++++++++
> include/asm-powerpc/phyp_dump.h | 38 +++++++++++++++
> include/asm/rtas.h | 3 +
> 6 files changed, 195 insertions(+)
>
> Index: 2.6.24-rc5/include/asm-powerpc/phyp_dump.h
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ 2.6.24-rc5/include/asm-powerpc/phyp_dump.h 2008-02-12 06:12:37.000000000 -0600
> @@ -0,0 +1,38 @@
> +/*
> + * Hypervisor-assisted dump
> + *
> + * Linas Vepstas, Manish Ahuja 2007
> + * Copyright (c) 2007 IBM Corp.
Hi Manish,
Sorry for the minor nits but this should be:
---
* Linas Vepstas, Manish Ahuja 2008
* Copyright 2008 IBM Corp.
---
You can optionally use the '©' symbol after word 'Copyright' but you
shouldn't use '(c)' anymore.
Also in at least one place you've misspelt "Copyright"
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* [PATCH 1/1] Cell RAS: Remove DEBUG, and add license and copyright
From: Michael Ellerman @ 2008-02-14 2:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
arch/powerpc/platforms/cell/ras.c still has DEBUG #defined, which is no
longer neccessary. Disable it, this disables to pr_debugs().
While we're there this file should have a copyright notice and license,
so add both.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/ras.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/cell/ras.c b/arch/powerpc/platforms/cell/ras.c
index b2494eb..e43024c 100644
--- a/arch/powerpc/platforms/cell/ras.c
+++ b/arch/powerpc/platforms/cell/ras.c
@@ -1,4 +1,13 @@
-#define DEBUG
+/*
+ * Copyright 2006-2008, IBM Corporation.
+ *
+ * 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.
+ */
+
+#undef DEBUG
#include <linux/types.h>
#include <linux/kernel.h>
--
1.5.2.rc1.1884.g59b20
^ permalink raw reply related
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