Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3] devicetree: bindings: nvmem: Add compatible string for imx6ul
From: Bai Ping @ 2016-11-07  5:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478497281-5477-1-git-send-email-ping.bai@nxp.com>

Add new compatible string for i.MX6UL SOC.

Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
 Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
index 383d588..a7ff65d 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
@@ -1,13 +1,14 @@
 Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
 
 This binding represents the on-chip eFuse OTP controller found on
-i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs.
+i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs.
 
 Required properties:
 - compatible: should be one of
 	"fsl,imx6q-ocotp" (i.MX6Q/D/DL/S),
-	"fsl,imx6sl-ocotp" (i.MX6SL), or
-	"fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon".
+	"fsl,imx6sl-ocotp" (i.MX6SL),
+	"fsl,imx6sx-ocotp" (i.MX6SX), or
+	"fsl,imx6ul-ocotp" (i.MX6UL), followed by "syscon".
 - reg: Should contain the register base and length.
 - clocks: Should contain a phandle pointing to the gated peripheral clock.
 
-- 
2.8.2

^ permalink raw reply related

* [PATCH 1/3] driver: nvmem: Add ocotp driver support for imx6ul
From: Bai Ping @ 2016-11-07  5:41 UTC (permalink / raw)
  To: linux-arm-kernel

i.MX6UL is an new SOC of i.MX6 family. Enable ocotp
driver support for this SOC.

Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
 drivers/nvmem/imx-ocotp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index ac27b9b..108e4bc 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -73,6 +73,7 @@ static const struct of_device_id imx_ocotp_dt_ids[] = {
 	{ .compatible = "fsl,imx6q-ocotp",  (void *)128 },
 	{ .compatible = "fsl,imx6sl-ocotp", (void *)32 },
 	{ .compatible = "fsl,imx6sx-ocotp", (void *)128 },
+	{ .compatible = "fsl,imx6ul-ocotp", (void *)128 },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids);
-- 
2.8.2

^ permalink raw reply related

* [3/4] ARM: EXYNOS: Remove static mapping of SCU SFR
From: Alim Akhtar @ 2016-11-07  4:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <581FE87E.2040607@samsung.com>

Hi Pankaj,

