* [Bug] VCHIQ functional test broken
From: Stefan Wahren @ 2017-04-24 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424185931.GQ17774@n2100.armlinux.org.uk>
> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 24. April 2017 um 20:59 geschrieben:
>
>
> On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > > What I can't see is how changing flush_dcache_page() has possibly broken
> > > this: it seems to imply that you're getting flush_dcache_page() somehow
> > > called inbetween mapping it for DMA, using it for DMA and CPU accesses
> > > occuring. However, the driver doesn't call flush_dcache_page() other
> > > than through get_user_pages() - and since dma_map_sg() is used in that
> > > path, it should be fine.
> > >
> > > So, I don't have much to offer.
> > >
> > > However, flush_dcache_page() is probably still a tad heavy - it currently
> > > flushes to the point of coherency, but it's really about making sure that
> > > the user vs kernel mappings are coherent, not about device coherency.
> > > That's the role of the DMA API.
> >
> > Currently i don't care too much about performance. More important is to
> > fix this regression, because i'm not able to verify the function of this
> > driver efficiently.
>
> This is a driver in staging, and the reason its in staging is because it
> has problems. This is just another example of another problem it has...
> Yes, the regression is regrettable, but I don't think it's something to
> get hung up on.
>
> > I'm thinking about 2 options:
> >
> > 1) add a force parameter to flush_dcache_page() which make it possible
> > to override the new logic
> > 2) create a second version of flush_dcache_page() with the old behavior
>
> Neither, really, because, as I've already explained, flush_dcache_page()
> has nothing what so ever to do with DMA coherence - and if a driver
> breaks because we change its semantic slightly (but still in a compliant
> way) then it's uncovered a latent bug in _that_ driver.
>
> Rather than trying to "fix" flush_dcache_page() to work how this driver
> wants it to (which is a totally crazy thing to propose - we can't go
> shoe-horning driver specific behaviour into these generic flushing
> functions), it would be much better to work out why the driver has
> broken.
I totally agree. I had the hope we could make a workaround within the driver until we found the real issue.
>
> I see the kernel driver has its own logging (using vchiq_log_info() etc?)
> maybe a starting point would be to compare the output from a working
> kernel with a non-working kernel to get more of an idea where the problem
> actually is?
I will try ...
>
> What I'm willing to do is to temporarily drop the offending patch for
> the next merge window to give more time for this driver to be debugged,
> but I will want to re-apply it after that merge window closes.
Since this is already in 4.11, please keep it. At least this makes it easier to reproduce. No need for more confusion and effort.
^ permalink raw reply
* [PATCH 2/3 v2] arm/xen: Consolidate calls to shutdown hypercall in a single helper
From: Stefano Stabellini @ 2017-04-24 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175839.5262-3-julien.grall@arm.com>
On Mon, 24 Apr 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes in v2:
> - Patch added
> ---
> arch/arm/xen/enlighten.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 81e3217b12d3..ba7f4c8f5c3e 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -191,20 +191,24 @@ static int xen_dying_cpu(unsigned int cpu)
> return 0;
> }
>
> -static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
> +void xen_reboot(int reason)
> {
> - struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
> + struct sched_shutdown r = { .reason = reason };
> int rc;
> +
> rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
> BUG_ON(rc);
> }
>
> +static void xen_restart(enum reboot_mode reboot_mode, const char *cmd)
> +{
> + xen_reboot(SHUTDOWN_reboot);
> +}
> +
> +
> static void xen_power_off(void)
> {
> - struct sched_shutdown r = { .reason = SHUTDOWN_poweroff };
> - int rc;
> - rc = HYPERVISOR_sched_op(SCHEDOP_shutdown, &r);
> - BUG_ON(rc);
> + xen_reboot(SHUTDOWN_poweroff);
> }
>
> static irqreturn_t xen_arm_callback(int irq, void *arg)
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH 2/2] reset: Add a Gemini reset controller
From: Linus Walleij @ 2017-04-24 19:28 UTC (permalink / raw)
To: linux-arm-kernel
The Cortina Systems Gemini reset controller is a simple
32bit register with self-deasserting reset lines. It is
accessed using regmap over syscon.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/reset/Kconfig | 7 +++
drivers/reset/Makefile | 1 +
drivers/reset/reset-gemini.c | 112 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 120 insertions(+)
create mode 100644 drivers/reset/reset-gemini.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index f4cdfe94b9ec..a82e1a78de25 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -27,6 +27,13 @@ config RESET_BERLIN
help
This enables the reset controller driver for Marvell Berlin SoCs.
+config RESET_GEMINI
+ bool "Gemini Reset Driver" if COMPILE_TEST
+ default ARCH_GEMINI
+ select MFD_SYSCON
+ help
+ This enables the reset controller driver for Cortina Systems Gemini.
+
config RESET_LPC18XX
bool "LPC18xx/43xx Reset Driver" if COMPILE_TEST
default ARCH_LPC18XX
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 2cd3f6c45165..99e90ad18545 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
+obj-$(CONFIG_RESET_GEMINI) += reset-gemini.o
obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
obj-$(CONFIG_RESET_MESON) += reset-meson.o
obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
diff --git a/drivers/reset/reset-gemini.c b/drivers/reset/reset-gemini.c
new file mode 100644
index 000000000000..481facbb2709
--- /dev/null
+++ b/drivers/reset/reset-gemini.c
@@ -0,0 +1,112 @@
+/*
+ * Cortina Gemini Reset controller driver
+ * Copyright (c) 2017 Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+
+/**
+ * struct gemini_reset - gemini reset controller
+ * @map: regmap to access the containing system controller
+ * @dev: pointer back to device
+ * @rcdev: reset controller device
+ */
+struct gemini_reset {
+ struct regmap *map;
+ struct device *dev;
+ struct reset_controller_dev rcdev;
+};
+
+#define GEMINI_GLOBAL_SOFT_RESET 0x0c
+
+#define to_gemini_reset(p) \
+ container_of((p), struct gemini_reset, rcdev)
+
+/*
+ * This is a self-deasserting reset controller.
+ */
+static int gemini_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct gemini_reset *gr = to_gemini_reset(rcdev);
+
+ /* Manual says to always set BIT 30 to 1 */
+ return regmap_write(gr->map,
+ GEMINI_GLOBAL_SOFT_RESET,
+ BIT(30) | BIT(id));
+}
+
+static int gemini_reset_status(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct gemini_reset *gr = to_gemini_reset(rcdev);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(gr->map, GEMINI_GLOBAL_SOFT_RESET, &val);
+ if (ret)
+ return ret;
+
+ return !!(val & BIT(id));
+}
+
+static const struct reset_control_ops gemini_reset_ops = {
+ .reset = gemini_reset,
+ .status = gemini_reset_status,
+};
+
+static int gemini_reset_probe(struct platform_device *pdev)
+{
+ struct gemini_reset *gr;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *parent_np = np->parent;
+ int ret;
+
+ if (!parent_np) {
+ dev_err(dev, "missing parent node\n");
+ return -ENODEV;
+ }
+
+ gr = devm_kzalloc(dev, sizeof(*gr), GFP_KERNEL);
+ if (!gr)
+ return -ENOMEM;
+
+ gr->dev = dev;
+ gr->map = syscon_node_to_regmap(parent_np);
+ if (IS_ERR(gr->map)) {
+ dev_err(dev, "unable to get regmap");
+ return PTR_ERR(gr->map);
+ }
+ gr->rcdev.owner = THIS_MODULE;
+ gr->rcdev.nr_resets = 32;
+ gr->rcdev.ops = &gemini_reset_ops;
+ gr->rcdev.of_node = pdev->dev.of_node;
+
+ ret = devm_reset_controller_register(&pdev->dev, &gr->rcdev);
+ if (ret)
+ return ret;
+
+ dev_info(dev, "registered Gemini reset controller\n");
+ return 0;
+}
+
+static const struct of_device_id gemini_reset_dt_ids[] = {
+ { .compatible = "cortina,gemini-reset", },
+ { /* sentinel */ },
+};
+
+static struct platform_driver gemini_reset_driver = {
+ .probe = gemini_reset_probe,
+ .driver = {
+ .name = "gemini-reset",
+ .of_match_table = gemini_reset_dt_ids,
+ },
+};
+builtin_platform_driver(gemini_reset_driver);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] reset: Add DT bindings for the Gemini reset controller
From: Linus Walleij @ 2017-04-24 19:27 UTC (permalink / raw)
To: linux-arm-kernel
This is a simple reset controller in a single 32bit
register.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../bindings/reset/cortina,gemini-reset.txt | 59 ++++++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
new file mode 100644
index 000000000000..21aa12901774
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/cortina,gemini-reset.txt
@@ -0,0 +1,59 @@
+Cortina Gemini Reset Controller
+
+This reset controller is found in Cortina Systems CS3516 and
+the predecessor StorLink SL3516.
+
+Required properties:
+- compatible: "cortina,gemini-reset"
+- #reset-cells: Must be 1
+
+The Gemini reset controller must be a child node of the
+system controller. Apart from this it follows the standard reset
+controller bindings.
+
+Valid reset line values:
+
+0: DRAM controller
+1: Flash controller
+2: IDE controller
+3: RAID controller
+4: Security module
+5: GMAC0 (ethernet)
+6: GMAC1 (ethernet)
+7: PCI host bridge
+8: USB0 USB host controller
+9: USB1 USB host controller
+10: General DMA controller
+11: APB bridge
+12: LPC (Low Pin Count) controller
+13: LCD module
+14: Interrupt controller 0
+15: Interrupt controller 1
+16: RTC module
+17: Timer module
+18: UART controller
+19: SSP controller
+20: GPIO0 GPIO controller
+21: GPIO1 GPIO controller
+22: GPIO2 GPIO controller
+23: Watchdog timer
+24: External device reset
+25: CIR module (infrared)
+26: SATA0 SATA bridge
+27: SATA1 SATA bridge
+28: TVE TV Encoder module
+29: Reserved
+30: CPU1 reset
+31: Global soft reset
+
+Example:
+
+syscon: syscon at 40000000 {
+ compatible = "cortina,gemini-syscon", "syscon", "simple-mfd";
+ reg = <0x40000000 0x1000>;
+
+ reset-controller {
+ compatible = "cortina,gemini-reset";
+ #reset-cells = <1>;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."
From: Stefano Stabellini @ 2017-04-24 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1704191023120.31486@sstabellini-ThinkPad-X260>
Hi Russell,
Given the outstanding regression we need to fix as soon as possible,
I'll queue these patches on the xentip tree for 4.12.
Please shout if you disagree.
Thank you.
- Stefano
On Wed, 19 Apr 2017, Stefano Stabellini wrote:
> Hello Russell,
>
> Can I have your acked-by on the following fix (original patch is
> 1492117462-19886-1-git-send-email-sstabellini at kernel.org)?
>
> Thanks,
>
> Stefano
>
>
> On Tue, 18 Apr 2017, Catalin Marinas wrote:
> > On Thu, Apr 13, 2017 at 02:04:21PM -0700, Stefano Stabellini wrote:
> > > The following commit:
> > >
> > > commit 815dd18788fe0d41899f51b91d0560279cf16b0d
> > > Author: Bart Van Assche <bart.vanassche@sandisk.com>
> > > Date: Fri Jan 20 13:04:04 2017 -0800
> > >
> > > treewide: Consolidate get_dma_ops() implementations
> > >
> > > rearranges get_dma_ops in a way that xen_dma_ops are not returned when
> > > running on Xen anymore, dev->dma_ops is returned instead (see
> > > arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
> > > include/linux/dma-mapping.h:get_dma_ops).
> > >
> > > Fix the problem by storing dev->dma_ops in dev_archdata, and setting
> > > dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
> > > by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
> > > dev_archdata when needed. It also allows us to remove __generic_dma_ops
> > > from common headers.
> > >
> > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > > Tested-by: Julien Grall <julien.grall@arm.com>
> > > Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> > > CC: linux at armlinux.org.uk
> > > CC: catalin.marinas at arm.com
> > > CC: will.deacon at arm.com
> > > CC: boris.ostrovsky at oracle.com
> > > CC: jgross at suse.com
> > > CC: Julien Grall <julien.grall@arm.com>
> >
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> >
> >
> > > diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> > > index 220ba20..36ec9c8 100644
> > > --- a/arch/arm/include/asm/device.h
> > > +++ b/arch/arm/include/asm/device.h
> > > @@ -16,6 +16,9 @@ struct dev_archdata {
> > > #ifdef CONFIG_ARM_DMA_USE_IOMMU
> > > struct dma_iommu_mapping *mapping;
> > > #endif
> > > +#ifdef CONFIG_XEN
> > > + const struct dma_map_ops *dev_dma_ops;
> > > +#endif
> > > bool dma_coherent;
> > > };
> > >
> > > diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> > > index 7166569..680d3f3 100644
> > > --- a/arch/arm/include/asm/dma-mapping.h
> > > +++ b/arch/arm/include/asm/dma-mapping.h
> > > @@ -16,19 +16,9 @@
> > > extern const struct dma_map_ops arm_dma_ops;
> > > extern const struct dma_map_ops arm_coherent_dma_ops;
> > >
> > > -static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
> > > -{
> > > - if (dev && dev->dma_ops)
> > > - return dev->dma_ops;
> > > - return &arm_dma_ops;
> > > -}
> > > -
> > > static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> > > {
> > > - if (xen_initial_domain())
> > > - return xen_dma_ops;
> > > - else
> > > - return __generic_dma_ops(NULL);
> > > + return &arm_dma_ops;
> > > }
> > >
> > > #define HAVE_ARCH_DMA_SUPPORTED 1
> > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > > index 63eabb0..a614459 100644
> > > --- a/arch/arm/mm/dma-mapping.c
> > > +++ b/arch/arm/mm/dma-mapping.c
> > > @@ -2396,6 +2396,13 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> > > dma_ops = arm_get_dma_map_ops(coherent);
> > >
> > > set_dma_ops(dev, dma_ops);
> > > +
> > > +#ifdef CONFIG_XEN
> > > + if (xen_initial_domain()) {
> > > + dev->archdata.dev_dma_ops = dev->dma_ops;
> > > + dev->dma_ops = xen_dma_ops;
> > > + }
> > > +#endif
> > > }
> > >
> > > void arch_teardown_dma_ops(struct device *dev)
> > > diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
> > > index 73d5bab..5a5fa47 100644
> > > --- a/arch/arm64/include/asm/device.h
> > > +++ b/arch/arm64/include/asm/device.h
> > > @@ -20,6 +20,9 @@ struct dev_archdata {
> > > #ifdef CONFIG_IOMMU_API
> > > void *iommu; /* private IOMMU data */
> > > #endif
> > > +#ifdef CONFIG_XEN
> > > + const struct dma_map_ops *dev_dma_ops;
> > > +#endif
> > > bool dma_coherent;
> > > };
> > >
> > > diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
> > > index 505756c..5392dbe 100644
> > > --- a/arch/arm64/include/asm/dma-mapping.h
> > > +++ b/arch/arm64/include/asm/dma-mapping.h
> > > @@ -27,11 +27,8 @@
> > > #define DMA_ERROR_CODE (~(dma_addr_t)0)
> > > extern const struct dma_map_ops dummy_dma_ops;
> > >
> > > -static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
> > > +static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> > > {
> > > - if (dev && dev->dma_ops)
> > > - return dev->dma_ops;
> > > -
> > > /*
> > > * We expect no ISA devices, and all other DMA masters are expected to
> > > * have someone call arch_setup_dma_ops at device creation time.
> > > @@ -39,14 +36,6 @@ static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
> > > return &dummy_dma_ops;
> > > }
> > >
> > > -static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> > > -{
> > > - if (xen_initial_domain())
> > > - return xen_dma_ops;
> > > - else
> > > - return __generic_dma_ops(NULL);
> > > -}
> > > -
> > > void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> > > const struct iommu_ops *iommu, bool coherent);
> > > #define arch_setup_dma_ops arch_setup_dma_ops
> > > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> > > index 81cdb2e..7f8b37e 100644
> > > --- a/arch/arm64/mm/dma-mapping.c
> > > +++ b/arch/arm64/mm/dma-mapping.c
> > > @@ -977,4 +977,11 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> > >
> > > dev->archdata.dma_coherent = coherent;
> > > __iommu_setup_dma_ops(dev, dma_base, size, iommu);
> > > +
> > > +#ifdef CONFIG_XEN
> > > + if (xen_initial_domain()) {
> > > + dev->archdata.dev_dma_ops = dev->dma_ops;
> > > + dev->dma_ops = xen_dma_ops;
> > > + }
> > > +#endif
> > > }
> > > diff --git a/include/xen/arm/page-coherent.h b/include/xen/arm/page-coherent.h
> > > index 95ce6ac..b0a2bfc 100644
> > > --- a/include/xen/arm/page-coherent.h
> > > +++ b/include/xen/arm/page-coherent.h
> > > @@ -2,8 +2,16 @@
> > > #define _ASM_ARM_XEN_PAGE_COHERENT_H
> > >
> > > #include <asm/page.h>
> > > +#include <asm/dma-mapping.h>
> > > #include <linux/dma-mapping.h>
> > >
> > > +static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
> > > +{
> > > + if (dev && dev->archdata.dev_dma_ops)
> > > + return dev->archdata.dev_dma_ops;
> > > + return get_arch_dma_ops(NULL);
> > > +}
> > > +
> > > void __xen_dma_map_page(struct device *hwdev, struct page *page,
> > > dma_addr_t dev_addr, unsigned long offset, size_t size,
> > > enum dma_data_direction dir, unsigned long attrs);
>
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Marc Zyngier @ 2017-04-24 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424185909.GD2137@mai>
On 24/04/17 19:59, Daniel Lezcano wrote:
> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
>> On 24/04/17 15:01, Daniel Lezcano wrote:
>>> In the next changes, we track when the interrupts occur in order to
>>> statistically compute when is supposed to happen the next interrupt.
>>>
>>> In all the interruptions, it does not make sense to store the timer interrupt
>>> occurences and try to predict the next interrupt as when know the expiration
>>> time.
>>>
>>> The request_irq() has a irq flags parameter and the timer drivers use it to
>>> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
>>> Based on this flag, we can discard these interrupts when tracking them.
>>>
>>> But, the API request_percpu_irq does not allow to pass a flag, hence specifying
>>> if the interrupt type is a timer.
>>>
>>> Add a function request_percpu_irq_flags() where we can specify the flags. The
>>> request_percpu_irq() function is changed to be a wrapper to
>>> request_percpu_irq_flags() passing a zero flag parameter.
>>>
>>> Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
>>> instead with the IRQF_TIMER flag set.
>>>
>>> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
>>> flag (or zero) is a valid parameter to be passed to the
>>> request_percpu_irq_flags() function.
>>
>> [...]
>>
>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>> index 35d7100..602e0a8 100644
>>> --- a/virt/kvm/arm/arch_timer.c
>>> +++ b/virt/kvm/arm/arch_timer.c
>>> @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
>>> host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
>>> }
>>>
>>> - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
>>> - "kvm guest timer", kvm_get_running_vcpus());
>>> + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
>>> + IRQF_TIMER, "kvm guest timer",
>>> + kvm_get_running_vcpus());
>>> if (err) {
>>> kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
>>> host_vtimer_irq, err);
>>>
>>
>> How is that useful? This timer is controlled by the guest OS, and not
>> the host kernel. Can you explain how you intend to make use of that
>> information in this case?
>
> Isn't it a source of interruption on the host kernel?
Only to cause an exit of the VM, and not under the control of the host.
This isn't triggering any timer related action on the host code either.
Your patch series seems to assume some kind of predictability of the
timer interrupt, which can make sense on the host. Here, this interrupt
is shared among *all* guests running on this system.
Maybe you could explain why you think this interrupt is relevant to what
you're trying to achieve?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm64: Add ASM modifier for xN register operands
From: Matthias Kaehlcke @ 2017-04-24 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424173413.GW12323@arm.com>
Hi,
El Mon, Apr 24, 2017 at 06:34:14PM +0100 Will Deacon ha dit:
> On Mon, Apr 24, 2017 at 06:22:51PM +0100, Ard Biesheuvel wrote:
> > On 24 April 2017 at 18:00, Will Deacon <will.deacon@arm.com> wrote:
> > > Hi Matthias,
> > >
> > > On Thu, Apr 20, 2017 at 11:30:53AM -0700, Matthias Kaehlcke wrote:
> > >> Many inline assembly statements don't include the 'x' modifier when
> > >> using xN registers as operands. This is perfectly valid, however it
> > >> causes clang to raise warnings like this:
> > >>
> > >> warning: value size does not match register size specified by the
> > >> constraint and modifier [-Wasm-operand-widths]
> > >> ...
> > >> arch/arm64/include/asm/barrier.h:62:23: note: expanded from macro
> > >> '__smp_store_release'
> > >> asm volatile ("stlr %1, %0"
> > >
> > > If I understand this correctly, then the warning is emitted when we pass
> > > in a value smaller than 64-bit, but refer to %<n> without a modifier
> > > in the inline asm.
To be honest I don't understand completely when clang emits the
warning and when not. I'm probably just not fluent enough in (inline)
assembly to see the pattern.
> > > However, if that's the case then I don't understand why:
> > >
> > >> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> > >> index 0c00c87bb9dd..021e1733da0c 100644
> > >> --- a/arch/arm64/include/asm/io.h
> > >> +++ b/arch/arm64/include/asm/io.h
> > >> @@ -39,33 +39,33 @@
> > >> #define __raw_writeb __raw_writeb
> > >> static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
> > >> {
> > >> - asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
> > >> + asm volatile("strb %w0, [%x1]" : : "rZ" (val), "r" (addr));
> > >
> > > is necessary. addr is a pointer type, so is 64-bit.
> > >
> > > Given that the scattergun nature of this patch implies that you've been
> > > fixing the places where warnings are reported, then I'm confused as to
> > > why a warning is generated for the case above.
In this case actually no warning is generated.
My idea was to add the modifier in all cases for consistency, not only
to get rid of the warnings. I'm fine with only addressing the warnings
if that is preferred.
> > AIUI, Clang now always complains for missing register width modifiers,
> > not just for placeholders that resolve to a 32-bit (or smaller)
> > quantity.
>
> Ok, in which case this patch is incomplete as there's a bunch of asm that
> isn't updated (e.g. spinlock.h).
Sorry, my grep pattern was a bit naive and didn't take multiline
inline assembly into account.
If you are ok with adding modifiers everywhere I'll add the missing
bits, otherwise I'll rework the patch to only change the instances
where clang emits the warning.
Cheers
Matthias
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Russell King - ARM Linux @ 2017-04-24 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1058502523.15283.1493055747531@email.1und1.de>
On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > What I can't see is how changing flush_dcache_page() has possibly broken
> > this: it seems to imply that you're getting flush_dcache_page() somehow
> > called inbetween mapping it for DMA, using it for DMA and CPU accesses
> > occuring. However, the driver doesn't call flush_dcache_page() other
> > than through get_user_pages() - and since dma_map_sg() is used in that
> > path, it should be fine.
> >
> > So, I don't have much to offer.
> >
> > However, flush_dcache_page() is probably still a tad heavy - it currently
> > flushes to the point of coherency, but it's really about making sure that
> > the user vs kernel mappings are coherent, not about device coherency.
> > That's the role of the DMA API.
>
> Currently i don't care too much about performance. More important is to
> fix this regression, because i'm not able to verify the function of this
> driver efficiently.
This is a driver in staging, and the reason its in staging is because it
has problems. This is just another example of another problem it has...
Yes, the regression is regrettable, but I don't think it's something to
get hung up on.
> I'm thinking about 2 options:
>
> 1) add a force parameter to flush_dcache_page() which make it possible
> to override the new logic
> 2) create a second version of flush_dcache_page() with the old behavior
Neither, really, because, as I've already explained, flush_dcache_page()
has nothing what so ever to do with DMA coherence - and if a driver
breaks because we change its semantic slightly (but still in a compliant
way) then it's uncovered a latent bug in _that_ driver.
Rather than trying to "fix" flush_dcache_page() to work how this driver
wants it to (which is a totally crazy thing to propose - we can't go
shoe-horning driver specific behaviour into these generic flushing
functions), it would be much better to work out why the driver has
broken.
I see the kernel driver has its own logging (using vchiq_log_info() etc?)
maybe a starting point would be to compare the output from a working
kernel with a non-working kernel to get more of an idea where the problem
actually is?
What I'm willing to do is to temporarily drop the offending patch for
the next merge window to give more time for this driver to be debugged,
but I will want to re-apply it after that merge window closes.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Daniel Lezcano @ 2017-04-24 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <398f3f3d-c567-0f1f-1a43-9b8d5805d5fd@arm.com>
On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote:
> On 24/04/17 15:01, Daniel Lezcano wrote:
> > In the next changes, we track when the interrupts occur in order to
> > statistically compute when is supposed to happen the next interrupt.
> >
> > In all the interruptions, it does not make sense to store the timer interrupt
> > occurences and try to predict the next interrupt as when know the expiration
> > time.
> >
> > The request_irq() has a irq flags parameter and the timer drivers use it to
> > pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> > Based on this flag, we can discard these interrupts when tracking them.
> >
> > But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> > if the interrupt type is a timer.
> >
> > Add a function request_percpu_irq_flags() where we can specify the flags. The
> > request_percpu_irq() function is changed to be a wrapper to
> > request_percpu_irq_flags() passing a zero flag parameter.
> >
> > Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> > instead with the IRQF_TIMER flag set.
> >
> > For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> > flag (or zero) is a valid parameter to be passed to the
> > request_percpu_irq_flags() function.
>
> [...]
>
> > diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> > index 35d7100..602e0a8 100644
> > --- a/virt/kvm/arm/arch_timer.c
> > +++ b/virt/kvm/arm/arch_timer.c
> > @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
> > host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
> > }
> >
> > - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
> > - "kvm guest timer", kvm_get_running_vcpus());
> > + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
> > + IRQF_TIMER, "kvm guest timer",
> > + kvm_get_running_vcpus());
> > if (err) {
> > kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
> > host_vtimer_irq, err);
> >
>
> How is that useful? This timer is controlled by the guest OS, and not
> the host kernel. Can you explain how you intend to make use of that
> information in this case?
Isn't it a source of interruption on the host kernel?
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 2/2] clk: Add Gemini SoC clock controller
From: Linus Walleij @ 2017-04-24 18:55 UTC (permalink / raw)
To: linux-arm-kernel
The Cortina Systems Gemini (SL3516/CS3516) has an on-chip clock
controller that derive all clocks from a single crystal, using some
documented and some undocumented PLLs, half dividers, counters and
gates. This is a best attempt to construct a clock driver for the
clocks so at least we can gate off unused hardware and driver the
PCI bus clock.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/clk/Kconfig | 7 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-gemini.c | 363 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 371 insertions(+)
create mode 100644 drivers/clk/clk-gemini.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9356ab4b7d76..9e7619f9bf0e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -118,6 +118,13 @@ config COMMON_CLK_CS2000_CP
help
If you say yes here you get support for the CS2000 clock multiplier.
+config COMMON_CLK_GEMINI
+ bool "Clock driver for Cortina Systems Gemini SoC"
+ select MFD_SYSCON
+ ---help---
+ This driver supports the SoC clocks on the Cortina Systems Gemini
+ platform, also known as SL3516 or CS3516.
+
config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE || COMPILE_TEST
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 92c12b86c2e8..e100d911a554 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_COMMON_CLK_CDCE925) += clk-cdce925.o
obj-$(CONFIG_ARCH_CLPS711X) += clk-clps711x.o
obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
+obj-$(CONFIG_COMMON_CLK_GEMINI) += clk-gemini.o
obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_ARCH_MB86S7X) += clk-mb86s7x.o
diff --git a/drivers/clk/clk-gemini.c b/drivers/clk/clk-gemini.c
new file mode 100644
index 000000000000..f4c6fb40c0cb
--- /dev/null
+++ b/drivers/clk/clk-gemini.c
@@ -0,0 +1,363 @@
+/*
+ * Cortina Gemini Clock Controller driver
+ * Copyright (c) 2017 Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#define pr_fmt(fmt) "clk-gemini: " fmt
+
+#include <linux/clkdev.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <dt-bindings/clock/cortina,gemini-clock.h>
+
+/* Globally visible clocks */
+static DEFINE_SPINLOCK(gemini_clk_lock);
+static struct clk *gemini_clks[GEMINI_NUM_CLKS];
+static struct clk_onecell_data gemini_clk_data;
+
+#define GEMINI_GLOBAL_STATUS 0x04
+#define PLL_OSC_SEL BIT(30)
+#define AHBSPEED_SHIFT (15)
+#define AHBSPEED_MASK 0x07
+#define CPU_AHB_RATIO_SHIFT (18)
+#define CPU_AHB_RATIO_MASK 0x03
+
+#define GEMINI_GLOBAL_PLL_CONTROL 0x08
+
+#define GEMINI_GLOBAL_MISC_CONTROL 0x30
+#define PCI_CLK_66MHZ BIT(18)
+#define PCI_CLK_OE BIT(17)
+
+#define GEMINI_GLOBAL_CLOCK_CONTROL 0x34
+#define PCI_CLKRUN_EN BIT(16)
+#define TVC_HALFDIV_SHIFT (24)
+#define TVC_HALFDIV_MASK 0x1f
+#define SECURITY_CLK_SEL BIT(29)
+
+#define GEMINI_GLOBAL_PCI_DLL_CONTROL 0x44
+#define PCI_DLL_BYPASS BIT(31)
+#define PCI_DLL_TAP_SEL_MASK 0x1f
+
+struct gemini_gate_data {
+ u8 bit_idx;
+ const char *name;
+ const char *parent_name;
+ unsigned long flags;
+};
+
+/**
+ * struct clk_gemini_pci - Gemini PCI clock
+ * @hw: corresponding clock hardware entry
+ * @map: regmap to access the registers
+ * @rate: current rate
+ */
+struct clk_gemini_pci {
+ struct clk_hw hw;
+ struct regmap *map;
+ unsigned long rate;
+};
+
+/*
+ * FIXME: some clocks are marked as CLK_IGNORE_UNUSED: this is
+ * because their kernel drivers lack proper clock handling so we
+ * need to avoid them being gated off by default. Remove this as
+ * the drivers get fixed to handle clocks properly.
+ *
+ * The DDR controller may never have a driver, but certainly must
+ * not be gated off.
+ */
+static const struct gemini_gate_data gemini_gates[] __initconst = {
+ { 1, "security-gate", "secdiv", 0 },
+ { 2, "gmac0-gate", "ahb", 0 },
+ { 3, "gmac1-gate", "ahb", 0 },
+ { 4, "sata0-gate", "ahb", 0 },
+ { 5, "sata1-gate", "ahb", 0 },
+ { 6, "usb0-gate", "ahb", 0 },
+ { 7, "usb1-gate", "ahb", 0 },
+ { 8, "ide-gate", "ahb", 0 },
+ { 9, "pci-gate", "ahb", 0 },
+ { 10, "ddr-gate", "ahb", CLK_IGNORE_UNUSED },
+ { 11, "flash-gate", "ahb", CLK_IGNORE_UNUSED },
+ { 12, "tvc-gate", "ahb", 0 },
+ { 13, "boot-gate", "apb", 0 },
+};
+
+#define to_pciclk(_hw) container_of(_hw, struct clk_gemini_pci, hw)
+
+static unsigned long gemini_pci_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_gemini_pci *pciclk = to_pciclk(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(pciclk->map, GEMINI_GLOBAL_MISC_CONTROL, &val);
+ if (ret)
+ return ret;
+ if (val & PCI_CLK_66MHZ)
+ return 66000000;
+ return 33000000;
+}
+
+static long gemini_pci_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ /* We support 33 and 66 MHz */
+ if (rate < 48000000)
+ return 33000000;
+ return 66000000;
+}
+
+static int gemini_pci_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_gemini_pci *pciclk = to_pciclk(hw);
+
+ if (rate == 33000000)
+ return regmap_update_bits(pciclk->map,
+ GEMINI_GLOBAL_MISC_CONTROL,
+ PCI_CLK_66MHZ, 0);
+ if (rate == 66000000)
+ return regmap_update_bits(pciclk->map,
+ GEMINI_GLOBAL_MISC_CONTROL,
+ 0, PCI_CLK_66MHZ);
+ return -EINVAL;
+}
+
+static int gemini_pci_enable(struct clk_hw *hw)
+{
+ struct clk_gemini_pci *pciclk = to_pciclk(hw);
+
+ regmap_update_bits(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL,
+ 0, PCI_CLKRUN_EN);
+ regmap_update_bits(pciclk->map,
+ GEMINI_GLOBAL_MISC_CONTROL,
+ 0, PCI_CLK_OE);
+ return 0;
+}
+
+static void gemini_pci_disable(struct clk_hw *hw)
+{
+ struct clk_gemini_pci *pciclk = to_pciclk(hw);
+
+ regmap_update_bits(pciclk->map,
+ GEMINI_GLOBAL_MISC_CONTROL,
+ PCI_CLK_OE, 0);
+ regmap_update_bits(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL,
+ PCI_CLKRUN_EN, 0);
+}
+
+static int gemini_pci_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gemini_pci *pciclk = to_pciclk(hw);
+ int ret;
+ unsigned int val;
+
+ ret = regmap_read(pciclk->map, GEMINI_GLOBAL_CLOCK_CONTROL, &val);
+ if (ret)
+ return ret;
+
+ return !!(val & PCI_CLKRUN_EN);
+}
+
+static const struct clk_ops gemini_pci_clk_ops = {
+ .recalc_rate = gemini_pci_recalc_rate,
+ .round_rate = gemini_pci_round_rate,
+ .set_rate = gemini_pci_set_rate,
+ .enable = gemini_pci_enable,
+ .disable = gemini_pci_disable,
+ .is_enabled = gemini_pci_is_enabled,
+};
+
+static struct clk *gemini_pci_clk_setup(const char *name,
+ const char *parent_name,
+ struct regmap *map)
+{
+ struct clk_gemini_pci *pciclk;
+ struct clk_init_data init;
+ struct clk *clk;
+
+ pciclk = kzalloc(sizeof(*pciclk), GFP_KERNEL);
+ if (!pciclk)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = &gemini_pci_clk_ops;
+ init.flags = 0;
+ init.parent_names = (parent_name ? &parent_name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+ pciclk->map = map;
+ pciclk->hw.init = &init;
+
+ clk = clk_register(NULL, &pciclk->hw);
+ if (IS_ERR(clk))
+ kfree(pciclk);
+
+ return clk;
+}
+
+static void __init gemini_cc_init(struct device_node *np)
+{
+ struct device_node *parent_np = np->parent;
+ void __iomem *base;
+ struct regmap *map;
+ struct clk *clk;
+ unsigned int mult, div;
+ unsigned long freq;
+ u32 val;
+ int ret;
+ int i;
+
+ if (!parent_np) {
+ pr_err("no parent\n");
+ return;
+ }
+ /* Remap the system controller for the exclusive register */
+ base = of_iomap(parent_np, 0);
+ if (!base) {
+ pr_err("no memory base\n");
+ return;
+ }
+ map = syscon_node_to_regmap(parent_np);
+ if (IS_ERR(map)) {
+ pr_err("no syscon regmap\n");
+ return;
+ }
+
+ /* RTC clock 32768 Hz */
+ clk = clk_register_fixed_rate(NULL, "rtc", NULL, CLK_IGNORE_UNUSED,
+ 32768);
+ gemini_clks[GEMINI_CLK_RTC] = clk;
+
+ ret = regmap_read(map, GEMINI_GLOBAL_STATUS, &val);
+ if (ret) {
+ pr_err("failed to read global status register\n");
+ return;
+ }
+
+ /*
+ * XTAL is the crystal oscillator, 60 or 30 MHz selected from
+ * strap pin E6
+ */
+ if (val & PLL_OSC_SEL)
+ freq = 30000000;
+ else
+ freq = 60000000;
+ clk = clk_register_fixed_rate(NULL, "xtal", NULL, CLK_IGNORE_UNUSED,
+ freq);
+ pr_info("main crystal @%lu MHz\n", (freq/1000000));
+
+ /* VCO clock derived from the crystal */
+ mult = 13 + ((val >> AHBSPEED_SHIFT) & AHBSPEED_MASK);
+ div = 2;
+ /* If we run on 30 Mhz crystal we have to multiply with two */
+ if (val & PLL_OSC_SEL)
+ mult *= 2;
+ clk = clk_register_fixed_factor(NULL, "vco", "xtal", CLK_IGNORE_UNUSED,
+ mult, div);
+
+ /* The AHB clock is always 1/3 of the VCO */
+ clk = clk_register_fixed_factor(NULL, "ahb", "vco",
+ CLK_IGNORE_UNUSED, 1, 3);
+ gemini_clks[GEMINI_CLK_AHB] = clk;
+
+ /* The APB clock is always 1/6 of the AHB */
+ clk = clk_register_fixed_factor(NULL, "apb", "ahb",
+ CLK_IGNORE_UNUSED, 1, 6);
+ gemini_clks[GEMINI_CLK_APB] = clk;
+
+ /* CPU clock derived as a fixed ratio from the AHB clock */
+ switch ((val >> CPU_AHB_RATIO_SHIFT) & CPU_AHB_RATIO_MASK) {
+ case 0x0:
+ /* 1x */
+ mult = 1;
+ div = 1;
+ break;
+ case 0x1:
+ /* 1.5x */
+ mult = 3;
+ div = 2;
+ break;
+ case 0x2:
+ /* 1.85x */
+ mult = 24;
+ div = 13;
+ break;
+ case 0x3:
+ /* 2x */
+ mult = 2;
+ div = 1;
+ break;
+ }
+ clk = clk_register_fixed_factor(NULL, "cpu", "ahb",
+ CLK_IGNORE_UNUSED, mult, div);
+ gemini_clks[GEMINI_CLK_CPU] = clk;
+
+ /* Security clock is 1:1 or 0.75 of APB */
+ ret = regmap_read(map, GEMINI_GLOBAL_CLOCK_CONTROL, &val);
+ if (ret) {
+ pr_err("failed to read global clock control register\n");
+ return;
+ }
+ if (val & SECURITY_CLK_SEL) {
+ mult = 1;
+ div = 1;
+ } else {
+ mult = 3;
+ div = 4;
+ }
+ clk = clk_register_fixed_factor(NULL, "secdiv", "ahb",
+ 0, mult, div);
+
+ /*
+ * These are the leaf gates, at boot no clocks are gated.
+ */
+ for (i = 0; i < ARRAY_SIZE(gemini_gates); i++) {
+ const struct gemini_gate_data *gd;
+
+ gd = &gemini_gates[i];
+ gemini_clks[GEMINI_CLK_GATES + i] =
+ clk_register_gate(NULL, gd->name,
+ gd->parent_name,
+ gd->flags,
+ base + GEMINI_GLOBAL_CLOCK_CONTROL,
+ gd->bit_idx,
+ CLK_GATE_SET_TO_DISABLE,
+ &gemini_clk_lock);
+ }
+
+ /*
+ * The TV Interface Controller has a 5-bit half divider register.
+ * This clock is supposed to be 27MHz as this is an exact multiple
+ * of PAL and NTSC frequencies. The register is undocumented :(
+ * FIXME: figure out the parent and how the divider works.
+ */
+ mult = 1;
+ div = ((val >> TVC_HALFDIV_SHIFT) & TVC_HALFDIV_MASK);
+ pr_debug("TVC half divider value = %d\n", div);
+ div += 1;
+ clk = clk_register_fixed_rate(NULL, "tvcdiv", "xtal", 0, 27000000);
+ gemini_clks[GEMINI_CLK_TVC] = clk;
+
+ /* FIXME: very unclear what the parent is */
+ clk = gemini_pci_clk_setup("PCI", "xtal", map);
+ gemini_clks[GEMINI_CLK_PCI] = clk;
+
+ /* FIXME: very unclear what the parent is */
+ clk = clk_register_fixed_rate(NULL, "uart", "xtal", CLK_IGNORE_UNUSED,
+ 48000000);
+ gemini_clks[GEMINI_CLK_UART] = clk;
+
+ /* Register the clocks to be accessed by the device tree */
+ gemini_clk_data.clks = gemini_clks;
+ gemini_clk_data.clk_num = ARRAY_SIZE(gemini_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, &gemini_clk_data);
+}
+CLK_OF_DECLARE_DRIVER(gemini_cc, "cortina,gemini-clock-controller",
+ gemini_cc_init);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] clk: Add bindings for the Gemini Clock Controller
From: Linus Walleij @ 2017-04-24 18:55 UTC (permalink / raw)
To: linux-arm-kernel
This adds device tree bindings and a header for the Gemini SoC
Clock Controller.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../clock/cortina,gemini-clock-controller.txt | 25 +++++++++++++++++++
include/dt-bindings/clock/cortina,gemini-clock.h | 29 ++++++++++++++++++++++
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
create mode 100644 include/dt-bindings/clock/cortina,gemini-clock.h
diff --git a/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
new file mode 100644
index 000000000000..7af84acfcbce
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/cortina,gemini-clock-controller.txt
@@ -0,0 +1,25 @@
+Clock bindings for the Cortina Systems Gemini SoC Clock Controller
+
+Required properties :
+- compatible : shall contain the following:
+ "cortina,gemini-clock-controller"
+- #clock-cells should be <1>
+
+The Gemini clock controller needs to be placed as a subnode of the
+system controller.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/cortina,gemini-clock.h header and can be used in device
+tree sources.
+
+Example:
+
+syscon: syscon at 40000000 {
+ compatible = "cortina,gemini-syscon", "syscon", "simple-mfd";
+ reg = <0x40000000 0x1000>;
+
+ clock-controller {
+ compatible = "cortina,gemini-clock-controller";
+ #clock-cells = <1>;
+ };
+};
diff --git a/include/dt-bindings/clock/cortina,gemini-clock.h b/include/dt-bindings/clock/cortina,gemini-clock.h
new file mode 100644
index 000000000000..acf5cd550b0c
--- /dev/null
+++ b/include/dt-bindings/clock/cortina,gemini-clock.h
@@ -0,0 +1,29 @@
+#ifndef DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
+#define DT_BINDINGS_CORTINA_GEMINI_CLOCK_H
+
+/* RTC, AHB, APB, CPU, PCI, TVC, UART clocks and 13 gates */
+#define GEMINI_NUM_CLKS 20
+
+#define GEMINI_CLK_RTC 0
+#define GEMINI_CLK_AHB 1
+#define GEMINI_CLK_APB 2
+#define GEMINI_CLK_CPU 3
+#define GEMINI_CLK_PCI 4
+#define GEMINI_CLK_TVC 5
+#define GEMINI_CLK_UART 6
+#define GEMINI_CLK_GATES 7
+#define GEMINI_CLK_GATE_SECURITY 7
+#define GEMINI_CLK_GATE_GMAC0 8
+#define GEMINI_CLK_GATE_GMAC1 9
+#define GEMINI_CLK_GATE_SATA0 10
+#define GEMINI_CLK_GATE_SATA1 11
+#define GEMINI_CLK_GATE_USB0 12
+#define GEMINI_CLK_GATE_USB1 13
+#define GEMINI_CLK_GATE_IDE 14
+#define GEMINI_CLK_GATE_PCI 15
+#define GEMINI_CLK_GATE_DDR 16
+#define GEMINI_CLK_GATE_FLASH 17
+#define GEMINI_CLK_GATE_TVC 18
+#define GEMINI_CLK_GATE_BOOT 19
+
+#endif /* DT_BINDINGS_CORTINA_GEMINI_CLOCK_H */
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] arm64:vdso: Rewrite gettimeofday into C.
From: Andrew Pinski @ 2017-04-24 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424152106.GG25449@e104818-lin.cambridge.arm.com>
On 4/24/2017 8:21 AM, Catalin Marinas wrote:
> On Sun, Apr 23, 2017 at 04:47:00PM -0700, Andrew Pinski wrote:
>> This allows the compiler to optimize the divide by 1000.
>> And remove the other divide.
>>
>> On ThunderX, gettimeofday improves by 32%. On ThunderX 2,
>> gettimeofday improves by 18%.
> Is this with or without the second patch (removing the ISB)?
Hi Caralin,
This is without the second patch that removes the ISB. Maybe I
should not have sent them as the same patch set to make it clear that
way. As I tried to make a mention of, the improvement is the compiler
not outputting the udiv instruction for the division by 1000. I
should also mention I tested this patch on a softiron using GCC 4.8.5
(SUSE's default compiler) and the performance was the same; GCC 4.8.5
emits udiv still in this case. I did not try a newer compiler to see
the performance there.
Thanks,
Andrew Pinski
>
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Marc Zyngier @ 2017-04-24 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493042494-14057-1-git-send-email-daniel.lezcano@linaro.org>
On 24/04/17 15:01, Daniel Lezcano wrote:
> In the next changes, we track when the interrupts occur in order to
> statistically compute when is supposed to happen the next interrupt.
>
> In all the interruptions, it does not make sense to store the timer interrupt
> occurences and try to predict the next interrupt as when know the expiration
> time.
>
> The request_irq() has a irq flags parameter and the timer drivers use it to
> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> Based on this flag, we can discard these interrupts when tracking them.
>
> But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> if the interrupt type is a timer.
>
> Add a function request_percpu_irq_flags() where we can specify the flags. The
> request_percpu_irq() function is changed to be a wrapper to
> request_percpu_irq_flags() passing a zero flag parameter.
>
> Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> instead with the IRQF_TIMER flag set.
>
> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> flag (or zero) is a valid parameter to be passed to the
> request_percpu_irq_flags() function.
[...]
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 35d7100..602e0a8 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void)
> host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
> }
>
> - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
> - "kvm guest timer", kvm_get_running_vcpus());
> + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler,
> + IRQF_TIMER, "kvm guest timer",
> + kvm_get_running_vcpus());
> if (err) {
> kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
> host_vtimer_irq, err);
>
How is that useful? This timer is controlled by the guest OS, and not
the host kernel. Can you explain how you intend to make use of that
information in this case?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 2/2] arm64: Add workaround for Cavium Thunder erratum 30115
From: David Daney @ 2017-04-24 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424184250.667-1-david.daney@cavium.com>
Some Cavium Thunder CPUs suffer a problem where a KVM guest may
inadvertently cause the host kernel to quit receiving interrupts.
The workaround is to toggle the group-1 interrupt enable on each exit
from the guest.
Signed-off-by: David Daney <david.daney@cavium.com>
---
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 11 +++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu_errata.c | 21 +++++++++++++++++++++
arch/arm64/kvm/hyp/switch.c | 9 +++++++++
5 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 10f2ddd..f5f93dc 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -62,6 +62,7 @@ stable kernels.
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
+| Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
| | | | |
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
| | | | |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e7f043e..fe29277 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -480,6 +480,17 @@ config CAVIUM_ERRATUM_27456
If unsure, say Y.
+config CAVIUM_ERRATUM_30115
+ bool "Cavium erratum 30115: Guest may disable interrupts in host"
+ default y
+ help
+ On ThunderX T88 pass 1.x through 2.2, T81 pass 1.0 through
+ 1.2, and T83 Pass 1.0, KVM guest execution may disable
+ interrupts in host. The fix is to reenable group 1
+ interrupts when returning to host mode.
+
+ If unsure, say Y.
+
config QCOM_FALKOR_ERRATUM_1003
bool "Falkor E1003: Incorrect translation due to ASID change"
default y
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index b3aab8a..8d2272c 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -38,7 +38,8 @@
#define ARM64_WORKAROUND_REPEAT_TLBI 17
#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 18
#define ARM64_WORKAROUND_858921 19
+#define ARM64_WORKAROUND_CAVIUM_30115 20
-#define ARM64_NCAPS 20
+#define ARM64_NCAPS 21
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 2ed2a76..0e27f86 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -133,6 +133,27 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x00),
},
#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+ {
+ /* Cavium ThunderX, T88 pass 1.x - 2.2 */
+ .desc = "Cavium erratum 30115",
+ .capability = ARM64_WORKAROUND_CAVIUM_30115,
+ MIDR_RANGE(MIDR_THUNDERX, 0x00,
+ (1 << MIDR_VARIANT_SHIFT) | 2),
+ },
+ {
+ /* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+ .desc = "Cavium erratum 30115",
+ .capability = ARM64_WORKAROUND_CAVIUM_30115,
+ MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x02),
+ },
+ {
+ /* Cavium ThunderX, T83 pass 1.0 */
+ .desc = "Cavium erratum 30115",
+ .capability = ARM64_WORKAROUND_CAVIUM_30115,
+ MIDR_RANGE(MIDR_THUNDERX_83XX, 0x00, 0x00),
+ },
+#endif
{
.desc = "Mismatched cache line size",
.capability = ARM64_MISMATCHED_CACHE_LINE_SIZE,
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index aede165..c174b5f 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -17,11 +17,13 @@
#include <linux/types.h>
#include <linux/jump_label.h>
+#include <linux/irqchip/arm-gic-v3.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
#include <asm/kvm_hyp.h>
#include <asm/fpsimd.h>
+#include <asm/cpufeature.h>
static bool __hyp_text __fpsimd_enabled_nvhe(void)
{
@@ -166,6 +168,13 @@ static void __hyp_text __vgic_save_state(struct kvm_vcpu *vcpu)
__vgic_v2_save_state(vcpu);
write_sysreg(read_sysreg(hcr_el2) & ~HCR_INT_OVERRIDE, hcr_el2);
+
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+ if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_30115)) {
+ gic_write_grpen1(0);
+ gic_write_grpen1(1);
+ }
+#endif
}
static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: Add MIDR values for Cavium cn83XX SoCs
From: David Daney @ 2017-04-24 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424184250.667-1-david.daney@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 0984d1b..235e77d 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -86,6 +86,7 @@
#define CAVIUM_CPU_PART_THUNDERX 0x0A1
#define CAVIUM_CPU_PART_THUNDERX_81XX 0x0A2
+#define CAVIUM_CPU_PART_THUNDERX_83XX 0x0A3
#define BRCM_CPU_PART_VULCAN 0x516
@@ -96,6 +97,7 @@
#define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A73)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
#ifndef __ASSEMBLY__
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] arm64: Workaround for Thunder KVM hang issues.
From: David Daney @ 2017-04-24 18:42 UTC (permalink / raw)
To: linux-arm-kernel
We have discovered in rare circumstances, guest execution may result
in host not receiving one or more interrupts. This does not otherwise
affect guest or host execution and/or isolation.
David Daney (2):
arm64: Add MIDR values for Cavium cn83XX SoCs
arm64: Add workaround for Cavium Thunder erratum 30115
Documentation/arm64/silicon-errata.txt | 1 +
arch/arm64/Kconfig | 11 +++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/cputype.h | 2 ++
arch/arm64/kernel/cpu_errata.c | 21 +++++++++++++++++++++
arch/arm64/kvm/hyp/switch.c | 9 +++++++++
6 files changed, 46 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request
From: Krzysztof Kozlowski @ 2017-04-24 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493042494-14057-1-git-send-email-daniel.lezcano@linaro.org>
On Mon, Apr 24, 2017 at 04:01:31PM +0200, Daniel Lezcano wrote:
> In the next changes, we track when the interrupts occur in order to
> statistically compute when is supposed to happen the next interrupt.
>
> In all the interruptions, it does not make sense to store the timer interrupt
> occurences and try to predict the next interrupt as when know the expiration
> time.
>
> The request_irq() has a irq flags parameter and the timer drivers use it to
> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer.
> Based on this flag, we can discard these interrupts when tracking them.
>
> But, the API request_percpu_irq does not allow to pass a flag, hence specifying
> if the interrupt type is a timer.
>
> Add a function request_percpu_irq_flags() where we can specify the flags. The
> request_percpu_irq() function is changed to be a wrapper to
> request_percpu_irq_flags() passing a zero flag parameter.
>
> Change the timers using request_percpu_irq() to use request_percpu_irq_flags()
> instead with the IRQF_TIMER flag set.
>
> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER
> flag (or zero) is a valid parameter to be passed to the
> request_percpu_irq_flags() function.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Kr?m?? <rkrcmar@redhat.com>
>
> ---
> Changelog:
>
> V9:
> - Clarified the patch description
> - Fixed EXPORT_SYMBOL_GPL(request_percpu_irq_flags)
> ---
> arch/arm/kernel/smp_twd.c | 3 ++-
> drivers/clocksource/arc_timer.c | 4 ++--
> drivers/clocksource/arm_arch_timer.c | 20 ++++++++++++--------
> drivers/clocksource/arm_global_timer.c | 4 ++--
> drivers/clocksource/exynos_mct.c | 7 ++++---
> drivers/clocksource/qcom-timer.c | 4 ++--
> drivers/clocksource/time-armada-370-xp.c | 9 +++++----
> drivers/clocksource/timer-nps.c | 6 +++---
> include/linux/interrupt.h | 11 ++++++++++-
> kernel/irq/manage.c | 15 ++++++++++-----
> virt/kvm/arm/arch_timer.c | 5 +++--
> 11 files changed, 55 insertions(+), 33 deletions(-)
>
For exynos-mct:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Maciej W. Rozycki @ 2017-04-24 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a03BTEBgz87k_dhJuqzOYQm_S5FFDrFgcBAE5FCH-e=dQ@mail.gmail.com>
On Mon, 24 Apr 2017, Arnd Bergmann wrote:
> I later tried all mips defconfigs with linux-4.3 and they all failed
> with gcc-4.1.3
> but built fine with gcc-4.9. I've now tried decstation_defconfig in 4.8-rc11,
> and this is what I see for gcc-4.1.3
>
> make O=build/mips/decstation_defconfig/ -skj30
> CC=/home/arnd/cross-gcc/bin/mips-linux-gcc-4.1.3\ ARCH=mips -f
> Makefile CROSS_COMPILE=/home/arnd/cross-gcc/bin/mips-linux-
> /git/arm-soc/fs/dcache.c: In function '__d_move':
> /git/arm-soc/fs/dcache.c:2773: warning: 'n' may be used uninitialized
> in this function
> /git/arm-soc/fs/dcache.c: In function 'd_splice_alias':
> /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized
> in this function
> /git/arm-soc/fs/dcache.c: In function 'd_add':
> /git/arm-soc/fs/dcache.c:2529: warning: 'n' may be used uninitialized
> in this function
> /git/arm-soc/mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited':
> /git/arm-soc/mm/page-writeback.c:1627: warning: 'writeback' is used
> uninitialized in this function
> /git/arm-soc/mm/page-writeback.c:1628: warning: 'filepages' is used
> uninitialized in this function
> /git/arm-soc/mm/page-writeback.c:1628: warning: 'headroom' is used
> uninitialized in this function
> /git/arm-soc/mm/page-writeback.c: In function 'wb_over_bg_thresh':
> /git/arm-soc/mm/page-writeback.c:1956: warning: 'filepages' is used
> uninitialized in this function
> /git/arm-soc/mm/page-writeback.c:1956: warning: 'headroom' is used
> uninitialized in this function
> /git/arm-soc/net/core/flow_dissector.c: In function '__skb_flow_dissect':
> /git/arm-soc/net/core/flow_dissector.c:272: warning: 'vlan' may be
> used uninitialized in this function
> /git/arm-soc/fs/splice.c: In function 'iter_file_splice_write':
> /git/arm-soc/fs/splice.c:716: warning: 'ret' may be used uninitialized
> in this function
> /git/arm-soc/net/core/dev.c: In function 'validate_xmit_skb_list':
> /git/arm-soc/net/core/dev.c:3003: warning: 'tail' may be used
> uninitialized in this function
> /git/arm-soc/kernel/printk/printk.c: In function 'devkmsg_sysctl_set_loglvl':
> /git/arm-soc/kernel/printk/printk.c:161: warning: 'old' may be used
> uninitialized in this function
> /git/arm-soc/kernel/time/ntp.c: In function 'ntp_validate_timex':
> /git/arm-soc/kernel/time/ntp.c:707: warning: comparison is always
> false due to limited range of data type
> /git/arm-soc/kernel/time/ntp.c:709: warning: comparison is always
> false due to limited range of data type
> /git/arm-soc/kernel/time/timekeeping.c: In function
> 'get_device_system_crosststamp':
> /git/arm-soc/kernel/time/timekeeping.c:1084: warning:
> 'cs_was_changed_seq' may be used uninitialized in this function
> /git/arm-soc/net/sunrpc/xdr.c: In function 'xdr_stream_decode_string_dup':
> /git/arm-soc/include/linux/sunrpc/xdr.h:409: warning: 'len' may be
> used uninitialized in this function
> /git/arm-soc/crypto/drbg.c: In function 'drbg_kcapi_random':
> /git/arm-soc/crypto/drbg.c:1865: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> /git/arm-soc/scripts/Makefile.build:300: recipe for target
> 'crypto/drbg.o' failed
>
> So it still fails, but only because of one compiler error that I can avoid by
> disabling that driver, and you probably use a slightly patched compiler
> version that doesn't have this particular bug, or it was a regression between
> gcc-4.1.2 and 4.1.3.
Umm, I didn't build modules, sorry, because I don't usually use them with
those systems. However I have completed this step now and it also worked
just fine:
$ ls -la crypto/drbg.o
-rw-r--r-- 1 macro macro 14096 Apr 24 18:59 crypto/drbg.o
$ file crypto/drbg.o
crypto/drbg.o: ELF 32-bit LSB MIPS-I relocatable, MIPS, version 1 (SYSV), not stripped
$
so you are likely right that either I have a patch applied to my 4.1.2
build that has somehow fixed the ICE or it is a 4.1.3 regression (or a bad
patch in your 4.1.3 build).
BTW I do see these `may be used uninitialized' warnings just as Geert
does and even have a local patch, which I have neglected to submit, for a
64-bit configuration (`decstation_defconfig' is 32-bit) where in a single
place -Werror turns it into a build failure. I do not consider it a big
issue though, and might even wrap that patch up and submit sometime.
Maciej
^ permalink raw reply
* [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v4)
From: Olof Johansson @ 2017-04-24 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170330002605.15213-1-eric@anholt.net>
Hi,
On Wed, Mar 29, 2017 at 5:26 PM, Eric Anholt <eric@anholt.net> wrote:
> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
> now, so it's useful to be able to test that mode on an upstream
> kernel. It's also been useful for me to use the same board for 32-bit
> and 64-bit development.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>
> v1: Gerd's patch that put the ../../../arm64/... link in the Makefile
> v2: Michael's patch that #included from ../../../arm64/... in a new
> bcm2837-rpi-3-b.dts.
> v3: Mine, using symlinks to make sure that we don't break the split DT
> tree.
> v4: Rely on the new include/arm64 symlink.
>
> Assuming positive review feedback, I assume it would be acceptable to
> merge the shared/dt-symlinks branch in a PR of my own for the 32-bit
> DT branch?
>
> arch/arm/boot/dts/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 011808490fed..27d258cb50f2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
> bcm2835-rpi-b-plus.dtb \
> bcm2835-rpi-a-plus.dtb \
> bcm2836-rpi-2-b.dtb \
> + include/arm64/broadcom/bcm2837-rpi-3-b.dtb \
Building straight out of (and into) the include dir is a little odd here.
A tiny wrapper *.dtb in this dir, that just includes a shared dts/dtsi
would be a lot nicer.
If you do that, we can still pick it up for 4.12.
-Olof
^ permalink raw reply
* [GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12, fixed
From: Krzysztof Kozlowski @ 2017-04-24 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421164050.7404-2-krzk@kernel.org>
Hi,
On top of previous pull request.
Fixed previous pull because of my doubled Signed-off-by in one comit.
Best regards,
Krzysztof
The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c:
arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI node (2017-03-08 08:55:39 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.12-3
for you to fetch changes up to 684c581f10f5e21976d9dcd85a190f37ddc843dd:
arm64: dts: exynos: Use - instead of @ for DT OPP entries (2017-04-24 20:19:32 +0200)
----------------------------------------------------------------
Second update of Samsung DeviceTree ARM64 for v4.12:
- Fix DTC warnings in Exynos ARM64 Device Tree sources.
- Add panel node to TM2E board.
----------------------------------------------------------------
Hoegeun Kwon (1):
arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
Viresh Kumar (1):
arm64: dts: exynos: Use - instead of @ for DT OPP entries
arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++++++-------------
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 ++++++
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 +++++++++++++-------------
3 files changed, 60 insertions(+), 49 deletions(-)
^ permalink raw reply
* [PATCH 3/3 v2] xen: Implement EFI reset_system callback
From: Boris Ostrovsky @ 2017-04-24 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175839.5262-4-julien.grall@arm.com>
On 04/24/2017 01:58 PM, Julien Grall wrote:
> When rebooting DOM0 with ACPI on ARM64, the kernel is crashing with the stack
> trace [1].
>
> This is happening because when EFI runtimes are enabled, the reset code
> (see machine_restart) will first try to use EFI restart method.
>
> However, the EFI restart code is expecting the reset_system callback to
> be always set. This is not the case for Xen and will lead to crash.
>
> The EFI restart helper is used in multiple places and some of them don't
> not have fallback (see machine_power_off). So implement reset_system
> callback as a call to xen_reboot when using EFI Xen.
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Santosh Shilimkar @ 2017-04-24 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c97828b4-7f19-93d1-6f23-d86e089cea87@ti.com>
On 4/24/2017 11:02 AM, Dave Gerlach wrote:
> On 04/21/2017 04:54 PM, Santosh Shilimkar wrote:
>> +Dave,
>>
[...]
>>> Ok, good, thanks for checking! They are however the commits that
>>> contain the silly https://urldefense.proofpoint.com URLs. Can you
>>> send a follow-up patch to fix these and use the regular
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ti.org&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=XBn1JQGPwR8CsE7xpP3wPlG6DQU7qw8ym65xieNZ4hY&m=vFHOEb7p2FxbH00YRQq4WnRiu2BKHADn0gl6e6DoNFQ&s=7mfiIp2Ywy9_ppWKjEGlrswiKRndv8_I7zGVF9uyT0w&e=
>>>
>>>
>>> URL that is in linux-next?
>>>
>> Dave,
>> Any reason you changed these URLs in last version ?
>> Can you please fixup these URLs to along with DT defines.
>
> I didn't change any of the URLs in the patches, I am not sure what those
> URLs are. In the patches I sent the URLs are fine, and I see them normal
> on patchwork too:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9660785_&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=XBn1JQGPwR8CsE7xpP3wPlG6DQU7qw8ym65xieNZ4hY&m=eK4-xq3xbWwYHfuVa6ee48pvTCWUv5X5PHM285eHMLQ&s=uCfKZ0Z0T8Aaf4ircFilcu8zRVDU8XyGdbsq4OW3GaE&e=
>
> Is there something that automatically changes those? I don't want to
> send another patch for it to just get mangled again.
>
Looks like thats the case as one of my Oracle colleague pointed out.
I will send you off-list an email to get correct URL and update the git
tree accordingly.
Regards,
Santosh
^ permalink raw reply
* [PATCH 1/3 v2] xen: Export xen_reboot
From: Boris Ostrovsky @ 2017-04-24 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424175839.5262-2-julien.grall@arm.com>
On 04/24/2017 01:58 PM, Julien Grall wrote:
> The helper xen_reboot will be called by the EFI code in a later patch.
>
> Note that the ARM version does not yet exist and will be added in a
> later patch too.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
I don't think these changes are worth a whole patch. They can be folded
into the third patch.
-boris
>
> ---
>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86 at kernel.org
>
> Changes in v2:
> - Patch added
> ---
> arch/x86/xen/enlighten.c | 2 +-
> include/xen/xen-ops.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index ec1d5c46e58f..563f2d963a04 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1294,7 +1294,7 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
> .end_context_switch = xen_end_context_switch,
> };
>
> -static void xen_reboot(int reason)
> +void xen_reboot(int reason)
> {
> struct sched_shutdown r = { .reason = reason };
> int cpu;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index b5486e648607..fc5ddb472f86 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -22,6 +22,8 @@ void xen_timer_resume(void);
> void xen_arch_resume(void);
> void xen_arch_suspend(void);
>
> +void xen_reboot(int reason);
> +
> void xen_resume_notifier_register(struct notifier_block *nb);
> void xen_resume_notifier_unregister(struct notifier_block *nb);
>
^ permalink raw reply
* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Geert Uytterhoeven @ 2017-04-24 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a03BTEBgz87k_dhJuqzOYQm_S5FFDrFgcBAE5FCH-e=dQ@mail.gmail.com>
Hi Arnd,
On Mon, Apr 24, 2017 at 7:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Apr 24, 2017 at 6:53 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
>> On Mon, 24 Apr 2017, Arnd Bergmann wrote:
>>> > If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not
>>> > do it.I guess most people using old compilers know what they're doing.
>>>
>>> What I'm trying to find out first is whether "people regularly using 10+
>>> year old compilers for the latest kernels" is a strict subset of "people in
>>> Geert's household".
>>
>> Well I do not live with Geert TBH.
>
> Sorry about that, you had mentioned that you had used it recently, which should
> have weighed more than my own results.
If you prefer to consider everyone who's been sleeping in the same room
at one of the Oldenburg Linux meetings as part of my household, that's
fine for me ;-)
> So it still fails, but only because of one compiler error that I can avoid by
> disabling that driver, and you probably use a slightly patched compiler
> version that doesn't have this particular bug, or it was a regression between
> gcc-4.1.2 and 4.1.3.
Mine is also some patched version of 4.1.1, built from Ubuntu sources:
gcc version 4.1.2 20061115 (prerelease) (Ubuntu 4.1.1-21)
These sources probably even contained the fixes to make gcc-4.1.1
usable on CELL.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* linux-next: manual merge of the pm tree with the arm-soc tree
From: Dave Gerlach @ 2017-04-24 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3dfaceb-41ba-b13d-f47e-a279c3e2f6b9@oracle.com>
On 04/21/2017 04:54 PM, Santosh Shilimkar wrote:
> +Dave,
>
> On 4/21/2017 2:44 PM, Arnd Bergmann wrote:
>> On Fri, Apr 21, 2017 at 11:02 PM, santosh.shilimkar at oracle.com
>> <santosh.shilimkar@oracle.com> wrote:
>>> On 4/21/17 2:31 AM, Arnd Bergmann wrote:
>
> [...]
>
>>>> arm-soc/next/drivers:
>>>> ae3874cc931b ARM: keystone: Drop PM domain support for k2g
>>>> 52835d59fc6c soc: ti: Add ti_sci_pm_domains driver
>>>> 7cc119f29b19 dt-bindings: Add TI SCI PM Domains
>>>> 213ec7fed302 PM / Domains: Do not check if simple providers have phandle
>>>> cells
>>>> a5ea7a0fcbd7 PM / Domains: Add generic data pointer to genpd data struct
>>>>
>>> Above are the correct git object for which I sent pull request for.
>>
>> Ok, good, thanks for checking! They are however the commits that
>> contain the silly https://urldefense.proofpoint.com URLs. Can you
>> send a follow-up patch to fix these and use the regular
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ti.org&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=XBn1JQGPwR8CsE7xpP3wPlG6DQU7qw8ym65xieNZ4hY&m=vFHOEb7p2FxbH00YRQq4WnRiu2BKHADn0gl6e6DoNFQ&s=7mfiIp2Ywy9_ppWKjEGlrswiKRndv8_I7zGVF9uyT0w&e=
>>
>> URL that is in linux-next?
>>
> Dave,
> Any reason you changed these URLs in last version ?
> Can you please fixup these URLs to along with DT defines.
I didn't change any of the URLs in the patches, I am not sure what those URLs
are. In the patches I sent the URLs are fine, and I see them normal on patchwork
too: https://patchwork.kernel.org/patch/9660785/
Is there something that automatically changes those? I don't want to send
another patch for it to just get mangled again.
Regards,
Dave
>
> Regards,
> Santosh
^ 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