Re: [PATCH 1/3] PCI: Introduce pci_bus_addr_t
On Sat, Apr 4, 2015 at 7:46 AM, Bjorn Helgaas wrote:
> On Fri, Apr 3, 2015 at 10:34 PM, Yinghai Lu wrote:
>> On Fri, Apr 3, 2015 at 1:52 PM, Bjorn Helgaas wrote:
>>> [+cc Sam (commented on previous versions), Russell, linux-arm-kernel, Ralf,
>>> linux-mips, Ben, linuxppc-dev, x86]
>>>
>>> On Fri, Apr 03, 2015 at 02:32:34PM -0500, Bjorn Helgaas wrote:
On Tue, Mar 31, 2015 at 07:57:47PM -0700, Yinghai Lu wrote:
> David Ahern found commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
> to fit in upstream windows") broke booting on sparc/T5-8.
>
> In the boot log, there is
> pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
> 0x110204000)
> but that only could happen when dma_addr_t is 32-bit.
>
> According to David Miller, all DMA occurs behind an IOMMU and these
> IOMMUs only support 32-bit addressing, therefore dma_addr_t is
> 32-bit on sparc64.
>
> Let's introduce pci_bus_addr_t instead of using dma_addr_t,
> and pci_bus_addr_t will be 64-bit on 64-bit platform or X86_PAE.
>
> Fixes: commit d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in
> upstream windows")
> Fixes: commit 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs
> larger than 4GB")
> Link:
> http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
> Reported-by: David Ahern
> Tested-by: David Ahern
> Signed-off-by: Yinghai Lu
> Cc: #3.19
> ---
> drivers/pci/Kconfig | 4
> drivers/pci/bus.c | 10 +-
> drivers/pci/probe.c | 12 ++--
> include/linux/pci.h | 12 +---
> 4 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 7a8f1c5..6a5a269 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -1,6 +1,10 @@
> #
> # PCI configuration
> #
> +config PCI_BUS_ADDR_T_64BIT
> + def_bool y if (64BIT || X86_PAE)
> + depends on PCI
We're going to use pci_bus_addr_t in some places where we previously used
dma_addr_t, which means pci_bus_addr_t should be at least as large as
dma_addr_t. Can you enforce that directly, e.g., with something like this?
def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT || X86_PAE)
>>
>> then should use
>>
>> def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
>
> OK, would you mind updating this series, incorporating the doc
> updates, and reposting it?
>
> I think there's still an unresolved question about the OF parsing code.
Got a pointer to what that is? I'll take a guess. Generally, we make
the parsing code independent of the kernel addr sizes and use u64
types. The DT sizes and kernel sizes are not always aligned. For
example, an LPAE capable platform running a non-LPAE kernel build.
Rob
>
> Bjorn
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] PCI: Introduce pci_bus_addr_t
On Sat, Apr 4, 2015 at 10:25 PM, Bjorn Helgaas wrote: > On Sat, Apr 4, 2015 at 2:48 PM, Rob Herring wrote: >> On Sat, Apr 4, 2015 at 7:46 AM, Bjorn Helgaas wrote: > >>> I think there's still an unresolved question about the OF parsing code. >> >> Got a pointer to what that is? I'll take a guess. Generally, we make >> the parsing code independent of the kernel addr sizes and use u64 >> types. The DT sizes and kernel sizes are not always aligned. For >> example, an LPAE capable platform running a non-LPAE kernel build. > > Yep: > http://lkml.kernel.org/r/1427857069-6789-3-git-send-email-ying...@kernel.org > > Yinghai made a change to the sparc OF parsing code. The question is > whether a similar change should be made to clones of that code (two > others in arch/sparc, one in arch/powerpc, and one in drivers/of). Yes, it appears to me that is needed. At least the drivers/of/ code does not distinguish 32 and 64 bit ATM. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: return NUMA_NO_NODE from fallback of_node_to_nid()
On Wed, Apr 8, 2015 at 11:59 AM, Konstantin Khlebnikov
wrote:
> Node 0 might be offline as well as any other numa node,
> in this case kernel cannot handle memory allocation and crashes.
>
> Signed-off-by: Konstantin Khlebnikov
> Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function")
> ---
> drivers/of/base.c |2 +-
> include/linux/of.h |5 -
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 8f165b112e03..51f4bd16e613 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -89,7 +89,7 @@ EXPORT_SYMBOL(of_n_size_cells);
> #ifdef CONFIG_NUMA
> int __weak of_node_to_nid(struct device_node *np)
> {
> - return numa_node_id();
> + return NUMA_NO_NODE;
This is going to break any NUMA machine that enables OF and expects
the weak function to work.
Rob
> }
> #endif
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index dfde07e77a63..78a04ee85a9c 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -623,7 +623,10 @@ static inline const char *of_prop_next_string(struct
> property *prop,
> #if defined(CONFIG_OF) && defined(CONFIG_NUMA)
> extern int of_node_to_nid(struct device_node *np);
> #else
> -static inline int of_node_to_nid(struct device_node *device) { return 0; }
> +static inline int of_node_to_nid(struct device_node *device)
> +{
> + return NUMA_NO_NODE;
> +}
> #endif
>
> static inline struct device_node *of_find_matching_node(
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: return NUMA_NO_NODE from fallback of_node_to_nid()
On Mon, Apr 13, 2015 at 8:38 AM, Konstantin Khlebnikov
wrote:
> On 13.04.2015 16:22, Rob Herring wrote:
>>
>> On Wed, Apr 8, 2015 at 11:59 AM, Konstantin Khlebnikov
>> wrote:
>>>
>>> Node 0 might be offline as well as any other numa node,
>>> in this case kernel cannot handle memory allocation and crashes.
>>>
>>> Signed-off-by: Konstantin Khlebnikov
>>> Fixes: 0c3f061c195c ("of: implement of_node_to_nid as a weak function")
>>> ---
>>> drivers/of/base.c |2 +-
>>> include/linux/of.h |5 -
>>> 2 files changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index 8f165b112e03..51f4bd16e613 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>> @@ -89,7 +89,7 @@ EXPORT_SYMBOL(of_n_size_cells);
>>> #ifdef CONFIG_NUMA
>>> int __weak of_node_to_nid(struct device_node *np)
>>> {
>>> - return numa_node_id();
>>> + return NUMA_NO_NODE;
>>
>>
>> This is going to break any NUMA machine that enables OF and expects
>> the weak function to work.
>
>
> Why? NUMA_NO_NODE == -1 -- this's standard "no-affinity" signal.
> As I see powerpc/sparc versions of of_node_to_nid returns -1 if they
> cannot find out which node should be used.
Ah, I was thinking those platforms were relying on the default
implementation. I guess any real NUMA support is going to need to
override this function. The arm64 patch series does that as well. We
need to be sure this change is correct for metag which appears to be
the only other OF enabled platform with NUMA support.
In that case, then there is little reason to keep the inline and we
can just always enable the weak function (with your change). It is
slightly less optimal, but the few callers hardly appear to be hot
paths.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] libfdt: add fdt type definitions
In preparation for libfdt/dtc update, add the new fdt specific types. Signed-off-by: Rob Herring Cc: Russell King Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org --- arch/arm/boot/compressed/libfdt_env.h | 4 arch/powerpc/boot/libfdt_env.h| 4 arch/powerpc/boot/of.h| 2 ++ include/linux/libfdt_env.h| 4 4 files changed, 14 insertions(+) diff --git a/arch/arm/boot/compressed/libfdt_env.h b/arch/arm/boot/compressed/libfdt_env.h index 1f4e718..17ae0f3 100644 --- a/arch/arm/boot/compressed/libfdt_env.h +++ b/arch/arm/boot/compressed/libfdt_env.h @@ -5,6 +5,10 @@ #include #include +typedef __be16 fdt16_t; +typedef __be32 fdt32_t; +typedef __be64 fdt64_t; + #define fdt16_to_cpu(x)be16_to_cpu(x) #define cpu_to_fdt16(x)cpu_to_be16(x) #define fdt32_to_cpu(x)be32_to_cpu(x) diff --git a/arch/powerpc/boot/libfdt_env.h b/arch/powerpc/boot/libfdt_env.h index 8dcd744..7e3789e 100644 --- a/arch/powerpc/boot/libfdt_env.h +++ b/arch/powerpc/boot/libfdt_env.h @@ -10,6 +10,10 @@ typedef u32 uint32_t; typedef u64 uint64_t; typedef unsigned long uintptr_t; +typedef __be16 fdt16_t; +typedef __be32 fdt32_t; +typedef __be64 fdt64_t; + #define fdt16_to_cpu(x)be16_to_cpu(x) #define cpu_to_fdt16(x)cpu_to_be16(x) #define fdt32_to_cpu(x)be32_to_cpu(x) diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h index 5603320..53f8f27 100644 --- a/arch/powerpc/boot/of.h +++ b/arch/powerpc/boot/of.h @@ -21,7 +21,9 @@ int of_setprop(const void *phandle, const char *name, const void *buf, /* Console functions */ void of_console_init(void); +typedef u16__be16; typedef u32__be32; +typedef u64__be64; #ifdef __LITTLE_ENDIAN__ #define cpu_to_be16(x) swab16(x) diff --git a/include/linux/libfdt_env.h b/include/linux/libfdt_env.h index 01508c7..2a663c6 100644 --- a/include/linux/libfdt_env.h +++ b/include/linux/libfdt_env.h @@ -5,6 +5,10 @@ #include +typedef __be16 fdt16_t; +typedef __be32 fdt32_t; +typedef __be64 fdt64_t; + #define fdt32_to_cpu(x) be32_to_cpu(x) #define cpu_to_fdt32(x) cpu_to_be32(x) #define fdt64_to_cpu(x) be64_to_cpu(x) -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
+dt list
On Fri, May 1, 2015 at 1:03 AM, Gavin Shan wrote:
> The requirement is raised when developing the PCI hotplug feature
> for PowerPC PowerNV platform, which runs on top of skiboot firmware.
> When plugging PCI adapter to one PCI slot, the firmware rescans the
> slot and build FDT (Flat Device Tree) blob, which is sent to the
> PowerNV PCI hotplug driver for processing. The new constructed device
> nodes from the FDT blob are expected to be attached to the device
> node of the PCI slot. Unfortunately, it seems we don't have a API
> to support the scenario. The patch intends to support it by newly
> introduced function of_fdt_add_subtree(), the design behind it is
> shown as below:
>
>* When the sub-tree FDT blob, which is owned by firmware, is
> received by kernel. It's copied over to the blob, which is
> dynamically allocated. Since then, the FDT blob owned by
> firmware isn't touched.
>* Rework unflatten_dt_node() so that the device nodes in current
> and deeper depth have been constructed from the FDT blob. All
> device nodes are marked with flag OF_DYNAMIC_HYBIRD, which is
Perhaps you meant HYBRID?
> similar to OF_DYNAMIC. However, device node with the flag set
> can be free'd, but in the way other than that for OF_DYNAMIC
> device nodes.
The difference seems to be whether you allocate space or just point to
the FDT for various strings/data. Is that right?
>* of_fdt_add_subtree() is the introduced API to do the work.
Have you looked at overlays and if so why do they not work for your purposes?
Why do you need to do this with the flattened tree?
Rob
>
> Cc: Grant Likely
> Cc: Rob Herring
> Signed-off-by: Gavin Shan
> ---
> drivers/of/dynamic.c | 19 +--
> drivers/of/fdt.c | 133
> -
> include/linux/of.h | 2 +
> include/linux/of_fdt.h | 1 +
> 4 files changed, 127 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index 3351ef4..f562080 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -330,13 +330,22 @@ void of_node_release(struct kobject *kobj)
> return;
> }
>
> - if (!of_node_check_flag(node, OF_DYNAMIC))
> + /* Release the subtree */
> + if (node->subtree) {
> + kfree(node->subtree);
> + node->subtree = NULL;
> + }
> +
> + if (!of_node_check_flag(node, OF_DYNAMIC) &&
> + !of_node_check_flag(node, OF_DYNAMIC_HYBIRD))
> return;
>
> while (prop) {
> struct property *next = prop->next;
> - kfree(prop->name);
> - kfree(prop->value);
> + if (of_node_check_flag(node, OF_DYNAMIC)) {
> + kfree(prop->name);
> + kfree(prop->value);
> + }
> kfree(prop);
> prop = next;
>
> @@ -345,7 +354,9 @@ void of_node_release(struct kobject *kobj)
> node->deadprops = NULL;
> }
> }
> - kfree(node->full_name);
> +
> + if (of_node_check_flag(node, OF_DYNAMIC))
> + kfree(node->full_name);
> kfree(node->data);
> kfree(node);
> }
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index cde35c5d01..7659560 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -28,6 +28,10 @@
> #include /* for COMMAND_LINE_SIZE */
> #include
>
> +#include "of_private.h"
> +
> +static int cur_node_depth;
> +
> /*
> * of_fdt_limit_memory - limit the number of regions in the /memory node
> * @limit: maximum entries
> @@ -168,20 +172,20 @@ static void *unflatten_dt_alloc(void **mem, unsigned
> long size,
> * @dad: Parent struct device_node
> * @fpsize: Size of the node path up at the current depth.
> */
> -static void * unflatten_dt_node(void *blob,
> - void *mem,
> - int *poffset,
> - struct device_node *dad,
> - struct device_node **nodepp,
> - unsigned long fpsize,
> - bool dryrun)
> +static void *unflatten_dt_node(void *blob,
> + void *mem,
> + int *poffset,
> + struct device_node *dad,
> + struct device_node **nodepp,
> + unsigned long fpsize,
> +
Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
On Fri, May 1, 2015 at 10:22 AM, Benjamin Herrenschmidt wrote: > On Fri, 2015-05-01 at 07:54 -0500, Rob Herring wrote: > >> The difference seems to be whether you allocate space or just point to >> the FDT for various strings/data. Is that right? >> >> >* of_fdt_add_subtree() is the introduced API to do the work. >> >> Have you looked at overlays and if so why do they not work for your purposes? >> >> Why do you need to do this with the flattened tree? > > The basic idea I asked Gavin to implement is that since the FW needs to > provide a bunch of DT updates to Linux at runtime in the form of new > nodes below an existing one, rather than doing it via some new/custom > format, instead, have it send a bit of FDT blob to expand under an > existing node. Overlay = an FDT blob to graft into a live running system. Sounds like the same thing. > As for the details of Gavin implementation, I haven't looked at it in > details yet so there might be issues there, however I don't know what > you mean by "overlays", any pointer ? CONFIG_OF_OVERLAY http://events.linuxfoundation.org/sites/events/files/slides/dynamic-dt-keynote-v3.pdf Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 1/1] arm64: dts: Add the arasan sdhc nodes in apm-storm.dtsi.
On Tue, May 5, 2015 at 4:17 AM, Suman Tripathi wrote:
> This patch adds the arasan sdhc nodes to reuse the of-arasan
> driver for APM X-Gene SoC.
>
> Signed-off-by: Suman Tripathi
> ---
> arch/arm64/boot/dts/apm/apm-mustang.dts | 4 +++
> arch/arm64/boot/dts/apm/apm-storm.dtsi | 44
> +
> 2 files changed, 48 insertions(+)
[...]
> @@ -533,6 +567,16 @@
> interrupts = <0x0 0x4f 0x4>;
> };
>
> + sdhc0: sdhc@1c00 {
> + device_type = "sdhc";
device_type generally should not be used (there are a few exceptions).
> + compatible = "arasan,sdhci-4.9a";
If you ever have an integration or xgene specific problem, you need a
chip specific compatible.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 19/21] drivers/of: Support adding sub-tree
On Wed, May 13, 2015 at 6:35 PM, Benjamin Herrenschmidt wrote: > On Tue, 2015-05-05 at 07:14 +1000, Benjamin Herrenschmidt wrote: >> So the "trivial" way to do it (and the way we have implemented the FW >> side so far) is to have the FW simply "flatten" the subtree below the >> slot and pass it to Linux, with the intent of expanding it back below >> the slot node. >> >> This is what Gavin proposed patches do. >> >> The overlay mechanism adds all sorts of features that we don't seen to >> need and would make the above more complex. > > Guys, I never got a final answer from you on this. Are we ok with adding > the way to just expand a subtree or are you insistent we need to use the > overlap mechanism ? I haven't decided really. The main thing with the current patch is I don't really like the added complexity to unflatten_dt_node. It is already a fairly complex function. Perhaps removing of "hybrid" as discussed will help? If there are things we can do to make overlays easier to use in your use case, I'd like to hear ideas. I don't really buy that being more complex than needed is an obstacle. That is very often the case to have common, scale-able solutions. I want to see a simple case be simple to support. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] of: clean-up unnecessary libfdt include paths
With the latest dtc import include fixups, it is no longer necessary to add explicit include paths to use libfdt. Remove these across the kernel. Signed-off-by: Rob Herring Cc: Ralf Baechle Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Grant Likely Cc: linux-m...@linux-mips.org Cc: linuxppc-dev@lists.ozlabs.org --- arch/mips/cavium-octeon/Makefile | 3 --- arch/mips/mti-sead3/Makefile | 2 -- arch/powerpc/kernel/Makefile | 1 - drivers/firmware/efi/libstub/Makefile | 2 -- drivers/of/Makefile | 3 --- 5 files changed, 11 deletions(-) diff --git a/arch/mips/cavium-octeon/Makefile b/arch/mips/cavium-octeon/Makefile index 69a8a8d..2a59265 100644 --- a/arch/mips/cavium-octeon/Makefile +++ b/arch/mips/cavium-octeon/Makefile @@ -9,9 +9,6 @@ # Copyright (C) 2005-2009 Cavium Networks # -CFLAGS_octeon-platform.o = -I$(src)/../../../scripts/dtc/libfdt -CFLAGS_setup.o = -I$(src)/../../../scripts/dtc/libfdt - obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o obj-y += dma-octeon.o obj-y += octeon-memcpy.o diff --git a/arch/mips/mti-sead3/Makefile b/arch/mips/mti-sead3/Makefile index ecd71db..2e52cbd 100644 --- a/arch/mips/mti-sead3/Makefile +++ b/arch/mips/mti-sead3/Makefile @@ -15,5 +15,3 @@ obj-y := sead3-lcd.o sead3-display.o sead3-init.o \ obj-y += leds-sead3.o obj-$(CONFIG_EARLY_PRINTK) += sead3-console.o - -CFLAGS_sead3-setup.o = -I$(src)/../../../scripts/dtc/libfdt diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index c1ebbda..c16e836 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -2,7 +2,6 @@ # Makefile for the linux kernel. # -CFLAGS_prom.o = -I$(src)/../../../scripts/dtc/libfdt CFLAGS_ptrace.o+= -DUTS_MACHINE='"$(UTS_MACHINE)"' subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index 280bc0a..816dbe9 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -24,8 +24,6 @@ KASAN_SANITIZE:= n lib-y := efi-stub-helper.o lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o -CFLAGS_fdt.o += -I$(srctree)/scripts/dtc/libfdt/ - # # arm64 puts the stub in the kernel proper, which will unnecessarily retain all # code indefinitely unless it is annotated as __init/__initdata/__initconst etc. diff --git a/drivers/of/Makefile b/drivers/of/Makefile index fcacb18..156c072 100644 --- a/drivers/of/Makefile +++ b/drivers/of/Makefile @@ -16,6 +16,3 @@ obj-$(CONFIG_OF_RESOLVE) += resolver.o obj-$(CONFIG_OF_OVERLAY) += overlay.o obj-$(CONFIG_OF_UNITTEST) += unittest-data/ - -CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt -CFLAGS_fdt_address.o = -I$(src)/../../scripts/dtc/libfdt -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: of: clean-up unnecessary libfdt include paths
On Thu, Jun 4, 2015 at 5:20 AM, Michael Ellerman wrote: > On Wed, 2015-03-06 at 05:10:25 UTC, Rob Herring wrote: >> With the latest dtc import include fixups, it is no longer necessary to >> add explicit include paths to use libfdt. Remove these across the >> kernel. > > What are the "latest dtc import include fixups" ? Changing the scripts/dtc/libfdt/libfdt.h includes from <> to "". The import script does this now and the recent import in my for-next tree has this. I'll clarify this in the commit message. > >> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile >> index c1ebbda..c16e836 100644 >> --- a/arch/powerpc/kernel/Makefile >> +++ b/arch/powerpc/kernel/Makefile >> @@ -2,7 +2,6 @@ >> # Makefile for the linux kernel. >> # >> >> -CFLAGS_prom.o= -I$(src)/../../../scripts/dtc/libfdt >> CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' >> >> subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror > > Acked-by: Michael Ellerman Thanks. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Check flat device tree version at boot
On Thu, Aug 28, 2014 at 3:40 AM, Michael Ellerman wrote:
> In commit e6a6928c3ea1 "of/fdt: Convert FDT functions to use libfdt",
> the kernel stopped supporting old flat device tree formats. The minimum
> supported version is now 0x10.
Ugg. Is that something which needs to be supported? Supporting it at
this point would mean adding support to libfdt.
Rob
> There was a checking function added, early_init_dt_verify(), but it's
> not called on powerpc.
>
> The result is, if you boot with an old flat device tree, the kernel will
> fail to parse it correctly, think you have no memory etc. and hilarity
> ensues.
>
> We can't really fix it, but we can at least catch the fact that the
> device tree is in an unsupported format and panic(). We can't call
> BUG(), it's too early.
>
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/kernel/prom.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 4e139f8a69ef..bb777b255b1c 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -641,6 +641,10 @@ void __init early_init_devtree(void *params)
>
> DBG(" -> early_init_devtree(%p)\n", params);
>
> + /* Too early to BUG_ON(), do it by hand */
> + if (!early_init_dt_verify(params))
> + panic("BUG: Failed verifying flat device tree, bad version?");
> +
> /* Setup flat device-tree pointer */
> initial_boot_params = params;
>
> --
> 1.9.1
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Check flat device tree version at boot
On Fri, Aug 29, 2014 at 6:13 AM, Grant Likely wrote:
> On 29 Aug 2014 02:56, "Michael Ellerman" wrote:
>>
>> On Thu, 2014-08-28 at 09:27 -0500, Rob Herring wrote:
>> > On Thu, Aug 28, 2014 at 3:40 AM, Michael Ellerman
>> > wrote:
>> > > In commit e6a6928c3ea1 "of/fdt: Convert FDT functions to use libfdt",
>> > > the kernel stopped supporting old flat device tree formats. The minimum
>> > > supported version is now 0x10.
>> >
>> > Ugg. Is that something which needs to be supported? Supporting it at
>> > this point would mean adding support to libfdt.
>>
>> Well it would have been nice to keep supporting v2, dropping it broke
>> kexec-tools for example. But it's done now, so we'll just deal with the
>> fallout.
>
> Umm, so we broke userspace? That's not okay. At the very least we
> should investigate how much work is needed to bring v2 support into
> libfdt, or up-rev the flat tree at runtime before we parse it.
Would up-reving work? kexec-tools is broken or booting a new kernel
with kexec is broken?
> We should be able to update it in-line. IIRC, the main difference
> between v2 and v0x10 is that only the leaf node name is encoded into
> the node instead of the full name. We can loop over the tree and
> truncate all the names while filling the unused bytes with FDT NOP
> tags. Should be simple. Something like the following:
There is also the name property in v1-v3. I'm guessing linux ignores
that already?
>
> fixup_old_device_tree(blob)
> {
>for (offset = fdt_next_node(blob, -1, &depth);
> offset >= 0 && depth >= 0 && !rc;
> offset = fdt_next_node(blob, offset, &depth)) {
> char *pathp = fdt_get_name(blob, offset, NULL);
> if (*pathp == '/') {
> char *leaf = kbasename(pathp);
> int len = strlen(pathp);
> int newlen = strlen(leaf);
> strcpy(pathp, leaf); /* copying in place, need
> to check make sure this code is safe */
> node->size = newlen /* fixme - this is just
> pseudocode */
> newlen = FDT_TAGALIGN(newlen);
> while (newlen < len) {
> *(pathp + newlen) = FDT_NOP;
> newlen = FDT_TAGALIGN(newlen+1);
> }
> }
>}
>
> }
>
> There's probable some more elegance that can be put into the above
> block, but you get the idea. That could be run in-place without
> copying the tree to another location, and it could possibly be done in
> the boot wrapper. Then we'd also be able to get rid of the v2
> compatibility code elsewhere in drivers/of/fdt.c because it would
> already be taken care of.
That's what got us into this problem. ;)
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/base: Fix PowerPC address parsing hack
On Tue, Nov 11, 2014 at 11:51 PM, Benjamin Herrenschmidt
wrote:
> We have a historical hack that treats missing ranges properties as the
> equivalent of an empty one. This is needed for ancient PowerMac "bad"
> device-trees, and shouldn't be enabled for any other PowerPC platform,
> otherwise we get some nasty layout of devices in sysfs or even
> duplication when a set of otherwise identically named devices is
> created multiple times under a different parent node with no ranges
> property.
>
> This fix is needed for the PowerNV i2c busses to be exposed properly
> and will fix a number of other embedded cases.
>
> Signed-off-by: Benjamin Herrenschmidt
> CC:
> ---
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index e371825..e37f017 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -7,6 +7,10 @@
> #include
> #include
>
> +#ifdef CONFIG_PPC
> +#include
> +#endif
> +
> /* Max address size we deal with */
> #define OF_MAX_ADDR_CELLS 4
> #define OF_CHECK_ADDR_COUNT(na)((na) > 0 && (na) <=
> OF_MAX_ADDR_CELLS)
> @@ -428,12 +432,13 @@ static int of_translate_one(struct device_node *parent,
> struct of_bus *bus,
> * This code is only enabled on powerpc. --gcl
> */
> ranges = of_get_property(parent, rprop, &rlen);
> -#if !defined(CONFIG_PPC)
> +#if defined(CONFIG_PPC)
> + if (!machine_is(powermac))
Can we use a machine compatible here or something not PPC specific?
Then we can use IS_ENABLED(CONFIG_PPC) instead of ifdefs.
Rob
> +#endif /* defined(CONFIG_PPC) */
> if (ranges == NULL) {
> - pr_err("OF: no ranges; cannot translate\n");
> + pr_debug("OF: no ranges; cannot translate\n");
> return 1;
> }
> -#endif /* !defined(CONFIG_PPC) */
> if (ranges == NULL || rlen == 0) {
> offset = of_read_number(addr, na);
> memset(addr, 0, pna * 4);
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/16] PCI generic configuration space accessors
This series adds common accessor functions for PCI configuration space accesses. This supports most PCI hosts with memory mapped configuration space like ECAM or hosts with memory mapped address/data registers. ECAM is not generically supported by this series, but could be added on top of this. While some hosts have standard address decoding which could be common as well, the various checks on bus numbers and device numbers are quite varied. It is unclear how much of that is really necessary or could be common. The first 4 patches are preparatory cleanup. Patch 5 introduces the common accessors. The remaining patches convert several PCI host controllers. This is in no way a complete list of host controllers. The conversion of more hosts should be possible. The Designware controller in particular should be able to be converted, but its config space accessors are a mess of override-able functions that I've not gotten my head around. This series is available here [1]. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git pci-config-access Rob Herring (16): frv: add struct pci_ops member names to initialization mips: add struct pci_ops member names to initialization mn10300: add struct pci_ops member names to initialization powerpc: add struct pci_ops member names to initialization pci: introduce common pci config space accessors ARM: cns3xxx: convert PCI to use generic config accesses ARM: integrator: convert PCI to use generic config accesses ARM: sa1100: convert PCI to use generic config accesses ARM: ks8695: convert PCI to use generic config accesses powerpc: fsl_pci: convert PCI to use generic config accesses powerpc: powermac: convert PCI to use generic config accesses pci/host: generic: convert to use generic config accesses pci/host: rcar-gen2: convert to use generic config accesses pci/host: tegra: convert to use generic config accesses pci/host: xgene: convert to use generic config accesses pci/host: xilinx: convert to use generic config accesses arch/arm/mach-cns3xxx/pcie.c | 52 ++ arch/arm/mach-integrator/pci_v3.c | 61 +--- arch/arm/mach-ks8695/pci.c | 77 + arch/arm/mach-sa1100/pci-nanoengine.c | 94 +-- arch/frv/mb93090-mb00/pci-vdk.c| 4 +- arch/mips/pci/pci-bcm1480.c| 4 +- arch/mips/pci/pci-octeon.c | 4 +- arch/mips/pci/pcie-octeon.c| 12 +- arch/mn10300/unit-asb2305/pci.c| 4 +- arch/powerpc/platforms/cell/celleb_scc_pciex.c | 4 +- arch/powerpc/platforms/powermac/pci.c | 209 + arch/powerpc/sysdev/fsl_pci.c | 46 +- drivers/pci/access.c | 87 ++ drivers/pci/host/pci-host-generic.c| 51 +- drivers/pci/host/pci-rcar-gen2.c | 51 +- drivers/pci/host/pci-tegra.c | 55 +-- drivers/pci/host/pci-xgene.c | 150 ++ drivers/pci/host/pcie-xilinx.c | 88 ++- include/linux/pci.h| 11 ++ 19 files changed, 212 insertions(+), 852 deletions(-) -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 04/16] powerpc: add struct pci_ops member names to initialization
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.
Signed-off-by: Rob Herring
Cc: Arnd Bergmann
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Cc: cbe-oss-...@lists.ozlabs.org
---
arch/powerpc/platforms/cell/celleb_scc_pciex.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
index f223875..94170e4 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
@@ -399,8 +399,8 @@ static int scc_pciex_write_config(struct pci_bus *bus,
unsigned int devfn,
}
static struct pci_ops scc_pciex_pci_ops = {
- scc_pciex_read_config,
- scc_pciex_write_config,
+ .read = scc_pciex_read_config,
+ .write = scc_pciex_write_config,
};
static void pciex_clear_intr_all(unsigned int __iomem *base)
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 10/16] powerpc: fsl_pci: convert PCI to use generic config accesses
Convert the fsl_pci driver to use the generic config access functions.
This changes accesses from (in|out)_(8|le16|le32) to readX/writeX
variants. I believe these should be equivalent for PCI config space
accesses, but confirmation would be nice.
Signed-off-by: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/sysdev/fsl_pci.c | 46 +++
1 file changed, 3 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 6455c1e..271b67e 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -645,61 +645,21 @@ mapped:
return pcie->cfg_type1 + offset;
}
-static int mpc83xx_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
-{
- void __iomem *cfg_addr;
-
- cfg_addr = mpc83xx_pcie_remap_cfg(bus, devfn, offset);
- if (!cfg_addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- switch (len) {
- case 1:
- *val = in_8(cfg_addr);
- break;
- case 2:
- *val = in_le16(cfg_addr);
- break;
- default:
- *val = in_le32(cfg_addr);
- break;
- }
-
- return PCIBIOS_SUCCESSFUL;
-}
-
static int mpc83xx_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 val)
{
struct pci_controller *hose = pci_bus_to_host(bus);
- void __iomem *cfg_addr;
-
- cfg_addr = mpc83xx_pcie_remap_cfg(bus, devfn, offset);
- if (!cfg_addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
/* PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS */
if (offset == PCI_PRIMARY_BUS && bus->number == hose->first_busno)
val &= 0xff00;
- switch (len) {
- case 1:
- out_8(cfg_addr, val);
- break;
- case 2:
- out_le16(cfg_addr, val);
- break;
- default:
- out_le32(cfg_addr, val);
- break;
- }
-
- return PCIBIOS_SUCCESSFUL;
+ return pci_generic_config_write(bus, devfn, offset, len, val);
}
static struct pci_ops mpc83xx_pcie_ops = {
- .read = mpc83xx_pcie_read_config,
+ .map_bus = mpc83xx_pcie_remap_cfg,
+ .read = pci_generic_config_read,
.write = mpc83xx_pcie_write_config,
};
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 11/16] powerpc: powermac: convert PCI to use generic config accesses
Convert the powermac PCI driver to use the generic config access functions.
This changes accesses from (in|out)_(8|le16|le32) to readX/writeX
variants. I believe these should be equivalent for PCI config space
accesses, but confirmation would be nice.
Signed-off-by: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/powermac/pci.c | 209 +++---
1 file changed, 39 insertions(+), 170 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c
b/arch/powerpc/platforms/powermac/pci.c
index 04702db..f4071a6 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -133,17 +133,23 @@ static void __init fixup_bus_range(struct device_node
*bridge)
|(((unsigned int)(off)) & 0xFCUL) \
|1UL)
-static volatile void __iomem *macrisc_cfg_access(struct pci_controller* hose,
- u8 bus, u8 dev_fn, u8 offset)
+static void __iomem *macrisc_cfg_map_bus(struct pci_bus *bus,
+unsigned int dev_fn,
+int offset)
{
unsigned int caddr;
+ struct pci_controller *hose;
- if (bus == hose->first_busno) {
+ hose = pci_bus_to_host(bus);
+ if (hose == NULL)
+ return NULL;
+
+ if (bus->number == hose->first_busno) {
if (dev_fn < (11 << 3))
return NULL;
caddr = MACRISC_CFA0(dev_fn, offset);
} else
- caddr = MACRISC_CFA1(bus, dev_fn, offset);
+ caddr = MACRISC_CFA1(bus->number, dev_fn, offset);
/* Uninorth will return garbage if we don't read back the value ! */
do {
@@ -154,129 +160,46 @@ static volatile void __iomem *macrisc_cfg_access(struct
pci_controller* hose,
return hose->cfg_data + offset;
}
-static int macrisc_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
-{
- struct pci_controller *hose;
- volatile void __iomem *addr;
-
- hose = pci_bus_to_host(bus);
- if (hose == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
- if (offset >= 0x100)
- return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = macrisc_cfg_access(hose, bus->number, devfn, offset);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
- /*
-* Note: the caller has already checked that offset is
-* suitably aligned and that len is 1, 2 or 4.
-*/
- switch (len) {
- case 1:
- *val = in_8(addr);
- break;
- case 2:
- *val = in_le16(addr);
- break;
- default:
- *val = in_le32(addr);
- break;
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int macrisc_write_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 val)
-{
- struct pci_controller *hose;
- volatile void __iomem *addr;
-
- hose = pci_bus_to_host(bus);
- if (hose == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
- if (offset >= 0x100)
- return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = macrisc_cfg_access(hose, bus->number, devfn, offset);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
- /*
-* Note: the caller has already checked that offset is
-* suitably aligned and that len is 1, 2 or 4.
-*/
- switch (len) {
- case 1:
- out_8(addr, val);
- break;
- case 2:
- out_le16(addr, val);
- break;
- default:
- out_le32(addr, val);
- break;
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
static struct pci_ops macrisc_pci_ops =
{
- .read = macrisc_read_config,
- .write = macrisc_write_config,
+ .map_bus = macrisc_cfg_map_bus,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
};
#ifdef CONFIG_PPC32
/*
* Verify that a specific (bus, dev_fn) exists on chaos
*/
-static int chaos_validate_dev(struct pci_bus *bus, int devfn, int offset)
+static void __iomem *chaos_map_bus(struct pci_bus *bus, unsigned int devfn,
+ int offset)
{
struct device_node *np;
const u32 *vendor, *device;
if (offset >= 0x100)
- return PCIBIOS_BAD_REGISTER_NUMBER;
+ return NULL;
np = of_pci_find_child_device(bus->dev.of_node, devfn);
if (np == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
+ return NULL;
vendor = of_get_property(np, "vendor-id", NULL);
device = of_ge
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On Thu, Apr 25, 2013 at 3:45 PM, Rob Herring wrote: > On 04/25/2013 03:12 PM, Benjamin Herrenschmidt wrote: >> On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote: >>> On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: > > [...] > >>> You need patch 2 of this series to fix this: >>> >>> driver core: move to_platform_driver to platform_device.h >>> >>> which as Arnd pointed out needs to come first. I've fixed that in my >>> tree, but I don't think it warrants another post. >> >> Can I pull you tree from somewhere to test ? > > Here you go: > > git://sources.calxeda.com/kernel/linux.git of-platform-removal Ben, Did you have a chance to test this? I want to get this into -next. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: Specify initrd location using 64-bit
On 06/21/2013 12:20 PM, Santosh Shilimkar wrote:
> On Friday 21 June 2013 05:04 AM, Sebastian Andrzej Siewior wrote:
>> On 06/21/2013 02:52 AM, Santosh Shilimkar wrote:
>>> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
>>> index 0a2c68f..62e2e8f 100644
>>> --- a/arch/microblaze/kernel/prom.c
>>> +++ b/arch/microblaze/kernel/prom.c
>>> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
>>> }
>>>
>>> #ifdef CONFIG_BLK_DEV_INITRD
>>> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
>>> - unsigned long end)
>>> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>>> {
>>> initrd_start = (unsigned long)__va(start);
>>> initrd_end = (unsigned long)__va(end);
>>
>> I think it would better to go here for phys_addr_t instead of u64. This
>> would force you in of_flat_dt_match() to check if the value passed from
>> DT specifies a memory address outside of 32bit address space and the
>> kernel can't deal with this because its phys_addr_t is 32bit only due
>> to a Kconfig switch.
>>
>> For x86, the initrd has to remain in the 32bit address space so passing
>> the initrd in the upper range would violate the ABI. Not sure if this
>> is true for other archs as well (ARM obviously not).
>>
> That pretty much means phys_addr_t. It will work for me as well but
> in last thread from consistency with memory and reserved node, Rob
> insisted to keep it as u64. So before I re-spin another version,
> would like to here what Rob has to say considering the x86 requirement.
>
> Rob,
> Are you ok with phys_addr_t since your concern was about rest
> of the memory specific bits of the device-tree code use u64 ?
No. I still think it should be u64 for same reasons I said originally.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] of: Specify initrd location using 64-bit
On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
>
> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
> It was concluded to stick to u64 to be consistent with rest of the device
> tree code. As summarized by Geert, "The address to load the initrd is decided
> by the bootloader/user and set at that point later in time. The dtb should not
> be tied to the kernel you are booting"
That was quoting me. Otherwise:
Acked-by: Rob Herring
Unless Grant feels compelled to pick this up for 3.11, I think it has to
wait for 3.12.
Rob
>
> More details on the discussion can be found here:
> https://lkml.org/lkml/2013/6/20/690
> https://lkml.org/lkml/2012/9/13/544
>
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Geert Uytterhoeven
> Cc: Sebastian Andrzej Siewior
> Cc: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Vineet Gupta
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Salter
> Cc: Aurelien Jacquiot
> Cc: James Hogan
> Cc: Michal Simek
> Cc: Ralf Baechle
> Cc: Jonas Bonn
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: x...@kernel.org
> Cc: a...@kernel.org
> Cc: Chris Zankel
> Cc: Max Filippov
> Cc: bige...@linutronix.de
> Cc: robherri...@gmail.com
> Cc: Nicolas Pitre
>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c6x-...@linux-c6x.org
> Cc: linux-m...@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-xte...@linux-xtensa.org
> Cc: devicetree-disc...@lists.ozlabs.org
>
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arc/mm/init.c|5 ++---
> arch/arm/mm/init.c|2 +-
> arch/arm64/mm/init.c |3 +--
> arch/c6x/kernel/devicetree.c |3 +--
> arch/metag/mm/init.c |5 ++---
> arch/microblaze/kernel/prom.c |3 +--
> arch/mips/kernel/prom.c |3 +--
> arch/openrisc/kernel/prom.c |3 +--
> arch/powerpc/kernel/prom.c|3 +--
> arch/x86/kernel/devicetree.c |3 +--
> arch/xtensa/kernel/setup.c|3 +--
> drivers/of/fdt.c | 10 ++
> include/linux/of_fdt.h|3 +--
> 13 files changed, 20 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 4a17736..7991e08 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned
> long end)
> #endif
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> - pr_err("%s(%lx, %lx)\n", __func__, start, end);
> + pr_err("%s(%llx, %llx)\n", __func__, start, end);
> }
> #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 9a5cdc0..afeaef7 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
> __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned
> long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> phys_initrd_start = start;
> phys_initrd_size = end - start;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f497ca7..7047708 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
>
> phys_addr_t memstart_addr __read_mostly = 0;
>
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> phys_initrd_start = start;
> phys_initrd_size = end - start;
> diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
> index bdb56f0..287d0e6 100644
> --- a/arch/c6x/kernel/devicetree.c
> +++ b/arch/c6x/kernel/devicetree.c
> @@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
>
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned
Re: [PATCH] of: Fix address decoding on Bimini and js2x machines
On 07/03/2013 01:01 AM, Benjamin Herrenschmidt wrote:
> Commit:
>
> e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7
> of/address: Handle #address-cells > 2 specially
>
> broke real time clock access on Bimini, js2x, and similar powerpc
> machines using the "maple" platform. That code was indirectly relying
> on the old (broken) behaviour of the translation for the hypertransport
> to ISA bridge.
>
> This fixes it by treating hypertransport as a PCI bus
>
> Signed-off-by: Benjamin Herrenschmidt
> CC: [v3.6+]
> ---
>
> Rob, if you have no objection I will put that in powerpc -next
NP.
Acked-by: Rob Herring
Rob
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 04da786..7c8221d 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -106,8 +106,12 @@ static unsigned int of_bus_default_get_flags(const
> __be32 *
>
> static int of_bus_pci_match(struct device_node *np)
> {
> - /* "vci" is for the /chaos bridge on 1st-gen PCI powermacs */
> - return !strcmp(np->type, "pci") || !strcmp(np->type, "vci");
> + /*
> +* "vci" is for the /chaos bridge on 1st-gen PCI powermacs
> +* "ht" is hypertransport
> +*/
> + return !strcmp(np->type, "pci") || !strcmp(np->type, "vci") ||
> + !strcmp(np->type, "ht");
> }
>
> static void of_bus_pci_count_cells(struct device_node *np,
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 2/2] powerpc/512x: add LocalPlus Bus FIFO device driver
On 07/10/2013 08:46 AM, Gerhard Sittig wrote:
> On Wed, Jul 10, 2013 at 14:21 +0400, Alexander Popov wrote:
>>
>> This is SCLPC device driver for the Freescale MPC512x.
>> It is needed for Direct Memory Access to the devices on LocalPlus Bus.
>>
>> Signed-off-by: Alexander Popov
>> ---
>> arch/powerpc/boot/dts/mpc5121.dtsi| 8 +-
>> arch/powerpc/include/asm/mpc5121.h| 32 ++
>> arch/powerpc/platforms/512x/Kconfig | 6 +
>> arch/powerpc/platforms/512x/Makefile | 1 +
>> arch/powerpc/platforms/512x/mpc512x_lpbfifo.c | 485
>> ++
>> 5 files changed, 531 insertions(+), 1 deletion(-)
>> create mode 100644 arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
>>
>> diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi
>> b/arch/powerpc/boot/dts/mpc5121.dtsi
>> index bd14c00..6e0b0c0 100644
>> --- a/arch/powerpc/boot/dts/mpc5121.dtsi
>> +++ b/arch/powerpc/boot/dts/mpc5121.dtsi
>> @@ -261,7 +261,13 @@
>> /* LocalPlus controller */
>> lpc@1 {
>> compatible = "fsl,mpc5121-lpc";
>> -reg = <0x1 0x200>;
>> +reg = <0x1 0x100>;
>> +};
>> +
>> +sclpc@10100 {
>> +compatible = "fsl,mpc512x-lpbfifo";
The binding needs to be documented.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG] mpc8323_rdb platform doesn't boot since kernel 3.16
On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy wrote: > I've got a MPC8323 RDB evaluation platform from freescale > kernel 4.0 doesn't boot > kernel 3.16 doesn't boot > kernel 3.15 boots ok > > I disected the issue down to your commit "of/fdt: Convert FDT functions to > use libfdt" (e6a6928c3ea1d0195ed75a091e345696b916c09b) > > Do you have an idea of what the issue could be ? Is your dtb older version of the dtb format (before 0x10)? libfdt doesn't work on the older versions. If not, do you have logs with debug enabled in drivers/of/fdt.c? Rob > > Christophe > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le > logiciel antivirus Avast. > https://www.avast.com/antivirus > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUG] mpc8323_rdb platform doesn't boot since kernel 3.16
On Wed, Jun 10, 2015 at 10:12 AM, leroy christophe wrote: > Le 06/06/2015 17:32, Rob Herring a écrit : >> >> On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy >> wrote: >>> >>> I've got a MPC8323 RDB evaluation platform from freescale >>> kernel 4.0 doesn't boot >>> kernel 3.16 doesn't boot >>> kernel 3.15 boots ok >>> >>> I disected the issue down to your commit "of/fdt: Convert FDT functions >>> to >>> use libfdt" (e6a6928c3ea1d0195ed75a091e345696b916c09b) >>> >>> Do you have an idea of what the issue could be ? >> >> Is your dtb older version of the dtb format (before 0x10)? libfdt >> doesn't work on the older versions. > > Yes, dtb has version 0x11, which seems to be the issue (see below) In that your bootloader doesn't understand 0x11. >> If not, do you have logs with debug enabled in drivers/of/fdt.c? > > I get "unflatten: error -11 processing FDT" Can I get the full debug prints. > Indeed, Uboot (version 1.1.6 - installed on that evaluation board) adds a > node called "chosen" at the end of the BLOB. > But Uboot doesn't update the FDT len in the BLOB header, therefore the > following test fails in fdt_offset_ptr() > > if (fdt_version(fdt) >= 0x11) > if (((offset + len) < offset) > || ((offset + len) > fdt_size_dt_struct(fdt))) > return NULL; > > > If I comment this test out, Linux 3.16 to 4.0 work properly on my evaluation > board. > > Can we find a proper workaround for this issue ? The options are: - update the ancient bootloader - make dtc build 0x10 version dtb for this platform (-V option will do this) - make the kernel fix the field (I'm not sure how we get the correct length. dt_string offset minus dt_struct offset?) - make the kernel force the version to 0x10 (I don't think there are any other changes from 0x10 to 0x11.) I'd probably lean toward the 2nd option. This is what the bootloader is compatible with and won't break if we rev the format again. I believe there is already some plumbing to pass per platform options to dtc. The question is what other platforms have this problem. Rob > Christophe > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
On Mon, Jun 15, 2015 at 11:42 AM, David Long wrote:
> From: "David A. Long"
>
> The pt_regs_offset structure is used for HAVE_REGS_AND_STACK_ACCESS_API
> feature and has identical definitions in four different arch ptrace.h
> include files. It seems unlikely that definition would ever need to be
> changed regardless of architecture so lets move it into
> include/linux/ptrace.h.
>
> Signed-off-by: David A. Long
> ---
> arch/arm/kernel/ptrace.c | 5 -
> arch/powerpc/kernel/ptrace.c | 5 -
> arch/sh/include/asm/ptrace.h | 5 -
> arch/x86/kernel/ptrace.c | 5 -
> include/linux/ptrace.h | 9 +
> 5 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
> index ef9119f..fb45cf1 100644
> --- a/arch/arm/kernel/ptrace.c
> +++ b/arch/arm/kernel/ptrace.c
> @@ -59,11 +59,6 @@
> #define BREAKINST_THUMB0xde01
> #endif
>
> -struct pt_regs_offset {
> - const char *name;
> - int offset;
> -};
> -
> #define REG_OFFSET_NAME(r) \
> {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
> #define REG_OFFSET_END {.name = NULL, .offset = 0}
Can't you also move these? ARM is complicated with the "ARM_"
prefixing, but the others appear to be the same. Maybe you can remove
the prefix or redefine the macro for ARM.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 41/42] drivers/of: Export OF changeset functions
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> The PowerNV PCI hotplug driver is going to use the OF changeset
> to manage the changed device sub-tree, which requires those OF
> changeset functions are exported.
>
> Signed-off-by: Gavin Shan
> ---
> drivers/of/dynamic.c | 65
> ---
> drivers/of/overlay.c | 8 +++
> drivers/of/unittest.c | 4 ++--
> include/linux/of.h| 2 ++
> 4 files changed, 54 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
> index 53826b8..af65b5b 100644
> --- a/drivers/of/dynamic.c
> +++ b/drivers/of/dynamic.c
> @@ -646,6 +646,7 @@ void of_changeset_init(struct of_changeset *ocs)
> memset(ocs, 0, sizeof(*ocs));
> INIT_LIST_HEAD(&ocs->entries);
> }
> +EXPORT_SYMBOL(of_changeset_init);
We probably want these to be the _GPL variant.
>
> /**
> * of_changeset_destroy - Destroy a changeset
> @@ -662,20 +663,9 @@ void of_changeset_destroy(struct of_changeset *ocs)
> list_for_each_entry_safe_reverse(ce, cen, &ocs->entries, node)
> __of_changeset_entry_destroy(ce);
> }
> +EXPORT_SYMBOL(of_changeset_destroy);
>
> -/**
> - * of_changeset_apply - Applies a changeset
> - *
> - * @ocs: changeset pointer
> - *
> - * Applies a changeset to the live tree.
> - * Any side-effects of live tree state changes are applied here on
> - * sucess, like creation/destruction of devices and side-effects
> - * like creation of sysfs properties and directories.
> - * Returns 0 on success, a negative error value in case of an error.
> - * On error the partially applied effects are reverted.
> - */
> -int of_changeset_apply(struct of_changeset *ocs)
> +int __of_changeset_apply(struct of_changeset *ocs)
> {
> struct of_changeset_entry *ce;
> int ret;
> @@ -704,17 +694,30 @@ int of_changeset_apply(struct of_changeset *ocs)
> }
>
> /**
> - * of_changeset_revert - Reverts an applied changeset
> + * of_changeset_apply - Applies a changeset
> *
> * @ocs: changeset pointer
> *
> - * Reverts a changeset returning the state of the tree to what it
> - * was before the application.
> - * Any side-effects like creation/destruction of devices and
> - * removal of sysfs properties and directories are applied.
> + * Applies a changeset to the live tree.
> + * Any side-effects of live tree state changes are applied here on
> + * sucess, like creation/destruction of devices and side-effects
s/sucess/success/
> + * like creation of sysfs properties and directories.
> * Returns 0 on success, a negative error value in case of an error.
> + * On error the partially applied effects are reverted.
> */
> -int of_changeset_revert(struct of_changeset *ocs)
> +int of_changeset_apply(struct of_changeset *ocs)
> +{
> + int ret;
> +
> + mutex_lock(&of_mutex);
> + ret = __of_changeset_apply(ocs);
> + mutex_unlock(&of_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(of_changeset_apply);
> +
> +int __of_changeset_revert(struct of_changeset *ocs)
> {
> struct of_changeset_entry *ce;
> int ret;
> @@ -742,6 +745,29 @@ int of_changeset_revert(struct of_changeset *ocs)
> }
>
> /**
> + * of_changeset_revert - Reverts an applied changeset
> + *
> + * @ocs: changeset pointer
> + *
> + * Reverts a changeset returning the state of the tree to what it
> + * was before the application.
> + * Any side-effects like creation/destruction of devices and
> + * removal of sysfs properties and directories are applied.
> + * Returns 0 on success, a negative error value in case of an error.
> + */
> +int of_changeset_revert(struct of_changeset *ocs)
> +{
> + int ret;
> +
> + mutex_lock(&of_mutex);
> + ret = __of_changeset_revert(ocs);
> + mutex_unlock(&of_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(of_changeset_revert);
> +
> +/**
> * of_changeset_action - Perform a changeset action
> *
> * @ocs: changeset pointer
> @@ -779,3 +805,4 @@ int of_changeset_action(struct of_changeset *ocs,
> unsigned long action,
> list_add_tail(&ce->node, &ocs->entries);
> return 0;
> }
> +EXPORT_SYMBOL(of_changeset_action);
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 24e025f..804ea33 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -378,9 +378,9 @@ int of_overlay_create(struct device_node *tree)
> }
>
> /* apply the changeset */
> - err = of_changeset_apply(&ov->cset);
> + err = __of_changeset_apply(&ov->cset);
> if (err) {
> - pr_err("%s: of_changeset_apply() failed for tree@%s\n",
> + pr_err("%s: __of_changeset_apply() failed for tree@%s\n",
> __func__, tree->full_name);
> goto err_revert_overlay;
> }
> @@ -508,7 +508,7 @@ int of_overlay_destroy(int id)
>
>
> list_del(&ov->node);
> - of_changese
Re: [PATCH v6 38/42] drivers/of: Unflatten subordinate nodes after specified level
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> unflatten_dt_node() is called recursively to unflatten FDT nodes
> with the assumption that FDT blob has only one root node, which
> isn't true when the FDT blob represents device sub-tree. This
> improves the function to supporting device sub-tree that have
> multiple nodes in the first level:
>
>* Rename original unflatten_dt_node() to __unflatten_dt_node().
>* Wrapper unflatten_dt_node() calls __unflatten_dt_node() with
> adjusted current node depth to 1 to avoid underflow.
>
> Signed-off-by: Gavin Shan
Acked-by: Rob Herring
> ---
> drivers/of/fdt.c | 53 -
> 1 file changed, 40 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 0749656..a18a2ce 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -161,7 +161,7 @@ static void *unflatten_dt_alloc(void **mem, unsigned long
> size,
> }
>
> /**
> - * unflatten_dt_node - Alloc and populate a device_node from the flat tree
> + * __unflatten_dt_node - Alloc and populate a device_node from the flat tree
> * @blob: The parent device tree blob
> * @mem: Memory chunk to use for allocating device nodes and properties
> * @poffset: pointer to node in flat tree
> @@ -171,20 +171,20 @@ static void *unflatten_dt_alloc(void **mem, unsigned
> long size,
> * @dryrun: If true, do not allocate device nodes but still calculate needed
> * memory size
> */
> -static void * unflatten_dt_node(const void *blob,
> +static void *__unflatten_dt_node(const void *blob,
> void *mem,
> int *poffset,
> struct device_node *dad,
> struct device_node **nodepp,
> unsigned long fpsize,
> - bool dryrun)
> + bool dryrun,
> + int *depth)
> {
> const __be32 *p;
> struct device_node *np;
> struct property *pp, **prev_pp = NULL;
> const char *pathp;
> unsigned int l, allocl;
> - static int depth = 0;
> int old_depth;
> int offset;
> int has_name = 0;
> @@ -337,13 +337,25 @@ static void * unflatten_dt_node(const void *blob,
> np->type = "";
> }
>
> - old_depth = depth;
> - *poffset = fdt_next_node(blob, *poffset, &depth);
> - if (depth < 0)
> - depth = 0;
> - while (*poffset > 0 && depth > old_depth)
> - mem = unflatten_dt_node(blob, mem, poffset, np, NULL,
> - fpsize, dryrun);
> + /* Multiple nodes might be in the first depth level if
> +* the device tree is sub-tree. All nodes in current
> +* or deeper depth are unflattened after it returns.
> +*/
> + old_depth = *depth;
> + *poffset = fdt_next_node(blob, *poffset, depth);
> + while (*poffset > 0) {
> + if (*depth < old_depth)
> + break;
> +
> + if (*depth == old_depth)
> + mem = __unflatten_dt_node(blob, mem, poffset,
> + dad, NULL, fpsize,
> + dryrun, depth);
> + else if (*depth > old_depth)
> + mem = __unflatten_dt_node(blob, mem, poffset,
> + np, NULL, fpsize,
> + dryrun, depth);
> + }
>
> if (*poffset < 0 && *poffset != -FDT_ERR_NOTFOUND)
> pr_err("unflatten: error %d processing FDT\n", *poffset);
> @@ -369,6 +381,20 @@ static void * unflatten_dt_node(const void *blob,
> return mem;
> }
>
> +static void *unflatten_dt_node(const void *blob,
> + void *mem,
> + int *poffset,
> + struct device_node *dad,
> + struct device_node **nodepp,
> + bool dryrun)
> +{
> + int depth = 1;
> +
> + return __unflatten_dt_node(blob, mem, poffset,
> + dad, nodepp, 0,
> + dryrun, &depth);
> +}
> +
> /**
> * __unflatten_device_tree - create tree of device_nodes from flat blob
> *
> @@ -408,7 +434,8 @@ static void __unflatten_device_tree(const voi
Re: [PATCH v6 40/42] drivers/of: Return allocated memory chunk from of_fdt_unflatten_tree()
On Wed, Aug 5, 2015 at 11:11 PM, Gavin Shan wrote:
> This changes of_fdt_unflatten_tree() so that it returns the allocated
> memory chunk for unflattened device-tree, which can be released once
> it's obsoleted.
>
> Signed-off-by: Gavin Shan
Acked-by: Rob Herring
> ---
> drivers/of/fdt.c | 11 ++-
> include/linux/of_fdt.h | 2 +-
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 074870a..8e1ba7e 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -408,7 +408,7 @@ static void *unflatten_dt_node(const void *blob,
> * @dt_alloc: An allocator that provides a virtual address to memory
> * for the resulting tree
> */
> -static void __unflatten_device_tree(const void *blob,
> +static void *__unflatten_device_tree(const void *blob,
> struct device_node *dad,
> struct device_node **mynodes,
> void * (*dt_alloc)(u64 size, u64 align))
> @@ -421,7 +421,7 @@ static void __unflatten_device_tree(const void *blob,
>
> if (!blob) {
> pr_debug("No device tree pointer\n");
> - return;
> + return NULL;
> }
>
> pr_debug("Unflattening device tree:\n");
> @@ -431,7 +431,7 @@ static void __unflatten_device_tree(const void *blob,
>
> if (fdt_check_header(blob)) {
> pr_err("Invalid device tree blob header\n");
> - return;
> + return NULL;
> }
>
> /* First pass, scan for size */
> @@ -458,6 +458,7 @@ static void __unflatten_device_tree(const void *blob,
>be32_to_cpup(mem + size));
>
> pr_debug(" <- unflatten_device_tree()\n");
> + return mem;
> }
>
> static void *kernel_tree_alloc(u64 size, u64 align)
> @@ -473,11 +474,11 @@ static void *kernel_tree_alloc(u64 size, u64 align)
> * pointers of the nodes so the normal device-tree walking functions
> * can be used.
> */
> -void of_fdt_unflatten_tree(const unsigned long *blob,
> +void *of_fdt_unflatten_tree(const unsigned long *blob,
> struct device_node *dad,
> struct device_node **mynodes)
> {
> - __unflatten_device_tree(blob, dad, mynodes, &kernel_tree_alloc);
> + return __unflatten_device_tree(blob, dad, mynodes,
> &kernel_tree_alloc);
> }
> EXPORT_SYMBOL_GPL(of_fdt_unflatten_tree);
>
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index 3644960..00db279 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -37,7 +37,7 @@ extern bool of_fdt_is_big_endian(const void *blob,
> unsigned long node);
> extern int of_fdt_match(const void *blob, unsigned long node,
> const char *const *compat);
> -extern void of_fdt_unflatten_tree(const unsigned long *blob,
> +extern void *of_fdt_unflatten_tree(const unsigned long *blob,
>struct device_node *dad,
>struct device_node **mynodes);
>
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] of/pci: Add of_pci_check_probe_only to parse "linux, pci-probe-only"
On Fri, Aug 14, 2015 at 11:19 AM, Marc Zyngier wrote:
> Both pci-host-generic and Pseries parse the "linux,pci-probe-only"
> to engage the PCI_PROBE_ONLY mode, and both have a subtle bug that
> can be triggered if the property has no parameter.
Humm, I bet we could break a lot of machines if we fixed the core code
to properly make pp->value NULL when there is no value.
> Provide a generic implementation that can be used by both.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/of/of_pci.c| 30 ++
> include/linux/of_pci.h | 3 +++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 5751dc5..a4e29ff 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -118,6 +118,36 @@ int of_get_pci_domain_nr(struct device_node *node)
> EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
>
> /**
> + * of_pci_check_probe_only - Setup probe only mode if linux,pci-probe-only
> + * is present and valid
> + *
> + * @node: device tree node that may contain the property (usually "chosen")
> + *
> + */
> +void of_pci_check_probe_only(struct device_node *node)
> +{
> + const int *prop;
> + int len;
> +
> + if (!node)
> + return;
> +
> + prop = of_get_property(node, "linux,pci-probe-only", &len);
It is preferred to use of_property_read_u32 to avoid just these types
of problems.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [GIT PULL] DT/core: cpu_ofnode updates for v3.12
On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha wrote: > Adding PowerPC list > > On 13/08/13 14:00, Rafael J. Wysocki wrote: >> On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote: >>> The following changes since commit >>> d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: >>> >>> Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) >>> >>> are available in the git repository at: >>> >>> git://linux-arm.org/linux-skn.git cpu_of_node [snip] >> All error/warnings: >> >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >> warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM) >> selects FSL_LBC which has unmet direct dependencies (FSL_SOC) >> In file included from arch/powerpc/include/asm/kvm_para.h:26:0, from >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >> from include/linux/kvm_host.h:30, from >> arch/powerpc/kernel/asm-offsets.c:53: >> include/linux/of.h:269:28: error: conflicting types for >>'of_get_cpu_node' >> extern struct device_node *of_get_cpu_node(int cpu); ^ In file >> included from include/linux/of.h:139:0, from >> arch/powerpc/include/asm/kvm_para.h:26, from >> include/uapi/linux/kvm_para.h:26, from include/linux/kvm_para.h:4, >> from include/linux/kvm_host.h:30, from >> arch/powerpc/kernel/asm-offsets.c:53: >> arch/powerpc/include/asm/prom.h:47:21: note: previous declaration >> of 'of_get_cpu_node' was here >> struct device_node *of_get_cpu_node(int cpu, unsigned int *thread); >> ^ make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: >> Target `__build' not remade because of errors. make[1]: *** >> [prepare0] Error 2 make[1]: Target `prepare' not remade because of >> errors. make: *** [sub-make] Error 2 >> > > There seems to be conflict in the new function "of_get_cpu_node" added. > PowerPC also defines the same function name. Further microblaze and > openrisc declares it(can be removed) but doesn't define it. > To fix this: > 1. I can rename the newly added function to something different like >`of_get_cpunode` or > 2. If of_* namespace should be used by only OF/FDT and not by any >architecture specific code, then the arch specific version can be >renamed to some thing like arch_of_get_cpu_node. >Also most of the calls to arch specific function can be moved to >generic code. > > Let me know your thoughts. It is up to Rafael if he is willing/able to rebase his tree, but I would drop this series until this is sorted out. I think the new common function should be and can be generalized to work for powerpc. It would need to make reg property optional and pass in the device node to the arch specific function. A short term solution would be just to make the function "#ifndef CONFIG_PPC". Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [GIT PULL] DT/core: cpu_ofnode updates for v3.12
On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote:
> On 13/08/13 22:07, Benjamin Herrenschmidt wrote:
>> On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
>>> I don't understand completely the use of ibm,ppc-interrupt-server#s and
>>> its implications on generic of_get_cpu_node implementation.
>>> I see the PPC specific definition of of_get_cpu_node uses thread id only
>>> in 2 instances. Based on that, I have tried to move all the other
>>> instances to use generic definition.
>>>
>>> Let me know if the idea is correct.
>>
>> No. The device-tree historically only represents cores, not HW threads, so
>> it makes sense to retrieve also the thread number corresponding to the CPU.
>>
> Ok
>
>> However, the mechanism to represent HW threads in the device-tree is
>> currently
>> somewhat platform specific (the ibm,ppc-interrupt-server#s).
> I see most of the callers pass NULL to thread id argument except 2
> instances in entire tree. If that's the case why can't we move to use
> generic of_get_cpu_node in most of those cases and have PPC specific
> implementation for the ones using thread id.
>
>>
>> So what you could do for now is:
>>
>> - Have a generic version that always returns 0 as the thread, which is weak
> I would prefer to move to generic of_get_cpu_node where ever possible
> and rename the function that takes thread id rather than making generic
> one weak.
>
>>
>> - powerpc keeps its own implementation
> How about only in cases where it needs thread_id.
>
>>
>> - Start a discussion on the bindings (if not already there) to define
>> threads
>> in a better way at which point the generic function can be updated.
>>
> I am not sure if we need to define any new bindings. Excerpts from ePAPR
> (v1.1):
> "3.7.1 General Properties of CPU nodes
> The value of "reg" is a that defines a unique
> CPU/thread id for the CPU/threads represented by the CPU node.
> If a CPU supports more than one thread (i.e. multiple streams of
> execution) the reg property is an array with 1 element per thread. The
> #address-cells on the /cpus node specifies how many cells each element
> of the array takes. Software can determine the number of threads by
> dividing the size of reg by the parent node's #address-cells."
>
> And this is exactly in agreement to what's implemented in the generic
> of_get_cpu_node:
>
> for_each_child_of_node(cpus, cpun) {
> if (of_node_cmp(cpun->type, "cpu"))
> continue;
> cell = of_get_property(cpun, "reg", &prop_len);
> if (!cell) {
> pr_warn("%s: missing reg property\n", cpun->full_name);
> continue;
> }
> prop_len /= sizeof(*cell);
> while (prop_len) {
> hwid = of_read_number(cell, ac);
> prop_len -= ac;
> if (arch_match_cpu_phys_id(cpu, hwid))
> return cpun;
> }
> }
How about something like this:
for_each_child_of_node(cpus, cpun) {
if (of_node_cmp(cpun->type, "cpu"))
continue;
if (arch_of_get_cpu_node(cpun, thread))
return cpun;
cell = of_get_property(cpun, "reg", &prop_len);
if (!cell) {
pr_warn("%s: missing reg property\n", cpun->full_name);
continue;
}
prop_len /= sizeof(*cell);
while (prop_len) {
hwid = of_read_number(cell, ac);
prop_len -= ac;
if (arch_match_cpu_phys_id(cpu, hwid))
return cpun;
}
}
For PPC:
arch_of_get_cpu_node()
{
const u32 *intserv;
unsigned int plen, t;
/* Check for ibm,ppc-interrupt-server#s. */
intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
&plen);
if (!intserv)
return false;
hardid = get_hard_smp_processor_id(cpu);
plen /= sizeof(u32);
for (t = 0; t < plen; t++) {
if (hardid == intserv[t]) {
if (thread)
*thread = t;
return true;
}
}
return false;
}
>
> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", for
> which we can have PPC specific wrapper above the generic one i.e. get
> the cpu node and then parse for thread id under custom property.
>
> Let me know your thoughts.
>
> Regards,
> Sudeep
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 3/4] powerpc: refactor of_get_cpu_node to support other architectures
On 08/19/2013 05:19 AM, Mark Rutland wrote:
> On Sat, Aug 17, 2013 at 11:09:36PM +0100, Benjamin Herrenschmidt wrote:
>> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
>>> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
>>> which
>>> the updated bindings[1] define #address-cells = <0> and so no reg
>>> property.
>>>
>>> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
>>
>> Why did you do that in the binding ? That sounds like looking to create
>> problems ...
>>
>> Traditionally, UP setups just used "0" as the "reg" property on other
>> architectures, why do differently ?
>
> The decision was taken because we defined our reg property to refer to
> the MPIDR register's Aff{2,1,0} bitfields, and on UP cores before v7
> there's no MPIDR register at all. Given there can only be a single CPU
> in that case, describing a register that wasn't present didn't seem
> necessary or helpful.
What exactly reg represents is up to the binding definition, but it
still should be present IMO. I don't see any issue with it being
different for pre-v7.
Rob
>
> Thanks,
> Mark.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 4/4] of: move of_get_cpu_node implementation to DT core library
On 08/16/2013 12:39 PM, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> This patch moves the generalized implementation of of_get_cpu_node from
> PowerPC to DT core library, thereby adding support for retrieving cpu
> node for a given logical cpu index on any architecture.
>
> The CPU subsystem can now use this function to assign of_node in the
> cpu device while registering CPUs.
>
> It is recommended to use these helper function only in pre-SMP/early
> initialisation stages to retrieve CPU device node pointers in logical
> ordering. Once the cpu devices are registered, it can be retrieved easily
> from cpu device of_node which avoids unnecessary parsing and matching.
>
> Cc: Rob Herring
> Cc: Grant Likely
> Cc: Benjamin Herrenschmidt
> Signed-off-by: Sudeep KarkadaNagesha
[snip]
> +/**
> + * of_get_cpu_node - Get device node associated with the given logical CPU
> + *
> + * @cpu: CPU number(logical index) for which device node is required
> + * @thread: if not NULL, local thread number within the physical core is
> + * returned
> + *
> + * The main purpose of this function is to retrieve the device node for the
> + * given logical CPU index. It should be used to initialize the of_node in
> + * cpu device. Once of_node in cpu device is populated, all the further
> + * references can use that instead.
> + *
> + * CPU logical to physical index mapping is architecture specific and is
> built
> + * before booting secondary cores. This function uses arch_match_cpu_phys_id
> + * which can be overridden by architecture specific implementation.
> + *
> + * Returns a node pointer for the logical cpu if found, else NULL.
> + */
> +struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
> +{
> + struct device_node *cpun, *cpus;
> +
> + cpus = of_find_node_by_path("/cpus");
> + if (!cpus) {
> + pr_warn("Missing cpus node, bailing out\n");
> + return NULL;
> + }
> +
> + for_each_child_of_node(cpus, cpun) {
> + if (of_node_cmp(cpun->type, "cpu"))
> + continue;
> +#ifdef CONFIG_PPC
You don't really need this ifdef as this function should never succeed
on other arches. Alternatively, you can use "IS_ENABLED(CONFIG_PPC)"
instead.
Otherwise,
Acked-by: Rob Herring
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND] i2c: move of helpers into the core
On 08/19/2013 12:59 PM, Wolfram Sang wrote: > I2C of helpers used to live in of_i2c.c but experience (from SPI) shows > that it is much cleaner to have this in the core. This also removes a > circular dependency between the helpers and the core, and so we can > finally register child nodes in the core instead of doing this manually > in each driver. So, fix the drivers and documentation, too. > > Signed-off-by: Wolfram Sang > --- Glad to see this. Acked-by: Rob Herring > > Sigh, hitting the CC threshold on vger again. So resending to the lists only. > BTW this patch is based on -rc4 and was tested on an AT91 board. More tests > very welcome. Thanks! > > > Documentation/acpi/enumeration.txt |1 - > drivers/i2c/busses/i2c-at91.c |3 - > drivers/i2c/busses/i2c-cpm.c|6 -- > drivers/i2c/busses/i2c-davinci.c|2 - > drivers/i2c/busses/i2c-designware-platdrv.c |2 - > drivers/i2c/busses/i2c-gpio.c |3 - > drivers/i2c/busses/i2c-i801.c |2 - > drivers/i2c/busses/i2c-ibm_iic.c|4 - > drivers/i2c/busses/i2c-imx.c|3 - > drivers/i2c/busses/i2c-mpc.c|2 - > drivers/i2c/busses/i2c-mv64xxx.c|3 - > drivers/i2c/busses/i2c-mxs.c|3 - > drivers/i2c/busses/i2c-nomadik.c|3 - > drivers/i2c/busses/i2c-ocores.c |3 - > drivers/i2c/busses/i2c-octeon.c |3 - > drivers/i2c/busses/i2c-omap.c |3 - > drivers/i2c/busses/i2c-pnx.c|3 - > drivers/i2c/busses/i2c-powermac.c |9 +- > drivers/i2c/busses/i2c-pxa.c|2 - > drivers/i2c/busses/i2c-s3c2410.c|2 - > drivers/i2c/busses/i2c-sh_mobile.c |2 - > drivers/i2c/busses/i2c-sirf.c |3 - > drivers/i2c/busses/i2c-stu300.c |2 - > drivers/i2c/busses/i2c-tegra.c |3 - > drivers/i2c/busses/i2c-versatile.c |2 - > drivers/i2c/busses/i2c-wmt.c|3 - > drivers/i2c/busses/i2c-xiic.c |3 - > drivers/i2c/i2c-core.c | 107 - > drivers/i2c/i2c-mux.c |3 - > drivers/i2c/muxes/i2c-arb-gpio-challenge.c |1 - > drivers/i2c/muxes/i2c-mux-gpio.c|1 - > drivers/i2c/muxes/i2c-mux-pinctrl.c |1 - > drivers/media/platform/exynos4-is/fimc-is-i2c.c |3 - > drivers/of/Kconfig |6 -- > drivers/of/Makefile |1 - > drivers/of/of_i2c.c | 114 > --- > include/linux/i2c.h | 20 > include/linux/of_i2c.h | 46 - > 38 files changed, 130 insertions(+), 253 deletions(-) > delete mode 100644 drivers/of/of_i2c.c > delete mode 100644 include/linux/of_i2c.h > > diff --git a/Documentation/acpi/enumeration.txt > b/Documentation/acpi/enumeration.txt > index d9be7a9..958266e 100644 > --- a/Documentation/acpi/enumeration.txt > +++ b/Documentation/acpi/enumeration.txt > @@ -238,7 +238,6 @@ An I2C bus (controller) driver does: > if (ret) > /* handle error */ > > - of_i2c_register_devices(adapter); > /* Enumerate the slave devices behind this bus via ACPI */ > acpi_i2c_register_devices(adapter); > > diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c > index 6bb839b..fd05930 100644 > --- a/drivers/i2c/busses/i2c-at91.c > +++ b/drivers/i2c/busses/i2c-at91.c > @@ -28,7 +28,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -775,8 +774,6 @@ static int at91_twi_probe(struct platform_device *pdev) > return rc; > } > > - of_i2c_register_devices(&dev->adapter); > - > dev_info(dev->dev, "AT91 i2c bus driver.\n"); > return 0; > } > diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c > index 2e1f7eb..b2b8aa9 100644 > --- a/drivers/i2c/busses/i2c-cpm.c > +++ b/drivers/i2c/busses/i2c-cpm.c > @@ -42,7 +42,6 @@ > #include > #include > #include > -#include > #include > #include > > @@ -681,11 +680,6 @@ static int cpm_i2c_probe(struct platform_device *ofdev) > dev_dbg(&ofdev->dev, "hw routines for %s registered.\n", > cpm->adap.
Re: [PATCH v2 07/10] of/irq: Propagate errors in of_irq_to_resource_table()
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> Now that all helpers return precise error codes, this function can
> propagate these errors to the caller properly.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - return 0 on success or a negative error code on failure
> - convert callers to new calling convention
[snip]
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index e4f38c0..6d7f824 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -397,18 +397,20 @@ int of_irq_count(struct device_node *dev)
> * @res: array of resources to fill in
> * @nr_irqs: the number of IRQs (and upper bound for num of @res elements)
You are effectively changing this to require an exact match rather
than an upper bound. That seems to be okay since that is what all the
callers want, but the documentation should be updated.
> *
> - * Returns the size of the filled in table (up to @nr_irqs).
> + * Returns 0 on success or a negative error code on failure.
> */
> int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
> int nr_irqs)
> {
> - int i;
> + int i, ret;
>
> - for (i = 0; i < nr_irqs; i++, res++)
> - if (!of_irq_to_resource(dev, i, res))
The error handling here needs to be updated in the previous patch.
> - break;
> + for (i = 0; i < nr_irqs; i++, res++) {
> + ret = of_irq_to_resource(dev, i, res);
> + if (ret < 0)
> + return ret;
> + }
>
> - return i;
> + return 0;
> }
> EXPORT_SYMBOL_GPL(of_irq_to_resource_table);
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 04/10] irqdomain: Return errors from irq_create_of_mapping()
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> Instead of returning 0 for all errors, allow the precise error code to
> be propagated. This will be used in subsequent patches to allow further
> propagation of error codes.
>
> The interrupt number corresponding to the new mapping is returned in an
> output parameter so that the return value is reserved to signal success
> (== 0) or failure (< 0).
>
> Signed-off-by: Thierry Reding
One comment below, otherwise:
Acked-by: Rob Herring
> diff --git a/arch/powerpc/kernel/pci-common.c
> b/arch/powerpc/kernel/pci-common.c
> index 905a24b..ae71b14 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -230,6 +230,7 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
> {
> struct of_irq oirq;
> unsigned int virq;
> + int ret;
>
> pr_debug("PCI: Try to map irq for %s...\n", pci_name(pci_dev));
>
> @@ -266,8 +267,10 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
> oirq.size, oirq.specifier[0], oirq.specifier[1],
> of_node_full_name(oirq.controller));
>
> - virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
> -oirq.size);
> + ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
> + oirq.size, &virq);
> + if (ret)
> + virq = NO_IRQ;
> }
> if(virq == NO_IRQ) {
> pr_debug(" Failed to map !\n");
Can you get rid of NO_IRQ usage here instead of adding to it.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 02/10] of/irq: Use irq_of_parse_and_map()
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> Replace some instances of of_irq_map_one()/irq_create_of_mapping() and
> of_irq_to_resource() by the simpler equivalent irq_of_parse_and_map().
>
> Signed-off-by: Thierry Reding
Acked-by: Rob Herring
> ---
> arch/arm/mach-u300/timer.c | 9 -
> arch/powerpc/platforms/cell/celleb_scc_pciex.c | 8 +++-
> arch/powerpc/platforms/cell/spider-pic.c | 7 ++-
> arch/powerpc/sysdev/fsl_gtm.c| 9 -
> arch/powerpc/sysdev/mpic_msgr.c | 6 ++
> drivers/crypto/caam/ctrl.c | 2 +-
> drivers/crypto/caam/jr.c | 2 +-
> drivers/crypto/omap-sham.c | 2 +-
> drivers/i2c/busses/i2c-cpm.c | 2 +-
> drivers/input/serio/xilinx_ps2.c | 7 ---
> drivers/net/ethernet/arc/emac_main.c | 10 +-
> drivers/net/ethernet/freescale/fs_enet/mac-fcc.c | 2 +-
> drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 2 +-
> drivers/net/ethernet/freescale/fs_enet/mac-scc.c | 2 +-
> drivers/spi/spi-fsl-espi.c | 6 +++---
> drivers/tty/serial/cpm_uart/cpm_uart_core.c | 2 +-
> 16 files changed, 35 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
> index b5db207..9a5f9fb 100644
> --- a/arch/arm/mach-u300/timer.c
> +++ b/arch/arm/mach-u300/timer.c
> @@ -358,8 +358,7 @@ static struct delay_timer u300_delay_timer;
> */
> static void __init u300_timer_init_of(struct device_node *np)
> {
> - struct resource irq_res;
> - int irq;
> + unsigned int irq;
> struct clk *clk;
> unsigned long rate;
>
> @@ -368,11 +367,11 @@ static void __init u300_timer_init_of(struct
> device_node *np)
> panic("could not ioremap system timer\n");
>
> /* Get the IRQ for the GP1 timer */
> - irq = of_irq_to_resource(np, 2, &irq_res);
> - if (irq <= 0)
> + irq = irq_of_parse_and_map(np, 2);
> + if (!irq)
> panic("no IRQ for system timer\n");
>
> - pr_info("U300 GP1 timer @ base: %p, IRQ: %d\n", u300_timer_base, irq);
> + pr_info("U300 GP1 timer @ base: %p, IRQ: %u\n", u300_timer_base, irq);
>
> /* Clock the interrupt controller */
> clk = of_clk_get(np, 0);
> diff --git a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
> b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
> index 14be2bd..856ad64 100644
> --- a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
> +++ b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
> @@ -486,8 +486,7 @@ static __init int celleb_setup_pciex(struct device_node
> *node,
> struct pci_controller *phb)
> {
> struct resource r;
> - struct of_irq oirq;
> - int virq;
> + unsigned int virq;
>
> /* SMMIO registers; used inside this file */
> if (of_address_to_resource(node, 0, &r)) {
> @@ -507,12 +506,11 @@ static __init int celleb_setup_pciex(struct device_node
> *node,
> phb->ops = &scc_pciex_pci_ops;
>
> /* internal interrupt handler */
> - if (of_irq_map_one(node, 1, &oirq)) {
> + virq = irq_of_parse_and_map(node, 1);
> + if (!virq) {
> pr_err("PCIEXC:Failed to map irq\n");
> goto error;
> }
> - virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
> -oirq.size);
> if (request_irq(virq, pciex_handle_internal_irq,
> 0, "pciex", (void *)phb)) {
> pr_err("PCIEXC:Failed to request irq\n");
> diff --git a/arch/powerpc/platforms/cell/spider-pic.c
> b/arch/powerpc/platforms/cell/spider-pic.c
> index 8e29944..1f72f4a 100644
> --- a/arch/powerpc/platforms/cell/spider-pic.c
> +++ b/arch/powerpc/platforms/cell/spider-pic.c
> @@ -235,12 +235,9 @@ static unsigned int __init
> spider_find_cascade_and_node(struct spider_pic *pic)
> /* First, we check whether we have a real "interrupts" in the device
> * tree in case the device-tree is ever fixed
> */
> - struct of_irq oirq;
> - if (of_irq_map_one(pic->host->of_node, 0, &oirq) == 0) {
> - virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
> -oirq.size);
> + virq = irq_of_parse_and_map(pic->host->of_node, 0);
> + if (virq)
>
Re: [PATCH v2 01/10] of/irq: Rework of_irq_count()
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> The of_irq_to_resource() helper that is used to implement of_irq_count()
> tries to resolve interrupts and in fact creates a mapping for resolved
> interrupts. That's pretty heavy lifting for something that claims to
> just return the number of interrupts requested by a given device node.
>
> Instead, use the more lightweight of_irq_map_one(), which, despite the
> name, doesn't create an actual mapping. Perhaps a better name would be
> of_irq_translate_one().
>
> Signed-off-by: Thierry Reding
Acked-by: Rob Herring
> ---
> drivers/of/irq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 1752988..5f44388 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -368,9 +368,10 @@ EXPORT_SYMBOL_GPL(of_irq_to_resource);
> */
> int of_irq_count(struct device_node *dev)
> {
> + struct of_irq irq;
> int nr = 0;
>
> - while (of_irq_to_resource(dev, nr, NULL))
> + while (of_irq_map_one(dev, nr, &irq) == 0)
> nr++;
>
> return nr;
> --
> 1.8.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 17/21] of: move of_translate_dma_address to of_address.h
From: Rob Herring of_translate_dma_address is implemented in common code, so move the declaration there too. Signed-off-by: Rob Herring Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Grant Likely Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/include/asm/prom.h | 4 include/linux/of_address.h | 4 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h index 43fe002..b8774bd 100644 --- a/arch/powerpc/include/asm/prom.h +++ b/arch/powerpc/include/asm/prom.h @@ -24,10 +24,6 @@ * OF address retreival & translation */ -/* Translate a DMA address from device space to CPU space */ -extern u64 of_translate_dma_address(struct device_node *dev, - const __be32 *in_addr); - /* Parse the ibm,dma-window property of an OF node into the busno, phys and * size parameters. */ diff --git a/include/linux/of_address.h b/include/linux/of_address.h index e8a1797..5f6ed6b 100644 --- a/include/linux/of_address.h +++ b/include/linux/of_address.h @@ -34,6 +34,10 @@ static inline void of_pci_range_to_resource(struct of_pci_range *range, res->name = np->full_name; } +/* Translate a DMA address from device space to CPU space */ +extern u64 of_translate_dma_address(struct device_node *dev, + const __be32 *in_addr); + #ifdef CONFIG_OF_ADDRESS extern u64 of_translate_address(struct device_node *np, const __be32 *addr); extern bool of_can_translate_address(struct device_node *dev); -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 19/21] powerpc: add explicit OF includes
From: Rob Herring When removing prom.h include by of.h, several OF headers will no longer be implicitly included. Add explicit includes of of_*.h as needed. Signed-off-by: Rob Herring Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Anatolij Gustschin Cc: Kumar Gala Cc: Olof Johansson Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/epapr_paravirt.c | 1 + arch/powerpc/platforms/512x/clock.c | 1 + arch/powerpc/platforms/512x/pdm360ng.c | 2 ++ arch/powerpc/platforms/82xx/mpc8272_ads.c| 2 ++ arch/powerpc/platforms/82xx/pq2fads.c| 2 ++ arch/powerpc/platforms/83xx/suspend.c| 2 ++ arch/powerpc/platforms/86xx/pic.c| 1 + arch/powerpc/platforms/embedded6xx/flipper-pic.c | 1 + arch/powerpc/platforms/embedded6xx/hlwd-pic.c| 2 ++ arch/powerpc/platforms/pasemi/gpio_mdio.c| 1 + arch/powerpc/platforms/powermac/pfunc_base.c | 1 + arch/powerpc/platforms/powernv/opal-lpc.c| 1 + arch/powerpc/platforms/powernv/opal.c| 1 + arch/powerpc/platforms/powernv/setup.c | 1 + arch/powerpc/platforms/pseries/hotplug-memory.c | 2 ++ arch/powerpc/sysdev/cpm_common.c | 1 + arch/powerpc/sysdev/fsl_gtm.c| 2 ++ arch/powerpc/sysdev/fsl_pmc.c| 1 + arch/powerpc/sysdev/mpic.c | 8 arch/powerpc/sysdev/mpic_timer.c | 2 ++ 20 files changed, 31 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/epapr_paravirt.c b/arch/powerpc/kernel/epapr_paravirt.c index 6300c13..7898be9 100644 --- a/arch/powerpc/kernel/epapr_paravirt.c +++ b/arch/powerpc/kernel/epapr_paravirt.c @@ -18,6 +18,7 @@ */ #include +#include #include #include #include diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c index e504166..fd8a376 100644 --- a/arch/powerpc/platforms/512x/clock.c +++ b/arch/powerpc/platforms/512x/clock.c @@ -24,6 +24,7 @@ #include #include +#include #include #include #include diff --git a/arch/powerpc/platforms/512x/pdm360ng.c b/arch/powerpc/platforms/512x/pdm360ng.c index 24b314d..116f2325 100644 --- a/arch/powerpc/platforms/512x/pdm360ng.c +++ b/arch/powerpc/platforms/512x/pdm360ng.c @@ -14,6 +14,8 @@ #include #include +#include +#include #include #include diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c b/arch/powerpc/platforms/82xx/mpc8272_ads.c index 30394b4..6a14cf5 100644 --- a/arch/powerpc/platforms/82xx/mpc8272_ads.c +++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c @@ -16,6 +16,8 @@ #include #include #include +#include +#include #include #include diff --git a/arch/powerpc/platforms/82xx/pq2fads.c b/arch/powerpc/platforms/82xx/pq2fads.c index e1dceee..e5f82ec 100644 --- a/arch/powerpc/platforms/82xx/pq2fads.c +++ b/arch/powerpc/platforms/82xx/pq2fads.c @@ -15,6 +15,8 @@ #include #include #include +#include +#include #include #include diff --git a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c index 1d769a2..3d9716c 100644 --- a/arch/powerpc/platforms/83xx/suspend.c +++ b/arch/powerpc/platforms/83xx/suspend.c @@ -20,6 +20,8 @@ #include #include #include +#include +#include #include #include diff --git a/arch/powerpc/platforms/86xx/pic.c b/arch/powerpc/platforms/86xx/pic.c index 9982f57..d5b98c0 100644 --- a/arch/powerpc/platforms/86xx/pic.c +++ b/arch/powerpc/platforms/86xx/pic.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include diff --git a/arch/powerpc/platforms/embedded6xx/flipper-pic.c b/arch/powerpc/platforms/embedded6xx/flipper-pic.c index 53d6eee0..4cde8e7 100644 --- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c +++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include "flipper-pic.h" diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c index 3006b51..7cab21d 100644 --- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c +++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c @@ -18,6 +18,8 @@ #include #include #include +#include +#include #include #include "hlwd-pic.h" diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c index 0237ab7..15adee5 100644 --- a/arch/powerpc/platforms/pasemi/gpio_mdio.c +++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include diff --git a/arch/powerpc/platforms/powermac/pfunc_base.c b/arch/powerpc/platforms/powermac/pfunc_base.c index f5e3cda..e49d07f 100644 --- a/arch/powerpc/platforms/powermac/pfunc_base.c +++ b/arch/powerpc/platforms/powermac/pfunc_base.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include diff --git a/ar
Re: linux-next: build failure after merge of the dt-rh tree
On 10/28/2013 03:38 AM, Stephen Rothwell wrote:
> Hi Rob,
>
> After merging the dt-rh tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/powernv/rng.c: In function
> 'rng_init_per_cpu': arch/powerpc/platforms/powernv/rng.c:64:2:
> error: implicit declaration of function 'of_get_ibm_chip_id'
> [-Werror=implicit-function-declaration] chip_id =
> of_get_ibm_chip_id(dn); ^ arch/powerpc/platforms/powernv/rng.c: In
> function 'rng_create': arch/powerpc/platforms/powernv/rng.c:85:2:
> error: implicit declaration of function 'of_iomap'
> [-Werror=implicit-function-declaration] rng->regs= of_iomap(dn, 0);
> ^
> arch/powerpc/platforms/powernv/rng.c:85:12: error: assignment makes pointer
> from integer without a cast [-Werror]
> rng->regs = of_iomap(dn, 0);
> ^
>
> Caused by commit a4da0d50b2a0 ("powerpc: Implement
> arch_get_random_long/int() for powernv") from the powerpc tree
> interacting with commit b5b4bb3f6a11 ("of: only include prom.h on sparc")
> from the dt-rh tree.
>
> I added this merge fix patch (which will need to be sent to Linus when
> these two trees get merged, or could be applied now to the powerpc tree):
Applying to the powerpc tree now seems like the better path.
> From: Stephen Rothwell
> Date: Mon, 28 Oct 2013 19:34:41 +1100
> Subject: [PATCH] powerpc: add include of prom.h to fix powernv/rng.c build
>
> Signed-off-by: Stephen Rothwell
Acked-by: Rob Herring
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the dt-rh tree with the powerpc tree
On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> Hi Rob,
>
> Today's linux-next merge of the dt-rh tree got a conflict in
> arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> Move definition of of_find_next_cache_node into common code") from
> the powerpc tree and commit 0c3f061c195c ("of: implement
> of_node_to_nid as a weak function") from the dt-rh tree.
Ben, I can pick these 2 patches up instead if you want to drop them
and avoid the conflict.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: add explicit OF includes for ppc4xx
From: Rob Herring Commit b5b4bb3f6a11f9 (of: only include prom.h on sparc) removed implicit includes of of_*.h headers by powerpc's prom.h. Some PPC4xx components were missed in initial clean-up patch, so add the necessary includes to fix ppc4xx builds. Signed-off-by: Rob Herring Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Tejun Heo Cc: Matt Mackall Cc: Herbert Xu Cc: "David S. Miller" Cc: Vinod Koul Cc: Dan Williams Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org --- I intend to send this patch to Linus with the rest of the DT clean-up series. Rob arch/powerpc/sysdev/ppc4xx_ocm.c | 1 + arch/powerpc/sysdev/xilinx_intc.c| 1 + drivers/ata/sata_dwc_460ex.c | 2 ++ drivers/char/hw_random/ppc4xx-rng.c | 1 + drivers/crypto/amcc/crypto4xx_core.c | 3 +++ drivers/dma/ppc4xx/adma.c| 2 ++ 6 files changed, 10 insertions(+) diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c b/arch/powerpc/sysdev/ppc4xx_ocm.c index 1b15f93..b7c4345 100644 --- a/arch/powerpc/sysdev/ppc4xx_ocm.c +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index f4fdc94..83f943a 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c index 2e39173..523524b 100644 --- a/drivers/ata/sata_dwc_460ex.c +++ b/drivers/ata/sata_dwc_460ex.c @@ -31,6 +31,8 @@ #include #include #include +#include +#include #include #include #include diff --git a/drivers/char/hw_random/ppc4xx-rng.c b/drivers/char/hw_random/ppc4xx-rng.c index 732c330..521f76b 100644 --- a/drivers/char/hw_random/ppc4xx-rng.c +++ b/drivers/char/hw_random/ppc4xx-rng.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c index f88e3d8..efaf630 100644 --- a/drivers/crypto/amcc/crypto4xx_core.c +++ b/drivers/crypto/amcc/crypto4xx_core.c @@ -27,6 +27,9 @@ #include #include #include +#include +#include +#include #include #include #include diff --git a/drivers/dma/ppc4xx/adma.c b/drivers/dma/ppc4xx/adma.c index 370ff82..e24b5ef 100644 --- a/drivers/dma/ppc4xx/adma.c +++ b/drivers/dma/ppc4xx/adma.c @@ -42,6 +42,8 @@ #include #include #include +#include +#include #include #include #include -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci and pcie device-tree binding - range No cells
On 12/10/2012 06:20 AM, Michal Simek wrote: > Hi Grant and others, > > I have a question regarding number of cells in ranges property > for pci and pcie nodes. > > Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts, > sequoia.dts, etc) > but also 6 cells format too (mpc832x_mds.dts) > > Here is shown 6 cells ranges format and describe > http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge > > And also in documentation in the linux > Documentation/devicetree/bindings/pci/83xx-512x-pci.txt > > Both format uses: > #size-cells = <2>; > #address-cells = <3>; > > What is valid format? Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells are valid when the host bus is 32-bit. The ranges property is < >. The parent address #address-cells is taken from the parent node. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci and pcie device-tree binding - range No cells
On 12/10/2012 09:05 AM, Michal Simek wrote:
> On 12/10/2012 03:26 PM, Rob Herring wrote:
>> On 12/10/2012 06:20 AM, Michal Simek wrote:
>>> Hi Grant and others,
>>>
>>> I have a question regarding number of cells in ranges property
>>> for pci and pcie nodes.
>>>
>>> Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
>>> sequoia.dts, etc)
>>> but also 6 cells format too (mpc832x_mds.dts)
>>>
>>> Here is shown 6 cells ranges format and describe
>>> http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>
>>> And also in documentation in the linux
>>> Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
>>>
>>> Both format uses:
>>> #size-cells = <2>;
>>> #address-cells = <3>;
>>>
>>> What is valid format?
>>
>> Both. 7 cells are valid when the host (parent) bus is 64-bit and 6 cells
>> are valid when the host bus is 32-bit. The ranges property is <> address> >. The parent address #address-cells is
>> taken from the parent node.
>
> Ok. Got it.
>
> Here is what we use on zynq and microblaze - both 32bit which should be
> fine.
>
> ps7_axi_interconnect_0: axi@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> axi_pcie_0: axi-pcie@5000 {
> #address-cells = <3>;
> #size-cells = <2>;
> compatible = "xlnx,axi-pcie-1.05.a";
> ranges = < 0x0200 0 0x6000 0x6000 0 0x1000 >;
> ...
> }
> }
>
> What I am wondering is pci_process_bridge_OF_ranges() at
> arch/powerpc/kernel/pci-common.c
> where there are used some hardcoded values which should be probably
> loaded from device-tree.
>
> For example:
> 683 int np = pna + 5;
> ...
> 702 pci_addr = of_read_number(ranges + 1, 2);
> 703 cpu_addr = of_translate_address(dev, ranges + 3);
> 704 size = of_read_number(ranges + pna + 3, 2);
These would always be correct whether you have 6 or 7 cells. pna is the
parent bus address cells size. The pci address is fixed at 3 cells.
>
>
> Unfortunately we have copied it to microblaze.
I look at the PCI DT code in powerpc and see a whole bunch of code that
seems like it should be common. The different per arch pci structs
complicates that. No one has really gotten to looking at PCI DT on ARM
yet except you and Thierry for Tegra. We definitely don't want to create
a 3rd copy. Starting the process of moving it to something like
drivers/pci/pci-of.c would be great.
Rob
>
> Thanks,
> Michal
>
>
>
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci and pcie device-tree binding - range No cells
On 12/10/2012 09:37 AM, Michal Simek wrote:
> On 12/10/2012 04:21 PM, Rob Herring wrote:
>> On 12/10/2012 09:05 AM, Michal Simek wrote:
>>> On 12/10/2012 03:26 PM, Rob Herring wrote:
>>>> On 12/10/2012 06:20 AM, Michal Simek wrote:
>>>>> Hi Grant and others,
>>>>>
>>>>> I have a question regarding number of cells in ranges property
>>>>> for pci and pcie nodes.
>>>>>
>>>>> Linux pci/pcie powerpc DTSes contain 7 cells (xpedite5370.dts,
>>>>> sequoia.dts, etc)
>>>>> but also 6 cells format too (mpc832x_mds.dts)
>>>>>
>>>>> Here is shown 6 cells ranges format and describe
>>>>> http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge
>>>>>
>>>>> And also in documentation in the linux
>>>>> Documentation/devicetree/bindings/pci/83xx-512x-pci.txt
>>>>>
>>>>> Both format uses:
>>>>> #size-cells = <2>;
>>>>> #address-cells = <3>;
>>>>>
>>>>> What is valid format?
>>>>
>>>> Both. 7 cells are valid when the host (parent) bus is 64-bit and 6
>>>> cells
>>>> are valid when the host bus is 32-bit. The ranges property is <>>> address> >. The parent address #address-cells is
>>>> taken from the parent node.
>>>
>>> Ok. Got it.
>>>
>>> Here is what we use on zynq and microblaze - both 32bit which should be
>>> fine.
>>>
>>> ps7_axi_interconnect_0: axi@0 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> axi_pcie_0: axi-pcie@5000 {
>>> #address-cells = <3>;
>>> #size-cells = <2>;
>>> compatible = "xlnx,axi-pcie-1.05.a";
>>> ranges = < 0x0200 0 0x6000 0x6000 0
>>> 0x1000 >;
>>> ...
>>> }
>>> }
>>>
>>> What I am wondering is pci_process_bridge_OF_ranges() at
>>> arch/powerpc/kernel/pci-common.c
>>> where there are used some hardcoded values which should be probably
>>> loaded from device-tree.
>>>
>>> For example:
>>> 683 int np = pna + 5;
>>> ...
>>> 702 pci_addr = of_read_number(ranges + 1, 2);
>>> 703 cpu_addr = of_translate_address(dev, ranges + 3);
>>> 704 size = of_read_number(ranges + pna + 3, 2);
>>
>> These would always be correct whether you have 6 or 7 cells. pna is the
>> parent bus address cells size. The pci address is fixed at 3 cells.
>
> Sorry for my pci ignorance (have never got hw for mb/zynq)
> I just want to get better overview how we should we our drivers to be
> compatible.
>
> Does it mean that pci is supposed be always 64 bit wide?
> And there is no option to have just 32bit values.
That's what the DT documentation says.
BTW, you can use 2 cells even if you only have a 32-bit bus.
>
>>> Unfortunately we have copied it to microblaze.
>>
>> I look at the PCI DT code in powerpc and see a whole bunch of code that
>> seems like it should be common. The different per arch pci structs
>> complicates that. No one has really gotten to looking at PCI DT on ARM
>> yet except you and Thierry for Tegra. We definitely don't want to create
>> a 3rd copy. Starting the process of moving it to something like
>> drivers/pci/pci-of.c would be great.
>
> We have done pcie working on zynq and the same pcie host is working on
> Microblaze too.
> There are just small differences. That's why I have sent another email
> ("Sharing PCIE driver between Microblaze and Arm zynq") to find out
> proper location.
Yes, I've followed the thread. There are lots of areas for consolidation
with PCIe hosts both across architectures and within ARM. There are
multiple people using DW PCIe IP although not upstream yet that I'm
aware of.
Rob
>
> PCI: Microblaze shares almost the same code with powerpc that's why I am
> definitely open
> to move this code out of architecture.
>
> Thanks,
> Michal
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci and pcie device-tree binding - range No cells
On 12/10/2012 11:15 AM, Thomas Petazzoni wrote: > Dear Michal Simek, > > On Mon, 10 Dec 2012 17:05:13 +0100, Michal Simek wrote: > >> CC: Thomas: I think it will be interesting to see this discussion >> because you are using size-cell/address-cells equal 1. >> http://www.spinics.net/lists/arm-kernel/msg211839.html > > Thanks for Cc'ing me. > > The thing is that on Marvell SoCs, we don't need to describe statically > in the Device Tree the translation between CPU addresses and PCI device > addresses, because those translations are set up dynamically at run > time through address decoding windows. > > Marvell SoCs have up to 20 configurable address windows, which allow > you, at run time, to say "I would like the range from physical address > 0x to 0x to correspond to the PCIe device in port 1, > lane 2, or to the NAND, or to this or that device". Therefore, in the > PCIe driver I proposed for the Armada 370/XP SoCs [1], there is no need > to encode all those ranges statically in the DT. That's not a unique feature. I'm not sure if any powerpc systems do that though. > The only "ranges" property I'm using is to allow the DT sub-nodes > describing each PCIe port/lane to access the CPU registers that allow > to see if the PCIe link is up or down, access the PCI configuration > space and so on. So all ranges in my "ranges" property correspond to > normal CPU registers, like the one you would put in the "reg" property > for any device. The fact that those devices are PCIe is really > orthogonal here. That doesn't really sound right. > Of course, I have no idea if I'm doing a correct usage of the DT, but I > certainly don't need those 6 values ranges with bits to say if it's I/O > space, memory space, bus number, device number and so on. The physical > addresses at which I'm setting up my address decoding windows are > decided dynamically at runtime, depending on the number of PCIe devices > that are found in the different PCIe slots (for now, those windows have > a statically defined size, but I'd ideally would like to size them to > match exactly the size of the PCIe device memory, in order to avoid > wasting physical address space, but I haven't found how to get the size > needed for each PCIe device during the ARM pcibios initialization > sequence). I don't think deviating from the normal binding is the right approach. Perhaps the host driver should fill in the ranges property with the addresses it uses. Then any child devices will get the right address translation. Also, while the h/w may support practically any config, there are practical constraints of what Linux will use like there's no reason to support more than 64K i/o space. PCI memory addresses generally start at 0x10. You probably don't need more than 1 memory window per root complex (although prefetchable memory may also be needed). You could let the DT settings drive the address window configuration. Rob > For those willing to have a look at the PCIe patch set for Armada > 370/XP, see: > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136455.html. > The core of the PCIe driver and its DT binding documentation is at > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136711.html. > > Thanks a lot for your comments, > > Thomas > > [1] that I hope to extend to cover previous Marvell SoCs as well, they > work basically the same way > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pci and pcie device-tree binding - range No cells
On 12/12/2012 10:16 AM, Thomas Petazzoni wrote: > Dear Rob Herring, > > On Mon, 10 Dec 2012 17:24:44 -0600, Rob Herring wrote: > >>> Marvell SoCs have up to 20 configurable address windows, which allow >>> you, at run time, to say "I would like the range from physical >>> address 0x to 0x to correspond to the PCIe device >>> in port 1, lane 2, or to the NAND, or to this or that device". >>> Therefore, in the PCIe driver I proposed for the Armada 370/XP SoCs >>> [1], there is no need to encode all those ranges statically in the >>> DT. >> >> That's not a unique feature. I'm not sure if any powerpc systems do >> that though. > > Yes, probably not an unique feature. > >>> The only "ranges" property I'm using is to allow the DT sub-nodes >>> describing each PCIe port/lane to access the CPU registers that >>> allow to see if the PCIe link is up or down, access the PCI >>> configuration space and so on. So all ranges in my "ranges" >>> property correspond to normal CPU registers, like the one you would >>> put in the "reg" property for any device. The fact that those >>> devices are PCIe is really orthogonal here. >> >> That doesn't really sound right. > > Very likely, but I still don't get what is "the right way". > >> I don't think deviating from the normal binding is the right approach. >> Perhaps the host driver should fill in the ranges property with the >> addresses it uses. Then any child devices will get the right address >> translation. > > I don't really understand what you mean here. If you look at the host > driver code (arch/arm/mach-mvebu/pcie.c), for each PCIe interface > is simply does: > > * Create an address decoding window for the memory BAR > * Create an address decoding window for the I/O BAR > * Associate the memory BAR window address and the I/O bar window >address with the PCIe interface > > And that's it. See > https://github.com/MISL-EBU-System-SW/mainline-public/blob/marvell-pcie-v1/arch/arm/mach-mvebu/pcie.c#L107. > > So this driver is both "deciding" of the physical addresses for each > PCIe interface, and "associating" them with the PCIe interfaces. How is > it useful to feed some addresses back into the Device Tree? I'm not completely sure for PCI, but the ranges is necessary to translate addresses of child nodes. If you don't need ranges then you could omit it. If you need ranges, then you should follow the PCI binding whether it is put in the DTS or you dynamically fill it in. This could be filled in by the bootloader as well if you have PCI devices you need to boot from. >> Also, while the h/w may support practically any config, there are >> practical constraints of what Linux will use like there's no reason to >> support more than 64K i/o space. PCI memory addresses generally start >> at 0x10. You probably don't need more than 1 memory window per >> root complex (although prefetchable memory may also be needed). > > I allocate one 64K I/O window and one memory window per PCIe interface > whose link is up (i.e a PCIe device is connected). > >> You could let the DT settings drive the address window configuration. > > No, because I don't want to have absolute addresses for the windows: I > have 10 PCIe interfaces, but often, only a few of them are used. So I > don't want in the Device Tree to over-allocate hundreds of MB of > physical address space if it's not useful. How many you have is probably board dependent and not probe-able, right? So you would at least know the subset of root complexes that you are using. I know you want to find the size of all the cards up front and size windows based on that, but I don't think that is going to be possible. > > PCIe is dynamic, address window configuration is dynamic. And we should > hardcode all this configuration statically in the DT? Doesn't seem like > the right solution. I'm just throwing out ideas. There are many cases of flexibility in h/w designs which are never used. H/w is often designed in a vacuum without s/w input. Not saying that is the case here, but you do have to consider that. Rob > > Best regards, > > Thomas > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: Fix export of of_find_matching_node_and_match()
On 12/19/2012 05:02 AM, Grant Likely wrote: > On Wed, Dec 19, 2012 at 10:58 AM, Grant Likely > wrote: >> Commit 50c8af4cf9, "of: introduce for_each_matching_node_and_match()" >> renamed of_find_matching_node() to of_find_matching_node_and_match() and >> created a new static inline of_find_matching_node() wrapper around the >> new name. However, the change neglected to change the EXPORT_SYMBOL() >> reference causing build errors for modules. >> >> This patch fixes the EXPORT_SYMBOL() statement. Discovered on a PowerPC >> Efika build with the mpc52xx_uart driver being built as a module. >> >> Reported-by: Benjamin Herrenschmidt >> Signed-off-by: Grant Likely >> Cc: Stephen Warren >> Cc: Rob Herring >> Cc: Anatolij Gustschin > > Rob, I've just pushed this out to my devicetree/merge branch. If > you've got any fixes queued up for Linus, then please pull this in > before sending them on to him. Otherwise I'll send Linus a pull req > for this fix this evening. Ether way, please reply to let me know what > you're going to do. > The only item on my todo is this one: "of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS" But I'm not going to get to it today if you want to pick it up. Rob > g. > > The following changes since commit 752451f01c4567b506bf4343082682dbb8fb30dd: > > Merge branch 'i2c-embedded/for-next' of > git://git.pengutronix.de/git/wsa/linux (2012-12-18 16:51:10 -0800) > > are available in the git repository at: > > git://git.secretlab.ca/git/linux-2.6 devicetree/merge > > for you to fetch changes up to 80c2022e5645a1a789531d13010292c5c18bf1db: > > of: Fix export of of_find_matching_node_and_match() (2012-12-19 > 10:58:53 +) > > > Grant Likely (1): > of: Fix export of of_find_matching_node_and_match() > > drivers/of/base.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >> --- >> >> I'll push this patch out to my tree ASAP. >> >> drivers/of/base.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/of/base.c b/drivers/of/base.c >> index db8d211..2390ddb 100644 >> --- a/drivers/of/base.c >> +++ b/drivers/of/base.c >> @@ -629,7 +629,7 @@ struct device_node >> *of_find_matching_node_and_match(struct device_node *from, >> read_unlock(&devtree_lock); >> return np; >> } >> -EXPORT_SYMBOL(of_find_matching_node); >> +EXPORT_SYMBOL(of_find_matching_node_and_match); >> >> /** >> * of_modalias_node - Lookup appropriate modalias for a device node >> -- >> 1.7.10.4 >> > > > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/5] of_platform_driver and OF_DEVICE removal
From: Rob Herring This series is a relatively straight-forward removal of the last remaining user of of_platform_driver (ibmebus) and removal of CONFIG_OF_DEVICE which is always enabled when CONFIG_OF is enabled. Compile tested on powerpc and sparc. Rob Rob Herring (5): ibmebus: convert of_platform_driver to platform_driver driver core: move to_platform_driver to platform_device.h of: remove of_platform_driver usb: chipidea: depend on CONFIG_OF instead of CONFIG_OF_DEVICE of: remove CONFIG_OF_DEVICE arch/powerpc/include/asm/ibmebus.h|4 ++-- arch/powerpc/kernel/ibmebus.c | 22 ++--- drivers/base/platform.c |3 --- drivers/infiniband/hw/ehca/ehca_main.c|5 ++--- drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++- drivers/of/Kconfig|3 --- drivers/of/Makefile |3 +-- drivers/usb/chipidea/Makefile |2 +- include/linux/of_device.h |6 +++--- include/linux/of_platform.h | 30 + include/linux/platform_device.h |3 +++ 11 files changed, 26 insertions(+), 63 deletions(-) -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
From: Rob Herring
ibmebus is the last remaining user of of_platform_driver and the
conversion to a regular platform driver is trivial.
Signed-off-by: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Hoang-Nam Nguyen
Cc: Christoph Raisch
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Thadeu Lima de Souza Cascardo
Cc: Grant Likely
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-r...@vger.kernel.org
Cc: net...@vger.kernel.org
---
arch/powerpc/include/asm/ibmebus.h|4 ++--
arch/powerpc/kernel/ibmebus.c | 22 ++
drivers/infiniband/hw/ehca/ehca_main.c|5 ++---
drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++-
4 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/ibmebus.h
b/arch/powerpc/include/asm/ibmebus.h
index 1a9d9ae..088f95b 100644
--- a/arch/powerpc/include/asm/ibmebus.h
+++ b/arch/powerpc/include/asm/ibmebus.h
@@ -48,8 +48,8 @@
extern struct bus_type ibmebus_bus_type;
-int ibmebus_register_driver(struct of_platform_driver *drv);
-void ibmebus_unregister_driver(struct of_platform_driver *drv);
+int ibmebus_register_driver(struct platform_driver *drv);
+void ibmebus_unregister_driver(struct platform_driver *drv);
int ibmebus_request_irq(u32 ist, irq_handler_t handler,
unsigned long irq_flags, const char *devname,
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 8220baa..16a7c23 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -205,7 +205,7 @@ static int ibmebus_create_devices(const struct of_device_id
*matches)
return ret;
}
-int ibmebus_register_driver(struct of_platform_driver *drv)
+int ibmebus_register_driver(struct platform_driver *drv)
{
/* If the driver uses devices that ibmebus doesn't know, add them */
ibmebus_create_devices(drv->driver.of_match_table);
@@ -215,7 +215,7 @@ int ibmebus_register_driver(struct of_platform_driver *drv)
}
EXPORT_SYMBOL(ibmebus_register_driver);
-void ibmebus_unregister_driver(struct of_platform_driver *drv)
+void ibmebus_unregister_driver(struct platform_driver *drv)
{
driver_unregister(&drv->driver);
}
@@ -338,11 +338,10 @@ static int ibmebus_bus_bus_match(struct device *dev,
struct device_driver *drv)
static int ibmebus_bus_device_probe(struct device *dev)
{
int error = -ENODEV;
- struct of_platform_driver *drv;
+ struct platform_driver *drv;
struct platform_device *of_dev;
- const struct of_device_id *match;
- drv = to_of_platform_driver(dev->driver);
+ drv = to_platform_driver(dev->driver);
of_dev = to_platform_device(dev);
if (!drv->probe)
@@ -350,9 +349,8 @@ static int ibmebus_bus_device_probe(struct device *dev)
of_dev_get(of_dev);
- match = of_match_device(drv->driver.of_match_table, dev);
- if (match)
- error = drv->probe(of_dev, match);
+ if (of_driver_match_device(dev, dev->driver))
+ error = drv->probe(of_dev);
if (error)
of_dev_put(of_dev);
@@ -362,7 +360,7 @@ static int ibmebus_bus_device_probe(struct device *dev)
static int ibmebus_bus_device_remove(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+ struct platform_driver *drv = to_platform_driver(dev->driver);
if (dev->driver && drv->remove)
drv->remove(of_dev);
@@ -372,7 +370,7 @@ static int ibmebus_bus_device_remove(struct device *dev)
static void ibmebus_bus_device_shutdown(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+ struct platform_driver *drv = to_platform_driver(dev->driver);
if (dev->driver && drv->shutdown)
drv->shutdown(of_dev);
@@ -419,7 +417,7 @@ struct device_attribute ibmebus_bus_device_attrs[] = {
static int ibmebus_bus_legacy_suspend(struct device *dev, pm_message_t mesg)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+ struct platform_driver *drv = to_platform_driver(dev->driver);
int ret = 0;
if (dev->driver && drv->suspend)
@@ -430,7 +428,7 @@ static int ibmebus_bus_legacy_suspend(struct device *dev,
pm_message_t mesg)
static int ibmebus_bus_legacy_resume(struct device *dev)
{
struct platform_device *of_dev = to_platform_device(dev);
- struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
+ struct platform_driver *drv = to_platform_driver(dev->driver);
int ret = 0;
if (dev->drive
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On Sun, Apr 21, 2013 at 9:13 PM, Rob Herring wrote:
> From: Rob Herring
>
> ibmebus is the last remaining user of of_platform_driver and the
> conversion to a regular platform driver is trivial.
>
> Signed-off-by: Rob Herring
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Hoang-Nam Nguyen
> Cc: Christoph Raisch
> Cc: Roland Dreier
> Cc: Sean Hefty
> Cc: Hal Rosenstock
> Cc: Thadeu Lima de Souza Cascardo
> Cc: Grant Likely
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-r...@vger.kernel.org
> Cc: net...@vger.kernel.org
Ben, Can I have your Ack for this? The change is straightforward and
neither of the 2 drivers used the id parameter that is removed.
Rob
> ---
> arch/powerpc/include/asm/ibmebus.h|4 ++--
> arch/powerpc/kernel/ibmebus.c | 22 ++
> drivers/infiniband/hw/ehca/ehca_main.c|5 ++---
> drivers/net/ethernet/ibm/ehea/ehea_main.c |8 +++-
> 4 files changed, 17 insertions(+), 22 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ibmebus.h
> b/arch/powerpc/include/asm/ibmebus.h
> index 1a9d9ae..088f95b 100644
> --- a/arch/powerpc/include/asm/ibmebus.h
> +++ b/arch/powerpc/include/asm/ibmebus.h
> @@ -48,8 +48,8 @@
>
> extern struct bus_type ibmebus_bus_type;
>
> -int ibmebus_register_driver(struct of_platform_driver *drv);
> -void ibmebus_unregister_driver(struct of_platform_driver *drv);
> +int ibmebus_register_driver(struct platform_driver *drv);
> +void ibmebus_unregister_driver(struct platform_driver *drv);
>
> int ibmebus_request_irq(u32 ist, irq_handler_t handler,
> unsigned long irq_flags, const char *devname,
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index 8220baa..16a7c23 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -205,7 +205,7 @@ static int ibmebus_create_devices(const struct
> of_device_id *matches)
> return ret;
> }
>
> -int ibmebus_register_driver(struct of_platform_driver *drv)
> +int ibmebus_register_driver(struct platform_driver *drv)
> {
> /* If the driver uses devices that ibmebus doesn't know, add them */
> ibmebus_create_devices(drv->driver.of_match_table);
> @@ -215,7 +215,7 @@ int ibmebus_register_driver(struct of_platform_driver
> *drv)
> }
> EXPORT_SYMBOL(ibmebus_register_driver);
>
> -void ibmebus_unregister_driver(struct of_platform_driver *drv)
> +void ibmebus_unregister_driver(struct platform_driver *drv)
> {
> driver_unregister(&drv->driver);
> }
> @@ -338,11 +338,10 @@ static int ibmebus_bus_bus_match(struct device *dev,
> struct device_driver *drv)
> static int ibmebus_bus_device_probe(struct device *dev)
> {
> int error = -ENODEV;
> - struct of_platform_driver *drv;
> + struct platform_driver *drv;
> struct platform_device *of_dev;
> - const struct of_device_id *match;
>
> - drv = to_of_platform_driver(dev->driver);
> + drv = to_platform_driver(dev->driver);
> of_dev = to_platform_device(dev);
>
> if (!drv->probe)
> @@ -350,9 +349,8 @@ static int ibmebus_bus_device_probe(struct device *dev)
>
> of_dev_get(of_dev);
>
> - match = of_match_device(drv->driver.of_match_table, dev);
> - if (match)
> - error = drv->probe(of_dev, match);
> + if (of_driver_match_device(dev, dev->driver))
> + error = drv->probe(of_dev);
> if (error)
> of_dev_put(of_dev);
>
> @@ -362,7 +360,7 @@ static int ibmebus_bus_device_probe(struct device *dev)
> static int ibmebus_bus_device_remove(struct device *dev)
> {
> struct platform_device *of_dev = to_platform_device(dev);
> - struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
> + struct platform_driver *drv = to_platform_driver(dev->driver);
>
> if (dev->driver && drv->remove)
> drv->remove(of_dev);
> @@ -372,7 +370,7 @@ static int ibmebus_bus_device_remove(struct device *dev)
> static void ibmebus_bus_device_shutdown(struct device *dev)
> {
> struct platform_device *of_dev = to_platform_device(dev);
> - struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
> + struct platform_driver *drv = to_platform_driver(dev->driver);
>
> if (dev->driver && drv->shutdown)
> drv->shutdown(of_dev);
> @@ -419,7 +417,7 @@ struct device_attribute ibmebus_bus_device_attrs[] = {
> static int ibmebus_bus_legacy_suspend(struct device *dev, pm_messag
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: > On Thu, 2013-04-25 at 10:23 -0500, Rob Herring wrote: >> Ben, Can I have your Ack for this? The change is straightforward and >> neither of the 2 drivers used the id parameter that is removed. > > Didn't you get my mail about a compile failure caused by this patch ? No, and I can't find any evidence of a mail in my inbox or in the list archives. > > A quick build test leads to: > > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function > 'ibmebus_bus_device_probe': > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:2: error: > implicit declaration of function 'to_platform_driver' > [-Werror=implicit-function-declaration] > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:344:6: error: > assignment makes pointer from integer without a cast [-Werror] > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function > 'ibmebus_bus_device_remove': > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:363:32: error: > initialization makes pointer from integer without a cast [-Werror] > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function > 'ibmebus_bus_device_shutdown': > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:373:32: error: > initialization makes pointer from integer without a cast [-Werror] > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function > 'ibmebus_bus_legacy_suspend': > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:420:32: error: > initialization makes pointer from integer without a cast [-Werror] > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c: In function > 'ibmebus_bus_legacy_resume': > /home/benh/linux-powerpc-test/arch/powerpc/kernel/ibmebus.c:431:32: error: > initialization makes pointer from integer without a cast [-Werror] > cc1: all warnings being treated as errors > make[2]: *** [arch/powerpc/kernel/ibmebus.o] Error 1 > make[2]: *** Waiting for unfinished jobs > > Haven't had a chance to look too closely today -EJETLAG :-) You need patch 2 of this series to fix this: driver core: move to_platform_driver to platform_device.h which as Arnd pointed out needs to come first. I've fixed that in my tree, but I don't think it warrants another post. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
On 04/25/2013 03:12 PM, Benjamin Herrenschmidt wrote: > On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote: >> On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote: [...] >> You need patch 2 of this series to fix this: >> >> driver core: move to_platform_driver to platform_device.h >> >> which as Arnd pointed out needs to come first. I've fixed that in my >> tree, but I don't think it warrants another post. > > Can I pull you tree from somewhere to test ? Here you go: git://sources.calxeda.com/kernel/linux.git of-platform-removal Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
On Fri, Apr 18, 2014 at 7:48 AM, Leif Lindholm wrote: > On Thu, Apr 17, 2014 at 07:43:13PM -0500, Rob Herring wrote: >> On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm >> wrote: >> > drivers/of/fdt.c contains a workaround for a missing memory type >> > entry on longtrail firmware. Make that quirk PPC32 only, and while >> > at it - fix up the .dts files in the tree currently working only >> > because of that quirk. >> >> But why do you need this? > > Apart from the current code permitting recreating a 15+ year old > firmware bug into completely new platform ports? I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here. Really, I would like to see quirks like this fixed up out of line from the normal flow somewhat like how PCI quirks are handled. So in this example, we would just add the missing property to the dtb for the broken platform before doing the memory scan. That does then require libfdt which is something I'm working on. > Because the UEFI stub for arm/arm64 needs to delete all of the "memory" > nodes from the DT. And it would be nice to at least not have to compile > the "and also delete anything called memory@0" into the arm64 image. Or > any image not including support for affected platforms. I don't see why you would handle that in the EFI stub. Given our lack of validation, I can see there is a chance this happens but I think it is pretty small. Given we only have a ARM board, I'd say we are doing surprisingly well. Rob >> > arch/arm/boot/dts/ste-ccu8540.dts |1 + >> > arch/mips/lantiq/dts/easy50712.dts|1 + >> > arch/mips/ralink/dts/mt7620a_eval.dts |1 + >> > arch/mips/ralink/dts/rt2880_eval.dts |1 + >> > arch/mips/ralink/dts/rt3052_eval.dts |1 + >> > arch/mips/ralink/dts/rt3883_eval.dts |1 + >> >> I'm not worried about these MIPS dts files because they are all >> built-in, but you are breaking compatibility with old dtbs for this >> ARM board. > > Yeah, sorry. Sending out a v2 of part 3 shortly. > > / > Leif ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
On Fri, Apr 18, 2014 at 3:13 PM, Leif Lindholm wrote: > On Fri, Apr 18, 2014 at 10:37:58AM -0500, Rob Herring wrote: >> >> But why do you need this? >> > >> > Apart from the current code permitting recreating a 15+ year old >> > firmware bug into completely new platform ports? >> >> I would prefer to see a "WARN_ON(!IS_ENABLED(CONFIG_PPC32));" added here. > > In addition to, or instead of, the QUIRK ifdef? Instead of because I don't see how you handle the ARM board compatibility with the ifdef. (And please, no ifdef for that board). >> Really, I would like to see quirks like this fixed up out of line from >> the normal flow somewhat like how PCI quirks are handled. So in this >> example, we would just add the missing property to the dtb for the >> broken platform before doing the memory scan. That does then require >> libfdt which is something I'm working on. > > Getting rid of all this handling from generic code would clearly be > preferable. Is that code going in in the near future, or could we add > the quirk as a stopgap? Some sort of quirk infrastructure is not going to happen soon. It's just an idea bouncing in my head ATM. >> > Because the UEFI stub for arm/arm64 needs to delete all of the "memory" >> > nodes from the DT. And it would be nice to at least not have to compile >> > the "and also delete anything called memory@0" into the arm64 image. Or >> > any image not including support for affected platforms. >> >> I don't see why you would handle that in the EFI stub. Given our lack >> of validation, I can see there is a chance this happens but I think it >> is pretty small. Given we only have a ARM board, I'd say we are doing >> surprisingly well. > > I'm not too bothered personally, but Mark Rutland handed me a patch to > improve the memory node handling in the stub, and he seemed to really > want this there. You guys can fight it out :) Simply put, we shouldn't put work-arounds in new code for new platforms. > What would be the effect of the UEFI code adding all its memblocks, > minus the reserved areas, and then the DT code doing a memblock_add > of all RAM (including reserved areas)? Would memblock_reserve()s on > the protected regions suffice to prevent crazy stuff from happening? So use UEFI to add the memory, but then add reserved areas with DT? I'm not sure I follow, but even if I did I don't know memblock code well enough to say what it would do. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
On Fri, Apr 18, 2014 at 7:59 AM, Leif Lindholm wrote: > Hi Geert, > > On Fri, Apr 18, 2014 at 10:04:15AM +0200, Geert Uytterhoeven wrote: >> On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm >> wrote: >> > In order to deal with an firmware bug on a specific ppc32 platform >> > (longtrail), early_init_dt_scan_memory() looks for a node called >> > memory@0 on all platforms. Restrict this quirk to ppc32 kernels only. >> >> This breaks backwards compatibilty with old DTSes (at least on ARM/MIPS, >> where you added the missing property in patches 1 and 2 of the series)? > > As Rob said in response to 0/3, the MIPSs would likely not be affected, > since they embed the DT. > >> For the Longtrail, I don't care much anymore, as mine died in 2004. >> AFAIK, there have never been many users anyway. > > There are still a few mentions of it under arch/powerpc/, so I wouldn't > want to be the one to kill it off... > > How about the below v2 3/3 to address the ARM platform? > > Regards, > > Leif > > From 6fa0b837ad71780334eb97d63c507165b6c57add Mon Sep 17 00:00:00 2001 > From: Leif Lindholm > Date: Thu, 17 Apr 2014 14:24:47 +0100 > Subject: [PATCH] of: arm: powerpc: Restrict memory@0 node handling to > affected platforms > > In order to deal with a firmware bug on a specific ppc32 platform > (longtrail), early_init_dt_scan_memory() looks for a node called > memory@0 on all platforms, for all nodes lacking a device_type. > Restrict this quirk to ppc32 and the arm mach-ux500 platforms (one of > which has depended on this special handling). > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 889005f..230c747 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -77,4 +77,7 @@ config OF_RESERVED_MEM > help > Helpers to allow for reservation of memory regions > > +config OF_MEMORY_AT_0_QUIRK > + def_bool n I do not like this because it would not scale to many quirks. As I said,, my preference here would be to just add a WARN. The other option is get approval to break compatibility on the ST platform. It may not be a concern on certain platforms. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 00/21] FDT clean-ups and libfdt support
From: Rob Herring This is a series of clean-ups of architecture FDT code and converts the core FDT code over to using libfdt functions. This is in preparation to add FDT based address translation parsing functions for early console support. This series removes direct access to FDT data from all arches except powerpc. The current MIPS lantiq and xlp DT code is buggy as built-in DTBs need to be copied out of init section. Patches 2 and 3 should be applied to 3.15. Changes in v2 are relatively minor. There was a bug in the unflattening code where walking up the tree was not being handled correctly (thanks to Michal Simek). I re-worked things a bit to avoid globally adding libfdt include paths. A branch is available here[1], and I plan to put into linux-next in a few days. Please test! I've compiled on arm, arm64, mips, microblaze, xtensa, and powerpc and booted on arm and arm64. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git libfdt Rob Herring (21): mips: octeon: convert to use unflatten_and_copy_device_tree mips: lantiq: copy built-in DTB out of init section mips: xlp: copy built-in DTB out of init section mips: ralink: convert to use unflatten_and_copy_device_tree ARM: dt: use default early_init_dt_alloc_memory_arch c6x: convert fdt pointers to opaque pointers mips: convert fdt pointers to opaque pointers of/fdt: consolidate built-in dtb section variables of/fdt: remove some unneeded includes of/fdt: remove unused of_scan_flat_dt_by_path of/fdt: update of_get_flat_dt_prop in prep for libfdt of/fdt: Convert FDT functions to use libfdt of/fdt: use libfdt accessors for header data of/fdt: create common debugfs of/fdt: move memreserve and dtb memory reservations into core of/fdt: fix phys_addr_t related print size warnings of/fdt: introduce of_get_flat_dt_size powerpc: use libfdt accessors for header data x86: use FDT accessors for FDT blob header data of/fdt: convert initial_boot_params to opaque pointer of: push struct boot_param_header and defines into powerpc arch/arc/include/asm/sections.h | 1 - arch/arc/kernel/devtree.c | 2 +- arch/arm/include/asm/prom.h | 2 - arch/arm/kernel/devtree.c | 34 +-- arch/arm/mach-exynos/exynos.c | 2 +- arch/arm/mach-vexpress/platsmp.c| 2 +- arch/arm/mm/init.c | 1 - arch/arm/plat-samsung/s5p-dev-mfc.c | 4 +- arch/arm64/mm/init.c| 21 -- arch/c6x/kernel/setup.c | 4 +- arch/metag/kernel/setup.c | 4 - arch/microblaze/kernel/prom.c | 39 +-- arch/mips/cavium-octeon/setup.c | 20 +- arch/mips/include/asm/mips-boards/generic.h | 4 - arch/mips/include/asm/prom.h| 6 +- arch/mips/kernel/prom.c | 2 +- arch/mips/lantiq/prom.c | 15 +- arch/mips/lantiq/prom.h | 2 - arch/mips/mti-sead3/sead3-setup.c | 8 +- arch/mips/netlogic/xlp/dt.c | 19 +- arch/mips/ralink/of.c | 29 +- arch/openrisc/kernel/vmlinux.h | 2 - arch/powerpc/include/asm/prom.h | 39 +++ arch/powerpc/kernel/Makefile| 1 + arch/powerpc/kernel/epapr_paravirt.c| 2 +- arch/powerpc/kernel/fadump.c| 4 +- arch/powerpc/kernel/prom.c | 78 ++ arch/powerpc/kernel/rtas.c | 2 +- arch/powerpc/mm/hash_utils_64.c | 22 +- arch/powerpc/platforms/52xx/efika.c | 4 +- arch/powerpc/platforms/chrp/setup.c | 4 +- arch/powerpc/platforms/powernv/opal.c | 12 +- arch/powerpc/platforms/pseries/setup.c | 4 +- arch/x86/kernel/devicetree.c| 12 +- arch/xtensa/kernel/setup.c | 3 +- drivers/of/Kconfig | 1 + drivers/of/Makefile | 2 + drivers/of/fdt.c| 398 ++-- drivers/of/of_reserved_mem.c| 4 +- include/linux/of_fdt.h | 63 + 40 files changed, 280 insertions(+), 598 deletions(-) -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 14/21] of/fdt: create common debugfs
From: Rob Herring
Both powerpc and microblaze have the same FDT blob in debugfs feature.
Move this to common location and remove the powerpc and microblaze
implementations. This feature could become more useful when FDT
overlay support is added.
This changes the path of the blob from "$arch/flat-device-tree" to
"device-tree/flat-device-tree".
Signed-off-by: Rob Herring
Cc: Michal Simek
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
v2: move to after libfdt conversion
arch/microblaze/kernel/prom.c | 31 ---
arch/powerpc/kernel/prom.c| 21 -
drivers/of/fdt.c | 24
3 files changed, 24 insertions(+), 52 deletions(-)
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index c766306..68f0999 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -114,34 +114,3 @@ void __init early_init_devtree(void *params)
pr_debug(" <- early_init_devtree()\n");
}
-
-/***
- *
- * New implementation of the OF "find" APIs, return a refcounted
- * object, call of_node_put() when done. The device tree and list
- * are protected by a rw_lock.
- *
- * Note that property management will need some locking as well,
- * this isn't dealt with yet.
- *
- ***/
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = initial_boot_params->totalsize;
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- of_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-device_initcall(export_flat_device_tree);
-#endif
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index f971134..03624ce 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -924,23 +923,3 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
{
return (int)phys_id == get_hard_smp_processor_id(cpu);
}
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- powerpc_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-__initcall(export_flat_device_tree);
-#endif
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 0b38a6a..4129f74 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include /* for COMMAND_LINE_SIZE */
#include
@@ -916,4 +917,27 @@ void __init unflatten_and_copy_device_tree(void)
unflatten_device_tree();
}
+#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
+static struct debugfs_blob_wrapper flat_dt_blob;
+
+static int __init of_flat_dt_debugfs_export_fdt(void)
+{
+ struct dentry *d = debugfs_create_dir("device-tree", NULL);
+
+ if (!d)
+ return -ENOENT;
+
+ flat_dt_blob.data = initial_boot_params;
+ flat_dt_blob.size = fdt_totalsize(initial_boot_params);
+
+ d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
+ d, &flat_dt_blob);
+ if (!d)
+ return -ENOENT;
+
+ return 0;
+}
+module_init(of_flat_dt_debugfs_export_fdt);
+#endif
+
#endif /* CONFIG_OF_EARLY_FLATTREE */
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 21/21] of: push struct boot_param_header and defines into powerpc
From: Rob Herring
Now powerpc is the only user of struct boot_param_header and FDT defines,
so they can be moved into the powerpc architecture code.
Signed-off-by: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
v2: no change
arch/powerpc/include/asm/prom.h | 39 +++
include/linux/of_fdt.h | 37 -
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index d977b9b..74b79f0 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -26,6 +26,45 @@
#include
#include
+#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
+#define OF_DT_END_NODE 0x2 /* End node */
+#define OF_DT_PROP 0x3 /* Property: name off, size,
+* content */
+#define OF_DT_NOP 0x4 /* nop */
+#define OF_DT_END 0x9
+
+#define OF_DT_VERSION 0x10
+
+/*
+ * This is what gets passed to the kernel by prom_init or kexec
+ *
+ * The dt struct contains the device tree structure, full pathes and
+ * property contents. The dt strings contain a separate block with just
+ * the strings for the property names, and is fully page aligned and
+ * self contained in a page, so that it can be kept around by the kernel,
+ * each property name appears only once in this page (cheap compression)
+ *
+ * the mem_rsvmap contains a map of reserved ranges of physical memory,
+ * passing it here instead of in the device-tree itself greatly simplifies
+ * the job of everybody. It's just a list of u64 pairs (base/size) that
+ * ends when size is 0
+ */
+struct boot_param_header {
+ __be32 magic; /* magic word OF_DT_HEADER */
+ __be32 totalsize; /* total size of DT block */
+ __be32 off_dt_struct; /* offset to structure */
+ __be32 off_dt_strings; /* offset to strings */
+ __be32 off_mem_rsvmap; /* offset to memory reserve map */
+ __be32 version;/* format version */
+ __be32 last_comp_version; /* last compatible version */
+ /* version 2 fields below */
+ __be32 boot_cpuid_phys;/* Physical CPU id we're booting on */
+ /* version 3 fields below */
+ __be32 dt_strings_size;/* size of the DT strings block */
+ /* version 17 fields below */
+ __be32 dt_struct_size; /* size of the DT structure block */
+};
+
/*
* OF address retreival & translation
*/
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 1f882e1..5c0ab05 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -17,45 +17,8 @@
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
-#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
-#define OF_DT_END_NODE 0x2 /* End node */
-#define OF_DT_PROP 0x3 /* Property: name off, size,
-* content */
-#define OF_DT_NOP 0x4 /* nop */
-#define OF_DT_END 0x9
-
-#define OF_DT_VERSION 0x10
#ifndef __ASSEMBLY__
-/*
- * This is what gets passed to the kernel by prom_init or kexec
- *
- * The dt struct contains the device tree structure, full pathes and
- * property contents. The dt strings contain a separate block with just
- * the strings for the property names, and is fully page aligned and
- * self contained in a page, so that it can be kept around by the kernel,
- * each property name appears only once in this page (cheap compression)
- *
- * the mem_rsvmap contains a map of reserved ranges of physical memory,
- * passing it here instead of in the device-tree itself greatly simplifies
- * the job of everybody. It's just a list of u64 pairs (base/size) that
- * ends when size is 0
- */
-struct boot_param_header {
- __be32 magic; /* magic word OF_DT_HEADER */
- __be32 totalsize; /* total size of DT block */
- __be32 off_dt_struct; /* offset to structure */
- __be32 off_dt_strings; /* offset to strings */
- __be32 off_mem_rsvmap; /* offset to memory reserve map */
- __be32 version;/* format version */
- __be32 last_comp_version; /* last compatible version */
- /* version 2 fields below */
- __be32 boot_cpuid_phys;/* Physical CPU id we're booting on */
- /* version 3 fields below */
- __be32 dt_strings_size;/* size of the DT strings block */
- /* version 17 fields below */
- __be32 dt_struct_size; /* size of the DT structure blo
[PATCH] powerpc: fix skipping call to early_init_fdt_scan_reserved_mem
From: Rob Herring The call to early_init_fdt_scan_reserved_mem will be skipped if reserved-ranges is not found. Move the call earlier so that it is called unconditionally. Signed-off-by: Rob Herring Cc: Marek Szyprowski Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org Tested-by: Stephen Chivers --- I found this issue in testing of my fdt clean-up series (thanks to Stephen). Since the reserved memory support is new, I don't think it is critical to fix this for 3.15. I plan to include this with my fdt series for 3.16 unless I hear otherwise. Rob arch/powerpc/kernel/prom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index 668aa47..d657549 100644 --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -567,6 +567,8 @@ static void __init early_reserve_mem_dt(void) unsigned long i, len, dt_root; const __be32 *prop; + early_init_fdt_scan_reserved_mem(); + dt_root = of_get_flat_dt_root(); prop = of_get_flat_dt_prop(dt_root, "reserved-ranges", &len); @@ -589,8 +591,6 @@ static void __init early_reserve_mem_dt(void) memblock_reserve(base, size); } } - - early_init_fdt_scan_reserved_mem(); } static void __init early_reserve_mem(void) -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 4/6] powerpc/85xx: Change vendor prefix for Intersil Corporation to isil
On Wed, Aug 20, 2014 at 3:43 AM, Philipp Zabel wrote:
> Currently there is a wild mixture of isl, isil, and intersil
> compatibles in the kernel. At this point, changing the vendor
> symbol to the most often used variant, which is equal to the
> NASDAQ symbol, isil, should not hurt, since the isl1208 driver
> doesn't care either way.
>
> Signed-off-by: Philipp Zabel
> ---
> arch/powerpc/boot/dts/ppa8548.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/ppa8548.dts
> b/arch/powerpc/boot/dts/ppa8548.dts
> index 27b0699..000262b 100644
> --- a/arch/powerpc/boot/dts/ppa8548.dts
> +++ b/arch/powerpc/boot/dts/ppa8548.dts
> @@ -89,7 +89,7 @@
> &soc {
> i2c@3000 {
> rtc@6f {
> - compatible = "intersil,isl1208";
> + compatible = "isil,isl1208";
This is a mature platform. You cannot change it. You can add the new
string, but the dts and kernel need both strings.
I would just leave it all alone and add the new prefix and mark the
others deprecated.
Rob
> reg = <0x6f>;
> };
> };
> --
> 2.1.0.rc1
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
[fixed DT maillist address]
On 12/17/2013 01:35 AM, Nikita Yushchenko wrote:
> Hi
>
> While trying to make freescale p2020ds and mpc8572ds boards working with
> mainline kernel, I faced that commit
> e38c0a1f (Handle #address-cells > 2 specially) breaks things with these
> boards.
Good to see this broke in v3.7 and is just now found...
>
> Both these boards have uli1575 chip.
> Corresponding part in device tree is something like
>
> uli1575@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <2>;
> #address-cells = <3>;
> ranges = <0x200 0x0 0x8000
> 0x200 0x0 0x8000
> 0x0 0x2000
>
> 0x100 0x0 0x0
> 0x100 0x0 0x0
> 0x0 0x1>;
> isa@1e {
> ...
>
> I.e. it has #address-cells = <3>
>
>
> With commit e38c0a1f reverted, devices under uli1575 are registered
> correctly, e.g. for rtc
>
> OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> OF: translating address: 0001 0070
> OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> OF: walking ranges...
> OF: ISA map, cp=0, s=1000, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> OF: walking ranges...
> OF: default map, cp=a000, s=2000, da=70
> OF: default map, cp=0, s=1, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0100 0070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000
> OF: walking ranges...
> OF: PCI map, cp=0, s=1, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0100 0070
> OF: parent bus is default (na=2, ns=2) on /
> OF: walking ranges...
> OF: PCI map, cp=0, s=1, da=70
> OF: parent translation for: ffc1
> OF: with offset: 70
> OF: one level translation: ffc10070
> OF: reached root node
>
> With commit e38c0a1f in place, address translation fails:
>
> OF: ** translation for device /pcie@ffe09000/pcie@0/uli1575@0/isa@1e/rtc@70 **
> OF: bus is isa (na=2, ns=1) on /pcie@ffe09000/pcie@0/uli1575@0/isa@1e
> OF: translating address: 0001 0070
> OF: parent bus is default (na=3, ns=2) on /pcie@ffe09000/pcie@0/uli1575@0
> OF: walking ranges...
> OF: ISA map, cp=0, s=1000, da=70
> OF: parent translation for: 0100
> OF: with offset: 70
> OF: one level translation: 0070
> OF: parent bus is pci (na=3, ns=2) on /pcie@ffe09000/pcie@0
> OF: walking ranges...
> OF: default map, cp=a000, s=2000, da=70
> OF: default map, cp=0, s=1, da=70
> OF: not found !
>
> Either e38c0a1f should be reverted, or uli1575 (and perhaps other similar
> devices) have to be described in device
> trees differently.
Reverting would break Tegra PCIe, but you should not have to change the
DT either. So we need a solution.
Is this something like this sufficient to fix it?
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 4b9317b..378aebd 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -74,7 +74,7 @@ static u64 of_bus_default_map(__be32 *addr, const
__be32 *range,
* mapping doesn't specify a physical address. Rather, the address
* specifies an identifier that must match exactly.
*/
- if (na > 2 && memcmp(range, addr, na * 4) != 0)
+ if (na > 2 && memcmp(range, addr, (na - 2) * 4) != 0)
return OF_BAD_ADDR;
if (da < cp || da >= (cp + s))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/irq: Fix device_node refcount in of_irq_parse_raw()
On Sun, Dec 29, 2013 at 8:37 PM, Benjamin Herrenschmidt <
b...@kernel.crashing.org> wrote:
> On Tue, 2013-12-17 at 18:32 +0100, Cédric Le Goater wrote:
> > Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" changed
> > the refcount on the device_node causing an error in of_node_put():
>
> Grant, Thierry, this is a regression, please send to Linus ASAP...
>
>
I'm working on doing that right this moment.
Rob
> Cheers,
> Ben.
>
> > ERROR: Bad of_node_put() on /pci@8002000
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3-dirty #2
> > Call Trace:
> > [c0003e403500] [c00144fc] .show_stack+0x7c/0x1f0 (unreliable)
> > [c0003e4035d0] [c070f250] .dump_stack+0x88/0xb4
> > [c0003e403650] [c05e8768] .of_node_release+0xd8/0xf0
> > [c0003e4036e0] [c05eeafc] .of_irq_parse_one+0x10c/0x280
> > [c0003e4037a0] [c05efd4c] .of_irq_parse_pci+0x3c/0x1d0
> > [c0003e403840] [c0038240] .pcibios_setup_device+0xa0/0x2e0
> > [c0003e403910] [c00398f0]
> .pcibios_setup_bus_devices+0x60/0xd0
> > [c0003e403990] [c003b3a4] .__of_scan_bus+0x1a4/0x2b0
> > [c0003e403a80] [c003a62c] .pcibios_scan_phb+0x30c/0x410
> > [c0003e403b60] [c09fe430] .pcibios_init+0x7c/0xd4
> >
> > This patch adjusts the refcount in the walk of the interrupt tree.
> > When a match is found, there is no need to increase the refcount
> > on 'out_irq->np' as 'newpar' is already holding a ref. The refcount
> > balance between 'ipar' and 'newpar' is maintained in the skiplevel:
> > goto label.
> >
> > This patch also removes the usage of the device_node variable 'old'
> > which seems useless after the latest changes.
> >
> > Signed-off-by: Cédric Le Goater
> > ---
> >
> > This patch was tested on powerpc, pseries and powernv. This is a
> > new area for me so I might have missed a path. Please take a look.
> >
> > We could now introduce an helper routine to look for #address-cells in
> > of_irq_parse_raw(). This can be the subject of another patch.
> >
> > Thanks,
> >
> > C.
> >
> > drivers/of/irq.c |5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > index 786b0b47fae4..27212402c532 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -165,7 +165,6 @@ int of_irq_parse_raw(const __be32 *addr, struct
> of_phandle_args *out_irq)
> > if (of_get_property(ipar, "interrupt-controller", NULL) !=
> > NULL) {
> > pr_debug(" -> got it !\n");
> > - of_node_put(old);
> > return 0;
> > }
> >
> > @@ -250,8 +249,7 @@ int of_irq_parse_raw(const __be32 *addr, struct
> of_phandle_args *out_irq)
> >* Successfully parsed an interrrupt-map translation; copy
> new
> >* interrupt specifier into the out_irq structure
> >*/
> > - of_node_put(out_irq->np);
> > - out_irq->np = of_node_get(newpar);
> > + out_irq->np = newpar;
> >
> > match_array = imap - newaddrsize - newintsize;
> > for (i = 0; i < newintsize; i++)
> > @@ -268,7 +266,6 @@ int of_irq_parse_raw(const __be32 *addr, struct
> of_phandle_args *out_irq)
> > }
> > fail:
> > of_node_put(ipar);
> > - of_node_put(out_irq->np);
> > of_node_put(newpar);
> >
> > return -EINVAL;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: give priority to the compatible match in __of_match_node()
On Wed, Feb 12, 2014 at 5:38 AM, Kevin Hao wrote:
> When the device node do have a compatible property, we definitely
> prefer the compatible match besides the type and name. Only if
> there is no such a match, we then consider the candidate which
> doesn't have compatible entry but do match the type or name with
> the device node.
>
> This is based on a patch from Sebastian Hesselbarth.
> http://patchwork.ozlabs.org/patch/319434/
>
> I did some code refactoring and also fixed a bug in the original patch.
I'm inclined to just revert this once again and avoid possibly
breaking yet another platform.
However, I think I would like to see this structured differently. We
basically have 2 ways of matching: the existing pre-3.14 way and the
desired match on best compatible only. All new bindings should match
with the new way and the old way needs to be kept for compatibility.
So lets structure the code that way. Search the match table first for
best compatible with name and type NULL, then search the table the old
way. I realize it appears you are doing this, but it is not clear this
is the intent of the code. I would like to see this written as a patch
with commit 105353145eafb3ea919 reverted first and you add a new match
function to call first and then fallback to the existing function.
Rob
>
> Cc: Sebastian Hesselbarth
> Signed-off-by: Kevin Hao
> ---
> drivers/of/base.c | 55
> +--
> 1 file changed, 37 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ff85450d5683..9d655df458bd 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -730,32 +730,45 @@ out:
> }
> EXPORT_SYMBOL(of_find_node_with_property);
>
> +static int of_match_type_or_name(const struct device_node *node,
> + const struct of_device_id *m)
> +{
> + int match = 1;
> +
> + if (m->name[0])
> + match &= node->name && !strcmp(m->name, node->name);
> +
> + if (m->type[0])
> + match &= node->type && !strcmp(m->type, node->type);
> +
> + return match;
> +}
> +
> static
> const struct of_device_id *__of_match_node(const struct of_device_id
> *matches,
>const struct device_node *node)
> {
> const char *cp;
> int cplen, l;
> + const struct of_device_id *m;
> + int match;
>
> if (!matches)
> return NULL;
>
> cp = __of_get_property(node, "compatible", &cplen);
> - do {
> - const struct of_device_id *m = matches;
> + while (cp && (cplen > 0)) {
> + m = matches;
>
> /* Check against matches with current compatible string */
> while (m->name[0] || m->type[0] || m->compatible[0]) {
> - int match = 1;
> - if (m->name[0])
> - match &= node->name
> - && !strcmp(m->name, node->name);
> - if (m->type[0])
> - match &= node->type
> - && !strcmp(m->type, node->type);
> - if (m->compatible[0])
> - match &= cp
> - && !of_compat_cmp(m->compatible, cp,
> + if (!m->compatible[0]) {
> + m++;
> + continue;
> + }
> +
> + match = of_match_type_or_name(node, m);
> + match &= cp && !of_compat_cmp(m->compatible, cp,
>
> strlen(m->compatible));
> if (match)
> return m;
> @@ -763,12 +776,18 @@ const struct of_device_id *__of_match_node(const struct
> of_device_id *matches,
> }
>
> /* Get node's next compatible string */
> - if (cp) {
> - l = strlen(cp) + 1;
> - cp += l;
> - cplen -= l;
> - }
> - } while (cp && (cplen > 0));
> + l = strlen(cp) + 1;
> + cp += l;
> + cplen -= l;
> + }
> +
> + m = matches;
> + /* Check against matches without compatible string */
> + while (m->name[0] || m->type[0] || m->compatible[0]) {
> + if (!m->compatible[0] && of_match_type_or_name(node, m))
> + return m;
> + m++;
> + }
>
> return NULL;
> }
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing
Re: [PATCH 2/2] of: search the best compatible match first in __of_match_node()
On Thu, Feb 13, 2014 at 11:22 PM, Kevin Hao wrote:
> Currently, of_match_node compares each given match against all node's
> compatible strings with of_device_is_compatible.
>
> To achieve multiple compatible strings per node with ordering from
> specific to generic, this requires given matches to be ordered from
> specific to generic. For most of the drivers this is not true and also
> an alphabetical ordering is more sane there.
>
> Therefore, this patch introduces a function to match each of the node's
> compatible strings against all given compatible matches without type and
> name first, before checking the next compatible string. This implies
> that node's compatibles are ordered from specific to generic while
> given matches can be in any order. If we fail to find such a match
> entry, then fall-back to the old method in order to keep compatibility.
>
> Cc: Sebastian Hesselbarth
> Signed-off-by: Kevin Hao
Looks good to me. I'll put this in next for a few days. I'd really
like to see some acks and tested-by's before sending to Linus.
We could be a bit more strict here and fallback to the old matching if
the match table has any entries with name or type. I don't think that
should be necessary though.
Rob
> ---
> drivers/of/base.c | 43 ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index ba195fbce4c6..10b51106c854 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -730,13 +730,49 @@ out:
> }
> EXPORT_SYMBOL(of_find_node_with_property);
>
> +static const struct of_device_id *
> +of_match_compatible(const struct of_device_id *matches,
> + const struct device_node *node)
> +{
> + const char *cp;
> + int cplen, l;
> + const struct of_device_id *m;
> +
> + cp = __of_get_property(node, "compatible", &cplen);
> + while (cp && (cplen > 0)) {
> + m = matches;
> + while (m->name[0] || m->type[0] || m->compatible[0]) {
> + /* Only match for the entries without type and name */
> + if (m->name[0] || m->type[0] ||
> + of_compat_cmp(m->compatible, cp,
> +strlen(m->compatible)))
> + m++;
> + else
> + return m;
> + }
> +
> + /* Get node's next compatible string */
> + l = strlen(cp) + 1;
> + cp += l;
> + cplen -= l;
> + }
> +
> + return NULL;
> +}
> +
> static
> const struct of_device_id *__of_match_node(const struct of_device_id
> *matches,
>const struct device_node *node)
> {
> + const struct of_device_id *m;
> +
> if (!matches)
> return NULL;
>
> + m = of_match_compatible(matches, node);
> + if (m)
> + return m;
> +
> while (matches->name[0] || matches->type[0] ||
> matches->compatible[0]) {
> int match = 1;
> if (matches->name[0])
> @@ -760,7 +796,12 @@ const struct of_device_id *__of_match_node(const struct
> of_device_id *matches,
> * @matches: array of of device match structures to search in
> * @node: the of device structure to match against
> *
> - * Low level utility function used by device matching.
> + * Low level utility function used by device matching. We have two ways
> + * of matching:
> + * - Try to find the best compatible match by comparing each compatible
> + * string of device node with all the given matches respectively.
> + * - If the above method failed, then try to match the compatible by
> using
> + * __of_device_is_compatible() besides the match in type and name.
> */
> const struct of_device_id *of_match_node(const struct of_device_id *matches,
> const struct device_node *node)
> --
> 1.8.5.3
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] devicetree: bindings: add Zarlink to the vendor prefixes
On Tue, Mar 25, 2014 at 8:41 AM, Valentin Longchamp wrote: > Even though the company belongs to Microsemi, many chips are still > labeled as Zarlink. Among them is the family of network clock generators, > the zl3034x. > > Signed-off-by: Valentin Longchamp Acked-by: Rob Herring > > --- > Changes in v3: None > Changes in v2: > - add a patch so that the Zarlink vendor prefix is defined > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 40ce2df..4a6eba0 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -95,3 +95,4 @@ winbond Winbond Electronics corp. > wlfWolfson Microelectronics > wm Wondermedia Technologies, Inc. > xlnx Xilinx > +zarlinkZarlink Semiconductor > -- > 1.8.0.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/20] FDT clean-ups and libfdt support
From: Rob Herring This is a series of clean-ups of architecture FDT code and converts the core FDT code over to using libfdt functions. This is in preparation to add FDT based address translation parsing functions for early console support. The current MIPS lantiq and xlp DT code is buggy as built-in DTBs need to be copied out of init section. Patches 2 and 3 should be applied to 3.15. A branch is available here[1]. Please test! I've compiled on arm, arm64, mips, microblaze, and powerpc and booted on arm and arm64. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git libfdt Rob Herring (20): mips: octeon: convert to use unflatten_and_copy_device_tree mips: lantiq: copy built-in DTB out of init section mips: xlp: copy built-in DTB out of init section mips: ralink: convert to use unflatten_and_copy_device_tree ARM: dt: use default early_init_dt_alloc_memory_arch c6x: convert fdt pointers to opaque pointers mips: convert fdt pointers to opaque pointers of/fdt: consolidate built-in dtb section variables of/fdt: create common debugfs of/fdt: remove some unneeded includes of/fdt: remove unused of_scan_flat_dt_by_path of/fdt: update of_get_flat_dt_prop in prep for libfdt of/fdt: Convert FDT functions to use libfdt of/fdt: use libfdt accessors for header data of/fdt: move memreserve and dtb memory reservations into core build: add libfdt include path globally powerpc: use libfdt accessors for header data x86: use libfdt accessors for header data of/fdt: convert initial_boot_params to opaque pointer of: push struct boot_param_header and defines into powerpc Makefile| 5 + arch/arc/include/asm/sections.h | 1 - arch/arc/kernel/devtree.c | 2 +- arch/arm/include/asm/prom.h | 2 - arch/arm/kernel/devtree.c | 34 +-- arch/arm/mach-exynos/exynos.c | 2 +- arch/arm/mach-vexpress/platsmp.c| 2 +- arch/arm/mm/init.c | 1 - arch/arm/plat-samsung/s5p-dev-mfc.c | 4 +- arch/arm64/mm/init.c| 21 -- arch/c6x/kernel/setup.c | 4 +- arch/metag/kernel/setup.c | 4 - arch/microblaze/kernel/prom.c | 37 +-- arch/mips/cavium-octeon/Makefile| 3 - arch/mips/cavium-octeon/setup.c | 18 +- arch/mips/include/asm/mips-boards/generic.h | 4 - arch/mips/include/asm/prom.h| 6 +- arch/mips/kernel/prom.c | 2 +- arch/mips/lantiq/prom.c | 15 +- arch/mips/lantiq/prom.h | 2 - arch/mips/mti-sead3/Makefile| 2 - arch/mips/mti-sead3/sead3-setup.c | 8 +- arch/mips/netlogic/xlp/dt.c | 17 +- arch/mips/ralink/of.c | 29 +-- arch/openrisc/kernel/vmlinux.h | 2 - arch/powerpc/include/asm/prom.h | 39 +++ arch/powerpc/kernel/epapr_paravirt.c| 2 +- arch/powerpc/kernel/fadump.c| 4 +- arch/powerpc/kernel/prom.c | 77 ++ arch/powerpc/kernel/rtas.c | 2 +- arch/powerpc/mm/hash_utils_64.c | 22 +- arch/powerpc/platforms/52xx/efika.c | 4 +- arch/powerpc/platforms/chrp/setup.c | 4 +- arch/powerpc/platforms/powernv/opal.c | 12 +- arch/powerpc/platforms/pseries/setup.c | 4 +- arch/x86/kernel/devicetree.c| 7 +- arch/xtensa/kernel/setup.c | 3 +- drivers/of/Kconfig | 1 + drivers/of/fdt.c| 379 +--- drivers/of/of_reserved_mem.c| 4 +- include/linux/of_fdt.h | 64 + lib/Makefile| 2 - 42 files changed, 261 insertions(+), 596 deletions(-) -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 09/20] of/fdt: create common debugfs
From: Rob Herring
Both powerpc and microblaze have the same FDT blob in debugfs feature.
Move this to common location and remove the powerpc and microblaze
implementations. This feature could become more useful when FDT
overlay support is added.
This changes the path of the blob from "$arch/flat-device-tree" to
"device-tree/flat-device-tree".
Signed-off-by: Rob Herring
Cc: Michal Simek
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/microblaze/kernel/prom.c | 31 ---
arch/powerpc/kernel/prom.c| 21 -
drivers/of/fdt.c | 24
3 files changed, 24 insertions(+), 52 deletions(-)
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index abdfb10..1312cd2 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -114,34 +114,3 @@ void __init early_init_devtree(void *params)
pr_debug(" <- early_init_devtree()\n");
}
-
-/***
- *
- * New implementation of the OF "find" APIs, return a refcounted
- * object, call of_node_put() when done. The device tree and list
- * are protected by a rw_lock.
- *
- * Note that property management will need some locking as well,
- * this isn't dealt with yet.
- *
- ***/
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = initial_boot_params->totalsize;
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- of_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-device_initcall(export_flat_device_tree);
-#endif
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index dd72beb..7c2f90c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -918,23 +917,3 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
{
return (int)phys_id == get_hard_smp_processor_id(cpu);
}
-
-#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
-static struct debugfs_blob_wrapper flat_dt_blob;
-
-static int __init export_flat_device_tree(void)
-{
- struct dentry *d;
-
- flat_dt_blob.data = initial_boot_params;
- flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
-
- d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
- powerpc_debugfs_root, &flat_dt_blob);
- if (!d)
- return 1;
-
- return 0;
-}
-__initcall(export_flat_device_tree);
-#endif
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index fa16a91..2085d47 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include /* for COMMAND_LINE_SIZE */
#ifdef CONFIG_PPC
@@ -1084,4 +1085,27 @@ void __init unflatten_and_copy_device_tree(void)
unflatten_device_tree();
}
+#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
+static struct debugfs_blob_wrapper flat_dt_blob;
+
+static int __init of_flat_dt_debugfs_export_fdt(void)
+{
+ struct dentry *d = debugfs_create_dir("device-tree", NULL);
+
+ if (!d)
+ return -ENOENT;
+
+ flat_dt_blob.data = initial_boot_params;
+ flat_dt_blob.size = fdt_totalsize(initial_boot_params);
+
+ d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
+ d, &flat_dt_blob);
+ if (!d)
+ return -ENOENT;
+
+ return 0;
+}
+module_init(of_flat_dt_debugfs_export_fdt);
+#endif
+
#endif /* CONFIG_OF_EARLY_FLATTREE */
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 20/20] of: push struct boot_param_header and defines into powerpc
From: Rob Herring
Now powerpc is the only user of struct boot_param_header and FDT defines,
so they can be moved into the powerpc architecture code.
Signed-off-by: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/prom.h | 39 +++
include/linux/of_fdt.h | 37 -
2 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index d977b9b..74b79f0 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -26,6 +26,45 @@
#include
#include
+#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
+#define OF_DT_END_NODE 0x2 /* End node */
+#define OF_DT_PROP 0x3 /* Property: name off, size,
+* content */
+#define OF_DT_NOP 0x4 /* nop */
+#define OF_DT_END 0x9
+
+#define OF_DT_VERSION 0x10
+
+/*
+ * This is what gets passed to the kernel by prom_init or kexec
+ *
+ * The dt struct contains the device tree structure, full pathes and
+ * property contents. The dt strings contain a separate block with just
+ * the strings for the property names, and is fully page aligned and
+ * self contained in a page, so that it can be kept around by the kernel,
+ * each property name appears only once in this page (cheap compression)
+ *
+ * the mem_rsvmap contains a map of reserved ranges of physical memory,
+ * passing it here instead of in the device-tree itself greatly simplifies
+ * the job of everybody. It's just a list of u64 pairs (base/size) that
+ * ends when size is 0
+ */
+struct boot_param_header {
+ __be32 magic; /* magic word OF_DT_HEADER */
+ __be32 totalsize; /* total size of DT block */
+ __be32 off_dt_struct; /* offset to structure */
+ __be32 off_dt_strings; /* offset to strings */
+ __be32 off_mem_rsvmap; /* offset to memory reserve map */
+ __be32 version;/* format version */
+ __be32 last_comp_version; /* last compatible version */
+ /* version 2 fields below */
+ __be32 boot_cpuid_phys;/* Physical CPU id we're booting on */
+ /* version 3 fields below */
+ __be32 dt_strings_size;/* size of the DT strings block */
+ /* version 17 fields below */
+ __be32 dt_struct_size; /* size of the DT structure block */
+};
+
/*
* OF address retreival & translation
*/
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index aa7fb87..7f67790 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -17,47 +17,10 @@
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
-#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
-#define OF_DT_END_NODE 0x2 /* End node */
-#define OF_DT_PROP 0x3 /* Property: name off, size,
-* content */
-#define OF_DT_NOP 0x4 /* nop */
-#define OF_DT_END 0x9
-
-#define OF_DT_VERSION 0x10
#ifndef __ASSEMBLY__
#include
-/*
- * This is what gets passed to the kernel by prom_init or kexec
- *
- * The dt struct contains the device tree structure, full pathes and
- * property contents. The dt strings contain a separate block with just
- * the strings for the property names, and is fully page aligned and
- * self contained in a page, so that it can be kept around by the kernel,
- * each property name appears only once in this page (cheap compression)
- *
- * the mem_rsvmap contains a map of reserved ranges of physical memory,
- * passing it here instead of in the device-tree itself greatly simplifies
- * the job of everybody. It's just a list of u64 pairs (base/size) that
- * ends when size is 0
- */
-struct boot_param_header {
- __be32 magic; /* magic word OF_DT_HEADER */
- __be32 totalsize; /* total size of DT block */
- __be32 off_dt_struct; /* offset to structure */
- __be32 off_dt_strings; /* offset to strings */
- __be32 off_mem_rsvmap; /* offset to memory reserve map */
- __be32 version;/* format version */
- __be32 last_comp_version; /* last compatible version */
- /* version 2 fields below */
- __be32 boot_cpuid_phys;/* Physical CPU id we're booting on */
- /* version 3 fields below */
- __be32 dt_strings_size;/* size of the DT strings block */
- /* version 17 fields below */
- __be32 dt_struct_size; /* size of the DT structure blo
Re: [PATCH 09/20] of/fdt: create common debugfs
On Fri, Apr 4, 2014 at 7:16 AM, Michal Simek wrote:
> On 04/04/2014 12:16 AM, Rob Herring wrote:
>> From: Rob Herring
>>
>> Both powerpc and microblaze have the same FDT blob in debugfs feature.
>> Move this to common location and remove the powerpc and microblaze
>> implementations. This feature could become more useful when FDT
>> overlay support is added.
>>
>> This changes the path of the blob from "$arch/flat-device-tree" to
>> "device-tree/flat-device-tree".
[snip]
>> -#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
>> -static struct debugfs_blob_wrapper flat_dt_blob;
>> -
>> -static int __init export_flat_device_tree(void)
>> -{
>> - struct dentry *d;
>> -
>> - flat_dt_blob.data = initial_boot_params;
>> - flat_dt_blob.size = initial_boot_params->totalsize;
>
> As I see even microblaze version was buggy.
How so?
> ...
>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index fa16a91..2085d47 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include /* for COMMAND_LINE_SIZE */
>> #ifdef CONFIG_PPC
>> @@ -1084,4 +1085,27 @@ void __init unflatten_and_copy_device_tree(void)
>> unflatten_device_tree();
>> }
>>
>> +#if defined(CONFIG_DEBUG_FS) && defined(DEBUG)
>> +static struct debugfs_blob_wrapper flat_dt_blob;
>> +
>> +static int __init of_flat_dt_debugfs_export_fdt(void)
>> +{
>> + struct dentry *d = debugfs_create_dir("device-tree", NULL);
>> +
>> + if (!d)
>> + return -ENOENT;
>> +
>> + flat_dt_blob.data = initial_boot_params;
>> + flat_dt_blob.size = fdt_totalsize(initial_boot_params);
>
> Have you tried to compile this?
>
> From my tests fdt_totalsize is not available for target just for host
> from libfdt.h
>
> drivers/of/fdt.c: In function 'of_flat_dt_debugfs_export_fdt':
> drivers/of/fdt.c:957:2: error: implicit declaration of function
> 'fdt_totalsize' [-Werror=implicit-function-declaration]
Ah, it needs to be re-ordered after the libfdt conversion when
libfdt.h gets added.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 09/20] of/fdt: create common debugfs
On Fri, Apr 4, 2014 at 8:22 AM, Michal Simek wrote:
> On 04/04/2014 03:00 PM, Rob Herring wrote:
>> On Fri, Apr 4, 2014 at 7:16 AM, Michal Simek wrote:
>>> On 04/04/2014 12:16 AM, Rob Herring wrote:
>>>> From: Rob Herring
>>>>
>>>> Both powerpc and microblaze have the same FDT blob in debugfs feature.
>>>> Move this to common location and remove the powerpc and microblaze
>>>> implementations. This feature could become more useful when FDT
>>>> overlay support is added.
>>
>> [snip]
> Anyway I am testing it for microblaze and getting problem
> caused by this patch:
> commit 3d2ee8571ac0580d49c3f41fa28336289934900a
> Author: Rob Herring
> Date: Wed Apr 2 15:10:14 2014 -0500
>
> of/fdt: Convert FDT functions to use libfdt
>
> And reason is that in unflatten_dt_node()
>
> pathp = fdt_get_name(blob, *poffset, &l);
>
> is returning NULL
> and here
> /* version 0x10 has a more compact unit name here instead of the full
> * path. we accumulate the full path size using "fpsize", we'll
> rebuild
> * it later. We detect this because the first character of the name is
> * not '/'.
> */
> if ((*pathp) != '/') {
>
> code is trying to read it which is causing this kernel bug:
> Oops: kernel access of bad area, sig: 11
>
> It means fdt_next_node(is doing something wrong)
>
> Any easy way how to debug it?
I didn't think fdt_get_path should fail. Can you add a print of
*poffset and pathp values.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 09/20] of/fdt: create common debugfs
On Fri, Apr 4, 2014 at 9:11 AM, Michal Simek wrote:
> On 04/04/2014 03:32 PM, Rob Herring wrote:
>> On Fri, Apr 4, 2014 at 8:22 AM, Michal Simek wrote:
>>> On 04/04/2014 03:00 PM, Rob Herring wrote:
>>>> On Fri, Apr 4, 2014 at 7:16 AM, Michal Simek wrote:
>>>>> On 04/04/2014 12:16 AM, Rob Herring wrote:
>>>>>> From: Rob Herring
>>>>>>
>>>>>> Both powerpc and microblaze have the same FDT blob in debugfs feature.
>>>>>> Move this to common location and remove the powerpc and microblaze
>>>>>> implementations. This feature could become more useful when FDT
>>>>>> overlay support is added.
>>>>
>>>> [snip]
>>
>>> Anyway I am testing it for microblaze and getting problem
>>> caused by this patch:
>>> commit 3d2ee8571ac0580d49c3f41fa28336289934900a
>>> Author: Rob Herring
>>> Date: Wed Apr 2 15:10:14 2014 -0500
>>>
>>> of/fdt: Convert FDT functions to use libfdt
>>>
>>> And reason is that in unflatten_dt_node()
>>>
>>> pathp = fdt_get_name(blob, *poffset, &l);
>>>
>>> is returning NULL
>>> and here
>>> /* version 0x10 has a more compact unit name here instead of the
>>> full
>>> * path. we accumulate the full path size using "fpsize", we'll
>>> rebuild
>>> * it later. We detect this because the first character of the name
>>> is
>>> * not '/'.
>>> */
>>> if ((*pathp) != '/') {
>>>
>>> code is trying to read it which is causing this kernel bug:
>>> Oops: kernel access of bad area, sig: 11
>>>
>>> It means fdt_next_node(is doing something wrong)
>>>
>>> Any easy way how to debug it?
>>
>> I didn't think fdt_get_path should fail. Can you add a print of
>> *poffset and pathp values.
I think I've fixed this now and updated the branch. Please test again
when you have a chance.
Thanks,
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
On Tue, Apr 8, 2014 at 7:44 PM, Scott Wood wrote: > On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote: >> These are the bindings for 2 MFD devices used on some of the Keymile boards. >> The first one is the chassis managmenet bfticu FPGA. >> The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL. >> These FPGAs are used in the kmcoge4 board. >> >> This patch also add KEYMILE to the vendor-prefixes. You can drop the keymile addition. I have that queued up. [snip] >> +Required properties: >> +- compatible: "keymile,bfticu" >> +- interrupt-controller: the bfticu FPGA is an interrupt controller >> +- interrupts: the main IRQ line to signal the collected IRQs >> +- #interrupt-cells : is 2 >> + - The 1st cell is the local IRQ number on the bfticu >> + - The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx) > > Device tree bindings should not depend on the content of Linux headers. > One is stable ABI, and the other isn't. > > If you want you can make the values the same for convenience, as is done > by IPIC, CPM PIC, etc -- but the values need to be explicitly stated in > the binding. It'll still break if the Linux values change (so it may > not be a good idea to try to keep the values the same), but at least the > fix would be in Linux code rather than an ABI change. You can simply refer to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm wrote: > drivers/of/fdt.c contains a workaround for a missing memory type > entry on longtrail firmware. Make that quirk PPC32 only, and while > at it - fix up the .dts files in the tree currently working only > because of that quirk. But why do you need this? > > Cc: devicet...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-ker...@vger.kernel.org > Cc: Mark Rutland > > Leif Lindholm (3): > arm: dts: add device_type="memory" for ste-ccu8540 > mips: dts: add device_type="memory" where missing > of: Handle memory@0 node on PPC32 only > > arch/arm/boot/dts/ste-ccu8540.dts |1 + > arch/mips/lantiq/dts/easy50712.dts|1 + > arch/mips/ralink/dts/mt7620a_eval.dts |1 + > arch/mips/ralink/dts/rt2880_eval.dts |1 + > arch/mips/ralink/dts/rt3052_eval.dts |1 + > arch/mips/ralink/dts/rt3883_eval.dts |1 + I'm not worried about these MIPS dts files because they are all built-in, but you are breaking compatibility with old dtbs for this ARM board. Rob > drivers/of/fdt.c |7 ++- > 7 files changed, 12 insertions(+), 1 deletion(-) > > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/16] PCI generic configuration space accessors
On Thu, Jan 22, 2015 at 3:03 PM, Bjorn Helgaas wrote: > On Fri, Jan 09, 2015 at 08:34:34PM -0600, Rob Herring wrote: >> This series adds common accessor functions for PCI configuration space >> accesses. This supports most PCI hosts with memory mapped configuration >> space like ECAM or hosts with memory mapped address/data registers. ECAM >> is not generically supported by this series, but could be added on top >> of this. While some hosts have standard address decoding which could be >> common as well, the various checks on bus numbers and device numbers are >> quite varied. It is unclear how much of that is really necessary or >> could be common. >> >> The first 4 patches are preparatory cleanup. Patch 5 introduces the >> common accessors. The remaining patches convert several PCI host >> controllers. This is in no way a complete list of host controllers. The >> conversion of more hosts should be possible. The Designware controller >> in particular should be able to be converted, but its config space >> accessors are a mess of override-able functions that I've not gotten my >> head around. [...] > Really nice cleanups. I added these with the acks so far to a pci/config > branch for v3.20. I'll update it with more acks if they trickle in. Thanks. > You've structured it nicely so I can also just drop individual arch pieces > if necessary. The pieces that haven't been acked yet (hint, hint): > > arch/arm/mach-cns3xxx/pcie.c > arch/arm/mach-sa1100/pci-nanoengine.c Some ARM sub-arch maintainers tend to not respond on things. These are platforms which aren't very active and aren't going to move to drivers/pci/host/ anytime soon. Maybe Arnd wants to ack them. > arch/mn10300/unit-asb2305/pci.c > arch/powerpc > > In addition, nobody has acked the frv and mips parts, but they're trivial > (they only add struct member names) that I can apply them without worrying. You must pick-up the 4 clean-up ones or the build will break for those platforms. Or perhaps that will encourage some acks. I've also got some actual conversions for some MIPS platforms in my tree I haven't sent out yet. MIPS is fun with all the variety of endianness and h/w swapping capability or not. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 16/29] powerpc/pci: Use pci_scan_host_bridge() for simplicity
On Fri, Mar 6, 2015 at 3:33 AM, Yijing Wang wrote:
> Now we could use pci_scan_host_bridge() to scan
> pci buses, provide powerpc specific pci_host_bridge_ops.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Yijing Wang
> CC: Benjamin Herrenschmidt
> CC: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Bjorn Helgaas
> ---
> arch/powerpc/include/asm/machdep.h |2 +-
> arch/powerpc/kernel/pci-common.c | 63
> ++
> arch/powerpc/platforms/pseries/pci.c |8 ++--
> arch/powerpc/platforms/pseries/pseries.h |2 +-
> 4 files changed, 44 insertions(+), 31 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/machdep.h
> b/arch/powerpc/include/asm/machdep.h
> index 8e7f2a8..b811d12 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -129,7 +129,7 @@ struct machdep_calls {
> void(*pcibios_fixup)(void);
> int (*pci_probe_mode)(struct pci_bus *);
> void(*pci_irq_fixup)(struct pci_dev *dev);
> - int (*pcibios_set_root_bus_speed)(struct pci_host_bridge
> + void(*pcibios_set_root_bus_speed)(struct pci_host_bridge
> *bridge);
Shouldn't this be part of patch 15?
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/5] of/fdt: split off FDT self reservation from memreserve processing
On Wed, Mar 11, 2015 at 11:00 AM, Ard Biesheuvel
wrote:
> This splits off the reservation of the memory occupied by the FDT
> binary itself from the processing of the memory reservations it
> contains. This is necessary because the physical address of the FDT,
> which is needed to perform the reservation, may not be known to the
> FDT driver core, i.e., it may be mapped outside the linear direct
> mapping, in which case __pa() returns a bogus value.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Signed-off-by: Ard Biesheuvel
Not really the direction I like going by moving more things back to
arch code, but I haven't come up with any better suggestion so:
Acked-by: Rob Herring
BTW, I do want to move early_init_fdt_scan_reserved_mem out of the
arch code as well. Other arches don't call it, but it should be
harmless if they never use the reserved memory regions.
Rob
> ---
> arch/arm/mm/init.c | 1 +
> arch/arm64/mm/init.c | 1 +
> arch/powerpc/kernel/prom.c | 1 +
> drivers/of/fdt.c | 19 ++-
> include/linux/of_fdt.h | 2 ++
> 5 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 1609b022a72f..0b8657c36fe4 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -317,6 +317,7 @@ void __init arm_memblock_init(const struct machine_desc
> *mdesc)
> if (mdesc->reserve)
> mdesc->reserve();
>
> + early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem();
>
> /* reserve memory for DMA contiguous allocations */
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index ae85da6307bb..fa2389b0f7f0 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -170,6 +170,7 @@ void __init arm64_memblock_init(void)
> memblock_reserve(__virt_to_phys(initrd_start), initrd_end -
> initrd_start);
> #endif
>
> + early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem();
>
> /* 4GB maximum for 32-bit only capable devices */
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index b8e15c678960..093ccfb384af 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -573,6 +573,7 @@ static void __init early_reserve_mem_dt(void)
> int len;
> const __be32 *prop;
>
> + early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem();
>
> dt_root = of_get_flat_dt_root();
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 3a896c9aeb74..bbb35cdb06e8 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -561,11 +561,6 @@ void __init early_init_fdt_scan_reserved_mem(void)
> if (!initial_boot_params)
> return;
>
> - /* Reserve the dtb region */
> - early_init_dt_reserve_memory_arch(__pa(initial_boot_params),
> - fdt_totalsize(initial_boot_params),
> - 0);
> -
> /* Process header /memreserve/ fields */
> for (n = 0; ; n++) {
> fdt_get_mem_rsv(initial_boot_params, n, &base, &size);
> @@ -579,6 +574,20 @@ void __init early_init_fdt_scan_reserved_mem(void)
> }
>
> /**
> + * early_init_fdt_reserve_self() - reserve the memory used by the FDT blob
> + */
> +void __init early_init_fdt_reserve_self(void)
> +{
> + if (!initial_boot_params)
> + return;
> +
> + /* Reserve the dtb region */
> + early_init_dt_reserve_memory_arch(__pa(initial_boot_params),
> + fdt_totalsize(initial_boot_params),
> + 0);
> +}
> +
> +/**
> * of_scan_flat_dt - scan flattened tree blob and call callback on each.
> * @it: callback function
> * @data: context data pointer
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index 0ff360d5b3b3..6ef6b33238d3 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -62,6 +62,7 @@ extern int early_init_dt_scan_chosen(unsigned long node,
> const char *uname,
> extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
> int depth, void *data);
> extern void early_init_fdt_scan_reserved_mem(void);
> +extern void early_init_fdt_reserve_self(void);
> extern void early_init_dt_add_memory_arch(u64 base, u64 size);
> extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t
> size,
> bool no_map);
> @@ -89,6 +90,7 @@ exte
Re: [PATCH] Revert "of: Fix premature bootconsole disable with 'stdout-path'"
On Tue, Mar 17, 2015 at 11:47 PM, Michael Ellerman wrote: > On Tue, 2015-03-17 at 16:46 -0400, Peter Hurley wrote: >> This reverts commit 2fa645cb2703d9b3786d850db815414dfeefa51d. >> >> The assumption that at least 1 preferred console will be registered >> when the stdout-path property is set is invalid, which can result >> in _no_ consoles. >> >> Signed-off-by: Peter Hurley > > Grant/Rob, in case you didn't see it, this has caused a panic on at least one > powerpc box. So would be nice if it could go in for 4.0. Yes, I'm well aware of it and it will go in this week. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 40/45] drivers/of: Split unflatten_dt_node()
On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan wrote: > The function unflatten_dt_node() is called recursively to unflatten > device nodes and properties in the FDT blob. It looks complicated > and hard to be understood. > > This splits the function into 3 functions: populate_properties(), > populate_node() and unflatten_dt_node(). populate_properties(), > which is called by populate_node(), creates properties for the > indicated device node. The later one creates the device nodes > from FDT blob. populate_node() gets the offset in FDT blob for > next device nodes and then calls populate_node(). No logical > changes introduced. > > Signed-off-by: Gavin Shan > --- > drivers/of/fdt.c | 249 > --- > 1 file changed, 147 insertions(+), 102 deletions(-) One nit, otherwise: Acked-by: Rob Herring [...] > + /* And we process the "ibm,phandle" property > +* used in pSeries dynamic device tree > +* stuff > +*/ > + if (!strcmp(pname, "ibm,phandle")) > + np->phandle = be32_to_cpup(val); > + > + pp->name = (char *)pname; > + pp->length = sz; > + pp->value = (__be32 *)val; This cast should not be needed. > + *pprev = pp; > + pprev = &pp->next; > + } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 41/45] drivers/of: Avoid recursively calling unflatten_dt_node()
On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan wrote: > In current implementation, unflatten_dt_node() is called recursively > to unflatten device nodes in FDT blob. It's stress to limited stack > capacity, especially to adopt the function to unflatten device sub-tree > that possibly has multiple root nodes. In that case, we runs out of > stack and the system can't boot up successfully. > > In order to reuse the function to unflatten device sub-tree, this avoids > calling the function recursively, meaning the device nodes are unflattened > in one call on unflatten_dt_node(): two arrays are introduced to track the > parent path size and the device node of current level of depth, which will > be used by the device node on next level of depth to be unflattened. All > device nodes in more than 64 level of depth are dropped and hopefully, > the system can boot up successfully with the partial device-tree. > > Also, the parameter "poffset" and "fpsize" are unused and dropped and the > parameter "dryrun" is figured out from "mem == NULL". Besides, the return > value of the function is changed to indicate the size of memory consumed by > the unflatten device tree or error code. > > Signed-off-by: Gavin Shan > --- > drivers/of/fdt.c | 122 > +++++++++-- > 1 file changed, 74 insertions(+), 48 deletions(-) Acked-by: Rob Herring ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 42/45] drivers/of: Rename unflatten_dt_node()
On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan wrote: > This renames unflatten_dt_node() to unflatten_dt_nodes() as it > populates multiple device nodes from FDT blob. No logical changes > introduced. > > Signed-off-by: Gavin Shan > --- > drivers/of/fdt.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) Acked-by: Rob Herring I'm happy to take patches 40-42 for 4.6 if the rest of the series doesn't go in given they fix a separate problem. I just need to know soon (or at least they need to go into -next soon). Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 43/45] drivers/of: Specify parent node in of_fdt_unflatten_tree()
On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan wrote: > This adds one more argument to of_fdt_unflatten_tree() to specify > the parent node of the FDT blob that is going to be unflattened. > In the result, the function can be used to unflatten FDT blob that > represents device sub-tree in PowerNV PCI hotplug driver. > > Cc: Jyri Sarha > Signed-off-by: Gavin Shan > --- > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 2 +- > drivers/of/fdt.c | 14 ++ > drivers/of/unittest.c| 2 +- > include/linux/of_fdt.h | 1 + > 4 files changed, 13 insertions(+), 6 deletions(-) Acked-by: Rob Herring ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/7] QE: Add IC, SI and SIRAM document to device tree bindings.
On Thu, Feb 18, 2016 at 09:06:06AM +0800, Zhao Qiang wrote: > Add IC, SI and SIRAM document of QE to > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt > > Signed-off-by: Zhao Qiang > --- > Changes for v2 > - Add interrupt-controller in Required properties > - delete address-cells and size-cells for qe-si and qe-siram > > .../devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt | 50 > ++ > 1 file changed, 50 insertions(+) > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt > b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt > index 4f89302..84052a7 100644 > --- a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt > +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt > @@ -69,6 +69,56 @@ Example: > }; > }; > > +* Interrupt Controller (IC) > + > +Required properties: > +- compatible : should be "fsl,qe-ic". > +- compatible : should be "fsl,qe-si". > +- compatible : should be "fsl,qe-siram". These compatible strings are all a bit generic and should have SoC specific compatible strings. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/7] QE: Add ucc hdlc document to bindings
On Thu, Feb 18, 2016 at 09:06:07AM +0800, Zhao Qiang wrote:
> Add ucc hdlc document to
> Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
Not a very useful description.
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2
> - use ucc-hdlc instead of ucc_hdlc
> - add more information to properties.
>
> .../bindings/powerpc/fsl/cpm_qe/network.txt| 93
> ++
> 1 file changed, 93 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
> index 29b28b8..936158c 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
> @@ -41,3 +41,96 @@ Example:
> fsl,mdio-pin = <12>;
> fsl,mdc-pin = <13>;
> };
> +
> +* HDLC
> +
> +Currently defined compatibles:
> +- fsl,ucc-hdlc
> +
> +Properties for fsl,ucc-hdlc:
> +- rx-clock-name
> +- tx-clock-name
> + Usage: required
> + Value type:
> + Definition : should be "brg1"-"brg16" for internal clock source,
> + should be "clk1"-"clk28" for external clock source.
> +
> +- fsl,rx-sync-clock
> + Usage: required
> + Value type:
> + Definition : should be "none" when using internal clock source,
> + should be "rsync_pin" when using external clock source.
Why not a boolean property here?
> +
> +- fsl,tx-sync-clock
> + Usage: required
> + Value type:
> + Definition : should be "none" when using internal clock source,
> + should be "tsync_pin" when using external clock source.
And here.
> +
> +- fsl,tx-timeslot
> +- fsl,rx-timeslot
Perhaps append "-mask"
> + Usage: required
> + Value type:
> + Definition : time slot for TDM operation. Indicates which time slots
> + used for transmitting and receiving.
> +
> +- fsl,tdm-framer-type
> + Usage: required
> + Value type:
> + Definition : "e1" or "t1"
Boolean?
> +
> +- fsl,tdm-mode
> + Usage: required
> + Value type:
> + Definition : "normal" or "internal-loopback"
Boolean?
> +
> +- fsl,tdm-id
> + Usage: required
> + Value type:
> + Definition : number of TDM ID
> +
> +- fsl,siram-entry-id
> + Usage: required
> + Value type:
> + Definition : should be 0,2,4...64. the number of TDM entry.
> +
> +- fsl,tdm-interface
> + Usage: optional
> + Value type:
> + Definition : Specify that hdlc is based on tdm-interface
> +
> +Example:
> +
> + ucc@2000 {
> + compatible = "fsl,ucc-hdlc";
> + rx-clock-name = "clk8";
> + tx-clock-name = "clk9";
> + fsl,rx-sync-clock = "rsync_pin";
> + fsl,tx-sync-clock = "tsync_pin";
> + fsl,tx-timeslot = <0xfffe>;
> + fsl,rx-timeslot = <0xfffe>;
> + fsl,tdm-framer-type = "e1";
> + fsl,tdm-mode = "normal";
> + fsl,tdm-id = <0>;
> + fsl,siram-entry-id = <0>;
> + fsl,tdm-interface;
> + };
> +fsl,siram-entry-id : SI RAM entry ID for the TDM
> +fsl,tdm-interface : hdlc is based on tdm-interface
Should be deleted?
> +
> +Example:
> +
> + ucc@2000 {
> + compatible = "fsl,ucc-hdlc";
> + rx-clock-name = "clk8";
> + tx-clock-name = "clk9";
> + fsl,rx-sync-clock = "rsync_pin";
> + fsl,tx-sync-clock = "tsync_pin";
> + fsl,tx-timeslot = <0xfffe>;
> + fsl,rx-timeslot = <0xfffe>;
> + fsl,tdm-framer-type = "e1";
> + fsl,tdm-mode = "normal";
> + fsl,tdm-id = <0>;
> + fsl,siram-entry-id = <0>;
> + fsl,tdm-interface;
> + };
> --
> 2.1.0.27.g96db324
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/7] QE: Add uqe_serial document to bindings
On Thu, Feb 18, 2016 at 09:06:08AM +0800, Zhao Qiang wrote:
> Add uqe_serial document to
> Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2
> - modify tx/rx-clock-name specification
>
> .../bindings/powerpc/fsl/cpm_qe/uqe_serial.txt| 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
>
> diff --git
> a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> new file mode 100644
> index 000..436c71c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> @@ -0,0 +1,19 @@
> +* Serial
> +
> +Currently defined compatibles:
> +- ucc_uart
> +
> +Properties for ucc_uart:
> +port-number : port number of UCC-UART
How is this used?
> +tx/rx-clock-name : should be "brg1"-"brg16" for internal clock source,
> +should be "clk1"-"clk28" for external clock source.
Perhaps you should be using the clock binding here and in other
bindings?
> +
> +Example:
> +
> + ucc_serial: ucc@2200 {
> + device_type = "serial";
> + compatible = "ucc_uart";
> + port-number = <1>;
> + rx-clock-name = "brg2";
> + tx-clock-name = "brg2";
> + };
> --
> 2.1.0.27.g96db324
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/7] bindings: move cpm_qe binding from powerpc/fsl to soc/fsl
On Thu, Feb 18, 2016 at 09:06:09AM +0800, Zhao Qiang wrote:
> cpm_qe is supported on both powerpc and arm.
> and the QE code has been moved from arch/powerpc into
> drivers/soc/fsl, so move cpm_qe binding from powerpc/fsl
> to soc/fsl
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2
> - new added
>
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/cpm.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/cpm/brg.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/cpm/i2c.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/cpm/pic.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/cpm/usb.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/gpio.txt| 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/network.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/qe.txt | 0
> .../devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/qe/firmware.txt | 0
> .../devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/qe/par_io.txt | 0
> .../devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/qe/pincfg.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/qe/ucc.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/qe/usb.txt | 0
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/serial.txt | 0
> .../devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/uqe_serial.txt| 0
> 15 files changed, 0 insertions(+), 0 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/cpm.txt
> (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/cpm/brg.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/cpm/i2c.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/cpm/pic.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/cpm/usb.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/gpio.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/network.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/cpm_qe/qe.txt
> (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/qe/firmware.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/qe/par_io.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/qe/pincfg.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/qe/ucc.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/qe/usb.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/serial.txt (100%)
> rename Documentation/devicetree/bindings/{powerpc =>
> soc}/fsl/cpm_qe/uqe_serial.txt (100%)
Acked-by: Rob Herring
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 42/45] drivers/of: Rename unflatten_dt_node()
On Thu, Feb 18, 2016 at 9:16 PM, Gavin Shan wrote: > On Wed, Feb 17, 2016 at 08:59:53AM -0600, Rob Herring wrote: >>On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan wrote: >>> This renames unflatten_dt_node() to unflatten_dt_nodes() as it >>> populates multiple device nodes from FDT blob. No logical changes >>> introduced. >>> >>> Signed-off-by: Gavin Shan >>> --- >>> drivers/of/fdt.c | 14 +++--- >>> 1 file changed, 7 insertions(+), 7 deletions(-) >> >>Acked-by: Rob Herring >> >>I'm happy to take patches 40-42 for 4.6 if the rest of the series >>doesn't go in given they fix a separate problem. I just need to know >>soon (or at least they need to go into -next soon). >> > > Thanks for quick response, Rob. It depends how much comments I will > receive for the powerpc/powernv part. Except that, all parts including > this one have been ack'ed. I can discuss it with Michael Ellerman. > By the way, how soon you need the decision to merge 40-42? If that's > one or two weeks later, I don't think the reivew on the whole series > can be done. Well, it's been 2 weeks now. I need to know this week. > Also, I think you probably can merge 40-44 as they're all about > fdt.c. If they can be merged at one time, I needn't bother (cc) > you again if I need send a updated revision. Thanks for your > review. I did not include 43 and 44 as they are only needed for the rest of your series. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/7] QE: Add IC, SI and SIRAM document to device tree bindings.
On Tue, Mar 01, 2016 at 03:09:37PM +0800, Zhao Qiang wrote: > Add IC, SI and SIRAM document of QE to > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt > > Signed-off-by: Zhao Qiang > --- > Changes for v2 > - Add interrupt-controller in Required properties > - delete address-cells and size-cells for qe-si and qe-siram > Changes for v3 > - Add SoC specific caompatible strings to qe-si and qe-siram > > .../devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt | 50 > ++ > 1 file changed, 50 insertions(+) Acked-by: Rob Herring ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 2/7] QE: Add ucc hdlc document to bindings
On Tue, Mar 01, 2016 at 03:09:38PM +0800, Zhao Qiang wrote: > Add ucc hdlc document to > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt > > Signed-off-by: Zhao Qiang > --- > Changes for v2 > - use ucc-hdlc instead of ucc_hdlc > - add more information to properties. > Changes for v3 > - use fsl,tx-timeslot-mask instead of fsl,tx-timeslot > - use fsl,rx-timeslot-mask instead of fsl,rx-timeslot > - add more info > > .../bindings/powerpc/fsl/cpm_qe/network.txt| 81 > ++ > 1 file changed, 81 insertions(+) Acked-by: Rob Herring ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/7] QE: Add uqe_serial document to bindings
On Tue, Mar 01, 2016 at 03:09:39PM +0800, Zhao Qiang wrote:
> Add uqe_serial document to
> Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2
> - modify tx/rx-clock-name specification
> Changes for v2
> - NA
>
> .../bindings/powerpc/fsl/cpm_qe/uqe_serial.txt| 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
>
> diff --git
> a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> new file mode 100644
> index 000..436c71c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> @@ -0,0 +1,19 @@
> +* Serial
> +
> +Currently defined compatibles:
> +- ucc_uart
I guess this is in use already and okay. However, looking at the driver
there really should be SoC specific compatible strings here since the
driver is looking up the SoC compatible string and composing the
firmware filename from that.
> +
> +Properties for ucc_uart:
> +port-number : port number of UCC-UART
> +tx/rx-clock-name : should be "brg1"-"brg16" for internal clock source,
> +should be "clk1"-"clk28" for external clock source.
> +
> +Example:
> +
> + ucc_serial: ucc@2200 {
> + device_type = "serial";
Drop device_type. It should only be used in a few legacy cases.
Looks like the driver is matching on this. Please drop it from the
driver too. I'd leave dts files for now, but they should be updated too
later.
> + compatible = "ucc_uart";
> + port-number = <1>;
> + rx-clock-name = "brg2";
> + tx-clock-name = "brg2";
> + };
> --
> 2.1.0.27.g96db324
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] bindings: move cpm_qe binding from powerpc/fsl to soc/fsl
On Tue, Mar 01, 2016 at 03:09:40PM +0800, Zhao Qiang wrote: > cpm_qe is supported on both powerpc and arm. > and the QE code has been moved from arch/powerpc into > drivers/soc/fsl, so move cpm_qe binding from powerpc/fsl > to soc/fsl > > Signed-off-by: Zhao Qiang > --- I already acked this. In the future, please add acks on subsequent revs. Acked-by: Rob Herring ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
On Mon, Mar 14, 2016 at 05:45:43PM +, Scott Wood wrote:
> On 03/14/2016 02:29 AM, Yangbo Lu wrote:
> >> -Original Message-
> >> From: Arnd Bergmann [mailto:a...@arndb.de]
> >> Sent: Monday, March 14, 2016 6:26 AM
> >> To: linuxppc-dev@lists.ozlabs.org
> >> Cc: Yangbo Lu; devicet...@vger.kernel.org; linux-arm-
> >> ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
> >> c...@vger.kernel.org; linux-...@vger.kernel.org; iommu@lists.linux-
> >> foundation.org; net...@vger.kernel.org; linux-...@vger.kernel.org;
> >> ulf.hans...@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma; Joerg
> >> Roedel; Santosh Shilimkar; Scott Wood; Rob Herring; Claudiu Manoil; Kumar
> >> Gala; Yang-Leo Li; Xiaobo Xie
> >> Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-
> >> R1.0-R2.0
> >>
> >> On Wednesday 09 March 2016 18:08:51 Yangbo Lu wrote:
> >>> @@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device
> >> *pdev, struct sdhci_host *host)
> >>> struct sdhci_pltfm_host *pltfm_host;
> >>> struct sdhci_esdhc *esdhc;
> >>> u16 host_ver;
> >>> + u32 svr;
> >>>
> >>> pltfm_host = sdhci_priv(host);
> >>> esdhc = sdhci_pltfm_priv(pltfm_host);
> >>>
> >>> + fsl_guts_init();
> >>> + svr = fsl_guts_get_svr();
> >>> + if (svr) {
> >>> + esdhc->soc_ver = SVR_SOC_VER(svr);
> >>> + esdhc->soc_rev = SVR_REV(svr);
> >>> + } else {
> >>> + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> >>> + }
> >>> +
> >>
> >> This makes the driver non-portable. Better identify the specific
> >> workarounds based on the compatible string for this device, or add a
> >> boolean DT property for the quirk.
> >>
> >>Arnd
> >
> > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1
> > before.
> > https://patchwork.kernel.org/patch/6834221/
> >
> > We don’t have a separate DTS file for each revision of an SOC and if we
> > did, we'd constantly have people using the wrong one.
> > In addition, the device tree is stable ABI and errata are often discovered
> > after device tree are deployed.
> > See the link for details.
> >
> > So we decide to read SVR from the device-config/guts MMIO block other than
> > using DTS.
> > Thanks.
>
> Also note that this driver is already only for fsl-specific hardware,
> and it will still work even if fsl_guts doesn't find anything to bind to
> -- it just wouldn't be able to detect errata based on SVR in that case.
IIRC, it is the same IP block as i.MX and Arnd's point is this won't
even compile on !PPC. It is things like this that prevent sharing the
driver. Dealing with Si revs is a common problem. We should have a
common solution. There is soc_device for this purpose.
OTOH, the integration differences may be enough that trying to have a
common driver with i.MX would not be worth it.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 3/7] QE: Add uqe_serial document to bindings
On Wed, Mar 09, 2016 at 09:21:30AM +0800, Zhao Qiang wrote: > Add uqe_serial document to > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt > > Signed-off-by: Zhao Qiang > --- > Changes for v2 > - modify tx/rx-clock-name specification > Changes for v3 > - NA > Changes for v4 > - drop device_type > - modify to SoC specific compatible > Changes for v5 > - add fsl to compatible as prefix > > .../bindings/powerpc/fsl/cpm_qe/uqe_serial.txt | 18 > ++ > 1 file changed, 18 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt Acked-by: Rob Herring ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory
On Thu, Mar 17, 2016 at 12:11 PM, Arnd Bergmann wrote: > On Thursday 17 March 2016 12:06:40 Rob Herring wrote: >> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt >> > b/Documentation/devicetree/bindings/soc/fsl/guts.txt >> > similarity index 91% >> > rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt >> > rename to Documentation/devicetree/bindings/soc/fsl/guts.txt >> > index b71b203..07adca9 100644 >> > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt >> > +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt >> > @@ -25,6 +25,9 @@ Recommended properties: >> > - fsl,liodn-bits : Indicates the number of defined bits in the LIODN >> > registers, for those SOCs that have a PAMU device. >> > >> > + - little-endian : Indicates that the global utilities block is little >> > + endian. The default is big endian. >> >> The default is "the native endianness of the system". > > This may be what is currently documented, but not what we are doing > in practice, as there is no "native endianess" for either PowerPC or > ARM -- both allow running big-endian or little-endian kernels and the > device registers are fixed. Notice I said system, not architecture. The way the device registers are fixed is what I mean by native endianness. If the purpose of adding this property now is to support GUTS on the ARM SoCs, then I'd argue using this property is probably wrong. If the PPC systems are designed with BE device registers and ARM systems with LE, then this property is not needed. > I think the property here is fine. Unless you have studied the FSL ARM based SoCs, then there is not enough information here to tell. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory
On Wed, Mar 09, 2016 at 06:08:49PM +0800, Yangbo Lu wrote:
> Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
> since it's used by not only PowerPC but also ARM. And add a specification
> for 'little-endian' property.
>
> Signed-off-by: Yangbo Lu
> ---
> Changes for v2:
> - None
> Changes for v3:
> - None
> Changes for v4:
> - Added this patch
> Changes for v5:
> - Modified the description for little-endian property
> Changes for v6:
> - None
> ---
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
> 1 file changed, 3 insertions(+)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
> index b71b203..07adca9 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> @@ -25,6 +25,9 @@ Recommended properties:
> - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
> registers, for those SOCs that have a PAMU device.
>
> + - little-endian : Indicates that the global utilities block is little
> + endian. The default is big endian.
The default is "the native endianness of the system". So absence on an
ARM system would be LE. This property is valid for any simple-bus
device, so it isn't really required to document per device. You can, but
your description had better match the documented behaviour.
Rob
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 42/45] drivers/of: Rename unflatten_dt_node()
On Mon, Mar 7, 2016 at 6:56 PM, Gavin Shan wrote: > On Tue, Mar 01, 2016 at 08:40:12PM -0600, Rob Herring wrote: >>On Thu, Feb 18, 2016 at 9:16 PM, Gavin Shan wrote: >>> On Wed, Feb 17, 2016 at 08:59:53AM -0600, Rob Herring wrote: >>>>On Tue, Feb 16, 2016 at 9:44 PM, Gavin Shan >>>>wrote: >>>>> This renames unflatten_dt_node() to unflatten_dt_nodes() as it >>>>> populates multiple device nodes from FDT blob. No logical changes >>>>> introduced. >>>>> >>>>> Signed-off-by: Gavin Shan >>>>> --- >>>>> drivers/of/fdt.c | 14 +++--- >>>>> 1 file changed, 7 insertions(+), 7 deletions(-) >>>> >>>>Acked-by: Rob Herring >>>> >>>>I'm happy to take patches 40-42 for 4.6 if the rest of the series >>>>doesn't go in given they fix a separate problem. I just need to know >>>>soon (or at least they need to go into -next soon). >>>> >>> >>> Thanks for quick response, Rob. It depends how much comments I will >>> receive for the powerpc/powernv part. Except that, all parts including >>> this one have been ack'ed. I can discuss it with Michael Ellerman. >>> By the way, how soon you need the decision to merge 40-42? If that's >>> one or two weeks later, I don't think the reivew on the whole series >>> can be done. >> >>Well, it's been 2 weeks now. I need to know this week. >> >>> Also, I think you probably can merge 40-44 as they're all about >>> fdt.c. If they can be merged at one time, I needn't bother (cc) >>> you again if I need send a updated revision. Thanks for your >>> review. >> >>I did not include 43 and 44 as they are only needed for the rest of your >>series. >> > > Rob, sorry for late reponse. I really expect this series to be merged to 4.6 > and > I was checking reviewers' bandwidth to review it. Unfortunately, I didn't > receive > any comments except yours until now. That means this series has to miss 4.6. > Please > pick/merge 41 and 42 if no body has objection. Thanks again for your time on > this. Too late for 4.6. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v7, 3/5] dt: move guts devicetree doc out of powerpc directory
On Fri, Apr 01, 2016 at 11:07:29AM +0800, Yangbo Lu wrote:
> Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
> since it's used by not only PowerPC but also ARM. And add a specification
> for 'little-endian' property.
>
> Signed-off-by: Yangbo Lu
> ---
> Changes for v2:
> - None
> Changes for v3:
> - None
> Changes for v4:
> - Added this patch
> Changes for v5:
> - Modified the description for little-endian property
> Changes for v6:
> - None
> Changes for v7:
> - None
> ---
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
> 1 file changed, 3 insertions(+)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
Acked-by: Rob Herring
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] devicetree/bindings: Add binding for operator panel on FSP machines
On Mon, Apr 11, 2016 at 11:41:29AM +1000, Suraj Jitindar Singh wrote: > Add a binding to Documentation/devicetree/bindings/powerpc/opal > (oppanel-opal.txt) for the operator panel which is present on IBM > pseries machines with FSPs. > > Signed-off-by: Suraj Jitindar Singh > --- > .../devicetree/bindings/powerpc/opal/oppanel-opal.txt | 14 > ++ > 1 file changed, 14 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/powerpc/opal/oppanel-opal.txt Acked-by: Rob Herring ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