On 11/07/2016 08:05 AM, pankaj.dubey wrote:
> Hi Alim,
>
> On Friday 04 November 2016 06:56 PM, Alim Akhtar wrote:
>> Hi Pankaj,
>>
>> On 11/04/2016 09:09 AM, Pankaj Dubey wrote:
>>> Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC
>>> based boards.
>>> Instead use mapping from device tree node of SCU.
>>>
>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>> ---
>>>    arch/arm/mach-exynos/exynos.c                | 22
>>> ----------------------
>>>    arch/arm/mach-exynos/include/mach/map.h      |  2 --
>>>    arch/arm/mach-exynos/platsmp.c               | 18 +++++++++++-------
>>>    arch/arm/mach-exynos/pm.c                    | 14 +++++++++++---
>>>    arch/arm/mach-exynos/suspend.c               | 15 +++++++++++----
>>>    arch/arm/plat-samsung/include/plat/map-s5p.h |  4 ----
>>>    6 files changed, 33 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/exynos.c
>>> b/arch/arm/mach-exynos/exynos.c
>>> index 757fc11..fa08ef9 100644
>>> --- a/arch/arm/mach-exynos/exynos.c
>>> +++ b/arch/arm/mach-exynos/exynos.c
>>> @@ -28,15 +28,6 @@
>>>
>>>    #include "common.h"
>>>
>>> -static struct map_desc exynos4_iodesc[] __initdata = {
>>> -    {
>>> -        .virtual    = (unsigned long)S5P_VA_COREPERI_BASE,
>>> -        .pfn        = __phys_to_pfn(EXYNOS4_PA_COREPERI),
>>> -        .length        = SZ_8K,
>>> -        .type        = MT_DEVICE,
>>> -    },
>>> -};
>>> -
>>>    static struct platform_device exynos_cpuidle = {
>>>        .name              = "exynos_cpuidle",
>>>    #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
>>> @@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned
>>> long node, const char *uname,
>>>        return 1;
>>>    }
>>>
>>> -/*
>>> - * exynos_map_io
>>> - *
>>> - * register the standard cpu IO areas
>>> - */
>>> -static void __init exynos_map_io(void)
>>> -{
>>> -    if (soc_is_exynos4())
>>> -        iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
>>> -}
>>> -
>>>    static void __init exynos_init_io(void)
>>>    {
>>>        debug_ll_io_init();
>>> @@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
>>>
>>>        /* detect cpu id and rev. */
>>>        s5p_init_cpu(S5P_VA_CHIPID);
>>> -
>>> -    exynos_map_io();
>>>    }
>>>
>>>    /*
>>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
>>> b/arch/arm/mach-exynos/include/mach/map.h
>>> index 5fb0040..0eef407 100644
>>> --- a/arch/arm/mach-exynos/include/mach/map.h
>>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>>> @@ -18,6 +18,4 @@
>>>
>>>    #define EXYNOS_PA_CHIPID        0x10000000
>>>
>>> -#define EXYNOS4_PA_COREPERI        0x10500000
>>> -
>>>    #endif /* __ASM_ARCH_MAP_H */
>>> diff --git a/arch/arm/mach-exynos/platsmp.c
>>> b/arch/arm/mach-exynos/platsmp.c
>>> index a5d6841..553d0d9 100644
>>> --- a/arch/arm/mach-exynos/platsmp.c
>>> +++ b/arch/arm/mach-exynos/platsmp.c
>>> @@ -224,11 +224,6 @@ static void write_pen_release(int val)
>>>        sync_cache_w(&pen_release);
>>>    }
>>>
>>> -static void __iomem *scu_base_addr(void)
>>> -{
>>> -    return (void __iomem *)(S5P_VA_SCU);
>>> -}
>>> -
>>>    static DEFINE_SPINLOCK(boot_lock);
>>>
>>>    static void exynos_secondary_init(unsigned int cpu)
>>> @@ -387,14 +382,23 @@ fail:
>>>
>>>    static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
>>>    {
>>> +    struct device_node *np;
>>> +    void __iomem *scu_base;
>>>        int i;
>>>
>>>        exynos_sysram_init();
>>>
>>>        exynos_set_delayed_reset_assertion(true);
>>>
>>> -    if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
>>> -        scu_enable(scu_base_addr());
>>> +    if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
>>> +        np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
>>
>> what if of_find_compatible_node() fails? May be add a error check for
>> the same?
>
> Thanks for review.
>
> You are right of_find_compatible_node() is bound to fail, but only in
> case supplied compatible is missing in DT. In our case this piece of
> code will execute only for Cortex-A9 based SoC (which in case of Exynos
> SoC is applicable only for Exynos4 series) and we will for sure
> providing "arm,cortex-a9-scu" in DT, so there is no chance of failure.
> So I feel extra check on "np" for NULL will add no benefit here.
>
Well I am not entirely convenience here, I still feel it better to have 
those check, lets not assume anything about future, but when I see 
of_find_compatible_node() uses elsewhere in kernel, both kind of uses 
are there (with/without error check).
So, I leave it to you and maintainer to take a call on this, otherwise 
this patch looks good.

Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>

>
> Thanks,
> Pankaj Dubey
>
>

^ permalink raw reply

* [PATCH v2 0/9] ARM: DRA7: Add support for DRA718-evm
From: Lokesh Vutla @ 2016-11-07  3:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>

Hi Tony,

On Friday 21 October 2016 04:08 PM, Lokesh Vutla wrote:
> This series does minor dts cleanup for dra72-evm and adds support for
> DRA718-evm.

Do you have any comments on this series?

Thanks and regards,
Lokesh

> 
> Changes since v1:
> - Updated xxx-supply to xxx-in-supply in Documentation.
> 
> Lokesh Vutla (7):
>   ARM: dts: dra72-evm: Remove pinmux configurations for erratum i869
>   ARM: dra72-evm: Fix modelling of regulators
>   ARM: dts: dra72: Add separate dtsi for tps65917
>   regulator: lp873x: Add support for populating input supply
>   ARM: OMAP2+: board-generic: add support for DRA71x family
>   ARM: omap2plus_defconfig: Enable REGULATOR_GPIO
>   ARM: omap2plus_defconfig: Enable LP873X support
> 
> Nishanth Menon (2):
>   ARM: DRA7: hwmod: Do not register RTC on DRA71
>   ARM: dts: Add support for dra718-evm
> 
>  .../devicetree/bindings/arm/omap/omap.txt          |   6 +
>  Documentation/devicetree/bindings/mfd/lp873x.txt   |   8 +
>  arch/arm/boot/dts/Makefile                         |   3 +-
>  arch/arm/boot/dts/dra71-evm.dts                    | 230 ++++++++++++++
>  arch/arm/boot/dts/dra72-evm-common.dtsi            | 348 +++------------------
>  arch/arm/boot/dts/dra72-evm-revc.dts               |  21 +-
>  arch/arm/boot/dts/dra72-evm-tps65917.dtsi          | 134 ++++++++
>  arch/arm/boot/dts/dra72-evm.dts                    |  14 +-
>  arch/arm/configs/omap2plus_defconfig               |   3 +
>  arch/arm/mach-omap2/board-generic.c                |   1 +
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c          |  10 +-
>  drivers/regulator/lp873x-regulator.c               |   1 +
>  12 files changed, 453 insertions(+), 326 deletions(-)
>  create mode 100644 arch/arm/boot/dts/dra71-evm.dts
>  create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> 

^ permalink raw reply

* [PATCH 1/4] ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
From: pankaj.dubey @ 2016-11-07  3:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161105154119.GA8183@kozik-lap>

Hi Krzysztof,

On Saturday 05 November 2016 09:11 PM, Krzysztof Kozlowski wrote:
> On Fri, Nov 04, 2016 at 09:09:21AM +0530, Pankaj Dubey wrote:
>> We can safely remove exynos_smp_init_cpus() hook from mach-exynos/platsmp.c,
>> as all SMP platforms in mach-exynos can rely on DT for CPU core description
>> instead of determining number of cores from the SCU.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>>  arch/arm/mach-exynos/platsmp.c | 31 -------------------------------
>>  1 file changed, 31 deletions(-)
>>
> 
> 
> Thanks, applied. Somehow your patchset did not reach linux-samsung-soc's
> Parchwork. I don't have a clue why... It is on linux-arm-kernel's
> Patchwork.
> 

Thanks for looking into this series.

I am also not sure why its not reflecting for you on linux-samsung-soc's
Patchwork, but I can see this series in linux-samsung-soc Patchwork at
below links:

[1/4]: https://patchwork.kernel.org/patch/9411787/
[2/4]: https://patchwork.kernel.org/patch/9411789/
[3/4]: https://patchwork.kernel.org/patch/9411791/
[4/4]: https://patchwork.kernel.org/patch/9411793/

Will you please review other two patches (3/4 and 4/4) in this series?

Thanks,
Pankaj Dubey

> Best regards,
> Krzysztof
> 
> 
> 
> 

^ permalink raw reply

* [PATCH RFC 3/7] spi: s3c64xx: Do not use platform_data for DMA parameters
From: Andi Shyti @ 2016-11-07  2:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478276094-19135-5-git-send-email-s.nawrocki@samsung.com>

Hi Sylwester,

> All related platforms use either devicetree or the DMA slave
> map API for mapping DMA channels to DMA slaves so we can now
> stop using platform_data for passing DMA details.
> 
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

Tested-by: Andi Shyti <andi.shyti@samsung.com>

Andi

^ permalink raw reply

* [3/4] ARM: EXYNOS: Remove static mapping of SCU SFR
From: pankaj.dubey @ 2016-11-07  2:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <581C8C8F.5080100@samsung.com>

Hi Alim,

On Friday 04 November 2016 06:56 PM, Alim Akhtar wrote:
> Hi Pankaj,
> 
> On 11/04/2016 09:09 AM, Pankaj Dubey wrote:
>> Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC
>> based boards.
>> Instead use mapping from device tree node of SCU.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>>   arch/arm/mach-exynos/exynos.c                | 22
>> ----------------------
>>   arch/arm/mach-exynos/include/mach/map.h      |  2 --
>>   arch/arm/mach-exynos/platsmp.c               | 18 +++++++++++-------
>>   arch/arm/mach-exynos/pm.c                    | 14 +++++++++++---
>>   arch/arm/mach-exynos/suspend.c               | 15 +++++++++++----
>>   arch/arm/plat-samsung/include/plat/map-s5p.h |  4 ----
>>   6 files changed, 33 insertions(+), 42 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c
>> b/arch/arm/mach-exynos/exynos.c
>> index 757fc11..fa08ef9 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -28,15 +28,6 @@
>>
>>   #include "common.h"
>>
>> -static struct map_desc exynos4_iodesc[] __initdata = {
>> -    {
>> -        .virtual    = (unsigned long)S5P_VA_COREPERI_BASE,
>> -        .pfn        = __phys_to_pfn(EXYNOS4_PA_COREPERI),
>> -        .length        = SZ_8K,
>> -        .type        = MT_DEVICE,
>> -    },
>> -};
>> -
>>   static struct platform_device exynos_cpuidle = {
>>       .name              = "exynos_cpuidle",
>>   #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
>> @@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned
>> long node, const char *uname,
>>       return 1;
>>   }
>>
>> -/*
>> - * exynos_map_io
>> - *
>> - * register the standard cpu IO areas
>> - */
>> -static void __init exynos_map_io(void)
>> -{
>> -    if (soc_is_exynos4())
>> -        iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
>> -}
>> -
>>   static void __init exynos_init_io(void)
>>   {
>>       debug_ll_io_init();
>> @@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
>>
>>       /* detect cpu id and rev. */
>>       s5p_init_cpu(S5P_VA_CHIPID);
>> -
>> -    exynos_map_io();
>>   }
>>
>>   /*
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
>> b/arch/arm/mach-exynos/include/mach/map.h
>> index 5fb0040..0eef407 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -18,6 +18,4 @@
>>
>>   #define EXYNOS_PA_CHIPID        0x10000000
>>
>> -#define EXYNOS4_PA_COREPERI        0x10500000
>> -
>>   #endif /* __ASM_ARCH_MAP_H */
>> diff --git a/arch/arm/mach-exynos/platsmp.c
>> b/arch/arm/mach-exynos/platsmp.c
>> index a5d6841..553d0d9 100644
>> --- a/arch/arm/mach-exynos/platsmp.c
>> +++ b/arch/arm/mach-exynos/platsmp.c
>> @@ -224,11 +224,6 @@ static void write_pen_release(int val)
>>       sync_cache_w(&pen_release);
>>   }
>>
>> -static void __iomem *scu_base_addr(void)
>> -{
>> -    return (void __iomem *)(S5P_VA_SCU);
>> -}
>> -
>>   static DEFINE_SPINLOCK(boot_lock);
>>
>>   static void exynos_secondary_init(unsigned int cpu)
>> @@ -387,14 +382,23 @@ fail:
>>
>>   static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
>>   {
>> +    struct device_node *np;
>> +    void __iomem *scu_base;
>>       int i;
>>
>>       exynos_sysram_init();
>>
>>       exynos_set_delayed_reset_assertion(true);
>>
>> -    if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
>> -        scu_enable(scu_base_addr());
>> +    if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
>> +        np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
> 
> what if of_find_compatible_node() fails? May be add a error check for
> the same?

Thanks for review.

You are right of_find_compatible_node() is bound to fail, but only in
case supplied compatible is missing in DT. In our case this piece of
code will execute only for Cortex-A9 based SoC (which in case of Exynos
SoC is applicable only for Exynos4 series) and we will for sure
providing "arm,cortex-a9-scu" in DT, so there is no chance of failure.
So I feel extra check on "np" for NULL will add no benefit here.


Thanks,
Pankaj Dubey

^ permalink raw reply

* [PATCH 1/2] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
From: Shawn Guo @ 2016-11-07  2:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <VI1PR04MB14556348390F18AF8D5A261D8BA70@VI1PR04MB1455.eurprd04.prod.outlook.com>

On Mon, Nov 07, 2016 at 01:32:29AM +0000, Peter Chen wrote:
>  
> >On Mon, Oct 31, 2016 at 10:58:28AM +0800, Peter Chen wrote:
> >> We need to change trimming value (as a percentage) of the 17.78mA TX
> >> reference current for better signal quality. With this change, we can
> >> patch the eye-diagram test on this board.
> >
> >s/patch/pass?  I just want to confirm this is a typo, and can fix it up when applying.
> >
> 
> Thanks, Shawn. It is a typo. Help me to change both of patches please.

Applied both, thanks.

^ permalink raw reply

* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Chen-Yu Tsai @ 2016-11-07  1:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161107012920.GA10559@b29397-desktop>

On Mon, Nov 7, 2016 at 9:29 AM, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote:
>> Quoting Peter Chen (2016-10-24 18:16:32)
>> > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
>> > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
>> > > > Hi,
>> > > >
>> > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
>> > > > > The ULPI bus can be built as a module, and it will soon be
>> > > > > calling these functions when it supports probing devices from DT.
>> > > > > Export them so they can be used by the ULPI module.
>> > > > >
>> > > > > Acked-by: Rob Herring <robh@kernel.org>
>> > > > > Cc: <devicetree@vger.kernel.org>
>> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
>> > > > > ---
>> > > > >  drivers/of/device.c | 2 ++
>> > > > >  1 file changed, 2 insertions(+)
>> > > > >
>> > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
>> > > > > index 8a22a253a830..6719ab35b62e 100644
>> > > > > --- a/drivers/of/device.c
>> > > > > +++ b/drivers/of/device.c
>> > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
>> > > > >
>> > > > >         return tsize;
>> > > > >  }
>> > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
>> > > > >
>> > > > >  int of_device_request_module(struct device *dev)
>> > > > >  {
>> > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
>> > > > >         }
>> > > > >         mutex_unlock(&of_mutex);
>> > > > >  }
>> > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
>> > > >
>> > > > This is trailing the wrong function.
>> > > >
>> > >
>> > > Good catch. Must have been some bad rebase.
>> > >
>> > > Peter, can you fix it while applying or should I resend this patch?
>> > >
>> >
>> > But, this is device tree patch. I can only get chipidea part and other
>> > USB patches if Greg agrees.
>> >
>>
>> Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
>> Rob acked them so they could go through usb with the other changes.
>
> I am just worried about possible merge error when linus pulls both OF
> and USB tree. Greg, is it ok the OF patches through USB tree with OF
> maintainer's ack?

May I suggest putting the OF patches on an immutable branch so other
subsystems can pull them in without pulling in the USB patches? At
least I want to use them in the I2C subsystem, and in the sunxi-rsb
driver.


Regards
ChenYu

^ permalink raw reply

* [PATCH v2 06/14] ASoC: sun4i-codec: Add support for A31 playback through headphone output
From: Chen-Yu Tsai @ 2016-11-07  1:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161106185715.tlvcakzqay2lamd5@lukather>

On Mon, Nov 7, 2016 at 2:57 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Nov 04, 2016 at 09:08:11AM +0800, Chen-Yu Tsai wrote:
>> On Fri, Nov 4, 2016 at 1:36 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > Hi,
>> >
>> > On Thu, Nov 03, 2016 at 03:55:48PM +0800, Chen-Yu Tsai wrote:
>> >> +/* headphone controls */
>> >> +static const char * const sun6i_codec_hp_src_enum_text[] = {
>> >> +     "DAC", "Mixer",
>> >> +};
>> >> +
>> >> +static SOC_ENUM_DOUBLE_DECL(sun6i_codec_hp_src_enum,
>> >> +                         SUN6I_CODEC_OM_DACA_CTRL,
>> >> +                         SUN6I_CODEC_OM_DACA_CTRL_LHPIS,
>> >> +                         SUN6I_CODEC_OM_DACA_CTRL_RHPIS,
>> >> +                         sun6i_codec_hp_src_enum_text);
>> >> +
>> >> +static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
>> >> +     SOC_DAPM_ENUM("Headphone Source Playback Route",
>> >> +                   sun6i_codec_hp_src_enum),
>> >> +};
>> >
>> > What is that route exactly? A muxer?
>>
>> Yup. The following is part of the widgets list later in the code:
>>
>> +       /* Headphone output path */
>> +       SND_SOC_DAPM_MUX("Headphone Source Playback Route",
>> +                        SND_SOC_NOPM, 0, 0, sun6i_codec_hp_src),
>
> Oh, right.
>
> You can add my Acked-by on this one and the other patches too.

Thanks. Mark already merged all the driver patches though.

ChenYu

^ permalink raw reply

* [PATCH] arm64: percpu: kill off final ACCESS_ONCE() uses
From: Dmitry Vyukov @ 2016-11-07  1:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478283426-6649-1-git-send-email-mark.rutland@arm.com>

On Fri, Nov 4, 2016 at 11:17 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> For several reasons it is preferable to use {READ,WRITE}_ONCE() rather than
> ACCESS_ONCE(). For example, these handle aggregate types, result in shorter
> source code, and better document the intended access (which may be useful for
> instrumentation features such as the upcoming KTSAN).
>
> Over a number of patches, most uses of ACCESS_ONCE() in arch/arm64 have been
> migrated to {READ,WRITE}_ONCE(). For consistency, and the above reasons, this
> patch migrates the final remaining uses.

Thanks!

Acked-by: Dmitry Vyukov <dvyukov@google.com>


> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm64/include/asm/percpu.h | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
> index 5394c84..4afb6fc 100644
> --- a/arch/arm64/include/asm/percpu.h
> +++ b/arch/arm64/include/asm/percpu.h
> @@ -101,16 +101,16 @@ static inline unsigned long __percpu_read(void *ptr, int size)
>
>         switch (size) {
>         case 1:
> -               ret = ACCESS_ONCE(*(u8 *)ptr);
> +               ret = READ_ONCE(*(u8 *)ptr);
>                 break;
>         case 2:
> -               ret = ACCESS_ONCE(*(u16 *)ptr);
> +               ret = READ_ONCE(*(u16 *)ptr);
>                 break;
>         case 4:
> -               ret = ACCESS_ONCE(*(u32 *)ptr);
> +               ret = READ_ONCE(*(u32 *)ptr);
>                 break;
>         case 8:
> -               ret = ACCESS_ONCE(*(u64 *)ptr);
> +               ret = READ_ONCE(*(u64 *)ptr);
>                 break;
>         default:
>                 BUILD_BUG();
> @@ -123,16 +123,16 @@ static inline void __percpu_write(void *ptr, unsigned long val, int size)
>  {
>         switch (size) {
>         case 1:
> -               ACCESS_ONCE(*(u8 *)ptr) = (u8)val;
> +               WRITE_ONCE(*(u8 *)ptr, (u8)val);
>                 break;
>         case 2:
> -               ACCESS_ONCE(*(u16 *)ptr) = (u16)val;
> +               WRITE_ONCE(*(u16 *)ptr, (u16)val);
>                 break;
>         case 4:
> -               ACCESS_ONCE(*(u32 *)ptr) = (u32)val;
> +               WRITE_ONCE(*(u32 *)ptr, (u32)val);
>                 break;
>         case 8:
> -               ACCESS_ONCE(*(u64 *)ptr) = (u64)val;
> +               WRITE_ONCE(*(u64 *)ptr, (u64)val);
>                 break;
>         default:
>                 BUILD_BUG();
> --
> 2.7.4
>

^ permalink raw reply

* [PATCH v4 0/3] Add initial ZTE VOU DRM/KMS driver
From: Shawn Guo @ 2016-11-07  1:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477905445-4983-1-git-send-email-shawnguo@kernel.org>

Hi David, Daniel,

On Mon, Oct 31, 2016 at 05:17:22PM +0800, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
> 
> The series adds the initial ZTE VOU display controller DRM/KMS driver.
> There are still some features to be added, like overlay plane, scaling,
> and more output devices support.  But it's already useful with dual
> CRTCs and HDMI display working.

After a few rounds of reviewing (thanks to all reviewers), it seems that
the series is ready for merging, I guess?  If so, could you suggest how
we proceed?  I can prepare a pull request if you like.  Thanks.

Shawn

> Changes for v4:
>  - Move the hardware setup done in zx_hdmi_hw_init() and clock enable
>    into .enable hook of drm_encoder_helper_funcs.
>  - Compare pipe to crtc->index instead of using our own index counter.
>  - Save the pipe check in zx_vou_enable[disable]_vblank by putting frame
>    interrupt bit into zx_crtc_bits.
>  - Use DRM_DEV_* for log messages instead of old dev_* functions
>  - Return directly in case of -ETIMEDOUT in zx_hdmi_i2c_read to simplify
>    the code for error condition.
>  - Shuffle things around to make the crtc and plane state check in
>    zx_gl_plane_atomic_check a bit clearer
>  - Move hardware register definitions into headers instead of disturbing
>    C file reading.
>  - Save the call to drm_connector_unregister(), so that
>    drm_connector_cleanup can directly be used as drm_connector_funcs
>    .destroy hook.
>  - Move vblank notification from .atomic_begin hook to .atomic_flush,
>    so that vblank event is sent to user space after planes are committed
>    rather than before.
> 
> Changes for v3:
>  - Rebase to v4.9-rc1
>  - Update bindings doc to use 'ranges' for address translation between
>    parent and child devices.
>  - Call drm_dev_register() last in bind function and drm_dev_unregister()
>    first in unbind, so that drm_connector_regiser() can be saved from
>    HDMI driver.
>  - Instead of using open-coded drm_do_get_edid(), add an I2C adapter for
>    HDMI DDC read and use drm_get_edid().
>  - Improve the plane .atomic_check implementation by calling helper
>    function drm_plane_helper_check_state().
>  - Rename zx_crtc.c to zx_vou.c to avoid the confusion that the file
>    implements crtc instance.
>  - Store vou pointer in zx_crtc, so that we do not need to embed the
>    pointer in zx_drm_private.
>  - Create zx_readl/zx_writel/zx_writel_mask for register access.
>  - Define a few macro helpers to ease the register bit setting, like
>    SYNC_WIDE, BACK_PORCH and FRONT_PORCH.
>  - Define main/aux channel specific register offset and bits in zx_crtc
>    to save the use of is_main check
>  - Sort include headers alphabetically
>  - Removing encoder pointer out of the structure and constify struct
>    vou_inf
>  - Add log message for error conditions
>  - Make the function calls in teardown path asymmetrical
>  - A few coding style improvements like defining macro for sub-module
>    address and changing code to save indentation level
>  - Add a MAINTAINERS entry for ZTE ZX DRM driver
> 
> Changes for v2:
>  - Change device tree bindings to kill the virtual display-subsystem
>    node make VOU the parent node.
> 
> Shawn Guo (3):
>   dt-bindings: add bindings doc for ZTE VOU display controller
>   drm: zte: add initial vou drm driver
>   MAINTAINERS: add an entry for ZTE ZX DRM driver
> 
>  .../devicetree/bindings/display/zte,vou.txt        |  84 +++
>  MAINTAINERS                                        |   7 +
>  drivers/gpu/drm/Kconfig                            |   2 +
>  drivers/gpu/drm/Makefile                           |   1 +
>  drivers/gpu/drm/zte/Kconfig                        |   8 +
>  drivers/gpu/drm/zte/Makefile                       |   7 +
>  drivers/gpu/drm/zte/zx_drm_drv.c                   | 267 +++++++++
>  drivers/gpu/drm/zte/zx_drm_drv.h                   |  36 ++
>  drivers/gpu/drm/zte/zx_hdmi.c                      | 624 +++++++++++++++++++
>  drivers/gpu/drm/zte/zx_hdmi_regs.h                 |  56 ++
>  drivers/gpu/drm/zte/zx_plane.c                     | 299 ++++++++++
>  drivers/gpu/drm/zte/zx_plane.h                     |  26 +
>  drivers/gpu/drm/zte/zx_plane_regs.h                |  91 +++
>  drivers/gpu/drm/zte/zx_vou.c                       | 661 +++++++++++++++++++++
>  drivers/gpu/drm/zte/zx_vou.h                       |  46 ++
>  drivers/gpu/drm/zte/zx_vou_regs.h                  | 157 +++++
>  16 files changed, 2372 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/zte,vou.txt
>  create mode 100644 drivers/gpu/drm/zte/Kconfig
>  create mode 100644 drivers/gpu/drm/zte/Makefile
>  create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.c
>  create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.h
>  create mode 100644 drivers/gpu/drm/zte/zx_hdmi.c
>  create mode 100644 drivers/gpu/drm/zte/zx_hdmi_regs.h
>  create mode 100644 drivers/gpu/drm/zte/zx_plane.c
>  create mode 100644 drivers/gpu/drm/zte/zx_plane.h
>  create mode 100644 drivers/gpu/drm/zte/zx_plane_regs.h
>  create mode 100644 drivers/gpu/drm/zte/zx_vou.c
>  create mode 100644 drivers/gpu/drm/zte/zx_vou.h
>  create mode 100644 drivers/gpu/drm/zte/zx_vou_regs.h
> 
> -- 
> 1.9.1
> 

^ permalink raw reply

* [PATCH 1/2] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
From: Peter Chen @ 2016-11-07  1:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161105083145.GF5597@dragon>

 
>On Mon, Oct 31, 2016 at 10:58:28AM +0800, Peter Chen wrote:
>> We need to change trimming value (as a percentage) of the 17.78mA TX
>> reference current for better signal quality. With this change, we can
>> patch the eye-diagram test on this board.
>
>s/patch/pass?  I just want to confirm this is a typo, and can fix it up when applying.
>

Thanks, Shawn. It is a typo. Help me to change both of patches please.

Peter

^ permalink raw reply

* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Peter Chen @ 2016-11-07  1:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <147829269430.21688.2345895151880009021@sboyd-linaro>

On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-24 18:16:32)
> > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
> > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> > > > Hi,
> > > > 
> > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > > > > The ULPI bus can be built as a module, and it will soon be
> > > > > calling these functions when it supports probing devices from DT.
> > > > > Export them so they can be used by the ULPI module.
> > > > >
> > > > > Acked-by: Rob Herring <robh@kernel.org>
> > > > > Cc: <devicetree@vger.kernel.org>
> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > > ---
> > > > >  drivers/of/device.c | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > > index 8a22a253a830..6719ab35b62e 100644
> > > > > --- a/drivers/of/device.c
> > > > > +++ b/drivers/of/device.c
> > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
> > > > >
> > > > >         return tsize;
> > > > >  }
> > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
> > > > >
> > > > >  int of_device_request_module(struct device *dev)
> > > > >  {
> > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > > >         }
> > > > >         mutex_unlock(&of_mutex);
> > > > >  }
> > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
> > > > 
> > > > This is trailing the wrong function.
> > > > 
> > > 
> > > Good catch. Must have been some bad rebase.
> > > 
> > > Peter, can you fix it while applying or should I resend this patch?
> > > 
> > 
> > But, this is device tree patch. I can only get chipidea part and other
> > USB patches if Greg agrees.
> > 
> 
> Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
> Rob acked them so they could go through usb with the other changes.

