* [PATCH 1/2] pinctrl: stm32: remove dependency with interrupt controller
From: Linus Walleij @ 2016-10-23 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-2-git-send-email-alexandre.torgue@st.com>
On Thu, Oct 20, 2016 at 3:26 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch allows to probe stm32 pinctrl driver even if no interrupt
> controller is defined to manage gpio irqs.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] pinctrl: stm32: move gpio irqs binding to optional
From: Linus Walleij @ 2016-10-23 23:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-3-git-send-email-alexandre.torgue@st.com>
On Thu, Oct 20, 2016 at 3:26 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> stm32 pinctrl driver could be probed even if no interrupt controller
> is defined to manage gpio irqs. Entries related to gpio irq management
> are moved to optional.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 2/4] arm64: dts: add Allwinner A64 SoC .dtsi
From: André Przywara @ 2016-10-23 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb11a71c58cd85551d9d793437db1792abd5077c.1476986335.git-series.maxime.ripard@free-electrons.com>
On 20/10/16 19:00, Maxime Ripard wrote:
Hi Maxime,
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> [Maxime: Convert to CCU binding, drop the MMC support for now]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +-
> MAINTAINERS | 1 +-
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 263 +++++++++++++++++-
> 3 files changed, 265 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 3975d0a0e4c2..4d6467cc2aa2 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,4 +14,5 @@ using one of the following compatible strings:
> allwinner,sun8i-a83t
> allwinner,sun8i-h3
> allwinner,sun9i-a80
> + allwinner,sun50i-a64
> nextthing,gr8
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7e0064..86488e92655f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1019,6 +1019,7 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> N: sun[x456789]i
> F: arch/arm/boot/dts/ntc-gr8*
> +F: arch/arm64/boot/dts/allwinner/
>
> ARM/Allwinner SoC Clock Support
> M: Emilio L?pez <emilio@elopez.com.ar>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> new file mode 100644
> index 000000000000..be51024743b4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -0,0 +1,263 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + * Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/clock/sun50i-a64-ccu.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +#include <dt-bindings/reset/sun50i-a64-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu at 0 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + };
> +
> + cpu1: cpu at 1 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + };
> +
> + cpu2: cpu at 2 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + };
> +
> + cpu3: cpu at 3 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + };
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + ccu: clock at 01c20000 {
> + compatible = "allwinner,sun50i-a64-ccu";
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + pio: pinctrl at 1c20800 {
> + compatible = "allwinner,sun50i-a64-pinctrl";
> + reg = <0x01c20800 0x400>;
> + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_PIO>;
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + i2c1_pins: i2c1_pins {
> + allwinner,pins = "PH2", "PH3";
> + allwinner,function = "i2c1";
So as Icenowy pointed out, we are missing the drive and pull properties
here, at least as long as we don't have your patch (series) in place to
cope with that.
But if we rely on this series (which seems OK to me), shouldn't we then
use the generic properties for pins and function here as well?
Cheers,
Andre.
> + };
> +
> + uart0_pins_a: uart0 at 0 {
> + allwinner,pins = "PB8", "PB9";
> + allwinner,function = "uart0";
> + };
> + };
> +
> + uart0: serial at 1c28000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28000 0x400>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + uart1: serial at 1c28400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28400 0x400>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART1>;
> + resets = <&ccu RST_BUS_UART1>;
> + status = "disabled";
> + };
> +
> + uart2: serial at 1c28800 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28800 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART2>;
> + resets = <&ccu RST_BUS_UART2>;
> + status = "disabled";
> + };
> +
> + uart3: serial at 1c28c00 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28c00 0x400>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART3>;
> + resets = <&ccu RST_BUS_UART3>;
> + status = "disabled";
> + };
> +
> + uart4: serial at 1c29000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c29000 0x400>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART4>;
> + resets = <&ccu RST_BUS_UART4>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c at 1c2ac00 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2ac00 0x400>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C0>;
> + resets = <&ccu RST_BUS_I2C0>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c at 1c2b000 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b000 0x400>;
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C1>;
> + resets = <&ccu RST_BUS_I2C1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c at 1c2b400 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b400 0x400>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C2>;
> + resets = <&ccu RST_BUS_I2C2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + gic: interrupt-controller at 1c81000 {
> + compatible = "arm,gic-400";
> + reg = <0x01c81000 0x1000>,
> + <0x01c82000 0x2000>,
> + <0x01c84000 0x2000>,
> + <0x01c86000 0x2000>;
> + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + };
> +
> + rtc: rtc at 1f00000 {
> + compatible = "allwinner,sun6i-a31-rtc";
> + reg = <0x01f00000 0x54>;
> + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH v3 2/6] pinctrl: sunxi: Support generic binding
From: Linus Walleij @ 2016-10-24 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <519ec867509f8033d9235a61f7979bd698906ab5.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Our bindings are mostly irrelevant now that we have generic pinctrl
> bindings that cover exactly the same uses cases.
>
> Add support for the new ones, and obviously keep our old binding support in
> order to keep the ABI stable.
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 3/6] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Linus Walleij @ 2016-10-24 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6aec73cd3b9d3dbf1085d042ec6c23f385a300de.1476971126.git-series.maxime.ripard@free-electrons.com>
On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The generic pin configuration and multiplexing should be preferred now,
> even though we still support the old one.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Linus Walleij @ 2016-10-24 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPoCmYKrUBEdyNXt8yRMFq_aCmb8WyK-x4a7og66zfeFYX4rQg@mail.gmail.com>
On Thu, Oct 20, 2016 at 6:58 PM, Gottfried Haider
<gottfried.haider@gmail.com> wrote:
> Somewhat off topic: is it planned to add
> support for setting GENERIC_PINCONF style pull-up/pull-down resistors
> throigh the new ABI?
Not planned, as in "I will do the job" but anticipated.
I expect that someone will come up with that usecase (indeed even the
Arduino is doing it) so that we will have to support it.
It's better than inventing a separate userspace ABI for pin control
anyways.
> (The bcm28xx drivers would still need to
> converted to this as well.)
All drivers that want to support it need converting I suspect.
>>> Regarding the proposed format using the header pin numbers: From what I've
>>> seen in terms of existing educational materials, it seems the overwhelming
>>> majority ends up using GPIO numbers instead of physical pin header
>>> numbering. (e.g. [1] [2])
>>
>> What does that number mean? If you are referring to the global
>> GPIO numberspace it is obsolete and just reflecting the fact that
>> people up until now was referring to Linux-internal GPIO numbers.
>
> I am referring to the name of the various GPIO lines as per datasheet
> ("GPIO0", "GPIO1", ...). So far, I believe those matched the global
> GPIO numberspace.
Aha. Yeah that is matching somewhat by chance these days, because:
static struct gpio_chip bcm2835_gpio_chip = {
.label = MODULE_NAME,
(...)
.base = -1,
(...)
};
That means this number is dynamicallly assigned and depend on
things like probe order or another GPIO chip failing etc.
> I understand that Linux can't guarantee a certain global GPIO number -
> but I fear that the board manufacturers also might not think of the
> pin headers as something set in stone (that the can't rearrange in a
> future revision/product).
Depends on which manufacturer. For 96boards there exist a document
specifying how they should be arranged and named:
https://github.com/96boards/documentation
Rpi would be wise to come up with something similar, but I have no
high hopes. We do need standardization and interoperability, but
it is not creating itself. :/
> Would there be a reason against _naming_ the pin "GPIO0"? (even if it
> ends up with a different global, internal number)
No not if it makes electronic sense, like if the schematic or SoC
uses that name, then use that if the board maintainer likes the idea.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH -next] ARM: mediatek: add terminate entry for of_device_id tables
From: weiyongjun (A) @ 2016-10-24 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477222977-1336-1-git-send-email-weiyj.lk@gmail.com>
> -----Original Message-----
> From: Wei Yongjun [mailto:weiyj.lk at gmail.com]
> Sent: Sunday, October 23, 2016 7:43 PM
> To: Matthias Brugger <matthias.bgg@gmail.com>; Russell King
> <linux@armlinux.org.uk>
> Cc: weiyongjun (A) <weiyongjun1@huawei.com>; linux-arm-
> kernel at lists.infradead.org; linux-mediatek at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: [PATCH -next] ARM: mediatek: add terminate entry for
> of_device_id tables
>
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Make sure of_device_id tables are NULL terminated.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> arch/arm/mach-mediatek/platsmp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
Sorry, this patch is not correct since mtk_tz_smp_boot_infos is used
as ARRAY_SIZE(mtk_tz_smp_boot_infos), please ignore it.
Regards,
Yongjun Wei
^ permalink raw reply
* [PATCH 5/8] pinctrl: aspeed: Enable capture of off-SCU pinmux state
From: Andrew Jeffery @ 2016-10-24 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdazJzE=Oa-0-FEYTvUk=-kPLojHY3afZKX5cpmzrUZHGQ@mail.gmail.com>
On Mon, 2016-10-24 at 00:20 +0200, Linus Walleij wrote:
> On Thu, Sep 29, 2016 at 8:45 AM, Joel Stanley <joel@jms.id.au> wrote:
> >
> > On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> >
> > >
> > > On the AST2400 and AST2500 a number of pins depend on state in one of
> > > the SIO, LPC or GFX IP blocks, so add support to at least capture what
> > > that state is. The pinctrl engine for the Aspeed SoCs doesn't try to
> > > inspect or modify the state of the off-SCU IP blocks. Instead, it logs
> > > the state requirement with the expectation that the platform
> > > designer/maintainer arranges for the appropriate configuration to be
> > > applied through the associated drivers.
> (...)
> >
> >
> > This is unfortunate.
> >
> > This patch kicks the can down the road, but doesn't solve the problem
> > for a user who wants to configure some functionality that depends on
> > the non-SCU bits. Because of this I'm not sure if we want to put it in
> > the tree.
> >
> > However, I'm not sure what a proper solution would look like. Perhaps
> > Linus can point out another SoC that has a similar problem?
> If I could only understand it.
>
> Don't you actually want to go and read a few registers on another
> IO range?
Yes. I guess the hesitation was whether we should also write those
registers so we can apply the requested function.
>
> What we generally do when pin control is spread out in a system is try
> to consolidate it, meaning expose the necessary registers on the remote
> end using syscon (drivers/mfd/syscon) so that we can easily get a handle
> on these registers withe regmap MMIO.
>
> Since regmap handles atomic access to the registers, that way we
> protect from disasters and keep the state in the hardware.
This seems like the reasonable approach if we want to read/write those
registers. The affected IO ranges correspond to:
* SuperIO Controller (SIO)
* SOC Display Controller (GFX)
* LPC Controller (LPC)
SIO and LPC both perform a mishmash of functions and so likely would
use the mfd subsystem anyway. I don't yet have any arguments against
doing it for the GFX IO space. Joel?
>
> I don't know if this is helpful. For a normal peripheral you may not want
> to put a regmap over all its registers but you prefer to ioremap it, and then
> we get the spaghetti of accessor functions to peek and poke into another
> peripherals I/O space, and that is undesireable.
I briefly experimented with the idea of accessing the other IO spaces
but it felt dirty precisely for what would have become accessor
spaghetti. So I wound up with the lame approach in this patch, which
just punts on the problem. I think the mfd/syscon approach would work
well though.
It looks like the rockchip pinctrl bindings are doing something along
the lines of what we need with the rockchip,pmu phandle property. Is it
acceptable to create three properties, a phandle to grab each regmap
for the IO spaces above?
>
> Maybe this is completely not understanding what you want to do, so
> sorry, please elaborate.
No, seems you have understood what we need to do.
> I am afraid the two of you are the only people on
> the planet who actually understand what is going on here.
>
> Also the hardware engineer who wrote the Aspeed pin controller, I would
> like to read this persons design specification, I am pretty sure it is very
> interesting.
Well, presumably this engineer knows too :) And yes, I'd like to know
what constraints existed that forced this design as a solution. I'd
like my sanity back.
>
> >
> > >
> > > -??* @reg: The register offset from base in bytes
> > > +??* @reg: Split into three fields:
> > > +??*???????31:24: IP selector
> > > +??*???????23:12: Reserved
> > > +??*???????11:0: Register offset
> That seems like unnecessary shoehorning. Is it reflecting the register layout
> of the hardware or are you trying to save bits? For the latter, let it
> go and instead
> have one member for offset and one member for selector.
It doesn't represent the register layout. But saving bits also wasn't
the motivation, more avoiding a lot of code churn in the g4/g5 drivers
to populate a new member. Maybe that's a bad motivation. I'll have more
of a think about it.
Thanks for the feedback,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/93d37a58/attachment.sig>
^ permalink raw reply
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Andrew Jeffery @ 2016-10-24 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYZPcjGuRKVL6qwof1p7ZXT4EvwzAuz59oTgp9Z5Dzixw@mail.gmail.com>
On Mon, 2016-10-24 at 00:09 +0200, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 2:33 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
> >
> > >
> > > Patch applied for v4.10.
> > > (Tell me if I'm applying patches in wrong order or something, and
> > > I hope this doesn't clash with the fixes.)
> > Both this patch and 8/8 functionally depend on 5/8. I fetched the
> > pinctrl tree to poke around but this patch didn't appear in any of the
> > updated branches, so I'm not sure whether we have the right ordering.
> > Without it we should hit build failures from missing macro definitions.
> >
> > Have you had a chance to look over patch 5/8? Joel wasn't keen on its
> > current form, so I would appreciate your input.
> Oops backed this patch out.
>
> Will look at 5/8.
>
> Appreciate if you repost the remaining patches in the series based on
> v4.9-rc2 once it's out, and I'll rebase the pinctrl tree onto that.
>
Will do!
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161024/f42ae859/attachment-0001.sig>
^ permalink raw reply
* [BUG] LPC32xx gpio driver broken by commit 762c2e46 in 4.9-rc1
From: Linus Walleij @ 2016-10-24 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476807799.10214.25.camel@localhost>
On Tue, Oct 18, 2016 at 6:23 PM, Sylvain Lemieux
<slemieux.tyco@gmail.com> wrote:
> the current LPC32xx GPIO driver is broken by commit 762c2e46
> (gpio: of: remove of_gpiochip_and_xlate() and struct gg_data).
>
> A call to "of_get_named_gpio" to retrieve the GPIO will
> always return -EINVAL, except for the first GPIO bank.
>
> Prior to this commit, the driver was working properly
> because of the side-effect of the match function called by
> "gpiochip_find" inside "of_get_named_gpiod_flags" function.
(...)
> Is there any short-term solution that can be done with
> the existing driver to keep the LPC32xx platform working
> properly in the 4.9 mainline kernel?
Masahiro, what do you think is the best course to proceed here?
Can we
- Restore the behaviour prior to the patches or
- Fix up all users or
- Do we have to revert these two patches?
I would prefer not to revert, because I liked the cleanup a lot ...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] gpio: mxs: use enable/disable regs to (un)mask irqs
From: Linus Walleij @ 2016-10-24 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-2-s.hauer@pengutronix.de>
On Fri, Oct 21, 2016 at 3:11 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> The mxs gpio controller does not only have a mask register to mask
> interrupts, but also enable/disable registers. Use the enable/disable
> registers rather than the mask register. This does not have any
> advantage for now, but makes the next patch simpler.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Patch applied with Marek's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] gpio: mxs: fix duplicate level interrupts
From: Linus Walleij @ 2016-10-24 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021131138.10467-3-s.hauer@pengutronix.de>
On Fri, Oct 21, 2016 at 3:11 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> According to the reference manual level interrupts can't be acked
> using the IRQSTAT registers. The effect is that when a level interrupt
> triggers the following ack is a no-op and the same interrupt triggers
> again right after it has been unmasked after running the interrupt
> handler.
>
> The reference manual says:
>
> Status bits for pins configured as level sensitive interrupts cannot be
> cleared unless either the actual pin is in the non-interrupting state, or
> the pin has been disabled as an interrupt source by clearing its bit in
> HW_PINCTRL_PIN2IRQ.
>
> To work around the duplicated interrupts we can use the PIN2IRQ
> rather than the IRQEN registers to mask the interrupts. This
> probably does not work for the edge interrupts, so we have to split up
> the irq chip into two chip types, one for the level interrupts and
> one for the edge interrupts. We now make use of two different enable
> registers, so we have to take care to always enable the right one,
> especially during switching of the interrupt type. An easy way
> to accomplish this is to use the IRQCHIP_SET_TYPE_MASKED which
> makes sure that set_irq_type is called with masked interrupts. With this
> the flow to change the irq type is like:
>
> - core masks interrupt (using the current chip type)
> - mxs_gpio_set_irq_type() changes chip type if necessary
> - mxs_gpio_set_irq_type() unconditionally sets the enable bit in the
> now unused enable register
> - core eventually unmasks the interrupt (using the new chip type)
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Patch applied with Marek's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Linus Walleij @ 2016-10-24 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-2-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Looks good to me. Tell me when I may apply it, it looks orthogonal
to the rest of the patches.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/6] arm64: dts: lg1312: DT fix s/#interrupts-cells/#interrupt-cells/
From: Chanho Min @ 2016-10-24 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039877-20227-3-git-send-email-geert+renesas@glider.be>
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> - Add Acked-by,
> - Rebased.
> ---
Acked-by: Chanho Min <chanho.min@lge.com>
^ permalink raw reply
* [PATCH v2 3/6] arm64: dts: lg1313: DT fix s/#interrupts-cells/#interrupt-cells/
From: Chanho Min @ 2016-10-24 2:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039877-20227-4-git-send-email-geert+renesas@glider.be>
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - New.
> ---
Acked-by: Chanho Min <chanho.min@lge.com>
^ permalink raw reply
* [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy
From: Peter Chen @ 2016-10-24 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147707842313.25848.12479294741874867656@sboyd-linaro>
On Fri, Oct 21, 2016 at 12:33:43PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-20 19:20:30)
> > On Thu, Oct 20, 2016 at 04:20:38PM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-10-17 18:56:36)
> > > > +
> > > > +static int
> > > > +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> > > > + void *ptr)
> > > > +{
> > > > + struct qcom_usb_hs_phy *uphy;
> > > > + int is_host;
> > > > + u8 addr;
> > > > +
> > > > + uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> > > > + is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
> > >
> > > Please don't apply this patch. This call now deadlocks on v4.9-rc1
> > > because of how extcon_get_cable_state_() now grabs a lock that is
> > > already held here when we're inside the notifier. It's not really
> > > required that we grab the lock in extcon there, but this has exposed a
> > > flaw in the logic anyway. We don't know if the id pin is going to toggle
> > > before or after this function is called, so we should really keep track
> > > of both vbus and id state in this driver and then do the same ulpi
> > > writes from two different notifiers for both vbus and id pin. We would
> > > be duplicating work sometimes, but that's pretty much the best solution
> > > I can come up with. Otherwise it's racy.
> > >
> >
> > Why you need to care id status? If EXTCON_USB event has happened, and
> > event is true, you can set, otherwise, it is clear operation, that's
> > to say you may not need have id extcon phandle, do you think so?
> >
>
> I need to add a comment to the code here because I forgot what was going
> on.
>
> Either way, this code is pulling D+ up when we're in device mode. We
> don't want to do the pullup if we're a host, and vbus extcon only tells
> us if the cable is attached so we can't just rely on that one bit of
> information.
>
> I suppose that's not really appropriate to do via extcon though in the
> phy driver though, so I'm thinking that it should be rewritten to use
> the phy_set_mode() feature of the phy framework. Basically,
> ci_udc_pullup() will call phy_set_mode() with PHY_MODE_USB_DEVICE or
> PHY_MODE_USB_HOST and then we can set or clear these bits in the ulpi
> register space. I think that will make things simpler here and things
> like soft-connect will work better. Sound good?
I agree with you, and you may notify controller role through
phy_set_mode at the controller probe and role switch routine.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: Sinan Kaya @ 2016-10-24 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vd+u5va3kyqcapeF9JATUfv5gBnoEM_W+frDmMXs5f2Uw@mail.gmail.com>
On 10/21/2016 12:11 PM, Andy Shevchenko wrote:
>> +static void hidma_free_msis(struct hidma_dev *dmadev)
>> > +{
>> > +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
> Perhaps one #ifdef and two definitions of functions?
I don't think it will make a difference. I'll have to move
#ifdef around the caller of hidma_free_msis instead which
I think is uglier.
The hidma_write_msi_msg function gets called only when
CONFIG_GENERIC_MSI_IRQ_DOMAIN is defined. If I don't put
this around the function definition, I get unused function
warning from the compiler. This is the reason why preprocessor
definition is outside of the function definition.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V4 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Sinan Kaya @ 2016-10-24 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021013930.GB31044@localhost>
On 10/20/2016 9:39 PM, Bjorn Helgaas wrote:
>> These API need to bypass the acpi_irq_get_penalty function.
> I don't mind this patch, but the changelog doesn't tell me what's
> broken and why we need this fix. Apparently acpi_irq_get_penalty()
> doesn't work before ACPI is initialized, but I don't see *why* it
> wouldn't work.
I'll update the commit message as you suggested. The code doesn't work
if we apply PATCH V4 2/3 + PATCH V4 3/3 without PATCH V4 1/3 since
the caller is going to end up calling get_penalty function while ACPI
is not initialized. This happened during the debug of this regression.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v5 3/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
From: Tiffany Lin @ 2016-10-24 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021110104.5733240e@vento.lan>
Hi Mauro,
On Fri, 2016-10-21 at 11:01 -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 2 Sep 2016 20:19:54 +0800
> Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
>
> > Add v4l2 layer decoder driver for MT8173
> >
> > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
>
> > +int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> > +{
> > + int ret = 0;
> > +
> > + switch (fourcc) {
> > + case V4L2_PIX_FMT_H264:
> > + case V4L2_PIX_FMT_VP8:
> > + default:
> > + return -EINVAL;
> > + }
>
> Did you ever test this driver? The above code will *always* return
> -EINVAL, with will cause vidioc_vdec_s_fmt() to always fail!
>
> I suspect that what you wanted to do, instead, is:
>
> switch (fourcc) {
> case V4L2_PIX_FMT_H264:
> case V4L2_PIX_FMT_VP8:
> break;
> default:
> return -EINVAL;
>
The original idea here is that vp8 and h264 are added in later patches.
If get this patch without later patches, it should return -EINVAL.
> Btw, this patch series has also several issues that were pointed by
> checkpatch. Please *always* run checkpatch when submitting your work.
>
> You should take a look at the Kernel documentation about how to
> submit patches, at:
> https://mchehab.fedorapeople.org/kernel_docs/process/index.html
>
> PS.: this time, I fixed the checkpatch issues for you. So, let me know
> if the patch below is OK, and I'll merge it at media upstream,
> assuming that the other patches in this series are ok.
>
I did run checkpatch, but I don't know why these issues missed.
probably I run checkpatch for all files not for patches.
I will take a look at the documentation and keep this in mind for future
upstream.
Appreciated for your help.
best regards,
Tiffany
^ permalink raw reply
* [PATCH v2 4/4] cpufreq: pxa: convert to clock API
From: Viresh Kumar @ 2016-10-24 3:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877f902hh6.fsf@belgarion.home>
On 22-10-16, 23:37, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > On 15-10-16, 21:57, Robert Jarzmik wrote:
> >> As the clock settings have been introduced into the clock pxa drivers,
> >> which are now available to change the CPU clock by themselves, remove
> >> the clock handling from this driver, and rely on pxa clock drivers.
> >>
> >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >> ---
> >> Since v1: added !OF Kconfig dependency
> >> ---
> >> drivers/cpufreq/Kconfig.arm | 2 +-
> >> drivers/cpufreq/pxa2xx-cpufreq.c | 191 ++++++++-------------------------------
> >> 2 files changed, 40 insertions(+), 153 deletions(-)
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Okay, after some more testing, I'd like to remove the !OF for next iteration.
> The reason is that I have a usecase where I have a single kernel image with
> devictree support (ie CONFIG_OF=y), but with support for both devicetree and
> legacy platforms. In this case, a platform such as lubbock can boot :
> - with devicetree
> - with legacy arch/arm/mach-pxa/lubbock.c
>
> In this kernel, the !OF Kconfig prevents the legacy version from working, as
> pxa2xx-cpufreq is descarded even if it is needed in the legacy version.
>
> Therefore, I'd like to respin without this !OF.
I imagined this case last week as well :)
No issues.
--
viresh
^ permalink raw reply
* [PATCH] arm64: dts: hip06: Fix no reg property warning
From: Kefeng Wang @ 2016-10-24 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474708465-38958-2-git-send-email-wangkefeng.wang@huawei.com>
Warning (unit_address_vs_reg): Node /soc/ethernet at 4 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/ethernet at 5 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/ethernet at 0 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/ethernet at 1 has a unit name, but no reg property
Fix warning when build with W=1.
Cc: Kejian Yan <yankejian@huawei.com>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index b548763..f66c51b 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -508,7 +508,7 @@
};
};
- eth0: ethernet at 4{
+ eth0: ethernet-4{
compatible = "hisilicon,hns-nic-v2";
ae-handle = <&dsaf0>;
port-idx-in-ae = <4>;
@@ -517,7 +517,7 @@
dma-coherent;
};
- eth1: ethernet at 5{
+ eth1: ethernet-5{
compatible = "hisilicon,hns-nic-v2";
ae-handle = <&dsaf0>;
port-idx-in-ae = <5>;
@@ -526,7 +526,7 @@
dma-coherent;
};
- eth2: ethernet at 0{
+ eth2: ethernet-0{
compatible = "hisilicon,hns-nic-v2";
ae-handle = <&dsaf0>;
port-idx-in-ae = <0>;
@@ -535,7 +535,7 @@
dma-coherent;
};
- eth3: ethernet at 1{
+ eth3: ethernet-1{
compatible = "hisilicon,hns-nic-v2";
ae-handle = <&dsaf0>;
port-idx-in-ae = <1>;
--
1.7.12.4
^ permalink raw reply related
* [PATCH V4 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Sinan Kaya @ 2016-10-24 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0jm-n8hbS_GFUY4EVKHiRaNPrkNcWDY+6c3SRxWhy4VAg@mail.gmail.com>
On 10/20/2016 5:39 PM, Rafael J. Wysocki wrote:
>> @@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
>> > void acpi_penalize_isa_irq(int irq, int active)
>> > {
>> > if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
>> > - acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
>> > + acpi_isa_irq_penalty[irq] = acpi_isa_irq_penalty[irq] +
> This looks slightly odd. What about
>
> + acpi_isa_irq_penalty[irq] +=
>
>> > (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
>> > }
Makes sense.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Sinan Kaya @ 2016-10-24 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a824792-486a-6251-4931-c5cc6fd67978@codeaurora.org>
On 10/21/2016 12:13 PM, Sinan Kaya wrote:
>> Wait a minute, I still have a question here: what about other ACPI
>> > arches (ia64, arm64)? Don't they need to call acpi_penalize_sci_irq()
>> > somewhere?
>> >
> ACPI ARM64 architecture implements reduced ACPI profile which doesn't
> have GED object.
I actually wanted to mean that ARM64 architecture doesn't have *GPE* object
implemented on ACPI reduced profile.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Sinan Kaya @ 2016-10-24 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021015814.GC31044@localhost>
On 10/20/2016 9:58 PM, Bjorn Helgaas wrote:
> I like this patch fine, except for the changelog. I don't think it's
> useful to describe this as a revert and give all the historical
> details. I think the important part is something like this:
>
> We previously used irq_get_trigger_type(irq) to help compute the
> penalty for the SCI, but that depends on the SCI having been
> registered already. Add acpi_penalize_sci_irq() so platforms can
> tell us the SCI IRQ, trigger, and polarity so we can compute the
> penalty even before the SCI has been registered.
OK, will replace with this and also change the commit summary as
"ACPI,PCI,IRQ: save SCI IRQ details for runtime penalty calculation"
>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
>> > Link: https://lkml.org/lkml/2016/10/4/283
>> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> > Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
>> > Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")
> "commit" is redundant; it's sufficient to say:
OK. I have been fighting with checkpatch. Checkpatch doesn't like a commit
summary without "commit 12 char SHA"
>
> Fixes: 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
>
> In fact, I don't think you really need to include "commit" in the
> reference to 9e5ed6d1fb87 above either.
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* FW: [PATCH] mtk-vcodec: fix some smatch warnings
From: Tiffany Lin @ 2016-10-24 3:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6D1A1B40F9E1B64689A7C1952F8B336792FED2F0@mtkmbs08n1>
> Fix this bug:
> drivers/media/platform/mtk-vcodec/vdec_drv_if.c:38 vdec_if_init() info: ignoring unreachable code.
>
> With is indeed a real problem that prevents the driver to work!
>
> While here, also remove an used var, as reported by smatch:
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_init_dec_pm':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:29:17: warning: variable 'dev' set but not used [-Wunused-but-set-variable]
> struct device *dev;
> ^~~
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Tiffany Lin <tiffany.lin@mediatek.com>
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 2 --
> drivers/media/platform/mtk-vcodec/vdec_drv_if.c | 1 +
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> index 18182f5676d8..79ca03ac449c 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> @@ -26,14 +26,12 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev) {
> struct device_node *node;
> struct platform_device *pdev;
> - struct device *dev;
> struct mtk_vcodec_pm *pm;
> int ret = 0;
>
> pdev = mtkdev->plat_dev;
> pm = &mtkdev->pm;
> pm->mtkdev = mtkdev;
> - dev = &pdev->dev;
> node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
> if (!node) {
> mtk_v4l2_err("of_parse_phandle mediatek,larb fail!"); diff --git a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
> index 3cb04ef45144..9813b2ffd5fa 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
> +++ b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
> @@ -31,6 +31,7 @@ int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> switch (fourcc) {
> case V4L2_PIX_FMT_H264:
> case V4L2_PIX_FMT_VP8:
> + break;
> default:
> return -EINVAL;
> }
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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
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