Re: [PATCH] of: i2c: improve last resort compatible entry selection
A reasonable "compatible" value would be something like "serial-eeprom-24c32". You can go a little bit more generic than that, if you write up in your binding how the driver should figure out the device size and the protocol used. Matching on "serial-eeprom-24c32" requires me to convince the at24 authors to add that string as an alias binding for their driver. No, it requires the IIC subsystem to get fixed and not use OF "compatible" values as module alias names. How about "serial-eeprom,24c32" or "generic,24x32"? Neither "serial-eeprom" nor "generic" is the name of a vendor, so no. The comma has a well-defined meaning. Why would a comma be easier than a dash for your device matching code, anyway? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Sat, 26 Jul 2008, Grant Likely wrote: > On Fri, Jul 25, 2008 at 02:01:45PM -0700, Trent Piepho wrote: >> Add bindings to support LEDs defined as of_platform devices in addition to >> the existing bindings for platform devices. > >> +- gpios : Should specify the LED GPIO. > > Question: it is possible/desirable for a single LED to be assigned > multiple GPIO pins? Say, for a tri-color LED? (I'm fishing for > opinions; I really don't know if it would be a good idea or not) Good question. The Linux LED layer has no concept of multi-color LEDs, so it's more difficult that just adding support to the gpio led driver. I have a device with a tri-color red/green/orange LED and this posed some difficulty. It's defined as independent red and greed LEDs, which is mostly fine, except I wanted it to flash orange. I can make both the red LED and green LED flash, but there is nothing to insure their flashing remains in sync. Other OF bindings allow multiple GPIOs to be listed in a gpios property, so that's not a problem if someone wants to do that. There would need to be a way to define what the gpios mean. I don't think it's worthwhile to come up with a binding for that until there is a real user. >> +- function : (optional) This parameter, if present, is a string >> + defining the function of the LED. It can be used to put the LED >> + under software control, e.g. Linux LED triggers like "heartbeat", >> + "ide-disk", and "timer". Or it could be used to attach a hardware >> + signal to the LED, e.g. a SoC that can configured to put a SATA >> + activity signal on a GPIO line. > > This makes me nervous. It exposes Linux internal implementation details > into the device tree data. If you want to have a property that > describes the LED usage, then the possible values and meanings should be > documented here. Should it be a linux specific property then? I could list all the current linux triggers, but enumerating every possible function someone might want to assign to an LED seems hopeless. >> +led.default_trigger = >> +of_get_property(child, "linux,default-trigger", NULL); > > This isn't in the documented binding. I assume that you mean 'function' > here? Looks like I emailed the wrong patch file. That should be changed to "function" and there are a few cosmetic changes that are missing. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] cpm_uart: Add generic clock API support to set baudrates
This patch introduces baudrate setting support via the generic clock API.
When present the optional device tree clock property is used instead of
fsl-cpm-brg. Platforms can then define complex clock schemes, to output
the serial clock on an external pin for instance.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart.h |1 +
drivers/serial/cpm_uart/cpm_uart_core.c | 26 +++---
2 files changed, 20 insertions(+), 7 deletions(-)
On Friday 25 July 2008, Kumar Gala wrote:
> I'm having problems applying due to mailer formatting.
*sigh* I'll definitely have to fix GPG support in kmail. Sorry about the
annoyance.
diff --git a/drivers/serial/cpm_uart/cpm_uart.h
b/drivers/serial/cpm_uart/cpm_uart.h
index d0c55e2..2e64c03 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -77,6 +77,7 @@ struct uart_cpm_port {
unsigned char *rx_buf;
u32 flags;
void(*set_lineif)(struct uart_cpm_port *);
+ struct clk *clk;
u8 brg;
uint dp_addr;
void*mem_addr;
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index d3c19e5..438e460 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
@@ -641,7 +642,10 @@ static void cpm_uart_set_termios(struct uart_port *port,
out_be16(&sccp->scc_psmr, (sbits << 12) | scval);
}
- cpm_set_brg(pinfo->brg - 1, baud);
+ if (pinfo->clk)
+ clk_set_rate(pinfo->clk, baud);
+ else
+ cpm_set_brg(pinfo->brg - 1, baud);
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -991,13 +995,21 @@ static int cpm_uart_init_port(struct device_node *np,
int ret;
int i;
- data = of_get_property(np, "fsl,cpm-brg", &len);
- if (!data || len != 4) {
- printk(KERN_ERR "CPM UART %s has no/invalid "
- "fsl,cpm-brg property.\n", np->name);
- return -EINVAL;
+ data = of_get_property(np, "clock", NULL);
+ if (data) {
+ struct clk *clk = clk_get(NULL, (const char*)data);
+ if (!IS_ERR(clk))
+ pinfo->clk = clk;
+ }
+ if (!pinfo->clk) {
+ data = of_get_property(np, "fsl,cpm-brg", &len);
+ if (!data || len != 4) {
+ printk(KERN_ERR "CPM UART %s has no/invalid "
+ "fsl,cpm-brg property.\n", np->name);
+ return -EINVAL;
+ }
+ pinfo->brg = *data;
}
- pinfo->brg = *data;
data = of_get_property(np, "fsl,cpm-command", &len);
if (!data || len != 4) {
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv4] cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
Based on earlier work by Laurent Pinchart.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
Cc: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +
arch/powerpc/sysdev/cpm2.c | 11
arch/powerpc/sysdev/cpm_common.c | 123 ++
include/asm-powerpc/cpm.h|3 +
4 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 87454c5..7e67e26 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -280,6 +280,8 @@ config CPM2
depends on MPC85xx || 8260
select CPM
select PPC_LIB_RHEAP
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
help
The CPM2 (Communications Processor Module) is a coprocessor on
embedded CPUs made by Freescale. Selecting this option means that
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 5a6c5df..9311778 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -377,3 +377,14 @@ void cpm2_set_pin(int port, int pin, int flags)
else
clrbits32(&iop[port].odr, pin);
}
+
+static int cpm_init_par_io(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,cpm2-pario-bank")
+ cpm2_gpiochip_add32(np);
+ return 0;
+}
+arch_initcall(cpm_init_par_io);
+
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..b957a48 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -19,6 +19,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -28,6 +30,10 @@
#include
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+#include
+#endif
+
#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
static u32 __iomem *cpm_udbg_txdesc =
(u32 __iomem __force *)CONFIG_PPC_EARLY_DEBUG_CPM_ADDR;
@@ -198,3 +204,120 @@ dma_addr_t cpm_muram_dma(void __iomem *addr)
return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
}
EXPORT_SYMBOL(cpm_muram_dma);
+
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+
+struct cpm2_ioports {
+ u32 dir, par, sor, odr, dat;
+ u32 res[3];
+};
+
+struct cpm2_gpio32_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct cpm2_gpio32_chip *
+to_cpm2_gpio32_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm2_gpio32_chip, mm_gc);
+}
+
+static void cpm2_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+
+ cpm2_gc->cpdata = in_be32(&iop->dat);
+}
+
+static int cpm2_gpio32_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ return !!(in_be32(&iop->dat) & pin_mask);
+}
+
+static void cpm2_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ spin_lock_irqsave(&cpm2_gc->lock, flags);
+
+ if (value)
+ cpm2_gc->cpdata |= pin_mask;
+ else
+ cpm2_gc->cpdata &= ~pin_mask;
+
+ out_be32(&iop->dat, cpm2_gc->cpdata);
+
+ spin_unlock_irqrestore(&cpm2_gc->lock, flags);
+}
+
+static int cpm2_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int
val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ setbits32(&iop->dir, pin_mask);
+
+ cpm2_gpio32_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm2_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ clrbits32(&iop->dir, pin_mask);
+
+ return 0;
+}
+
+int cpm2_gpiochip_add32(struct device_node *np)
+{
+ struct cpm2_gpio32_chip *cpm2_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm2_gc = kzalloc(sizeof(*cpm2_gc), GFP_KERNEL);
+ if (!cpm2_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&cpm2_gc->lock);
+
+ mm_gc = &cpm2_gc->mm_gc;
+ of_gc = &mm_gc
Re: mISDN still breaking the allmodconfig build...
On Sun, 27 Jul 2008 20:48:05 -0400 Sean MacLennan <[EMAIL PROTECTED]> wrote: > On Mon, 28 Jul 2008 10:13:42 +1000 > "Benjamin Herrenschmidt" <[EMAIL PROTECTED]> wrote: > > > On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote: > > > More fallout from the premature mISDN driver merge: > > > > > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not > > > running on big endian machines now" > > > > Lovely... > > mISDN is notoriously bad on big endian machines. In which case it really should not be in Linus tree but in linux-next. Karsten - will you ask Linus to revert mISDN so it can go into linux-next instead and get cleaned up in the right place ? Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] leds: make the default trigger name const
On Sun, Jul 27, 2008 at 06:56:49PM -0700, Trent Piepho wrote: > On Sun, 27 Jul 2008, Stephen Rothwell wrote: > > On Sat, 26 Jul 2008 20:08:57 -0600 Grant Likely <[EMAIL PROTECTED]> wrote: > >> On Fri, Jul 25, 2008 at 02:01:44PM -0700, Trent Piepho wrote: > >>> The default_trigger fields of struct gpio_led and thus struct led_classdev > >>> are pretty much always assigned from a string literal, which means the > >>> string can't be modified. Which is fine, since there is no reason to > >>> modify the string and in fact it never is. > >>> > >>> But they should be marked const to prevent such code from being added, to > >>> prevent warnings if -Wwrite-strings is used and when assigned from a > >>> constant string other than a string literal (which produces a warning > >>> under > >>> current kernel compiler flags), and for general good coding practices. > >>> > >>> Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> > >> Acked-by: Grant Likely <[EMAIL PROTECTED]> > > > > I would ack this as well, except I am not sure what tree this patch is > > against. In the current powerpc next tree, > > It was against powerpc next from Jul 22nd, current at the time I made the > patch. It looks like that file has changed in the last few days. There is a > patch from Anton Vorontsov, "leds: mark led_classdev.default_trigger as > const", which adds const to one of the structs I modified, but doesn't get the > other one (struct gpio_led). Yes, I posted the patch for my version of OF GPIO LEDs, which didn't use struct gpio_led's default_trigger. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! I lied :-) There is a couple more features coming in. Mostly Roland tracehook stuff which came in a bit late but since the generic bits are in and he had some powerpc support ready, we felt like it was something worth having. There's also some SPI bits from Grant who were around but took some time to be fully acked and some stuff to expose our cache topology through sysfs that we wanted but took a bit longer to finish than expected. The rest is mostly fixes. It's all in: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge (Hopefully no silly non-printable character this time, at least nothing I manage to spot with evo but who knows...) Cheers, Ben. arch/powerpc/Kconfig |1 arch/powerpc/kernel/entry_32.S | 17 +- arch/powerpc/kernel/entry_64.S | 10 + arch/powerpc/kernel/legacy_serial.c| 44 ++-- arch/powerpc/kernel/process.c |8 - arch/powerpc/kernel/prom_init.c| 39 arch/powerpc/kernel/ptrace.c | 54 ++--- arch/powerpc/kernel/setup-common.c | 24 -- arch/powerpc/kernel/setup_64.c |3 arch/powerpc/kernel/signal.c | 23 ++ arch/powerpc/kernel/smp.c | 119 ++- arch/powerpc/kernel/stacktrace.c |1 arch/powerpc/kernel/sysfs.c| 311 arch/powerpc/kernel/vio.c |6 - arch/powerpc/mm/hugetlbpage.c |9 + arch/powerpc/platforms/powermac/setup.c| 72 ++ arch/powerpc/platforms/powermac/udbg_scc.c | 12 + arch/powerpc/platforms/pseries/cmm.c |8 + drivers/net/ibmveth.c |8 - drivers/of/Kconfig |6 + drivers/of/Makefile|1 drivers/of/base.c | 88 drivers/of/of_i2c.c| 64 -- drivers/of/of_spi.c| 93 drivers/spi/spi.c | 139 + include/asm-powerpc/pgtable-4k.h |2 include/asm-powerpc/pgtable-64k.h |2 include/asm-powerpc/pgtable-ppc32.h|3 include/asm-powerpc/pgtable-ppc64.h|4 include/asm-powerpc/ptrace.h |1 include/asm-powerpc/signal.h |3 include/asm-powerpc/smp.h |2 include/asm-powerpc/syscall.h | 84 include/asm-powerpc/thread_info.h |5 include/asm-powerpc/topology.h |2 include/linux/of.h |1 include/linux/of_spi.h | 18 ++ include/linux/spi/spi.h| 12 + 38 files changed, 1039 insertions(+), 260 deletions(-) create mode 100644 drivers/of/of_spi.c create mode 100644 include/asm-powerpc/syscall.h create mode 100644 include/linux/of_spi.h Benjamin Herrenschmidt (3): powerpc/powermac: Use sane default baudrate for SCC debugging powerpc/powermac: Fixup default serial port device for pmac_zilog powerpc: Disable 64K hugetlb support when doing 64K SPU mappings Grant Likely (3): of: adapt of_find_i2c_driver() to be usable by SPI also spi: split up spi_new_device() to allow two stage registration. spi: Add OF binding support for SPI busses Huang Weiyi (1): powerpc: Removed duplicated include in stacktrace.c Kumar Gala (2): powerpc/booke: Clean up the hardware watchpoint support powerpc: Fix 8xx build failure Nathan Lynch (7): powerpc: Fix vio build warnings powerpc: kill useless SMT code in prom_hold_cpus powerpc: register_cpu_online should be __cpuinit powerpc: Update cpu_sibling_maps dynamically powerpc: Make core sibling information available to userspace powerpc: Make core id information available to userspace powerpc: Show processor cache information in sysfs Nick Piggin (1): powerpc/mm: Implement _PAGE_SPECIAL & pte_special() for 64-bit Roland McGrath (5): powerpc: Call tracehook_signal_handler() when setting up signal frames powerpc: Make syscall tracing use tracehook.h helpers powerpc: Add asm/syscall.h with the tracehook entry points powerpc: Add TIF_NOTIFY_RESUME support for tracehook powerpc: Enable tracehook for the architecture Stephen Rothwell (3): powerpc/pseries: Fix CMO sysdev attribute API change fallout ibmveth: Fix multiple errors with dma_mapping_error conversion powerpc/vio: More fallout from dma_mapping_error API change ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
On Mon, 2008-07-28 at 03:03 +0200, Marcel Holtmann wrote: > Hi Dave, > > > More fallout from the premature mISDN driver merge: > > > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not > > running on big endian machines now" > > is that only the HFC driver or the whole mISDN stack? > > I know that the two old ISDN stacks where really bad on big endian, > but my assumption was that we did sort this out in the end. Well, I got it working well enough (the old one) on a ppc405 about 5 or 6 years ago... It did require some endian & dma mapping fixing, iirc, in the hisax pci driver, but nothing very tricky. What bugs me is that we -fixed- at least some of these things in the old stack, up to the point where I could use it reliably in some commercial products, and now we are merging a new stack which, in that area, is a clear regression over the old code. One basic premise to me for replacing a whole stack with a new one is that the new one should be -at-least- as good as the old one in all areas, and those (virt_to_bus and endianness) are pretty major. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
Hi Marcel, On Mon, Jul 28, 2008 at 03:13:21AM +0200, Marcel Holtmann wrote: > Hi Dave, > > >>>More fallout from the premature mISDN driver merge: > >>> > >>>drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not > >>>running on big endian machines now" > >> > >>is that only the HFC driver or the whole mISDN stack? > >> > >>I know that the two old ISDN stacks where really bad on big endian, > >>but my assumption was that we did sort this out in the end. > > > >One of the two mISDN drivers uses the deprecated virt_to_bus() > >interface for handling DMA addresses (that doesn't even work on many > >x86 systems these days) and the other mISDN driver gives the above > >big-endian compile time error. > > > >In short, this driver was not ready for merging at all. > > I am not defending it and agree that this driver should have had at > least one test run in linux-next. Yes my fault, sorry. > However mISDN is a whole ISDN stack. > So does mISDN has an issue too or do we only have a really broken > driver. Karsten? Yes this is only a issue of the hardware layer not of the stack. OK the driver are based on the old drivers already in HiSax and for virt_to_bus() I never got a complain before and yes I already have some patches to solve the endian issues in the HFC driver, but it was not finaly confirmed, that all this work now on big endian systems and my PPC system unfortunately died some time ago, so I did leave it as it is, but with the wrong option, instead to mark it X86 only I let it break. On the other side this remained me to check the big endian thing again ;-) -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
On Sun, Jul 27, 2008 at 06:07:36PM -0700, David Miller wrote: > From: Marcel Holtmann <[EMAIL PROTECTED]> > Date: Mon, 28 Jul 2008 03:03:04 +0200 > > > > More fallout from the premature mISDN driver merge: > > > > > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not > > > running on big endian machines now" > > > > is that only the HFC driver or the whole mISDN stack? > > > > I know that the two old ISDN stacks where really bad on big endian, > > but my assumption was that we did sort this out in the end. > > One of the two mISDN drivers uses the deprecated virt_to_bus() > interface for handling DMA addresses (that doesn't even work on many > x86 systems these days) and the other mISDN driver gives the above > big-endian compile time error. > OK this was forgotten to change in a printk from the old driver, the new allocation code should be OK it use pci_alloc_consistent(). I think it should simple use the returned dmahandle in this printk. -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
On Mon, Jul 28, 2008 at 10:20:09AM +0100, Alan Cox wrote: > On Sun, 27 Jul 2008 20:48:05 -0400 > Sean MacLennan <[EMAIL PROTECTED]> wrote: > > > On Mon, 28 Jul 2008 10:13:42 +1000 > > "Benjamin Herrenschmidt" <[EMAIL PROTECTED]> wrote: > > > > > On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote: > > > > More fallout from the premature mISDN driver merge: > > > > > > > > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not > > > > running on big endian machines now" > > > > > > Lovely... > > > > mISDN is notoriously bad on big endian machines. > This only affect the hardware IO layer of some cards and I think it will be fixed very soon, I did not remove the very old #error line, because I did not had the hardware to verify that it is OK now. I already reserved a PPC machine now (will get it today or tomorrow) and will test the endian robustness this week. > In which case it really should not be in Linus tree but in linux-next. > Karsten - will you ask Linus to revert mISDN so it can go into linux-next > instead and get cleaned up in the right place ? > This was my original plan and my fault, that I only included the pull URL and sent it to Linus diectely, I did not know that in this case Linus will pull it without further discussion, but I'm still glad that it is in and only show few issues (I'm very unhappy that I did not find these before, I did builds on all our architectures, but not with the all*config, only with subsets). The good thing is, that this brought back the ENDIAN issue back on my radar and on my near time TODO list :-) -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()
On Sun, Jul 27, 2008 at 12:56:04PM -0700, David Miller wrote: > Yes, please. > > IMHO, this driver was really rushed in and that was a huge mistake. > If it had gone through linux-next we could have tidied all of this > stuff up in a less "rushed" manner. Or just reviewed in at least some way.. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv4] cpm2: Implement GPIO LIB API on CPM2 Freescale SoC.
On Jul 28, 2008, at 3:43 AM, Laurent Pinchart wrote: Based on earlier work by Laurent Pinchart. This patch implement GPIO LIB support for the CPM2 GPIOs. Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> Cc: Laurent Pinchart <[EMAIL PROTECTED]> --- arch/powerpc/platforms/Kconfig |2 + arch/powerpc/sysdev/cpm2.c | 11 arch/powerpc/sysdev/cpm_common.c | 123 + + include/asm-powerpc/cpm.h|3 + 4 files changed, 139 insertions(+), 0 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] cpm_uart: Add generic clock API support to set baudrates
On Jul 28, 2008, at 3:42 AM, Laurent Pinchart wrote: This patch introduces baudrate setting support via the generic clock API. When present the optional device tree clock property is used instead of fsl-cpm-brg. Platforms can then define complex clock schemes, to output the serial clock on an external pin for instance. Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]> --- drivers/serial/cpm_uart/cpm_uart.h |1 + drivers/serial/cpm_uart/cpm_uart_core.c | 26 ++ +--- 2 files changed, 20 insertions(+), 7 deletions(-) On Friday 25 July 2008, Kumar Gala wrote: I'm having problems applying due to mailer formatting. *sigh* I'll definitely have to fix GPG support in kmail. Sorry about the annoyance. np. applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2] cpm_uart: Modem control lines support
On Jul 24, 2008, at 11:36 AM, Laurent Pinchart wrote: This patch replaces the get_mctrl/set_mctrl stubs with modem control line read/write access through the GPIO lib. Available modem control lines are described in the device tree using GPIO bindings. The driver expect a GPIO pin for each of the CTS, RTS, DCD, DSR, DTR and RI signals. Unused control lines can be left out. Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]> --- Documentation/powerpc/booting-without-of.txt | 10 ++ drivers/serial/cpm_uart/cpm_uart.h | 10 ++ drivers/serial/cpm_uart/cpm_uart_core.c | 40 + +++-- 3 files changed, 57 insertions(+), 3 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC
On Jun 11, 2008, at 6:04 PM, Anton Vorontsov wrote: i8259 PIC is disabled on MPC8610HPCD boards, thus currently rtc-cmos driver fails to probe. To fix the issue, we lookup the device tree for "chrp,iic" and "pnpPNP,000" compatible devices, and if not found we do not assign RTC IRQ and assuming that i8259 was disabled. Though this patch fixes RTC on some boards (and surely should not break any other), the whole approach is still broken. We can't easily fix this though, because old device trees do not specify i8259 interrupts for the cmos rtc node. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/rtc_cmos_setup.c | 23 +-- 1 files changed, 17 insertions(+), 6 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'powerpc-next' branch (for 2.6.27)
Please pull from 'powerpc-next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next to receive the following updates: Sorry for taking so long on these. Being at OLS limited patch applying ability last week. These are some CPM related patches that have been on the list for some time and a fix to the RTC cmos detection need for the mpc8610ds board. - k Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt | 11 arch/powerpc/platforms/8xx/Kconfig | 10 arch/powerpc/platforms/Kconfig |2 arch/powerpc/sysdev/cpm1.c | 267 ++- arch/powerpc/sysdev/cpm2.c | 11 arch/powerpc/sysdev/cpm_common.c | 123 ++ arch/powerpc/sysdev/rtc_cmos_setup.c | 23 - drivers/serial/cpm_uart/cpm_uart.h | 11 drivers/serial/cpm_uart/cpm_uart_core.c | 66 +++ include/asm-powerpc/cpm.h|3 10 files changed, 506 insertions(+), 21 deletions(-) Anton Vorontsov (1): powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC Jochen Friedrich (1): powerpc: implement GPIO LIB API on CPM1 Freescale SoC. Laurent Pinchart (3): cpm2: Implement GPIO LIB API on CPM2 Freescale SoC. cpm_uart: Modem control lines support cpm_uart: Add generic clock API support to set baudrates ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
Karsten Keil wrote: [...] virt_to_bus() I never got a complain before and yes I already have some patches to solve the endian issues in the HFC driver, but it was not finaly Karsten, do you have those patches available somewhere ? I could give it a try on 4xx with a 4s card in the near future. Thanks Sinan Akman ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cpm2: Rework baud rate generators configuration to support external clocks.
On Jul 22, 2008, at 11:00 AM, Laurent Pinchart wrote: The CPM2 BRG setup functions cpm_setbrg and cpm2_fastbrg don't support external clocks. This patch adds a new exported __cpm2_setbrg function that takes the clock rate and clock source as extra parameters, and moves cpm_setbrg and cpm2_fastbrg to include/asm-powerpc/cpm2.h where they become inline wrappers around __cpm2_setbrg. Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/cpm2.c | 34 +++ include/asm-powerpc/cpm2.h | 46 ++ + 2 files changed, 37 insertions(+), 43 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'powerpc-next' branch (for 2.6.27)(updated)
Please pull from 'powerpc-next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next Laurent informed me I missed one CPM related patch: 'cpm2: Rework baud rate generators configuration to support external clocks.' - k to receive the following updates: Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt | 11 arch/powerpc/platforms/8xx/Kconfig | 10 arch/powerpc/platforms/Kconfig |3 arch/powerpc/sysdev/cpm1.c | 267 ++- arch/powerpc/sysdev/cpm2.c | 45 -- arch/powerpc/sysdev/cpm_common.c | 123 ++ arch/powerpc/sysdev/rtc_cmos_setup.c | 23 - drivers/serial/cpm_uart/cpm_uart.h | 11 drivers/serial/cpm_uart/cpm_uart_core.c | 66 +++ include/asm-powerpc/cpm.h|3 include/asm-powerpc/cpm2.h | 46 +- 11 files changed, 544 insertions(+), 64 deletions(-) Anton Vorontsov (1): powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC Jochen Friedrich (1): powerpc: implement GPIO LIB API on CPM1 Freescale SoC. Laurent Pinchart (4): cpm2: Implement GPIO LIB API on CPM2 Freescale SoC. cpm_uart: Modem control lines support cpm_uart: Add generic clock API support to set baudrates cpm2: Rework baud rate generators configuration to support external clocks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
On Sat, Jul 26, 2008 at 10:36:42PM +1000, Benjamin Herrenschmidt wrote: > On Sat, 2008-07-26 at 12:02 +0100, Hugh Dickins wrote: > > > > Hmm, perhaps it is doing sibling calls differently even without the > > explicit -fno-optimize-sibling-calls (but when I add that option, > > the vmlinux size does go up another 4400). > > > > Sorry, I'm most probably fussing over nothing, > > and wasting your time with my ignorance. > > No you aren't, there is indeed something happening. It looks like gcc is > keeping a copy of each stack frame in r31, thus forcing to save/restore > that register, along function calls, possibly to help get reliable > frames for leaf functions. I don't think we use that "feature" in our > backtrace code though... so it won't harm in the sense that it won't > break things, but it will indeed bloat the code a little bit. > > Maybe we should totally disable -fno-omit-frame-pointers on powerpc ... Yes. > either that or see about actually using that r31 linkage, though I'm not > sure it would be that useful. On PPC you can get reliable backtraces (modulo leaf functions, but AFAIR the frame pointer does not help, only the CFI data) without a frame pointer since the ABI makes the stack pointer chain easy to follow. The frame pointer (r31) is only necessary when there are variable size stack allocations, alloca() for example, but are they even allowed in the kernel? Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Changing Mac address
Hello all,
there's something I miss here. I'd like to setup a MAC address in software
at the start of the boot process. I'm trying to figure out where this is
done in the kernel code.
I'm on a custom variant of a Xilinx ML405 card, still in PPC arch.
So it appears to be going in the arch/ppc/boot/simple/embed_config.c piece
of code, but since I don't have I2C, the only 'relevant' code is this one:
#if (!defined(CONFIG_XILINX_MLxxx) || !defined(XPAR_IIC_0_BASEADDR) ||
!defined(XPAR_PERSISTENT_0_IIC_0_BASEADDR))
int get_cfg_data(unsigned char **cfg_data) {
#warning I2C needed for obtaining the Ethernet MAC address. Using hard-coded
MAC address
return 0; /* no cfg data found */
}
Nonetheless, ifconfig (from busybox) gives me a proper MAC address
(00:0A:35:01:02:03) and can even change it:
ifconfig eth0 down hw ether 00:0A:35:01:02:10 up
But I want to do that before the network is up.
What is the relevant kernel section to change in order to set the MAC
address ?
Thanks.
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
* Hugh Dickins <[EMAIL PROTECTED]> wrote: > [PATCH] sched: move sched_clock before first use > > Move sched_clock() up to stop warning: weak declaration of > `sched_clock' after first use results in unspecified behavior (if > -fno-unit-at-a-time). > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> applied to tip/sched/urgent - thanks Hugh. > I rather think CONFIG_FRAME_POINTER shouldn't exist at all (or be a > private, config-user-invisible, specific-to-a-few-arches thing): what > one wants to configure is how far to sacrifice cpu performance and > kernel smallness to getting a good stacktrace. Frame pointer is just > an implementation detail on that, appropriate to some arches. Perhaps > three settings: no stacktrace, fair stacktrace, best stacktrace. actually, we consciously use and rely on frame pointers on x86. The runtime cost on 64-bit is miniscule and the improved backtrace output in recent kernels makes backtraces _much_ easier to interpret: Call Trace: [] _raw_spin_trylock+0x19/0x50 [] _spin_lock_irqsave+0x59/0x90 [] atomic_notifier_chain_register+0x24/0x60 [] ? __profile_tick+0x58/0x90 [] nmi_watchdog_tick+0x59/0x1e0 [] default_do_nmi+0x6a/0x220 [] do_nmi+0x64/0xb0 [] nmi+0xa2/0xc2 [] ? stopmachine+0x61/0xd0 <> [] child_rip+0xa/0x11 [] ? restore_args+0x0/0x30 [] ? stopmachine+0x0/0xd0 [] ? child_rip+0x0/0x11 we experimented with using dwarf2 data in the past but it proved to be very fragile in practice - we depended too much on the whims of gcc/binutils being absolutely correct, etc. Something as fundamental to the kernel's general health as backtraces must not be fragile. So the EBP based backtracing code was ported to 64-bit as well and it was improved further upon. kudos to Arjan for that. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text]
On Mon, 28 Jul 2008, Ingo Molnar wrote: > * Hugh Dickins <[EMAIL PROTECTED]> wrote: > > > I rather think CONFIG_FRAME_POINTER shouldn't exist at all (or be a > > private, config-user-invisible, specific-to-a-few-arches thing): what > > one wants to configure is how far to sacrifice cpu performance and > > kernel smallness to getting a good stacktrace. Frame pointer is just > > an implementation detail on that, appropriate to some arches. Perhaps > > three settings: no stacktrace, fair stacktrace, best stacktrace. > > actually, we consciously use and rely on frame pointers on x86. The > runtime cost on 64-bit is miniscule and the improved backtrace output in > recent kernels makes backtraces _much_ easier to interpret: Just to clarify, no way was I criticizing the use of frame pointers on x86. What I don't care for is that CONFIG_FRAME_POINTER is used by common code (e.g. top level Makefile, and various debug Kconfigs), when I see it as an arch-specific technique for getting best stacktrace. Hugh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Monday 28 July 2008, Benjamin Herrenschmidt wrote: > On Mon, 2008-07-28 at 11:29 +1000, Benjamin Herrenschmidt wrote: > > The current ide-pmac upstream is broken. It calls > > media_bay_set_ide_infos() with an uninitialized "hwif" argument. > > > > It's not a trivial mistake, there's a chicken-and-egg problem in the > > init code in there. > > > > I've locally fixed it with this patch that i'll merge via the powerpc > > tree unless you have an objection. Fine with me (you may add my ACK) and thanks for fixing it. > > However, the machine crashes when removing the media-bay CD-ROM drive. > > > > Crash appears to be a NULL deref, possibly in elv_may_queue() though > > I don't have a clean backtrace yet, working on it... I wonder whether conversion from on-stack struct requests to allocated ones may have something to do with it (or not?)... > Here's a backtrace: > > Vector: 300 (Data Access) at [c58b7b80] > pc: c014f264: elv_may_queue+0x10/0x44 > lr: c0152750: get_request+0x2c/0x2c0 > sp: c58b7c30 >msr: 1032 >dar: c > dsisr: 4000 > current = 0xc58aaae0 > pid = 854, comm = media-bay > enter ? for help > mon> t > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > [c58b7e70] c0163650 kref_put+0x54/0x6c > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > [c58b7f00] c01e7424 device_del+0x104/0x198 > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > [c58b7fd0] c00485c0 kthread+0x48/0x84 > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: correctly hookup PTRACE_GET/SETVSRREGS for 32 bit processes
Fix bug where PTRACE_GET/SETVSRREGS are not connected for 32 bit processes. Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> --- arch/powerpc/kernel/ptrace32.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace32.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace32.c @@ -294,6 +294,8 @@ long compat_arch_ptrace(struct task_stru case PTRACE_SETFPREGS: case PTRACE_GETVRREGS: case PTRACE_SETVRREGS: + case PTRACE_GETVSRREGS: + case PTRACE_SETVSRREGS: case PTRACE_GETREGS64: case PTRACE_SETREGS64: case PPC_PTRACE_GETFPREGS: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] powerpc: VSX ptrace bug fixes for 2.6.27
Below are a few bug fixes for VSX ptrace for 2.6.27. Thanks to Luis Machado for helping find these with his VSX GDB work. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: fix setting the wrong thread_struct for ptrace get/set VSX regs
In PTRACE_GET/SETVSRREGS, we should be using the thread we are ptracing rather than current. Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> --- arch/powerpc/kernel/ptrace.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c @@ -374,7 +374,7 @@ static int vsr_get(struct task_struct *t flush_vsx_to_thread(target); for (i = 0; i < 32 ; i++) - buf[i] = current->thread.fpr[i][TS_VSRLOWOFFSET]; + buf[i] = target->thread.fpr[i][TS_VSRLOWOFFSET]; ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, buf, 0, 32 * sizeof(double)); @@ -393,7 +393,7 @@ static int vsr_set(struct task_struct *t ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, buf, 0, 32 * sizeof(double)); for (i = 0; i < 32 ; i++) - current->thread.fpr[i][TS_VSRLOWOFFSET] = buf[i]; + target->thread.fpr[i][TS_VSRLOWOFFSET] = buf[i]; return ret; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: fix ptrace buffer size for VSX
Fix cut-and-paste error in the size setting for ptrace buffers for VSX. Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> --- arch/powerpc/kernel/ptrace.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/ptrace.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/ptrace.c @@ -913,15 +913,13 @@ long arch_ptrace(struct task_struct *chi case PTRACE_GETVSRREGS: return copy_regset_to_user(child, &user_ppc_native_view, REGSET_VSX, - 0, (32 * sizeof(vector128) + - sizeof(u32)), + 0, 32 * sizeof(double), (void __user *) data); case PTRACE_SETVSRREGS: return copy_regset_from_user(child, &user_ppc_native_view, REGSET_VSX, -0, (32 * sizeof(vector128) + -sizeof(u32)), +0, 32 * sizeof(double), (const void __user *) data); #endif #ifdef CONFIG_SPE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote: > > It's all in: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge It doesn't really seem to be. I get "Already up-to-date.", and the top commit there seems to be from July 3.. Forgot to push? > (Hopefully no silly non-printable character this time, at least > nothing I manage to spot with evo but who knows...) Yeah, no odd whitespace here either. Not that it helps ;) Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
Hi Linus, On Mon, 28 Jul 2008 08:40:44 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote: > > > > It's all in: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge > > It doesn't really seem to be. I get "Already up-to-date.", and the top > commit there seems to be from July 3.. > > Forgot to push? It should be git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Ben seems to have copied from one of Paul's pull requests. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpswHK2SQX9a.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Tue, 29 Jul 2008, Stephen Rothwell wrote: > > It should be > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > > Ben seems to have copied from one of Paul's pull requests. Ok, that one worked for me. Ben, I'm sure some day you'll get it right on the first try. We're all cheering for you! Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mpc8349-mITX DTB load failure
Hello All, I am trying to boot the mpc8349-mITX board with Compact flash support, and am unable to boot the Linux kernel. Here is the pertinant versioning information: DTC 1.2.0-rc2-g17773b0e U-Boot 1.3.4-rc1-00012-g1953d12 Linux-2.6.26-05752-g93ded9b I've built the DTB using the following two commands - neither change the error I get during boot-up. $ ../dtc/dtc -b 0 -I dts -O dtb -R 4 -S 0x3000 -o /tftproot/ssparks/itx/cf2/itx.dtb -V 17 arch/powerpc/boot/dts/mpc8349emitx.dts $ ../dtc/dtc -I dts -O dtb -o /tftproot/ssparks/itx/cf2/itx2.dtb arch/powerpc/boot/dts/mpc8349emitx.dts Can anyone shed any light onto what I am doing to cause the following error? I haven't been able to find this error message in the mailing list or by asking google... ## Booting kernel from Legacy Image at 01001000 ... Image Name: Linux-2.6.26-05752-g93ded9b Created: 2008-07-24 20:40:59 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1708661 Bytes = 1.6 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Flattened Device Tree blob at 0100 Booting using the fdt blob at 0x100 Loading Device Tree to 007fb000, end 007ff526 ... OK WARNING: could not create /chosen FDT_ERR_BADSTRUCTURE. ERROR: /chosen node create failed - must RESET the board to recover. Resetting the board. Thanks for the help, Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Mon, Jul 28, 2008 at 09:06:35AM -0700, Linus Torvalds wrote: > > > On Tue, 29 Jul 2008, Stephen Rothwell wrote: > > > > It should be > > > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > > > > Ben seems to have copied from one of Paul's pull requests. > > Ok, that one worked for me. > > Ben, I'm sure some day you'll get it right on the first try. We're all > cheering for you! Ben! Ben! He's our man! If he can't grok it, no-one can! :-) git-request-pull has saved me from many a bogus pull request. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Changing Mac address
On Mon, Jul 28, 2008 at 04:25:54PM +0200, Guillaume Dargaud wrote: > Hello all, > there's something I miss here. I'd like to setup a MAC address in > software at the start of the boot process. I'm trying to figure out where > this is done in the kernel code. > I'm on a custom variant of a Xilinx ML405 card, still in PPC arch. > So it appears to be going in the arch/ppc/boot/simple/embed_config.c Yes, this is the correct location to set it. Do whatever you need to set a different MAC address. In arch/powerpc this all goes away and you can just set it in the device tree. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
. . .
> Come to think of it, I'd support just removing the zImage symlink
> entirely to eliminate confusion so that everyone knows that 'make
> zImage' is the 'make all' for default image targets.
That ("zImage" means all default image targets) seems pretty non-intui-
tive; why not something like 'make all_def_images'?
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
XAgainst HTML | at 'email.mot.com'
/ \ in e-mail & news |
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 0/4 REPOST] OF infrastructure for SPI devices
On Sun, Jul 27, 2008 at 02:49:28PM -0700, David Brownell wrote: > On Friday 25 July 2008, Grant Likely wrote: > > I don't know what to do with these patches. Â I'd really like to see them > > in .27, and now that akpm has cleared his queue, the prerequisite patch > > has been merged so they are ready to go in. Â However, even though there > > has been favourable reception on the SPI and linuxppc lists for these > > changes I don't have any acks from anybody yet. > > > > David, can you please reply on if you are okay with these patches > > getting merged? Â If so, do you want me to merge them via my tree, or > > do you want to pick them up? > > OK ... to recap, #1 and #3 are OF-specific, I'll be agnostic. > If other OF folk think it's OK, great. > > Some cleanup was needed for #2, but it was basically ok ... > I'd like to see the final version, and if it goes via an > OF push that's OK by me. (Though I'd like to see that change > make it into 2.6.27 regardless, so let me know.) Thanks for the review. 1-3 is already merged into my git tree and Ben has pulled them. I hope that's okay. Here's a link to the commit: http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=dc87c98e8f635a718f1abb2c3e15fc77c0001651 Let me know if you see anything else that needs to be changed and I'll submit a fixup patch. > And #4 isn't quite cooked yet. Okay, I'll hack on this more and post v4. Thanks again, g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC,PATCH] scripts/package: add powerpc images to tarball
On Mon, Jul 28, 2008 at 11:34:35AM -0500, T Ziomek wrote:
> On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
> . . .
> > Come to think of it, I'd support just removing the zImage symlink
> > entirely to eliminate confusion so that everyone knows that 'make
> > zImage' is the 'make all' for default image targets.
>
> That ("zImage" means all default image targets) seems pretty non-intui-
> tive; why not something like 'make all_def_images'?
It is purely historical. zImage and modules have been the default
make targets for a long time. I'm not opposed to changing it, but it is
a change that affects almost everyone. I'd like to see some consensus
before going down this path.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Mon, Jul 28, 2008 at 01:31:47AM -0700, Trent Piepho wrote: > On Sat, 26 Jul 2008, Grant Likely wrote: > > On Fri, Jul 25, 2008 at 02:01:45PM -0700, Trent Piepho wrote: > >> Add bindings to support LEDs defined as of_platform devices in addition to > >> the existing bindings for platform devices. > > > >> +- gpios : Should specify the LED GPIO. > > > > Question: it is possible/desirable for a single LED to be assigned > > multiple GPIO pins? Say, for a tri-color LED? (I'm fishing for > > opinions; I really don't know if it would be a good idea or not) > > Good question. The Linux LED layer has no concept of multi-color LEDs, so > it's more difficult that just adding support to the gpio led driver. I have > a device with a tri-color red/green/orange LED and this posed some > difficulty. It's defined as independent red and greed LEDs, which is mostly > fine, except I wanted it to flash orange. I can make both the red LED and > green LED flash, but there is nothing to insure their flashing remains in > sync. > > Other OF bindings allow multiple GPIOs to be listed in a gpios property, so > that's not a problem if someone wants to do that. There would need to be a > way to define what the gpios mean. I don't think it's worthwhile to come up > with a binding for that until there is a real user. True. The binding can be extended at a later date anyway. It might be as simple as adding an array of strings that define what each gpio value means. ie. if 2 gpio lines are used for a led, then that maps to numbers in the range [0, 1, 2, 3]. It could be encoded thus: led-states = "off", "green", "red", "orange"; The driver would then need to interpret/adapt these strings to something useful in the LED driver. Just a thought. > >> +- function : (optional) This parameter, if present, is a string > >> + defining the function of the LED. It can be used to put the LED > >> + under software control, e.g. Linux LED triggers like "heartbeat", > >> + "ide-disk", and "timer". Or it could be used to attach a hardware > >> + signal to the LED, e.g. a SoC that can configured to put a SATA > >> + activity signal on a GPIO line. > > > > This makes me nervous. It exposes Linux internal implementation details > > into the device tree data. If you want to have a property that > > describes the LED usage, then the possible values and meanings should be > > documented here. > > Should it be a linux specific property then? I could list all the current > linux triggers, but enumerating every possible function someone might want > to assign to an LED seems hopeless. I don't like adding Linux specific properties to the device tree if at all possible, and I really don't like encoding Linux internal details (like trigger names). They can change between kernel versions and breaking compatibility with older device trees is strongly avoided. That's why so much effort goes into getting bindings correct the first time. I'd rather see the device tree provide 'hints' toward the expected usage and if a platform needs something specific, then the platform specific code should setup the trigger. Regardless, any hints provided by the binding must be documented. In most cases the gpio-leds driver should be able to figure out which trigger to bind without platform code intervention. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8349-mITX DTB load failure
On Mon, Jul 28, 2008 at 11:10:47AM -0500, Sparks, Sam wrote: > Hello All, > > I am trying to boot the mpc8349-mITX board with Compact flash support, > and am unable to boot the Linux kernel. Here is the pertinant versioning > information: > DTC 1.2.0-rc2-g17773b0e > U-Boot 1.3.4-rc1-00012-g1953d12 > Linux-2.6.26-05752-g93ded9b > > I've built the DTB using the following two commands - neither change the > error I get during boot-up. > $ ../dtc/dtc -b 0 -I dts -O dtb -R 4 -S 0x3000 -o > /tftproot/ssparks/itx/cf2/itx.dtb -V 17 > arch/powerpc/boot/dts/mpc8349emitx.dts > $ ../dtc/dtc -I dts -O dtb -o /tftproot/ssparks/itx/cf2/itx2.dtb > arch/powerpc/boot/dts/mpc8349emitx.dts Try adding "-p 0x3000" to ensure that you get padding to the blob. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: mpc8349-mITX DTB load failure
> From: Grant Likely > Sent: Monday, July 28, 2008 12:17 PM > > On Mon, Jul 28, 2008 at 11:10:47AM -0500, Sparks, Sam wrote: > > Hello All, > > > > I am trying to boot the mpc8349-mITX board with Compact > flash support, > > and am unable to boot the Linux kernel. Here is the pertinant > > versioning > > information: > > DTC 1.2.0-rc2-g17773b0e > > U-Boot 1.3.4-rc1-00012-g1953d12 > > Linux-2.6.26-05752-g93ded9b > > > > I've built the DTB using the following two commands - > neither change > > the error I get during boot-up. > > $ ../dtc/dtc -b 0 -I dts -O dtb -R 4 -S 0x3000 -o > > /tftproot/ssparks/itx/cf2/itx.dtb -V 17 > > arch/powerpc/boot/dts/mpc8349emitx.dts > > $ ../dtc/dtc -I dts -O dtb -o /tftproot/ssparks/itx/cf2/itx2.dtb > > arch/powerpc/boot/dts/mpc8349emitx.dts > > Try adding "-p 0x3000" to ensure that you get padding to the blob. > > g. > No luck there, either. I ran into a issue with space a year ago, and was getting the FDT_ERR_NOSPACE error until I added the -S 0x3000 option. This looks like something completely different. Thanks tho, Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
[...]
> > >> +- function : (optional) This parameter, if present, is a string
> > >> + defining the function of the LED. It can be used to put the LED
> > >> + under software control, e.g. Linux LED triggers like "heartbeat",
> > >> + "ide-disk", and "timer". Or it could be used to attach a hardware
> > >> + signal to the LED, e.g. a SoC that can configured to put a SATA
> > >> + activity signal on a GPIO line.
> > >
> > > This makes me nervous. It exposes Linux internal implementation details
> > > into the device tree data. If you want to have a property that
> > > describes the LED usage, then the possible values and meanings should be
> > > documented here.
> >
> > Should it be a linux specific property then? I could list all the current
> > linux triggers, but enumerating every possible function someone might want
> > to assign to an LED seems hopeless.
>
> I don't like adding Linux specific properties to the device tree if at
> all possible, and I really don't like encoding Linux internal details
> (like trigger names). They can change between kernel versions and
> breaking compatibility with older device trees is strongly avoided.
> That's why so much effort goes into getting bindings correct the first
> time.
>
> I'd rather see the device tree provide 'hints' toward the expected usage
> and if a platform needs something specific, then the platform specific
> code should setup the trigger.
>
> Regardless, any hints provided by the binding must be documented. In
> most cases the gpio-leds driver should be able to figure out which trigger
> to bind without platform code intervention.
Maybe we can encode leds into devices themselves, via phandles?
E.g.
[EMAIL PROTECTED] {
compatible = "fsl,sata";
leds = <&red_led>;
};
And then the OF GPIO LEDs driver could do something like:
char *ide_disk_trigger_compatibles[] = {
"fsl,sata",
"ide-generic",
...
};
for_each_node_with_leds_property(node, led_phandle) {
if (if_ide_disk_compatible(node)) {
struct gpio_led *led = phandle_to_led(led_phandle);
led->default_trigger = "ide-disk";
}
}
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8349-mITX DTB load failure
On Mon, Jul 28, 2008 at 12:49:19PM -0500, Sparks, Sam wrote: > No luck there, either. I ran into a issue with space a year ago, and was > getting the FDT_ERR_NOSPACE error until I added the -S 0x3000 option. > This looks like something completely different. Does your dts source file already have a chosen node? There had been an issue where u-boot cacks if chosen was pre-created. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Mon, Jul 28, 2008 at 10:02:04PM +0400, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > I'd rather see the device tree provide 'hints' toward the expected usage
> > and if a platform needs something specific, then the platform specific
> > code should setup the trigger.
> >
> > Regardless, any hints provided by the binding must be documented. In
> > most cases the gpio-leds driver should be able to figure out which trigger
> > to bind without platform code intervention.
>
> Maybe we can encode leds into devices themselves, via phandles?
>
> E.g.
>
> [EMAIL PROTECTED] {
> compatible = "fsl,sata";
> leds = <&red_led>;
> };
I like that idea! That neatly solves the problem for many use cases.
> And then the OF GPIO LEDs driver could do something like:
>
> char *ide_disk_trigger_compatibles[] = {
> "fsl,sata",
> "ide-generic",
> ...
> };
>
> for_each_node_with_leds_property(node, led_phandle) {
> if (if_ide_disk_compatible(node)) {
> struct gpio_led *led = phandle_to_led(led_phandle);
>
> led->default_trigger = "ide-disk";
> }
> }
I'm not sure what would be best for implementation details, but
implementation details can easily be changed.
>
> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: mpc8349-mITX DTB load failure
> From: Grant Likely > Sent: Monday, July 28, 2008 1:03 PM > Does your dts source file already have a chosen node? There > had been an issue where u-boot cacks if chosen was pre-created. Nope, there is no reference to "chosen" in the dts --Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8349-mITX DTB load failure
On Mon, 28 Jul 2008 11:10:47 -0500 "Sparks, Sam" <[EMAIL PROTECTED]> wrote: > ## Booting kernel from Legacy Image at 01001000 ... > ## Flattened Device Tree blob at 0100 so the dtb is being loaded only 0x1000 bytes from the kernel, yet it's probably bigger than that. Can you try different load addresses, preferably with the two images at least 0x3000 bytes apart? Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> [...]
> +- function : (optional) This parameter, if present, is a string
> + defining the function of the LED. It can be used to put the LED
> + under software control, e.g. Linux LED triggers like "heartbeat",
> + "ide-disk", and "timer". Or it could be used to attach a hardware
> + signal to the LED, e.g. a SoC that can configured to put a SATA
> + activity signal on a GPIO line.
This makes me nervous. It exposes Linux internal implementation details
into the device tree data. If you want to have a property that
describes the LED usage, then the possible values and meanings should be
documented here.
>>>
>>> Should it be a linux specific property then? I could list all the current
>>> linux triggers, but enumerating every possible function someone might want
>>> to assign to an LED seems hopeless.
>>
>> I'd rather see the device tree provide 'hints' toward the expected usage
>> and if a platform needs something specific, then the platform specific
>> code should setup the trigger.
>>
> Maybe we can encode leds into devices themselves, via phandles?
How will this work for anything besides ide activity? For example, flashing,
heartbeat, default on, overheat, fan failed, kernel panic, etc.
> And then the OF GPIO LEDs driver could do something like:
>
> char *ide_disk_trigger_compatibles[] = {
> "fsl,sata",
> "ide-generic",
> ...
> };
Everytime someone added a new ide driver, this table would have to be updated.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC8323RDB BSP on Kernel2.4
Hi All, Is the any MPC8323RDB BSP on Kernel 2.4? I have the BSP on Kernel 2.6 provided by Freescale. Unfortunate we are using Kernel2.4. Is there any exist BSP of this board on Kernel2.4? Or a BSP of similar board on Kernel2.4? Thanks in advance, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Documentation: remove old sbc8260 board specific information
This file contains 8 yr. old board specific information that was for the now gone ppc implementation, and it pre-dates widespread u-boot support. Any of the technical details of the board memory map would be more appropriately captured in a dts if I revive it as powerpc anyway. Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]> Acked-by: Jason Wessel <[EMAIL PROTECTED]> --- Documentation/powerpc/00-INDEX |2 - Documentation/powerpc/SBC8260_memory_mapping.txt | 197 -- 2 files changed, 0 insertions(+), 199 deletions(-) delete mode 100644 Documentation/powerpc/SBC8260_memory_mapping.txt diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 3be84aa..29d839c 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX @@ -20,8 +20,6 @@ mpc52xx-device-tree-bindings.txt - MPC5200 Device Tree Bindings ppc_htab.txt - info about the Linux/PPC /proc/ppc_htab entry -SBC8260_memory_mapping.txt - - EST SBC8260 board info smp.txt - use and state info about Linux/PPC on MP machines sound.txt diff --git a/Documentation/powerpc/SBC8260_memory_mapping.txt b/Documentation/powerpc/SBC8260_memory_mapping.txt deleted file mode 100644 index e6e9ee0..000 --- a/Documentation/powerpc/SBC8260_memory_mapping.txt +++ /dev/null @@ -1,197 +0,0 @@ -Please mail me (Jon Diekema, [EMAIL PROTECTED] or [EMAIL PROTECTED]) -if you have questions, comments or corrections. - - * EST SBC8260 Linux memory mapping rules - - http://www.estc.com/ - http://www.estc.com/products/boards/SBC8260-8240_ds.html - - Initial conditions: - --- - - Tasks that need to be perform by the boot ROM before control is - transferred to zImage (compressed Linux kernel): - - - Define the IMMR to 0xf000 - - - Initialize the memory controller so that RAM is available at - physical address 0x. On the SBC8260 is this 16M (64M) - SDRAM. - - - The boot ROM should only clear the RAM that it is using. - - The reason for doing this is to enhances the chances of a - successful post mortem on a Linux panic. One of the first - items to examine is the 16k (LOG_BUF_LEN) circular console - buffer called log_buf which is defined in kernel/printk.c. - - - To enhance boot ROM performance, the I-cache can be enabled. - - Date: Mon, 22 May 2000 14:21:10 -0700 - From: Neil Russell <[EMAIL PROTECTED]> - - LiMon (LInux MONitor) runs with and starts Linux with MMU - off, I-cache enabled, D-cache disabled. The I-cache doesn't - need hints from the MMU to work correctly as the D-cache - does. No D-cache means no special code to handle devices in - the presence of cache (no snooping, etc). The use of the - I-cache means that the monitor can run acceptably fast - directly from ROM, rather than having to copy it to RAM. - - - Build the board information structure (see - include/asm-ppc/est8260.h for its definition) - - - The compressed Linux kernel (zImage) contains a bootstrap loader - that is position independent; you can load it into any RAM, - ROM or FLASH memory address >= 0x0050 (above 5 MB), or - at its link address of 0x0040 (4 MB). - - Note: If zImage is loaded at its link address of 0x0040 (4 MB), - then zImage will skip the step of moving itself to - its link address. - - - Load R3 with the address of the board information structure - - - Transfer control to zImage - - - The Linux console port is SMC1, and the baud rate is controlled - from the bi_baudrate field of the board information structure. - On thing to keep in mind when picking the baud rate, is that - there is no flow control on the SMC ports. I would stick - with something safe and standard like 19200. - - On the EST SBC8260, the SMC1 port is on the COM1 connector of - the board. - - - EST SBC8260 defaults: - - - -Chip -Memory Sel Bus Use -- --- --- -- - 0x-0x03FF CS2 60x (16M or 64M)/64M SDRAM - 0x0400-0x04FF CS4 local 4M/16M SDRAM (soldered to the board) - 0x2100-0x2100 CS7 60x1B/64K Flash present detect (from the flash SIMM) - 0x2101-0x2101 CS7 60x1B/64K Switches (read) and LEDs (write) - 0x2200-0x2200 CS5 60x8K/64K EEPROM - 0xFC00-0xFCFF CS6 60x2M/16M flash (8 bits wide, soldered to the board) - 0xFE00-0x CS0 60x4M/16M flash (SIMM) - - Notes: - -- - - - The chip selects can map 3
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> > On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > [...]
> > +- function : (optional) This parameter, if present, is a string
> > + defining the function of the LED. It can be used to put the LED
> > + under software control, e.g. Linux LED triggers like "heartbeat",
> > + "ide-disk", and "timer". Or it could be used to attach a hardware
> > + signal to the LED, e.g. a SoC that can configured to put a SATA
> > + activity signal on a GPIO line.
>
> This makes me nervous. It exposes Linux internal implementation details
> into the device tree data. If you want to have a property that
> describes the LED usage, then the possible values and meanings should be
> documented here.
> >>>
> >>> Should it be a linux specific property then? I could list all the current
> >>> linux triggers, but enumerating every possible function someone might want
> >>> to assign to an LED seems hopeless.
> >>
> >> I'd rather see the device tree provide 'hints' toward the expected usage
> >> and if a platform needs something specific, then the platform specific
> >> code should setup the trigger.
> >>
> > Maybe we can encode leds into devices themselves, via phandles?
>
> How will this work for anything besides ide activity? For example, flashing,
> heartbeat, default on, overheat, fan failed, kernel panic, etc.
It certainly doesn't work for everything; but where it does work it
makes a lot of sense because the property position provides a lot of
context.
>
> > And then the OF GPIO LEDs driver could do something like:
> >
> > char *ide_disk_trigger_compatibles[] = {
> > "fsl,sata",
> > "ide-generic",
> > ...
> > };
>
> Everytime someone added a new ide driver, this table would have to be updated.
Yes, the implementation needs thought.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> > On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
> > [...]
> > +- function : (optional) This parameter, if present, is a string
> > + defining the function of the LED. It can be used to put the LED
> > + under software control, e.g. Linux LED triggers like "heartbeat",
> > + "ide-disk", and "timer". Or it could be used to attach a hardware
> > + signal to the LED, e.g. a SoC that can configured to put a SATA
> > + activity signal on a GPIO line.
>
> This makes me nervous. It exposes Linux internal implementation details
> into the device tree data. If you want to have a property that
> describes the LED usage, then the possible values and meanings should be
> documented here.
> >>>
> >>> Should it be a linux specific property then? I could list all the current
> >>> linux triggers, but enumerating every possible function someone might want
> >>> to assign to an LED seems hopeless.
> >>
> >> I'd rather see the device tree provide 'hints' toward the expected usage
> >> and if a platform needs something specific, then the platform specific
> >> code should setup the trigger.
> >>
> > Maybe we can encode leds into devices themselves, via phandles?
>
> How will this work for anything besides ide activity? For example, flashing,
> heartbeat, default on, overheat, fan failed, kernel panic, etc.
Everything is possible, but will look weird. For example,
Default on (power led) could be encoded in the root node.
fan and overheat in a PM controller's node.
Kernel panic in the chosen node.
> > And then the OF GPIO LEDs driver could do something like:
> >
> > char *ide_disk_trigger_compatibles[] = {
> > "fsl,sata",
> > "ide-generic",
> > ...
> > };
>
> Everytime someone added a new ide driver, this table would have to be updated.
Yes. device_type would be helpful here. :-)
Well, otherwise, we could provide a trigger map in the chosen node:
chosen {
/* leds map: default-on, ide-disk, nand-disk, panic */
linux,leds = <&green_led &red_led 0 0>;
};
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8323RDB BSP on Kernel2.4
On Mon, Jul 28, 2008 at 2:44 PM, mike zheng <[EMAIL PROTECTED]> wrote: > Hi All, > > Is the any MPC8323RDB BSP on Kernel 2.4? I have the BSP on Kernel 2.6 > provided by Freescale. Unfortunate we are using Kernel2.4. Is there > any exist BSP of this board on Kernel2.4? Or a BSP of similar board on > Kernel2.4? Generally speaking, most of these more modern eval boards from Freescale have been supported only since post 2.6.15 or so, and as such are implemented as arch/powerpc and not the older/obsolete arch/ppc (as what was used in 2.4). Trying to graft them onto a 2.4 kernel sounds like a lot of wasted cycles to me. You may have to revisit your reasoning for requiring a 2.4 kernel. Paul. > > Thanks in advance, > > Mike > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] leds: Support OpenFirmware led bindings
On Mon, 28 Jul 2008, Anton Vorontsov wrote:
> On Mon, Jul 28, 2008 at 11:26:28AM -0700, Trent Piepho wrote:
>> On Mon, 28 Jul 2008, Anton Vorontsov wrote:
>>> On Mon, Jul 28, 2008 at 11:09:14AM -0600, Grant Likely wrote:
>>> [...]
>>> +- function : (optional) This parameter, if present, is a string
>>> + defining the function of the LED. It can be used to put the LED
>>> + under software control, e.g. Linux LED triggers like "heartbeat",
>>> + "ide-disk", and "timer". Or it could be used to attach a hardware
>>> + signal to the LED, e.g. a SoC that can configured to put a SATA
>>> + activity signal on a GPIO line.
>>
>> This makes me nervous. It exposes Linux internal implementation details
>> into the device tree data. If you want to have a property that
>> describes the LED usage, then the possible values and meanings should be
>> documented here.
>
> Should it be a linux specific property then? I could list all the current
> linux triggers, but enumerating every possible function someone might want
> to assign to an LED seems hopeless.
I'd rather see the device tree provide 'hints' toward the expected usage
and if a platform needs something specific, then the platform specific
code should setup the trigger.
>>> Maybe we can encode leds into devices themselves, via phandles?
>>
>> How will this work for anything besides ide activity? For example, flashing,
>> heartbeat, default on, overheat, fan failed, kernel panic, etc.
>
> Everything is possible, but will look weird. For example,
>
> Default on (power led) could be encoded in the root node.
> fan and overheat in a PM controller's node.
> Kernel panic in the chosen node.
What about flashing? What if the sensor chip isn't an OF device?
>>> And then the OF GPIO LEDs driver could do something like:
>>>
>>> char *ide_disk_trigger_compatibles[] = {
>>> "fsl,sata",
>>> "ide-generic",
>>> ...
>>> };
>>
>> Everytime someone added a new ide driver, this table would have to be
>> updated.
>
> Yes. device_type would be helpful here. :-)
>
>
> Well, otherwise, we could provide a trigger map in the chosen node:
>
> chosen {
> /* leds map: default-on, ide-disk, nand-disk, panic */
> linux,leds = <&green_led &red_led 0 0>;
> };
What if you have multiple leds that you want to be default on? What happens
when new functions are added?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
Certain workloads benefit if their data or text segments are backed by huge pages. The stack is no exception to this rule but there is no mechanism currently that allows the backing of a stack reliably with huge pages. Doing this from userspace is excessively messy and has some awkward restrictions. Particularly on POWER where 256MB of address space gets wasted if the stack is setup there. This patch stack introduces a personality flag that indicates the kernel should setup the stack as a hugetlbfs-backed region. A userspace utility may set this flag then exec a process whose stack is to be backed by hugetlb pages. Eric Munson (5): Align stack boundaries based on personality Add shared and reservation control to hugetlb_file_setup Split boundary checking from body of do_munmap Build hugetlb backed process stacks [PPC] Setup stack memory segment for hugetlb pages arch/powerpc/mm/hugetlbpage.c |6 + arch/powerpc/mm/slice.c | 11 ++ fs/exec.c | 209 ++--- fs/hugetlbfs/inode.c | 52 +++ include/asm-powerpc/hugetlb.h |3 + include/linux/hugetlb.h | 22 - include/linux/mm.h|1 + include/linux/personality.h |3 + ipc/shm.c |2 +- mm/mmap.c | 11 ++- 10 files changed, 284 insertions(+), 36 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/5 V2] Build hugetlb backed process stacks
This patch allows a processes stack to be backed by huge pages on request.
The personality flag defined in a previous patch should be set before
exec is called for the target process to use a huge page backed stack.
When the hugetlb file is setup to back the stack it is sized to fit the
ulimit for stack size or 256 MB if ulimit is unlimited. The GROWSUP and
GROWSDOWN VM flags are turned off because a hugetlb backed vma is not
resizable so it will be appropriately sized when created. When a process
exceeds stack size it recieves a segfault as it would if it exceeded the
ulimit.
Also certain architectures require special setup for a memory region before
huge pages can be used in that region. This patch defines a function with
__attribute__ ((weak)) set that can be defined by these architectures to
do any necessary setup. If it exists, it will be called right before the
hugetlb file is mmapped.
Signed-off-by: Eric Munson <[EMAIL PROTECTED]>
---
Based on 2.6.26-rc8-mm1
Changes from V1:
Add comment about not padding huge stacks
Break personality_page_align helper and personality flag into separate patch
Add move_to_huge_pages function that moves the stack onto huge pages
Add hugetlb_mm_setup weak function for archs that require special setup to
use hugetlb pages
Rebase to 2.6.26-rc8-mm1
fs/exec.c | 194 ---
include/linux/hugetlb.h |5 +
2 files changed, 187 insertions(+), 12 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index c99ba24..bf9ead2 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
#include
@@ -59,6 +60,8 @@
#include
#endif
+#define HUGE_STACK_MAX (256*1024*1024)
+
#ifdef __alpha__
/* for /sbin/loader handling in search_binary_handler() */
#include
@@ -189,7 +192,12 @@ static struct page *get_arg_page(struct linux_binprm
*bprm, unsigned long pos,
return NULL;
if (write) {
- unsigned long size = bprm->vma->vm_end - bprm->vma->vm_start;
+ /*
+* Args are always placed at the high end of the stack space
+* so this calculation will give the proper size and it is
+* compatible with huge page stacks.
+*/
+ unsigned long size = bprm->vma->vm_end - pos;
struct rlimit *rlim;
/*
@@ -255,7 +263,10 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
* configured yet.
*/
vma->vm_end = STACK_TOP_MAX;
- vma->vm_start = vma->vm_end - PAGE_SIZE;
+ if (current->personality & HUGETLB_STACK)
+ vma->vm_start = vma->vm_end - HPAGE_SIZE;
+ else
+ vma->vm_start = vma->vm_end - PAGE_SIZE;
vma->vm_flags = VM_STACK_FLAGS;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
@@ -574,6 +585,156 @@ static int shift_arg_pages(struct vm_area_struct *vma,
unsigned long shift)
return 0;
}
+static struct file *hugetlb_stack_file(int stack_hpages)
+{
+ struct file *hugefile = NULL;
+
+ if (!stack_hpages) {
+ set_personality(current->personality & (~HUGETLB_STACK));
+ printk(KERN_DEBUG
+ "Stack rlimit set too low for huge page backed
stack.\n");
+ return NULL;
+ }
+
+ hugefile = hugetlb_file_setup(HUGETLB_STACK_FILE,
+ HPAGE_SIZE * stack_hpages,
+ HUGETLB_PRIVATE_INODE);
+ if (unlikely(IS_ERR(hugefile))) {
+ /*
+* If huge pages are not available for this stack fall
+* fall back to normal pages for execution instead of
+* failing.
+*/
+ printk(KERN_DEBUG
+ "Huge page backed stack unavailable for process %lu.\n",
+ (unsigned long)current->pid);
+ set_personality(current->personality & (~HUGETLB_STACK));
+ return NULL;
+ }
+ return hugefile;
+}
+
+static int move_to_huge_pages(struct linux_binprm *bprm,
+ struct vm_area_struct *vma, unsigned long shift)
+{
+ struct mm_struct *mm = vma->vm_mm;
+ struct vm_area_struct *new_vma;
+ unsigned long old_end = vma->vm_end;
+ unsigned long old_start = vma->vm_start;
+ unsigned long new_end = old_end - shift;
+ unsigned long new_start, length;
+ unsigned long arg_size = new_end - bprm->p;
+ unsigned long flags = vma->vm_flags;
+ struct file *hugefile = NULL;
+ unsigned int stack_hpages = 0;
+ struct page **from_pages = NULL;
+ struct page **to_pages = NULL;
+ unsigned long num_pages = (arg_size / PAGE_SIZE) + 1;
+ int ret;
+ int i;
+
+#ifdef CONFIG_STACK_GROWSUP
+ /*
+* Huge page stacks are not currently supporte
[PATCH 1/5 V2] Align stack boundaries based on personality
This patch adds a personality flag that requests hugetlb pages be used for
a processes stack. It adds a helper function that chooses the proper ALIGN
macro based on tthe process personality and calls this function from
setup_arg_pages when aligning the stack address.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Signed-off-by: Eric Munson <[EMAIL PROTECTED]>
---
Based on 2.6.26-rc8-mm1
Changes from V1:
Rebase to 2.6.26-rc8-mm1
fs/exec.c | 15 ++-
include/linux/hugetlb.h |3 +++
include/linux/personality.h |3 +++
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index af9b29c..c99ba24 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
#include
@@ -155,6 +156,18 @@ exit:
goto out;
}
+static unsigned long personality_page_align(unsigned long addr)
+{
+ if (current->personality & HUGETLB_STACK)
+#ifdef CONFIG_STACK_GROWSUP
+ return HPAGE_ALIGN(addr);
+#else
+ return addr & HPAGE_MASK;
+#endif
+
+ return PAGE_ALIGN(addr);
+}
+
#ifdef CONFIG_MMU
static struct page *get_arg_page(struct linux_binprm *bprm, unsigned long pos,
@@ -596,7 +609,7 @@ int setup_arg_pages(struct linux_binprm *bprm,
bprm->p = vma->vm_end - stack_shift;
#else
stack_top = arch_align_stack(stack_top);
- stack_top = PAGE_ALIGN(stack_top);
+ stack_top = personality_page_align(stack_top);
stack_shift = vma->vm_end - stack_top;
bprm->p -= stack_shift;
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 9a71d4c..eed37d7 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -95,6 +95,9 @@ static inline unsigned long hugetlb_total_pages(void)
#ifndef HPAGE_MASK
#define HPAGE_MASK PAGE_MASK /* Keep the compiler happy */
#define HPAGE_SIZE PAGE_SIZE
+
+/* to align the pointer to the (next) huge page boundary */
+#define HPAGE_ALIGN(addr) ALIGN(addr, HPAGE_SIZE)
#endif
#endif /* !CONFIG_HUGETLB_PAGE */
diff --git a/include/linux/personality.h b/include/linux/personality.h
index a84e9ff..2bb0f95 100644
--- a/include/linux/personality.h
+++ b/include/linux/personality.h
@@ -22,6 +22,9 @@ extern int__set_personality(unsigned long);
* These occupy the top three bytes.
*/
enum {
+ HUGETLB_STACK = 0x002, /* Attempt to use hugetlb pages
+* for the process stack
+*/
ADDR_NO_RANDOMIZE = 0x004, /* disable randomization of VA
space */
FDPIC_FUNCPTRS =0x008, /* userspace function ptrs
point to descriptors
* (signal handling)
--
1.5.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/5] Split boundary checking from body of do_munmap
Currently do_unmap pre-checks the unmapped address range against the
valid address range for the process size. However during initial setup
the stack may actually be outside this range, particularly it may be
initially placed at the 64 bit stack address and later moved to the
normal 32 bit stack location. In a later patch we will want to unmap
the stack as part of relocating it into huge pages.
This patch moves the bulk of do_munmap into __do_munmap which will not
be protected by the boundary checking. When an area that would normally
fail at these checks needs to be unmapped (e.g. unmapping a stack that
was setup at 64 bit TASK_SIZE for a 32 bit process) __do_munmap should
be called directly. do_munmap will continue to do the boundary checking
and will call __do_munmap as appropriate.
Signed-off-by: Eric Munson <[EMAIL PROTECTED]>
---
Based on 2.6.26-rc8-mm1
include/linux/mm.h |1 +
mm/mmap.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a4eeb3c..59c6f89 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1152,6 +1152,7 @@ out:
return ret;
}
+extern int __do_munmap(struct mm_struct *, unsigned long, size_t);
extern int do_munmap(struct mm_struct *, unsigned long, size_t);
extern unsigned long do_brk(unsigned long, unsigned long);
diff --git a/mm/mmap.c b/mm/mmap.c
index 5b62e5d..4e56369 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1881,17 +1881,24 @@ int split_vma(struct mm_struct * mm, struct
vm_area_struct * vma,
return 0;
}
+int do_munmap(struct mm_struct *mm, unsigned long start, size_t len)
+{
+ if (start > TASK_SIZE || len > TASK_SIZE-start)
+ return -EINVAL;
+ return __do_munmap(mm, start, len);
+}
+
/* Munmap is split into 2 main parts -- this part which finds
* what needs doing, and the areas themselves, which do the
* work. This now handles partial unmappings.
* Jeremy Fitzhardinge <[EMAIL PROTECTED]>
*/
-int do_munmap(struct mm_struct *mm, unsigned long start, size_t len)
+int __do_munmap(struct mm_struct *mm, unsigned long start, size_t len)
{
unsigned long end;
struct vm_area_struct *vma, *prev, *last;
- if ((start & ~PAGE_MASK) || start > TASK_SIZE || len > TASK_SIZE-start)
+ if (start & ~PAGE_MASK)
return -EINVAL;
if ((len = PAGE_ALIGN(len)) == 0)
--
1.5.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5 V2] Add shared and reservation control to hugetlb_file_setup
There are two kinds of "Shared" hugetlbfs mappings:
1. using internal vfsmount use ipc/shm.c and shmctl()
2. mmap() of /hugetlbfs/file with MAP_SHARED
There is one kind of private: mmap() of /hugetlbfs/file file with
MAP_PRIVATE
This patch adds a second class of "private" hugetlb-backed mapping. But
we do it by sharing code with the ipc shm. This is mostly because we
need to do our stack setup at execve() time and can't go opening files
from hugetlbfs. The kernel-internal vfsmount for shm lets us get around
this. We truly want anonymous memory, but MAP_PRIVATE is close enough
for now.
Currently, if the mapping on an internal mount is larger than a single
huge page, one page is allocated, one is reserved, and the rest are
faulted as needed. For hugetlb backed stacks we do not want any
reserved pages. This patch gives the caller of hugetlb_file_steup the
ability to control this behavior by specifying flags for private inodes
and page reservations.
Signed-off-by: Eric Munson <[EMAIL PROTECTED]>
---
Based on 2.6.26-rc8-mm1
Changes from V1:
Add creat_flags to struct hugetlbfs_inode_info
Check if space should be reserved in hugetlbfs_file_mmap
Rebase to 2.6.26-rc8-mm1
fs/hugetlbfs/inode.c| 52 ++
include/linux/hugetlb.h | 18 ---
ipc/shm.c |2 +-
3 files changed, 49 insertions(+), 23 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index dbd01d2..2e960d6 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -92,7 +92,7 @@ static int hugetlbfs_file_mmap(struct file *file, struct
vm_area_struct *vma)
* way when do_mmap_pgoff unwinds (may be important on powerpc
* and ia64).
*/
- vma->vm_flags |= VM_HUGETLB | VM_RESERVED;
+ vma->vm_flags |= VM_HUGETLB;
vma->vm_ops = &hugetlb_vm_ops;
if (vma->vm_pgoff & ~(huge_page_mask(h) >> PAGE_SHIFT))
@@ -106,10 +106,13 @@ static int hugetlbfs_file_mmap(struct file *file, struct
vm_area_struct *vma)
ret = -ENOMEM;
len = vma_len + ((loff_t)vma->vm_pgoff << PAGE_SHIFT);
- if (hugetlb_reserve_pages(inode,
+ if (HUGETLBFS_I(inode)->creat_flags & HUGETLB_RESERVE) {
+ vma->vm_flags |= VM_RESERVED;
+ if (hugetlb_reserve_pages(inode,
vma->vm_pgoff >> huge_page_order(h),
len >> huge_page_shift(h), vma))
- goto out;
+ goto out;
+ }
ret = 0;
hugetlb_prefault_arch_hook(vma->vm_mm);
@@ -496,7 +499,8 @@ out:
}
static struct inode *hugetlbfs_get_inode(struct super_block *sb, uid_t uid,
- gid_t gid, int mode, dev_t dev)
+ gid_t gid, int mode, dev_t dev,
+ unsigned long creat_flags)
{
struct inode *inode;
@@ -512,7 +516,9 @@ static struct inode *hugetlbfs_get_inode(struct super_block
*sb, uid_t uid,
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
INIT_LIST_HEAD(&inode->i_mapping->private_list);
info = HUGETLBFS_I(inode);
- mpol_shared_policy_init(&info->policy, NULL);
+ info->creat_flags = creat_flags;
+ if (!(creat_flags & HUGETLB_PRIVATE_INODE))
+ mpol_shared_policy_init(&info->policy, NULL);
switch (mode & S_IFMT) {
default:
init_special_inode(inode, mode, dev);
@@ -553,7 +559,8 @@ static int hugetlbfs_mknod(struct inode *dir,
} else {
gid = current->fsgid;
}
- inode = hugetlbfs_get_inode(dir->i_sb, current->fsuid, gid, mode, dev);
+ inode = hugetlbfs_get_inode(dir->i_sb, current->fsuid, gid, mode, dev,
+ HUGETLB_RESERVE);
if (inode) {
dir->i_ctime = dir->i_mtime = CURRENT_TIME;
d_instantiate(dentry, inode);
@@ -589,7 +596,8 @@ static int hugetlbfs_symlink(struct inode *dir,
gid = current->fsgid;
inode = hugetlbfs_get_inode(dir->i_sb, current->fsuid,
- gid, S_IFLNK|S_IRWXUGO, 0);
+ gid, S_IFLNK|S_IRWXUGO, 0,
+ HUGETLB_RESERVE);
if (inode) {
int l = strlen(symname)+1;
error = page_symlink(inode, symname, l);
@@ -693,7 +701,8 @@ static struct inode *hugetlbfs_alloc_inode(struct
super_block *sb)
static void hugetlbfs_destroy_inode(struct inode *inode)
{
hugetlbfs_inc_free_inodes(HUGETLBFS_SB(inode->i_sb));
- mpol_free_shared_policy(&HUGETLBFS_I(inode)->policy);
+ if (!(HUGETLBFS_I(inode)->creat_flags & HUGETLB_PRIVATE_INODE))
+ mpol_free_shared_policy(&HUGETLBFS_I(inode)->policy);
[PATCH 5/5 V2] [PPC] Setup stack memory segment for hugetlb pages
Currently the memory slice that holds the process stack is always initialized
to hold small pages. This patch defines the weak function that is declared
in the previos patch to convert the stack slice to hugetlb pages.
Signed-off-by: Eric Munson <[EMAIL PROTECTED]>
---
Based on 2.6.26-rc8-mm1
Changes from V1:
Instead of setting the mm-wide page size to huge pages, set only the relavent
slice psize using an arch defined weak function.
arch/powerpc/mm/hugetlbpage.c |6 ++
arch/powerpc/mm/slice.c | 11 +++
include/asm-powerpc/hugetlb.h |3 +++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index fb42c4d..bd7f777 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -152,6 +152,12 @@ pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud,
unsigned long addr,
}
#endif
+void hugetlb_mm_setup(struct mm_struct *mm, unsigned long addr,
+ unsigned long len)
+{
+ slice_convert_address(mm, addr, len, shift_to_mmu_psize(HPAGE_SHIFT));
+}
+
/* Build list of addresses of gigantic pages. This function is used in early
* boot before the buddy or bootmem allocator is setup.
*/
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 583be67..d984733 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -397,6 +398,16 @@ static unsigned long slice_find_area(struct mm_struct *mm,
unsigned long len,
#define MMU_PAGE_BASE MMU_PAGE_4K
#endif
+void slice_convert_address(struct mm_struct *mm, unsigned long addr,
+ unsigned long len, unsigned int psize)
+{
+ struct slice_mask mask;
+
+ mask = slice_range_to_mask(addr, len);
+ slice_convert(mm, mask, psize);
+ slice_flush_segments(mm);
+}
+
unsigned long slice_get_unmapped_area(unsigned long addr, unsigned long len,
unsigned long flags, unsigned int psize,
int topdown, int use_cache)
diff --git a/include/asm-powerpc/hugetlb.h b/include/asm-powerpc/hugetlb.h
index 26f0d0a..10ef089 100644
--- a/include/asm-powerpc/hugetlb.h
+++ b/include/asm-powerpc/hugetlb.h
@@ -17,6 +17,9 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t huge_ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
pte_t *ptep);
+void slice_convert_address(struct mm_struct *mm, unsigned long addr,
+ unsigned long len, unsigned int psize);
+
/*
* If the arch doesn't supply something else, assume that hugepage
* size aligned regions are ok without further preparation.
--
1.5.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: mpc8349-mITX DTB load failure
> From: Kim Phillips > Sent: Monday, July 28, 2008 1:31 PM > > ## Booting kernel from Legacy Image at 01001000 ... > > > ## Flattened Device Tree blob at 0100 > > so the dtb is being loaded only 0x1000 bytes from the kernel, > yet it's probably bigger than that. Can you try different > load addresses, preferably with the two images at least > 0x3000 bytes apart? Ouch. Thanks for pointing that out, it worked. :-) --Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Documentation: remove old sbc8260 board specific information
On Jul 28, 2008, at 1:50 PM, Paul Gortmaker wrote: This file contains 8 yr. old board specific information that was for the now gone ppc implementation, and it pre-dates widespread u-boot support. Any of the technical details of the board memory map would be more appropriately captured in a dts if I revive it as powerpc anyway. Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]> Acked-by: Jason Wessel <[EMAIL PROTECTED]> --- Documentation/powerpc/00-INDEX |2 - Documentation/powerpc/SBC8260_memory_mapping.txt | 197 -- 2 files changed, 0 insertions(+), 199 deletions(-) delete mode 100644 Documentation/powerpc/SBC8260_memory_mapping.txt applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/lpar - defer prefered console setup
Hi
The powerpc lpar code adds a prefered console at a very early state,
during arch_setup. This runs even before the console setup from the
command line and takes preference.
This patch moves the prefered console setup into an arch_initcall which
runs later and allows the specification of the correct console on the
command line. The udbg console remains as boot console.
There is a different problem that the code does not pick up the correct
console because it uses a part (4) of the lpar device number (3004)
instead of the correct index 1.
Signed-off-by: Bastian Blank <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 9235c46..626290d 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -57,6 +57,7 @@ extern void pSeries_find_serial_port(void);
int vtermno; /* virtual terminal# for udbg */
+static char *console_name;
#define __ALIGNED__ __attribute__((__aligned__(sizeof(long
static void udbg_hvsi_putc(char c)
@@ -232,18 +233,24 @@ void __init find_udbg_vterm(void)
udbg_putc = udbg_putcLP;
udbg_getc = udbg_getcLP;
udbg_getc_poll = udbg_getc_pollLP;
- add_preferred_console("hvc", termno[0] & 0xff, NULL);
+ console_name = "hvc";
} else if (of_device_is_compatible(stdout_node, "hvterm-protocol")) {
- vtermno = termno[0];
udbg_putc = udbg_hvsi_putc;
udbg_getc = udbg_hvsi_getc;
udbg_getc_poll = udbg_hvsi_getc_poll;
- add_preferred_console("hvsi", termno[0] & 0xff, NULL);
+ console_name = "hvsi";
}
out:
of_node_put(stdout_node);
}
+static void __init enable_vterm(void)
+{
+ if (console_name)
+ add_preferred_console(console_name, vtermno, NULL);
+}
+arch_initcall(enable_vterm);
+
void vpa_init(int cpu)
{
int hwcpu = get_hard_smp_processor_id(cpu);
--
Genius doesn't work on an assembly line basis. You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Mon, 2008-07-28 at 08:40 -0700, Linus Torvalds wrote: > > On Mon, 28 Jul 2008, Benjamin Herrenschmidt wrote: > > > > It's all in: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge > > It doesn't really seem to be. I get "Already up-to-date.", and the top > commit there seems to be from July 3.. > > Forgot to push? No, forgot to s/paulus/benh in the path :-) > > > (Hopefully no silly non-printable character this time, at least > > nothing I manage to spot with evo but who knows...) > > Yeah, no odd whitespace here either. Not that it helps ;) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Mon, 2008-07-28 at 09:06 -0700, Linus Torvalds wrote: > > On Tue, 29 Jul 2008, Stephen Rothwell wrote: > > > > It should be > > > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > > > > Ben seems to have copied from one of Paul's pull requests. > > Ok, that one worked for me. > > Ben, I'm sure some day you'll get it right on the first try. We're all > cheering for you! Should I hang out with a brown paper bag on my head all day today ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Mon, 2008-07-28 at 10:20 -0600, Grant Likely wrote: > On Mon, Jul 28, 2008 at 09:06:35AM -0700, Linus Torvalds wrote: > > > > > > On Tue, 29 Jul 2008, Stephen Rothwell wrote: > > > > > > It should be > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > > > > > > Ben seems to have copied from one of Paul's pull requests. > > > > Ok, that one worked for me. > > > > Ben, I'm sure some day you'll get it right on the first try. We're all > > cheering for you! > > Ben! Ben! He's our man! If he can't grok it, no-one can! :-) > > git-request-pull has saved me from many a bogus pull request. Ah, I didn't know about this critter ! I'm learning new things everyday, woow ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Mon, 28 Jul 2008, Dave Hansen wrote: > On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote: > > > > This patch stack introduces a personality flag that indicates the > > kernel > > should setup the stack as a hugetlbfs-backed region. A userspace > > utility > > may set this flag then exec a process whose stack is to be backed by > > hugetlb pages. > > I didn't see it mentioned here, but these stacks are fixed-size, right? > They can't actually grow and are fixed in size at exec() time, right? > > -- Dave The stack VMA is a fixed size but the pages will be faulted in as needed. -- Eric B Munson IBM Linux Technology Center [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
Vivek Goyal <[EMAIL PROTECTED]> writes: > Hi All, > > How does following series of patches look like. I have moved > elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section > of crash dump to make sure that it can be worked with even when > CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled. > > I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and > sh versions are completely untested. Given the current state of the code: Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]> To process a kernel crash dump we pass the kernel elfcorehdr option, so testing to see if it was passed seems reasonable. In general I think this method of handling the problems with kdump is too brittle to live, but in the case of iommus we certainly need to do something different, and unfortunately iommus were not common on x86 when the original code was merged so we have not handled them well. Eric ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Tue, Jul 29, 2008 at 07:15:36AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2008-07-28 at 09:06 -0700, Linus Torvalds wrote: > > > > On Tue, 29 Jul 2008, Stephen Rothwell wrote: > > > > > > It should be > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge > > > > > > Ben seems to have copied from one of Paul's pull requests. > > > > Ok, that one worked for me. > > > > Ben, I'm sure some day you'll get it right on the first try. We're all > > cheering for you! > > Should I hang out with a brown paper bag on my head all day today ? No, that's reserved for committing things to the top level Makefile for no reason. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux kernel for ppc as elf relocatable
Can somebody help me with a few indications regarding how to obtain a relocatable vmlinux when compiling the linux kernel for ppc32 ? For powerpc, by default, the building process results in an ELF 32-bit MSB executable statically linked. I saw that for other architectures it builds, by default, a relocatable elf file. Why is it statically linked for some architectures and relocatable for others ? How to make it relocatable for ppc32? I assume that changing LDFLAGS_vmlinux to '-r' in the Makefile for ppc is not enough... (i'm using 2.6.11) p.s. any comments/answers to my posting, please add me in CC, as i didn't subscribe, thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5 V2] Align stack boundaries based on personality
On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
>
> +static unsigned long personality_page_align(unsigned long addr)
> +{
> + if (current->personality & HUGETLB_STACK)
> +#ifdef CONFIG_STACK_GROWSUP
> + return HPAGE_ALIGN(addr);
> +#else
> + return addr & HPAGE_MASK;
> +#endif
> +
> + return PAGE_ALIGN(addr);
> +}
...
> - stack_top = PAGE_ALIGN(stack_top);
> + stack_top = personality_page_align(stack_top);
Just out of curiosity, why doesn't the existing small-page case seem to
care about the stack growing up/down? Why do you need to care in the
large page case?
-- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote: > > This patch stack introduces a personality flag that indicates the > kernel > should setup the stack as a hugetlbfs-backed region. A userspace > utility > may set this flag then exec a process whose stack is to be backed by > hugetlb pages. I didn't see it mentioned here, but these stacks are fixed-size, right? They can't actually grow and are fixed in size at exec() time, right? -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5 V2] Build hugetlb backed process stacks
On Mon, 2008-07-28 at 12:17 -0700, Eric Munson wrote:
>
> +static int move_to_huge_pages(struct linux_binprm *bprm,
> + struct vm_area_struct *vma, unsigned
> long shift)
> +{
> + struct mm_struct *mm = vma->vm_mm;
> + struct vm_area_struct *new_vma;
> + unsigned long old_end = vma->vm_end;
> + unsigned long old_start = vma->vm_start;
> + unsigned long new_end = old_end - shift;
> + unsigned long new_start, length;
> + unsigned long arg_size = new_end - bprm->p;
> + unsigned long flags = vma->vm_flags;
> + struct file *hugefile = NULL;
> + unsigned int stack_hpages = 0;
> + struct page **from_pages = NULL;
> + struct page **to_pages = NULL;
> + unsigned long num_pages = (arg_size / PAGE_SIZE) + 1;
> + int ret;
> + int i;
> +
> +#ifdef CONFIG_STACK_GROWSUP
Why do you have the #ifdef for the CONFIG_STACK_GROWSUP=y case in that
first patch if you don't support CONFIG_STACK_GROWSUP=y?
I think it might be worth some time to break this up a wee little bit.
16 local variables is a big on the beefy side. :)
-- Dave
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/5] sh: Define elfcorehdr_addr in arch dependent section
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or not. o I don't see sh setup code parsing the command line for elfcorehdr_addr. I am wondering how does vmcore interface work on sh. Anyway, I am atleast defining elfcoredhr_addr so that compilation is not broken on sh. Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> --- arch/sh/kernel/crash_dump.c |3 +++ 1 file changed, 3 insertions(+) diff -puN arch/sh/kernel/crash_dump.c~fix-elfcorehdr_addr-sh arch/sh/kernel/crash_dump.c --- linux-2.6.27-pre-rc1/arch/sh/kernel/crash_dump.c~fix-elfcorehdr_addr-sh 2008-07-28 12:17:12.0 -0400 +++ linux-2.6.27-pre-rc1-root/arch/sh/kernel/crash_dump.c 2008-07-28 12:17:12.0 -0400 @@ -10,6 +10,9 @@ #include #include +/* Stores the physical address of elf header of crash image. */ +unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX; + /** * copy_oldmem_page - copy one page from "oldmem" * @pfn: page frame number to be copied _ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] x86: Define elfcorehdr_addr in arch dependent section
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or not. Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> --- arch/x86/kernel/crash_dump_32.c |3 +++ arch/x86/kernel/crash_dump_64.c |3 +++ arch/x86/kernel/setup.c |8 +++- 3 files changed, 13 insertions(+), 1 deletion(-) diff -puN arch/x86/kernel/setup.c~fix-elfcorehdr_addr-parsing-x86 arch/x86/kernel/setup.c --- linux-2.6.27-pre-rc1/arch/x86/kernel/setup.c~fix-elfcorehdr_addr-parsing-x86 2008-07-28 12:01:35.0 -0400 +++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/setup.c 2008-07-28 12:01:35.0 -0400 @@ -558,7 +558,13 @@ static void __init reserve_standard_io_r } -#ifdef CONFIG_PROC_VMCORE +/* + * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by + * is_kdump_kernel() to determine if we are booting after a panic. Hence + * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE. + */ + +#ifdef CONFIG_CRASH_DUMP /* elfcorehdr= specifies the location of elf core header * stored by the crashed kernel. This option will be passed * by kexec loader to the capture kernel. diff -puN arch/x86/kernel/crash_dump_32.c~fix-elfcorehdr_addr-parsing-x86 arch/x86/kernel/crash_dump_32.c --- linux-2.6.27-pre-rc1/arch/x86/kernel/crash_dump_32.c~fix-elfcorehdr_addr-parsing-x86 2008-07-28 12:01:35.0 -0400 +++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/crash_dump_32.c 2008-07-28 12:01:35.0 -0400 @@ -13,6 +13,9 @@ static void *kdump_buf_page; +/* Stores the physical address of elf header of crash image. */ +unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX; + /** * copy_oldmem_page - copy one page from "oldmem" * @pfn: page frame number to be copied diff -puN arch/x86/kernel/crash_dump_64.c~fix-elfcorehdr_addr-parsing-x86 arch/x86/kernel/crash_dump_64.c --- linux-2.6.27-pre-rc1/arch/x86/kernel/crash_dump_64.c~fix-elfcorehdr_addr-parsing-x86 2008-07-28 12:01:35.0 -0400 +++ linux-2.6.27-pre-rc1-root/arch/x86/kernel/crash_dump_64.c 2008-07-28 12:01:35.0 -0400 @@ -11,6 +11,9 @@ #include #include +/* Stores the physical address of elf header of crash image. */ +unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX; + /** * copy_oldmem_page - copy one page from "oldmem" * @pfn: page frame number to be copied _ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/5] ia64: Define elfcorehdr_addr in arch dependent section
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
not.
Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---
arch/ia64/kernel/setup.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff -puN arch/ia64/kernel/setup.c~fix-elfcorehdr_addr-parsing-ia64
arch/ia64/kernel/setup.c
---
linux-2.6.27-pre-rc1/arch/ia64/kernel/setup.c~fix-elfcorehdr_addr-parsing-ia64
2008-07-28 12:16:40.0 -0400
+++ linux-2.6.27-pre-rc1-root/arch/ia64/kernel/setup.c 2008-07-28
12:16:40.0 -0400
@@ -478,7 +478,12 @@ static __init int setup_nomca(char *s)
}
early_param("nomca", setup_nomca);
-#ifdef CONFIG_PROC_VMCORE
+/*
+ * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
+ * is_kdump_kernel() to determine if we are booting after a panic. Hence
+ * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
+ */
+#ifdef CONFIG_CRASH_DUMP
/* elfcorehdr= specifies the location of elf core header
* stored by the crashed kernel.
*/
@@ -491,7 +496,9 @@ static int __init parse_elfcorehdr(char
return 0;
}
early_param("elfcorehdr", parse_elfcorehdr);
+#endif
+#ifdef CONFIG_PROC_VMCORE
int __init reserve_elfcorehdr(unsigned long *start, unsigned long *end)
{
unsigned long length;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/5] powerpc: Define elfcorehdr_addr in arch dependent section
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
not.
Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/crash_dump.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff -puN arch/powerpc/kernel/crash_dump.c~fix-elfcorehdr_addr-parsing-ppc64
arch/powerpc/kernel/crash_dump.c
---
linux-2.6.27-pre-rc1/arch/powerpc/kernel/crash_dump.c~fix-elfcorehdr_addr-parsing-ppc64
2008-07-28 12:14:22.0 -0400
+++ linux-2.6.27-pre-rc1-root/arch/powerpc/kernel/crash_dump.c 2008-07-28
12:14:22.0 -0400
@@ -27,6 +27,9 @@
#define DBG(fmt...)
#endif
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
void __init reserve_kdump_trampoline(void)
{
lmb_reserve(0, KDUMP_RESERVE_LIMIT);
@@ -66,7 +69,11 @@ void __init setup_kdump_trampoline(void)
DBG(" <- setup_kdump_trampoline()\n");
}
-#ifdef CONFIG_PROC_VMCORE
+/*
+ * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
+ * is_kdump_kernel() to determine if we are booting after a panic. Hence
+ * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
+ */
static int __init parse_elfcorehdr(char *p)
{
if (p)
@@ -75,7 +82,6 @@ static int __init parse_elfcorehdr(char
return 1;
}
__setup("elfcorehdr=", parse_elfcorehdr);
-#endif
static int __init parse_savemaxmem(char *p)
{
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
Hi All,
How does following series of patches look like. I have moved
elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section
of crash dump to make sure that it can be worked with even when
CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled.
I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and
sh versions are completely untested.
Thanks
Vivek
o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE but
also by the code which is not inside CONFIG_PROC_VMCORE. For example,
is_kdump_kernel() is used by powerpc code to determine if kernel is booting
after a panic then use previous kernel's TCE table. So even if
CONFIG_PROC_VMCORE is not set in second kernel, one should be able to
correctly determine that we are booting after a panic and setup calgary
iommu accordingly.
o So remove the assumption that elfcorehdr_addr is under CONFIG_PROC_VMCORE.
o Move definition of elfcorehdr_addr to arch dependent crash files.
(Unfortunately crash dump does not have an arch independent file otherwise
that would have been the best place).
o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
second kernel without KEXEC being enabled.
Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
---
fs/proc/vmcore.c |3 ---
include/linux/crash_dump.h | 14 ++
2 files changed, 10 insertions(+), 7 deletions(-)
diff -puN fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore
fs/proc/vmcore.c
---
linux-2.6.27-pre-rc1/fs/proc/vmcore.c~remove-elfcore-hdr-addr-definition-vmcore
2008-07-28 09:19:50.0 -0400
+++ linux-2.6.27-pre-rc1-root/fs/proc/vmcore.c 2008-07-28 09:20:10.0
-0400
@@ -32,9 +32,6 @@ static size_t elfcorebuf_sz;
/* Total size of vmcore file. */
static u64 vmcore_size;
-/* Stores the physical address of elf header of crash image. */
-unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-
struct proc_dir_entry *proc_vmcore = NULL;
/* Reads a page from the oldmem device from given offset. */
diff -puN include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore
include/linux/crash_dump.h
---
linux-2.6.27-pre-rc1/include/linux/crash_dump.h~remove-elfcore-hdr-addr-definition-vmcore
2008-07-28 12:00:44.0 -0400
+++ linux-2.6.27-pre-rc1-root/include/linux/crash_dump.h2008-07-28
12:00:56.0 -0400
@@ -9,11 +9,7 @@
#define ELFCORE_ADDR_MAX (-1ULL)
-#ifdef CONFIG_PROC_VMCORE
extern unsigned long long elfcorehdr_addr;
-#else
-static const unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
-#endif
extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
unsigned long, int);
@@ -28,6 +24,16 @@ extern struct proc_dir_entry *proc_vmcor
#define vmcore_elf_check_arch(x) (elf_check_arch(x) ||
vmcore_elf_check_arch_cross(x))
+/*
+ * is_kdump_kernel() checks whether this kernel is booting after a panic of
+ * previous kernel or not. This is determined by checking if previous kernel
+ * has passed the elf core header address on command line.
+ *
+ * This is not just a test if CONFIG_CRASH_DUMP is enabled or not. It will
+ * return 1 if CONFIG_CRASH_DUMP=y and if kernel is booting after a panic of
+ * previous kernel.
+ */
+
static inline int is_kdump_kernel(void)
{
return (elfcorehdr_addr != ELFCORE_ADDR_MAX) ? 1 : 0;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: pci-current tree build failure
Hi Jesse,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/kernel/iommu.c:54: error: static declaration of 'iommu_num_pages'
follows non-static declaration
include/linux/iommu-helper.h:11: error: previous declaration of
'iommu_num_pages' was here
Caused by commit 3bc9f79ee1ddc913be0a6d3592036683ef8a3148 ("iommu: add
iommu_num_pages helper function") which introduced a global version of a
function that powerpc has a different version of. I am not sure that the
two do the same thing - in fact they don't since powerpc can have a 64k
page size and still need to use a 4k iommu pages. I applied the
patch below (which I personally hate :-))
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
>From ade341416a628800ad2a27ecd576238087290125 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Tue, 29 Jul 2008 10:47:59 +1000
Subject: [PATCH] powerpc: generic iommu helper fallout
Powerpc needs it own version of iommu_num_pages() since the iommu pages
may be a different size to the system pages.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/iommu.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 550a193..b147055 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -51,7 +51,7 @@ static int protect4gb = 1;
static void __iommu_free(struct iommu_table *, dma_addr_t, unsigned int);
-static inline unsigned long iommu_num_pages(unsigned long vaddr,
+static inline unsigned long ppc_iommu_num_pages(unsigned long vaddr,
unsigned long slen)
{
unsigned long npages;
@@ -325,7 +325,7 @@ int iommu_map_sg(struct device *dev, struct iommu_table
*tbl,
}
/* Allocate iommu entries for that segment */
vaddr = (unsigned long) sg_virt(s);
- npages = iommu_num_pages(vaddr, slen);
+ npages = ppc_iommu_num_pages(vaddr, slen);
align = 0;
if (IOMMU_PAGE_SHIFT < PAGE_SHIFT && slen >= PAGE_SIZE &&
(vaddr & ~PAGE_MASK) == 0)
@@ -418,7 +418,7 @@ int iommu_map_sg(struct device *dev, struct iommu_table
*tbl,
unsigned long vaddr, npages;
vaddr = s->dma_address & IOMMU_PAGE_MASK;
- npages = iommu_num_pages(s->dma_address, s->dma_length);
+ npages = ppc_iommu_num_pages(s->dma_address,
s->dma_length);
__iommu_free(tbl, vaddr, npages);
s->dma_address = DMA_ERROR_CODE;
s->dma_length = 0;
@@ -452,7 +452,7 @@ void iommu_unmap_sg(struct iommu_table *tbl, struct
scatterlist *sglist,
if (sg->dma_length == 0)
break;
- npages = iommu_num_pages(dma_handle, sg->dma_length);
+ npages = ppc_iommu_num_pages(dma_handle, sg->dma_length);
__iommu_free(tbl, dma_handle, npages);
sg = sg_next(sg);
}
@@ -584,7 +584,7 @@ dma_addr_t iommu_map_single(struct device *dev, struct
iommu_table *tbl,
BUG_ON(direction == DMA_NONE);
uaddr = (unsigned long)vaddr;
- npages = iommu_num_pages(uaddr, size);
+ npages = ppc_iommu_num_pages(uaddr, size);
if (tbl) {
align = 0;
@@ -617,7 +617,7 @@ void iommu_unmap_single(struct iommu_table *tbl, dma_addr_t
dma_handle,
BUG_ON(direction == DMA_NONE);
if (tbl) {
- npages = iommu_num_pages(dma_handle, size);
+ npages = ppc_iommu_num_pages(dma_handle, size);
iommu_free(tbl, dma_handle, npages);
}
}
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > Hi All, > > > > How does following series of patches look like. I have moved > > elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section > > of crash dump to make sure that it can be worked with even when > > CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled. > > > > I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and > > sh versions are completely untested. > > Given the current state of the code: > Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]> > > To process a kernel crash dump we pass the kernel elfcorehdr option, > so testing to see if it was passed seems reasonable. > > In general I think this method of handling the problems with kdump is > too brittle to live, but in the case of iommus we certainly need to do > something different, and unfortunately iommus were not common on x86 > when the original code was merged so we have not handled them well. Agreed, however these patches look like they really ought to be merged into a single patch for the sake of bisect. As things stand, applying the first patch will break the build on each architecture with an architecture specific until the latter is applied. -- Horms ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: pci-current tree build failure
On Monday, July 28, 2008 5:52 pm Stephen Rothwell wrote:
> Hi Jesse,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/kernel/iommu.c:54: error: static declaration of
> 'iommu_num_pages' follows non-static declaration
> include/linux/iommu-helper.h:11: error: previous declaration of
> 'iommu_num_pages' was here
>
> Caused by commit 3bc9f79ee1ddc913be0a6d3592036683ef8a3148 ("iommu: add
> iommu_num_pages helper function") which introduced a global version of a
> function that powerpc has a different version of. I am not sure that the
> two do the same thing - in fact they don't since powerpc can have a 64k
> page size and still need to use a 4k iommu pages. I applied the
> patch below (which I personally hate :-))
Hopefully my ppc machine will arrive soon and I can build & test boot things
so this won't happen in the future.
Joerg, what do you think here?
Thanks,
Jesse
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
On Tue, Jul 29, 2008 at 11:22:48AM +1000, Simon Horman wrote: > On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote: > > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > > > Hi All, > > > > > > How does following series of patches look like. I have moved > > > elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section > > > of crash dump to make sure that it can be worked with even when > > > CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled. > > > > > > I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and > > > sh versions are completely untested. > > > > Given the current state of the code: > > Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]> > > > > To process a kernel crash dump we pass the kernel elfcorehdr option, > > so testing to see if it was passed seems reasonable. > > > > In general I think this method of handling the problems with kdump is > > too brittle to live, but in the case of iommus we certainly need to do > > something different, and unfortunately iommus were not common on x86 > > when the original code was merged so we have not handled them well. > > Agreed, however these patches look like they really ought to be merged > into a single patch for the sake of bisect. As things stand, applying > the first patch will break the build on each architecture with an > architecture specific until the latter is applied. That's a good point. I was not very sure because changes were in different arches and I broke the patch. At the same time changes are really miniscule in each arch. So, for the sake of not breaking compilation for git-bisect, I will generate a single patch tomorrow. (Until and unless somebody has an objection). Thanks Vivek > > -- > Horms ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/lpar - defer prefered console setup
On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
> Hi
>
> The powerpc lpar code adds a prefered console at a very early state,
> during arch_setup. This runs even before the console setup from the
> command line and takes preference.
>
> This patch moves the prefered console setup into an arch_initcall which
> runs later and allows the specification of the correct console on the
> command line. The udbg console remains as boot console.
>
> There is a different problem that the code does not pick up the correct
> console because it uses a part (4) of the lpar device number (3004)
> instead of the correct index 1.
>
> Signed-off-by: Bastian Blank <[EMAIL PROTECTED]>
Shouldn't it be a console_initcall() ?
Now, regarding the "different problem" I think it's even worse than
that, looking at the code there's some non sensical things in here...
add_preferred_console() argument is what gets compared to
console->index, right ? Now if you look at hvc_instantiate(),
it compares each "index" argument passed in to hvc_con_driver.index,
and that index argument passed from hvc_find_vtys() has strictly
nothing to do with the vtermno, it's purely the index of the node
found in order...
So I think the whole stuff is non-sensical and needs fixing.
Cheers,
Ben.
> diff --git a/arch/powerpc/platforms/pseries/lpar.c
> b/arch/powerpc/platforms/pseries/lpar.c
> index 9235c46..626290d 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -57,6 +57,7 @@ extern void pSeries_find_serial_port(void);
>
>
> int vtermno; /* virtual terminal# for udbg */
> +static char *console_name;
>
> #define __ALIGNED__ __attribute__((__aligned__(sizeof(long
> static void udbg_hvsi_putc(char c)
> @@ -232,18 +233,24 @@ void __init find_udbg_vterm(void)
> udbg_putc = udbg_putcLP;
> udbg_getc = udbg_getcLP;
> udbg_getc_poll = udbg_getc_pollLP;
> - add_preferred_console("hvc", termno[0] & 0xff, NULL);
> + console_name = "hvc";
> } else if (of_device_is_compatible(stdout_node, "hvterm-protocol")) {
> - vtermno = termno[0];
> udbg_putc = udbg_hvsi_putc;
> udbg_getc = udbg_hvsi_getc;
> udbg_getc_poll = udbg_hvsi_getc_poll;
> - add_preferred_console("hvsi", termno[0] & 0xff, NULL);
> + console_name = "hvsi";
> }
> out:
> of_node_put(stdout_node);
> }
>
> +static void __init enable_vterm(void)
> +{
> + if (console_name)
> + add_preferred_console(console_name, vtermno, NULL);
> +}
> +arch_initcall(enable_vterm);
> +
> void vpa_init(int cpu)
> {
> int hwcpu = get_hard_smp_processor_id(cpu);
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr')
On Mon, Jul 28, 2008 at 10:28:22PM -0400, Vivek Goyal wrote: > On Tue, Jul 29, 2008 at 11:22:48AM +1000, Simon Horman wrote: > > On Mon, Jul 28, 2008 at 03:47:41PM -0700, Eric W. Biederman wrote: > > > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > > > > > Hi All, > > > > > > > > How does following series of patches look like. I have moved > > > > elfcorehdr_addr out of vmcore.c and pushed it to arch dependent section > > > > of crash dump to make sure that it can be worked with even when > > > > CONFIG_PROC_VMCORE is disabled and CONFIG_CRASH_DUMP is enabled. > > > > > > > > I tested it on x86_64. Compile tested it on i386 and ppc64. ia64 and > > > > sh versions are completely untested. > > > > > > Given the current state of the code: > > > Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]> > > > > > > To process a kernel crash dump we pass the kernel elfcorehdr option, > > > so testing to see if it was passed seems reasonable. > > > > > > In general I think this method of handling the problems with kdump is > > > too brittle to live, but in the case of iommus we certainly need to do > > > something different, and unfortunately iommus were not common on x86 > > > when the original code was merged so we have not handled them well. > > > > Agreed, however these patches look like they really ought to be merged > > into a single patch for the sake of bisect. As things stand, applying > > the first patch will break the build on each architecture with an > > architecture specific until the latter is applied. > > That's a good point. I was not very sure because changes were in > different arches and I broke the patch. At the same time changes are > really miniscule in each arch. I guessed that was why you split them up. But really the per-arch change is very small. > So, for the sake of not breaking compilation for git-bisect, I will > generate a single patch tomorrow. (Until and unless somebody has an > objection). For combiled patch: Acked-by: Simon Horman <[EMAIL PROTECTED]> -- Horms ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] ia64: Define elfcorehdr_addr in arch dependent section
On Mon, Jul 28, 2008 at 05:13:14PM -0400, Vivek Goyal wrote:
>
> o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
> equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
> CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
> used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or
> not.
>
> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]>
> ---
>
> arch/ia64/kernel/setup.c |9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff -puN arch/ia64/kernel/setup.c~fix-elfcorehdr_addr-parsing-ia64
> arch/ia64/kernel/setup.c
> ---
> linux-2.6.27-pre-rc1/arch/ia64/kernel/setup.c~fix-elfcorehdr_addr-parsing-ia64
> 2008-07-28 12:16:40.0 -0400
> +++ linux-2.6.27-pre-rc1-root/arch/ia64/kernel/setup.c2008-07-28
> 12:16:40.0 -0400
> @@ -478,7 +478,12 @@ static __init int setup_nomca(char *s)
> }
> early_param("nomca", setup_nomca);
>
> -#ifdef CONFIG_PROC_VMCORE
> +/*
> + * Note: elfcorehdr_addr is not just limited to vmcore. It is also used by
> + * is_kdump_kernel() to determine if we are booting after a panic. Hence
> + * ifdef it under CONFIG_CRASH_DUMP and not CONFIG_PROC_VMCORE.
> + */
> +#ifdef CONFIG_CRASH_DUMP
> /* elfcorehdr= specifies the location of elf core header
> * stored by the crashed kernel.
> */
> @@ -491,7 +496,9 @@ static int __init parse_elfcorehdr(char
> return 0;
> }
> early_param("elfcorehdr", parse_elfcorehdr);
> +#endif
>
> +#ifdef CONFIG_PROC_VMCORE
> int __init reserve_elfcorehdr(unsigned long *start, unsigned long *end)
> {
> unsigned long length;
> _
Hi Vivek,
I think that you also need the following in arch/ia64/kernel/crash_dump.c.
With this change your code compiles on ia64.
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/crash_dump.c
===
--- linux-2.6.orig/arch/ia64/kernel/crash_dump.c2008-07-29
14:06:57.0 +1000
+++ linux-2.6/arch/ia64/kernel/crash_dump.c 2008-07-29 14:09:55.0
+1000
@@ -8,10 +8,14 @@
#include
#include
+#include
#include
#include
+/* Stores the physical address of elf header of crash image. */
+unsigned long long elfcorehdr_addr = ELFCORE_ADDR_MAX;
+
/**
* copy_oldmem_page - copy one page from "oldmem"
* @pfn: page frame number to be copied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfdt: Forgot one function when cleaning the namespace
In commit b6d80a20fc293f3b995c3ce1a6744a5574192125, we renamed all
libfdt functions to be prefixed with fdt_ or _fdt_ to minimise the
chance of collisions with things from whatever package libfdt is
embedded in, pulled into the libfdt build via that environment's
libfdt_env.h.
Except... I missed one. This patch applies the same treatment to
_stringlist_contains(). While we're at it, also make it static since
it's only used in the same file.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/libfdt/fdt_ro.c
===
--- dtc.orig/libfdt/fdt_ro.c2008-07-29 13:43:23.0 +1000
+++ dtc/libfdt/fdt_ro.c 2008-07-29 13:43:33.0 +1000
@@ -408,7 +408,8 @@ int fdt_node_offset_by_phandle(const voi
&phandle, sizeof(phandle));
}
-int _stringlist_contains(const char *strlist, int listlen, const char *str)
+static int _fdt_stringlist_contains(const char *strlist, int listlen,
+ const char *str)
{
int len = strlen(str);
const char *p;
@@ -434,7 +435,7 @@ int fdt_node_check_compatible(const void
prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
if (!prop)
return len;
- if (_stringlist_contains(prop, len, compatible))
+ if (_fdt_stringlist_contains(prop, len, compatible))
return 0;
else
return 1;
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Remove unused lexer function
dtc does not use the input() function in flex. Apparently on some gcc versions the unused function will cause warnings. Therefore, this patch removes the function by using the 'noinput' option to flex. Signed-off-by: David Gibson <[EMAIL PROTECTED]> Index: dtc/dtc-lexer.l === --- dtc.orig/dtc-lexer.l2008-07-29 14:48:08.0 +1000 +++ dtc/dtc-lexer.l 2008-07-29 14:48:27.0 +1000 @@ -18,7 +18,7 @@ * USA */ -%option noyywrap nounput yylineno +%option noyywrap nounput noinput yylineno %x INCLUDE %x BYTESTRING -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Tue, 2008-07-29 at 14:17 +0900, FUJITA Tomonori wrote: > If q->elevator is NULL, the media-bay code might mess up the ref > counting of the request queue... Well, all I do is call into Bart's new helpers to scan for or unregister devices ... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
On Mon, 28 Jul 2008 16:31:56 +0200 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > > However, the machine crashes when removing the media-bay CD-ROM drive. > > > > > > Crash appears to be a NULL deref, possibly in elv_may_queue() though > > > I don't have a clean backtrace yet, working on it... > > I wonder whether conversion from on-stack struct requests to allocated > ones may have something to do with it (or not?)... It might be. q->elevator is NULL? I think that everyone goes through this path (generic_ide_remove -> ide_cd_release -> cdrom_get_disc_info ->...). With 2.6.27-rc1, I've just tried this path by removing ide-cd module, and it's fine. If q->elevator is NULL, the media-bay code might mess up the ref counting of the request queue... > > Here's a backtrace: > > > > Vector: 300 (Data Access) at [c58b7b80] > > pc: c014f264: elv_may_queue+0x10/0x44 > > lr: c0152750: get_request+0x2c/0x2c0 > > sp: c58b7c30 > >msr: 1032 > >dar: c > > dsisr: 4000 > > current = 0xc58aaae0 > > pid = 854, comm = media-bay > > enter ? for help > > mon> t > > [c58b7c40] c0152750 get_request+0x2c/0x2c0 > > [c58b7c70] c0152a08 get_request_wait+0x24/0xec > > [c58b7cc0] c0225674 ide_cd_queue_pc+0x58/0x1a0 > > [c58b7d40] c022672c ide_cdrom_packet+0x9c/0xdc > > [c58b7d70] c0261810 cdrom_get_disc_info+0x60/0xd0 > > [c58b7dc0] c026208c cdrom_mrw_exit+0x1c/0x11c > > [c58b7e30] c0260f7c unregister_cdrom+0x84/0xe8 > > [c58b7e50] c022395c ide_cd_release+0x80/0x84 > > [c58b7e70] c0163650 kref_put+0x54/0x6c > > [c58b7e80] c0223884 ide_cd_put+0x40/0x5c > > [c58b7ea0] c0211100 generic_ide_remove+0x28/0x3c > > [c58b7eb0] c01e9d34 __device_release_driver+0x78/0xb4 > > [c58b7ec0] c01e9e44 device_release_driver+0x28/0x44 > > [c58b7ee0] c01e8f7c bus_remove_device+0xac/0xd8 > > [c58b7f00] c01e7424 device_del+0x104/0x198 > > [c58b7f20] c01e74d0 device_unregister+0x18/0x30 > > [c58b7f40] c02121c4 __ide_port_unregister_devices+0x6c/0x88 > > [c58b7f60] c0212398 ide_port_unregister_devices+0x38/0x80 > > [c58b7f80] c0208ca4 media_bay_step+0x1cc/0x5c0 > > [c58b7fb0] c0209124 media_bay_task+0x8c/0xcc > > [c58b7fd0] c00485c0 kthread+0x48/0x84 > > [c58b7ff0] c0011b20 kernel_thread+0x44/0x60 > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