I am just worried about possible merge error when linus pulls both OF
and USB tree. Greg, is it ok the OF patches through USB tree with OF
maintainer's ack?

-- 

Best Regards,
Peter Chen

^ permalink raw reply

* [PATCH] drm/sun4i: Propagate error to the caller
From: Gustavo Padovan @ 2016-11-07  1:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161104061352.12596-1-christophe.jaillet@wanadoo.fr>

Hi Christophe,

2016-11-04 Christophe JAILLET <christophe.jaillet@wanadoo.fr>:

> If 'sun4i_layers_init()' returns an error, propagate it instead of
> returning -EINVAL unconditionally.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

Gustavo

^ permalink raw reply

* [PATCH 1/9] ARM: dts: imx1: Remove skeleton.dtsi
From: Shawn Guo @ 2016-11-07  1:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOMZO5CUyZF5wXBxvcsJWSLt1NVzejpH0bZKedJfx3TfBPB2vQ@mail.gmail.com>

On Sat, Nov 05, 2016 at 05:35:50PM -0200, Fabio Estevam wrote:
> Hi Shawn,
> 
> On Tue, Sep 6, 2016 at 12:53 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> > The inclusion of skeleton.dtsi causes the following build warning:
> >
> > Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
> >
> > Instead of fixing skeleton.dtsi, just add the top level definitions
> > for address-cells and size-cell and remove its inclusion.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> 
> Are you OK with this series?

Has the series cleaned up all i.MX dts files?  I do not like to see so
many patches doing such small cleanups.  Can we do it with 3 patches
maybe?

 - one for skeleton.dtsi cleanup
 - one for memory node
 - one for cpu node

Each one covers all i.MX dts files.

Shawn

^ permalink raw reply

* [PATCH 10/13] ARM: dts: exynos: replace to "max-frequecy" instead of "clock-freq-min-max"
From: Jaehoon Chung @ 2016-11-07  0:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161104150447.GA4829@kozik-lap>

On 11/05/2016 12:04 AM, Krzysztof Kozlowski wrote:
> On Fri, Nov 04, 2016 at 12:19:49PM +0100, Heiko Stuebner wrote:
>> Hi Jaehoon,
>>
>> Am Freitag, 4. November 2016, 19:21:30 CET schrieb Jaehoon Chung:
>>> On 11/04/2016 03:41 AM, Krzysztof Kozlowski wrote:
>>>> On Thu, Nov 03, 2016 at 03:21:32PM +0900, Jaehoon Chung wrote:
>>>>> In drivers/mmc/core/host.c, there is "max-frequency" property.
>>>>> It should be same behavior. So Use the "max-frequency" instead of
>>>>> "clock-freq-min-max".
>>>>>
>>>>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>>>>> ---
>>>>>
>>>>>  arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
>>>>>  arch/arm/boot/dts/exynos3250-artik5.dtsi     | 2 +-
>>>>>  arch/arm/boot/dts/exynos3250-monk.dts        | 2 +-
>>>>>  arch/arm/boot/dts/exynos3250-rinato.dts      | 2 +-
>>>>>  4 files changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> This looks totally independent to rest of patches so it can be applied
>>>> separately without any functional impact (except lack of minimum
>>>> frequency). Is that correct?
>>>
>>> You're right. I will split the patches. And will resend.
>>> Thanks!
>>
>> I think what Krzysztof was asking was just if he can simply pick up this patch 
>> alone, as it does not require any of the previous changes.
>>
>> Same is true for the Rockchip patches I guess, so we could just take them 
>> individually into samsung/rockchip dts branches.
> 
> Yes, I wanted to get exactly this information. I couldn't find it in
> cover letter.

In drivers/mmc/core/host.c, there already is "max-frequency" property.
It's same functionality with "clock-freq-min-max". 
Minimum clock value can be fixed to 100K. because MMC core will check clock value from 400K to 100K.
But max-frequency can be difference.
If we can use "max-frequency" property, we don't need to use "clock-freq-min-max" property anymore.
I will resend the deprecated property instead of removing "clock-freq-min-max".

If you want to pick this, it's possible to pick. Then i will resend the patches without dt patches.

Best Regards,
Jaehoon Chung


> 
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

^ permalink raw reply

* [PATCH v4 0/7] i2c: bcm2835: Bring in changes from downstream
From: Wolfram Sang @ 2016-11-07  0:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1475525174-28604-1-git-send-email-noralf@tronnes.org>

On Mon, Oct 03, 2016 at 10:06:07PM +0200, Noralf Tr?nnes wrote:

> This patchset tries to bring in the lessons learned in the downstream
> driver i2c-bcm2708. The downstream clock stretcing timeout patch has
> been left out since clock stretching is broken/unreliable on this
> controller, so no point in setting it.
> 
> Changes since version 3:
> - Add comment about I2C_C_CLEAR on error

Looks like some serious hacking to get around HW limitations. Thanks for
upporting it.

Applied to for-next.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/3c095562/attachment.sig>

^ permalink raw reply

* [PATCH 13/22] mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on error
From: Vladimir Zapolskiy @ 2016-11-07  0:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161106192743.00e401ec@bbrezillon>

Hi Boris,

On 11/06/2016 08:27 PM, Boris Brezillon wrote:
> On Fri,  4 Nov 2016 19:43:01 +0900
> Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
>
>> The nand_scan_ident/tail() returns an appropriate error value when
>> it fails.  Use it instead of the fixed error code -ENXIO.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> ---

[snip]

>> -	if (nand_scan_tail(mtd)) {
>> -		res = -ENXIO;
>> +	res = nand_scan_tail(mtd);
>
> You miss
>
> 	if (res)
>
> here.
>
> No need to resend, I'll fix it when applying the patches.
>
>>  		goto err_exit3;
>> -	}
>>

nice catch, thank you for noticing and fixing the overlooked bug!

--
With best wishes,
Vladimir

^ permalink raw reply

* [PATCH 4/4] fpga mgr: socfpga: Expose support for encrypted bitstreams
From: Moritz Fischer @ 2016-11-07  0:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-1-moritz.fischer@ettus.com>

