Re: [PATCH v4] [POWERPC] Move to runtime allocated exception stacks
On May 31, 2008, at 12:04 AM, Paul Mackerras wrote: Kumar Gala writes: For the additonal exception levels (critical, debug, machine check) on 40x/book-e we were using "static" allocations of the stack in the associated head.S. Move to a runtime allocation to make the code a bit easier to read as we mimic how we handle IRQ stacks. Its also a bit easier to setup the stack with a "dummy" thread_info in C code. Looks fine, with just one very minor comment: - addir11,r11,THREAD_SIZE; \ -1: subi r11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\ +1: addir11,r11,THREAD_SIZE; \ + subir11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\ You could make that a single addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE now. I remember noticing that and thinking I should go back in fix. Will look at doing that and add the patches to my powerpc-next tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix DMA nodes in the MPC8610 HPCD device tree
On May 31, 2008, at 12:27 AM, Paul Mackerras wrote: Timur Tabi writes: The node for DMA2 in the MPC8610 HPCD device tree has the wrong compatible properties. This breaks the DMA driver and the sound driver. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- I have no idea how I let this bug slip in, but this is a must-fix for 2.6.26. Kumar, do you have anything else for 2.6.26 at the moment? If not, and this patch is OK with you, I'll put it in along with Olof's two patches and send them to Linus. Does anyone else have any pending fixes for 2.6.26? I don't. I want/need to do defconfig updates but that can wait if you plan on getting this out over the weekend. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix DMA nodes in the MPC8610 HPCD device tree
Timur Tabi writes: > The node for DMA2 in the MPC8610 HPCD device tree has the wrong compatible > properties. This breaks the DMA driver and the sound driver. > > Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> > --- > > I have no idea how I let this bug slip in, but this is a must-fix for 2.6.26. Kumar, do you have anything else for 2.6.26 at the moment? If not, and this patch is OK with you, I'll put it in along with Olof's two patches and send them to Linus. Does anyone else have any pending fixes for 2.6.26? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] [POWERPC] Move to runtime allocated exception stacks
Kumar Gala writes: > For the additonal exception levels (critical, debug, machine check) on > 40x/book-e we were using "static" allocations of the stack in the > associated head.S. > > Move to a runtime allocation to make the code a bit easier to read as > we mimic how we handle IRQ stacks. Its also a bit easier to setup the > stack with a "dummy" thread_info in C code. Looks fine, with just one very minor comment: > - addir11,r11,THREAD_SIZE; \ > -1: subir11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\ > +1: addir11,r11,THREAD_SIZE; \ > + subir11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */\ You could make that a single addi r11,r11,THREAD_SIZE-INT_FRAME_SIZE now. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] net: OpenFirmware GPIO based MDIO bitbang driver
Laurent Pinchart wrote: This patch adds an MDIO bitbang driver that uses the GPIO library and its OF bindings to access the bus I/Os. Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]> --- Documentation/powerpc/booting-without-of.txt | 21 +++ drivers/net/phy/Kconfig |6 + drivers/net/phy/Makefile |1 + drivers/net/phy/mdio-ofgpio.c| 205 ++ 4 files changed, 233 insertions(+), 0 deletions(-) create mode 100644 drivers/net/phy/mdio-ofgpio.c applied 1-2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2 v2] talitos: Freescale integrated security engine (SEC) driver
Add support for the SEC available on a wide range of PowerQUICC devices,
e.g. MPC8349E, MPC8548E.
this initial version supports authenc(hmac(sha1),cbc(aes)) for use with IPsec.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
removed priv->status hw interrupt status assignment. Done tasklet now
checks all channels unconditionally.
drivers/crypto/Kconfig | 15 +
drivers/crypto/Makefile |1 +
drivers/crypto/talitos.c | 1367 ++
drivers/crypto/talitos.h | 191 +++
4 files changed, 1574 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/talitos.c
create mode 100644 drivers/crypto/talitos.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 43b71b6..98d96df 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,4 +174,19 @@ config CRYPTO_DEV_HIFN_795X_RNG
Select this option if you want to enable the random number generator
on the HIFN 795x crypto adapters.
+config CRYPTO_DEV_TALITOS
+ tristate "Talitos Freescale Security Engine (SEC)"
+ select CRYPTO_ALGAPI
+ select CRYPTO_AUTHENC
+ depends on FSL_SOC
+ help
+ Say 'Y' here to use the Freescale Security Engine (SEC)
+ to offload cryptographic algorithm computation.
+
+ The Freescale SEC is present on PowerQUICC 'E' processors, such
+ as the MPC8349E and MPC8548E.
+
+ To compile this driver as a module, choose M here: the module
+ will be called talitos.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c0327f0..d29d2cd 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
new file mode 100644
index 000..cf2e6f3
--- /dev/null
+++ b/drivers/crypto/talitos.c
@@ -0,0 +1,1367 @@
+/*
+ * talitos - Freescale Integrated Security Engine (SEC) device driver
+ *
+ * Copyright (c) 2008 Freescale Semiconductor, Inc.
+ *
+ * Scatterlist Crypto API glue code copied from files with the following:
+ * Copyright (c) 2006-2007 Herbert Xu <[EMAIL PROTECTED]>
+ *
+ * Crypto algorithm registration code copied from hifn driver:
+ * 2007+ Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "talitos.h"
+
+#define TALITOS_TIMEOUT 10
+#define TALITOS_MAX_DATA_LEN 65535
+
+#define DESC_TYPE(desc_hdr) ((be32_to_cpu(desc_hdr) >> 3) & 0x1f)
+#define PRIMARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) >> 28) & 0xf)
+#define SECONDARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) >> 16) & 0xf)
+
+/* descriptor pointer entry */
+struct talitos_ptr {
+ __be16 len; /* length */
+ u8 j_extent;/* jump to sg link table and/or extent */
+ u8 eptr;/* extended address */
+ __be32 ptr; /* address */
+};
+
+/* descriptor */
+struct talitos_desc {
+ __be32 hdr; /* header high bits */
+ __be32 hdr_lo; /* header low bits */
+ struct talitos_ptr ptr[7]; /* ptr/len pair array */
+};
+
+/**
+ * talitos_request - descriptor submission request
+ * @desc: descriptor pointer (kernel virtual)
+ * @dma_desc: descriptor's physical bus address
+ * @callback: whom to call when descriptor processing is done
+ * @context: caller context (optional)
+ */
+struct talitos_request {
+ struct talitos_desc *desc;
+ dma_addr_t dma_desc;
+ void (*callback) (struct device *dev, struct talitos_desc *desc,
+ void *context, int error);
+ void *context;
+};
+
+struct talitos_private {
+ struct device *dev;
+ struct of_device *ofdev;
+ void __iomem *reg;
+ int irq;
+
+ /* SEC version geometry (from device tree node) */
+ unsi
Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
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. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] update crypto node definition and device tree instances
On Fri, 30 May 2008 23:28:38 +0200 Segher Boessenkool <[EMAIL PROTECTED]> wrote: > Nice cleanup! Just one thing... > > > +- compatible : Should contain entries for all compatible SEC > > versions, > > + high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" > > *All* compatible versions? That's not really correct -- for > example that would include *future* versions! ok, so 'backward compatible'.. > The first entry should describe the exact device version. If > there are more entries, they should be for device versions where > the driver for that device version can be reasonably expected to > do something useful with this newer device (reduced functionality, > perhaps). Listing *all* compatible devices is a) infeasible, > b) not useful, and c) insane :-) > > Say you have a 3.3 device, and all 3.x devices have the same > programming interface; also, the 2.x interface works with reduced > functionality, and 1.x isn't useful at all; in that case, you would > list 3.3, 3.0, 2.0. The driver that knows about 3.x would probe > for 3.0, while an older driver would probe for 2.0. The driver > doesn't need to probe for 3.3, since devices implementing 3.3 > should show they are compatible with 3.0 (and the binding should > say they should show this). > All the driver has to do to turn on a particular feature is call of_device_is_compatible with the version string of the h/w version that introduces that feature. In the above case, a driver wanting to use e.g., hardware ICV checking, would have to check for 2.1 and 3.x instead of just 2.1. > Also, the binding should explicitly list all defined compatible > entries (and what they mean), not just give a few examples. > I'm not sure I understand; a lot of the differences between the SEC versions are miniscule feature bits scattered across the programming model. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problems changing ethernet phy settings with LXT973 (and 8555)
I'm not sure if this is the right place to post, but it's one of the few places that seems relevant (the other I think would be linuxppc-embedded). Our board is using an 8555 with an LXT973 dual-phy chip hooked up to TSEC0 and TSEC1. We're currently using 2.6.20 but I don't see any major changes in the 2.6.25 release in the area of the phy driver. We're using the gianfar driver, with the generic phy driver. When the phy driver writes to BMCR to turn off auto-negotiation and set the speed and duplex, it appears that none of the writes except the RESET bit take effect. Reading back the register immediately shows the RESET bit set, but none of the other changes (later the RESET bit is cleared, but again, none of the changes are visible). One possibility was that the LXT973 was wired up to come up in hardware control mode, where it's supposed to ignore all writes (I'm not sure if there is supposed to be an exception for the RESET bit or not in this case), but that appears not to be the case. I was wondering if anyone has any idea as to what might be the source of this problem, or if anyone has any suggestions as to avenues of investigation to track it down. -- Ben Gamsa [EMAIL PROTECTED] SOMA Networks, Inc. 312 Adelaide St. W. Suite 600 Toronto, Ontario, M5V1R2 ___ 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 01:12:08 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips ([EMAIL PROTECTED]) > wrote: > > sorry, by ISR I meant interrupt status registers. but I can't tell > > where the suspected simultaneous accesses are. Evgeniy, can you point > > out the register accesses you're talking about? > > priv->status is accessed from tasklets, although readonly, but that rises > a red flag... Also callback invocation tasklet drops the lock around 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. > 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. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix DMA nodes in the MPC8610 HPCD device tree
The node for DMA2 in the MPC8610 HPCD device tree has the wrong compatible
properties. This breaks the DMA driver and the sound driver.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
I have no idea how I let this bug slip in, but this is a must-fix for 2.6.26.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 08a780d..fa9b6bb 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -251,14 +251,14 @@
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
+ compatible = "fsl,mpc8610-dma", "fsl,eloplus-dma";
cell-index = <1>;
reg = <0xc300 0x4>; /* DMA general status register */
ranges = <0x0 0xc100 0x200>;
[EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
- "fsl,mpc8540-dma-channel";
+ "fsl,eloplus-dma-channel";
cell-index = <0>;
reg = <0x0 0x80>;
interrupt-parent = <&mpic>;
@@ -266,7 +266,7 @@
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
- "fsl,mpc8540-dma-channel";
+ "fsl,eloplus-dma-channel";
cell-index = <1>;
reg = <0x80 0x80>;
interrupt-parent = <&mpic>;
@@ -274,7 +274,7 @@
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
- "fsl,mpc8540-dma-channel";
+ "fsl,eloplus-dma-channel";
cell-index = <2>;
reg = <0x100 0x80>;
interrupt-parent = <&mpic>;
@@ -282,7 +282,7 @@
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
- "fsl,mpc8540-dma-channel";
+ "fsl,eloplus-dma-channel";
cell-index = <3>;
reg = <0x180 0x80>;
interrupt-parent = <&mpic>;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add port multiplier (PMP) support in sata_fsl driver
Kumar Gala wrote: From: Ashish Kalra <[EMAIL PROTECTED]> PMP support for sata_fsl driver. Signed-off-by: Ashish Kalra <[EMAIL PROTECTED]> --- Jeff, The following commit (4c9bf4e799ce06a7378f1196587084802a414c03): libata: replace tf_read with qc_fill_rtf for non-SFF drivers Broke the sata_fsl.c driver in 2.6.26. I know the following patch fixes the issue, it clearly also adds port multipler support. I'm not sure if you are willing to take that as part of 2.6.26 or not, but the current 2.6.26 driver is broken. On boot with debug enabled we get something like (w/o this patch): spurious interrupt!!, CC = 0x1 interrupt status 0x1 xx_scr_read, reg_in = 1 spurious interrupt!!, CC = 0x1 interrupt status 0x1 xx_scr_read, reg_in = 1 spurious interrupt!!, CC = 0x1 interrupt status 0x1 xx_scr_read, reg_in = 1 .. continues for ever. - k drivers/ata/sata_fsl.c | 224 +++- 1 files changed, 163 insertions(+), 61 deletions(-) applied ___ 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.) Segher ___ 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). Dunno if we need "clock-frequency". This patch also removes "built-in" properties. I'm all for that, but the patch description didn't say it does. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] update crypto node definition and device tree instances
Nice cleanup! Just one thing... +- compatible : Should contain entries for all compatible SEC versions, + high to low, e.g., "fsl,sec2.1", "fsl,sec2.0" *All* compatible versions? That's not really correct -- for example that would include *future* versions! The first entry should describe the exact device version. If there are more entries, they should be for device versions where the driver for that device version can be reasonably expected to do something useful with this newer device (reduced functionality, perhaps). Listing *all* compatible devices is a) infeasible, b) not useful, and c) insane :-) Say you have a 3.3 device, and all 3.x devices have the same programming interface; also, the 2.x interface works with reduced functionality, and 1.x isn't useful at all; in that case, you would list 3.3, 3.0, 2.0. The driver that knows about 3.x would probe for 3.0, while an older driver would probe for 2.0. The driver doesn't need to probe for 3.3, since devices implementing 3.3 should show they are compatible with 3.0 (and the binding should say they should show this). Also, the binding should explicitly list all defined compatible entries (and what they mean), not just give a few examples. Segher ___ 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 Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: > sorry, by ISR I meant interrupt status registers. but I can't tell > where the suspected simultaneous accesses are. Evgeniy, can you point > out the register accesses you're talking about? priv->status is accessed from tasklets, although readonly, but that rises a red flag... Also callback invocation tasklet drops the lock around callback, during that time cached status and priv itself (and tail like in two simultaneous flushes) could change (or not?) -- Evgeniy Polyakov ___ 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 Fri, 30 May 2008 15:36:50 -0500 Scott Wood <[EMAIL PROTECTED]> wrote: > Kim Phillips wrote: > > On Fri, 30 May 2008 15:19:43 -0500 > > Scott Wood <[EMAIL PROTECTED]> wrote: > > > >> Kim Phillips wrote: > >>> On Fri, 30 May 2008 14:41:17 -0500 > >>> Scott Wood <[EMAIL PROTECTED]> wrote: > >>> > Kim Phillips wrote: > > On Fri, 30 May 2008 22:09:04 +0400 > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > >> Don't you want to protect against simultaneous access to register space > >> from different CPUs? Or it is single processor board only? > > Doesn't linux mask the IRQ line for the interrupt currently being > > serviced, and on all processors? > Yes. Could there be interference from non-interrupt driver code on > another cpu (or interrupted code), though? > >>> not that I can see - the fetch fifo register writes are protected with > >>> per-channel spinlocks. > >> But you don't take the spinlocks from the interrupt handler. > > > > why can't fetch fifo registers be written the same time the ISR is > > being accessed? > > I don't know -- you brought them up. My question was whether there's > anything that the ISR touches that is also touched by non-ISR code. > sorry, by ISR I meant interrupt status registers. but I can't tell where the suspected simultaneous accesses are. Evgeniy, can you point out the register accesses you're talking about? Kim ___ 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 Fri, 30 May 2008 15:19:43 -0500 Scott Wood <[EMAIL PROTECTED]> wrote: > Kim Phillips wrote: > > On Fri, 30 May 2008 14:41:17 -0500 > > Scott Wood <[EMAIL PROTECTED]> wrote: > > > >> Kim Phillips wrote: > >>> On Fri, 30 May 2008 22:09:04 +0400 > >>> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > Don't you want to protect against simultaneous access to register space > from different CPUs? Or it is single processor board only? > >>> Doesn't linux mask the IRQ line for the interrupt currently being > >>> serviced, and on all processors? > >> Yes. Could there be interference from non-interrupt driver code on > >> another cpu (or interrupted code), though? > > > > not that I can see - the fetch fifo register writes are protected with > > per-channel spinlocks. > > But you don't take the spinlocks from the interrupt handler. why can't fetch fifo registers be written the same time the ISR is being accessed? Kim ___ 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
Kim Phillips wrote: On Fri, 30 May 2008 15:19:43 -0500 Scott Wood <[EMAIL PROTECTED]> wrote: Kim Phillips wrote: On Fri, 30 May 2008 14:41:17 -0500 Scott Wood <[EMAIL PROTECTED]> wrote: Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? not that I can see - the fetch fifo register writes are protected with per-channel spinlocks. But you don't take the spinlocks from the interrupt handler. why can't fetch fifo registers be written the same time the ISR is being accessed? I don't know -- you brought them up. My question was whether there's anything that the ISR touches that is also touched by non-ISR code. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 85xx: Add next-level-cache property
Added next-level-cache to the L1 and a reference to the new L2 label.
---
In my powerpc-next branch.
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
+ next-level-cache = <&L2>;
};
};
@@ -68,7 +69,7 @@
interrupts = <18 2>;
};
- [EMAIL PROTECTED] {
+
[PATCH] [POWERPC] Cleanup mpic nodes in .dts
Removed clock-frequency and big-endian props as they aren't specified
anywhere.
---
In my powerpc-next branch.
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
b/arch/powerpc/boot/dts/mpc8544ds.dts
index 1cfd970..921f9f6 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
++
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Kim Phillips wrote: On Fri, 30 May 2008 14:41:17 -0500 Scott Wood <[EMAIL PROTECTED]> wrote: Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? not that I can see - the fetch fifo register writes are protected with per-channel spinlocks. But you don't take the spinlocks from the interrupt handler. -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 Fri, 30 May 2008 14:41:17 -0500 Scott Wood <[EMAIL PROTECTED]> wrote: > Kim Phillips wrote: > > On Fri, 30 May 2008 22:09:04 +0400 > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > >> Don't you want to protect against simultaneous access to register space > >> from different CPUs? Or it is single processor board only? > > > > Doesn't linux mask the IRQ line for the interrupt currently being > > serviced, and on all processors? > > Yes. Could there be interference from non-interrupt driver code on > another cpu (or interrupted code), though? not that I can see - the fetch fifo register writes are protected with per-channel spinlocks. Kim ___ 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 Fri, May 30, 2008 at 02:41:17PM -0500, Scott Wood ([EMAIL PROTECTED]) wrote: > >>Don't you want to protect against simultaneous access to register space > >>from different CPUs? Or it is single processor board only? > > > >Doesn't linux mask the IRQ line for the interrupt currently being > >serviced, and on all processors? > > Yes. Could there be interference from non-interrupt driver code on > another cpu (or interrupted code), though? Yes, that register space can be assigned from non-interrupt path on different cpu. I saw spin_lock_irqsave() is used in some other places, but not in interrupt handler itself. -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
On May 30, 2008, at 3:07 PM, Scott Wood wrote:
Kumar Gala wrote:
+mpic: [EMAIL PROTECTED] {
+clock-frequency = <0>;
remove clock-frequency
Where would one express the PIC timer frequency, then?
+interrupt-controller;
+#address-cells = <0>;
+#interrupt-cells = <2>;
+reg = <0x4 0x4>;
+compatible = "chrp,open-pic";
+device_type = "open-pic";
+big-endian;
remove big-endian.
I thought this was part of the open-pic binding.
In any case, if these are to go, we should remove them from existing
trees and from the examples in bwof.txt before complaining about
them in new boards...
I've got a patch for this. will update the examples in bwof.txt
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
Kumar Gala wrote:
+mpic: [EMAIL PROTECTED] {
+clock-frequency = <0>;
remove clock-frequency
Where would one express the PIC timer frequency, then?
+interrupt-controller;
+#address-cells = <0>;
+#interrupt-cells = <2>;
+reg = <0x4 0x4>;
+compatible = "chrp,open-pic";
+device_type = "open-pic";
+big-endian;
remove big-endian.
I thought this was part of the open-pic binding.
In any case, if these are to go, we should remove them from existing
trees and from the examples in bwof.txt before complaining about them in
new boards...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
On May 30, 2008, at 1:49 AM, Wolfgang Grandegger wrote:
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 371 +++
+
1 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm8548-bigflash.dts
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/
powerpc/boot/dts/tqm8548-bigflash.dts
new file mode 100644
index 000..895bb80
--- /dev/null
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -0,0 +1,371 @@
+/*
+ * 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/;
+
+/ {
+ model = "tqm,8548";
+ compatible = "tqm,8548", "tqm,85xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ ethernet2 = &enet2;
+ ethernet3 = &enet3;
+
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ pci1 = &pci1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <32>; // 32 bytes
+ i-cache-line-size = <32>; // 32 bytes
+ d-cache-size = <0x8000>; // L1, 32K
+ i-cache-size = <0x8000>; // L1, 32K
+ timebase-frequency = <0>; // from U-Boot
+ bus-frequency = <0>; // from U-Boot
+ clock-frequency = <0>;// from U-Boot
add next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x2000>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ ranges = <0x0 0xa000 0x10>;
+ reg = <0xa000 0x1000>;// CCSRBAR
+ bus-frequency = <0>;
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,8548-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <&mpic>;
+ interrupts = <18 2>;
+ };
+
+ [EMAIL PROTECTED] {
add L2 label (L2 : l2-cache-...)
+ compatible = "fsl,8548-l2-cache-controller";
+ reg = <0x2 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x8>; // L2, 512K
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+
+
+ mpic: [EMAIL PROTECTED] {
+ clock-frequency = <0>;
remove clock-frequency
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x4 0x4>;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+big-endian;
remove big-endian.
+ };
+ };
+
- k
___
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
Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? -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 Fri, 30 May 2008 22:09:04 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> On Thu, May 29, 2008 at 02:12:50PM -0500, Kim Phillips ([EMAIL PROTECTED])
> wrote:
>
> > +static irqreturn_t talitos_interrupt(int irq, void *data)
> > +{
> > + struct device *dev = data;
> > + struct talitos_private *priv = dev_get_drvdata(dev);
> > +
> > + priv->status = in_be32(priv->reg + TALITOS_ISR);
> > + priv->status_lo = in_be32(priv->reg + TALITOS_ISR_LO);
> > +
> > + if (unlikely(priv->status & ~TALITOS_ISR_CHDONE)) {
> > + talitos_error((unsigned long)data);
> > + /* ack */
> > + out_be32(priv->reg + TALITOS_ICR, priv->status);
> > + out_be32(priv->reg + TALITOS_ICR_LO, priv->status_lo);
> > + }
> > + else
> > + {
> > + /* ack */
> > + out_be32(priv->reg + TALITOS_ICR, priv->status);
> > + out_be32(priv->reg + TALITOS_ICR_LO, priv->status_lo);
> > +
> > + if (likely(priv->status & TALITOS_ISR_CHDONE))
> > + tasklet_schedule(&priv->done_task);
> > + }
> > +
> > + return (priv->status || priv->status_lo) ? IRQ_HANDLED : IRQ_NONE;
> > +}
>
> Don't you want to protect against simultaneous access to register space
> from different CPUs? Or it is single processor board only?
Doesn't linux mask the IRQ line for the interrupt currently being
serviced, and on all processors?
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for binary includes.
David Gibson wrote: What I don't like is the combination of the two. Using the /word/ form in (1) suggests that each /word/ is a lexically distinct symbol with functions in different contexts: consider /dts-v1/, /include/, /memreserve/ - they're all used only in their own distinct context. Use of /word/s in (2) would suggest that each /word/ is just an identifier for a different function, and should all be usable in a similar grammtical context - which won't be true of /memreserve/, /dts-v1/ and any other truly lexically distinct symbols we need to add. I don't understand this conclusion -- I wouldn't expect to be able to use "for" or "while" at file scope of C code, just because I can use "struct", "int", or "sizeof" there. The slashes are simply a way of creating reserved words, some of which happen to be function-like. So, I like the notion of functions like this, but with identifiers that aren't /word/s. Re-invoking the "least surprise to C programmers" principle, in general I think the identifiers should be as C identifiers (i.e. [a-zA-Z_][a-zA-Z0-9_]*). That would make it difficult to have function-like syntax outside of properties. With one caveat, it's not essential but it might be worthwhile to make built-in function identifiers obviously distinct from user-defined ones (if we add those in future). We have a way to make them obviously distinct -- slashes. :-) -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 Thu, May 29, 2008 at 02:12:50PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> +static irqreturn_t talitos_interrupt(int irq, void *data)
> +{
> + struct device *dev = data;
> + struct talitos_private *priv = dev_get_drvdata(dev);
> +
> + priv->status = in_be32(priv->reg + TALITOS_ISR);
> + priv->status_lo = in_be32(priv->reg + TALITOS_ISR_LO);
> +
> + if (unlikely(priv->status & ~TALITOS_ISR_CHDONE)) {
> + talitos_error((unsigned long)data);
> + /* ack */
> + out_be32(priv->reg + TALITOS_ICR, priv->status);
> + out_be32(priv->reg + TALITOS_ICR_LO, priv->status_lo);
> + }
> + else
> + {
> + /* ack */
> + out_be32(priv->reg + TALITOS_ICR, priv->status);
> + out_be32(priv->reg + TALITOS_ICR_LO, priv->status_lo);
> +
> + if (likely(priv->status & TALITOS_ISR_CHDONE))
> + tasklet_schedule(&priv->done_task);
> + }
> +
> + return (priv->status || priv->status_lo) ? IRQ_HANDLED : IRQ_NONE;
> +}
Don't you want to protect against simultaneous access to register space
from different CPUs? Or it is single processor board only?
--
Evgeniy Polyakov
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
Anton Vorontsov wrote: > On Fri, May 30, 2008 at 08:49:46AM +0200, Wolfgang Grandegger wrote: >> Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash >> memory and therefore a modified memory map is required and setup by >> the board loader. This patch adds an appropriate DTS file. >> >> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> >> --- > [...] >> +/* NAND support must be enabled in U-Boot before Linux can use it > > nand/fsl_upm.c can detect this in run-time. That is, if BRx/ORx aren't > configured, fsl_upm_find() will return ENODEV/ENOENT/EINVAL, depending > on what exactly is mis-configured. Ah, I saw that and I could test UPBx configuration for the CAN as well. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Friday, May 30, 2008 2:36 am Jes Sorensen wrote: > James Bottomley wrote: > >> The only way to guarantee ordering in the above setup, is to either > >> make writel() fully ordered or adding the mmiowb()'s inbetween the two > >> writel's. On Altix you have to go and read from the PCI brige to > >> ensure all writes to it have been flushed, which is also what mmiowb() > >> is doing. If writel() was to guarantee this ordering, it would make > >> every writel() call extremely expensive :-( > > > > So if a read from the bridge achieves the same effect, can't we just put > > one after the writes within the spinlock (an unrelaxed one). That way > > this whole sequence will look like a well understood PCI posting flush > > rather than have to muck around with little understood (at least by most > > driver writers) io barriers? > > Hmmm, > > I think mmiowb() does some sort of status read from the bridge, I am not > sure if it's enough to just do a regular readl(). > > I'm adding Jeremy to the list, he should know for sure. I think a read from the target host bridge is enough. What mmiowb() does though is to read a *local* host bridge register, which contains a count of the number of PIO ops still "in flight" on their way to their target bridge. When it reaches 0, all PIOs have arrived at the target host bridge (they still may be bufferd), so ordering is guaranteed. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] Add support for Analogue & Micro ASP837E board
On May 8, 2008, at 7:47 AM, Bryan O'Donoghue wrote: Greetings. Attached is a patchset to support the ASP8347E. http://www.analogue-micro.com/ASP8347.html. Due to the fact that the board shipped with a root filesystem that requires devfs, you have to run a different rootfs with all current kernels. I've been using the 8xx root fs from the ELDK via NFS, for this. v2 implements all changes - bar ethernet aliases in the dts, as suggested by Stephen Rothwell and Kumar Gala, to date. Please apply. Cheers, Bryan Signed-off-by: Bryan O'Donoghue <[EMAIL PROTECTED]> --- applied to powerpc-next. I had to make a few changes to this patch. In the future please make sure the commit message is before the ---. Also, look at running scripts/checkpatch.pl. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add warning for unrecognized I2C nodes in the device tree
On May 15, 2008, at 5:04 PM, Timur Tabi wrote: Update of_find_i2c_driver in fsl_soc.c to display a warning message if an I2C node in the device tree isn't found in the i2c_devices[] array. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/fsl_soc.c |4 1 files changed, 4 insertions(+), 0 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add CS4270 i2c data to fsl_soc.c
On May 15, 2008, at 5:46 PM, Timur Tabi wrote: The i2c_devices[] array in fsl_soc.c lists all the I2C nodes that are supported on Freescale boards. Add an entry for the Cirrus Logic CS4270 so that a new-style CS4270 driver will work. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/fsl_soc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.26] electra_cf: Add MODULE_DEVICE_TABLE()
Hi,
On May 30, 2008, at 12:25 AM, Stephen Rothwell wrote:
On Thu, 29 May 2008 15:05:44 -0500 Olof Johansson <[EMAIL PROTECTED]>
wrote:
electra_cf: Add MODULE_DEVICE_TABLE()
Add a module device table to electra_cf so that modules can be
auto-probed/loaded.
[will be included in git pull request later today]
No Signed-off-by?
It's signed off in my git tree, I normally remove the s-o-b on the
postings to avoid having to rebase if Paul picks it up by mistake
from patchwork instead. Kumar usually does that as well.
diff --git a/drivers/pcmcia/electra_cf.c b/drivers/pcmcia/
electra_cf.c
index 0a6cea1..52d0aa8 100644
--- a/drivers/pcmcia/electra_cf.c
+++ b/drivers/pcmcia/electra_cf.c
@@ -352,6 +352,7 @@ static struct of_device_id electra_cf_match[] = {
While you are here, want to make that const?
I'll do that for .27, thanks for pointing it out.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [NAND] driver extension to support NAND on TQM85xx modules
Kumar Gala wrote: > > On May 30, 2008, at 1:36 AM, Wolfgang Grandegger wrote: > >> This patch extends the FSL UPM NAND driver from Anton Vorontsov to >> support for the TQM85xx modules. Unfortunately, the hardware does >> not support the R/B pins of the NAND chip and therefore the specified >> maximum delay time must used. It therefore re-introduces the chip-delay >> property. >> >> Note: this patch is based on a patch Anton Vorontsov posted to this list: >> See http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055587.html. >> It should show up mainstream soon. >> >> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> >> --- >> drivers/mtd/nand/Kconfig |2 +- >> drivers/mtd/nand/fsl_upm.c | 30 +- >> include/linux/of_gpio.h|2 +- >> 3 files changed, 23 insertions(+), 11 deletions(-) > > You really need to CC the MTD list as this should go via them. Also > you're adding a new property and there should be updates to > booting-w-o-f for it. OK. There are various patches pending for booting-w-o-f including "[PATCH 6/7] [POWERPC] booting-without-of: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings" from Anton. What tree should the patches for NAND and 85xx be based on for kernel inclusion? Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [NAND] driver extension to support NAND on TQM85xx modules
On May 30, 2008, at 1:36 AM, Wolfgang Grandegger wrote: This patch extends the FSL UPM NAND driver from Anton Vorontsov to support for the TQM85xx modules. Unfortunately, the hardware does not support the R/B pins of the NAND chip and therefore the specified maximum delay time must used. It therefore re-introduces the chip- delay property. Note: this patch is based on a patch Anton Vorontsov posted to this list: See http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055587.html . It should show up mainstream soon. Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> --- drivers/mtd/nand/Kconfig |2 +- drivers/mtd/nand/fsl_upm.c | 30 +- include/linux/of_gpio.h|2 +- 3 files changed, 23 insertions(+), 11 deletions(-) You really need to CC the MTD list as this should go via them. Also you're adding a new property and there should be updates to booting-w- o-f for it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] [POWERPC] QE: implement support for the GPIO LIB API
On Tue, May 27, 2008 at 07:16:28PM +0400, Anton Vorontsov wrote: > On Tue, May 27, 2008 at 10:04:20AM -0500, Kumar Gala wrote: > > > > On May 23, 2008, at 11:39 AM, Anton Vorontsov wrote: > > > >> This is needed to access QE GPIOs via Linux GPIO API. > >> > >> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > >> Acked-By: Timur Tabi <[EMAIL PROTECTED]> > >> --- > >> Documentation/powerpc/booting-without-of.txt | 27 + > >> arch/powerpc/sysdev/qe_lib/Kconfig |9 ++ > >> arch/powerpc/sysdev/qe_lib/Makefile |1 + > >> arch/powerpc/sysdev/qe_lib/gpio.c| 148 + > >> + > >> include/asm-powerpc/qe.h |2 + > >> 5 files changed, 187 insertions(+), 0 deletions(-) > >> create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c > > > > didn't we talk about putting this is drivers/gpio/ ? > > :-) > > Yes, we did. And David Brownell politely suggested to not do this, > and instead leave it in arch/ as do all other arches for their SOC > GPIOs. Ping? -- 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
[PATCH] [OF] of_gpio: should use new header
From: Wolfgang Grandegger <[EMAIL PROTECTED]> Since commit 7560fa60fcdcdb0da662f6a9fad9064b554ef46c (gpio: and "no GPIO support here" stubs) drivers can use GPIOs if they're available, but don't require them. This patch actually enables this feature. Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- include/linux/of_gpio.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h index 2ee97e9..67db101 100644 --- a/include/linux/of_gpio.h +++ b/include/linux/of_gpio.h @@ -15,7 +15,7 @@ #define __LINUX_OF_GPIO_H #include -#include +#include #ifdef CONFIG_OF_GPIO -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [NAND] driver extension to support NAND on TQM85xx modules
On Fri, May 30, 2008 at 08:36:32AM +0200, Wolfgang Grandegger wrote: > This patch extends the FSL UPM NAND driver from Anton Vorontsov to > support for the TQM85xx modules. Unfortunately, the hardware does > not support the R/B pins of the NAND chip and therefore the specified > maximum delay time must used. It therefore re-introduces the chip-delay > property. > > Note: this patch is based on a patch Anton Vorontsov posted to this list: > See http://ozlabs.org/pipermail/linuxppc-dev/2008-April/055587.html. > It should show up mainstream soon. Personally, I like this patch. But OF people should approve "chip-delay" property. Though, the whole UPM NAND bindings are in the air still. > --- a/include/linux/of_gpio.h > +++ b/include/linux/of_gpio.h > @@ -15,7 +15,7 @@ > #define __LINUX_OF_GPIO_H > > #include > -#include > +#include This should be done separately. 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/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
On Fri, May 30, 2008 at 08:49:46AM +0200, Wolfgang Grandegger wrote:
> Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
> memory and therefore a modified memory map is required and setup by
> the board loader. This patch adds an appropriate DTS file.
>
> Signed-off-by: Wolfgang Grandegger <[EMAIL PROTECTED]>
> ---
[...]
> +/* NAND support must be enabled in U-Boot before Linux can use it
nand/fsl_upm.c can detect this in run-time. That is, if BRx/ORx aren't
configured, fsl_upm_find() will return ENODEV/ENOENT/EINVAL, depending
on what exactly is mis-configured.
> + [EMAIL PROTECTED],0 {
> + #address-cells = <0>;
> + #size-cells = <0>;
> + compatible = "fsl,upm-nand";
> + reg = <3 0x0 0x800>;
> + fsl,upm-addr-offset = <0x10>;
> + fsl,upm-cmd-offset = <0x08>;
> + chip-delay = <25>; // in micro-seconds
> +
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + [EMAIL PROTECTED] {
> + label = "fs";
> + reg = <0x 0x0100>;
> + };
> + };
> + };
> +*/
> + };
--
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: MMIO and gcc re-ordering issue
Benjamin Herrenschmidt wrote: On Thu, 2008-05-29 at 10:47 -0400, Jes Sorensen wrote: The only way to guarantee ordering in the above setup, is to either make writel() fully ordered or adding the mmiowb()'s inbetween the two writel's. On Altix you have to go and read from the PCI brige to ensure all writes to it have been flushed, which is also what mmiowb() is doing. If writel() was to guarantee this ordering, it would make every writel() call extremely expensive :-( Interesting. I've always been taught by ia64 people that mmiowb() was intended to be used solely between writel() and spin_unlock(). I think in the above case, you really should make writel() ordered. Anything else is asking for trouble, for the exact same reasons that I made it fully ordered on powerpc at least vs. previous stores. I only kept it relaxed vs. subsequent cacheable stores (ie, spin_unlock), for which I use the trick mentioned before. Hmmm I hope I didn't mess up the description of this and added to the confusion. The net result of that would be to kill performance completely, I really don't like that idea Having each writel() go out and poll the PCI bridge is going to make every driver used on Altix slow as a dog. In addition it's still not going to solve the problem for userland mapped stuff such as infinibug. Yes, this has some cost (can be fairly significant on powerpc too) but I think it's a very basic assumption from drivers that consecutive writel's, especially issued by the same CPU, will get to the device in order. In this case the cost is more than just significant, it's pretty crippling. If this is a performance problem, then provide relaxed variants and use them in selected drivers. We'd have to make major changes to drivers like e1000, tg3, mptsas, the qla2/3/4xxx and a bunch of others to get performance back. I really think the code maintenance issue there will get far worse than what we have today :( Cheers, Jes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
Jesse Barnes wrote: On Thursday, May 29, 2008 2:40 pm Benjamin Herrenschmidt wrote: On Thu, 2008-05-29 at 10:47 -0400, Jes Sorensen wrote: The only way to guarantee ordering in the above setup, is to either make writel() fully ordered or adding the mmiowb()'s inbetween the two writel's. On Altix you have to go and read from the PCI brige to ensure all writes to it have been flushed, which is also what mmiowb() is doing. If writel() was to guarantee this ordering, it would make every writel() call extremely expensive :-( Interesting. I've always been taught by ia64 people that mmiowb() was intended to be used solely between writel() and spin_unlock(). Well, that *was* true, afaik, but maybe these days multipath isn't just for fail-over. If that's true, then yeah making every single writeX ordered would be the only way to go... I could be getting bits wrong, but multi-path here is in the NUMA routing, not at the device level. If this is a performance problem, then provide relaxed variants and use them in selected drivers. Sounds reasonable. That way drivers "just work" and important drivers can be optimized. That would kill all levels of performance in all drivers, resulting in attempts to try and modify a fair bit of drivers to get the performance back. In reality this problem really only exists for devices where ordering of consecutive writel's is a big issue. In my experience it really isn't the case very frequently - and the number of mmiowb's that have put in shows that too :-) Cheers, Jes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
James Bottomley wrote: The only way to guarantee ordering in the above setup, is to either make writel() fully ordered or adding the mmiowb()'s inbetween the two writel's. On Altix you have to go and read from the PCI brige to ensure all writes to it have been flushed, which is also what mmiowb() is doing. If writel() was to guarantee this ordering, it would make every writel() call extremely expensive :-( So if a read from the bridge achieves the same effect, can't we just put one after the writes within the spinlock (an unrelaxed one). That way this whole sequence will look like a well understood PCI posting flush rather than have to muck around with little understood (at least by most driver writers) io barriers? Hmmm, I think mmiowb() does some sort of status read from the bridge, I am not sure if it's enough to just do a regular readl(). I'm adding Jeremy to the list, he should know for sure. Cheers, Jes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
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.
So what happened to the old idea of putting the accessor function pointers
in the device/bus structure?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Fri, 30 May 2008 17:24:27 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Fri, 2008-05-30 at 08:07 +0200, Haavard Skinnemoen wrote: > > I think the drivers I've written have the necessary barriers (or dma > > ops with implicit barriers) that they don't actually depend on any > > DMA vs. MMIO ordering guarantees. I hope MMIO vs. MMIO ordering is > > guaranteed though? > > Only to the same address I'd say. Right, I sort of suspected that. Now, I'm pretty sure the architectures that can actually run those drivers (ARM9 and AVR32 AP7) provide stronger guarantees than that, and I suspect the same is true on most other embedded architectures that use __raw_* in their drivers. So I don't think adding barriers is the right thing to do because they won't do anything useful in practice, so it's hard to tell whether they are used "correctly". And it will hurt performance at least on AVR32 since wmb() evaluates to a "sync" instruction, which flushes the write buffer to RAM. Since MMIO writes are unbuffered, that's pure overhead. Maybe we need another interface that does not do byteswapping but provides stronger ordering guarantees? Haavard ___ 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 Friday 30 May 2008, Wolfgang Grandegger wrote:
>
> #ifdef CONFIG_PCI
> - for_each_compatible_node(np, "pci", "fsl,mpc8540-pci")
> - fsl_add_bridge(np, 1);
> + for_each_node_by_type(np, "pci") {
> + if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
> + of_device_is_compatible(np, "fsl,mpc8548-pcie")) {
> + struct resource rsrc;
> + of_address_to_resource(np, 0, &rsrc);
> + if ((rsrc.start & 0xf) == 0x8000)
> + fsl_add_bridge(np, 1);
> + else
> + fsl_add_bridge(np, 0);
> + }
> + }
> #endif
This looks like a very wrong to figure out what is a primary bridge.
I do realize that you copied it from other places, but that doesn't
make it better.
Can't we change fsl_add_bridge to figure this out automatically?
A much better heuristic should be to make a bridge primary if
it has an "ISA" child bus. Does that work for all existing systems?
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MMIO and gcc re-ordering issue
On Fri, 2008-05-30 at 08:07 +0200, Haavard Skinnemoen wrote: > On Fri, 30 May 2008 11:13:23 +1000 > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > Currently, this is the only interface I know that can do native-endian > > > accesses, so if you take it away, I'm gonna need an alternative > > > interface that doesn't do byteswapping. > > > > Are you aware that these also don't provide any ordering guarantee ? > > Yes, but I am not aware of any alternative. > > I think the drivers I've written have the necessary barriers (or dma > ops with implicit barriers) that they don't actually depend on any > DMA vs. MMIO ordering guarantees. I hope MMIO vs. MMIO ordering is > guaranteed though? Only to the same address I'd say. Ben. ___ 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
Stephen Rothwell wrote:
> Hi Wolfgang,
>
> On Fri, 30 May 2008 08:49:45 +0200 Wolfgang Grandegger <[EMAIL PROTECTED]>
> wrote:
>> +++ b/arch/powerpc/platforms/85xx/tqm85xx.c
>> @@ -120,8 +120,17 @@ static void __init tqm85xx_setup_arch(void)
>> #endif
>>
>> #ifdef CONFIG_PCI
>> -for_each_compatible_node(np, "pci", "fsl,mpc8540-pci")
>> -fsl_add_bridge(np, 1);
>> +for_each_node_by_type(np, "pci") {
>> +if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
>> +of_device_is_compatible(np, "fsl,mpc8548-pcie")) {
>> +struct resource rsrc;
>> +of_address_to_resource(np, 0, &rsrc);
>
> What happens if of_address_to_resource fails?
Checking the return code is missing, of course. Obviously a cut & paste
from a bad source (sbc8548.c).
Will fix.
Wolfgang.
___
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
Hi Wolfgang,
On Fri, 30 May 2008 08:49:45 +0200 Wolfgang Grandegger <[EMAIL PROTECTED]>
wrote:
>
> +++ b/arch/powerpc/platforms/85xx/tqm85xx.c
> @@ -120,8 +120,17 @@ static void __init tqm85xx_setup_arch(void)
> #endif
>
> #ifdef CONFIG_PCI
> - for_each_compatible_node(np, "pci", "fsl,mpc8540-pci")
> - fsl_add_bridge(np, 1);
> + for_each_node_by_type(np, "pci") {
> + if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
> + of_device_is_compatible(np, "fsl,mpc8548-pcie")) {
> + struct resource rsrc;
> + of_address_to_resource(np, 0, &rsrc);
What happens if of_address_to_resource fails?
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpOzrHfWGv91.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
