* [PATCH v2 4/8] ARM: dts: am335x: Support the PMIC interrupt
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
AM335x bone based boards have the PMIC interrupt named NMI which is
connected to TPS65217 device. AM335x main interrupt controller provides it
and the number is 7.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 007b5e5..25303d9 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -310,6 +310,10 @@
* by the hardware problems. (Tip: double-check by performing a current
* measurement after shutdown: it should be less than 1 mA.)
*/
+
+ interrupts = <7>; /* NMI */
+ interrupt-parent = <&intc>;
+
ti,pmic-shutdown-controller;
regulators {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/8] ARM: dts: tps65217: Add the power button device
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Support the power button driver and disable it by default.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 8f77d0d..02de56b 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -21,6 +21,11 @@
status = "disabled";
};
+ pwrbutton {
+ compatible = "ti,tps65217-pwrbutton";
+ status = "disabled";
+ };
+
regulators {
#address-cells = <1>;
#size-cells = <0>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/8] ARM: dts: tps65217: Add the charger device
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
Support the charger driver and disable it by default.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 27935f8..8f77d0d 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -16,6 +16,11 @@
interrupt-controller;
#interrupt-cells = <1>;
+ charger {
+ compatible = "ti,tps65217-charger";
+ status = "disabled";
+ };
+
regulators {
#address-cells = <1>;
#size-cells = <0>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/8] ARM: dts: tps65217: Specify the interrupt controller
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028123702.21849-1-woogyom.kim@gmail.com>
TPS65217 MFD driver supports the IRQ domain to handle the charger input
interrupts and push button status event. The interrupt controller enables
corresponding IRQ handling in the charger[*] and power button driver[**].
[*] drivers/power/supply/tps65217_charger.c
[**] drivers/input/misc/tps65218-pwrbutton.c
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/tps65217.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index a632724..27935f8 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -13,6 +13,8 @@
&tps {
compatible = "ti,tps65217";
+ interrupt-controller;
+ #interrupt-cells = <1>;
regulators {
#address-cells = <1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/8] Support TPS65217 PMIC interrupt in DT
From: Milo Kim @ 2016-10-28 12:36 UTC (permalink / raw)
To: linux-arm-kernel
TPS65217 interrupt events include push button pressed/released, USB and AC
voltage status change. AM335x bone based boards (like BB, BBB, BBG) have
common PMIC interrupt pin (named NMI) of AM335x core.
This patchset support interrupts in device tree file.
v2:
Add missing a dt-binding header
Use #defines instead of enum type for interrupt numbers
Milo Kim (8):
ARM: dts: tps65217: Specify the interrupt controller
ARM: dts: tps65217: Add the charger device
ARM: dts: tps65217: Add the power button device
ARM: dts: am335x: Support the PMIC interrupt
dt-bindings: mfd: Provide human readable defines for TPS65217
interrupts
ARM: dts: am335x: Add the charger interrupt
ARM: dts: am335x: Add the power button interrupt
mfd: tps65217: Fix mismatched interrupt number
arch/arm/boot/dts/am335x-bone-common.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/tps65217.dtsi | 12 ++++++++++++
include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
include/linux/mfd/tps65217.h | 11 +++++------
4 files changed, 60 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/mfd/tps65217.h
--
2.9.3
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes
From: Leo Yan @ 2016-10-28 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f5dfafbb-39df-4edb-03b8-57c0e34c912f@samsung.com>
On Fri, Oct 28, 2016 at 08:52:49PM +0900, Jaehoon Chung wrote:
[...]
> >> Could you check the below thing..
> >>
> >> /* find reset controller when exist */
> >> - pdata->rstc = devm_reset_control_get_optional(dev, NULL);
> >> + pdata->rstc = devm_reset_control_get_optional(dev, "dwmci-reset");
> >> if (IS_ERR(pdata->rstc)) {
> >> if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
> >> return ERR_PTR(-EPROBE_DEFER);
> >
> > Confirmed with this fixing, the kernel can bootup successfully.
> >
> > Thanks for this.
>
> Thanks for checking this..If this approach is not bad, i will send the patch.
> Or if there are other good approaches, let me know, plz.
I'd like Guodong and John to confirm for Hikey specific. I have no
knowledge for this so cannot answer.
Thanks,
Leo Yan
^ permalink raw reply
* [PATCH] Revert "gpio/mvebu: convert to use irq_domain_add_simple()"
From: Linus Walleij @ 2016-10-28 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87twbyb65j.fsf@free-electrons.com>
On Thu, Oct 27, 2016 at 9:30 AM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> On lun., oct. 24 2016, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Wed, Oct 19, 2016 at 11:03 PM, Jason Gunthorpe
>> <jgunthorpe@obsidianresearch.com> wrote:
>>
>>> From 7566f05ac445b652ba7607cc1899fed10fea1c76 Mon Sep 17 00:00:00 2001
>>> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>>> Date: Wed, 19 Oct 2016 14:57:45 -0600
>>> Subject: [PATCH] gpio/mvebu: Use irq_domain_add_linear
>>>
>>> This fixes the irq allocation in this driver to not print:
>>> irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
>>> irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
>>>
>>> Which happens because the driver already called irq_alloc_descs()
>>> and so the change to use irq_domain_add_simple resulted in calling
>>> irq_alloc_descs() twice.
>>>
>>> Modernize the irq allocation in this driver to use the
>>> irq_domain_add_linear flow directly and eliminate the use of
>>> irq_domain_add_simple/legacy
>>>
>>> Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
>>> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>>
>> So can I just apply this?
>> Gregory?
>
> For me it's OK.
APplied this inline version.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Greg Kroah-Hartman @ 2016-10-28 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACQ1gAjX6fVghjxf=o_WNUDYFW6Sc_HF_3G6gxrSma5F3qjpbQ@mail.gmail.com>
On Fri, Oct 28, 2016 at 12:56:09PM +0200, Richard Genoud wrote:
> 2016-10-28 11:51 GMT+02:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > On Fri, Oct 28, 2016 at 01:13:31AM +0200, Alexandre Belloni wrote:
> >> On 27/10/2016 at 20:02:29 +0200, Uwe Kleine-K?nig wrote :
> >> > Hello Richard,
> >> >
> >> > On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
> >> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> >> > > index fd8aa1f4ba78..168b10cad47b 100644
> >> > > --- a/drivers/tty/serial/atmel_serial.c
> >> > > +++ b/drivers/tty/serial/atmel_serial.c
> >> > > @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> >> > > mode |= ATMEL_US_USMODE_RS485;
> >> > > } else if (termios->c_cflag & CRTSCTS) {
> >> > > /* RS232 with hardware handshake (RTS/CTS) */
> >> > > - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> >> > > - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> >> > > - termios->c_cflag &= ~CRTSCTS;
> >> > > - } else {
> >> > > + if (atmel_use_fifo(port) &&
> >> > > + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> >> > > + /*
> >> > > + * with ATMEL_US_USMODE_HWHS set, the controller will
> >> > > + * be able to drive the RTS pin high/low when the RX
> >> > > + * FIFO is above RXFTHRES/below RXFTHRES2.
> >> > > + * It will also disable the transmitter when the CTS
> >> > > + * pin is high.
> >> > > + * This mode is not activated if CTS pin is a GPIO
> >> > > + * because in this case, the transmitter is always
> >> > > + * disabled (there must be an internal pull-up
> >> > > + * responsible for this behaviour).
> >> > > + * If the RTS pin is a GPIO, the controller won't be
> >> > > + * able to drive it according to the FIFO thresholds,
> >> > > + * but it will be handled by the driver.
> >> > > + */
> >> > > mode |= ATMEL_US_USMODE_HWHS;
> >> >
> >> > You use
> >> >
> >> > !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
> >> >
> >> > as indicator that the cts mode of the respective pin is used. Is this
> >> > reliable? (It's not if there are machines that don't use CTS, neither as
> >> > gpio nor using the hardware function.) Maybe this needs a dt property to
> >> > indicate that there is no (hw)handshaking available?
> >> >
> >>
> >> We had a call today were we agreed that this should be added in a future
> >> patch. Let's fix the regression for now.
> >
> > A machine without CTS (neither gpio nor hw function) used to work fine
> > before the breaking commit, right? So this case is part of the
> > regression and needs a fix?
> Actually, a machine with a FIFO and without CTS didn't even exist at the
> time of the breaking commit (v4.0), the FIFO handling was introduced later,
> so it's not even a regression !
>
> > Anyhow, this probably shouldn't stop the commit entering mainline
> > because there are probably very few such machines (if any).
> >
> > So:
> > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> >
> > Best regards
> > Uwe
>
>
> Thanks !
>
> Greg, could you take this in your tree ?
Now applied, thanks for working through all of this.
greg k-h
^ permalink raw reply
* [PATCH] ARM: davinci: enable PM for DT boot
From: Sekhar Nori @ 2016-10-28 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025214738.27744-1-khilman@baylibre.com>
Hi Kevin,
On Wednesday 26 October 2016 03:17 AM, Kevin Hilman wrote:
> Currently system PM is only enabled for legacy (non-DT) boot. Enable
> for DT boot also.
>
> Tested on da850-lcdk using "rtcwake -m mem -s5 -d rtc0".
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> arch/arm/mach-davinci/da8xx-dt.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index c9f7e9274aa8..a8089fa40d86 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -43,8 +43,26 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>
> #ifdef CONFIG_ARCH_DAVINCI_DA850
>
> +static struct davinci_pm_config da850_pm_pdata = {
> + .sleepcount = 128,
> +};
> +
> +static struct platform_device da850_pm_device = {
> + .name = "pm-davinci",
> + .dev = {
> + .platform_data = &da850_pm_pdata,
> + },
> + .id = -1,
> +};
> +
> static void __init da850_init_machine(void)
> {
> + int ret;
> +
> + ret = da850_register_pm(&da850_pm_device);
I am not sure if it makes sense to keep the "pm device" around anymore.
I think for both DT and non-DT boot, we can get rid of the fake PM
device and combine da850_register_pm() and davinci_pm_probe() into a
single davinci_init_suspend() function which can then be called both for
DT and non-DT boot.
This was we can also avoid replication of the platform data and platform
device structures.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes
From: Jaehoon Chung @ 2016-10-28 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028101919.GA25564@leoy-linaro>
Hi,
On 10/28/2016 07:19 PM, Leo Yan wrote:
> On Fri, Oct 28, 2016 at 06:54:58PM +0900, Jaehoon Chung wrote:
>
> [...]
>
>>>>> Could you share the log? Is there any log about failure?
>>>>
>>>> Sure, please see below log:
>>>
>>> It's related with -EPROBE_DEFER..I'm not sure but if CONFIG_RESET_CONTROLLER is enabled, it's searching for reset controller.
>>> Maybe hi6220 has handled the reset controller(?)...
>>>
>>> I'm checking devm_reset_control_xxx...It's possible to occur the other boards which enabled RESET_CONTROLLER..
>>
>> Could you check the below thing..
>>
>> /* find reset controller when exist */
>> - pdata->rstc = devm_reset_control_get_optional(dev, NULL);
>> + pdata->rstc = devm_reset_control_get_optional(dev, "dwmci-reset");
>> if (IS_ERR(pdata->rstc)) {
>> if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
>> return ERR_PTR(-EPROBE_DEFER);
>
> Confirmed with this fixing, the kernel can bootup successfully.
>
> Thanks for this.
Thanks for checking this..If this approach is not bad, i will send the patch.
Or if there are other good approaches, let me know, plz.
Best Regards,
Jaehoon Chung
>
>> To prevent the wrong controlling, how about adding "#reset-names" for dwmmc controller?
>>
>>
>> Best Regards,
>> Jaehoon Chung
>
>
>
^ permalink raw reply
* [PATCHv4 4/4] arm64: dump: Add checking for writable and exectuable pages
From: Ard Biesheuvel @ 2016-10-28 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477585654-8908-5-git-send-email-labbott@redhat.com>
On 27 October 2016 at 17:27, Laura Abbott <labbott@redhat.com> wrote:
>
> Page mappings with full RWX permissions are a security risk. x86
> has an option to walk the page tables and dump any bad pages.
> (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar
> implementation for arm64.
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v4: Changed pr_info -> pr_warn. Added a separate count variable for uxn to avoid
> double counting.
> ---
> arch/arm64/Kconfig.debug | 29 ++++++++++++++++++++++
> arch/arm64/include/asm/ptdump.h | 8 +++++++
> arch/arm64/mm/dump.c | 53 +++++++++++++++++++++++++++++++++++++++++
> arch/arm64/mm/mmu.c | 2 ++
> 4 files changed, 92 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index 21a5b74..d1ebd46 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -42,6 +42,35 @@ config ARM64_RANDOMIZE_TEXT_OFFSET
> of TEXT_OFFSET and platforms must not require a specific
> value.
>
> +config DEBUG_WX
> + bool "Warn on W+X mappings at boot"
> + select ARM64_PTDUMP_CORE
> + ---help---
> + Generate a warning if any W+X mappings are found at boot.
> +
> + This is useful for discovering cases where the kernel is leaving
> + W+X mappings after applying NX, as such mappings are a security risk.
> + This check also includes UXN, which should be set on all kernel
> + mappings.
> +
> + Look for a message in dmesg output like this:
> +
> + arm64/mm: Checked W+X mappings: passed, no W+X pages found.
> +
> + or like this, if the check failed:
> +
> + arm64/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
> +
> + Note that even if the check fails, your kernel is possibly
> + still fine, as W+X mappings are not a security hole in
> + themselves, what they do is that they make the exploitation
> + of other unfixed kernel bugs easier.
> +
> + There is no runtime or memory usage effect of this option
> + once the kernel has booted up - it's a one time check.
> +
> + If in doubt, say "Y".
> +
> config DEBUG_SET_MODULE_RONX
> bool "Set loadable kernel module data as NX and text as RO"
> depends on MODULES
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index f72ee69..6afd847 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -42,5 +42,13 @@ static inline int ptdump_debugfs_register(struct ptdump_info *info,
> return 0;
> }
> #endif
> +void ptdump_check_wx(void);
> #endif /* CONFIG_ARM64_PTDUMP_CORE */
> +
> +#ifdef CONFIG_DEBUG_WX
> +#define debug_checkwx() ptdump_check_wx()
> +#else
> +#define debug_checkwx() do { } while (0)
> +#endif
> +
> #endif /* __ASM_PTDUMP_H */
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index bb36649..ef8aca8 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -74,6 +74,9 @@ struct pg_state {
> unsigned long start_address;
> unsigned level;
> u64 current_prot;
> + bool check_wx;
> + unsigned long wx_pages;
> + unsigned long uxn_pages;
> };
>
> struct prot_bits {
> @@ -202,6 +205,35 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits,
> }
> }
>
> +static void note_prot_uxn(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> +
> + if ((st->current_prot & PTE_UXN) == PTE_UXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found non-UXN mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->uxn_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
> +static void note_prot_wx(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> + if ((st->current_prot & PTE_RDONLY) == PTE_RDONLY)
> + return;
> + if ((st->current_prot & PTE_PXN) == PTE_PXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found insecure W+X mapping at address %p/%pS\n",
> + (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}
> +
> static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> u64 val)
> {
> @@ -219,6 +251,8 @@ static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
> unsigned long delta;
>
> if (st->current_prot) {
> + note_prot_uxn(st, addr);
> + note_prot_wx(st, addr);
> pt_dump_seq_printf(st->seq, "0x%016lx-0x%016lx ",
> st->start_address, addr);
>
> @@ -344,6 +378,25 @@ static struct ptdump_info kernel_ptdump_info = {
> .base_addr = VA_START,
> };
>
> +void ptdump_check_wx(void)
> +{
> + struct pg_state st = {
> + .seq = NULL,
> + .marker = (struct addr_marker[]) {
> + { -1, NULL},
> + },
> + .check_wx = true,
> + };
> +
> + walk_pgd(&st, &init_mm, 0);
> + note_page(&st, 0, 0, 0);
> + if (st.wx_pages || st.uxn_pages)
> + pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found, %lu non-UXN pages found\n",
> + st.wx_pages, st.uxn_pages);
> + else
> + pr_info("Checked W+X mappings: passed, no W+X pages found\n");
> +}
> +
> static int ptdump_init(void)
> {
> ptdump_initialize();
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 05615a3..2cbe2fe 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -42,6 +42,7 @@
> #include <asm/tlb.h>
> #include <asm/memblock.h>
> #include <asm/mmu_context.h>
> +#include <asm/ptdump.h>
>
> u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>
> @@ -396,6 +397,7 @@ void mark_rodata_ro(void)
> section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
> create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> section_size, PAGE_KERNEL_RO);
> + debug_checkwx();
> }
>
> static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Fabio Estevam @ 2016-10-28 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028014127.GD16026@codeaurora.org>
Hi Stephen,
On Thu, Oct 27, 2016 at 11:41 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/12, Emil Lundmark wrote:
>> Since 'parent_rate * mfn' may overflow 32 bits, the result should be
>> stored using 64 bits.
>>
>> The problem was discovered when trying to set the rate of the audio PLL
>> (pll4_post_div) on an i.MX6Q. The desired rate was 196.608 MHz, but
>> the actual rate returned was 192.000570 MHz. The round rate function should
>> have been able to return 196.608 MHz, i.e., the desired rate.
>>
>> Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
>> Cc: Anson Huang <b20788@freescale.com>
>> Signed-off-by: Emil Lundmark <emil@limesaudio.com>
>> ---
>
> Applied to clk-next
This one fixes a regression caused by ba7f4f557eb6 ("clk: imx: correct
AV PLL rate formula").
So it should go to clk-fixes instead with the stable tag:
Cc: <stable@vger.kernel.org> # 4.8.x
Thanks
^ permalink raw reply
* [PATCH 1/1] ARM: dts: imx6ul-14x14-evk: add USB dual-role support
From: Fabio Estevam @ 2016-10-28 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470128903-942-1-git-send-email-peter.chen@nxp.com>
On Tue, Aug 2, 2016 at 6:08 AM, Peter Chen <peter.chen@nxp.com> wrote:
> With commit 851ce932242d ("usb: chipidea: otg: don't wait vbus
> drops below BSV when starts host"), the driver can support
> enabling vbus output without software control, so this board
> (control vbus output through ID pin) can support dual-role now.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [GIT PULL] arm64: dts: juno: updates for v4.10
From: Sudeep Holla @ 2016-10-28 11:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC Team,
Please pull.
--
Regards,
Sudeep
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-dt-4.10
for you to fetch changes up to c1ab65b24065ab04bdb0bc4e89d88784d38dc644:
arm64: dts: juno: add cpu capacity-dmips-mhz information to R2 boards (2016-10-17 17:43:22 +0100)
----------------------------------------------------------------
ARMv8 Vexpress/Juno DT updates for v4.10
1. Addition of SMMU(MMU-401) device nodes mainly to assist other
developments and testing
2. Addition of CPU dmips/capacity information on all the Juno boards
----------------------------------------------------------------
Juri Lelli (3):
arm64: dts: juno: add cpu capacity-dmips-mhz information to R0 boards
arm64: dts: juno: add cpu capacity-dmips-mhz information to R1 boards
arm64: dts: juno: add cpu capacity-dmips-mhz information to R2 boards
Robin Murphy (1):
arm64: dts: juno: Add SMMUs device nodes
arch/arm64/boot/dts/arm/juno-base.dtsi | 80 ++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/arm/juno-r1.dts | 6 +++
arch/arm64/boot/dts/arm/juno-r2.dts | 6 +++
arch/arm64/boot/dts/arm/juno.dts | 6 +++
4 files changed, 98 insertions(+)
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: fixes/updates for v4.10
From: Sudeep Holla @ 2016-10-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM Soc Team,
Please pull !
--
Regards,
Sudeep
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-dt-4.10
for you to fetch changes up to b01c3994817dc4e117c5642c3e09e0a231b5b477:
ARM: dts: vexpress: add TC2 cpu capacity-dmips-mhz information (2016-10-17 17:05:58 +0100)
----------------------------------------------------------------
ARMv7 Vexpress DT fixes/updates for v4.10
1. Addition of CPU dmips/capacity information to TC2 platform
2. Cleanup/fix unit address warnings and removal of skeleton.dtsi from
MPS2 device tree
----------------------------------------------------------------
Juri Lelli (1):
ARM: dts: vexpress: add TC2 cpu capacity-dmips-mhz information
Vladimir Murzin (1):
ARM: dts: mps2: remove skeleton.dtsi include and fix unit address warnings
arch/arm/boot/dts/mps2-an385.dts | 2 +-
arch/arm/boot/dts/mps2-an399.dts | 2 +-
arch/arm/boot/dts/mps2.dtsi | 4 +++-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 5 +++++
4 files changed, 10 insertions(+), 3 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: vexpress: fixes for v4.10
From: Sudeep Holla @ 2016-10-28 11:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC team,
These couple of fixes help to boot TC2 in HYP mode with CONFIG_MCPM
enabled. This was not supported directly before and hence targeting for
v4.10. Currently those who want to boot in HYP mode have to disable
MCPM config in the build.
Please pull.
--
Regards,
Sudeep
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-fixes-4.10
for you to fetch changes up to 801f33be8e902d8cea75cb7ac056d07c4fdd25f8:
drivers: cci: add missing CCI port availability firmware check (2016-10-17 14:27:54 +0100)
----------------------------------------------------------------
ARMv7 Vexpress fixes for v4.10
Couple of fixes to MCPM/CCI drivers to check and ensure that the kernel
is actually allowed to take control over CCI ports(i.e. running in
secure mode) before enabling MCPM.
This is needed to boot Linux in HYP mode (very useful for development
on virtualization) with CONFIG_MCPM enabled kernel.
----------------------------------------------------------------
Lorenzo Pieralisi (2):
ARM: vexpress: refine MCPM smp operations override criteria
drivers: cci: add missing CCI port availability firmware check
arch/arm/mach-vexpress/platsmp.c | 34 ++++++++++++++++++++++++++--------
drivers/bus/arm-cci.c | 10 ++++++++++
2 files changed, 36 insertions(+), 8 deletions(-)
^ permalink raw reply
* [GIT PULL] firmware: SCPI updates for v4.10
From: Sudeep Holla @ 2016-10-28 11:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM-SoC Team,
Please pull !
--
Regards,
Sudeep
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scpi-updates-4.10
for you to fetch changes up to a9e0192d8b35c6ab115a154ed1499ff39a0e5b06:
firmware: arm_scpi: add support for legacy match table on Amlogic GXBB SoC (2016-10-19 15:17:28 +0100)
----------------------------------------------------------------
SCPI updates for v4.10
1. Adds support for Legacy SCPI(pre- SCPI v1.0) protocol
2. Adds support for SCPI used on Amlogic GXBB SoC using the legacy
SCPI protocol
----------------------------------------------------------------
Neil Armstrong (5):
dt-bindings: Add support for Amlogic GXBB SCPI Interface
firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
firmware: arm_scpi: add alternative legacy structures, functions and macros
firmware: arm_scpi: allow firmware with get_capabilities not implemented
firmware: arm_scpi: add support for legacy match table on Amlogic GXBB SoC
Sudeep Holla (1):
firmware: arm_scpi: add command indirection to support legacy commands
Documentation/devicetree/bindings/arm/arm,scpi.txt | 8 +-
drivers/firmware/arm_scpi.c | 276 ++++++++++++++++++---
2 files changed, 249 insertions(+), 35 deletions(-)
^ permalink raw reply
* [PATCH 2/2] irqchip/gic-v3: Use nops macro for Cavium ThunderX erratum 23154
From: Will Deacon @ 2016-10-28 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477653838-21569-1-git-send-email-will.deacon@arm.com>
The workaround for Cavium ThunderX erratum 23154 has a homebrew
pipeflush built out of NOP sequences around the read of the IAR.
This patch converts the code to use the new nops macro, which makes it
a little easier to read.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/arch_gicv3.h | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
index fdf34f8b4ee0..0313670a3e3f 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -122,14 +122,9 @@ static inline u64 gic_read_iar_cavium_thunderx(void)
{
u64 irqstat;
- asm volatile(
- "nop;nop;nop;nop\n\t"
- "nop;nop;nop;nop");
-
+ nops(8);
irqstat = read_sysreg_s(ICC_IAR1_EL1);
-
- asm volatile(
- "nop;nop;nop;nop");
+ nops(4);
mb();
return irqstat;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] irqchip/gic-v3: Convert arm64 GIC accessors to {read, write}_sysreg_s
From: Will Deacon @ 2016-10-28 11:23 UTC (permalink / raw)
To: linux-arm-kernel
The GIC system registers are accessed using open-coded wrappers around
the mrs_s/msr_s asm macros.
This patch moves the code over to the {read,wrote}_sysreg_s accessors
instead, reducing the amount of explicit asm blocks in the arch headers.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/arch_gicv3.h | 45 ++++++++++++++-----------------------
1 file changed, 17 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
index f8ae6d6e4767..fdf34f8b4ee0 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -80,18 +80,8 @@
#include <linux/stringify.h>
#include <asm/barrier.h>
-#define read_gicreg(r) \
- ({ \
- u64 reg; \
- asm volatile("mrs_s %0, " __stringify(r) : "=r" (reg)); \
- reg; \
- })
-
-#define write_gicreg(v,r) \
- do { \
- u64 __val = (v); \
- asm volatile("msr_s " __stringify(r) ", %0" : : "r" (__val));\
- } while (0)
+#define read_gicreg read_sysreg_s
+#define write_gicreg write_sysreg_s
/*
* Low-level accessors
@@ -102,13 +92,13 @@
static inline void gic_write_eoir(u32 irq)
{
- asm volatile("msr_s " __stringify(ICC_EOIR1_EL1) ", %0" : : "r" ((u64)irq));
+ write_sysreg_s(irq, ICC_EOIR1_EL1);
isb();
}
static inline void gic_write_dir(u32 irq)
{
- asm volatile("msr_s " __stringify(ICC_DIR_EL1) ", %0" : : "r" ((u64)irq));
+ write_sysreg_s(irq, ICC_DIR_EL1);
isb();
}
@@ -116,7 +106,7 @@ static inline u64 gic_read_iar_common(void)
{
u64 irqstat;
- asm volatile("mrs_s %0, " __stringify(ICC_IAR1_EL1) : "=r" (irqstat));
+ irqstat = read_sysreg_s(ICC_IAR1_EL1);
dsb(sy);
return irqstat;
}
@@ -134,10 +124,12 @@ static inline u64 gic_read_iar_cavium_thunderx(void)
asm volatile(
"nop;nop;nop;nop\n\t"
- "nop;nop;nop;nop\n\t"
- "mrs_s %0, " __stringify(ICC_IAR1_EL1) "\n\t"
- "nop;nop;nop;nop"
- : "=r" (irqstat));
+ "nop;nop;nop;nop");
+
+ irqstat = read_sysreg_s(ICC_IAR1_EL1);
+
+ asm volatile(
+ "nop;nop;nop;nop");
mb();
return irqstat;
@@ -145,37 +137,34 @@ static inline u64 gic_read_iar_cavium_thunderx(void)
static inline void gic_write_pmr(u32 val)
{
- asm volatile("msr_s " __stringify(ICC_PMR_EL1) ", %0" : : "r" ((u64)val));
+ write_sysreg_s(val, ICC_PMR_EL1);
}
static inline void gic_write_ctlr(u32 val)
{
- asm volatile("msr_s " __stringify(ICC_CTLR_EL1) ", %0" : : "r" ((u64)val));
+ write_sysreg_s(val, ICC_CTLR_EL1);
isb();
}
static inline void gic_write_grpen1(u32 val)
{
- asm volatile("msr_s " __stringify(ICC_GRPEN1_EL1) ", %0" : : "r" ((u64)val));
+ write_sysreg_s(val, ICC_GRPEN1_EL1);
isb();
}
static inline void gic_write_sgi1r(u64 val)
{
- asm volatile("msr_s " __stringify(ICC_SGI1R_EL1) ", %0" : : "r" (val));
+ write_sysreg_s(val, ICC_SGI1R_EL1);
}
static inline u32 gic_read_sre(void)
{
- u64 val;
-
- asm volatile("mrs_s %0, " __stringify(ICC_SRE_EL1) : "=r" (val));
- return val;
+ return read_sysreg_s(ICC_SRE_EL1);
}
static inline void gic_write_sre(u32 val)
{
- asm volatile("msr_s " __stringify(ICC_SRE_EL1) ", %0" : : "r" ((u64)val));
+ write_sysreg_s(val, ICC_SRE_EL1);
isb();
}
--
2.1.4
^ permalink raw reply related
* [PATCH] fpga zynq: Check the bitstream for validity
From: Matthias Brugger @ 2016-10-28 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026225413.GA6220@obsidianresearch.com>
On 10/27/2016 12:54 AM, Jason Gunthorpe wrote:
> There is no sense in sending a bitstream we know will not work, and
> with the variety of options for bitstream generation in Xilinx tools
> it is not terribly clear or very well documented what the correct
> input should be, especially since auto-detection was removed from this
> driver.
>
> All Zynq full configuration bitstreams must start with the sync word in
> the correct byte order.
>
> Zynq is also only able to DMA dword quantities, so bitstreams must be
> a multiple of 4 bytes. This also fixes a DMA-past the end bug.
>
The you can also fix the transfer_length calculation in
zynq_fpga_ops_write, as we don't allow buffers which are not a multiple
of 4.
Regards,
Matthias
^ permalink raw reply
* [RFC][PATCH] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Mark Rutland @ 2016-10-28 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9-Pm_j-3shoiGZY+8zMBjTpNOXOphwea+tdC4KPbie3Q@mail.gmail.com>
On Fri, Oct 28, 2016 at 08:52:50AM +0100, Ard Biesheuvel wrote:
> Hi Laura,
>
> On 28 October 2016 at 01:18, Laura Abbott <labbott@redhat.com> wrote:
> > x86 has an option CONFIG_DEBUG_VIRTUAL to do additional checks
> > on virt_to_phys calls. The goal is to catch users who are calling
> > virt_to_phys on non-linear addresses immediately. As features
> > such as CONFIG_VMAP_STACK get enabled for arm64, this becomes
> > increasingly important. Add checks to catch bad virt_to_phys
> > usage.
>
> I think this is a useful thing to have. However, the Kconfig
> description talks about virt to page translations, not virt to phys.
> Of course, this is a shift away from being equivalent on x86, but not
> so much on arm64. Any concerns there?
See commit 59ea746337c69f6a ("MM: virtual address debug"); the existing
x86 cases cover virt to phys also.
The Kconfig text does say "and friends"...
Thanks,
Mark.
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Matthias Brugger @ 2016-10-28 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027143937.GC6818@obsidianresearch.com>
On 10/27/2016 04:39 PM, Jason Gunthorpe wrote:
> On Thu, Oct 27, 2016 at 10:50:48AM +0200, Matthias Brugger wrote:
>>> + /* Sanity check the proposed bitstream. It must start with the
>>> + * sync word in the correct byte order and be a multiple of 4
>>> + * bytes.
>>> + */
>>> + if (count <= 4 || buf[0] != 0x66 || buf[1] != 0x55 ||
>>> + buf[2] != 0x99 || buf[3] != 0xaa) {
>>
>> This checks if the bit stream is bigger then 4 bytes. We error out before,
>> if it is smaller.
>
> We do? Where?
>
Just a few lines before:
+ /* All valid bitstreams are multiples of 32 bits */
+ if ((count % 4) != 0)
+ return -EINVAL;
+
The only case we don't check is, if count == 0. If we check that here,
we can get rid of the count <= 4 check.
>> So you should fix the wording in the comment and check for count ==
>> 4.
>
> Ah right, the comment reflected an earlier revision that had the
> length check here.
>
> The count <= 4 should stay here since it is primarily guarding against
> read past the buffer in the if.
If you insist in doing this check, it should be count < 4, because we
check the first four elements of buf, or do I miss something?
Cheers,
Matthias
>
> Jason
>
> _______________________________________________
> 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 v2] irqchip/bcm2836: Prevent spurious interrupts
From: Thomas Gleixner @ 2016-10-28 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027182038.11312-1-eric@anholt.net>
On Thu, 27 Oct 2016, Eric Anholt wrote:
> From: Phil Elwell <phil@raspberrypi.org>
>
> The old arch-specific IRQ macros included a dsb to ensure the
> write to clear the mailbox interrupt completed before returning
> from the interrupt. The BCM2836 irqchip driver needs the same
> precaution to avoid spurious interrupts.
This is missing a fixes tag. I have no idea when that problem was
introduced, so I have no way to decide whether this needs to be tagged
stable or not.
Thanks,
tglx
>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> drivers/irqchip/irq-bcm2836.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
> index d96b2c947e74..93e3f7660c42 100644
> --- a/drivers/irqchip/irq-bcm2836.c
> +++ b/drivers/irqchip/irq-bcm2836.c
> @@ -175,6 +175,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct pt_regs *regs)
> u32 ipi = ffs(mbox_val) - 1;
>
> writel(1 << ipi, mailbox0);
> + dsb(sy);
> handle_IPI(ipi, regs);
> #endif
> } else if (stat) {
> --
> 2.9.3
>
>
^ permalink raw reply
* [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Richard Genoud @ 2016-10-28 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028095151.f24lhelfknzrpy6c@pengutronix.de>
2016-10-28 11:51 GMT+02:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> On Fri, Oct 28, 2016 at 01:13:31AM +0200, Alexandre Belloni wrote:
>> On 27/10/2016 at 20:02:29 +0200, Uwe Kleine-K?nig wrote :
>> > Hello Richard,
>> >
>> > On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote:
>> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> > > index fd8aa1f4ba78..168b10cad47b 100644
>> > > --- a/drivers/tty/serial/atmel_serial.c
>> > > +++ b/drivers/tty/serial/atmel_serial.c
>> > > @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
>> > > mode |= ATMEL_US_USMODE_RS485;
>> > > } else if (termios->c_cflag & CRTSCTS) {
>> > > /* RS232 with hardware handshake (RTS/CTS) */
>> > > - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
>> > > - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
>> > > - termios->c_cflag &= ~CRTSCTS;
>> > > - } else {
>> > > + if (atmel_use_fifo(port) &&
>> > > + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
>> > > + /*
>> > > + * with ATMEL_US_USMODE_HWHS set, the controller will
>> > > + * be able to drive the RTS pin high/low when the RX
>> > > + * FIFO is above RXFTHRES/below RXFTHRES2.
>> > > + * It will also disable the transmitter when the CTS
>> > > + * pin is high.
>> > > + * This mode is not activated if CTS pin is a GPIO
>> > > + * because in this case, the transmitter is always
>> > > + * disabled (there must be an internal pull-up
>> > > + * responsible for this behaviour).
>> > > + * If the RTS pin is a GPIO, the controller won't be
>> > > + * able to drive it according to the FIFO thresholds,
>> > > + * but it will be handled by the driver.
>> > > + */
>> > > mode |= ATMEL_US_USMODE_HWHS;
>> >
>> > You use
>> >
>> > !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)
>> >
>> > as indicator that the cts mode of the respective pin is used. Is this
>> > reliable? (It's not if there are machines that don't use CTS, neither as
>> > gpio nor using the hardware function.) Maybe this needs a dt property to
>> > indicate that there is no (hw)handshaking available?
>> >
>>
>> We had a call today were we agreed that this should be added in a future
>> patch. Let's fix the regression for now.
>
> A machine without CTS (neither gpio nor hw function) used to work fine
> before the breaking commit, right? So this case is part of the
> regression and needs a fix?
Actually, a machine with a FIFO and without CTS didn't even exist at the
time of the breaking commit (v4.0), the FIFO handling was introduced later,
so it's not even a regression !
> Anyhow, this probably shouldn't stop the commit entering mainline
> because there are probably very few such machines (if any).
>
> So:
> Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
>
> Best regards
> Uwe
Thanks !
Greg, could you take this in your tree ?
regards,
Richard.
^ permalink raw reply
* [v15, 0/7] Fix eSDHC host version register bug
From: Arnd Bergmann @ 2016-10-28 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477637418-38938-1-git-send-email-yangbo.lu@nxp.com>
On Friday, October 28, 2016 2:50:11 PM CEST Yangbo Lu wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first five patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
Looks good overall. With patch 3 dropped (or an explanation why it's still
needed), everything
Acked-by: Arnd Bergmann <arnd@arndb.de>
Arnd
^ 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