* [PATCH] arm64: fix strnlen_user when count <= strlen
From: Kyle McMartin @ 2014-01-17 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117105107.GC16003@mudshark.cambridge.arm.com>
On Fri, Jan 17, 2014 at 10:51:07AM +0000, Will Deacon wrote:
> Actually, I have removed strnlen_user for 3.14. Could you try your test case
> with our for-next branch please?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
>
This will work fine, I believe (I can't easily test on HW since we're
dependent on $vendor drivers that aren't upstream yet) but in my testing
yesterday I parroted the x86 word-at-a-time.h and lib/strnlen_user.c and
that seemed to work.
> As for the issue you spotted, we probably need a fix for that to go into
> stable kernels. Does the following (smaller patch) work for you?
>
This gets the count == 0 case wrong still, I believe.
=== count = 0 ===
strnlen_user = 0
__strnlen_user = 1
(Where strnlen_user is the lib/strnlen_user.c implementation.)
Testing if (n <= 0) return 0; before __strnlen_user fixes it though.
Given this is called in, I think, only two places in the kernel, maybe
we should just backport the switch to generic for stable? I can't
imagine it conflicting with anything.
regards, Kyle
> Will
>
> --->8
>
> diff --git a/arch/arm64/lib/strnlen_user.S b/arch/arm64/lib/strnlen_user.S
> index 7f7b176a5646..73f3335a2a45 100644
> --- a/arch/arm64/lib/strnlen_user.S
> +++ b/arch/arm64/lib/strnlen_user.S
> @@ -37,6 +37,7 @@ ENTRY(__strnlen_user)
> USER(9f, ldrb w3, [x0], #1 )
> cbnz w3, 1b
> 2: sub x0, x0, x2
> + cinc x0, x0, mi
> ret
> ENDPROC(__strnlen_user)
>
^ permalink raw reply
* [PATCH] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Arnd Bergmann @ 2014-01-17 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389894803-4147-2-git-send-email-sthokal@xilinx.com>
On Thursday 16 January 2014, Srikanth Thokala wrote:
> @@ -0,0 +1,71 @@
> +Xilinx AXI VDMA engine, it does transfers between memory and video devices.
> +It can be configured to have one channel or two channels. If configured
> +as two channels, one is to transmit to the video device and another is
> +to receive from the video device.
> +
> +Required properties:
> +- compatible: Should be "xlnx,axi-vdma-1.00.a"
> +- #dma-cells: Should be <1>, see "dmas" property below
> +- reg: Should contain VDMA registers location and length.
> +- interrupts: Should contain per channel VDMA interrupts.
> +- compatible (child node): It should be either "xlnx,axi-vdma-mm2s-channel" or
> + "xlnx,axi-vdma-s2mm-channel". It depends on the hardware design and it
> + can also have both channels.
> +- xlnx,device-id: Should contain device number in each channel. It should be
> + {0,1,2...so on} to the number of VDMA devices configured in hardware.
> +- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
> +- xlnx,data-width: Should contain the stream data width, takes {32,64...so on}.
> +- xlnx,flush-fsync: (Optional) Tells whether which channel to Flush on Fsync.
> + It takes following values:
> + {1}, flush both channels
> + {2}, flush mm2s channel
> + {3}, flush s2mm channel
> +- xlnx,include-sg: (Optional) Tells whether configured for Scatter-mode in
> + the hardware.
> +- xlnx,include-dre: (Optional) Tells whether hardware is configured for Data
> + Realignment Engine.
> +- xlnx,genlock-mode: (Optional) Tells whether Genlock synchornisation is
> + enabled/disabled in hardware.
The documentation doesn't seem to match the example, since you don't mention
the fact that the channels have separate nodes here, or which properties
are meant for the parent or the child node. Also, some of the "required"
properties are absent in the example, which makes no sense.
I also assume that some of the properties should just go away:
* xlnx,device-id should be the argument in the handle from the slave device
* data width should be a property of the slave driver that is configured
through dma_slave_config(), unless you can have dma engines that only
support certain a width.
Arnd
^ permalink raw reply
* [PATCH 2/2] mmc: dw_mmc: k3: remove clk_table
From: Seungwon Jeon @ 2014-01-17 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86sism7iuz.fsf@void.printf.net>
On Sat, Jan 18, 2014 at 12:01 AM, Chris Ball <chris@printf.net> wrote:
>
> Hi,
>
> On Tue, Jan 14 2014, Seungwon Jeon wrote:
> > On Monday, January 13, 2014, Zhangfei Gao wrote:
> >> Remove clk_table and directly use ios->clock as clock source rate.
> >> Abstract init clock rate and max clock limitation in clk.c
> >>
> >> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> >
> > Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
>
> It looks like patch 1/2 did not make 3.14. Do you want me to take
> this patch for 3.14 anyway? (Why?)
Yes, I hope that it would be merged this time.
I think that this change should have been applied to (036f29: mmc:
dw_mmc: add dw_mmc-k3 for k3 platform) originally.
Thanks,
sw-j
^ permalink raw reply
* [PATCH 01/20] ARM64 / ACPI: Make PCI optional for ACPI on ARM64
From: Bjorn Helgaas @ 2014-01-17 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389961514-13562-2-git-send-email-hanjun.guo@linaro.org>
[+cc Jens, James, Ben, Fujita (authors of PCI_DMA_BUS_IS_PHYS usage)]
On Fri, Jan 17, 2014 at 5:24 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> Not all the ARM64 targets that are using ACPI have PCI, so introduce
> some stub functions to make PCI optional for ACPI, and make ACPI core
> run without CONFIG_PCI on ARM64.
>
> pcibios_penalize_isa_irq() is arch dependent, introduce asm/pci.h to
> include it.
>
> Since ACPI on X86 and IA64 depends on PCI, it will not break X86 and
> IA64 with this patch.
>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/include/asm/pci.h | 20 ++++++++++++++++++++
> drivers/acpi/Makefile | 2 +-
> drivers/acpi/internal.h | 7 +++++++
> drivers/acpi/osl.c | 3 ++-
> include/linux/pci.h | 33 ++++++++++++++++++++++++---------
> 5 files changed, 54 insertions(+), 11 deletions(-)
> create mode 100644 arch/arm64/include/asm/pci.h
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..455909d
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,20 @@
> +#ifndef __ASMARM64_PCI_H
> +#define __ASMARM64_PCI_H
> +
> +#ifdef __KERNEL__
> +
> +static inline void pcibios_penalize_isa_irq(int irq, int active)
> +{
> + /* We don't do dynamic PCI IRQ allocation */
> +}
> +
> +/*
> + * The PCI address space does equal the physical memory address space.
> + * The networking and block device layers use this boolean for bounce
> + * buffer decisions.
> + */
> +#define PCI_DMA_BUS_IS_PHYS (1)
I'm not sure this is accurate. The arm code uses
pci_add_resource_offset() with non-zero offsets, which means a
physical memory address is not the same as a PCI bus address. I don't
know what arm64 does for PCI, but I suspect it is similar.
I think PCI_DMA_BUS_IS_PHYS is due for some overhaul. I'm dubious
that it is working as intended anymore. At the very least, it seems
like something that is dependent on the device in question.
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index a13d682..726cf2a 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> ...
> +static inline int raw_pci_read(unsigned int domain, unsigned int bus,
> + unsigned int devfn, int reg, int len, u32 *val)
> +{ return -EINVAL; }
> +
> +static inline int raw_pci_write(unsigned int domain, unsigned int bus,
> + unsigned int devfn, int reg, int len, u32 val)
> +{return -EINVAL; }
Fix the spacing here (missing a space before "return").
With that, this include/linux/pci.h change is:
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
^ permalink raw reply
* [PATCH 06/18] ARM: dts: omap3-overo: Enable MMC2
From: Javier Martinez Canillas @ 2014-01-17 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D92E93.8050804@epfl.ch>
Hello Florian,
On Fri, Jan 17, 2014 at 10:22 AM, Florian Vaussard
<florian.vaussard@epfl.ch> wrote:
> Hello Javier
>
> On 01/09/2014 09:43 PM, Javier Martinez Canillas wrote:
>> [adding Enric Balletbo to cc]
>>
>> Hello Florian,
>>
>> On Thu, Jan 9, 2014 at 1:48 PM, Florian Vaussard
>> <florian.vaussard@epfl.ch> wrote:
>>> MMC2 is used by the on-board WiFi module populated on some boards
>>> (based on Marvell Libertas 8688 SDIO).
>>>
>>> Note: currently WiFi only works on cold boot, as the module is not
>>> properly reset (missing binding for the GPIO reset).
>>>
>>
>> Have you looked at commit 0e9fd777 ("ARM: dts: omap3-igep: Add support
>> for LBEE1USJYC WiFi connected to SDIO") ?
>>
>> If I remember correctly the LBEE1USJYC Wifi/BT combo module is
>> basically a Marvell Libertas 8688 Wlan and Enric got soft reset
>> working too by adding a GPIO property to the regulator for the reset
>> GPIO.
>>
>> Hope it helps,
>
> Thank you, I got it working. It is a bit messy, as I have 3 GPIOs
> (poweron, wifi-reset and bt-reset). As a regulator can control only one
> GPIO, I had to define 3 regulators, and assigning them to the vmmc,
> vqmmc, and vmmc_aux. I hope that a better solution will pop-up in this
> thread [1]. It is a pity that the previous version of the GPIO-reset
> controller was not merged.
>
Glad to know that you got it working and yes it is a bit messy so
let's hope that a cleaner solution will be the result of the current
discussion on that thread.
> Florian
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/294907
Best regards,
Javier
^ permalink raw reply
* [PATCH 01/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Ezequiel Garcia @ 2014-01-17 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131001115538.GO31178@titan.lakedaemon.net>
Hi Jason,
On Tue, Oct 01, 2013 at 07:55:38AM -0400, Jason Cooper wrote:
[..]
>
> Have you made any progress on this? I know you've been working on other
> stuff lately, I just saw this series sitting on my stack and thought I'd
> poke you.
>
Thanks for the ping! I think it's time to resurrect this... let me try
a few things and see if we can come up with something to solve this.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] of: add functions to count number of elements in a property
From: Heiko Stübner @ 2014-01-17 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117144456.GG19578@e106331-lin.cambridge.arm.com>
The need to know the number of array elements in a property is
a common pattern. To prevent duplication of open-coded implementations
add a helper static function that also centralises strict sanity
checking and DTB format details, as well as a set of wrapper functions
for u8, u16, u32 and u64.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes since v1:
address comments from Rob Herring and Mark Rutland:
- provide a helper and a set of wrappers for u8-u64
- get rid of extra len variable, prop->length is enough
- include node name in error message
drivers/of/base.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 32 +++++++++++++++++
2 files changed, 130 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index f807d0e..b6e6d4a 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -862,6 +862,104 @@ struct device_node *of_find_node_by_phandle(phandle handle)
EXPORT_SYMBOL(of_find_node_by_phandle);
/**
+ * of_count_property_elems_of_size - Count the number of elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @elem_size: size of the individual element
+ */
+static int of_count_property_elems_of_size(const struct device_node *np,
+ const char *propname, int elem_size)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+
+ if (prop->length % elem_size != 0) {
+ pr_err("size of %s in node %s is not a multiple of %d\n",
+ propname, np->name, elem_size);
+ return -EINVAL;
+ }
+
+ return prop->length / elem_size;
+}
+
+/**
+ * of_property_count_u8_elems - Count the number of u8 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u8 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u8 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u8_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_count_property_elems_of_size(np, propname, sizeof(u8));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u8_elems);
+
+/**
+ * of_property_count_u16_elems - Count the number of u16 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u16 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u16 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u16_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_count_property_elems_of_size(np, propname, sizeof(u16));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u16_elems);
+
+/**
+ * of_property_count_u32_elems - Count the number of u32 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u32 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u32 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u32_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_count_property_elems_of_size(np, propname, sizeof(u32));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u32_elems);
+
+/**
+ * of_property_count_u64_elems - Count the number of u64 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u64 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u64 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u64_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_count_property_elems_of_size(np, propname, sizeof(u64));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u64_elems);
+
+/**
* of_find_property_value_of_size
*
* @np: device node from which the property value is to be read.
diff --git a/include/linux/of.h b/include/linux/of.h
index 276c546..06fe898 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -250,6 +250,14 @@ extern struct device_node *of_find_node_with_property(
extern struct property *of_find_property(const struct device_node *np,
const char *name,
int *lenp);
+extern int of_property_count_u8_elems(const struct device_node *np,
+ const char *propname);
+extern int of_property_count_u16_elems(const struct device_node *np,
+ const char *propname);
+extern int of_property_count_u32_elems(const struct device_node *np,
+ const char *propname);
+extern int of_property_count_u64_elems(const struct device_node *np,
+ const char *propname);
extern int of_property_read_u32_index(const struct device_node *np,
const char *propname,
u32 index, u32 *out_value);
@@ -426,6 +434,30 @@ static inline struct device_node *of_find_compatible_node(
return NULL;
}
+static inline int of_property_count_u8_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
+static inline int of_property_count_u16_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
+static inline int of_property_count_u32_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
+static inline int of_property_count_u64_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
static inline int of_property_read_u32_index(const struct device_node *np,
const char *propname, u32 index, u32 *out_value)
{
--
1.7.10.4
^ permalink raw reply related
* [PATCH] Add Xilinx AXI Video DMA Engine driver
From: Andy Shevchenko @ 2014-01-17 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389894803-4147-1-git-send-email-sthokal@xilinx.com>
On Thu, 2014-01-16 at 23:23 +0530, Srikanth Thokala wrote:
> Hi,
>
> This is the driver for Xilinx AXI Video Direct Memory Access Engine.
> It is a soft IP core, which provides high-bandwidth direct memory
> access between memory and AXI4-Stream video type target peripherals
> including peripherals which support AXI4-Stream Video Protocol. The
> core provides efficient two dimensional DMA operations with independent
> asynchronous read and write channel operation.
>
> For more information on the IP, please refer to
> http://www.xilinx.com/support/documentation/ip_documentation/axi_vdma/v6_1/pg020_axi_vdma.pdf
>
> This patch also provides a test client, which assumes read and write channels
> of the core are configured in a back-to-back connection. It transfers
> data on the write channel, read and verify the data on the read channel.
>
> drivers/dma/xilinx/xilinx_vdma_test.c | 629 ++++++++
What about to modify dmatest.c accordingly to your needs?
I see no much sense to have another copy of that in the tree.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v2 resend 1/5] ARM: add support for AT_HWCAP2 ELF auxv entry
From: Ard Biesheuvel @ 2014-01-17 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117150725.GK16003@mudshark.cambridge.arm.com>
On 17 January 2014 16:07, Will Deacon <will.deacon@arm.com> wrote:
> Hi Ard,
>
> On Fri, Jan 17, 2014 at 09:23:07AM +0000, Ard Biesheuvel wrote:
>> This enables AT_HWCAP2 for ARM. The generic support for this
>> new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
>> Add HWCAP2 aux entry)
>
> Does this require a corresponding change in libc so that the entry is
> actually used by the dynamic linker?
>
The auxv entry itself is already wired up [this includes getauxval()]
https://sourceware.org/git/?p=glibc.git;a=commit;h=1ae8bfe07c1a
The only thing that is lacking is a way to hook up ifunc relocation,
as the current prototype passes a single 32-bit quantity.
So either we change the prototype to (hwcap, hwcap2) or we need to
rely on getauxval() in ifunc selectors if they need to inspect hwcap2
--
Ard.
^ permalink raw reply
* [PATCH v9 3/5] arm: introduce CONFIG_PARAVIRT, PARAVIRT_TIME_ACCOUNTING and pv_time_ops
From: Stefano Stabellini @ 2014-01-17 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389292336-9292-3-git-send-email-stefano.stabellini@eu.citrix.com>
On Thu, 9 Jan 2014, Stefano Stabellini wrote:
> Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM.
>
> The only paravirt interface supported is pv_time_ops.steal_clock, so no
> runtime pvops patching needed.
>
> This allows us to make use of steal_account_process_tick for stolen
> ticks accounting.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Christopher Covington <cov@codeaurora.org>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> CC: linux at arm.linux.org.uk
> CC: will.deacon at arm.com
> CC: nico at linaro.org
> CC: marc.zyngier at arm.com
> CC: cov at codeaurora.org
> CC: arnd at arndb.de
> CC: olof at lixom.net
Russell? Do you have an opinion on this?
> Changes in v7:
> - ifdef CONFIG_PARAVIRT the content of paravirt.h.
>
> Changes in v3:
> - improve commit description and Kconfig help text;
> - no need to initialize pv_time_ops;
> - add PARAVIRT_TIME_ACCOUNTING.
> ---
> arch/arm/Kconfig | 20 ++++++++++++++++++++
> arch/arm/include/asm/paravirt.h | 20 ++++++++++++++++++++
> arch/arm/kernel/Makefile | 2 ++
> arch/arm/kernel/paravirt.c | 25 +++++++++++++++++++++++++
> 4 files changed, 67 insertions(+)
> create mode 100644 arch/arm/include/asm/paravirt.h
> create mode 100644 arch/arm/kernel/paravirt.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c1f1a7e..d6c3ba1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1874,6 +1874,25 @@ config SWIOTLB
> config IOMMU_HELPER
> def_bool SWIOTLB
>
> +config PARAVIRT
> + bool "Enable paravirtualization code"
> + ---help---
> + This changes the kernel so it can modify itself when it is run
> + under a hypervisor, potentially improving performance significantly
> + over full virtualization.
> +
> +config PARAVIRT_TIME_ACCOUNTING
> + bool "Paravirtual steal time accounting"
> + select PARAVIRT
> + default n
> + ---help---
> + Select this option to enable fine granularity task steal time
> + accounting. Time spent executing other tasks in parallel with
> + the current vCPU is discounted from the vCPU power. To account for
> + that, there can be a small performance impact.
> +
> + If in doubt, say N here.
> +
> config XEN_DOM0
> def_bool y
> depends on XEN
> @@ -1885,6 +1904,7 @@ config XEN
> depends on !GENERIC_ATOMIC64
> select ARM_PSCI
> select SWIOTLB_XEN
> + select PARAVIRT
> help
> Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>
> diff --git a/arch/arm/include/asm/paravirt.h b/arch/arm/include/asm/paravirt.h
> new file mode 100644
> index 0000000..8435ff59
> --- /dev/null
> +++ b/arch/arm/include/asm/paravirt.h
> @@ -0,0 +1,20 @@
> +#ifndef _ASM_ARM_PARAVIRT_H
> +#define _ASM_ARM_PARAVIRT_H
> +
> +#ifdef CONFIG_PARAVIRT
> +struct static_key;
> +extern struct static_key paravirt_steal_enabled;
> +extern struct static_key paravirt_steal_rq_enabled;
> +
> +struct pv_time_ops {
> + unsigned long long (*steal_clock)(int cpu);
> +};
> +extern struct pv_time_ops pv_time_ops;
> +
> +static inline u64 paravirt_steal_clock(int cpu)
> +{
> + return pv_time_ops.steal_clock(cpu);
> +}
> +#endif
> +
> +#endif
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index a30fc9b..34cf9a6 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -87,6 +87,7 @@ obj-$(CONFIG_ARM_CPU_TOPOLOGY) += topology.o
> ifneq ($(CONFIG_ARCH_EBSA110),y)
> obj-y += io.o
> endif
> +obj-$(CONFIG_PARAVIRT) += paravirt.o
>
> head-y := head$(MMUEXT).o
> obj-$(CONFIG_DEBUG_LL) += debug.o
> diff --git a/arch/arm/kernel/paravirt.c b/arch/arm/kernel/paravirt.c
> new file mode 100644
> index 0000000..53f371e
> --- /dev/null
> +++ b/arch/arm/kernel/paravirt.c
> @@ -0,0 +1,25 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2013 Citrix Systems
> + *
> + * Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> + */
> +
> +#include <linux/export.h>
> +#include <linux/jump_label.h>
> +#include <linux/types.h>
> +#include <asm/paravirt.h>
> +
> +struct static_key paravirt_steal_enabled;
> +struct static_key paravirt_steal_rq_enabled;
> +
> +struct pv_time_ops pv_time_ops;
> +EXPORT_SYMBOL_GPL(pv_time_ops);
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH v9] clk: add MOXA ART SoCs clock driver
From: Sudeep Holla @ 2014-01-17 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389971035-17781-1-git-send-email-jonas.jensen@gmail.com>
On 17/01/14 15:03, Jonas Jensen wrote:
> This patch adds MOXA ART SoCs clock driver support.
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> ---
>
> Notes:
> Changes since v8:
>
> 1. rebase drivers/clk/Makefile to next-20140117
>
> DT bindings document:
>
> 2. use two separate sections describing PLL/APB
> 3. update example
>
> Applies to next-20140117
>
> .../bindings/clock/moxa,moxart-clock.txt | 48 +++++++++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-moxart.c | 112 +++++++++++++++++++++
> 3 files changed, 161 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
> create mode 100644 drivers/clk/clk-moxart.c
>
> diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
> new file mode 100644
> index 0000000..242e3fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
> @@ -0,0 +1,48 @@
> +Device Tree Clock bindings for arch-moxart
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +MOXA ART SoCs allow to determine PLL output and APB frequencies
> +by reading registers holding multiplier and divisor information.
> +
> +
> +PLL:
> +
> +Required properties:
> +- compatible : Must be "moxa,moxart-pll-clock"
> +- #clock-cells : Should be 0
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle to parent clock
> +
> +Optional properties:
> +- clock-output-names : Should contain clock name
> +
> +
> +APB:
> +
> +Required properties:
> +- compatible : Must be "moxa,moxart-apb-clock"
> +- #clock-cells : Should be 0
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle to parent clock
> +
> +Optional properties:
> +- clock-output-names : Should contain clock name
> +
> +
> +For example:
> +
> + clk_pll: clk_pll at 98100000 {
> + compatible = "moxa,moxart-pll-clock";
> + #clock-cells = <0>;
> + reg = <0x98100000 0x34>;
> + };
> +
> + clk_apb: clk_apb at 98100000 {
> + compatible = "moxa,moxart-apb-clock";
> + #clock-cells = <0>;
> + reg = <0x98100000 0x34>;
> + clocks = <&clk_pll>;
> + };
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 0c16e9c..ed5d58d 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-composite.o
> # SoCs specific
> obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
> +obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
> obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
> obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
> obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
> diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
> new file mode 100644
> index 0000000..f0436a3
> --- /dev/null
> +++ b/drivers/clk/clk-moxart.c
> @@ -0,0 +1,112 @@
> +/*
> + * MOXA ART SoCs clock driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen@gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/clkdev.h>
> +
> +void __init moxart_of_pll_clk_init(struct device_node *node)
> +{
> + static void __iomem *base;
> + struct clk *clk, *ref_clk;
> + unsigned long rate;
> + unsigned int mul;
> + const char *name = node->name;
> +
> + of_property_read_string(node, "clock-output-names", &name);
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s: of_iomap failed\n", node->full_name);
> + return;
> + }
> +
> + mul = readl(base + 0x30) >> 3 & 0x3f;
> + iounmap(base);
> +
> + ref_clk = of_clk_get(node, 0);
> + if (IS_ERR(ref_clk)) {
> + pr_err("%s: of_clk_get failed\n", node->full_name);
> + return;
> + }
> +
> + rate = mul * clk_get_rate(ref_clk);
> +
> + clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
> + if (IS_ERR(clk)) {
> + pr_err("%s: clk_register_fixed_rate failed\n", node->full_name);
> + return;
> + }
> +
> + clk_register_clkdev(clk, NULL, name);
> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +}
> +CLK_OF_DECLARE(moxart_pll_clock, "moxa,moxart-pll-clock",
> + moxart_of_pll_clk_init);
> +
> +void __init moxart_of_apb_clk_init(struct device_node *node)
> +{
> + static void __iomem *base;
> + struct clk *clk, *pll_clk;
> + unsigned long rate;
> + unsigned int div, val;
> + const char *name = node->name;
> +
> + of_property_read_string(node, "clock-output-names", &name);
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s: of_iomap failed\n", node->full_name);
> + return;
> + }
> +
> + val = readl(base + 0xc) >> 4 & 0x7;
> + iounmap(base);
> +
> + switch (val) {
> + case 1:
> + div = 3;
> + break;
> + case 2:
> + div = 4;
> + break;
> + case 3:
> + div = 6;
> + break;
> + case 4:
> + div = 8;
> + break;
> + default:
> + div = 2;
> + break;
> + }
How about something like this to avoid unnecessary switch:
int div_idx[] = { 2, 3, 4, 6, 8};
if (val > 4)
val = 0;
div = div_idx[val];
Regards,
Sudeep
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Rob Herring @ 2014-01-17 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.10.1401162204560.28907@knanqh.ubzr>
On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 16 Jan 2014, Olof Johansson wrote:
>
>> "for SDIO slots" is somewhat misleading; nearly all controllers only
>> do one slot/device per controller. The designware controller can do
>> multiple slots, and that adds a bit of driver and binding complexity
>> for something that seemingly not a single vendor has actually
>> implemented.
>
> The Marvell 8688, just to name one, does both WIFI and BlueTooth over
> the same SDIO controller using separate functions/slots.
But that is logical functions within a chip, not multiple discrete
chips (i.e. slots) with their own reset, regulators, etc. There would
still be a single set of external controls per host controller I
think.
Rob
^ permalink raw reply
* [PATCH] ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY to enforce this ACPI mode
From: Arnd Bergmann @ 2014-01-17 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D82671.6000200@linaro.org>
On Thursday 16 January 2014, Al Stone wrote:
> Right; I assumed I had to have that SELECT. My apologies -- I
> still cannot reproduce the warning. I'll resubmit the patch
> incorporating the suggestion, though, since the result ends up
> being the same -- you must have ACPI and EXPERT selected in order
> to enable ACPI_REDUCED_HARDWARE_ONLY.
>
You should never 'select' CONFIG_EXPERT from architecture code, that
is supposed to be a user-settable option. If you also select CONFIG_EXPERT
or have that enabled in the configuration, you will not get a warning.
Arnd
^ permalink raw reply
* [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
From: Arnd Bergmann @ 2014-01-17 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACoXjc=ZT9fEm_KdY4WFSoS8n5FmO+hn9LjsR4m8YZG2iBbt5A@mail.gmail.com>
On Friday 17 January 2014, Tanmay Inamdar wrote:
> On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 15 January 2014, Tanmay Inamdar wrote:
> >> This patch adds the AppliedMicro X-Gene SOC PCIe controller driver.
> >> X-Gene PCIe controller supports maxmum upto 8 lanes and GEN3 speed.
> >> X-Gene has maximum 5 PCIe ports supported.
> >>
> >> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
> >
> > This already looks much better than the first version, but I have a more
> > comments. Most importantly, it would help to know how the root ports
> > are structured. Is this a standard root complex and multiple ports,
> > multiple root complexes with one port each, or a nonstandard organization
> > that is a mix of those two models?
>
> This is multiple root complexes with one port each.
Ok.
> > I also wonder why you need to do this at all. If there isn't a global
> > config space for all ports, but rather a separate type0/type1 config
> > cycle based on the bus number, I see that as an indication that the
> > ports are in fact separate domains and should each start with bus 0.
>
> It is not a standard ECAM layout. We also have a separate RTDID
> register as well to program bus, device, function. While accessing EP
> config space, we have to set the bit 17:16 as 2b'01. The same config
> space address is utilized for enabling a customized nonstandard PCIe
> DMA feature. The bits are defined to differentiate the access purpose.
> The feature is not supported in this driver yet.
>
> Secondly I don't think it will matter if each port starts with bus 0.
> As long as we set the correct BDF in RTDID and set correct bits in
> config address, the config reads and writes would work. Right?
Yes, I think the current code will work (aside from my other comment),
but it seems unnecessary to do this if you use pci domains correctly:
If you have one pci domain and one root port per root complex, you
would not get any config space cycles for the root port and can
do away with the special case here, as well as with the
xgene_pcie_fixup_bridge() that seems to be a special case to
avoid touching the root ports as well.
> >
> >> + switch (restype) {
> >> + case IORESOURCE_MEM:
> >> + res = &port->mem.res;
> >> + pci_addr = port->mem.pci_addr;
> >> + min_size = SZ_128M;
> >> + break;
> >> + case IORESOURCE_IO:
> >> + res = &port->io.res;
> >> + pci_addr = port->io.pci_addr;
> >> + min_size = 128;
> >> + flag |= OB_LO_IO;
> >> + break;
> >> + }
> >
> > I assume this works ok, but seems wrong in one detail: If the resource
> > is marked IORESOURCE_IO, res->start is supposed to be in I/O space, not
> > in memory space, which would make it the wrong number to program
> > into the hardware registers.
Sorry, I was actually wrong with my statement above and I thought I had
deleted my comment before sending the mail.
> Yes for using ioport resource. However we have decided to defer using
> it since 'pci_ioremap_io' is not yet supported from arm64 side.
>
> From HW point of view, for memory mapped IO space, it is nothing but a
> piece taken out of the ranges in address map for outbound accesses. So
> while configuring registers from SOC side, it should take the CPU
> address which is address from SOC address map. Right?
>
> Later on we can have a separate io resource like 'realio' similar to
> what pci-mvebu.c does.
I think your code is actually correct here, but please also add the
pci_ioremap_io implementation for arm64 in a separate patch in this
series. It shouldn't be hard and we need it for every pci host driver
anyway.
> >> +static int xgene_pcie_setup(int nr, struct pci_sys_data *sys)
> >> +{
> >> + struct xgene_pcie_port *pp = xgene_pcie_sys_to_port(sys);
> >> +
> >> + if (pp == NULL)
> >> + return 0;
> >> +
> >> + sys->mem_offset = pp->mem.res.start - pp->mem.pci_addr;
> >> + pci_add_resource_offset(&sys->resources, &pp->mem.res,
> >> + sys->mem_offset);
> >> + return 1;
> >> +}
> > Also, what would be a reason for the port to be zero here? If
> > it's something that can't happen in practice, don't try to handle
> > it gracefully. You can use BUG_ON() for fatal conditions that
> > are supposed to be impossible to reach.
>
> This function is a hook to upper layer. We register nr_controllers in
> hw_pci structure as MAX_PORTS we support. It can happen that number of
> ports actually enabled from device tree are less than the number in
> nr_controllers.
I see. I'll comment more on this below.
> >> + if (!port->link_up)
> >> + dev_info(port->dev, "(rc) link down\n");
> >> + else
> >> + dev_info(port->dev, "(rc) x%d gen-%d link up\n",
> >> + lanes, port->link_speed + 1);
> >> +#ifdef CONFIG_PCI_DOMAINS
> >> + xgene_pcie_hw.domain++;
> >> +#endif
> >> + xgene_pcie_hw.private_data[index++] = port;
> >> + platform_set_drvdata(pdev, port);
> >> + return 0;
> >> +}
> >
> > Do you have multiple domains or not? I don't see how it can work if you
> > make the domain setup conditional on a kernel configuration option.
> > If you in fact have multiple domains, make sure in Kconfig that
> > CONFIG_PCI_DOMAINS is enabled. Otherwise don't mess with the domain
> > number...
>
> It is enabled in Kconfig.
Ok, then remove the #ifdef here.
> >> +static int __init xgene_pcie_init(void)
> >> +{
> >> + void *private;
> >> + int ret;
> >> +
> >> + pr_info("X-Gene: PCIe driver\n");
> >> +
> >> + /* allocate private data to keep xgene_pcie_port information */
> >> + private = kzalloc((XGENE_PCIE_MAX_PORTS * sizeof(void *)), GFP_KERNEL);
> >
> > This should not be done unconditionally: There is no point in printing
> > a message or allocating memory if you don't actually run on a system
> > with this device.
>
> I am doing this here because I have one instance of hw_pci structure
> with multiple pcie controllers. I can't do it from probe since it will
> be called once per instance in device tree.
>
> >
> >> + xgene_pcie_hw.private_data = private;
> >> + ret = platform_driver_probe(&xgene_pcie_driver,
> >> + xgene_pcie_probe_bridge);
> >> + if (ret)
> >> + return ret;
> >> + pci_common_init(&xgene_pcie_hw);
> >> + return 0;
> >
> > This seems wrong: You should not use platform_driver_probe() because
> > that has issues with deferred probing.
>
> I think 'platform_driver_probe' prevents the deferred probing.
> 'pci_common_init' needs to be called only once with current driver
> structure. The probes for all pcie ports should be finished (ports
> initialized) before 'pci_common_init' gets called.
I think it would be cleaner for dynamically registered host controllers
to call pci_common_init_dev() with nr_controllers=1 once for each root
complex in the probe() function. This should take care of a few other
things I've mentioned as well.
Arnd
^ permalink raw reply
* [PATCH v2 resend 1/5] ARM: add support for AT_HWCAP2 ELF auxv entry
From: Will Deacon @ 2014-01-17 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389950591-4212-2-git-send-email-ard.biesheuvel@linaro.org>
Hi Ard,
On Fri, Jan 17, 2014 at 09:23:07AM +0000, Ard Biesheuvel wrote:
> This enables AT_HWCAP2 for ARM. The generic support for this
> new ELF auxv entry was added in commit 2171364d1a9 (powerpc:
> Add HWCAP2 aux entry)
Does this require a corresponding change in libc so that the entry is
actually used by the dynamic linker?
Will
^ permalink raw reply
* [PATCH v2 1/7] ARM: perf_event: Support percpu irqs for the CPU PMU
From: Will Deacon @ 2014-01-17 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115205427.GB26193@codeaurora.org>
Hi Stephen,
On Wed, Jan 15, 2014 at 08:54:27PM +0000, Stephen Boyd wrote:
> On 01/15, Stephen Boyd wrote:
> > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > index 789d846a9184..e76750980b38 100644
> > --- a/arch/arm/kernel/perf_event.c
> > +++ b/arch/arm/kernel/perf_event.c
> > @@ -295,9 +297,15 @@ validate_group(struct perf_event *event)
> >
> > static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
> > {
> > - struct arm_pmu *armpmu = (struct arm_pmu *) dev;
> > - struct platform_device *plat_device = armpmu->plat_device;
> > - struct arm_pmu_platdata *plat = dev_get_platdata(&plat_device->dev);
> > + struct arm_pmu *armpmu;
> > + struct platform_device *plat_device;
> > + struct arm_pmu_platdata *plat;
> > +
> > + if (irq_is_percpu(irq))
> > + dev = *(struct arm_pmu_cpu **)dev;
>
> Oh. I just realized that struct arm_pmu_cpu doesn't even exist. This
> still compiles though because we're dealing with a void pointer.
>
> Perhaps its better to just do
>
> dev = *(void **)dev;
>
> here. Can you fix that up when applying? Otherwise I'll do it on
> the next send if there are more comments.
Shouldn't that actually be some per_cpu accessor like this_cpu_ptr?
Will
^ permalink raw reply
* [PATCH v9] clk: add MOXA ART SoCs clock driver
From: Jonas Jensen @ 2014-01-17 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1386602163-28479-1-git-send-email-jonas.jensen@gmail.com>
This patch adds MOXA ART SoCs clock driver support.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Changes since v8:
1. rebase drivers/clk/Makefile to next-20140117
DT bindings document:
2. use two separate sections describing PLL/APB
3. update example
Applies to next-20140117
.../bindings/clock/moxa,moxart-clock.txt | 48 +++++++++
drivers/clk/Makefile | 1 +
drivers/clk/clk-moxart.c | 112 +++++++++++++++++++++
3 files changed, 161 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
create mode 100644 drivers/clk/clk-moxart.c
diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
new file mode 100644
index 0000000..242e3fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
@@ -0,0 +1,48 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine PLL output and APB frequencies
+by reading registers holding multiplier and divisor information.
+
+
+PLL:
+
+Required properties:
+- compatible : Must be "moxa,moxart-pll-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clocks : Should contain phandle to parent clock
+
+Optional properties:
+- clock-output-names : Should contain clock name
+
+
+APB:
+
+Required properties:
+- compatible : Must be "moxa,moxart-apb-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clocks : Should contain phandle to parent clock
+
+Optional properties:
+- clock-output-names : Should contain clock name
+
+
+For example:
+
+ clk_pll: clk_pll at 98100000 {
+ compatible = "moxa,moxart-pll-clock";
+ #clock-cells = <0>;
+ reg = <0x98100000 0x34>;
+ };
+
+ clk_apb: clk_apb at 98100000 {
+ compatible = "moxa,moxart-apb-clock";
+ #clock-cells = <0>;
+ reg = <0x98100000 0x34>;
+ clocks = <&clk_pll>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 0c16e9c..ed5d58d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-composite.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
+obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
new file mode 100644
index 0000000..f0436a3
--- /dev/null
+++ b/drivers/clk/clk-moxart.c
@@ -0,0 +1,112 @@
+/*
+ * MOXA ART SoCs clock driver.
+ *
+ * Copyright (C) 2013 Jonas Jensen
+ *
+ * Jonas Jensen <jonas.jensen@gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/clkdev.h>
+
+void __init moxart_of_pll_clk_init(struct device_node *node)
+{
+ static void __iomem *base;
+ struct clk *clk, *ref_clk;
+ unsigned long rate;
+ unsigned int mul;
+ const char *name = node->name;
+
+ of_property_read_string(node, "clock-output-names", &name);
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ pr_err("%s: of_iomap failed\n", node->full_name);
+ return;
+ }
+
+ mul = readl(base + 0x30) >> 3 & 0x3f;
+ iounmap(base);
+
+ ref_clk = of_clk_get(node, 0);
+ if (IS_ERR(ref_clk)) {
+ pr_err("%s: of_clk_get failed\n", node->full_name);
+ return;
+ }
+
+ rate = mul * clk_get_rate(ref_clk);
+
+ clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+ if (IS_ERR(clk)) {
+ pr_err("%s: clk_register_fixed_rate failed\n", node->full_name);
+ return;
+ }
+
+ clk_register_clkdev(clk, NULL, name);
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(moxart_pll_clock, "moxa,moxart-pll-clock",
+ moxart_of_pll_clk_init);
+
+void __init moxart_of_apb_clk_init(struct device_node *node)
+{
+ static void __iomem *base;
+ struct clk *clk, *pll_clk;
+ unsigned long rate;
+ unsigned int div, val;
+ const char *name = node->name;
+
+ of_property_read_string(node, "clock-output-names", &name);
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ pr_err("%s: of_iomap failed\n", node->full_name);
+ return;
+ }
+
+ val = readl(base + 0xc) >> 4 & 0x7;
+ iounmap(base);
+
+ switch (val) {
+ case 1:
+ div = 3;
+ break;
+ case 2:
+ div = 4;
+ break;
+ case 3:
+ div = 6;
+ break;
+ case 4:
+ div = 8;
+ break;
+ default:
+ div = 2;
+ break;
+ }
+
+ pll_clk = of_clk_get(node, 0);
+ if (IS_ERR(pll_clk)) {
+ pr_err("%s: of_clk_get failed\n", node->full_name);
+ return;
+ }
+
+ rate = clk_get_rate(pll_clk) / (div * 2);
+
+ clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
+ if (IS_ERR(clk)) {
+ pr_err("%s: clk_register_fixed_rate failed\n", node->full_name);
+ return;
+ }
+
+ clk_register_clkdev(clk, NULL, name);
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(moxart_apb_clock, "moxa,moxart-apb-clock",
+ moxart_of_apb_clk_init);
--
1.8.2.1
^ permalink raw reply related
* [RFC PATCH 3/3] arm64: KVM: flush VM pages before letting the guest enable caches
From: Marc Zyngier @ 2014-01-17 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389970993-19371-1-git-send-email-marc.zyngier@arm.com>
When the guest runs with caches disabled (like in an early boot
sequence, for example), all the writes are diectly going to RAM,
bypassing the caches altogether.
Once the MMU and caches are enabled, whatever sits in the cache
becomes suddently visible, which isn't what the guest expects.
A way to avoid this potential disaster is to invalidate the cache
when the MMU is being turned on. For this, we hook into the SCTLR_EL1
trapping code, and scan the stage-2 page tables, invalidating the
pages/sections that have already been mapped in.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/kvm/mmu.c | 72 ++++++++++++++++++++++++++++++++++++++++
arch/arm64/include/asm/kvm_mmu.h | 1 +
arch/arm64/kvm/sys_regs.c | 5 ++-
3 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 415fd63..704c939 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -187,6 +187,78 @@ static void unmap_range(struct kvm *kvm, pgd_t *pgdp,
}
}
+void stage2_flush_ptes(struct kvm *kvm, pmd_t *pmd,
+ unsigned long addr, unsigned long end)
+{
+ pte_t *pte;
+
+ pte = pte_offset_kernel(pmd, addr);
+ do {
+ if (!pte_none(*pte)) {
+ hva_t hva = gfn_to_hva(kvm, addr >> PAGE_SHIFT);
+ kvm_flush_dcache_to_poc((void*)hva, PAGE_SIZE);
+ }
+ } while(pte++, addr += PAGE_SIZE, addr != end);
+}
+
+void stage2_flush_pmds(struct kvm *kvm, pud_t *pud,
+ unsigned long addr, unsigned long end)
+{
+ pmd_t *pmd;
+ unsigned long next;
+
+ pmd = pmd_offset(pud, addr);
+ do {
+ next = pmd_addr_end(addr, end);
+ if (!pmd_none(*pmd)) {
+ if (kvm_pmd_huge(*pmd)) {
+ hva_t hva = gfn_to_hva(kvm, addr >> PAGE_SHIFT);
+ kvm_flush_dcache_to_poc((void*)hva, PMD_SIZE);
+ } else {
+ stage2_flush_ptes(kvm, pmd, addr, next);
+ }
+ }
+ } while(pmd++, addr = next, addr != end);
+}
+
+void stage2_flush_puds(struct kvm *kvm, pgd_t *pgd,
+ unsigned long addr, unsigned long end)
+{
+ pud_t *pud;
+ unsigned long next;
+
+ pud = pud_offset(pgd, addr);
+ do {
+ next = pud_addr_end(addr, end);
+ if (!pud_none(*pud)) {
+ if (pud_huge(*pud)) {
+ hva_t hva = gfn_to_hva(kvm, addr >> PAGE_SHIFT);
+ kvm_flush_dcache_to_poc((void*)hva, PUD_SIZE);
+ } else {
+ stage2_flush_pmds(kvm, pud, addr, next);
+ }
+ }
+ } while(pud++, addr = next, addr != end);
+}
+
+void stage2_flush_vm(struct kvm *kvm)
+{
+ unsigned long long addr = 0;
+ unsigned long end = KVM_PHYS_SIZE;
+ unsigned long next;
+ pgd_t *pgd;
+
+ spin_lock(&kvm->mmu_lock);
+
+ pgd = kvm->arch.pgd + pgd_index(addr);
+ do {
+ next = pgd_addr_end(addr, end);
+ stage2_flush_puds(kvm, pgd, addr, next);
+ } while(pgd++, addr = next, addr != end);
+
+ spin_unlock(&kvm->mmu_lock);
+}
+
/**
* free_boot_hyp_pgd - free HYP boot page tables
*
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 2232dd0..b7b2ca3 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -139,6 +139,7 @@ static inline void coherent_cache_guest_page(struct kvm_vcpu *vcpu, hva_t hva,
}
}
+void stage2_flush_vm(struct kvm *kvm);
#endif /* __ASSEMBLY__ */
#endif /* __ARM64_KVM_MMU_H__ */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 5e92b9e..32e440f 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -27,6 +27,7 @@
#include <asm/kvm_host.h>
#include <asm/kvm_emulate.h>
#include <asm/kvm_coproc.h>
+#include <asm/kvm_mmu.h>
#include <asm/cacheflush.h>
#include <asm/cputype.h>
#include <trace/events/kvm.h>
@@ -150,8 +151,10 @@ static bool access_sctlr_el1(struct kvm_vcpu *vcpu,
val = *vcpu_reg(vcpu, p->Rt);
vcpu_sys_reg(vcpu, r->reg) = val;
- if ((val & (0b101)) == 0b101) /* MMU+Caches enabled? */
+ if ((val & (0b101)) == 0b101) { /* MMU+Caches enabled? */
vcpu->arch.hcr_el2 &= ~HCR_TVM;
+ stage2_flush_vm(vcpu->kvm);
+ }
return true;
}
--
1.8.3.4
^ permalink raw reply related
* [RFC PATCH 2/3] arm64: KVM: trap VM system registers until MMU and caches are ON
From: Marc Zyngier @ 2014-01-17 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389970993-19371-1-git-send-email-marc.zyngier@arm.com>
In order to be able to detect the point where the guest enables
its MMU and caches, trap all the VM related system registers.
Once we see the guest enabling both the MMU and the caches, we
can go back to a saner mode of operation, which is to leave these
registers in complete control of the guest.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/kvm_arm.h | 3 ++-
arch/arm64/kvm/sys_regs.c | 58 ++++++++++++++++++++++++++++++++--------
2 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index c98ef47..fd0a651 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -62,6 +62,7 @@
* RW: 64bit by default, can be overriden for 32bit VMs
* TAC: Trap ACTLR
* TSC: Trap SMC
+ * TVM: Trap VM ops (until M+C set in SCTLR_EL1)
* TSW: Trap cache operations by set/way
* TWE: Trap WFE
* TWI: Trap WFI
@@ -74,7 +75,7 @@
* SWIO: Turn set/way invalidates into set/way clean+invalidate
*/
#define HCR_GUEST_FLAGS (HCR_TSC | HCR_TSW | HCR_TWE | HCR_TWI | HCR_VM | \
- HCR_BSU_IS | HCR_FB | HCR_TAC | \
+ HCR_TVM | HCR_BSU_IS | HCR_FB | HCR_TAC | \
HCR_AMO | HCR_IMO | HCR_FMO | \
HCR_SWIO | HCR_TIDCP | HCR_RW)
#define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 02e9d09..5e92b9e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -121,6 +121,42 @@ done:
}
/*
+ * Generic accessor for VM registers. Only called as long as HCR_TVM
+ * is set.
+ */
+static bool access_vm_reg(struct kvm_vcpu *vcpu,
+ const struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ BUG_ON(!p->is_write);
+
+ vcpu_sys_reg(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt);
+ return true;
+}
+
+/*
+ * SCTLR_EL1 accessor. Only called as long as HCR_TVM is set. If the
+ * guest enables the MMU, we stop trapping the VM sys_regs and leave
+ * it in complete control of the caches.
+ */
+static bool access_sctlr_el1(struct kvm_vcpu *vcpu,
+ const struct sys_reg_params *p,
+ const struct sys_reg_desc *r)
+{
+ unsigned long val;
+
+ BUG_ON(!p->is_write);
+
+ val = *vcpu_reg(vcpu, p->Rt);
+ vcpu_sys_reg(vcpu, r->reg) = val;
+
+ if ((val & (0b101)) == 0b101) /* MMU+Caches enabled? */
+ vcpu->arch.hcr_el2 &= ~HCR_TVM;
+
+ return true;
+}
+
+/*
* We could trap ID_DFR0 and tell the guest we don't support performance
* monitoring. Unfortunately the patch to make the kernel check ID_DFR0 was
* NAKed, so it will read the PMCR anyway.
@@ -185,32 +221,32 @@ static const struct sys_reg_desc sys_reg_descs[] = {
NULL, reset_mpidr, MPIDR_EL1 },
/* SCTLR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b000),
- NULL, reset_val, SCTLR_EL1, 0x00C50078 },
+ access_sctlr_el1, reset_val, SCTLR_EL1, 0x00C50078 },
/* CPACR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0001), CRm(0b0000), Op2(0b010),
NULL, reset_val, CPACR_EL1, 0 },
/* TTBR0_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b000),
- NULL, reset_unknown, TTBR0_EL1 },
+ access_vm_reg, reset_unknown, TTBR0_EL1 },
/* TTBR1_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b001),
- NULL, reset_unknown, TTBR1_EL1 },
+ access_vm_reg, reset_unknown, TTBR1_EL1 },
/* TCR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0010), CRm(0b0000), Op2(0b010),
- NULL, reset_val, TCR_EL1, 0 },
+ access_vm_reg, reset_val, TCR_EL1, 0 },
/* AFSR0_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b000),
- NULL, reset_unknown, AFSR0_EL1 },
+ access_vm_reg, reset_unknown, AFSR0_EL1 },
/* AFSR1_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0001), Op2(0b001),
- NULL, reset_unknown, AFSR1_EL1 },
+ access_vm_reg, reset_unknown, AFSR1_EL1 },
/* ESR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0101), CRm(0b0010), Op2(0b000),
- NULL, reset_unknown, ESR_EL1 },
+ access_vm_reg, reset_unknown, ESR_EL1 },
/* FAR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0110), CRm(0b0000), Op2(0b000),
- NULL, reset_unknown, FAR_EL1 },
+ access_vm_reg, reset_unknown, FAR_EL1 },
/* PAR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b0111), CRm(0b0100), Op2(0b000),
NULL, reset_unknown, PAR_EL1 },
@@ -224,17 +260,17 @@ static const struct sys_reg_desc sys_reg_descs[] = {
/* MAIR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
- NULL, reset_unknown, MAIR_EL1 },
+ access_vm_reg, reset_unknown, MAIR_EL1 },
/* AMAIR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0011), Op2(0b000),
- NULL, reset_amair_el1, AMAIR_EL1 },
+ access_vm_reg, reset_amair_el1, AMAIR_EL1 },
/* VBAR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1100), CRm(0b0000), Op2(0b000),
NULL, reset_val, VBAR_EL1, 0 },
/* CONTEXTIDR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b001),
- NULL, reset_val, CONTEXTIDR_EL1, 0 },
+ access_vm_reg, reset_val, CONTEXTIDR_EL1, 0 },
/* TPIDR_EL1 */
{ Op0(0b11), Op1(0b000), CRn(0b1101), CRm(0b0000), Op2(0b100),
NULL, reset_unknown, TPIDR_EL1 },
--
1.8.3.4
^ permalink raw reply related
* [RFC PATCH 1/3] arm64: KVM: force cache clean on page fault when caches are off
From: Marc Zyngier @ 2014-01-17 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389970993-19371-1-git-send-email-marc.zyngier@arm.com>
In order for the guest with caches off to observe data written
contained in a given page, we need to make sure that page is
committed to memory, and not just hanging in the cache (as
guest accesses are completely bypassing the cache until it
decides to enable it).
For this purpose, hook into the coherent_icache_guest_page
function and flush the region if the guest SCTLR_EL1
register doesn't show the MMU and caches as being enabled.
The function also get renamed to coherent_cache_guest_page.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/include/asm/kvm_mmu.h | 4 ++--
arch/arm/kvm/mmu.c | 4 ++--
arch/arm64/include/asm/kvm_mmu.h | 11 +++++++----
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 77de4a4..f997b9e 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -116,8 +116,8 @@ static inline void kvm_set_s2pmd_writable(pmd_t *pmd)
struct kvm;
-static inline void coherent_icache_guest_page(struct kvm *kvm, hva_t hva,
- unsigned long size)
+static inline void coherent_cache_guest_page(struct kvm_vcpu *vcpu, hva_t hva,
+ unsigned long size)
{
/*
* If we are going to insert an instruction page and the icache is
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 5809069..415fd63 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -713,7 +713,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
kvm_set_s2pmd_writable(&new_pmd);
kvm_set_pfn_dirty(pfn);
}
- coherent_icache_guest_page(kvm, hva & PMD_MASK, PMD_SIZE);
+ coherent_cache_guest_page(vcpu, hva & PMD_MASK, PMD_SIZE);
ret = stage2_set_pmd_huge(kvm, memcache, fault_ipa, &new_pmd);
} else {
pte_t new_pte = pfn_pte(pfn, PAGE_S2);
@@ -721,7 +721,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
kvm_set_s2pte_writable(&new_pte);
kvm_set_pfn_dirty(pfn);
}
- coherent_icache_guest_page(kvm, hva, PAGE_SIZE);
+ coherent_cache_guest_page(vcpu, hva, PAGE_SIZE);
ret = stage2_set_pte(kvm, memcache, fault_ipa, &new_pte, false);
}
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 680f74e..2232dd0 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -106,7 +106,6 @@ static inline bool kvm_is_write_fault(unsigned long esr)
return true;
}
-static inline void kvm_clean_dcache_area(void *addr, size_t size) {}
static inline void kvm_clean_pgd(pgd_t *pgd) {}
static inline void kvm_clean_pmd_entry(pmd_t *pmd) {}
static inline void kvm_clean_pte(pte_t *pte) {}
@@ -124,9 +123,14 @@ static inline void kvm_set_s2pmd_writable(pmd_t *pmd)
struct kvm;
-static inline void coherent_icache_guest_page(struct kvm *kvm, hva_t hva,
- unsigned long size)
+#define kvm_flush_dcache_to_poc(a,l) __flush_dcache_area((a), (l))
+
+static inline void coherent_cache_guest_page(struct kvm_vcpu *vcpu, hva_t hva,
+ unsigned long size)
{
+ if ((vcpu_sys_reg(vcpu, SCTLR_EL1) & 0b101) != 0b101)
+ kvm_flush_dcache_to_poc((void *)hva, size);
+
if (!icache_is_aliasing()) { /* PIPT */
flush_icache_range(hva, hva + size);
} else if (!icache_is_aivivt()) { /* non ASID-tagged VIVT */
@@ -135,7 +139,6 @@ static inline void coherent_icache_guest_page(struct kvm *kvm, hva_t hva,
}
}
-#define kvm_flush_dcache_to_poc(a,l) __flush_dcache_area((a), (l))
#endif /* __ASSEMBLY__ */
#endif /* __ARM64_KVM_MMU_H__ */
--
1.8.3.4
^ permalink raw reply related
* [RFC PATCH 0/3] arm64: KVM: host cache maintainance when guest caches are off
From: Marc Zyngier @ 2014-01-17 15:03 UTC (permalink / raw)
To: linux-arm-kernel
When we run a guest with cache disabled, we don't flush the cache to
the Point of Coherency, hence possibly missing bits of data that have
been written in the cache, but have not yet reached memory.
We also have the opposite issue: when a guest enables its cache,
whatever sits in the cache is suddenly going to become visible,
shadowing whatever the guest has written into RAM.
There are several approaches to these issues:
- Using the DC bit when caches are off: this breaks guests assuming
caches off while doing DMA operations. Bootloaders, for example.
It also breaks the I-D coherency.
- Fetch the memory attributes on translation fault, and flush the
cache while handling the fault. This relies on using the PAR_EL1
register to obtain the Stage-1 memory attributes, and tends to be
slow.
- Detecting the translation faults occuring with MMU off (and
performing a cache clean), and trapping SCTLR_EL1 to detect the
moment when the guest is turning its caches on (and performing a
cache invalidation). Trapping of SCTLR_EL1 is then disabled to
ensure the best performance.
This patch series implements the last solution, only on arm64 for the
time being (I'll add the necessary ARMv7 bits once we reach an
agreement on arm64).
Marc Zyngier (3):
arm64: KVM: force cache clean on page fault when caches are off
arm64: KVM: trap VM system registers until MMU and caches are ON
arm64: KVM: flush VM pages before letting the guest enable caches
arch/arm/include/asm/kvm_mmu.h | 4 +--
arch/arm/kvm/mmu.c | 76 ++++++++++++++++++++++++++++++++++++++--
arch/arm64/include/asm/kvm_arm.h | 3 +-
arch/arm64/include/asm/kvm_mmu.h | 12 ++++---
arch/arm64/kvm/sys_regs.c | 61 ++++++++++++++++++++++++++------
5 files changed, 136 insertions(+), 20 deletions(-)
--
1.8.3.4
^ permalink raw reply
* [PATCH 2/2] mmc: dw_mmc: k3: remove clk_table
From: Chris Ball @ 2014-01-17 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002b01cf1115$4cdfe240$e69fa6c0$%jun@samsung.com>
Hi,
On Tue, Jan 14 2014, Seungwon Jeon wrote:
> On Monday, January 13, 2014, Zhangfei Gao wrote:
>> Remove clk_table and directly use ios->clock as clock source rate.
>> Abstract init clock rate and max clock limitation in clk.c
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>
> Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
It looks like patch 1/2 did not make 3.14. Do you want me to take
this patch for 3.14 anyway? (Why?)
Thanks,
- Chris.
--
Chris Ball <chris@printf.net> <http://printf.net/>
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Arnd Bergmann @ 2014-01-17 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.10.1401162204560.28907@knanqh.ubzr>
On Friday 17 January 2014, Nicolas Pitre wrote:
> On Thu, 16 Jan 2014, Olof Johansson wrote:
>
> > "for SDIO slots" is somewhat misleading; nearly all controllers only
> > do one slot/device per controller. The designware controller can do
> > multiple slots, and that adds a bit of driver and binding complexity
> > for something that seemingly not a single vendor has actually
> > implemented.
>
> The Marvell 8688, just to name one, does both WIFI and BlueTooth over
> the same SDIO controller using separate functions/slots.
>
> Or maybe I'm misunderstanding you?
>
I wasn't aware of this but I just checked (in mmc_attach_sdio) that
there can be multiple functions on a slot. I assume the sd8688 has
a single slot with two functions, so that potentially extends the
problem space if we need to supply clocks and regulators per
function rather than just per slot.
Arnd
^ permalink raw reply
* [PATCH] of: add function to count number of u32 elements in a property
From: Mark Rutland @ 2014-01-17 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3781679.27UF2dWtKL@phil>
On Thu, Jan 16, 2014 at 06:04:42PM +0000, Heiko St?bner wrote:
> The need to know the number of array elements in a property is
> a common pattern. To prevent duplication of open-coded implementations
> add a helper function that also centralises strict sanity checking
> and DTB format details.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Hi Mark,
> did you mean it like this? I've tested it with the sram-reserve change and
> it made the part of the determining the number elements a lot nicer :-)
Yes! This looks pretty nice! :)
>
> drivers/of/base.c | 32 ++++++++++++++++++++++++++++++++
> include/linux/of.h | 8 ++++++++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f807d0e..0f40ea5 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -920,6 +920,38 @@ int of_property_read_u32_index(const struct device_node *np,
> EXPORT_SYMBOL_GPL(of_property_read_u32_index);
>
> /**
> + * of_property_count_u32_elems - Count the number of u32 values in a property
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + *
> + * Search for a property in a device node and count the number of u32 elements
> + * in it. Returns number of elements on sucess, -EINVAL if the property does
> + * not exist or its length does not match a multiple of u32 and -ENODATA if the
> + * property does not have a value.
> + */
> +int of_property_count_u32_elems(const struct device_node *np,
> + const char *propname)
> +{
> + int elem_size = sizeof(u32);
> + int len;
> + struct property *prop = of_find_property(np, propname, &len);
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> +
> + if (prop->length % elem_size != 0) {
> + pr_err("size of %s is not a multiple of u32\n", propname);
> + return -EINVAL;
> + }
> +
> + return len / elem_size;
> +}
> +EXPORT_SYMBOL_GPL(of_property_count_u32_elems);
As Rob said in his reply, it would be nice to split this into a static
helper that took elem size as a parameter, so we can have the full suite
of of_property_count_{u8,u16,u32,u64}_elems.
Also, I think you can get rid of len and always use prop->length, as
other helpers seem to do.
Cheers for putting this together!
Mark.
^ permalink raw reply
* [PATCH 2/2] mmc: dw_mmc: k3: remove clk_table
From: Seungwon Jeon @ 2014-01-17 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389604469-8064-3-git-send-email-zhangfei.gao@linaro.org>
+ Chris Ball (New e-mail)
On Tue, January 14, 2014, Seungwon Jeon wrote:
> On Monday, January 13, 2014, Zhangfei Gao wrote:
> > Remove clk_table and directly use ios->clock as clock source rate.
> > Abstract init clock rate and max clock limitation in clk.c
> >
> > Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>
> Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
>
> Thanks,
> Seungwon Jeon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox