* [GIT PULL] ARM: mvebu: fixes for v4.8 (#3)
From: Gregory CLEMENT @ 2016-10-17 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4853532.G9HOlQ47QA@wuerfel>
Hi Arnd,
On mer., sept. 21 2016, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, September 20, 2016 6:14:47 PM CEST Gregory CLEMENT wrote:
>> mvebu fixes for 4.8 (part 3)
>>
>> - Select corediv clk for all mvebu v7 SoC
>> - Fix clocksource for CP110 master SPI0 for Armada 7K/8K
>>
>
> Pulled into fixes, thanks!
I don't see this patch in the v4.8 or the v4.9-rc1.
I think it slipped through the cracks as there were the only one in the
fixes branches.
Do you think you could make them part of your next pull request for
fixes for 4.9-rc2?
Thanks,
Gregory
>
> Arnd
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Regression: usb serial gadget on sama5d3 broken
From: Peter Rosin @ 2016-10-17 12:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
I'm suffering from a regression while using the usb gadget port on the
sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
I get this message when I try to connect:
udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
USB endpoint nodes".
And indeed, reverting that commit on top of v4.9-rc1 fixes things,
although that doesn't look like the best of fixes...
BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
somewhere in the overlayfs area. I hope I will never ever need to bisect
in the v4.6..v4.7 area again. This was the second time, the first time
I was chasing a gpio interrupt bug, but I never found out what was wrong
and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
was bad, it was just too painful to look for things that already seemed
fixed.
Cheers,
Peter
^ permalink raw reply
* [PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4
From: Masahiro Yamada @ 2016-10-17 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017123043.GA15142@kroah.com>
Hi Greg,
2016-10-17 21:30 GMT+09:00 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
>> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
>> needs to handle 4 reset lines for EHCI.
>
> Why? What makes it different from other EHCI implementations?
>
> thanks,
>
> greg k-h
This is a generic EHCI driver, but the number of clocks/resets
are SoC-specific.
The following patch you picked up will remind you something?
commit 73577d61799e8d8bb7d69a9acdc54923e5998138
Author: Icenowy Zheng <icenowy@aosc.xyz>
Date: Fri Aug 12 11:06:22 2016 +0800
ehci-platform: add the max clock number to 4
Allwinner A64 EHCI requires 4 clocks to be enabled.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v4 0/1] Armada 7k/8k CP110 system controller fixes
From: Marcin Wojtas @ 2016-10-17 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKf13FJxGkpt+OcNO--hRQoZr-TtuzCcAJrQwFXjqRgM2Q@mail.gmail.com>
Hi Stephen,
Since merge window is closed, I kindly remind about remaining patch.
Best regards,
Marcin
2016-10-06 21:24 GMT+02:00 Marcin Wojtas <mw@semihalf.com>:
> Hi Stephen,
>
> Do you have any further comments on the remaining patch?
>
> Best regards,
> Marcin
>
> 2016-09-25 9:47 GMT+02:00 Marcin Wojtas <mw@semihalf.com>:
>> Hi,
>>
>> Two patches from the third version of the patchset have already been
>> applied, so I re-send the last one with corrected allocation of
>> clock data, which was pointed in the review.
>>
>> Any feedback would be very welcome.
>>
>> Best regards,
>> Marcin
>>
>> Changelog:
>> v4 <- v3
>> * fix allocation of clock data
>>
>> v3 <- v2
>> * return -ENOMEM on alloc failures
>>
>> v1 <- v2
>> * replace setting CLK_IS_BASIC flag with clearing init structure fields
>> with memset
>> * minor improvements of allocation and error checking
>> * add migration to clk_hw
>>
>>
>> Marcin Wojtas (1):
>> clk: mvebu: migrate CP110 system controller to clk_hw API and
>> registration
>>
>> drivers/clk/mvebu/cp110-system-controller.c | 150 +++++++++++++---------------
>> 1 file changed, 72 insertions(+), 78 deletions(-)
>>
>> --
>> 1.8.3.1
>>
^ permalink raw reply
* ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()
From: Mark Rutland @ 2016-10-17 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d012ad47-9688-5c9c-6ffd-78300c7b21ae@users.sourceforge.net>
On Mon, Oct 17, 2016 at 02:50:57PM +0200, SF Markus Elfring wrote:
> > I prefer the code as-is. Unless there's a compelling reason to change it.
>
> Is the chance for faster log output interesting enough?
Is there a particular user that cares today, or are we trying to work
backwards to a rationale?
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Lorenzo Pieralisi @ 2016-10-17 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cf1acbf9c42cc99e5cc0dacb50b7a92c3bd0feb.1476702234.git.robin.murphy@arm.com>
On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
> We now delay installing our per-bus iommu_ops until we know an SMMU has
> successfully probed, as they don't serve much purpose beforehand, and
> doing so also avoids fights between multiple IOMMU drivers in a single
> kernel. However, the upshot of passing the return value of bus_set_iommu()
> back from our probe function is that if there happens to be more than
> one SMMUv3 device in a system, the second and subsequent probes will
> wind up returning -EBUSY to the driver core and getting torn down again.
>
> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
> 1. The bus already has iommu_ops installed
> 2. One of the add_device callbacks from the initial notifier failed
> 3. Allocating or installing the notifier itself failed
>
> The first two are down to devices other than the SMMU in question, so
> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
> indicative of the kind of catastrophic system failure which isn't going
> to get much further anyway. Consequently, there is little harm in
> ignoring the return value either way.
>
> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 15c01c3cd540..74fbef384deb 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> #ifdef CONFIG_PCI
> pci_request_acs();
> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> - if (ret)
> - return ret;
> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> #endif
> #ifdef CONFIG_ARM_AMBA
> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> - if (ret)
> - return ret;
> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> #endif
> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> + return 0;
Nit: I do not see why you would not take the same approach as
the ARM SMMUv1/v2, namely checking if ops are already set and
skip the call if that's the case.
Anyway:
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> }
>
> static int arm_smmu_device_remove(struct platform_device *pdev)
> --
> 1.9.1
>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.8 (#3)
From: Arnd Bergmann @ 2016-10-17 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87insrf8aw.fsf@free-electrons.com>
On Monday, October 17, 2016 2:51:03 PM CEST Gregory CLEMENT wrote:
> Hi Arnd,
>
> On mer., sept. 21 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Tuesday, September 20, 2016 6:14:47 PM CEST Gregory CLEMENT wrote:
> >> mvebu fixes for 4.8 (part 3)
> >>
> >> - Select corediv clk for all mvebu v7 SoC
> >> - Fix clocksource for CP110 master SPI0 for Armada 7K/8K
> >>
> >
> > Pulled into fixes, thanks!
>
> I don't see this patch in the v4.8 or the v4.9-rc1.
>
> I think it slipped through the cracks as there were the only one in the
> fixes branches.
>
> Do you think you could make them part of your next pull request for
> fixes for 4.9-rc2?
Indeed, I missed how this was still on the fixes branch during
the merge window. It is still on that branch (and nothing else
is so far), and it will be part of the next fixes pull request.
Thanks for the reminder.
Arnd
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Arnd Bergmann @ 2016-10-17 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017120705.3726-2-wenpan@hisilicon.com>
On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>
> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>
Looks ok. I've added Marty Plummer to Cc, he was recently proposing
patches for Hi3520, which I think is closely related to this one.
Please try to work together so the patches don't conflict. It should
be fairly straightforward since you are basically doing the same
change here.
Arnd
^ permalink raw reply
* [PATCH 0/2] mmc: sdhci-iproc: Add byte register access support
From: Ulf Hansson @ 2016-10-17 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476297352-7812-1-git-send-email-scott.branden@broadcom.com>
On 12 October 2016 at 20:35, Scott Branden <scott.branden@broadcom.com> wrote:
> Add brcm,sdhci-iproc compat string and code for support of newer versions of
> sdhci-iproc controller that allow byte-wise register accesses.
>
> Scott Branden (2):
> mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings
> document
> mmc: sdhci-iproc: support standard byte register accesses
>
> .../devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 1 +
> drivers/mmc/host/sdhci-iproc.c | 35 ++++++++++++++++++++--
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> --
> 2.5.0
>
Thanks, applied for next!
Kind regards
Uffe
^ permalink raw reply
* [PATCH v2] ARM: shmobile: Consolidate R8A7743 and R8A779[234] machine definitions
From: Laurent Pinchart @ 2016-10-17 13:59 UTC (permalink / raw)
To: linux-arm-kernel
The four SoCs use identical machine operations, consolidate them into
two machine definitions in a single file.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes since v1:
- Rebased on top of Simon's latest devel branch, thus including R8A7743
consolidation
arch/arm/mach-shmobile/Makefile | 4 ----
arch/arm/mach-shmobile/setup-r8a7743.c | 34 -------------------------------
arch/arm/mach-shmobile/setup-r8a7792.c | 35 --------------------------------
arch/arm/mach-shmobile/setup-r8a7793.c | 33 ------------------------------
arch/arm/mach-shmobile/setup-r8a7794.c | 33 ------------------------------
arch/arm/mach-shmobile/setup-rcar-gen2.c | 33 ++++++++++++++++++++++++++++++
6 files changed, 33 insertions(+), 139 deletions(-)
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7743.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7792.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7793.c
delete mode 100644 arch/arm/mach-shmobile/setup-r8a7794.c
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 332b84f8261f..64611a1b4276 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -9,14 +9,10 @@ obj-y := timer.o
obj-$(CONFIG_ARCH_SH73A0) += setup-sh73a0.o
obj-$(CONFIG_ARCH_R8A73A4) += setup-r8a73a4.o
obj-$(CONFIG_ARCH_R8A7740) += setup-r8a7740.o
-obj-$(CONFIG_ARCH_R8A7743) += setup-r8a7743.o
obj-$(CONFIG_ARCH_R8A7778) += setup-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += setup-r8a7779.o pm-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += setup-r8a7790.o
obj-$(CONFIG_ARCH_R8A7791) += setup-r8a7791.o
-obj-$(CONFIG_ARCH_R8A7792) += setup-r8a7792.o
-obj-$(CONFIG_ARCH_R8A7793) += setup-r8a7793.o
-obj-$(CONFIG_ARCH_R8A7794) += setup-r8a7794.o
obj-$(CONFIG_ARCH_EMEV2) += setup-emev2.o
obj-$(CONFIG_ARCH_R7S72100) += setup-r7s72100.o
diff --git a/arch/arm/mach-shmobile/setup-r8a7743.c b/arch/arm/mach-shmobile/setup-r8a7743.c
deleted file mode 100644
index a7ecb82d219f..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7743.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * r8a7743 processor support
- *
- * Copyright (C) 2016 Cogent Embedded, Inc.
- *
- * 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; of the License.
- *
- * 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.
- */
-
-#include <linux/init.h>
-
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7743_boards_compat_dt[] __initconst = {
- "renesas,r8a7743",
- NULL,
-};
-
-DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_time = rcar_gen2_timer_init,
- .init_late = shmobile_init_late,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7743_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7792.c b/arch/arm/mach-shmobile/setup-r8a7792.c
deleted file mode 100644
index a0910395da09..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7792.c
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * r8a7792 processor support
- *
- * Copyright (C) 2014 Renesas Electronics Corporation
- * Copyright (C) 2016 Cogent Embedded, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * 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.
- */
-
-#include <linux/of_platform.h>
-
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7792_boards_compat_dt[] __initconst = {
- "renesas,r8a7792",
- NULL,
-};
-
-DT_MACHINE_START(R8A7792_DT, "Generic R8A7792 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_late = shmobile_init_late,
- .init_time = rcar_gen2_timer_init,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7792_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7793.c b/arch/arm/mach-shmobile/setup-r8a7793.c
deleted file mode 100644
index 5fce87f7f254..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7793.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * r8a7793 processor support
- *
- * Copyright (C) 2015 Ulrich Hecht
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * 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.
- */
-
-#include <linux/init.h>
-#include <asm/mach/arch.h>
-
-#include "common.h"
-#include "rcar-gen2.h"
-
-static const char * const r8a7793_boards_compat_dt[] __initconst = {
- "renesas,r8a7793",
- NULL,
-};
-
-DT_MACHINE_START(R8A7793_DT, "Generic R8A7793 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_time = rcar_gen2_timer_init,
- .init_late = shmobile_init_late,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7793_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-r8a7794.c b/arch/arm/mach-shmobile/setup-r8a7794.c
deleted file mode 100644
index d2b093033132..000000000000
--- a/arch/arm/mach-shmobile/setup-r8a7794.c
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * r8a7794 processor support
- *
- * Copyright (C) 2014 Renesas Electronics Corporation
- * Copyright (C) 2014 Ulrich Hecht
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * 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.
- */
-
-#include <linux/of_platform.h>
-#include "common.h"
-#include "rcar-gen2.h"
-#include <asm/mach/arch.h>
-
-static const char * const r8a7794_boards_compat_dt[] __initconst = {
- "renesas,r8a7794",
- NULL,
-};
-
-DT_MACHINE_START(R8A7794_DT, "Generic R8A7794 (Flattened Device Tree)")
- .init_early = shmobile_init_delay,
- .init_late = shmobile_init_late,
- .init_time = rcar_gen2_timer_init,
- .reserve = rcar_gen2_reserve,
- .dt_compat = r8a7794_boards_compat_dt,
-MACHINE_END
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index afb9fdcd3d90..875bcb8c1026 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -24,6 +24,7 @@
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
#include <asm/mach/arch.h>
#include "common.h"
#include "rcar-gen2.h"
@@ -203,3 +204,35 @@ void __init rcar_gen2_reserve(void)
}
#endif
}
+
+static const char * const rcar_gen2_boards_compat_dt[] __initconst = {
+ /*
+ * R8A7790 and R8A7791 can't be handled here as long as they need SMP
+ * initialization fallback.
+ */
+ "renesas,r8a7792",
+ "renesas,r8a7793",
+ "renesas,r8a7794",
+ NULL,
+};
+
+DT_MACHINE_START(RCAR_GEN2_DT, "Generic R-Car Gen2 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_late = shmobile_init_late,
+ .init_time = rcar_gen2_timer_init,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = rcar_gen2_boards_compat_dt,
+MACHINE_END
+
+static const char * const rz_g1_boards_compat_dt[] __initconst = {
+ "renesas,r8a7743",
+ NULL,
+};
+
+DT_MACHINE_START(RZ_G1_DT, "Generic RZ/G1 (Flattened Device Tree)")
+ .init_early = shmobile_init_delay,
+ .init_late = shmobile_init_late,
+ .init_time = rcar_gen2_timer_init,
+ .reserve = rcar_gen2_reserve,
+ .dt_compat = rz_g1_boards_compat_dt,
+MACHINE_END
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Bartosz Golaszewski @ 2016-10-17 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <daf49046-ad0a-d9e2-d744-1e06085c6585@ti.com>
2016-10-17 14:29 GMT+02:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
> On 17/10/16 14:40, Laurent Pinchart wrote:
>> Hello,
>>
>> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>>> On 17/10/16 10:12, Sekhar Nori wrote:
>>>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>>>> On 15/10/16 20:42, Sekhar Nori wrote:
>>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>>> index f79e1b9..32908ae 100644
>>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>>> @@ -399,6 +420,14 @@
>>>>>>> <&edma0 0 1>;
>>>>>>> dma-names = "tx", "rx";
>>>>>>> };
>>>>>>> +
>>>>>>> + display: display at 213000 {
>>>>>>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>>>>>>
>>>>>> This should instead be:
>>>>>>
>>>>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>>>>
>>>>>> as the closest match should appear first in the list.
>>>>>
>>>>> Actually I don't think that's correct. The LCDC on da850 is not
>>>>> compatible with the LCDC on AM335x. I think it should be just
>>>>> "ti,da850-tilcdc".
>>>>
>>>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>>>> the case, I wonder how the patch passed testing. Bartosz?
>>>
>>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>>> similar, but different.
>>>
>>> The driver gets the version number from LCDC's register, and acts based
>>> on that, so afaik the compatible string doesn't really affect the
>>> functionality (as long as it matches).
>>>
>>> But even if it works with the current driver, I don't think
>>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
>>
>> If the hardware provides IP revision information, how about just "ti,lcdc" ?
>
> Maybe, and I agree that's the "correct" way, but looking at the history,
> it's not just once or twice when we've suddenly found out some
> difference or bug or such in an IP revision, or the integration to a
> SoC, that can't be found based on the IP revision.
>
> That's why I feel it's usually safer to have the SoC revision there in
> the compatible string.
>
> That said, we have only a few different old SoCs with LCDC (compared to,
> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.
>
> Tomi
>
I Sekhar is ok with this, I'll send a follow-up patch for that.
Thanks,
Bartosz
^ permalink raw reply
* [PATCH] arm64: kernel: numa: fix ACPI boot cpu numa node mapping
From: Lorenzo Pieralisi @ 2016-10-17 14:18 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
bind to node0") removed the numa cpu<->node mapping restriction whereby
logical cpu 0 always corresponds to numa node 0; removing the
restriction was correct, in that it does not really exist in practice
but the commit only updated the early mapping of logical cpu 0 to its
real numa node for the DT boot path, missing the ACPI one, leading to
boot failures on ACPI systems with numa enabled owing to missing
node<->cpu map for logical cpu 0.
Fix the issue by updating the ACPI boot path with code that carries out
the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
what is currently done in the DT boot path.
Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d3f151c..8507703 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
return;
}
bootcpu_valid = true;
+ early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
return;
}
--
2.10.0
^ permalink raw reply related
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Sricharan @ 2016-10-17 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5cf1acbf9c42cc99e5cc0dacb50b7a92c3bd0feb.1476702234.git.robin.murphy@arm.com>
Hi,
>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Robin Murphy
>Sent: Monday, October 17, 2016 4:36 PM
>To: will.deacon at arm.com; joro at 8bytes.org
>Cc: iommu at lists.linux-foundation.org; Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; linux-arm-kernel at lists.infradead.org
>Subject: [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
>
>We now delay installing our per-bus iommu_ops until we know an SMMU has
>successfully probed, as they don't serve much purpose beforehand, and
>doing so also avoids fights between multiple IOMMU drivers in a single
>kernel. However, the upshot of passing the return value of bus_set_iommu()
>back from our probe function is that if there happens to be more than
>one SMMUv3 device in a system, the second and subsequent probes will
>wind up returning -EBUSY to the driver core and getting torn down again.
>
>There are essentially 3 cases in which bus_set_iommu() returns nonzero:
>1. The bus already has iommu_ops installed
>2. One of the add_device callbacks from the initial notifier failed
>3. Allocating or installing the notifier itself failed
>
>The first two are down to devices other than the SMMU in question, so
>shouldn't abort an otherwise-successful SMMU probe, whilst the third is
>indicative of the kind of catastrophic system failure which isn't going
>to get much further anyway. Consequently, there is little harm in
>ignoring the return value either way.
>
>CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>---
> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>index 15c01c3cd540..74fbef384deb 100644
>--- a/drivers/iommu/arm-smmu-v3.c
>+++ b/drivers/iommu/arm-smmu-v3.c
>@@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> #ifdef CONFIG_PCI
> pci_request_acs();
>- ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>- if (ret)
>- return ret;
>+ bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> #endif
> #ifdef CONFIG_ARM_AMBA
>- ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>- if (ret)
>- return ret;
>+ bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> #endif
>- return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>+ bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>+ return 0;
reviewed-by: sricharan at codeaurora.org
Regards,
Sricharan
^ permalink raw reply
* [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64
From: Auger Eric @ 2016-10-17 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mvi7qikn.fsf@e105922-lin.cambridge.arm.com>
Hi Punit,
On 14/10/2016 13:24, Punit Agrawal wrote:
> Hi Eric,
>
> I am a bit late in joining, but I've tried to familiarise
> myself with earlier discussions on the series.
>
> Eric Auger <eric.auger@redhat.com> writes:
>
>> This is the second respin on top of Robin's series [1], addressing Alex' comments.
>>
>> Major changes are:
>> - MSI-doorbell API now is moved to DMA IOMMU API following Alex suggestion
>> to put all API pieces at the same place (so eventually in the IOMMU
>> subsystem)
>
> IMHO, this is headed in the opposite direction, i.e., away from the
> owner of the information - the doorbells are the property of the MSI
> controller. The MSI controllers know the location, size and interrupt
> remapping capability as well. On the consumer side, VFIO needs access to
> the doorbells to allow userspace to carve out a region in the IOVA.
>
> I quite liked what you had in v13, though I think you can go further
> though. Instead of adding new doorbell API [un]registration calls, how
> about adding a callback to the irq_domain_ops? The callback will be
> populated for irqdomains registered by MSI controllers.
Thank you for jumping into that thread. Any help/feedback is greatly
appreciated.
Regarding your suggestion, the irq_domain looks dedicated to the
translation between linux irq and HW irq. I tend to think adding an ops
to retrieve the MSI doorbell info at that level looks far from the
original goal of the infrastructure. Obviously the fact there is a list
of such domain is tempting but I preferred to add a separate struct and
separate list.
In the v14 release I moved the "doorbell API" in the dma-iommu API since
Alex recommended to offer a unified API where all pieces would be at the
same place.
Anyway I will follow the guidance of maintainers.
>
> From VFIO, we can calculate the required aperture reservation by
> iterating over the irqdomains (something like irq_domain_for_each). The
> same callback can also provide information about support for interrupt
> remapping.
>
> For systems where there are no separate MSI controllers, i.e., the IOMMU
> has a fixed reservation, no MSI callbacks will be populated - which
> tells userspace that no separate MSI reservation is required. IIUC, this
> was one of Alex' concerns on the prior version.
I'am working on a separate series to report to the user-space the usable
IOVA range(s).
Thanks
Eric
>
> Thoughts, opinions?
>
> Punit
>
>> - new iommu_domain_msi_resv struct and accessor through DOMAIN_ATTR_MSI_RESV
>> domain with mirror VFIO capability
>> - more robustness I think in the VFIO layer
>> - added "iommu/iova: fix __alloc_and_insert_iova_range" since with the current
>> code I failed allocating an IOVA page in a single page domain with upper part
>> reserved
>>
>> IOVA range exclusion will be handled in a separate series
>>
>> The priority really is to discuss and freeze the API and especially the MSI
>> doorbell's handling. Do we agree to put that in DMA IOMMU?
>>
>> Note: the size computation does not take into account possible page overlaps
>> between doorbells but it would add quite a lot of complexity i think.
>>
>> Tested on AMD Overdrive (single GICv2m frame) with I350 VF assignment.
>>
>> dependency:
>> the series depends on Robin's generic-v7 branch:
>> [1] [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
>> http://www.spinics.net/lists/arm-kernel/msg531110.html
>>
>> Best Regards
>>
>> Eric
>>
>> Git: complete series available at
>> https://github.com/eauger/linux/tree/generic-v7-pcie-passthru-v14
>>
>> the above branch includes a temporary patch to work around a ThunderX pci
>> bus reset crash (which I think unrelated to this series):
>> "vfio: pci: HACK! workaround thunderx pci_try_reset_bus crash"
>> Do not take this one for other platforms.
>>
>>
>> Eric Auger (15):
>> iommu/iova: fix __alloc_and_insert_iova_range
>> iommu: Introduce DOMAIN_ATTR_MSI_RESV
>> iommu/dma: MSI doorbell alloc/free
>> iommu/dma: Introduce iommu_calc_msi_resv
>> iommu/arm-smmu: Implement domain_get_attr for DOMAIN_ATTR_MSI_RESV
>> irqchip/gic-v2m: Register the MSI doorbell
>> irqchip/gicv3-its: Register the MSI doorbell
>> vfio: Introduce a vfio_dma type field
>> vfio/type1: vfio_find_dma accepting a type argument
>> vfio/type1: Implement recursive vfio_find_dma_from_node
>> vfio/type1: Handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots
>> vfio: Allow reserved msi iova registration
>> vfio/type1: Check doorbell safety
>> iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP
>> vfio/type1: Introduce MSI_RESV capability
>>
>> Robin Murphy (1):
>> iommu/dma: Allow MSI-only cookies
>>
>> drivers/iommu/Kconfig | 4 +-
>> drivers/iommu/arm-smmu-v3.c | 10 +-
>> drivers/iommu/arm-smmu.c | 10 +-
>> drivers/iommu/dma-iommu.c | 184 ++++++++++++++++++++++++++
>> drivers/iommu/iova.c | 2 +-
>> drivers/irqchip/irq-gic-v2m.c | 10 +-
>> drivers/irqchip/irq-gic-v3-its.c | 13 ++
>> drivers/vfio/vfio_iommu_type1.c | 279 +++++++++++++++++++++++++++++++++++++--
>> include/linux/dma-iommu.h | 59 +++++++++
>> include/linux/iommu.h | 8 ++
>> include/uapi/linux/vfio.h | 30 ++++-
>> 11 files changed, 587 insertions(+), 22 deletions(-)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Robin Murphy @ 2016-10-17 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017132146.GA26341@red-moon>
Hi Lorenzo,
On 17/10/16 14:21, Lorenzo Pieralisi wrote:
> On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
>> We now delay installing our per-bus iommu_ops until we know an SMMU has
>> successfully probed, as they don't serve much purpose beforehand, and
>> doing so also avoids fights between multiple IOMMU drivers in a single
>> kernel. However, the upshot of passing the return value of bus_set_iommu()
>> back from our probe function is that if there happens to be more than
>> one SMMUv3 device in a system, the second and subsequent probes will
>> wind up returning -EBUSY to the driver core and getting torn down again.
>>
>> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
>> 1. The bus already has iommu_ops installed
>> 2. One of the add_device callbacks from the initial notifier failed
>> 3. Allocating or installing the notifier itself failed
>>
>> The first two are down to devices other than the SMMU in question, so
>> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
>> indicative of the kind of catastrophic system failure which isn't going
>> to get much further anyway. Consequently, there is little harm in
>> ignoring the return value either way.
>>
>> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
>> 1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 15c01c3cd540..74fbef384deb 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
>> #ifdef CONFIG_PCI
>> pci_request_acs();
>> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>> - if (ret)
>> - return ret;
>> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>> #endif
>> #ifdef CONFIG_ARM_AMBA
>> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>> - if (ret)
>> - return ret;
>> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>> #endif
>> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>> + return 0;
>
> Nit: I do not see why you would not take the same approach as
> the ARM SMMUv1/v2, namely checking if ops are already set and
> skip the call if that's the case.
Well, I'd say it really goes the other way around - since the very first
thing bus_set_iommu() does is check if ops are present, and return if
so, and the v2 driver already doesn't care about that return value,
there's not really any need for it to duplicate the check either. I
didn't change it at the time to avoid cluttering the gigantic rework any
further, but I could spin a cleanup patch if you like.
> Anyway:
>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Thanks!
Robin.
^ permalink raw reply
* [PATCH v14 04/16] iommu/dma: MSI doorbell alloc/free
From: Auger Eric @ 2016-10-17 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgxrqijs.fsf@e105922-lin.cambridge.arm.com>
Hi Punit,
On 14/10/2016 13:25, Punit Agrawal wrote:
> Hi Eric,
>
> One query and a comment below.
>
> Eric Auger <eric.auger@redhat.com> writes:
>
>> We introduce the capability to (un)register MSI doorbells.
>>
>> A doorbell region is characterized by its physical address base, size,
>> and whether it its safe (ie. it implements IRQ remapping). A doorbell
>> can be per-cpu or global. We currently only care about global doorbells.
>>
>> A function returns whether all registered doorbells are safe.
>>
>> MSI controllers likely to work along with IOMMU that translate MSI
>> transaction must register their doorbells to allow device assignment
>> with MSI support. Otherwise the MSI transactions will cause IOMMU faults.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> v13 -> v14:
>> - previously in msi-doorbell.h/c
>> ---
>> drivers/iommu/dma-iommu.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/dma-iommu.h | 41 ++++++++++++++++++++++++++
>> 2 files changed, 116 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index d45f9a0..d8a7d86 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -43,6 +43,38 @@ struct iommu_dma_cookie {
>> spinlock_t msi_lock;
>> };
>>
>> +/**
>> + * struct iommu_msi_doorbell_info - MSI doorbell region descriptor
>> + * @percpu_doorbells: per cpu doorbell base address
>> + * @global_doorbell: base address of the doorbell
>> + * @doorbell_is_percpu: is the doorbell per cpu or global?
>> + * @safe: true if irq remapping is implemented
>> + * @size: size of the doorbell
>> + */
>> +struct iommu_msi_doorbell_info {
>> + union {
>> + phys_addr_t __percpu *percpu_doorbells;
>
> Out of curiosity, have you come across systems that have per-cpu
> doorbells? I couldn't find a system that'd help solidify my
> understanding on it's usage.
This came out after a discussion With Marc. However at the moment I am
not aware of any MSI controller featuring per-cpu doorbell. Not sure
whether it stays relevant to keep this notion at that stage.
>
>> + phys_addr_t global_doorbell;
>> + };
>> + bool doorbell_is_percpu;
>> + bool safe;
>
> Although you've got the comment above, 'safe' doesn't quite convey it's
> purpose. Can this be renamed to something more descriptive -
> 'intr_remapping' or 'intr_isolation' perhaps?
Yes definitively
Thanks
Eric
>
> Thanks,
> Punit
>
>
> [...]
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] arm64: kernel: numa: fix ACPI boot cpu numa node mapping
From: Laszlo Ersek @ 2016-10-17 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017141848.5274-1-lorenzo.pieralisi@arm.com>
On 10/17/16 16:18, Lorenzo Pieralisi wrote:
> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
> bind to node0") removed the numa cpu<->node mapping restriction whereby
> logical cpu 0 always corresponds to numa node 0; removing the
> restriction was correct, in that it does not really exist in practice
> but the commit only updated the early mapping of logical cpu 0 to its
> real numa node for the DT boot path, missing the ACPI one, leading to
> boot failures on ACPI systems with numa enabled owing to missing
> node<->cpu map for logical cpu 0.
Small correction request: please drop the "with numa enabled"
qualification. The bug breaks ACPI boot on numa-disabled systems as well
(i.e., where there's only one node, and there are no NUMA-related ACPI
tables (like SRAT) and objects (like _PXM in the DSDT)).
Many thanks!
Laszlo
>
> Fix the issue by updating the ACPI boot path with code that carries out
> the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
> what is currently done in the DT boot path.
>
> Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Tested-by: Laszlo Ersek <lersek@redhat.com>
> Reported-by: Laszlo Ersek <lersek@redhat.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Andrew Jones <drjones@redhat.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/kernel/smp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index d3f151c..8507703 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> return;
> }
> bootcpu_valid = true;
> + early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
> return;
> }
>
>
^ permalink raw reply
* [PATCH v3 08/11] ARM: dts: r8a7743: add IRQC support
From: Geert Uytterhoeven @ 2016-10-17 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1550113.UvRQMtlFiI@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:43 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Describe the IRQC interrupt controller in the R8A7743 device tree.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
* [PATCH v3 07/11] ARM: dts: r8a7743: add Ether support
From: Geert Uytterhoeven @ 2016-10-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1823688.my1YjA2iHn@wasted.cogentembedded.com>
On Wed, Oct 5, 2016 at 11:42 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Define the generic R8A7743 part of the Ether device node.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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
* [PATCH] arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=y
From: Will Deacon @ 2016-10-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9X3-mMk7_2R=LZ6V38f-dPYrcZkROrkQBde5H-kFcYbw@mail.gmail.com>
On Fri, Oct 14, 2016 at 08:53:02PM +0100, Ard Biesheuvel wrote:
> On 14 October 2016 at 19:26, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Oct 14, 2016 at 07:23:15PM +0100, Ard Biesheuvel wrote:
> >> On 13 October 2016 at 20:59, Timur Tabi <timur@codeaurora.org> wrote:
> >> > Ard Biesheuvel wrote:
> >> >>
> >> >> As it turns out, the KASLR code breaks CONFIG_MODVERSIONS, since the
> >> >> kcrctab has an absolute address field that is relocated at runtime
> >> >> when the kernel offset is randomized.
> >> >>
> >> >> This has been fixed already for PowerPC in the past, so simply wire up
> >> >> the existing code dealing with this issue.
> >> >>
> >> >> Signed-off-by: Ard Biesheuvel<ard.biesheuvel@linaro.org>
> >> >
> >> >
> >> > Tested-by: Timur Tabi <timur@codeaurora.org>
> >> >
> >>
> >> Thanks. I will resend this with a fixes: tag and a better description
> >
> > Feel free, but I already queued it locally and added the Fixes tag myself.
> > I'm just waiting for Lorenzo to post a fix to the ACPI NUMA stuff, then
> > I'll send these two up together next week.
>
> It's no big deal. The description is not entirely accurate in the
> sense that the kcrctab does not contain an absolute address field, but
> it masquerades as an absolute address so that the build system can
> populate the kcrctab entries using a linker script include containing
> name=value pairs. This does not only result in 4 wasted bytes per CRC,
> but on PPC64 and arm64 with CONFIG_RELOCATABLE=y, it also results in
> the breakage this patch addresses, and more importantly, results in a
> 24 byte RELA entry per CRC in the __init section. So I intend to
> propose a patch to change this in the generic code, after which this
> patch could be reverted.
>
> BTW, I spotted another KASLR issue, with ftrace this time, where it
> attempts to poke relative branches into modules targeting the core
> kernel, which is likely to fail when
> CONFIG_RANDOMIZE_MODULE_REGION_FULL=y. Should we address this at the
> Kconfig level? Or should we try to fix ftrace to support long
> branches?
I guess we could fix it at the kconfig level in the short term, then it
makes it clear that some ftrace work needs doing to fix it properly.
Will
^ permalink raw reply
* Regression: usb serial gadget on sama5d3 broken
From: Nicolas Ferre @ 2016-10-17 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <569c65cd-4e2e-4455-c24c-074f8c5fd315@axentia.se>
Le 17/10/2016 ? 14:53, Peter Rosin a ?crit :
> Hi!
>
> I'm suffering from a regression while using the usb gadget port on the
> sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
>
> I get this message when I try to connect:
> udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
>
> A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
> USB endpoint nodes".
>
> And indeed, reverting that commit on top of v4.9-rc1 fixes things,
> although that doesn't look like the best of fixes...
>
> BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
> somewhere in the overlayfs area. I hope I will never ever need to bisect
> in the v4.6..v4.7 area again. This was the second time, the first time
> I was chasing a gpio interrupt bug, but I never found out what was wrong
> and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
> was bad, it was just too painful to look for things that already seemed
> fixed.
I guess that you are referring to the regression listed here:
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1239220.html
The patch is available and will hopefully land in an official kernel
soon (4.8.1) as said by Felipe and Greg.
Sorry for the inconvenience. Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH -next] PCI: layerscape: Remove redundant dev_err call in ls_pcie_probe()
From: Wei Yongjun @ 2016-10-17 14:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pci/host/pci-layerscape.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
index 2cb7315..bbd3d23 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -251,10 +251,8 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
pcie->pp.dbi_base = devm_ioremap_resource(dev, dbi_base);
- if (IS_ERR(pcie->pp.dbi_base)) {
- dev_err(dev, "missing *regs* space\n");
+ if (IS_ERR(pcie->pp.dbi_base))
return PTR_ERR(pcie->pp.dbi_base);
- }
pcie->drvdata = match->data;
pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
^ permalink raw reply related
* [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping
From: Lorenzo Pieralisi @ 2016-10-17 14:56 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
bind to node0") removed the numa cpu<->node mapping restriction whereby
logical cpu 0 always corresponds to numa node 0; removing the
restriction was correct, in that it does not really exist in practice
but the commit only updated the early mapping of logical cpu 0 to its
real numa node for the DT boot path, missing the ACPI one, leading to
boot failures on ACPI systems owing to missing cpu<->node map for
logical cpu 0.
Fix the issue by updating the ACPI boot path with code that carries out
the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
what is currently done in the DT boot path.
Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
v1 -> v2
- Updated commit log to reflect boot failures set-ups
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d3f151c..8507703 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
return;
}
bootcpu_valid = true;
+ early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
return;
}
--
2.10.0
^ permalink raw reply related
* [PATCH -next] PCI: rockchip: Add missing of_node_put() in rockchip_pcie_init_irq_domain()
From: Wei Yongjun @ 2016-10-17 14:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
This node pointer is returned by of_get_next_child() with refcount
incremented in this function. of_node_put() on it before exitting
this function on error.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pci/host/pcie-rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index e0b22da..ab88859 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -949,6 +949,7 @@ static int rockchip_pcie_init_irq_domain(struct rockchip_pcie *rockchip)
&intx_domain_ops, rockchip);
if (!rockchip->irq_domain) {
dev_err(dev, "failed to get a INTx IRQ domain\n");
+ of_node_put(intc);
return -EINVAL;
}
^ permalink raw reply related
* [PATCH -next] PCI: xilinx-nwl: Add missing of_node_put() in nwl_pcie_init_irq_domain()
From: Wei Yongjun @ 2016-10-17 14:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
This node pointer is returned by of_get_next_child() with refcount
incremented in this function. of_node_put() on it before exitting
this function on error.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pci/host/pcie-xilinx-nwl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c
index 43eaa4a..c16b26c 100644
--- a/drivers/pci/host/pcie-xilinx-nwl.c
+++ b/drivers/pci/host/pcie-xilinx-nwl.c
@@ -535,6 +535,7 @@ static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
if (!pcie->legacy_irq_domain) {
dev_err(dev, "failed to create IRQ domain\n");
+ of_node_put(legacy_intc_node);
return -ENOMEM;
}
^ permalink raw reply related
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