[PATCH] [POWERPC] Fix incorrect enabling of VMX when building signal or user context
When building a signal or a ucontext, we can incorrectly set the MSR_VEC bit of the kernel pt_regs-msr before returning to userspace if the task -ever- used VMX. This can lead to funny result if that stack used it in the past, then lost it (ie. it wasn't enabled after a context switch for example) and then called get_context. It can end up with VMX enabled and the registers containing values from some other task. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- arch/powerpc/kernel/signal_64.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- linux-work.orig/arch/powerpc/kernel/signal_64.c 2008-06-02 16:14:10.0 +1000 +++ linux-work/arch/powerpc/kernel/signal_64.c 2008-06-02 16:18:39.0 +1000 @@ -87,6 +87,7 @@ static long setup_sigcontext(struct sigc #ifdef CONFIG_ALTIVEC elf_vrreg_t __user *v_regs = (elf_vrreg_t __user *)(((unsigned long)sc-vmx_reserve + 15) ~0xful); #endif + unsigned long msr = regs-msr; long err = 0; flush_fp_to_thread(current); @@ -102,7 +103,7 @@ static long setup_sigcontext(struct sigc /* set MSR_VEC in the MSR value in the frame to indicate that sc-v_reg) * contains valid data. */ - regs-msr |= MSR_VEC; + msr |= MSR_VEC; } /* We always copy to/from vrsave, it's 0 if we don't have or don't * use altivec. @@ -114,6 +115,7 @@ static long setup_sigcontext(struct sigc err |= __put_user(sc-gp_regs, sc-regs); WARN_ON(!FULL_REGS(regs)); err |= __copy_to_user(sc-gp_regs, regs, GP_REGS_SIZE); + err |= __put_user(msr, sc-gp_regs[PT_MSR]); err |= __copy_to_user(sc-fp_regs, current-thread.fpr, FP_REGS_SIZE); err |= __put_user(signr, sc-signal); err |= __put_user(handler, sc-handler); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
David Gibson wrote:
On Fri, May 30, 2008 at 08:49:45AM +0200, Wolfgang Grandegger wrote:
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
[snip]
index 000..d09250a
--- /dev/null
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -0,0 +1,370 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
[snip]
+[EMAIL PROTECTED] {
+#address-cells = 1;
+#size-cells = 0;
+cell-index = 0;
[...]
+enet0: [EMAIL PROTECTED] {
+cell-index = 0;
[...]
+serial0: [EMAIL PROTECTED] {
+cell-index = 0;
[...]
+pci0: [EMAIL PROTECTED] {
+cell-index = 0;
You have a whole lot of 'cell-index' properties through both these
trees, and they all look wrong. cell-index is a hack, which should be
avoided wherever practical - it should only be used when the index is
used to offset into some global register block, never simply to
differentiate (use reg for that) or name the devices (use aliases for
that).
OK, I can remove them from the TQM85*.dts files but I think the problem
is more general. It seems to be frequently used for similar purposes,
also in the code, at least in 2.6.26-rc4:
$ cd linux-2.6/arch/powerpc/boot/dts
$ grep -l 'cell-index' *.dts | wc -l
58
Wolfgang
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Tue, May 27, 2008 at 02:55:56PM -0700, Linus Torvalds wrote: On Wed, 28 May 2008, Benjamin Herrenschmidt wrote: A problem with __raw_ though is that they -also- don't do byteswap, Well, that's why there is __readl() and __raw_readl(), no? Neither does ordering, and __raw_readl() doesn't do byte-swap. This is where the lack of documentation causes arch maintainers a big problem. None of the semantics of __raw_readl vs __readl vs readl are documented _anywhere_. If you look at x86 as a template, there's no comments there about what the different variants are supposed to do or not do. So it's left up to arch maintainers to literally guess what should be done. That's precisely what I did when I implemented ARMs __raw_readl and friends. I guessed. And it was only after I read a few mails on lkml which suggested that readl and friends should always be LE that ARMs readl implementation started to use le32_to_cpu()... before that it had always been native endian. Again, lack of documentation... So, can the semantics of what's expected from these IO accessor functions be documented somewhere. Please? Before this thread gets lost in the depths of time? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
Geert Uytterhoeven [EMAIL PROTECTED] wrote: On Fri, 30 May 2008, Haavard Skinnemoen wrote: Maybe we need another interface that does not do byteswapping but provides stronger ordering guarantees? The byte swapping depends on the device/bus. Of course. But isn't it reasonable to assume that a device integrated on the same silicon as the CPU is connected to a somewhat sane bus which doesn't require any byte swapping? So what happened to the old idea of putting the accessor function pointers in the device/bus structure? Don't know. I think it sounds like overkill to replace a simple load or store with an indirect function call. Haavard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
slow MMC over SPI
All, has anybody made some investigations about performance of a SD/MMC card on SPI ? Actually I'm using various cards (different speed classes) on an SPI bus of a MPC8343 cpu. Everything is working fine basically, i.e. card is detected properly and block device can be mounted and used. SPI clock is adjusted to the card's capabilities and is running quite fast (30MHz). But between consecutive reads/writes there's a fixed gap of 2us thus yielding a poor performance of approx. 300KBytes/sec. The spi bus is utilized only ~10%. Any ideas where this comes from ? Ist it a fixed delay regarding to some kind of spec or is it possibly a spi driver/mmc layer issue ? regards, Andre Schwarz MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] celleb_scc_pciex endianness misannotations
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
index 31da84c..0e04f8f 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
@@ -217,7 +217,7 @@ static u##size scc_pciex_in##name(unsigned long port)
\
static void scc_pciex_ins##name(unsigned long p, void *b, unsigned long c) \
{ \
struct iowa_bus *bus = iowa_pio_find_bus(p);\
- u##size *dst = b; \
+ __le##size *dst = b;\
for (; c != 0; c--, dst++) \
*dst = cpu_to_le##size(__scc_pciex_in##name(bus-phb, p)); \
scc_pciex_io_flush(bus);\
@@ -231,10 +231,11 @@ static void scc_pciex_outs##name(unsigned long p, const
void *b, \
unsigned long c) \
{ \
struct iowa_bus *bus = iowa_pio_find_bus(p);\
- const u##size *src = b; \
+ const __le##size *src = b; \
for (; c != 0; c--, src++) \
__scc_pciex_out##name(bus-phb, le##size##_to_cpu(*src), p); \
}
+#define __le8 u8
#define cpu_to_le8(x) (x)
#define le8_to_cpu(x) (x)
PCIEX_PIO_FUNC(8, b)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] mpc52xx_gpio iomem annotations
Signed-off-by: Al Viro [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index 48da5df..8a455eb 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -100,7 +100,7 @@ static int mpc52xx_wkup_gpio_dir_in(struct gpio_chip *gc,
unsigned int gpio)
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
struct mpc52xx_gpiochip *chip = container_of(mm_gc,
struct mpc52xx_gpiochip, mmchip);
- struct mpc52xx_gpio_wkup *regs = mm_gc-regs;
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc-regs;
unsigned long flags;
spin_lock_irqsave(gpio_lock, flags);
@@ -122,7 +122,7 @@ static int
mpc52xx_wkup_gpio_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 mpc52xx_gpio_wkup *regs = mm_gc-regs;
+ struct mpc52xx_gpio_wkup __iomem *regs = mm_gc-regs;
struct mpc52xx_gpiochip *chip = container_of(mm_gc,
struct mpc52xx_gpiochip, mmchip);
unsigned long flags;
@@ -150,7 +150,7 @@ static int __devinit mpc52xx_wkup_gpiochip_probe(struct
of_device *ofdev,
const struct of_device_id *match)
{
struct mpc52xx_gpiochip *chip;
- struct mpc52xx_gpio_wkup *regs;
+ struct mpc52xx_gpio_wkup __iomem *regs;
struct of_gpio_chip *ofchip;
int ret;
@@ -260,7 +260,7 @@ static int mpc52xx_simple_gpio_dir_in(struct gpio_chip *gc,
unsigned int gpio)
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
struct mpc52xx_gpiochip *chip = container_of(mm_gc,
struct mpc52xx_gpiochip, mmchip);
- struct mpc52xx_gpio *regs = mm_gc-regs;
+ struct mpc52xx_gpio __iomem *regs = mm_gc-regs;
unsigned long flags;
spin_lock_irqsave(gpio_lock, flags);
@@ -284,7 +284,7 @@ mpc52xx_simple_gpio_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 mpc52xx_gpiochip *chip = container_of(mm_gc,
struct mpc52xx_gpiochip, mmchip);
- struct mpc52xx_gpio *regs = mm_gc-regs;
+ struct mpc52xx_gpio __iomem *regs = mm_gc-regs;
unsigned long flags;
spin_lock_irqsave(gpio_lock, flags);
@@ -312,7 +312,7 @@ static int __devinit mpc52xx_simple_gpiochip_probe(struct
of_device *ofdev,
{
struct mpc52xx_gpiochip *chip;
struct of_gpio_chip *ofchip;
- struct mpc52xx_gpio *regs;
+ struct mpc52xx_gpio __iomem *regs;
int ret;
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
@@ -387,7 +387,7 @@ mpc52xx_gpt_gpio_set(struct gpio_chip *gc, unsigned int
gpio, int val)
static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
- struct mpc52xx_gpt *regs = mm_gc-regs;
+ struct mpc52xx_gpt __iomem *regs = mm_gc-regs;
out_be32(regs-mode, 0x04);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
Jeremy Higdon wrote: We don't actually have that problem on the Altix. All writes issued by CPU X will be ordered with respect to each other. But writes by CPU X and CPU Y will not be, unless an mmiowb() is done by the original CPU before the second CPU writes. I.e. CPU X writel CPU X writel CPU X mmiowb CPU Y writel ... Note that this implies some sort of locking. Also note that if in the above, CPU Y did the mmiowb, that would not work. Hmmm, Then it's less bad than I thought - my apologies for the confusion. Would we be able to use Ben's trick of setting a per cpu flag in writel() then and checking that in spin unlock issuing the mmiowb() there if needed? Cheers, Jes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
* Linus Torvalds [EMAIL PROTECTED] wrote: Here's a UNTESTED patch for x86 that may or may not compile and work, and which serializes (on a compiler level) the IO accesses against regular memory accesses. Ok, so it at least boots on x86-32. Thus probably on x86-64 too (since the code is now shared). I didn't look at whether it generates much bigger code due to the potential extra serialization, but some of the code generation I looked at looked fine. IOW, it doesn't at least create any _obviously_ worse code, and it should be arguably safer than assuming the compiler does volatile accesses the way we want it to. ok, to pursue this topic of making readl*/writel*() more robust i picked up your patch into -tip and created a new topic branch for it: tip/x86/mmio. The patch passed initial light testing in -tip (~30 successful random self-builds and bootups on various mixed 32-bit/64-bit boxes) but it's still v2.6.27 material IMO. Failures in this area are subtle so there's no good way to tell whether it works as intended - we need wider testing. I've also added the tip/x86/mmio topic to tip/auto-x86-next rules as well so these changes will be picked up by tomorrow's linux-next tree as well, and by the next -mm iteration. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
Pavel Machek wrote: Still better than changing semantics of writel for _all_ drivers. If you are really sure driver does not depend on writel order, it is just a sed/// command, so I don't see any big code maintenance issues... This isn't changing the semantics for all drivers, it means it leaves it up to us to fix the drivers that hit the problem. Whereas the other way round we'd have to make some fairly big modifications to a large number of drivers, which the driver maintainers are likely to be reluctant to accept and maintain. It will be a constant chase to keep that in order. Cheers Jes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 1/2] mmc_spi: export probe and remove functions
On Sun, Jun 01, 2008 at 12:18:41PM +0200, Pierre Ossman wrote: On Mon, 26 May 2008 17:10:09 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote: Btw, this isn't actually drivers encapsulating. This is about making mmc_spi export some library function which could be used by other bindings. Think of usb_add_hcd() used by various drivers' bindings for e.g. drivers/usb/host/ehci-*.c. Though usb_add_hcd() is more generic than just EHCI bindings, but only because there is nothing to share between them. (for MMC over SPI bindings all we want to do is fill the platform data). There's a big difference. This depends on the perception. :-) usb_add_hcd() is designed specifically to be called by other, real probe functions. Yes, by convention (or better, by design). mmc_spi_probe() _is_ a probe function. Yes, so far. Also exporting it as a library function is very confusing. No, if designed/documented properly. Just imagine this (100% similarity to USB code): mmc_spi_create_hcd(mmc_spi_driver, dev, dev-bus_id); mmc_spi_add_hcd(dev, irq, irqflags); Maybe something like this? I don't like it so much, but given that you don't like to export functions from mmc_spi, we'll have to place some calls into the driver itself. :-/ And there is no easy way to do generic callbacks, since that way we'll have implement mmc_spi callbacks subsystem. :-) That's not a callback, but an explicit call to another module. All of this work looks a bit like trying to wedge a square piece into a round hole. It looks to me that the kernel needs a bit of restructuring to handle it. You can't really export every probe function of every platform device so that you can add OF hooks to it. From what I can tell, the OF stuff behaves very much like the PNP system on PCs. The information relayed is a bit more versatile though. Perhaps what is needed is a more advanced platform bus that is modeled after the PNP bus, but with the extra ability of handling the stuff currently crammed into the platform structures. mmc_spi would then be extended to be driver for the platform bus and we could have generic calls like platform_get_pin(dev, ro);. platform_get_pin()? Um, maybe platform_get_gpio(), as _irq()? Yes, this is doable (and someday this should be done). But this way we can pass only GPIOs and then teach mmc_spi to work with them directly (in addition to callbacks). But this is not enough, there is still no way to pass real platform data, such as: caps and ocr_mask. Any idea how to deliver these? Thanks, -- 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: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Sat, 31 May 2008 13:59:02 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Hi. On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: ok, I see what you are saying now; if a channel gets done during talitos_done processing, it'll trigger an interrupt and reset priv-status, leaving the tasklet in the dark as to which channel has done status, depending on how many channel dones it has already processed. I think the only solution here is to call flush_channel on each channel, regardless of the bits in the interrupt status - I'll send out a patch shortly. Out of curiosity, what is number of channels? I had simialar issue with typically four but some parts only have one. HIFN crypto driver and limited number of descriptor to 80 iirc, since with that number HIFN traversal did not show perfromance degradataion on Ghz x86. ok, I've been focusing on correctness for the time being. callback, during that time cached status and priv itself (and tail like in two simultaneous flushes) could change (or not?) I think you're talking about a different 'status' here; flush_channel's local 'status' doesn't resemble priv-status bits in any way, it looks at the descriptor header writeback bits for done status, on a per descriptor basis. It forwards this descriptor done vs. error status to the callback. priv itself won't change; it's uniquely associated to the device. I meant descriptor hdr value accessed via it - can it be checked in tasklet under the lock and in submit path without? Can they correlate somehow? I believe the check for a non-null request-desc (under lock) before the hdr value is accessed ensures this doesn't happen. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
Kumar Gala wrote: The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB - tristate PHY Device support and infrastructure + bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET What are the issues? The core _should_ be able to be built as a module. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Generating a FDT from an MHS file
I'm going to be spending most of this week bringing myself up to speed on how to use these mhs tools (as part of a larger project on partial reconfiguration on Xilinx PPC Virtex boards). For now, can someone help me understand how to run the fdt part of the program? I'd like to generate an FDT from an MHS file. I'm reading as much as I can independently, but I'd definitely appreciate some guidance to help me off the ground. Thanks, Jake Poteet ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: I meant descriptor hdr value accessed via it - can it be checked in tasklet under the lock and in submit path without? Can they correlate somehow? I believe the check for a non-null request-desc (under lock) before the hdr value is accessed ensures this doesn't happen. But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted attention. -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] phylib: Don't allow core of phylib to build as a module
The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB - tristate PHY Device support and infrastructure + bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET help -- 1.5.4.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Mon, Jun 02, 2008 at 10:11:02AM +0200, Haavard Skinnemoen wrote: Geert Uytterhoeven [EMAIL PROTECTED] wrote: On Fri, 30 May 2008, Haavard Skinnemoen wrote: Maybe we need another interface that does not do byteswapping but provides stronger ordering guarantees? The byte swapping depends on the device/bus. Of course. But isn't it reasonable to assume that a device integrated on the same silicon as the CPU is connected to a somewhat sane bus which doesn't require any byte swapping? No, unfortunately. :-( See the end of drivers/dma/fsldma.h. Likewise with Freescale's PCI host bridges; for some reason the bus itself being little endian led to the host bridge control registers also being little endian. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Mon, 2 Jun 2008 20:00:12 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: I meant descriptor hdr value accessed via it - can it be checked in tasklet under the lock and in submit path without? Can they correlate somehow? I believe the check for a non-null request-desc (under lock) before the hdr value is accessed ensures this doesn't happen. But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted attention. can you point where in the code your concern is? desc is assigned under head lock and cleared under tail lock, both after an smp_wmb. hdr data is assigned before desc is written, and read after desc is found to be !NULL (i.e, hdr access is governed by if (desc)). head and tail indices get advanced each within their corresponding locks. So afaict there shouldn't be a case where data pointed to by desc can be accessed by both the consumer and the producer at any one point in time. Does that help? Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Cleanup mpic nodes in .dts
On May 30, 2008, at 4:42 PM, Segher Boessenkool wrote: Removed clock-frequency and big-endian props as they aren't specified anywhere. If you remove big-endian, you'll have to provide some other way to get that information (like, some new compatible value). I'm all for big-endian but we don't spec this anywhere and aren't using it right now. So until we have an real need to start an extended mpic definition I'm getting rid of it. Dunno if we need clock-frequency. Not used today. This patch also removes built-in properties. I'm all for that, but the patch description didn't say it does. will add that to the commit message. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
On Mon, Jun 02, 2008 at 11:25:14AM -0500, Kumar Gala wrote: The core provides functions like phy_read/phy_write. Andy has recently introduced board level workaround/fixups. The problem is these workarounds tend to use phy_read/phy_write and the board/platform code is not built as modules. So why not have those platforms select PHYLIB? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
Kumar Gala wrote: On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote: Kumar Gala wrote: The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB -tristate PHY Device support and infrastructure +bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET What are the issues? The core _should_ be able to be built as a module. The core provides functions like phy_read/phy_write. Andy has recently introduced board level workaround/fixups. The problem is these workarounds tend to use phy_read/phy_write and the board/platform code is not built as modules. So we get errors like: arch/powerpc/platforms/built-in.o: In function `mpc8568_mds_phy_fixups': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/mpc85xx_mds.c:99: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/mpc85xx_mds.c:104: undefined reference to `phy_read' The whole world isn't embedded ppc, we use this stuff elsewhere too. You guys need to figure out something that doesn't require phylib be built-in on ALL platforms, but only the platforms that require it. Or, update the platform to not require built-in -- convert the board code to function pointers, and execute them later on somehow, for example. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote: Kumar Gala wrote: The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB - tristate PHY Device support and infrastructure + bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET What are the issues? The core _should_ be able to be built as a module. The core provides functions like phy_read/phy_write. Andy has recently introduced board level workaround/fixups. The problem is these workarounds tend to use phy_read/phy_write and the board/ platform code is not built as modules. So we get errors like: arch/powerpc/platforms/built-in.o: In function `mpc8568_mds_phy_fixups': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:99: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:104: undefined reference to `phy_read' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:110: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:115: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:120: undefined reference to `phy_read' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:125: undefined reference to `phy_read' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:132: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:138: undefined reference to `phy_read' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:144: undefined reference to `phy_write' arch/powerpc/platforms/built-in.o: In function `mpc8568_fixup_125_clock': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:68: undefined reference to `phy_read' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:73: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:78: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:83: undefined reference to `phy_read' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:88: undefined reference to `phy_write' arch/powerpc/platforms/built-in.o: In function `board_fixups': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:246: undefined reference to `phy_register_fixup_for_id' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:247: undefined reference to `phy_register_fixup_for_id' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:251: undefined reference to `phy_register_fixup_for_id' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:246: undefined reference to `phy_register_fixup_for_id' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:247: undefined reference to `phy_register_fixup_for_id' arch/powerpc/platforms/built-in.o:/home/galak/git/master/powerpc/arch/ powerpc/platforms/85xx/mpc85xx_mds.c:251: more undefined references to `phy_register_fixup_for_id' follow make: *** [.tmp_vmlinux1] Error 1 - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/8] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
On MPC86xx the watchdog could be enabled only at power-on-reset, and
could not be disabled afterwards. We must ping the watchdog from the
kernel until the userspace handles it.
MPC83xx CPUs are only differ in a way that watchdog could be disabled
once, but after it was enabled via software it becomes just the same
as MPC86xx.
Thus, to support MPC86xx I added the kernel timer which pings the
watchdog until the userspace opens it.
Since we implemented the timer, now we're able to implement proper
handling for the CONFIG_WATCHDOG_NOWAYOUT case, for MPC83xx and MPC86xx.
Also move the probe code into subsys_initcall, because we want start
pinging the watchdog ASAP, and misc devices are available in
subsys_initcall.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/watchdog/Kconfig |4 +-
drivers/watchdog/mpc83xx_wdt.c | 80
2 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 254d115..2929055 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -683,8 +683,8 @@ config 8xx_WDT
depends on 8xx
config 83xx_WDT
- tristate MPC83xx Watchdog Timer
- depends on PPC_83xx
+ tristate MPC83xx/MPC86xx Watchdog Timer
+ depends on PPC_83xx || PPC_86xx
config MV64X60_WDT
tristate MV64X60 (Marvell Discovery) Watchdog Timer
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
index 127d85e..19e3082 100644
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ b/drivers/watchdog/mpc83xx_wdt.c
@@ -1,10 +1,12 @@
/*
- * mpc83xx_wdt.c - MPC83xx watchdog userspace interface
+ * mpc83xx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
*
* Authors: Dave Updegraff [EMAIL PROTECTED]
* Kumar Gala [EMAIL PROTECTED]
* Attribution: from 83xx_wst: Florian Schirmer [EMAIL PROTECTED]
* ..and from sc520_wdt
+ * Copyright (c) 2008 MontaVista Software, Inc.
+ * Anton Vorontsov [EMAIL PROTECTED]
*
* Note: it appears that you can only actually ENABLE or DISABLE the thing
* once after POR. Once enabled, you cannot disable, and vice versa.
@@ -18,6 +20,7 @@
#include linux/fs.h
#include linux/init.h
#include linux/kernel.h
+#include linux/timer.h
#include linux/miscdevice.h
#include linux/of_platform.h
#include linux/module.h
@@ -39,6 +42,11 @@ struct mpc83xx_wdt {
u8 res2[0xF0];
};
+struct mpc83xx_wdt_type {
+ int prescaler;
+ bool hw_enabled;
+};
+
static struct mpc83xx_wdt __iomem *wd_base;
static u16 timeout = 0x;
@@ -51,6 +59,11 @@ module_param(reset, bool, 0);
MODULE_PARM_DESC(reset, Watchdog Interrupt/Reset Mode.
0 = interrupt, 1 = reset);
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started
+(default= __MODULE_STRING(WATCHDOG_NOWAYOUT) ));
+
/*
* We always prescale, but if someone really doesn't want to they can set this
* to 0
@@ -70,6 +83,22 @@ static void mpc83xx_wdt_keepalive(void)
spin_unlock(wdt_spinlock);
}
+static void mpc83xx_wdt_timer_ping(unsigned long arg);
+static DEFINE_TIMER(wdt_timer, mpc83xx_wdt_timer_ping, 0, 0);
+
+static void mpc83xx_wdt_timer_ping(unsigned long arg)
+{
+ mpc83xx_wdt_keepalive();
+ /* We're pinging it twice faster than needed, just to be sure. */
+ mod_timer(wdt_timer, jiffies + HZ * timeout_sec / 2);
+}
+
+static void mpc83xx_wdt_pr_warn(const char *msg)
+{
+ pr_crit(mpc83xx_wdt: %s, expect the %s soon!\n, msg,
+ reset ? reset : machine check exception);
+}
+
static ssize_t mpc83xx_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
@@ -85,7 +114,8 @@ static int mpc83xx_wdt_open(struct inode *inode, struct file
*file)
return -EBUSY;
/* Once we start the watchdog we can't stop it */
- __module_get(THIS_MODULE);
+ if (nowayout)
+ __module_get(THIS_MODULE);
/* Good, fire up the show */
if (prescale)
@@ -97,13 +127,17 @@ static int mpc83xx_wdt_open(struct inode *inode, struct
file *file)
out_be32(wd_base-swcrr, tmp);
+ del_timer_sync(wdt_timer);
+
return nonseekable_open(inode, file);
}
static int mpc83xx_wdt_release(struct inode *inode, struct file *file)
{
- printk(KERN_CRIT Unexpected close, not stopping watchdog!\n);
- mpc83xx_wdt_keepalive();
+ if (!nowayout)
+ mpc83xx_wdt_timer_ping(0);
+ else
+ mpc83xx_wdt_pr_warn(watchdog closed);
clear_bit(0, wdt_is_open);
return 0;
}
@@ -154,15 +188,25 @@ static int __devinit mpc83xx_wdt_probe(struct of_device
*ofdev,
const struct of_device_id *match)
{
int ret;
+
[PATCH 0/8 v4] mpc83xx_wdt rework, support for mpc8610 and mpc8xx
Hi all, No comments on the previous version for two weeks... resending once again. Changes since v3: - None. Simply resending, plus adding Andrew Morton and linux-kernel to Cc, since I'm constantly getting bounces from Wim Van Sebroeck's email: - - - - [EMAIL PROTECTED]: 213.249.96.99 does not like recipient. Remote host said: 450 Client host rejected: cannot find your hostname, [85.21.88.2] Giving up on 213.249.96.99. I'm not going to try again; this message has been in the queue too long. - - - - Not sure whose fault is it though. Andrew, if Wim will not get this series and there will no objections, could you please pick [WATCHDOG] ones? Changes since v2: - New patch to fix current driver's checkpatch issues; - New patch supporting MPC8xx watchdogs; - Removed MODULE_ALIAS(platform:mpc83xx_wdt), since this driver is no longer on the platform bus; - When renaming the driver also mention what kind of CPUs we support. Also give a pointer for BookE watchdog driver. Though BookE users will not see the MPC8xxx driver at all, because we're explicitly listing the CPU families in depends on. But this tip might be useful for developers. - Scott Wood noticed that we don't need device_type anymore. I thought that OpenFirmware defines this type, but google didn't prove that. So I just removed the device_type. Changes since v1: - Scott Wood asked for mpc83xx_wdt on multiplatform kernels. Done via OF platform driver; - Kumar Gala asked for mpc83xx_wdt - mpc8xxx_wdt rename. Done in two steps; - Segher Boessenkool noticed a negligence in the wdt device tree node. Fixed by removing mpc83xx_wdt compatible entry. -- 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: [PATCH] phylib: Don't allow core of phylib to build as a module
On Mon, Jun 02, 2008 at 11:25:14AM -0500, Kumar Gala wrote: On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote: Kumar Gala wrote: The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB - tristate PHY Device support and infrastructure + bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET What are the issues? The core _should_ be able to be built as a module. The core provides functions like phy_read/phy_write. Andy has recently introduced board level workaround/fixups. The problem is these workarounds tend to use phy_read/phy_write and the board/platform code is not built as modules. So we get errors like: arch/powerpc/platforms/built-in.o: In function `mpc8568_mds_phy_fixups': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:99: undefined reference to `phy_write' ... At first glance PHYLIB=n might also cause similar problems. Please send me the failing .config and I'll cook up a fix. - k cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] [WATCHDOG] mpc83xx_wdt: fix checkpatch issues
Quite tired of these warnings ;-), checkpatch spitting them when
seeing the rename patch.
WARNING: Use #include linux/io.h instead of asm/io.h
#25: FILE: watchdog/mpc83xx_wdt.c:25:
+#include asm/io.h
WARNING: Use #include linux/uaccess.h instead of asm/uaccess.h
#26: FILE: watchdog/mpc83xx_wdt.c:26:
+#include asm/uaccess.h
WARNING: line over 80 characters
#45: FILE: watchdog/mpc83xx_wdt.c:45:
+MODULE_PARM_DESC(timeout, Watchdog timeout in ticks. (0timeout65536,
default=65535);
WARNING: line over 80 characters
#49: FILE: watchdog/mpc83xx_wdt.c:49:
+MODULE_PARM_DESC(reset, Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 =
reset);
WARNING: space prohibited between function name and open parenthesis '('
#164: FILE: watchdog/mpc83xx_wdt.c:164:
+ wd_base = ioremap(r-start, sizeof (struct mpc83xx_wdt));
total: 0 errors, 5 warnings, 230 lines checked
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/watchdog/mpc83xx_wdt.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
index b16c5cd..6905712 100644
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ b/drivers/watchdog/mpc83xx_wdt.c
@@ -22,8 +22,8 @@
#include linux/platform_device.h
#include linux/module.h
#include linux/watchdog.h
-#include asm/io.h
-#include asm/uaccess.h
+#include linux/io.h
+#include linux/uaccess.h
struct mpc83xx_wdt {
__be32 res0;
@@ -42,11 +42,13 @@ static struct mpc83xx_wdt __iomem *wd_base;
static u16 timeout = 0x;
module_param(timeout, ushort, 0);
-MODULE_PARM_DESC(timeout, Watchdog timeout in ticks. (0timeout65536,
default=65535);
+MODULE_PARM_DESC(timeout, Watchdog timeout in ticks.
+(0timeout65536, default=65535);
static int reset = 1;
module_param(reset, bool, 0);
-MODULE_PARM_DESC(reset, Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 =
reset);
+MODULE_PARM_DESC(reset, Watchdog Interrupt/Reset Mode.
+0 = interrupt, 1 = reset);
/*
* We always prescale, but if someone really doesn't want to they can set this
@@ -161,7 +163,7 @@ static int __devinit mpc83xx_wdt_probe(struct
platform_device *dev)
goto err_out;
}
- wd_base = ioremap(r-start, sizeof (struct mpc83xx_wdt));
+ wd_base = ioremap(r-start, sizeof(struct mpc83xx_wdt));
if (wd_base == NULL) {
ret = -ENOMEM;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted attention. can you point where in the code your concern is? talitos_submit() writes to hdr (initially I think?) without locks. It is read in flush_channel() under tail lock, but then it is dropped, so I rised a question, if it can be modified during that time, since if it can, status value, calculated from it, can be different and thus error check result can be false. Or this is not an issue? -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/8] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
Rename the driver because now we support some MPC86xx processors.
There are no changes to the mpc83xx_wdt.c file, yet. When possible, we do
file renames and changes separately (because Linus once asked so, because
it helps git to track the renamed files).
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/watchdog/Kconfig | 11 ++-
drivers/watchdog/Makefile |2 +-
drivers/watchdog/mpc83xx_wdt.c | 294
drivers/watchdog/mpc8xxx_wdt.c | 294
4 files changed, 304 insertions(+), 297 deletions(-)
delete mode 100644 drivers/watchdog/mpc83xx_wdt.c
create mode 100644 drivers/watchdog/mpc8xxx_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2929055..008eaa6 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -682,9 +682,16 @@ config 8xx_WDT
tristate MPC8xx Watchdog Timer
depends on 8xx
-config 83xx_WDT
- tristate MPC83xx/MPC86xx Watchdog Timer
+config 8xxx_WDT
+ tristate MPC8xxx Platform Watchdog Timer
depends on PPC_83xx || PPC_86xx
+ help
+ This driver is for a SoC level watchdog that exists on some
+ Freescale PowerPC processors. So far this driver supports:
+ - MPC83xx watchdogs
+ - MPC86xx watchdogs
+
+ For BookE processors (MPC85xx) use the BOOKE_WDT driver instead.
config MV64X60_WDT
tristate MV64X60 (Marvell Discovery) Watchdog Timer
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f3fb170..d5782f9 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -102,7 +102,7 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
# POWERPC Architecture
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
-obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
+obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
deleted file mode 100644
index 19e3082..000
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ /dev/null
@@ -1,294 +0,0 @@
-/*
- * mpc83xx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
- *
- * Authors: Dave Updegraff [EMAIL PROTECTED]
- * Kumar Gala [EMAIL PROTECTED]
- * Attribution: from 83xx_wst: Florian Schirmer [EMAIL PROTECTED]
- * ..and from sc520_wdt
- * Copyright (c) 2008 MontaVista Software, Inc.
- * Anton Vorontsov [EMAIL PROTECTED]
- *
- * Note: it appears that you can only actually ENABLE or DISABLE the thing
- * once after POR. Once enabled, you cannot disable, and vice versa.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include linux/fs.h
-#include linux/init.h
-#include linux/kernel.h
-#include linux/timer.h
-#include linux/miscdevice.h
-#include linux/of_platform.h
-#include linux/module.h
-#include linux/watchdog.h
-#include linux/io.h
-#include linux/uaccess.h
-#include sysdev/fsl_soc.h
-
-struct mpc83xx_wdt {
- __be32 res0;
- __be32 swcrr; /* System watchdog control register */
-#define SWCRR_SWTC 0x /* Software Watchdog Time Count. */
-#define SWCRR_SWEN 0x0004 /* Watchdog Enable bit. */
-#define SWCRR_SWRI 0x0002 /* Software Watchdog Reset/Interrupt Select
bit.*/
-#define SWCRR_SWPR 0x0001 /* Software Watchdog Counter Prescale bit. */
- __be32 swcnr; /* System watchdog count register */
- u8 res1[2];
- __be16 swsrr; /* System watchdog service register */
- u8 res2[0xF0];
-};
-
-struct mpc83xx_wdt_type {
- int prescaler;
- bool hw_enabled;
-};
-
-static struct mpc83xx_wdt __iomem *wd_base;
-
-static u16 timeout = 0x;
-module_param(timeout, ushort, 0);
-MODULE_PARM_DESC(timeout, Watchdog timeout in ticks.
-(0timeout65536, default=65535);
-
-static int reset = 1;
-module_param(reset, bool, 0);
-MODULE_PARM_DESC(reset, Watchdog Interrupt/Reset Mode.
-0 = interrupt, 1 = reset);
-
-static int nowayout = WATCHDOG_NOWAYOUT;
-module_param(nowayout, int, 0);
-MODULE_PARM_DESC(nowayout, Watchdog cannot be stopped once started
-(default= __MODULE_STRING(WATCHDOG_NOWAYOUT) ));
-
-/*
- * We always prescale, but if someone really doesn't want to they can set this
- * to 0
- */
-static int prescale = 1;
-static unsigned int timeout_sec;
-
-static unsigned long wdt_is_open;
-static DEFINE_SPINLOCK(wdt_spinlock);
-
-static void mpc83xx_wdt_keepalive(void)
-{
- /* Ping the WDT */
- spin_lock(wdt_spinlock);
- out_be16(wd_base-swsrr, 0x556c);
- out_be16(wd_base-swsrr, 0xaa39);
- spin_unlock(wdt_spinlock);
-}
-
-static
[PATCH 8/8] [POWERPC] 86xx: mpc8610_hpcd: add watchdog node
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index fa9c297..bb0395b 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -204,6 +204,11 @@
fsl,has-rstcr;
};
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8610-wdt;
+ reg = 0xe4000 0x100;
+ };
+
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
cell-index = 0;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/8] [WATCHDOG] mpc8xxx_wdt: add support for MPC8xx watchdogs
The mpc8xxx_wdt driver is using two registers: SWSRR to push magic
numbers, and SWCRR to control the watchdog. Both registers are available
on the MPC8xx, and seem to have the same offsets and semantics as in
MPC83xx/MPC86xx watchdogs. The only difference is prescale value. So this
driver simply works on the MPC8xx CPUs.
One quirk is needed for the MPC8xx, though. It has small prescale value
and slow CPU, so the watchdog resets board prior to the driver has time
to load. To solve this we should split initialization in two steps: start
ping the watchdog early, and register the watchdog userspace interface
later.
MPC823 seem to be the first CPU in MPC8xx line, so we use fsl,mpc823-wdt
compatible matching.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Tested-by: Jochen Friedrich [EMAIL PROTECTED]
---
drivers/watchdog/Kconfig |3 +-
drivers/watchdog/mpc8xxx_wdt.c | 44 ++--
2 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 008eaa6..f9e617b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -684,10 +684,11 @@ config 8xx_WDT
config 8xxx_WDT
tristate MPC8xxx Platform Watchdog Timer
- depends on PPC_83xx || PPC_86xx
+ depends on PPC_8xx || PPC_83xx || PPC_86xx
help
This driver is for a SoC level watchdog that exists on some
Freescale PowerPC processors. So far this driver supports:
+ - MPC8xx watchdogs
- MPC83xx watchdogs
- MPC86xx watchdogs
diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
index 2f0681f..0f7e165 100644
--- a/drivers/watchdog/mpc8xxx_wdt.c
+++ b/drivers/watchdog/mpc8xxx_wdt.c
@@ -1,5 +1,5 @@
/*
- * mpc8xxx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
+ * mpc8xxx_wdt.c - MPC8xx/MPC83xx/MPC86xx watchdog userspace interface
*
* Authors: Dave Updegraff [EMAIL PROTECTED]
* Kumar Gala [EMAIL PROTECTED]
@@ -207,13 +207,6 @@ static int __devinit mpc8xxx_wdt_probe(struct of_device
*ofdev,
goto err_unmap;
}
- ret = misc_register(mpc8xxx_wdt_miscdev);
- if (ret) {
- pr_err(cannot register miscdev on minor=%d (err=%d)\n,
- WATCHDOG_MINOR, ret);
- goto err_unmap;
- }
-
/* Calculate the timeout in seconds */
if (prescale)
timeout_sec = (timeout * wdt_type-prescaler) / freq;
@@ -234,6 +227,7 @@ static int __devinit mpc8xxx_wdt_probe(struct of_device
*ofdev,
return 0;
err_unmap:
iounmap(wd_base);
+ wd_base = NULL;
return ret;
}
@@ -261,6 +255,12 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
.hw_enabled = true,
},
},
+ {
+ .compatible = fsl,mpc823-wdt,
+ .data = (struct mpc8xxx_wdt_type) {
+ .prescaler = 0x800,
+ },
+ },
{},
};
MODULE_DEVICE_TABLE(of, mpc8xxx_wdt_match);
@@ -275,20 +275,42 @@ static struct of_platform_driver mpc8xxx_wdt_driver = {
},
};
+/*
+ * We do wdt initialization in two steps: arch_initcall probes the wdt
+ * very early to start pinging the watchdog (misc devices are not yet
+ * available), and later module_init() just registers the misc device.
+ */
+static int __init mpc8xxx_wdt_init_late(void)
+{
+ int ret;
+
+ if (!wd_base)
+ return -ENODEV;
+
+ ret = misc_register(mpc8xxx_wdt_miscdev);
+ if (ret) {
+ pr_err(cannot register miscdev on minor=%d (err=%d)\n,
+ WATCHDOG_MINOR, ret);
+ return ret;
+ }
+ return 0;
+}
+module_init(mpc8xxx_wdt_init_late);
+
static int __init mpc8xxx_wdt_init(void)
{
return of_register_platform_driver(mpc8xxx_wdt_driver);
}
+arch_initcall(mpc8xxx_wdt_init);
static void __exit mpc8xxx_wdt_exit(void)
{
of_unregister_platform_driver(mpc8xxx_wdt_driver);
}
-
-subsys_initcall(mpc8xxx_wdt_init);
module_exit(mpc8xxx_wdt_exit);
MODULE_AUTHOR(Dave Updegraff, Kumar Gala);
-MODULE_DESCRIPTION(Driver for watchdog timer in MPC83xx/MPC86xx uProcessors);
+MODULE_DESCRIPTION(Driver for watchdog timer in MPC8xx/MPC83xx/MPC86xx
+ uProcessors);
MODULE_LICENSE(GPL);
MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/8] [POWERPC] fsl_soc: remove mpc83xx_wdt code
mpc83xx_wdt is the OF driver now, so we don't need fsl_soc constructor.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 46 -
1 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index a5ceeef..32a3ac8 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -545,52 +545,6 @@ err:
arch_initcall(fsl_i2c_of_init);
#endif
-#ifdef CONFIG_PPC_83xx
-static int __init mpc83xx_wdt_init(void)
-{
- struct resource r;
- struct device_node *np;
- struct platform_device *dev;
- u32 freq = fsl_get_sys_freq();
- int ret;
-
- np = of_find_compatible_node(NULL, watchdog, mpc83xx_wdt);
-
- if (!np) {
- ret = -ENODEV;
- goto nodev;
- }
-
- memset(r, 0, sizeof(r));
-
- ret = of_address_to_resource(np, 0, r);
- if (ret)
- goto err;
-
- dev = platform_device_register_simple(mpc83xx_wdt, 0, r, 1);
- if (IS_ERR(dev)) {
- ret = PTR_ERR(dev);
- goto err;
- }
-
- ret = platform_device_add_data(dev, freq, sizeof(freq));
- if (ret)
- goto unreg;
-
- of_node_put(np);
- return 0;
-
-unreg:
- platform_device_unregister(dev);
-err:
- of_node_put(np);
-nodev:
- return ret;
-}
-
-arch_initcall(mpc83xx_wdt_init);
-#endif
-
static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
{
if (!phy_type)
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/8] [WATCHDOG] mpc8xxx_wdt: various renames, mostly s/mpc83xx/mpc8xxx/g
mpc83xx_wdt.c renamed to mpc8xxx_wdt.c, now we can do various renames
in the file itself.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/watchdog/mpc8xxx_wdt.c | 104
1 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
index 19e3082..2f0681f 100644
--- a/drivers/watchdog/mpc8xxx_wdt.c
+++ b/drivers/watchdog/mpc8xxx_wdt.c
@@ -1,5 +1,5 @@
/*
- * mpc83xx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
+ * mpc8xxx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
*
* Authors: Dave Updegraff [EMAIL PROTECTED]
* Kumar Gala [EMAIL PROTECTED]
@@ -29,7 +29,7 @@
#include linux/uaccess.h
#include sysdev/fsl_soc.h
-struct mpc83xx_wdt {
+struct mpc8xxx_wdt {
__be32 res0;
__be32 swcrr; /* System watchdog control register */
#define SWCRR_SWTC 0x /* Software Watchdog Time Count. */
@@ -42,12 +42,12 @@ struct mpc83xx_wdt {
u8 res2[0xF0];
};
-struct mpc83xx_wdt_type {
+struct mpc8xxx_wdt_type {
int prescaler;
bool hw_enabled;
};
-static struct mpc83xx_wdt __iomem *wd_base;
+static struct mpc8xxx_wdt __iomem *wd_base;
static u16 timeout = 0x;
module_param(timeout, ushort, 0);
@@ -74,7 +74,7 @@ static unsigned int timeout_sec;
static unsigned long wdt_is_open;
static DEFINE_SPINLOCK(wdt_spinlock);
-static void mpc83xx_wdt_keepalive(void)
+static void mpc8xxx_wdt_keepalive(void)
{
/* Ping the WDT */
spin_lock(wdt_spinlock);
@@ -83,31 +83,31 @@ static void mpc83xx_wdt_keepalive(void)
spin_unlock(wdt_spinlock);
}
-static void mpc83xx_wdt_timer_ping(unsigned long arg);
-static DEFINE_TIMER(wdt_timer, mpc83xx_wdt_timer_ping, 0, 0);
+static void mpc8xxx_wdt_timer_ping(unsigned long arg);
+static DEFINE_TIMER(wdt_timer, mpc8xxx_wdt_timer_ping, 0, 0);
-static void mpc83xx_wdt_timer_ping(unsigned long arg)
+static void mpc8xxx_wdt_timer_ping(unsigned long arg)
{
- mpc83xx_wdt_keepalive();
+ mpc8xxx_wdt_keepalive();
/* We're pinging it twice faster than needed, just to be sure. */
mod_timer(wdt_timer, jiffies + HZ * timeout_sec / 2);
}
-static void mpc83xx_wdt_pr_warn(const char *msg)
+static void mpc8xxx_wdt_pr_warn(const char *msg)
{
- pr_crit(mpc83xx_wdt: %s, expect the %s soon!\n, msg,
+ pr_crit(mpc8xxx_wdt: %s, expect the %s soon!\n, msg,
reset ? reset : machine check exception);
}
-static ssize_t mpc83xx_wdt_write(struct file *file, const char __user *buf,
+static ssize_t mpc8xxx_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
if (count)
- mpc83xx_wdt_keepalive();
+ mpc8xxx_wdt_keepalive();
return count;
}
-static int mpc83xx_wdt_open(struct inode *inode, struct file *file)
+static int mpc8xxx_wdt_open(struct inode *inode, struct file *file)
{
u32 tmp = SWCRR_SWEN;
if (test_and_set_bit(0, wdt_is_open))
@@ -132,17 +132,17 @@ static int mpc83xx_wdt_open(struct inode *inode, struct
file *file)
return nonseekable_open(inode, file);
}
-static int mpc83xx_wdt_release(struct inode *inode, struct file *file)
+static int mpc8xxx_wdt_release(struct inode *inode, struct file *file)
{
if (!nowayout)
- mpc83xx_wdt_timer_ping(0);
+ mpc8xxx_wdt_timer_ping(0);
else
- mpc83xx_wdt_pr_warn(watchdog closed);
+ mpc8xxx_wdt_pr_warn(watchdog closed);
clear_bit(0, wdt_is_open);
return 0;
}
-static int mpc83xx_wdt_ioctl(struct inode *inode, struct file *file,
+static int mpc8xxx_wdt_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
void __user *argp = (void __user *)arg;
@@ -150,7 +150,7 @@ static int mpc83xx_wdt_ioctl(struct inode *inode, struct
file *file,
static struct watchdog_info ident = {
.options = WDIOF_KEEPALIVEPING,
.firmware_version = 1,
- .identity = MPC83xx,
+ .identity = MPC8xxx,
};
switch (cmd) {
@@ -160,7 +160,7 @@ static int mpc83xx_wdt_ioctl(struct inode *inode, struct
file *file,
case WDIOC_GETBOOTSTATUS:
return put_user(0, p);
case WDIOC_KEEPALIVE:
- mpc83xx_wdt_keepalive();
+ mpc8xxx_wdt_keepalive();
return 0;
case WDIOC_GETTIMEOUT:
return put_user(timeout_sec, p);
@@ -169,27 +169,27 @@ static int mpc83xx_wdt_ioctl(struct inode *inode, struct
file *file,
}
}
-static const struct file_operations mpc83xx_wdt_fops = {
+static const struct file_operations mpc8xxx_wdt_fops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
- .write = mpc83xx_wdt_write,
- .ioctl
[RFC PATCH] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
Hi all,
Here are the notorious bindings. I believe I addressed Segher's comments.
Major changes are in the LEDs bindings, I removed all the cruft and now
using aliases mechanism to determine LEDs' trigger.
Comments, suggestions?
Thanks,
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 117 ++
1 files changed, 117 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 1ad903a..2a452c3 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -62,6 +62,10 @@ Table of Contents
s) Freescale on board FPGA
t) Freescael MSI interrupt controller
u) Freescale General-purpose Timers Module
+ v) Freescale QUICC Engine USB Controller
+ w) Freescale MCU with MPC8349E-mITX compatible firmware
+ x) Freescale Localbus UPM programmed to work with NAND flash
+ y) LEDs on GPIOs
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@@ -2970,6 +2974,119 @@ platforms are moved over to use the
flattened-device-tree model.
clock-frequency = 0;
};
+v) Freescale QUICC Engine USB Controller
+
+Required properties:
+ - compatible : should be fsl,chip-qe-usb, fsl,mpc8323-qe-usb;
+ - reg : the first two cells should contain usb registers location and
+length, the next two two cells should contain PRAM location and
+length.
+ - interrupts : should contain USB interrupt.
+ - interrupt-parent : interrupt source phandle.
+ - fsl,fullspeed-clock : specifies the full speed USB clock source:
+none: clock source is disabled
+brg1 through brg16: clock source is BRG1-BRG16, respectively
+clk1 through clk24: clock source is CLK1-CLK24, respectively
+ - fsl,lowspeed-clock : specifies the low speed USB clock source:
+none: clock source is disabled
+brg1 through brg16: clock source is BRG1-BRG16, respectively
+clk1 through clk24: clock source is CLK1-CLK24, respectively
+ - hub-power-budget : optional, USB power budget for the root hub, in mA.
+ - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
+USBRN, SPEED (optional), and POWER (optional).
+
+Example:
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8360-qe-usb, fsl,mpc8323-qe-usb;
+ reg = 0x6c0 0x40 0x8b00 0x100;
+ interrupts = 11;
+ interrupt-parent = qeic;
+ fsl,fullspeed-clock = clk21;
+ gpios = qe_pio_b 2 0 /* USBOE */
+qe_pio_b 3 0 /* USBTP */
+qe_pio_b 8 0 /* USBTN */
+qe_pio_b 9 0 /* USBRP */
+qe_pio_b 11 0 /* USBRN */
+qe_pio_e 20 0 /* SPEED */
+qe_pio_e 21 0 /* POWER */;
+ };
+
+w) Freescale MCU with MPC8349E-mITX compatible firmware
+
+Required properties:
+ - compatible : fsl,mcu-chip-board, fsl,mcu-mpc8349emitx;
+ - reg : should specify I2C address (0x0a).
+ - #gpio-cells : should be 2.
+ - gpio-controller : should be present;
+
+Example:
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = fsl,mc9s08qg8-mpc8349emitx,
+fsl,mcu-mpc8349emitx;
+ reg = 0x0a;
+ gpio-controller;
+ };
+
+x) Freescale Localbus UPM programmed to work with NAND flash
+
+ Required properties:
+ - compatible : fsl,upm-nand.
+ - reg : should specify localbus chip select and size used for the chip.
+ - fsl,upm-addr-offset : UPM pattern offset for the address latch.
+ - fsl,upm-cmd-offset : UPM pattern offset for the command latch.
+ - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
+
+ Example:
+
+ [EMAIL PROTECTED],0 {
+ compatible = fsl,upm-nand;
+ reg = 1 0 1;
+ fsl,upm-addr-offset = 16;
+ fsl,upm-cmd-offset = 8;
+ gpios = qe_pio_e 18 0;
+
+ flash {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = stmicro,NAND512W3A2BN6E;
+
+ [EMAIL PROTECTED] {
+ ...
+ };
+ };
+ };
+
+y) LEDs on GPIOs
+
+Required properties:
+ - compatible : should be gpio-led.
+ - gpios : should specify LED GPIO.
+
+Example:
+
+ pwr_led: [EMAIL PROTECTED] {
+ compatible = gpio-led;
+ gpios = mcu_pio 0 1;
+ };
+
+ hdd_led: [EMAIL PROTECTED] {
+ compatible = gpio-led;
+ gpios = mcu_pio 1 0;
+
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote: Kumar Gala wrote: On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote: Kumar Gala wrote: The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB -tristate PHY Device support and infrastructure +bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET What are the issues? The core _should_ be able to be built as a module. The core provides functions like phy_read/phy_write. Andy has recently introduced board level workaround/fixups. The problem is these workarounds tend to use phy_read/phy_write and the board/ platform code is not built as modules. So we get errors like: arch/powerpc/platforms/built-in.o: In function `mpc8568_mds_phy_fixups': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:99: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:104: undefined reference to `phy_read' The whole world isn't embedded ppc, we use this stuff elsewhere too. You guys need to figure out something that doesn't require phylib be built-in on ALL platforms, but only the platforms that require it. I wasn't suggesting we build it always, just not let it be built as a module. Or, update the platform to not require built-in -- convert the board code to function pointers, and execute them later on somehow, for example. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
On Mon, 2 Jun 2008, Adrian Bunk wrote: On Mon, Jun 02, 2008 at 11:25:14AM -0500, Kumar Gala wrote: On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote: Kumar Gala wrote: The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB - tristate PHY Device support and infrastructure + bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET What are the issues? The core _should_ be able to be built as a module. The core provides functions like phy_read/phy_write. Andy has recently introduced board level workaround/fixups. The problem is these workarounds tend to use phy_read/phy_write and the board/platform code is not built as modules. So we get errors like: arch/powerpc/platforms/built-in.o: In function `mpc8568_mds_phy_fixups': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/ mpc85xx_mds.c:99: undefined reference to `phy_write' ... At first glance PHYLIB=n might also cause similar problems. Please send me the failing .config and I'll cook up a fix. - k cu Adrian defconfig attached. I think Scott might be right in that the simple fix would be to select PHYLIB from the MPC8568_MDS config in arch/powerpc/platforms/85xx/Kconfig. - k phylib-module.config.gz Description: GNU Zip compressed data ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Mon, 2 Jun 2008 21:57:51 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted attention. can you point where in the code your concern is? talitos_submit() writes to hdr (initially I think?) without locks. ok, the desc whose hdr is being written was allocated by talitos_submit's caller, and it hasn't been made part of the circular buffer at that point. It becomes a part of the buffer (eligible for contention with the consumer side) when desc is assigned. It is read in flush_channel() under tail lock, but then it is dropped, so I rised a question, if it can be modified during that time, since if it can, status value, calculated from it, can be different and thus error check result can be false. Or this is not an issue? it would be an issue if flush_cannel didn't save off the data required to call the callback with in saved_req. flush_channel does this on purpose to be able to call the callback outside of lock (as is commented). Note desc gets assigned NULL prior to releasing the lock, after copying its contents to saved_req. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote:
Kumar Gala wrote:
On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
Kumar Gala wrote:
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that the bus driver and core need to be built into the kernel.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Jeff, please consider this for 2.6.26 as w/o it we get build issues
if phylib is config'd as a module on ppc.
drivers/net/phy/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 6eb2d31..ab04cc7 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig PHYLIB
-tristate PHY Device support and infrastructure
+bool PHY Device support and infrastructure
depends on !S390
depends on NET_ETHERNET
What are the issues?
The core _should_ be able to be built as a module.
The core provides functions like phy_read/phy_write. Andy has
recently introduced board level workaround/fixups. The problem is
these workarounds tend to use phy_read/phy_write and the board/
platform code is not built as modules.
So we get errors like:
arch/powerpc/platforms/built-in.o: In function
`mpc8568_mds_phy_fixups':
/home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/
mpc85xx_mds.c:99: undefined reference to `phy_write'
/home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/
mpc85xx_mds.c:104: undefined reference to `phy_read'
The whole world isn't embedded ppc, we use this stuff elsewhere too.
You guys need to figure out something that doesn't require phylib be
built-in on ALL platforms, but only the platforms that require it.
Or, update the platform to not require built-in -- convert the board
code to function pointers, and execute them later on somehow, for
example.
If you really think the core of the phylib should be able to be built
as a module than we could possibly add function pointers to phy_dev to
do the real phy_read()/phy_write() and change phy_read/_write to look
like:
int phy_read(struct phy_device *phydev, u16 regnum) {
return phydev-read(phydev, regnum);
}
int phy_write(struct phy_device *phydev, u16 regnum, u16 val) {
return phydev-write(phydev, regnum, val);
}
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] Cleanup mpic nodes in .dts
Removed clock-frequency, big-endian, and built-in props as they aren't
specified anywhere. Also added compatible = chrp,open-pic in the
places it was missing.
---
Updated the commit message to be more explicit.
(in my powerpc.git powerpc-next branch)
- k
Documentation/powerpc/booting-without-of.txt |6 --
arch/powerpc/boot/dts/mpc7448hpc2.dts|2 --
arch/powerpc/boot/dts/mpc8540ads.dts |2 --
arch/powerpc/boot/dts/mpc8541cds.dts |2 --
arch/powerpc/boot/dts/mpc8544ds.dts |2 --
arch/powerpc/boot/dts/mpc8548cds.dts |2 --
arch/powerpc/boot/dts/mpc8555cds.dts |2 --
arch/powerpc/boot/dts/mpc8560ads.dts |1 +
arch/powerpc/boot/dts/mpc8568mds.dts |2 --
arch/powerpc/boot/dts/mpc8572ds.dts |2 --
arch/powerpc/boot/dts/mpc8610_hpcd.dts |2 --
arch/powerpc/boot/dts/mpc8641_hpcn.dts |2 --
arch/powerpc/boot/dts/sbc8548.dts|2 --
arch/powerpc/boot/dts/sbc8560.dts|2 +-
arch/powerpc/boot/dts/storcenter.dts |1 +
arch/powerpc/boot/dts/stx_gp3_8560.dts |1 +
arch/powerpc/boot/dts/tqm8540.dts|1 +
arch/powerpc/boot/dts/tqm8541.dts|1 +
arch/powerpc/boot/dts/tqm8555.dts|1 +
arch/powerpc/boot/dts/tqm8560.dts|1 +
20 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index c67d2f5..948f641 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1363,14 +1363,11 @@ platforms are moved over to use the
flattened-device-tree model.
[EMAIL PROTECTED] {
linux,phandle = 4;
- clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
reg = 4 4;
- built-in;
compatible = chrp,open-pic;
device_type = open-pic;
- big-endian;
};
@@ -3663,14 +3660,11 @@ not necessary as they are usually the same as the root
node.
[EMAIL PROTECTED] {
linux,phandle = 4;
- clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
reg = 4 4;
- built-in;
compatible = chrp,open-pic;
device_type = open-pic;
-big-endian;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts
b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 4936349..705c23c 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -124,14 +124,12 @@
};
mpic: [EMAIL PROTECTED] {
- clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x7400 0x400;
compatible = chrp,open-pic;
device_type = open-pic;
- big-endian;
};
[EMAIL PROTECTED] {
compatible = tsi108-pci;
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts
b/arch/powerpc/boot/dts/mpc8540ads.dts
index 18033ed..58e165e 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -165,14 +165,12 @@
interrupt-parent = mpic;
};
mpic: [EMAIL PROTECTED] {
- clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
- big-endian;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts
b/arch/powerpc/boot/dts/mpc8541cds.dts
index 663c7c5..21ebe7c 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -148,14 +148,12 @@
};
mpic: [EMAIL PROTECTED] {
- clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 0x4 0x4;
compatible = chrp,open-pic;
device_type = open-pic;
-big-endian;
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts
[PATCH v2] [POWERPC] 85xx: Add next-level-cache property
Added next-level-cache to the L1 and a reference to the new L2 label.
This is per the ePAPR 0.94 spec. Since we are't really dependent on this
today we aren't supporting the legacy l2-cache phandle that is specified
in the PPC v2.1 OF Binding spec.
---
Updated the commit message to be more explicit about rationale.
(in my powerpc.git powerpc-next branch)
- k
arch/powerpc/boot/dts/ksi8560.dts |3 ++-
arch/powerpc/boot/dts/mpc8540ads.dts |3 ++-
arch/powerpc/boot/dts/mpc8541cds.dts |3 ++-
arch/powerpc/boot/dts/mpc8544ds.dts|3 ++-
arch/powerpc/boot/dts/mpc8548cds.dts |3 ++-
arch/powerpc/boot/dts/mpc8555cds.dts |3 ++-
arch/powerpc/boot/dts/mpc8560ads.dts |2 +-
arch/powerpc/boot/dts/mpc8568mds.dts |3 ++-
arch/powerpc/boot/dts/mpc8572ds.dts|4 +++-
arch/powerpc/boot/dts/sbc8548.dts |3 ++-
arch/powerpc/boot/dts/sbc8560.dts |3 ++-
arch/powerpc/boot/dts/stx_gp3_8560.dts |3 ++-
arch/powerpc/boot/dts/tqm8540.dts |3 ++-
arch/powerpc/boot/dts/tqm8541.dts |3 ++-
arch/powerpc/boot/dts/tqm8555.dts |3 ++-
arch/powerpc/boot/dts/tqm8560.dts |3 ++-
16 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/ksi8560.dts
b/arch/powerpc/boot/dts/ksi8560.dts
index f869ce3..6eb7c77 100644
--- a/arch/powerpc/boot/dts/ksi8560.dts
+++ b/arch/powerpc/boot/dts/ksi8560.dts
@@ -40,6 +40,7 @@
timebase-frequency = 0; /* From U-boot
*/
bus-frequency = 0;/* From U-boot
*/
clock-frequency = 0; /* From U-boot
*/
+ next-level-cache = L2;
};
};
@@ -62,7 +63,7 @@
interrupts = 0x12 0x2;
};
- [EMAIL PROTECTED] {
+ L2: [EMAIL PROTECTED] {
compatible = fsl,8540-l2-cache-controller;
reg = 0x2 0x1000;
cache-line-size = 0x20; /* 32 bytes */
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts
b/arch/powerpc/boot/dts/mpc8540ads.dts
index 58e165e..79881a1 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -40,6 +40,7 @@
timebase-frequency = 0; // 33 MHz, from uboot
bus-frequency = 0;// 166 MHz
clock-frequency = 0; // 825 MHz, from uboot
+ next-level-cache = L2;
};
};
@@ -63,7 +64,7 @@
interrupts = 18 2;
};
- [EMAIL PROTECTED] {
+ L2: [EMAIL PROTECTED] {
compatible = fsl,8540-l2-cache-controller;
reg = 0x2 0x1000;
cache-line-size = 32; // 32 bytes
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts
b/arch/powerpc/boot/dts/mpc8541cds.dts
index 21ebe7c..66192aa 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -40,6 +40,7 @@
timebase-frequency = 0; // 33 MHz, from uboot
bus-frequency = 0;// 166 MHz
clock-frequency = 0; // 825 MHz, from uboot
+ next-level-cache = L2;
};
};
@@ -63,7 +64,7 @@
interrupts = 18 2;
};
- [EMAIL PROTECTED] {
+ L2: [EMAIL PROTECTED] {
compatible = fsl,8541-l2-cache-controller;
reg = 0x2 0x1000;
cache-line-size = 32; // 32 bytes
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts
b/arch/powerpc/boot/dts/mpc8544ds.dts
index 921f9f6..6cf533f 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -41,6 +41,7 @@
timebase-frequency = 0;
bus-frequency = 0;
clock-frequency = 0;
+ next-level-cache = L2;
};
};
@@ -65,7 +66,7 @@
interrupts = 18 2;
};
- [EMAIL PROTECTED] {
+ L2: [EMAIL PROTECTED] {
compatible = fsl,8544-l2-cache-controller;
reg = 0x2 0x1000;
cache-line-size = 32; // 32 bytes
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts
b/arch/powerpc/boot/dts/mpc8548cds.dts
index 213c88e..205598d 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -45,6 +45,7 @@
timebase-frequency = 0; // 33 MHz, from uboot
bus-frequency = 0;// 166 MHz
clock-frequency = 0; // 825 MHz, from uboot
+
Re: [PATCH] [POWERPC] 85xx: Add next-level-cache property
On May 30, 2008, at 4:49 PM, Segher Boessenkool wrote: Added next-level-cache to the L1 and a reference to the new L2 label. Where is this property defined? I can't find it. The PowerPC binding defines an l2-cache property for this (it points from CPU node to L2 cache node, from L2 cache node to L3 cache node, from L3 cache node to L4 cache node, etc.) So looking at the PPC binding its not terrible clear about l3-cache being a valid property. I believe the discussion w/ePAPR was to create something a bit more generic and clarify/update the PPC binding. I'm going to stick with the new binding as we don't use this linking currently. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
On Jun 2, 2008, at 14:30, Kumar Gala wrote:
On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote:
If you really think the core of the phylib should be able to be
built as a module than we could possibly add function pointers to
phy_dev to do the real phy_read()/phy_write() and change phy_read/
_write to look like:
int phy_read(struct phy_device *phydev, u16 regnum) {
return phydev-read(phydev, regnum);
}
That would be a bit silly, since this is the definition of phy_read():
int phy_read(struct phy_device *phydev, u16 regnum)
{
int retval;
struct mii_bus *bus = phydev-bus;
BUG_ON(in_interrupt());
mutex_lock(bus-mdio_lock);
retval = bus-read(bus, phydev-addr, regnum);
mutex_unlock(bus-mdio_lock);
return retval;
}
We could, of course, move phy_read *out* of the phylib module. And
also phy_register_fixup and any other functions needed by board code.
I'm partial to the select-it-if-you-need-it paradigm.
Andy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] [WATCHDOG] mpc83xx_wdt: fix checkpatch issues
On Mon, 2 Jun 2008 21:38:36 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote: Quite tired of these warnings ;-), checkpatch spitting them when seeing the rename patch. I've already sent the maintainer a complete overhaul of watchdog via checkpatch. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][POWERPC] Update fsl_soc to use cell-index property of I2C nodes
Currently, fsl_i2c_of_init() uses the order of the I2C adapter nodes in the
device tree to enumerate the I2C adapters. Instead, let's check for the
cell-index property and use it if it exists.
This is handy for device drivers that need to identify the I2C adapters by
specific numbers. The Freescale MPC8610 ASoC V2 sound drivers are an example.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This patch is for Kumar's powerpc-next branch.
arch/powerpc/sysdev/fsl_soc.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 167523e..14616d5 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -496,6 +496,8 @@ static int __init fsl_i2c_of_init(void)
struct resource r[2];
struct fsl_i2c_platform_data i2c_data;
const unsigned char *flags = NULL;
+ int idx;
+ const u32 *iprop;
memset(r, 0, sizeof(r));
memset(i2c_data, 0, sizeof(i2c_data));
@@ -506,7 +508,10 @@ static int __init fsl_i2c_of_init(void)
of_irq_to_resource(np, 0, r[1]);
- i2c_dev = platform_device_register_simple(fsl-i2c, i, r, 2);
+ iprop = of_get_property(np, cell-index, NULL);
+ idx = iprop ? *iprop : i;
+
+ i2c_dev = platform_device_register_simple(fsl-i2c, idx, r, 2);
if (IS_ERR(i2c_dev)) {
ret = PTR_ERR(i2c_dev);
goto err;
@@ -528,7 +533,8 @@ static int __init fsl_i2c_of_init(void)
if (ret)
goto unreg;
- of_register_i2c_devices(np, i++);
+ of_register_i2c_devices(np, idx);
+ i++;
}
return 0;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for binary includes.
On Thu, May 29, 2008 at 09:04:29AM -0500, Jon Loeliger wrote: I believe I am fully caught up at this point. Not quite, this one slipped through the cracks: Rats. dtc: Fix some printf() format warnings when compiling 64-bit Currently, dtc generates a few gcc build warnings if built for a 64-bit target, due to the altered type of uint64_t and size_t. This patch fixes the warnings (without generating new warnings for 32-bit). Signed-off-by: David Gibson [EMAIL PROTECTED] Please use git for your patches. Really. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Add a testcase for 'reg' or 'ranges' in /
This patch adds an extra testcase to dtc to ensure that the reg_format and ranges_format checks trigger as they should if a 'reg' or 'ranges' property appears in the root node. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
Kumar Gala wrote: On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote: Kumar Gala wrote: On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote: Kumar Gala wrote: The core portions of the phylib aren't capable of being used as a module. This isn't really any different than something like i2c in that the bus driver and core need to be built into the kernel. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Jeff, please consider this for 2.6.26 as w/o it we get build issues if phylib is config'd as a module on ppc. drivers/net/phy/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 6eb2d31..ab04cc7 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -3,7 +3,7 @@ # menuconfig PHYLIB -tristate PHY Device support and infrastructure +bool PHY Device support and infrastructure depends on !S390 depends on NET_ETHERNET What are the issues? The core _should_ be able to be built as a module. The core provides functions like phy_read/phy_write. Andy has recently introduced board level workaround/fixups. The problem is these workarounds tend to use phy_read/phy_write and the board/platform code is not built as modules. So we get errors like: arch/powerpc/platforms/built-in.o: In function `mpc8568_mds_phy_fixups': /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/mpc85xx_mds.c:99: undefined reference to `phy_write' /home/galak/git/master/powerpc/arch/powerpc/platforms/85xx/mpc85xx_mds.c:104: undefined reference to `phy_read' The whole world isn't embedded ppc, we use this stuff elsewhere too. You guys need to figure out something that doesn't require phylib be built-in on ALL platforms, but only the platforms that require it. I wasn't suggesting we build it always, just not let it be built as a module. I was saying, you are requiring everyone to bloat their kernel with phylib, if they enable phylib, because of your particular platform details. That is not a path we want to follow -- limiting everyone else because of one case is not acceptable. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
Andy Fleming wrote: I'm partial to the select-it-if-you-need-it paradigm. AFAICS this can all be solved by the platform Kconfig ensuring that phylib=y Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Cleanup mpic nodes in .dts
Removed clock-frequency and big-endian props as they aren't specified anywhere. If you remove big-endian, you'll have to provide some other way to get that information (like, some new compatible value). I'm all for big-endian but we don't spec this anywhere and aren't using it right now. So until we have an real need to start an extended mpic definition I'm getting rid of it. If we would remove everything insufficiently documented, not much would be left. This doesn't seem very productive to me. Could you instead just add some TODO somewhere? Dunno if we need clock-frequency. Not used today. Sure, the kernel might not use it today, but that's no reason to remove stuff from the device tree. I'm not against removing clock-frequency though, it's not well-defined, and what would it be useful for anyway? This patch also removes built-in properties. I'm all for that, but the patch description didn't say it does. will add that to the commit message. Thanks. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Mon, Jun 02, 2008 at 11:56:39AM +0200, Jes Sorensen wrote: Jeremy Higdon wrote: We don't actually have that problem on the Altix. All writes issued by CPU X will be ordered with respect to each other. But writes by CPU X and CPU Y will not be, unless an mmiowb() is done by the original CPU before the second CPU writes. I.e. CPU X writel CPU X writel CPU X mmiowb CPU Y writel ... Note that this implies some sort of locking. Also note that if in the above, CPU Y did the mmiowb, that would not work. Hmmm, Then it's less bad than I thought - my apologies for the confusion. Would we be able to use Ben's trick of setting a per cpu flag in writel() then and checking that in spin unlock issuing the mmiowb() there if needed? Yes, that should work fine. You will get more mmiowb's than you need, since some drivers, such as Fusion, don't need them. On the Origins (older SGI MIPS-based Numa), the 'sync' instruction had the same effect as mmiowb() with respect to mmio write ordering, and it was issued unconditionally in the spin unlock. It was cheaper than mmiowb, however. If it matters, we could invent and use writel_relaxed() to get performance back in drivers we care about jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 85xx: Add next-level-cache property
Added next-level-cache to the L1 and a reference to the new L2 label. Where is this property defined? I can't find it. The PowerPC binding defines an l2-cache property for this (it points from CPU node to L2 cache node, from L2 cache node to L3 cache node, from L3 cache node to L4 cache node, etc.) So looking at the PPC binding its not terrible clear about l3-cache being a valid property. It isn't. The property is called l2-cache at every level. I believe the discussion w/ePAPR was to create something a bit more generic and clarify/update the PPC binding. Nasty. Sure, l2-cache isn't the nicest name to point to deeper cache levels, but introducing a new property with (substantially) the same semantics is worse. There really shouldn't be a new property name until new functionality is introduced. For example, it could allow to describe more than one cache at each level (the current binding already allows more than one parent for each cache, but only one child; and cache hierarchies like that actually exist). I'm going to stick with the new binding as we don't use this linking currently. Dunno what's the best thing to do here. If you don't need the functionality yet, it might be best to postpone putting either property in there. Sigh, what a mess. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] [WATCHDOG] mpc83xx_wdt: fix checkpatch issues
On Mon, Jun 02, 2008 at 08:43:18PM +0100, Alan Cox wrote: On Mon, 2 Jun 2008 21:38:36 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote: Quite tired of these warnings ;-), checkpatch spitting them when seeing the rename patch. I've already sent the maintainer a complete overhaul of watchdog via checkpatch. Oh, I see it now, thanks. I've just read Wim's comments there, and I think I'll have to wait for git-watchdog update and then will rebase my work on top. Thanks, -- 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: [PATCH] [POWERPC] 85xx: Add next-level-cache property
Segher Boessenkool wrote: The PowerPC binding defines an l2-cache property for this (it points from CPU node to L2 cache node, from L2 cache node to L3 cache node, from L3 cache node to L4 cache node, etc.) So looking at the PPC binding its not terrible clear about l3-cache being a valid property. It isn't. The property is called l2-cache at every level. I believe the discussion w/ePAPR was to create something a bit more generic and clarify/update the PPC binding. Nasty. Sure, l2-cache isn't the nicest name to point to deeper cache levels, but introducing a new property with (substantially) the same semantics is worse. The semantics appear to be identical, even. There really shouldn't be a new property name until new functionality is introduced. For example, it could allow to describe more than one cache at each level (the current binding already allows more than one parent for each cache, but only one child; and cache hierarchies like that actually exist). I'm going to stick with the new binding as we don't use this linking currently. Dunno what's the best thing to do here. If you don't need the functionality yet, it might be best to postpone putting either property in there. Sigh, what a mess. Does existing practice count for anything? IBM pseries firmware uses the l2-cache property as described in the PowerPC binding. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Mon, 2008-06-02 at 12:36 +0200, Ingo Molnar wrote: The patch passed initial light testing in -tip (~30 successful random self-builds and bootups on various mixed 32-bit/64-bit boxes) but it's still v2.6.27 material IMO. I think adding the memory clobber should be .26 and even -stable. We know for sure newer gcc will re-order things, we know it for sure some drivers will break in subtle ways because of that, ad we know as well that sticking memory clobber in there will fix that breakage we know about ... So I don't see the point of waiting. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
Geoff Levand wrote: Alessandro Zummo wrote: On Wed, 20 Feb 2008 10:11:23 -0600 Kumar Gala [EMAIL PROTECTED] wrote: Is the functionality provided by drivers/char/gen_rtc.c completely handled by the rtc subsystem in drivers/rtc? I ask for two reasons: 1. should we make it mutually exclusive in Kconfig 2. I've enabled both and get (we'll my defconfig did): They shouldn't be enabled at once. I think a patch for Kconfig has been recently submitted to give a warning in such a case. rtc-cmos should be able to handle the vast majority of x86 rtcs out there. gen_rtc was hooked up to the powerpc platform ppc_md.set_rtc_time and ppc_md.get_rtc_time via the arch specific get_rtc_time() and set_rtc_time() routines. From what I can tell, those generic rtc routines the powerpc arch provides are not properly hooked into the new rtc subsystem. This causes problems for multi-platform builds where some platforms must use gen_rtc, and some must the new rtc subsytem. Just to follow up, I found that David Woodhouse has submitted a patch which does this: http://patchwork.ozlabs.org/linuxppc/patch?id=18139 -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 85xx: Add next-level-cache property
On Jun 2, 2008, at 4:26 PM, Nathan Lynch wrote: Segher Boessenkool wrote: The PowerPC binding defines an l2-cache property for this (it points from CPU node to L2 cache node, from L2 cache node to L3 cache node, from L3 cache node to L4 cache node, etc.) So looking at the PPC binding its not terrible clear about l3- cache being a valid property. It isn't. The property is called l2-cache at every level. I believe the discussion w/ePAPR was to create something a bit more generic and clarify/update the PPC binding. Nasty. Sure, l2-cache isn't the nicest name to point to deeper cache levels, but introducing a new property with (substantially) the same semantics is worse. The semantics appear to be identical, even. There really shouldn't be a new property name until new functionality is introduced. For example, it could allow to describe more than one cache at each level (the current binding already allows more than one parent for each cache, but only one child; and cache hierarchies like that actually exist). I'm going to stick with the new binding as we don't use this linking currently. Dunno what's the best thing to do here. If you don't need the functionality yet, it might be best to postpone putting either property in there. Sigh, what a mess. Does existing practice count for anything? IBM pseries firmware uses the l2-cache property as described in the PowerPC binding. The ePAPR does suggest to implement l2-cache for SW compat. If there is strong enough feeling we can support both but I'm sticking w/what's in ePAPR for 85xx as its just slightly more sane. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
The whole world isn't embedded ppc, we use this stuff elsewhere too. You guys need to figure out something that doesn't require phylib be built-in on ALL platforms, but only the platforms that require it. I wasn't suggesting we build it always, just not let it be built as a module. I was saying, you are requiring everyone to bloat their kernel with phylib, if they enable phylib, because of your particular platform details. That is not a path we want to follow -- limiting everyone else because of one case is not acceptable. Are you saying that all the driver subsystems that require being built into the kernel should be changed to not require this? (I2C, SPI, DMA engine, etc.) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Cleanup mpic nodes in .dts
On Jun 2, 2008, at 11:32 AM, Segher Boessenkool wrote: Removed clock-frequency and big-endian props as they aren't specified anywhere. If you remove big-endian, you'll have to provide some other way to get that information (like, some new compatible value). I'm all for big-endian but we don't spec this anywhere and aren't using it right now. So until we have an real need to start an extended mpic definition I'm getting rid of it. If we would remove everything insufficiently documented, not much would be left. This doesn't seem very productive to me. Could you instead just add some TODO somewhere? we were already inconsistent here so I've made all things equal and baselined. Dunno if we need clock-frequency. Not used today. Sure, the kernel might not use it today, but that's no reason to remove stuff from the device tree. I'm not against removing clock-frequency though, it's not well- defined, and what would it be useful for anyway? As Scott pointed it it could be used for the frequency of the timers that exist in OpenPIC. This patch also removes built-in properties. I'm all for that, but the patch description didn't say it does. will add that to the commit message. Thanks. I'm sticking to removing the cruft and if/when we need it some can add it properly. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
On Jun 2, 2008, at 3:30 PM, Jeff Garzik wrote: Andy Fleming wrote: I'm partial to the select-it-if-you-need-it paradigm. AFAICS this can all be solved by the platform Kconfig ensuring that phylib=y I don't care for this as it means making sure each platform/board port gets it right. I think we'd be better off with a small stub that is always built into the kernel for phy_read/phy_write, etc or the function pointer indirection mechanism. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
On Jun 1, 2008, at 9:03 PM, David Gibson wrote:
On Fri, May 30, 2008 at 08:49:45AM +0200, Wolfgang Grandegger wrote:
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
[snip]
index 000..d09250a
--- /dev/null
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -0,0 +1,370 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License, or
(at your
+ * option) any later version.
+ */
+
+/dts-v1/;
[snip]
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
[...]
+ enet0: [EMAIL PROTECTED] {
+ cell-index = 0;
[...]
+ serial0: [EMAIL PROTECTED] {
+ cell-index = 0;
[...]
+ pci0: [EMAIL PROTECTED] {
+ cell-index = 0;
You have a whole lot of 'cell-index' properties through both these
trees, and they all look wrong. cell-index is a hack, which should be
avoided wherever practical - it should only be used when the index is
used to offset into some global register block, never simply to
differentiate (use reg for that) or name the devices (use aliases for
that).
this is why FSL device tree's have cell-index. We have global control
registers that need to know such things.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Don't allow core of phylib to build as a module
Kumar Gala wrote: On Jun 2, 2008, at 3:30 PM, Jeff Garzik wrote: Andy Fleming wrote: I'm partial to the select-it-if-you-need-it paradigm. AFAICS this can all be solved by the platform Kconfig ensuring that phylib=y I don't care for this as it means making sure each platform/board port gets it right. How is this different from any other kconfig dependency? It's not too hard to scan through your platform code and see what you call... I think we'd be better off with a small stub that is always built into the kernel for phy_read/phy_write, etc or the function pointer indirection mechanism. And then instead of build failures, you'd get a silent runtime failure to apply the workaround if phylib is built as a module. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Hi. On Mon, Jun 02, 2008 at 02:06:03PM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: it would be an issue if flush_cannel didn't save off the data required to call the callback with in saved_req. flush_channel does this on purpose to be able to call the callback outside of lock (as is commented). Note desc gets assigned NULL prior to releasing the lock, after copying its contents to saved_req. Excellent! It looks like there are no more issues and second version fixed found problem place. -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] use dev_set_name in pci_64.c
During the next merge window, pci_name()'s return value will become const, so use the new dev_set_name() instead to avoid the warning (from linux-next): arch/powerpc/kernel/pci_64.c: In function 'of_create_pci_dev': arch/powerpc/kernel/pci_64.c:193: warning: passing argument 1 of 'sprintf' discards qualifiers from pointer target type Cc: Kay Sievers [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/kernel/pci_64.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) This is similar to a patch for sparc64 that is in linux-next. It is suitable for either 2.6.26 or 2.6.27. diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c index 5275074..30eedfc 100644 --- a/arch/powerpc/kernel/pci_64.c +++ b/arch/powerpc/kernel/pci_64.c @@ -189,7 +189,7 @@ struct pci_dev *of_create_pci_dev(struct device_node *node, dev-cfg_size = pci_cfg_space_size(dev); - sprintf(pci_name(dev), %04x:%02x:%02x.%d, pci_domain_nr(bus), + dev_set_name(dev-dev, %04x:%02x:%02x.%d, pci_domain_nr(bus), dev-bus-number, PCI_SLOT(devfn), PCI_FUNC(devfn)); dev-class = get_int_prop(node, class-code, 0); dev-revision = get_int_prop(node, revision-id, 0); -- 1.5.5.3 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Monday 02 June 2008 19:56, Jes Sorensen wrote: Jeremy Higdon wrote: We don't actually have that problem on the Altix. All writes issued by CPU X will be ordered with respect to each other. But writes by CPU X and CPU Y will not be, unless an mmiowb() is done by the original CPU before the second CPU writes. I.e. CPU X writel CPU X writel CPU X mmiowb CPU Y writel ... Note that this implies some sort of locking. Also note that if in the above, CPU Y did the mmiowb, that would not work. Hmmm, Then it's less bad than I thought - my apologies for the confusion. Would we be able to use Ben's trick of setting a per cpu flag in writel() then and checking that in spin unlock issuing the mmiowb() there if needed? Yes you could, but your writels would still not be strongly ordered within (or outside) spinlock regions, which is what Linus wants (and I kind of agree with). This comes back to my posting about mmiowb and io_*mb barriers etc. Despite what you say, what you've done really _does_ change the semantics of wmb() for all drivers. It is a really sad situation we've got ourselves into somehow, AFAIKS in the hope of trying to save ourselves a tiny bit of work upfront :( (this is not just the sgi folk with mmiowb I'm talking about, but the whole random undefinedness of ordering and io barriers). The right way to make any change is never to weaken the postcondition of an existing interface *unless* you are willing to audit the entire tree and fix it. Impossible for drivers, so the correct thing to do is introduce a new interface, and move things over at an easier pace. Not rocket science. The argument that Altix only uses a few drivers so this way we can just fix these up rather than make big modifications to large numbers of drivers is bogus. It is far worse even for Altix if you make incompatible changes, because you first *break* every driver on your platform, then you have to audit and fix them. If you make compatible changes, then you have to do exactly the same audits to move them over to the new API, but you go from slower-faster rather than broken-non broken. As a bonus, you haven't got random broken stuff all over the tree that you forgot to audit. I don't know how there is still so much debate about this :( I have a proposal: I am a neutral party here, not being an arch maintainer, so I'll take input and write up a backward compatible API specification and force everybody to conform to it ;) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to link a .o with all modules
On May 8, 2008, at 3:22 PM, Sam Ravnborg wrote: On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote: On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote: Let me know if this does address your question. The problem is MODPOST complains about undefined symbols: MODPOST 24 modules ERROR: _restgpr_20_x [net/key/af_key.ko] undefined! ERROR: _restgpr_25_x [net/key/af_key.ko] undefined! ERROR: _restgpr_30_x [net/key/af_key.ko] undefined! I need a bit more context to try to analyse this. Where did you expect _restgpr_20_x to be defined. If in vmlinux then were they present in the Module.symvers file? No they aren't there since we I'm not EXPORT_SYMBOL() them. Should I also be doing EXPORT_SYMBOL? So modpost claim it cannot find the symbols. If in the linked in .o file - could you see the symbols using objdump. Yes. readelf -a: ... Symbol table '.symtab' contains 113 entries: Num:Value Size TypeBind Vis Ndx Name ... 5: 0 FUNCGLOBAL DEFAULT1 _savegpr_14 6: 0 FUNCGLOBAL DEFAULT1 _save32gpr_14 ... Strange. I did not look closer. But it looks like the linker failed to resolve these symbols in the final link somehow - despite the symbols are present in the linked in .o file. Can you try to drop me the output of the relocation records for the finally linked .o file (the one with your .o file linked in). objdump -r IIRC Sam, Didn't see any feedback from the relocation records. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][POWERPC] Update fsl_soc to use cell-index property of I2C nodes
On Jun 2, 2008, at 3:09 PM, Timur Tabi wrote: Currently, fsl_i2c_of_init() uses the order of the I2C adapter nodes in the device tree to enumerate the I2C adapters. Instead, let's check for the cell-index property and use it if it exists. This is handy for device drivers that need to identify the I2C adapters by specific numbers. The Freescale MPC8610 ASoC V2 sound drivers are an example. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] Kprobes for book-e
This is a patch that adds kprobes support for book-e style debug. Its
based on the patch posted by Madhvesh and assumes the exception cleanup
that I've already posted.
Post to get any feedback. The code needs some cleaning up but wanted to
see if there were any initial comments.
- k
---
arch/powerpc/kernel/kprobes.c | 35 +++
arch/powerpc/kernel/misc_32.S |2 +-
arch/powerpc/kernel/traps.c | 26 +-
3 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 23545a2..2c9940c 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -35,6 +35,21 @@
#include asm/sstep.h
#include asm/uaccess.h
+
+#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
+#define single_stepping(regs) (current-thread.dbcr0 DBCR0_IC)
+#define clear_single_step(regs)(current-thread.dbcr0 = ~DBCR0_IC)
+#else
+#define single_stepping(regs) ((regs)-msr MSR_SE)
+#define clear_single_step(regs)((regs)-msr = ~MSR_SE)
+#endif
+
+#ifdef CONFIG_BOOKE
+#define MSR_SINGLESTEP (MSR_DE)
+#else
+#define MSR_SINGLESTEP (MSR_SE)
+#endif
+
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
@@ -53,7 +68,8 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
ret = -EINVAL;
}
- /* insn must be on a special executable page on ppc64 */
+ /* insn must be on a special executable page on ppc64. This is
+* explicitly required on ppc32 (right now), but it doesn't hurt */
if (!ret) {
p-ainsn.insn = get_insn_slot();
if (!p-ainsn.insn)
@@ -95,7 +111,14 @@ void __kprobes arch_remove_kprobe(struct kprobe *p)
static void __kprobes prepare_singlestep(struct kprobe *p, struct pt_regs
*regs)
{
+#ifdef CONFIG_BOOKE
+ regs-msr = ~(MSR_EE); /* Turn off 'Externel Interrupt' bits */
+ regs-msr = ~(MSR_CE); /* Turn off 'Critical Interrupt' bits */
+ regs-msr |= MSR_DE;
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
+#else
regs-msr |= MSR_SE;
+#endif
/*
* On powerpc we should single step on the original
@@ -124,6 +147,10 @@ static void __kprobes set_current_kprobe(struct kprobe *p,
struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
__get_cpu_var(current_kprobe) = p;
+#ifdef CONFIG_BOOKE
+ regs-msr |= (MSR_EE); /* Turn on 'External Interrupt' bits */
+ regs-msr |= (MSR_CE); /* Turn on 'Critical Interrupt' bits */
+#endif
kcb-kprobe_saved_msr = regs-msr;
}
@@ -158,7 +185,7 @@ static int __kprobes kprobe_handler(struct pt_regs *regs)
kprobe_opcode_t insn = *p-ainsn.insn;
if (kcb-kprobe_status == KPROBE_HIT_SS
is_trap(insn)) {
- regs-msr = ~MSR_SE;
+ regs-msr = ~MSR_SINGLESTEP; /* Turn off
'trace' bits */
regs-msr |= kcb-kprobe_saved_msr;
goto no_kprobe;
}
@@ -398,7 +425,7 @@ out:
* will have SE set, in which case, continue the remaining processing
* of do_debug, as if this is not a probe hit.
*/
- if (regs-msr MSR_SE)
+ if (single_stepping(regs))
return 0;
return 1;
@@ -421,7 +448,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs,
int trapnr)
* normal page fault.
*/
regs-nip = (unsigned long)cur-addr;
- regs-msr = ~MSR_SE;
+ regs-msr = ~MSR_SINGLESTEP; /* Turn off 'trace' bits */
regs-msr |= kcb-kprobe_saved_msr;
if (kcb-kprobe_status == KPROBE_REENTER)
restore_previous_kprobe(kcb);
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 896..6321ae3 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -489,7 +489,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_UNIFIED_ID_CACHE)
*
* flush_icache_range(unsigned long start, unsigned long stop)
*/
-_GLOBAL(__flush_icache_range)
+_KPROBE(__flush_icache_range)
BEGIN_FTR_SECTION
blr /* for 601, do nothing */
END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 4b5b7ff..dc97207 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1030,10 +1030,34 @@ void SoftwareEmulation(struct pt_regs *regs)
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
-void DebugException(struct pt_regs *regs, unsigned long debug_status)
+void __kprobes DebugException(struct pt_regs *regs, unsigned long debug_status)
{
if (debug_status DBSR_IC) { /* instruction
Re: [RFC] Kprobes for book-e
On Jun 3, 2008, at 12:48 AM, Ananth N Mavinakayanahalli wrote: On Tue, Jun 03, 2008 at 12:30:51AM -0500, Kumar Gala wrote: This is a patch that adds kprobes support for book-e style debug. Its based on the patch posted by Madhvesh and assumes the exception cleanup that I've already posted. Post to get any feedback. The code needs some cleaning up but wanted to see if there were any initial comments. - k ... @@ -53,7 +68,8 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p) ret = -EINVAL; } - /* insn must be on a special executable page on ppc64 */ + /* insn must be on a special executable page on ppc64. This is +* explicitly required on ppc32 (right now), but it doesn't hurt */ not required? yes. that should be 'not required'.. I don't have much (any) knowledge about Book-E details, but the generic powerpc changes look fine to me. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Kprobes for book-e
On Tue, Jun 03, 2008 at 12:30:51AM -0500, Kumar Gala wrote: This is a patch that adds kprobes support for book-e style debug. Its based on the patch posted by Madhvesh and assumes the exception cleanup that I've already posted. Post to get any feedback. The code needs some cleaning up but wanted to see if there were any initial comments. - k ... @@ -53,7 +68,8 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p) ret = -EINVAL; } - /* insn must be on a special executable page on ppc64 */ + /* insn must be on a special executable page on ppc64. This is + * explicitly required on ppc32 (right now), but it doesn't hurt */ not required? I don't have much (any) knowledge about Book-E details, but the generic powerpc changes look fine to me. Ananth ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: slow MMC over SPI
Hello, I am trying to enable the SD over SPI on a emebedded system with one processor powerpc mpc5200b; you have enabled mmc over spi into a native spi or psc spi? regards, Fabio Andre Schwarz ha scritto: All, has anybody made some investigations about performance of a SD/MMC card on SPI ? Actually I'm using various cards (different speed classes) on an SPI bus of a MPC8343 cpu. Everything is working fine basically, i.e. card is detected properly and block device can be mounted and used. SPI clock is adjusted to the card's capabilities and is running quite fast (30MHz). But between consecutive reads/writes there's a fixed gap of 2us thus yielding a poor performance of approx. 300KBytes/sec. The spi bus is utilized only ~10%. Any ideas where this comes from ? Ist it a fixed delay regarding to some kind of spec or is it possibly a spi driver/mmc layer issue ? regards, Andre Schwarz MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ 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