Expose support for on the fly decryption of bitstreams.
This needs no additional work or configuration,
so just expose the new capability.

Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Alan Tull <atull@opensource.altera.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---

Alan,

can you please let me know if that works this way, or where to find
information on encrypted bitstreams? I have a CycloneV SoCFPGA to test
on ...

Cheers,

Moritz
---
 drivers/fpga/socfpga.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
index fd9760c..ab57ec0c 100644
--- a/drivers/fpga/socfpga.c
+++ b/drivers/fpga/socfpga.c
@@ -579,6 +579,7 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
 
 	fpga_mgr_cap_zero(&caps);
 	fpga_mgr_cap_set(FPGA_MGR_CAP_FULL_RECONF, caps);
+	fpga_mgr_cap_set(FPGA_MGR_CAP_DECRYPT, caps);
 
 	return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager",
 				 &socfpga_fpga_ops, caps, priv);
-- 
2.10.0

^ permalink raw reply related

* [PATCH 3/4] fpga mgr: zynq: Add support for encrypted bitstreams
From: Moritz Fischer @ 2016-11-07  0:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-1-moritz.fischer@ettus.com>

Add new flag FPGA_MGR_DECRYPT_BISTREAM as well as a matching
capability FPGA_MGR_CAP_DECRYPT to allow for on-the-fly
decryption of an encrypted bitstream.

If the system is not booted in secure mode AES & HMAC units
are disabled by the boot ROM, therefore the capability
is not available.

Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Alan Tull <atull@opensource.altera.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/fpga/fpga-mgr.c       |  7 +++++++
 drivers/fpga/zynq-fpga.c      | 21 +++++++++++++++++++--
 include/linux/fpga/fpga-mgr.h |  2 ++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index 98230b7..e4d08e1 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -61,6 +61,12 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
 		return -ENOTSUPP;
 	}
 
+	if (flags & FPGA_MGR_DECRYPT_BITSTREAM &&
+	    !fpga_mgr_has_cap(FPGA_MGR_CAP_DECRYPT, mgr->caps)) {
+		dev_err(dev, "Bitstream decryption not supported\n");
+		return -ENOTSUPP;
+	}
+
 	/*
 	 * Call the low level driver's write_init function.  This will do the
 	 * device-specific things to get the FPGA into the state where it is
@@ -170,6 +176,7 @@ static const char * const state_str[] = {
 static const char * const cap_str[] = {
 	[FPGA_MGR_CAP_FULL_RECONF] = "Full reconfiguration",
 	[FPGA_MGR_CAP_PARTIAL_RECONF] = "Partial reconfiguration",
+	[FPGA_MGR_CAP_DECRYPT] = "Decrypt bitstream on the fly",
 };
 
 static ssize_t name_show(struct device *dev,
diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index 1d37ff0..0aa4705 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -71,6 +71,10 @@
 #define CTRL_PCAP_PR_MASK		BIT(27)
 /* Enable PCAP */
 #define CTRL_PCAP_MODE_MASK		BIT(26)
+/* Needed to reduce clock rate for secure config */
+#define CTRL_PCAP_RATE_EN_MASK		BIT(25)
+/* System booted in secure mode */
+#define CTRL_SEC_EN_MASK		BIT(7)
 
 /* Miscellaneous Control Register bit definitions */
 /* Internal PCAP loopback */
@@ -252,12 +256,20 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
 
 	/* set configuration register with following options:
 	 * - enable PCAP interface
-	 * - set throughput for maximum speed
+	 * - set throughput for maximum speed (if we're not decrypting)
 	 * - set CPU in user mode
 	 */
 	ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
-	zynq_fpga_write(priv, CTRL_OFFSET,
+	if (flags & FPGA_MGR_DECRYPT_BITSTREAM) {
+		zynq_fpga_write(priv, CTRL_OFFSET,
+			(CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK |
+			 CTRL_PCAP_RATE_EN_MASK | ctrl));
+
+	} else {
+		ctrl &= ~CTRL_PCAP_RATE_EN_MASK;
+		zynq_fpga_write(priv, CTRL_OFFSET,
 			(CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK | ctrl));
+	}
 
 	/* check that we have room in the command queue */
 	status = zynq_fpga_read(priv, STATUS_OFFSET);
@@ -412,6 +424,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
 	struct resource *res;
 	fpga_mgr_cap_mask_t caps;
 	int err;
+	u32 tmp;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -466,6 +479,10 @@ static int zynq_fpga_probe(struct platform_device *pdev)
 	fpga_mgr_cap_set(FPGA_MGR_CAP_FULL_RECONF, caps);
 	fpga_mgr_cap_set(FPGA_MGR_CAP_PARTIAL_RECONF, caps);
 
+	/* only works if we booted in secure mode */
+	tmp = zynq_fpga_read(priv, CTRL_OFFSET);
+	if (tmp & CTRL_SEC_EN_MASK)
+		fpga_mgr_cap_set(FPGA_MGR_CAP_DECRYPT, caps);
 
 	err = fpga_mgr_register(dev, "Xilinx Zynq FPGA Manager",
 				&zynq_fpga_ops, caps, priv);
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index 9bb96a5..aabe258 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -68,10 +68,12 @@ enum fpga_mgr_states {
  */
 #define FPGA_MGR_PARTIAL_RECONFIG	BIT(0)
 #define FPGA_MGR_FULL_RECONFIG		BIT(1)
+#define FPGA_MGR_DECRYPT_BITSTREAM	BIT(2)
 
 enum fpga_mgr_capability {
 	FPGA_MGR_CAP_PARTIAL_RECONF,
 	FPGA_MGR_CAP_FULL_RECONF,
+	FPGA_MGR_CAP_DECRYPT,
 
 /* last capability type for creation of the capabilities mask */
 	FPGA_MGR_CAP_END,
-- 
2.10.0

^ permalink raw reply related

* [PATCH 2/4] fpga mgr: Expose FPGA capabilities to userland via sysfs
From: Moritz Fischer @ 2016-11-07  0:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-1-moritz.fischer@ettus.com>

Expose FPGA capabilities to userland via sysfs.

Add Documentation for currently supported capabilities
that get exported via sysfs.

Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Alan Tull <atull@opensource.altera.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 Documentation/ABI/testing/sysfs-class-fpga-manager | 16 ++++++++++++++++
 drivers/fpga/fpga-mgr.c                            | 20 ++++++++++++++++++++
 include/linux/fpga/fpga-mgr.h                      |  2 ++
 3 files changed, 38 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-fpga-manager b/Documentation/ABI/testing/sysfs-class-fpga-manager
index 23056c5..d9aee21 100644
--- a/Documentation/ABI/testing/sysfs-class-fpga-manager
+++ b/Documentation/ABI/testing/sysfs-class-fpga-manager
@@ -35,3 +35,19 @@ Description:	Read fpga manager state as a string.
 		* write complete	= Doing post programming steps
 		* write complete error	= Error while doing post programming
 		* operating		= FPGA is programmed and operating
+
+What: 		/sys/class/fpga_manager/fpga/capabilities
+Date:		November 2016
+KernelVersion:	4.9
+Contact:	Moritz Fischer <moritz.fischer@ettus.com>
+Description:	Read fpga manager capabilities as a string.
+		The intent is to provide userspace with information on what
+		operations the particular instance can execute.
+
+		Each line expresses a capability that is available on the
+		particular instance of an fpga manager.
+		Supported so far:
+
+		* Full reconfiguration
+		* Partial reconfiguration
+		* Decrypt bitstream on the fly
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index ed57c17..98230b7 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -167,6 +167,11 @@ static const char * const state_str[] = {
 	[FPGA_MGR_STATE_OPERATING] =		"operating",
 };
 
+static const char * const cap_str[] = {
+	[FPGA_MGR_CAP_FULL_RECONF] = "Full reconfiguration",
+	[FPGA_MGR_CAP_PARTIAL_RECONF] = "Partial reconfiguration",
+};
+
 static ssize_t name_show(struct device *dev,
 			 struct device_attribute *attr, char *buf)
 {
@@ -183,10 +188,25 @@ static ssize_t state_show(struct device *dev,
 	return sprintf(buf, "%s\n", state_str[mgr->state]);
 }
 
+static ssize_t capabilities_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	struct fpga_manager *mgr = to_fpga_manager(dev);
+	char *start = buf;
+	enum fpga_mgr_capability cap;
+
+	for_each_fpga_mgr_cap_mask(cap, mgr->caps)
+		buf += sprintf(buf, "%s\n", cap_str[cap]);
+
+	return buf - start;
+}
+
+static DEVICE_ATTR_RO(capabilities);
 static DEVICE_ATTR_RO(name);
 static DEVICE_ATTR_RO(state);
 
 static struct attribute *fpga_mgr_attrs[] = {
+	&dev_attr_capabilities.attr,
 	&dev_attr_name.attr,
 	&dev_attr_state.attr,
 	NULL,
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index e73429c..9bb96a5 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -108,6 +108,8 @@ static inline void __fpga_mgr_cap_set(enum fpga_mgr_capability cap,
 	set_bit(cap, mask->bits);
 }
 
+#define for_each_fpga_mgr_cap_mask(cap, mask) \
+	for_each_set_bit(cap, mask.bits, FPGA_MGR_CAP_END)
 
 /**
  * struct fpga_manager_ops - ops for low level fpga manager drivers
-- 
2.10.0

^ permalink raw reply related

* [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: Moritz Fischer @ 2016-11-07  0:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-1-moritz.fischer@ettus.com>

Add FPGA capabilities as a way to express the capabilities
of a given FPGA manager.

Removes code duplication by comparing the low-level driver's
capabilities at the framework level rather than having each driver
check for supported operations in the write_init() callback.

This allows for extending with additional capabilities, similar
to the the dmaengine framework's implementation.

Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Alan Tull <atull@opensource.altera.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---

Changes from RFC:
* in the RFC the caps weren't actually stored into the struct fpga_mgr

Note:

If people disagree on the typedef being a 'false positive' I can fix
that in a future rev of the patchset.

Thanks,

    Moritz

---
 drivers/fpga/fpga-mgr.c       | 15 ++++++++++++++
 drivers/fpga/socfpga.c        | 10 +++++-----
 drivers/fpga/zynq-fpga.c      |  7 ++++++-
 include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index 953dc91..ed57c17 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
 	struct device *dev = &mgr->dev;
 	int ret;
 
+	if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
+	    !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
+		dev_err(dev, "Partial reconfiguration not supported\n");
+		return -ENOTSUPP;
+	}
+
+	if (flags & FPGA_MGR_FULL_RECONFIG &&
+	    !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
+		dev_err(dev, "Full reconfiguration not supported\n");
+		return -ENOTSUPP;
+	}
+
 	/*
 	 * Call the low level driver's write_init function.  This will do the
 	 * device-specific things to get the FPGA into the state where it is
@@ -245,12 +257,14 @@ EXPORT_SYMBOL_GPL(fpga_mgr_put);
  * @dev:	fpga manager device from pdev
  * @name:	fpga manager name
  * @mops:	pointer to structure of fpga manager ops
+ * @caps:	fpga manager capabilities
  * @priv:	fpga manager private data
  *
  * Return: 0 on success, negative error code otherwise.
  */
 int fpga_mgr_register(struct device *dev, const char *name,
 		      const struct fpga_manager_ops *mops,
+		      fpga_mgr_cap_mask_t caps,
 		      void *priv)
 {
 	struct fpga_manager *mgr;
@@ -282,6 +296,7 @@ int fpga_mgr_register(struct device *dev, const char *name,
 	mgr->name = name;
 	mgr->mops = mops;
 	mgr->priv = priv;
+	mgr->caps = caps;
 
 	/*
 	 * Initialize framework state by requesting low level driver read state
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
index 27d2ff2..fd9760c 100644
--- a/drivers/fpga/socfpga.c
+++ b/drivers/fpga/socfpga.c
@@ -413,10 +413,6 @@ static int socfpga_fpga_ops_configure_init(struct fpga_manager *mgr, u32 flags,
 	struct socfpga_fpga_priv *priv = mgr->priv;
 	int ret;
 
-	if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
-		dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
-		return -EINVAL;
-	}
 	/* Steps 1 - 5: Reset the FPGA */
 	ret = socfpga_fpga_reset(mgr);
 	if (ret)
@@ -555,6 +551,7 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct socfpga_fpga_priv *priv;
 	struct resource *res;
+	fpga_mgr_cap_mask_t caps;
 	int ret;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -580,8 +577,11 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	fpga_mgr_cap_zero(&caps);
+	fpga_mgr_cap_set(FPGA_MGR_CAP_FULL_RECONF, caps);
+
 	return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager",
-				 &socfpga_fpga_ops, priv);
+				 &socfpga_fpga_ops, caps, priv);
 }
 
 static int socfpga_fpga_remove(struct platform_device *pdev)
diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index c2fb412..1d37ff0 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -410,6 +410,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct zynq_fpga_priv *priv;
 	struct resource *res;
+	fpga_mgr_cap_mask_t caps;
 	int err;
 
 	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -461,9 +462,13 @@ static int zynq_fpga_probe(struct platform_device *pdev)
 	zynq_fpga_write(priv, UNLOCK_OFFSET, UNLOCK_MASK);
 
 	clk_disable(priv->clk);
+	fpga_mgr_cap_zero(&caps);
+	fpga_mgr_cap_set(FPGA_MGR_CAP_FULL_RECONF, caps);
+	fpga_mgr_cap_set(FPGA_MGR_CAP_PARTIAL_RECONF, caps);
+
 
 	err = fpga_mgr_register(dev, "Xilinx Zynq FPGA Manager",
-				&zynq_fpga_ops, priv);
+				&zynq_fpga_ops, caps, priv);
 	if (err) {
 		dev_err(dev, "unable to register FPGA manager");
 		clk_unprepare(priv->clk);
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index 0940bf4..e73429c 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -67,6 +67,47 @@ enum fpga_mgr_states {
  * FPGA_MGR_PARTIAL_RECONFIG: do partial reconfiguration if supported
  */
 #define FPGA_MGR_PARTIAL_RECONFIG	BIT(0)
+#define FPGA_MGR_FULL_RECONFIG		BIT(1)
+
+enum fpga_mgr_capability {
+	FPGA_MGR_CAP_PARTIAL_RECONF,
+	FPGA_MGR_CAP_FULL_RECONF,
+
+/* last capability type for creation of the capabilities mask */
+	FPGA_MGR_CAP_END,
+};
+
+typedef struct { DECLARE_BITMAP(bits, FPGA_MGR_CAP_END); } fpga_mgr_cap_mask_t;
+
+#define fpga_mgr_has_cap(cap, mask) __fpga_mgr_has_cap((cap), &(mask))
+static inline int __fpga_mgr_has_cap(enum fpga_mgr_capability cap,
+				     fpga_mgr_cap_mask_t *mask)
+{
+	return test_bit(cap, mask->bits);
+}
+
+#define fpga_mgr_cap_zero(mask) __fpga_mgr_cap_zero(mask)
+static inline void __fpga_mgr_cap_zero(fpga_mgr_cap_mask_t *mask)
+{
+	bitmap_zero(mask->bits, FPGA_MGR_CAP_END);
+}
+
+#define fpga_mgr_cap_clear(cap, mask) __fpga_mgr_cap_clear((cap), &(mask))
+static inline void __fpga_mgr_cap_clear(enum fpga_mgr_capability cap,
+				       fpga_mgr_cap_mask_t *mask)
+
+{
+	clear_bit(cap, mask->bits);
+}
+
+#define fpga_mgr_cap_set(cap, mask) __fpga_mgr_cap_set((cap), &(mask))
+static inline void __fpga_mgr_cap_set(enum fpga_mgr_capability cap,
+				      fpga_mgr_cap_mask_t *mask)
+
+{
+	set_bit(cap, mask->bits);
+}
+
 
 /**
  * struct fpga_manager_ops - ops for low level fpga manager drivers
@@ -105,6 +146,7 @@ struct fpga_manager {
 	enum fpga_mgr_states state;
 	const struct fpga_manager_ops *mops;
 	void *priv;
+	fpga_mgr_cap_mask_t caps;
 };
 
 #define to_fpga_manager(d) container_of(d, struct fpga_manager, dev)
@@ -120,7 +162,9 @@ struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
 void fpga_mgr_put(struct fpga_manager *mgr);
 
 int fpga_mgr_register(struct device *dev, const char *name,
-		      const struct fpga_manager_ops *mops, void *priv);
+		      const struct fpga_manager_ops *mops,
+		      fpga_mgr_cap_mask_t caps,
+		      void *priv);
 
 void fpga_mgr_unregister(struct device *dev);
 
-- 
2.10.0

^ permalink raw reply related

* [PATCH 0/4] fpga mgr: Add support for capabilities & encrypted bistreams
From: Moritz Fischer @ 2016-11-07  0:13 UTC (permalink / raw)
  To: linux-arm-kernel

This patchset introduces FPGA capabilities, to model what operations
an FPGA Manager low level driver supports.
Exposing them via sysfs allows userland to make smart decisions which FPGA to deploy
an image to in case there are multiple FPGAs with different capabilities available.

As an example of a capability: Support for encrypted bitstreams to Zynq & SocFPGA.
Please note that [4/4] is separate as I couldn't find info on how encrypted bitstreams
work on socfpga platforms, however Alan mentioned during an offline discussion it should
'just work'.

On Zynq using the HMAC & AES units in the devcfg peripheral only work when the system
has been booted in Secure Mode, otherwise the boot rom will disable them.
The FPGA manager capability will only get exposed if available.

Thanks,

    Moritz

Moritz Fischer (4):
  fpga mgr: Introduce FPGA capabilities
  fpga mgr: Expose FPGA capabilities to userland via sysfs
  fpga mgr: zynq: Add support for encrypted bitstreams
  fpga mgr: socfpga: Expose support for encrypted bitstreams

 Documentation/ABI/testing/sysfs-class-fpga-manager | 16 +++++++
 drivers/fpga/fpga-mgr.c                            | 42 ++++++++++++++++++
 drivers/fpga/socfpga.c                             | 11 ++---
 drivers/fpga/zynq-fpga.c                           | 28 ++++++++++--
 include/linux/fpga/fpga-mgr.h                      | 50 +++++++++++++++++++++-
 5 files changed, 138 insertions(+), 9 deletions(-)

-- 
2.10.0

^ permalink raw reply

* [PATCH 00/22] mtd: nand: return error code of nand_scan(_ident,_tail) on error
From: Boris Brezillon @ 2016-11-06 22:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1478256190-7452-1-git-send-email-yamada.masahiro@socionext.com>

On Fri,  4 Nov 2016 19:42:48 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:

> nand_scan(), nand_scan_ident(), nand_scan_tail() return
> an appropriate negative value on error.
> 
> Most of drivers return the value from them on error,
> but some of them return the fixed error code -ENXIO
> (and a few return -ENODEV).
> 
> This series make those drivers return more precise error code.

Applied and fixed the bug I found in patch 13.

Thanks,

Boris

> 
> 
> Masahiro Yamada (22):
>   mtd: nand: ams-delta: return error code of nand_scan() on error
>   mtd: nand: cmx270: return error code of nand_scan() on error
>   mtd: nand: cs553x: return error code of nand_scan() on error
>   mtd: nand: gpio: return error code of nand_scan() on error
>   mtd: nand: mpc5121: return error code of nand_scan() on error
>   mtd: nand: tmio: return error code of nand_scan() on error
>   mtd: nand: orion: return error code of nand_scan() on error
>   mtd: nand: pasemi: return error code of nand_scan() on error
>   mtd: nand: plat_nand: return error code of nand_scan() on error
>   mtd: nand: atmel: return error code of nand_scan_ident/tail() on error
>   mtd: nand: brcmnand: return error code of nand_scan_ident/tail() on
>     error
>   mtd: nand: fsmc: return error code of nand_scan_ident/tail() on error
>   mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on
>     error
>   mtd: nand: mediatek: return error code of nand_scan_ident/tail() on
>     error
>   mtd: nand: mxc: return error code of nand_scan_ident/tail() on error
>   mtd: nand: omap2: return error code of nand_scan_ident/tail() on error
>   mtd: nand: vf610: return error code of nand_scan_ident/tail() on error
>   mtd: nand: cafe: return error code of nand_scan_ident() on error
>   mtd: nand: hisi504: return error code of nand_scan_ident() on error
>   mtd: nand: pxa3xx: return error code of nand_scan_ident() on error
>   mtd: nand: nandsim: remove unneeded checks for nand_scan_ident/tail()
>   mtd: nand: socrates: use nand_scan() for nand_scan_ident/tail() combo
> 
>  drivers/mtd/nand/ams-delta.c         |  5 ++---
>  drivers/mtd/nand/atmel_nand.c        | 10 ++++------
>  drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++++++----
>  drivers/mtd/nand/cafe_nand.c         |  5 ++---
>  drivers/mtd/nand/cmx270_nand.c       |  4 ++--
>  drivers/mtd/nand/cs553x_nand.c       |  5 ++---
>  drivers/mtd/nand/fsmc_nand.c         |  9 ++++-----
>  drivers/mtd/nand/gpio.c              |  5 ++---
>  drivers/mtd/nand/hisi504_nand.c      |  4 +---
>  drivers/mtd/nand/lpc32xx_mlc.c       | 10 ++++------
>  drivers/mtd/nand/lpc32xx_slc.c       |  9 +++------
>  drivers/mtd/nand/mpc5121_nfc.c       |  4 ++--
>  drivers/mtd/nand/mtk_nand.c          |  4 ++--
>  drivers/mtd/nand/mxc_nand.c          | 10 ++++------
>  drivers/mtd/nand/nandsim.c           |  4 ----
>  drivers/mtd/nand/omap2.c             |  9 ++++-----
>  drivers/mtd/nand/orion_nand.c        |  5 ++---
>  drivers/mtd/nand/pasemi_nand.c       |  5 ++---
>  drivers/mtd/nand/plat_nand.c         |  5 ++---
>  drivers/mtd/nand/pxa3xx_nand.c       |  5 +++--
>  drivers/mtd/nand/socrates_nand.c     | 12 ++----------
>  drivers/mtd/nand/tmio_nand.c         |  6 +++---
>  drivers/mtd/nand/vf610_nfc.c         | 10 ++++------
>  23 files changed, 62 insertions(+), 93 deletions(-)
> 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox