* Re: [PATCH v4 05/10] clk: mediatek: add clk support for MT6797
From: Stephen Boyd @ 2017-04-19 16:19 UTC (permalink / raw)
To: Mars Cheng
Cc: Matthias Brugger, CC Hwang, Loda Chou, Miles Chen, Jades Shih,
Yingjoe Chen, Kevin-CW Chen, linux-clk, linux-kernel,
linux-mediatek, devicetree, wsd_upstream
In-Reply-To: <1491614435-23754-6-git-send-email-mars.cheng@mediatek.com>
On 04/08, Mars Cheng wrote:
> From: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
>
> Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> and subsystem clocks
>
> Signed-off-by: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 1/2] clk: imx7d: fix USDHC NAND clock
From: Stephen Boyd @ 2017-04-19 16:14 UTC (permalink / raw)
To: Stefan Agner
Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
aisheng.dong-3arQi8VN3Tc, fabio.estevam-3arQi8VN3Tc,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170410210015.1620-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On 04/10, Stefan Agner wrote:
> The USDHC NAND root clock is not gated by any CCM clock gate. Remove
> the bogus gate definition.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
Can this be applied? It's followed by a dtsi change and there is
zero information about if the two depend on each other. Please
add cover letters for these sorts of things in the future
indicating how you expect merging to work.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 3/3] clk: vc5: Add support for IDT VersaClock 5P49V5935
From: Stephen Boyd @ 2017-04-19 16:09 UTC (permalink / raw)
To: Alexey Firago
Cc: mturquette, robh+dt, marek.vasut, geert, linux-clk, devicetree
In-Reply-To: <1491556344-9465-4-git-send-email-alexey_firago@mentor.com>
On 04/07, Alexey Firago wrote:
> Update IDT VersaClock 5 driver to support 5P49V5935. This chip has
> two clock inputs (internal XTAL or external CLKIN), four fractional
> dividers (FODs) and five clock outputs (four universal clock outputs
> and one reference clock output at OUT0_SELB_I2C).
>
> Current driver supports up to 2 FODs and up to 3 clock outputs. This
> patch sets max number of supported FODs to 4 and max number of supported
> clock outputs to 5.
>
> Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v4 2/3] clk: vc5: Add bindings for IDT VersaClock 5P49V5935
From: Stephen Boyd @ 2017-04-19 16:09 UTC (permalink / raw)
To: Alexey Firago
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491556344-9465-3-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 04/07, Alexey Firago wrote:
> IDT VersaClock 5 5P49V5935 has 4 clock outputs, 4 fractional dividers.
> Input clock source can be taken from either integrated crystal or from
> external reference clock.
>
> Signed-off-by: Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/3] clk: vc5: Add structure to describe particular chip features
From: Stephen Boyd @ 2017-04-19 16:09 UTC (permalink / raw)
To: Alexey Firago
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491556344-9465-2-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 04/07, Alexey Firago wrote:
> Introduce vc5_chip_info structure to describe features of a particular
> VC5 chip (id, number of FODs, number of outputs, flags).
> For now flags are only used to indicate if chip has internal XTAL.
> vc5_chip_info is set on probe from the matched of_device_id->data.
>
> Also add defines to specify maximum number of FODs and clock outputs
> supported by the driver.
>
> With these changes it should be easier to extend driver to support
> more VC5 models.
>
> Signed-off-by: Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Stephen Boyd @ 2017-04-19 16:00 UTC (permalink / raw)
To: Daniel Lezcano
Cc: mturquette, lee.jones, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <20170416205713.GW2078@mai>
On 04/16, Daniel Lezcano wrote:
> On Wed, Apr 12, 2017 at 08:02:45AM -0700, Stephen Boyd wrote:
> > On 04/08, Daniel Lezcano wrote:
>
> > > + struct hi655x_clk *hi655x_clk;
> > > + const char *clk_name = "hi655x-clk";
> > > + int ret;
> > > +
> > > + hi655x_clk = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk), GFP_KERNEL);
> > > + if (!hi655x_clk)
> > > + return -ENOMEM;
> > > +
> > > + hi655x_clk_init = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk_init),
> > > + GFP_KERNEL);
> > > + if (!hi655x_clk_init)
> > > + return -ENOMEM;
> > > +
> > > + of_property_read_string_index(parent->of_node, "clock-output-names",
> > > + 0, &clk_name);
> > > +
> > > + hi655x_clk_init->name = clk_name;
> > > + hi655x_clk_init->ops = &hi655x_clk_ops;
> > > +
> > > + hi655x_clk->clk_hw.init = hi655x_clk_init;
> > > + hi655x_clk->hi655x = hi655x;
> > > +
> > > + platform_set_drvdata(pdev, hi655x_clk);
> > > +
> > > + ret = devm_clk_hw_register(&pdev->dev, &hi655x_clk->clk_hw);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get,
> > > + &hi655x_clk->clk_hw);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> >
> > Missed this last time. Do you use this clkdev lookup? The name is
> > usually supposed to be based on what the device is expecting,
> > instead of clk_name, and we would want some device name for the
> > third argument here.
>
> I'm not sure to get your comment. Are you saying the clk_name should be the
> third argument?
>
>
Sorry, no. I meant that con_id is typically something like "core"
or "ahb" or something like that, and dev_id is something like
"a456002.pmic_device" or whatever dev_name(pmic_dev) would return for
the consuming device. That way when we call clk_get(dev, "core")
it will find the lookup with "core" and "a456002.pmic_device" to
match up the clk lookup.
If anything, the clk_name should just go into the con_id for now,
and then it will need to be a globally unique identifier for the
clk. But that is going against how clkdev is supposed to be used.
Hence the question if you even need to use it. If not, just don't
add it. I can fix up v3 of this patch to put clk_name back at
con_id if you like. No need to resend.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH 2/4] ARM: sunxi: Drop mmc0_cd_pin_reference_design pinmux setting
From: Chen-Yu Tsai @ 2017-04-19 15:49 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Maxime Ripard, devicetree, linux-sunxi,
linux-kernel, linux-arm-kernel
In-Reply-To: <442479d213a83c73cd7ff44538d234ea-h8G6r0blFSE@public.gmane.org>
On Wed, Apr 19, 2017 at 11:36 PM, <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
> 在 2017-04-19 13:09，Chen-Yu Tsai 写道：
>>
>> As part of our effort to move pinctrl/GPIO interlocking into the
>> driver where it belongs, this patch drops the definition and usage
>> of the mmc0_cd_pin_reference_design pinmux setting for the default
>> mmc0 card detect GPIO pin.
>>
>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
[...]
>> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
>> b/arch/arm/boot/dts/sun7i-a20.dtsi
>> index 93aa55970bd7..c03b59aaec82 100644
>> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
>> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
>> @@ -1190,12 +1190,6 @@
>> bias-pull-up;
>> };
>>
>> - mmc0_cd_pin_reference_design: mmc0_cd_pin@0 {
>> - pins = "PH1";
>> - function = "gpio_in";
>> - bias-pull-up;
>
>
> It needs pull up, so shouldn't be dropped.
>
> (Although there may be external pull-up resistors on the board;
> however last time we removed the pull-up on MMC node many boards
> failed, so we cannot rely on external pull-up resistors)
I checked the boards that I have schematics, and the reference design.
All have proper external pull-up resistors for this pin, unlike the
other mmc pins.
If some board doesn't, it really needs to be singled out and handled
separately. Have you encountered any issues?
Regards
ChenYu
>
>> - };
>> -
>> mmc2_pins_a: mmc2@0 {
>> pins = "PC6", "PC7", "PC8",
>> "PC9", "PC10", "PC11";
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] ARM: sunxi: Drop mmc0_cd_pin_reference_design pinmux setting
From: icenowy-h8G6r0blFSE @ 2017-04-19 15:36 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170419050919.6762-3-wens-jdAy2FN1RRM@public.gmane.org>
在 2017-04-19 13:09，Chen-Yu Tsai 写道：
> As part of our effort to move pinctrl/GPIO interlocking into the
> driver where it belongs, this patch drops the definition and usage
> of the mmc0_cd_pin_reference_design pinmux setting for the default
> mmc0 card detect GPIO pin.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> arch/arm/boot/dts/sun4i-a10-a1000.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-gemei-g9.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-hackberry.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-inet1.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-marsboard.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-mini-xplus.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-mk802.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-mk802ii.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-pcduino.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts | 2 +-
> arch/arm/boot/dts/sun4i-a10.dtsi | 6 ------
> arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-hummingbird.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-icnova-swac.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-itead-ibox.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-m3.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-mk808c.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 2 +-
> arch/arm/boot/dts/sun7i-a20.dtsi | 6 ------
> 38 files changed, 36 insertions(+), 48 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> index f2a01fe2bebc..f80d37ddc4c6 100644
> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> @@ -171,7 +171,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
> b/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
> index 942d739a4384..6b02de592a02 100644
> --- a/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-ba10-tvbox.dts
> @@ -109,7 +109,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> index 17f8c5ec011c..a7d61994b8fd 100644
> --- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> @@ -128,7 +128,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> index d844938e2aa7..a698a994e5ff 100644
> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> @@ -142,7 +142,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
> b/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
> index aad3bec1cb39..e0777ae808c7 100644
> --- a/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts
> @@ -163,7 +163,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
> b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
> index 9616cdecce93..d8bfd7b74916 100644
> --- a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
> @@ -146,7 +146,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH01 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
> b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
> index a1a7282199d5..856cfc9128e6 100644
> --- a/arch/arm/boot/dts/sun4i-a10-hackberry.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-hackberry.dts
> @@ -107,7 +107,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> index bc4351bb851f..6506595268b2 100644
> --- a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> @@ -79,7 +79,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet1.dts
> b/arch/arm/boot/dts/sun4i-a10-inet1.dts
> index b8923b92cb36..d51d8c302daf 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet1.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet1.dts
> @@ -161,7 +161,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> index a1a2bbb3f9d3..a8e479fe43ca 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> @@ -147,7 +147,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
> b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
> index 4a27eb9102cd..2acb89a87d41 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
> @@ -305,7 +305,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
> b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
> index 4e798f014c99..92e3e030ced3 100644
> --- a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
> @@ -100,7 +100,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
> b/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
> index 308dc1513041..92b2d4af3d21 100644
> --- a/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts
> @@ -140,7 +140,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-marsboard.dts
> b/arch/arm/boot/dts/sun4i-a10-marsboard.dts
> index 98a5f7258dca..0f927da28ee1 100644
> --- a/arch/arm/boot/dts/sun4i-a10-marsboard.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-marsboard.dts
> @@ -141,7 +141,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
> b/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
> index 484c57493bd2..a5ed9e4e22c6 100644
> --- a/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-mini-xplus.dts
> @@ -97,7 +97,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts
> b/arch/arm/boot/dts/sun4i-a10-mk802.dts
> index 2b75745cd246..81db6824a2c7 100644
> --- a/arch/arm/boot/dts/sun4i-a10-mk802.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-mk802.dts
> @@ -72,7 +72,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-mk802ii.dts
> b/arch/arm/boot/dts/sun4i-a10-mk802ii.dts
> index c861fa7e356c..e74a881fd9a7 100644
> --- a/arch/arm/boot/dts/sun4i-a10-mk802ii.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-mk802ii.dts
> @@ -83,7 +83,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> index 3a2522a9419d..462412ee903c 100644
> --- a/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts
> @@ -145,7 +145,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
> b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
> index 83596fd2ccfc..84f55e76df0c 100644
> --- a/arch/arm/boot/dts/sun4i-a10-pcduino.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-pcduino.dts
> @@ -147,7 +147,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
> b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
> index a68c7cc53b94..c0f8c88b5a7d 100644
> --- a/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts
> @@ -149,7 +149,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index b63668ece151..41c2579143fd 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -1030,12 +1030,6 @@
> bias-pull-up;
> };
>
> - mmc0_cd_pin_reference_design: mmc0_cd_pin@0 {
> - pins = "PH1";
> - function = "gpio_in";
> - bias-pull-up;
> - };
> -
> ps20_pins_a: ps20@0 {
> pins = "PI20", "PI21";
> function = "ps2";
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> index a2eab7aa80e0..7ac5bcc9f972 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> @@ -137,7 +137,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> index 102903e83bd2..4ebeecf9c3d7 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> @@ -178,7 +178,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
> b/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
> index 99c00b9a1546..6e6264cd69f8 100644
> --- a/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-hummingbird.dts
> @@ -160,7 +160,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v0>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> index 4da49717da21..e5cbcad3a556 100644
> --- a/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
> @@ -157,7 +157,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
> b/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
> index 28d3abbdc2d4..794e7617f545 100644
> --- a/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
> @@ -104,7 +104,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 8 5 GPIO_ACTIVE_HIGH>; /* PI5 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> index d52222c82cb8..8a8a6dbcd414 100644
> --- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> @@ -121,7 +121,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-m3.dts
> b/arch/arm/boot/dts/sun7i-a20-m3.dts
> index 86f69813683e..43c94787ef07 100644
> --- a/arch/arm/boot/dts/sun7i-a20-m3.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-m3.dts
> @@ -117,7 +117,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-mk808c.dts
> b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
> index c4ee30709f3a..f7413094183c 100644
> --- a/arch/arm/boot/dts/sun7i-a20-mk808c.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
> @@ -109,7 +109,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v0>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> index 1af5b46862cb..64c8ef9a2756 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> @@ -187,7 +187,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
> index dcd0f7a0dffa..2ce1a9f13a17 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
> @@ -130,7 +130,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> index e7d45425758c..097bd755764c 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> @@ -131,7 +131,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> index def0ad8395bb..0b7403e4d687 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> @@ -198,7 +198,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
> b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
> index f47a5c46bc20..39bc73db72e5 100644
> --- a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
> @@ -130,7 +130,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
> b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
> index 98177b5891cb..777152a3df0f 100644
> --- a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
> @@ -156,7 +156,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> index e19f17177755..f8d0aafb9f88 100644
> --- a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> @@ -151,7 +151,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
> b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
> index c3078d4f1093..84462d7961f5 100644
> --- a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
> @@ -120,7 +120,7 @@
>
> &mmc0 {
> pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>;
> + pinctrl-0 = <&mmc0_pins_a>;
> vmmc-supply = <®_vcc3v3>;
> bus-width = <4>;
> cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 93aa55970bd7..c03b59aaec82 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -1190,12 +1190,6 @@
> bias-pull-up;
> };
>
> - mmc0_cd_pin_reference_design: mmc0_cd_pin@0 {
> - pins = "PH1";
> - function = "gpio_in";
> - bias-pull-up;
It needs pull up, so shouldn't be dropped.
(Although there may be external pull-up resistors on the board;
however last time we removed the pull-up on MMC node many boards
failed, so we cannot rely on external pull-up resistors)
> - };
> -
> mmc2_pins_a: mmc2@0 {
> pins = "PC6", "PC7", "PC8",
> "PC9", "PC10", "PC11";
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* RE: [PATCH v2 1/2] dt-binding: regulator: anatop: make regulator name property required
From: A.S. Dong @ 2017-04-19 15:33 UTC (permalink / raw)
To: A.S. Dong, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1492180234-2496-1-git-send-email-aisheng.dong-3arQi8VN3Tc@public.gmane.org>
> -----Original Message-----
> From: Dong Aisheng [mailto:aisheng.dong-3arQi8VN3Tc@public.gmane.org]
> Sent: Friday, April 14, 2017 10:31 PM
> To: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: A.S. Dong; Rob Herring; Mark Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: [PATCH v2 1/2] dt-binding: regulator: anatop: make regulator name
> property required
>
> We actually can't allow the missing of the regualor name, thus update the
> binding doc to make regulator-name property to be required.
>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Dong Aisheng <aisheng.dong-3arQi8VN3Tc@public.gmane.org>
Sorry, Mark, missed you about this one.
Regards
Dong Aisheng
> ---
> Documentation/devicetree/bindings/regulator/anatop-regulator.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/anatop-
> regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-
> regulator.txt
> index 1d58c8c..a3106c7 100644
> --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> @@ -2,6 +2,7 @@ Anatop Voltage regulators
>
> Required properties:
> - compatible: Must be "fsl,anatop-regulator"
> +- regulator-name: A string used as a descriptive name for regulator
> +outputs
> - anatop-reg-offset: Anatop MFD register offset
> - anatop-vol-bit-shift: Bit shift for the register
> - anatop-vol-bit-width: Number of bits used in the register
> --
> 2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 6/8] coresight: add support for CPU debug module
From: Leo Yan @ 2017-04-19 15:30 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Suzuki K Poulose, Stephen Boyd, linux-doc,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-arm-msm, linux-soc,
Mike Leach, Sudeep Holla
In-Reply-To: <CANLsYkyheVJkEjpcWAd5HHFCimfTPhgihioE7bYo1RAL=8Shdw@mail.gmail.com>
On Wed, Apr 19, 2017 at 08:52:12AM -0600, Mathieu Poirier wrote:
[...]
> >> > +static bool debug_enable;
> >> > +module_param_named(enable, debug_enable, bool, 0600);
> >> > +MODULE_PARM_DESC(enable, "Knob to enable debug functionality "
> >> > + "(default is 0, which means is disabled by default)");
> >>
> >> For this driver we have a debugFS interface so I question the validity of a
> >> kernel module parameter. Other than adding complexity to the code it offers no
> >> real added value. If a user is to insmod a module, it is just as easy to switch
> >> on the functionality using debugFS in a second step.
> >
> > This module parameter can be used for kernel command line, so
> > it's useful when user wants to dynamically turn on/off the
> > functionality at boot up time.
> >
> > Does this make sense for you? Removing this parameter is okay for
> > me, but this means users need to decide if use it by Kernel config
> > with static building in. This is a bit contradictory with before's
> > discussion.
>
> My hope was to use the kernel command line and the debugFS interface,
> avoiding the module parameter. Look at what the baycom_par and
> blacklist drivers are doing with the "__setup()" function and see if
> we can void a module parameter. If not then let it be, unless someone
> else has a better idea.
>
> [1]. drivers/net/hamradio/baycom_par.c
> [2]. drivers/s390/cio/blacklist.c
This driver supports module mode. So we can choose to use either module
parameter or __setup(). But as described in the file
Documentation/admin-guide/kernel-parameters.rst, the module parameter
is more flexible to be used at boot time or insmod the module:
"Parameters for modules which are built into the kernel need to be
specified on the kernel command line. modprobe looks through the
kernel command line (/proc/cmdline) and collects module parameters
when it loads a module, so the kernel command line can be used for
loadable modules too."
__setup() cannot support module mode, and when use __setup(), we need
register one callback function for it. The callback function is
friendly to parse complex parameters rather than module parameter.
but it's not necessary for this case.
So I'm bias to use module parameter :)
Thanks,
Leo Yan
^ permalink raw reply
* Re: [RFC 2/2] mux: mmio-based syscon mux controller
From: Philipp Zabel @ 2017-04-19 15:27 UTC (permalink / raw)
To: Peter Rosin
Cc: Steve Longerbeam, Rob Herring, Mark Rutland, Sakari Ailus,
devicetree, linux-kernel, kernel
In-Reply-To: <e4d4b515-e799-9594-f88a-de9d8a5d14bb@axentia.se>
On Wed, 2017-04-19 at 13:58 +0200, Peter Rosin wrote:
> On 2017-04-19 13:50, Philipp Zabel wrote:
> > On Thu, 2017-04-13 at 18:09 -0700, Steve Longerbeam wrote:
> >>
> >> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
> >>> This adds a driver for mmio-based syscon multiplexers controlled by a
> >>> single bitfield in a syscon register range.
> >>>
> >>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> >>> ---
> >>> drivers/mux/Kconfig | 13 +++++
> >>> drivers/mux/Makefile | 1 +
> >>> drivers/mux/mux-syscon.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++
> >>> 3 files changed, 144 insertions(+)
> >>> create mode 100644 drivers/mux/mux-syscon.c
> >>>
> >>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
> >>> index 86668b4d2fc52..a5e6a3b01ac24 100644
> >>> --- a/drivers/mux/Kconfig
> >>> +++ b/drivers/mux/Kconfig
> >>> @@ -43,4 +43,17 @@ config MUX_GPIO
> >>> To compile the driver as a module, choose M here: the module will
> >>> be called mux-gpio.
> >>>
> >>> +config MUX_SYSCON
> >>
> >> my preference would be CONFIG_MUX_MMIO.
> >>
> >>> + tristate "MMIO bitfield-controlled Multiplexer"
> >>
> >> "MMIO register bitfield-controlled Multiplexer"
> >>
> >> The rest looks good to me.
> >
> > I'll change those. mux-syscon.c should probably be renamed to
> > mux-mmio.c, too.
>
> I think I disagree. But I'm not familiar with syscon so I don't know.
> IIUC, syscon uses regmap to do mmio and this driver requires syscon
> to get at the regmap, and in the end this driver doesn't know anything
> about mmio. All it knows is syscon/regmap.
That is a good point. Right now there is nothing MMIO about the driver
except for the hardware that I want it to handle.
> If some warped syscon
> thing shows up that wraps something other than mmio in its regmap,
> this driver wouldn't care about it. And syscon is something that
> is also known in the DT world. Given that, I think everything in this
> driver should be named syscon and not mmio.
>
> Or?
Well, ...
the driver could be extended to do actual MMIO if the syscon is not
found. This would work only if it has exclusive access to its register.
On the other hand, the driver could also be made to match against
compatible = "bitfield-mux",
for example, and allow handling muxes inside SPI or I2C controlled MFD
devices that provide a syscon regmap, as you describe:
spi-host {
mfd-device {
compatible = "some-spi-regmap-device";
mux {
compatible = "bitfield-mux";
};
};
};
regards
Philipp
^ permalink raw reply
* Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt
From: Joao Pinto @ 2017-04-19 15:22 UTC (permalink / raw)
To: Niklas Cassel, Rob Herring, Mark Rutland, David S. Miller,
Joao Pinto, Niklas Cassel, Alexandre TORGUE, Giuseppe CAVALLARO,
Thierry Reding, Eric Engestrom
Cc: netdev, devicetree, linux-kernel
In-Reply-To: <20170418123955.21335-1-niklass@axis.com>
Hi Niklas,
Às 1:39 PM de 4/18/2017, Niklas Cassel escreveu:
> From: Niklas Cassel <niklas.cassel@axis.com>
>
> The hardware has a LPI interrupt.
> There is already code in the stmmac driver to parse and handle the
> interrupt. However, this information was missing from the DT binding.
>
> At the same time, improve the description of the existing interrupts.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index f652b0c384ce..c3a7be6615c5 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -7,9 +7,12 @@ Required properties:
> - interrupt-parent: Should be the phandle for the interrupt controller
> that services interrupts for this device
> - interrupts: Should contain the STMMAC interrupts
> -- interrupt-names: Should contain the interrupt names "macirq"
> - "eth_wake_irq" if this interrupt is supported in the "interrupts"
> - property
> +- interrupt-names: Should contain a list of interrupt names corresponding to
> + the interrupts in the interrupts property, if available.
> + Valid interrupt names are:
> + - "macirq" (combined signal for various interrupt events)
> + - "eth_wake_irq" (the interrupt to manage the remote wake-up packet detection)
> + - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
> - phy-mode: See ethernet.txt file in the same directory.
> - snps,reset-gpio gpio number for phy reset.
> - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> @@ -152,8 +155,8 @@ Examples:
> compatible = "st,spear600-gmac";
> reg = <0xe0800000 0x8000>;
> interrupt-parent = <&vic1>;
> - interrupts = <24 23>;
> - interrupt-names = "macirq", "eth_wake_irq";
> + interrupts = <24 23 22>;
> + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
> mac-address = [000000000000]; /* Filled in by U-Boot */
> max-frame-size = <3800>;
> phy-mode = "gmii";
>
Acked-By: Joao Pinto <jpinto@synopsys.com>
Regards!
^ permalink raw reply
* Re: [PATCH v6 6/8] coresight: add support for CPU debug module
From: Leo Yan @ 2017-04-19 15:07 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Mathieu Poirier, Stephen Boyd, linux-doc, linux-kernel,
devicetree, linux-arm-kernel, linux-arm-msm, linux-soc,
Mike Leach, Sudeep Holla
In-Reply-To: <f42088f6-aa53-06b1-b332-22198744ab7a@arm.com>
On Wed, Apr 19, 2017 at 03:32:39PM +0100, Suzuki K Poulose wrote:
[...]
> >>>+static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> >>>+{
> >>>+ void __iomem *base;
> >>>+ struct device *dev = &adev->dev;
> >>>+ struct debug_drvdata *drvdata;
> >>>+ struct resource *res = &adev->res;
> >>>+ struct device_node *np = adev->dev.of_node;
> >>>+ int ret;
> >>>+
> >>>+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> >>>+ if (!drvdata)
> >>>+ return -ENOMEM;
> >>>+
> >>>+ drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> >>>+ if (per_cpu(debug_drvdata, drvdata->cpu)) {
> >>>+ dev_err(dev, "CPU%d drvdata has been initialized\n",
> >>>+ drvdata->cpu);
> >>
> >>May be we could warn about a possible issue in the DT ?
> >
> >So can I understand the suggestion is to add warning in function
> >of_coresight_get_cpu() when cannot find CPU number, and here directly
> >bail out?
>
> No. One could have single CPU DT, where he doesn't need to provide the CPU number.
> Hence, it doesn't make sense to WARN in of_coresight_get_cpu().
>
> But when we hit the case above, we find that the some node was registered for
> the given CPU (be it 0 or any other), which is definitely an error in DT. Due to
>
> 1) Hasn't specified the CPU number for more than one node
>
> OR
>
> 2) CPU number duplicated in the more than one nodes.
Thanks for explaination. It's clear for me now.
> Cheers
> Suzuki
^ permalink raw reply
* Re: [PATCH 0/4] ARM: sunxi: device tree pinctrl clean up and H3 OTG
From: Maxime Ripard @ 2017-04-19 14:54 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170419050919.6762-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On Wed, Apr 19, 2017 at 01:09:15PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> This series has 2 parts. The parts are largely unrelated, though the
> second part should be applied after the first part, so we don't
> accidentally mux pins that we shouldn't. Hence I'm sending them
> together.
>
> The first 2 patches clean up the sunxi device tree files, removing
> pinmux settings for common GPIO pins. These include the enable pins
> for the common regulators, and the mmc0 card detect pin from the
> reference designs.
>
> The second part, the latter 2 patches, enable USB OTG on the Orangepi
> PC, PC Plus, Plus 2E, and the Bananapi M2+. The first 3 boards are
> bunched together, due to how the PC Plus and Plus 2E device trees include
> the device tree of the Opi PC.
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: pine64: Prepare optional UART nodes with pinctrl
From: Maxime Ripard @ 2017-04-19 14:52 UTC (permalink / raw)
To: Andreas Färber
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20170418192538.24174-1-afaerber@suse.de>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Tue, Apr 18, 2017 at 09:25:38PM +0200, Andreas Färber wrote:
> Pine64 exposes all A64 UARTs, not just UART0.
>
> Since the pins can be used as GPIO, don't enable the new UART nodes by
> default, but prepare the pinctrl settings to aid in activating them via
> overlays, i.e., overriding the status property of &uartX nodes.
>
> For UART4 (Euler) the safer route of not including RTS/CTS pins is chosen,
> whereas for UART1 (Bluetooth) they are included.
>
> Add the corresponding pinctrl nodes where missing.
>
> Suggested-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Andreas Färber <afaerber@suse.de>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v6 6/8] coresight: add support for CPU debug module
From: Mathieu Poirier @ 2017-04-19 14:52 UTC (permalink / raw)
To: Leo Yan
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Suzuki K Poulose, Stephen Boyd, linux-doc,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-arm-msm, linux-soc,
Mike Leach, Sudeep Holla
In-Reply-To: <20170419001807.GB8524@leoy-linaro>
On 18 April 2017 at 18:18, Leo Yan <leo.yan@linaro.org> wrote:
> On Tue, Apr 18, 2017 at 11:40:50AM -0600, Mathieu Poirier wrote:
>> On Thu, Apr 06, 2017 at 09:30:59PM +0800, Leo Yan wrote:
>> > Coresight includes debug module and usually the module connects with CPU
>> > debug logic. ARMv8 architecture reference manual (ARM DDI 0487A.k) has
>> > description for related info in "Part H: External Debug".
>> >
>> > Chapter H7 "The Sample-based Profiling Extension" introduces several
>> > sampling registers, e.g. we can check program counter value with
>> > combined CPU exception level, secure state, etc. So this is helpful for
>> > analysis CPU lockup scenarios, e.g. if one CPU has run into infinite
>> > loop with IRQ disabled. In this case the CPU cannot switch context and
>> > handle any interrupt (including IPIs), as the result it cannot handle
>> > SMP call for stack dump.
>> >
>> > This patch is to enable coresight debug module, so firstly this driver
>> > is to bind apb clock for debug module and this is to ensure the debug
>> > module can be accessed from program or external debugger. And the driver
>> > uses sample-based registers for debug purpose, e.g. when system triggers
>> > panic, the driver will dump program counter and combined context
>> > registers (EDCIDSR, EDVIDSR); by parsing context registers so can
>> > quickly get to know CPU secure state, exception level, etc.
>> >
>> > Some of the debug module registers are located in CPU power domain, so
>> > this requires the CPU power domain stays on when access related debug
>> > registers, but the power management for CPU power domain is quite
>> > dependent on SoC integration for power management. For the platforms
>> > which with sane power controller implementations, this driver follows
>> > the method to set EDPRCR to try to pull the CPU out of low power state
>> > and then set 'no power down request' bit so the CPU has no chance to
>> > lose power.
>> >
>> > If the SoC has not followed up this design well for power management
>> > controller, the user should use the command line parameter or sysfs
>> > to constrain all or partial idle states to ensure the CPU power
>> > domain is enabled and access coresight CPU debug component safely.
>> >
>> > Signed-off-by: Leo Yan <leo.yan@linaro.org>
>>
>> This is coming along well - a few comment below. In your next revision please
>> add GKH to the 'To' list.
>
> Sure. Will send out in this week and add Greg in 'To' list.
>
>> > ---
>> > drivers/hwtracing/coresight/Kconfig | 14 +
>> > drivers/hwtracing/coresight/Makefile | 1 +
>> > drivers/hwtracing/coresight/coresight-cpu-debug.c | 667 ++++++++++++++++++++++
>> > 3 files changed, 682 insertions(+)
>> > create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
>> >
>> > diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>> > index 130cb21..8d55d6d 100644
>> > --- a/drivers/hwtracing/coresight/Kconfig
>> > +++ b/drivers/hwtracing/coresight/Kconfig
>> > @@ -89,4 +89,18 @@ config CORESIGHT_STM
>> > logging useful software events or data coming from various entities
>> > in the system, possibly running different OSs
>> >
>> > +config CORESIGHT_CPU_DEBUG
>> > + tristate "CoreSight CPU Debug driver"
>> > + depends on ARM || ARM64
>> > + depends on DEBUG_FS
>> > + help
>> > + This driver provides support for coresight debugging module. This
>> > + is primarily used to dump sample-based profiling registers when
>> > + system triggers panic, the driver will parse context registers so
>> > + can quickly get to know program counter (PC), secure state,
>> > + exception level, etc. Before use debugging functionality, platform
>> > + needs to ensure the clock domain and power domain are enabled
>> > + properly, please refer Documentation/trace/coresight-cpu-debug.txt
>> > + for detailed description and the example for usage.
>> > +
>> > endif
>> > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>> > index af480d9..433d590 100644
>> > --- a/drivers/hwtracing/coresight/Makefile
>> > +++ b/drivers/hwtracing/coresight/Makefile
>> > @@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
>> > coresight-etm4x-sysfs.o
>> > obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>> > obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> > +obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>> > diff --git a/drivers/hwtracing/coresight/coresight-cpu-debug.c b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> > new file mode 100644
>> > index 0000000..8470e31
>> > --- /dev/null
>> > +++ b/drivers/hwtracing/coresight/coresight-cpu-debug.c
>> > @@ -0,0 +1,667 @@
>> > +/*
>> > + * Copyright (c) 2017 Linaro Limited. All rights reserved.
>> > + *
>> > + * Author: Leo Yan <leo.yan@linaro.org>
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify it
>> > + * under the terms of the GNU General Public License version 2 as published by
>> > + * the Free Software Foundation.
>> > + *
>> > + * This program is distributed in the hope that it will be useful, but WITHOUT
>> > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> > + * more details.
>> > + *
>> > + * You should have received a copy of the GNU General Public License along with
>> > + * this program. If not, see <http://www.gnu.org/licenses/>.
>> > + *
>> > + */
>> > +#include <linux/amba/bus.h>
>> > +#include <linux/coresight.h>
>> > +#include <linux/cpu.h>
>> > +#include <linux/debugfs.h>
>> > +#include <linux/delay.h>
>> > +#include <linux/device.h>
>> > +#include <linux/err.h>
>> > +#include <linux/init.h>
>> > +#include <linux/io.h>
>> > +#include <linux/iopoll.h>
>> > +#include <linux/kernel.h>
>> > +#include <linux/module.h>
>> > +#include <linux/moduleparam.h>
>> > +#include <linux/pm_qos.h>
>> > +#include <linux/slab.h>
>> > +#include <linux/smp.h>
>> > +#include <linux/types.h>
>> > +#include <linux/uaccess.h>
>> > +
>> > +#include "coresight-priv.h"
>> > +
>> > +#define EDPCSR 0x0A0
>> > +#define EDCIDSR 0x0A4
>> > +#define EDVIDSR 0x0A8
>> > +#define EDPCSR_HI 0x0AC
>> > +#define EDOSLAR 0x300
>> > +#define EDPRCR 0x310
>> > +#define EDPRSR 0x314
>> > +#define EDDEVID1 0xFC4
>> > +#define EDDEVID 0xFC8
>> > +
>> > +#define EDPCSR_PROHIBITED 0xFFFFFFFF
>> > +
>> > +/* bits definition for EDPCSR */
>> > +#define EDPCSR_THUMB BIT(0)
>> > +#define EDPCSR_ARM_INST_MASK GENMASK(31, 2)
>> > +#define EDPCSR_THUMB_INST_MASK GENMASK(31, 1)
>> > +
>> > +/* bits definition for EDPRCR */
>> > +#define EDPRCR_COREPURQ BIT(3)
>> > +#define EDPRCR_CORENPDRQ BIT(0)
>> > +
>> > +/* bits definition for EDPRSR */
>> > +#define EDPRSR_DLK BIT(6)
>> > +#define EDPRSR_PU BIT(0)
>> > +
>> > +/* bits definition for EDVIDSR */
>> > +#define EDVIDSR_NS BIT(31)
>> > +#define EDVIDSR_E2 BIT(30)
>> > +#define EDVIDSR_E3 BIT(29)
>> > +#define EDVIDSR_HV BIT(28)
>> > +#define EDVIDSR_VMID GENMASK(7, 0)
>> > +
>> > +/*
>> > + * bits definition for EDDEVID1:PSCROffset
>> > + *
>> > + * NOTE: armv8 and armv7 have different definition for the register,
>> > + * so consolidate the bits definition as below:
>> > + *
>> > + * 0b0000 - Sample offset applies based on the instruction state, we
>> > + * rely on EDDEVID to check if EDPCSR is implemented or not
>> > + * 0b0001 - No offset applies.
>> > + * 0b0010 - No offset applies, but do not use in AArch32 mode
>> > + *
>> > + */
>> > +#define EDDEVID1_PCSR_OFFSET_MASK GENMASK(3, 0)
>> > +#define EDDEVID1_PCSR_OFFSET_INS_SET (0x0)
>> > +#define EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32 (0x2)
>> > +
>> > +/* bits definition for EDDEVID */
>> > +#define EDDEVID_PCSAMPLE_MODE GENMASK(3, 0)
>> > +#define EDDEVID_IMPL_EDPCSR (0x1)
>> > +#define EDDEVID_IMPL_EDPCSR_EDCIDSR (0x2)
>> > +#define EDDEVID_IMPL_FULL (0x3)
>> > +
>> > +#define DEBUG_WAIT_SLEEP 1000
>> > +#define DEBUG_WAIT_TIMEOUT 32000
>> > +
>> > +struct debug_drvdata {
>> > + void __iomem *base;
>> > e struct device *dev;
>> > + int cpu;
>> > +
>> > + bool edpcsr_present;
>> > + bool edcidsr_present;
>> > + bool edvidsr_present;
>> > + bool pc_has_offset;
>> > +
>> > + u32 edpcsr;
>> > + u32 edpcsr_hi;
>> > + u32 edprsr;
>> > + u32 edvidsr;
>> > + u32 edcidsr;
>> > +};
>> > +
>> > +static DEFINE_MUTEX(debug_lock);
>> > +static DEFINE_PER_CPU(struct debug_drvdata *, debug_drvdata);
>> > +static int debug_count;
>> > +static struct dentry *debug_debugfs_dir;
>> > +
>> > +static bool debug_enable;
>> > +module_param_named(enable, debug_enable, bool, 0600);
>> > +MODULE_PARM_DESC(enable, "Knob to enable debug functionality "
>> > + "(default is 0, which means is disabled by default)");
>>
>> For this driver we have a debugFS interface so I question the validity of a
>> kernel module parameter. Other than adding complexity to the code it offers no
>> real added value. If a user is to insmod a module, it is just as easy to switch
>> on the functionality using debugFS in a second step.
>
> This module parameter can be used for kernel command line, so
> it's useful when user wants to dynamically turn on/off the
> functionality at boot up time.
>
> Does this make sense for you? Removing this parameter is okay for
> me, but this means users need to decide if use it by Kernel config
> with static building in. This is a bit contradictory with before's
> discussion.
My hope was to use the kernel command line and the debugFS interface,
avoiding the module parameter. Look at what the baycom_par and
blacklist drivers are doing with the "__setup()" function and see if
we can void a module parameter. If not then let it be, unless someone
else has a better idea.
[1]. drivers/net/hamradio/baycom_par.c
[2]. drivers/se90/cio/blacklist.c
>
>> > +static void debug_os_unlock(struct debug_drvdata *drvdata)
>> > +{
>> > + /* Unlocks the debug registers */
>> > + writel_relaxed(0x0, drvdata->base + EDOSLAR);
>>
>> Here the wmb is to make sure reordering (either at compile time or in the CPU)
>> doesn't happend. You need a comment here otherwise checkpatch will complain.
>> Speaking of which, did you run this through checkpatch?
>
> Right. Everytime I run checkpatch before sending patch and it has
> complain for this. Will add comment. Sorry for imprecise working.
>
>> > + wmb();
>> > +}
>> > +
>> > +/*
>> > + * According to ARM DDI 0487A.k, before access external debug
>> > + * registers should firstly check the access permission; if any
>> > + * below condition has been met then cannot access debug
>> > + * registers to avoid lockup issue:
>> > + *
>> > + * - CPU power domain is powered off;
>> > + * - The OS Double Lock is locked;
>> > + *
>> > + * By checking EDPRSR can get to know if meet these conditions.
>> > + */
>> > +static bool debug_access_permitted(struct debug_drvdata *drvdata)
>> > +{
>> > + /* CPU is powered off */
>> > + if (!(drvdata->edprsr & EDPRSR_PU))
>> > + return false;
>> > +
>> > + /* The OS Double Lock is locked */
>> > + if (drvdata->edprsr & EDPRSR_DLK)
>> > + return false;
>> > +
>> > + return true;
>> > +}
>> > +
>> > +static void debug_force_cpu_powered_up(struct debug_drvdata *drvdata)
>> > +{
>> > + bool retried = false;
>> > + u32 edprcr;
>> > +
>> > +try_again:
>> > +
>> > + /*
>> > + * Send request to power management controller and assert
>> > + * DBGPWRUPREQ signal; if power management controller has
>> > + * sane implementation, it should enable CPU power domain
>> > + * in case CPU is in low power state.
>> > + */
>> > + edprcr = readl_relaxed(drvdata->base + EDPRCR);
>> > + edprcr |= EDPRCR_COREPURQ;
>> > + writel_relaxed(edprcr, drvdata->base + EDPRCR);
>> > +
>> > + /* Wait for CPU to be powered up (timeout~=32ms) */
>> > + if (readx_poll_timeout_atomic(readl_relaxed, drvdata->base + EDPRSR,
>> > + drvdata->edprsr, (drvdata->edprsr & EDPRSR_PU),
>> > + DEBUG_WAIT_SLEEP, DEBUG_WAIT_TIMEOUT)) {
>> > + /*
>> > + * Unfortunately the CPU cannot be powered up, so return
>> > + * back and later has no permission to access other
>> > + * registers. For this case, should disable CPU low power
>> > + * states to ensure CPU power domain is enabled!
>> > + */
>> > + pr_err("%s: power up request for CPU%d failed\n",
>> > + __func__, drvdata->cpu);
>> > + return;
>> > + }
>> > +
>> > + /*
>> > + * At this point the CPU is powered up, so set the no powerdown
>> > + * request bit so we don't lose power and emulate power down.
>> > + */
>> > + edprcr = readl_relaxed(drvdata->base + EDPRCR);
>> > + edprcr |= EDPRCR_COREPURQ | EDPRCR_CORENPDRQ;
>> > + writel_relaxed(edprcr, drvdata->base + EDPRCR);
>> > +
>> > + drvdata->edprsr = readl_relaxed(drvdata->base + EDPRSR);
>> > +
>> > + /* Bail out if CPU is powered up */
>> > + if (likely(drvdata->edprsr & EDPRSR_PU))
>> > + return;
>>
>> /* The core power domain got switched off on use, try again */
>> if (unlikely(!drvdata->edprsr & EDPRSR_PU))
>> goto try_again;
>>
>> I understand you don't want to introduce a infinite loop but if that happens
>> here, something else has gone very wrong. The above readx_poll_timeout_atomic
>> loop should take care of bailing out in case of problems. That way you also get
>> to rid of the retried variable and the code is more simple.
>
> Okay. I will follow your method. Thinking the duration of CPU power
> on/off is not same magnitude with this piece code, the infinite loop
> will not happen.
>
>> > +
>> > + /*
>> > + * Handle race condition if CPU has been waken up but it sleeps
>> > + * again if EDPRCR_CORENPDRQ has been flipped, so try to run
>> > + * waken flow one more time.
>> > + */
>> > + if (!retried) {
>> > + retried = true;
>> > + goto try_again;
>> > + }
>> > +}
>> > +
>> > +static void debug_read_regs(struct debug_drvdata *drvdata)
>> > +{
>> > + u32 save_edprcr;
>> > +
>> > + CS_UNLOCK(drvdata->base);
>> > +
>> > + /* Unlock os lock */
>> > + debug_os_unlock(drvdata);
>> > +
>> > + /* Save EDPRCR register */
>> > + save_edprcr = readl_relaxed(drvdata->base + EDPRCR);
>> > +
>> > + /*
>> > + * Ensure CPU power domain is enabled to let registers
>> > + * are accessiable.
>> > + */
>> > + debug_force_cpu_powered_up(drvdata);
>> > +
>> > + if (!debug_access_permitted(drvdata))
>> > + goto out;
>> > +
>> > + drvdata->edpcsr = readl_relaxed(drvdata->base + EDPCSR);
>> > +
>> > + /*
>> > + * As described in ARM DDI 0487A.k, if the processing
>> > + * element (PE) is in debug state, or sample-based
>> > + * profiling is prohibited, EDPCSR reads as 0xFFFFFFFF;
>> > + * EDCIDSR, EDVIDSR and EDPCSR_HI registers also become
>> > + * UNKNOWN state. So directly bail out for this case.
>> > + */
>> > + if (drvdata->edpcsr == EDPCSR_PROHIBITED)
>> > + goto out;
>> > +
>> > + /*
>> > + * A read of the EDPCSR normally has the side-effect of
>> > + * indirectly writing to EDCIDSR, EDVIDSR and EDPCSR_HI;
>> > + * at this point it's safe to read value from them.
>> > + */
>> > + if (IS_ENABLED(CONFIG_64BIT))
>> > + drvdata->edpcsr_hi = readl_relaxed(drvdata->base + EDPCSR_HI);
>> > +
>> > + if (drvdata->edcidsr_present)
>> > + drvdata->edcidsr = readl_relaxed(drvdata->base + EDCIDSR);
>> > +
>> > + if (drvdata->edvidsr_present)
>> > + drvdata->edvidsr = readl_relaxed(drvdata->base + EDVIDSR);
>> > +
>> > +out:
>> > + /* Restore EDPRCR register */
>> > + writel_relaxed(save_edprcr, drvdata->base + EDPRCR);
>> > +
>> > + CS_LOCK(drvdata->base);
>> > +}
>> > +
>> > +static unsigned long debug_adjust_pc(struct debug_drvdata *drvdata)
>> > +{
>> > + unsigned long arm_inst_offset = 0, thumb_inst_offset = 0;
>> > + unsigned long pc;
>> > +
>> > + if (IS_ENABLED(CONFIG_64BIT))
>> > + return (unsigned long)drvdata->edpcsr_hi << 32 |
>> > + (unsigned long)drvdata->edpcsr;
>> > +
>> > + pc = (unsigned long)drvdata->edpcsr;
>> > +
>> > + if (drvdata->pc_has_offset) {
>> > + arm_inst_offset = 8;
>> > + thumb_inst_offset = 4;
>> > + }
>> > +
>> > + /* Handle thumb instruction */
>> > + if (pc & EDPCSR_THUMB) {
>> > + pc = (pc & EDPCSR_THUMB_INST_MASK) - thumb_inst_offset;
>> > + return pc;
>> > + }
>> > +
>> > + /*
>> > + * Handle arm instruction offset, if the arm instruction
>> > + * is not 4 byte alignment then it's possible the case
>> > + * for implementation defined; keep original value for this
>> > + * case and print info for notice.
>> > + */
>> > + if (pc & BIT(1))
>> > + pr_emerg("Instruction offset is implementation defined\n");
>> > + else
>> > + pc = (pc & EDPCSR_ARM_INST_MASK) - arm_inst_offset;
>> > +
>> > + return pc;
>> > +}
>> > +
>> > +static void debug_dump_regs(struct debug_drvdata *drvdata)
>> > +{
>> > + unsigned long pc;
>> > +
>> > + pr_emerg("\tEDPRSR: %08x (Power:%s DLK:%s)\n", drvdata->edprsr,
>> > + drvdata->edprsr & EDPRSR_PU ? "On" : "Off",
>> > + drvdata->edprsr & EDPRSR_DLK ? "Lock" : "Unlock");
>> > +
>> > + if (!debug_access_permitted(drvdata)) {
>> > + pr_emerg("No permission to access debug registers!\n");
>> > + return;
>> > + }
>> > +
>> > + if (drvdata->edpcsr == EDPCSR_PROHIBITED) {
>> > + pr_emerg("CPU is in Debug state or profiling is prohibited!\n");
>> > + return;
>> > + }
>> > +
>> > + pc = debug_adjust_pc(drvdata);
>> > + pr_emerg("\tEDPCSR: [<%p>] %pS\n", (void *)pc, (void *)pc);
>> > +
>> > + if (drvdata->edcidsr_present)
>> > + pr_emerg("\tEDCIDSR: %08x\n", drvdata->edcidsr);
>> > +
>> > + if (drvdata->edvidsr_present)
>> > + pr_emerg("\tEDVIDSR: %08x (State:%s Mode:%s Width:%dbits VMID:%x)\n",
>> > + drvdata->edvidsr,
>> > + drvdata->edvidsr & EDVIDSR_NS ? "Non-secure" : "Secure",
>> > + drvdata->edvidsr & EDVIDSR_E3 ? "EL3" :
>> > + (drvdata->edvidsr & EDVIDSR_E2 ? "EL2" : "EL1/0"),
>> > + drvdata->edvidsr & EDVIDSR_HV ? 64 : 32,
>> > + drvdata->edvidsr & (u32)EDVIDSR_VMID);
>> > +}
>> > +
>> > +static void debug_init_arch_data(void *info)
>> > +{
>> > + struct debug_drvdata *drvdata = info;
>> > + u32 mode, pcsr_offset;
>> > + u32 eddevid, eddevid1;
>> > +
>> > + CS_UNLOCK(drvdata->base);
>> > +
>> > + /* Read device info */
>> > + eddevid = readl_relaxed(drvdata->base + EDDEVID);
>> > + eddevid1 = readl_relaxed(drvdata->base + EDDEVID1);
>> > +
>> > + CS_LOCK(drvdata->base);
>> > +
>> > + /* Parse implementation feature */
>> > + mode = eddevid & EDDEVID_PCSAMPLE_MODE;
>> > + pcsr_offset = eddevid1 & EDDEVID1_PCSR_OFFSET_MASK;
>> > +
>> > + drvdata->edpcsr_present = false;
>> > + drvdata->edcidsr_present = false;
>> > + drvdata->edvidsr_present = false;
>> > + drvdata->pc_has_offset = false;
>> > +
>> > + switch (mode) {
>> > + case EDDEVID_IMPL_FULL:
>> > + drvdata->edvidsr_present = true;
>> > + /* Fall through */
>> > + case EDDEVID_IMPL_EDPCSR_EDCIDSR:
>> > + drvdata->edcidsr_present = true;
>> > + /* Fall through */
>> > + case EDDEVID_IMPL_EDPCSR:
>> > + /*
>> > + * In ARM DDI 0487A.k, the EDDEVID1.PCSROffset is used to
>> > + * define if has the offset for PC sampling value; if read
>> > + * back EDDEVID1.PCSROffset == 0x2, then this means the debug
>> > + * module does not sample the instruction set state when
>> > + * armv8 CPU in AArch32 state.
>> > + */
>> > + drvdata->edpcsr_present = (IS_ENABLED(CONFIG_64BIT) ||
>> > + (pcsr_offset != EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32));
>> > +
>> > + drvdata->pc_has_offset =
>> > + (pcsr_offset == EDDEVID1_PCSR_OFFSET_INS_SET);
>> > + break;
>> > + default:
>> > + break;
>> > + }
>> > +}
>> > +
>> > +/*
>> > + * Dump out information on panic.
>> > + */
>> > +static int debug_notifier_call(struct notifier_block *self,
>> > + unsigned long v, void *p)
>> > +{
>> > + int cpu;
>> > + struct debug_drvdata *drvdata;
>> > +
>> > + pr_emerg("ARM external debug module:\n");
>> > +
>> > + for_each_possible_cpu(cpu) {
>> > + drvdata = per_cpu(debug_drvdata, cpu);
>> > + if (!drvdata)
>> > + continue;
>> > +
>> > + pr_emerg("CPU[%d]:\n", drvdata->cpu);
>> > +
>> > + debug_read_regs(drvdata);
>> > + debug_dump_regs(drvdata);
>> > + }
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static struct notifier_block debug_notifier = {
>> > + .notifier_call = debug_notifier_call,
>> > +};
>> > +
>> > +static int debug_enable_func(void)
>> > +{
>> > + struct debug_drvdata *drvdata;
>> > + int cpu;
>> > +
>> > + for_each_possible_cpu(cpu) {
>> > + drvdata = per_cpu(debug_drvdata, cpu);
>> > + if (!drvdata)
>> > + continue;
>> > +
>> > + pm_runtime_get_sync(drvdata->dev);
>> > + }
>> > +
>> > + return atomic_notifier_chain_register(&panic_notifier_list,
>> > + &debug_notifier);
>> > +}
>> > +
>> > +static int debug_disable_func(void)
>> > +{
>> > + struct debug_drvdata *drvdata;
>> > + int cpu;
>> > +
>> > + for_each_possible_cpu(cpu) {
>> > + drvdata = per_cpu(debug_drvdata, cpu);
>> > + if (!drvdata)
>> > + continue;
>> > +
>> > + pm_runtime_put(drvdata->dev);
>> > + }
>> > +
>> > + return atomic_notifier_chain_unregister(&panic_notifier_list,
>> > + &debug_notifier);
>> > +}
>> > +
>> > +static ssize_t debug_func_knob_write(struct file *f,
>> > + const char __user *buf, size_t count, loff_t *ppos)
>> > +{
>> > + u8 val;
>> > + int ret;
>> > +
>> > + ret = kstrtou8_from_user(buf, count, 2, &val);
>> > + if (ret)
>> > + return ret;
>> > +
>> > + mutex_lock(&debug_lock);
>> > +
>> > + if (val == debug_enable)
>> > + goto out;
>> > +
>> > + if (val)
>> > + ret = debug_enable_func();
>> > + else
>> > + ret = debug_disable_func();
>>
>> I don't think you need to install the handler every time the functionality is
>> switched on/off. I suggest to install the handler at boot time (or module
>> insertion time) and in the notifier handler, check the debug_enable flag before
>> moving on with the output.
>
> Will do.
>
>> > +
>> > + if (ret) {
>> > + pr_err("%s: unable to %s debug function: %d\n",
>> > + __func__, val ? "enable" : "disable", ret);
>> > + goto err;
>> > + }
>> > +
>> > + debug_enable = val;
>>
>> Using a true/false value is probably better here. That way you don't end up
>> with miscellaneous values in debugFS.
>
> From my testing here will not assign other values rather than 0 or 1.
> This is controlled by function kstrtou8_from_user(), the 3rd parameter
> '2' is to define the value range [0..1], so other values will report
> error after return back from kstrtou8_from_user().
Ok that works.
>
>> > +out:
>> > + ret = count;
>> > +err:
>> > + mutex_unlock(&debug_lock);
>> > + return ret;
>> > +}
>> > +
>> > +static ssize_t debug_func_knob_read(struct file *f,
>> > + char __user *ubuf, size_t count, loff_t *ppos)
>> > +{
>> > + ssize_t ret;
>> > + char buf[2];
>> > +
>> > + mutex_lock(&debug_lock);
>> > +
>> > + buf[0] = '0' + debug_enable;
>> > + buf[1] = '\n';
>>
>> snprintf()
>
> Will fix.
>
>> > + ret = simple_read_from_buffer(ubuf, count, ppos, buf, sizeof(buf));
>> > +
>> > + mutex_unlock(&debug_lock);
>> > + return ret;
>> > +}
>> > +
>> > +static const struct file_operations debug_func_knob_fops = {
>> > + .open = simple_open,
>> > + .read = debug_func_knob_read,
>> > + .write = debug_func_knob_write,
>> > +};
>> > +
>> > +static int debug_func_init(void)
>> > +{
>> > + struct dentry *file;
>> > + int ret;
>> > +
>> > + /* Create debugfs node */
>> > + debug_debugfs_dir = debugfs_create_dir("coresight_cpu_debug", NULL);
>> > + if (!debug_debugfs_dir) {
>> > + pr_err("%s: unable to create debugfs directory\n", __func__);
>> > + return -ENOMEM;
>> > + }
>> > +
>> > + file = debugfs_create_file("enable", S_IRUGO | S_IWUSR,
>> > + debug_debugfs_dir, NULL, &debug_func_knob_fops);
>>
>> Please align this properly.
>
> Will fix. Thanks a lot for detailed reviewing.
>
> [...]
>
> Thanks,
> Leo Yan
^ permalink raw reply
* Re: [PATCH 0/4] staging: add ccree crypto driver
From: Gilad Ben-Yossef @ 2017-04-19 14:40 UTC (permalink / raw)
To: Mark Rutland
Cc: Herbert Xu, David S. Miller, Rob Herring, Greg Kroah-Hartman,
devel, linux-crypto, devicetree, Linux kernel mailing list,
Gilad Ben-Yossef, Binoy Jayan, Ofir Drang
In-Reply-To: <20170418154349.GJ17866@leverpostej>
On Tue, Apr 18, 2017 at 6:43 PM, Mark Rutland <mark.rutland@arm.com> wrote:
...
>> >>
>> >> The code still needs some cleanup before maturing to a proper
>> >> upstream driver, which I am in the process of doing. However,
>> >> as discussion of some of the capabilities of the hardware and
>> >> its application to some dm-crypt and dm-verity features recently
>> >> took place I though it is better to do this in the open via the
>> >> staging tree.
>> >>
>> >> A Git repository based off of Linux 4.11-rc7 is available at
>> >> https://github.com/gby/linux.git branch ccree.
>> >>
...
>> >> .../devicetree/bindings/crypto/arm-cryptocell.txt | 23 +
>> >
>> > I'm interested in looking at the DT binding, but for some reason I've
>> > only recevied the cover letter so far.
>> >
>> > Are my mail servers being particularly slow today, or has something gone
>> > wrong with the Cc list for the remaining patches?
>> >
>>
>> Thanks a bunch for the willingness to review this.
>>
>> My apologies for not communicating this clearly enough - Since it is
>> an pre-existing driver it is rather big.
>> I did not want to inflict a 600K patch on the mailing list so opted to
>> provide a git repo instead, as stated in the
>> email.
>
> Should this have been a [GIT PULL], then?
>
> I was confused by the [PATCH 0/4].
Yes, it should have. Sorry about that.
>
>> The patch in question is here:
>> https://github.com/gby/linux/commit/12d92e0bc19aa9bbd891cdab765eaaeabe0b6967
>>
>> Do let me know if you prefer that I will send at least the smaller
>> patch file via email in the normal fashion.
>
> Sending patches is the usual way to have things reviewed. Linking to an
> external site doesn't fit with the workflows of everyone.
>
> If you wish to have patches reviewed, please send them as patches in the
> usual fashion.
Thanks for the feedback.
I will break the driver up and post patches in the normal fashion.
>
> I will note that on the patch you linked, the compatible string is far
> too vague, per common conventions. Per your description above, that
> should be something like "arm,cryptocell-712-ree" (and each variant
> should have its own string).
Got it. Will change.
Thanks for the review even in this unconventional form :-) !
>
> I don't have documentation to hand to attempt to review the rest.
>
> I would appreciate if you could ensure that the DT binding was reviewed
> as part of the staging TODOs. That needs to follow the usual DT review
> process of sending patches to the list. Until that has occurred, it
> shouldn't be in Documentation/devicetree/.
Of course, will do.
Thanks,
Gilad
>
> Thanks,
> Mark.
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* Re: [PATCH 0/4] staging: add ccree crypto driver
From: Gilad Ben-Yossef @ 2017-04-19 14:34 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Herbert Xu, David S. Miller, Rob Herring, Mark Rutland, devel,
linux-crypto, devicetree, Linux kernel mailing list,
Gilad Ben-Yossef, Binoy Jayan, Ofir Drang
In-Reply-To: <20170418153951.GA31214@kroah.com>
On Tue, Apr 18, 2017 at 6:39 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote:
>> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
>> accelerators. It is supported by a long lived series of out of tree
>> drivers, which I am now in the process of unifying and upstreaming.
>> This is the first drop, supporting the new CryptoCell 712 REE.
>>
>> The code still needs some cleanup before maturing to a proper
>> upstream driver, which I am in the process of doing. However,
>> as discussion of some of the capabilities of the hardware and
>> its application to some dm-crypt and dm-verity features recently
>> took place I though it is better to do this in the open via the
>> staging tree.
>>
>> A Git repository based off of Linux 4.11-rc7 is available at
>> https://github.com/gby/linux.git branch ccree.
>>
>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>> CC: Binoy Jayan <binoy.jayan@linaro.org>
>> CC: Ofir Drang <ofir.drang@arm.com>
>>
>> Gilad Ben-Yossef (4):
>> staging: add ccree crypto driver
>> staging: ccree: add TODO list
>> staging: ccree: add devicetree bindings
>> MAINTAINERS: add Gilad BY as maintainer for ccree
>
> We can't do much without a real patch, sorry. Digging in random git
> trees doesn't work :(
>
> I can't take this as-is, I need patches.
Got it.
I'll break the driver to a series of patches and post them .
Thanks for the feedback.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* Re: [PATCH v6 6/8] coresight: add support for CPU debug module
From: Suzuki K Poulose @ 2017-04-19 14:32 UTC (permalink / raw)
To: Leo Yan
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Mathieu Poirier, Stephen Boyd, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA, Mike Leach, Sudeep Holla
In-Reply-To: <20170419142812.GA16160@leoy-linaro>
On 19/04/17 15:28, Leo Yan wrote:
> Hi Suzuki,
>
> On Wed, Apr 19, 2017 at 02:23:04PM +0100, Suzuki K Poulose wrote:
>> Hi Leo,
>>
>> This version looks good to me. I have two minor comments below.
>
> Thanks for reviewing. Will take the suggestions. Just check a bit for
> last comment.
>
> [...]
>
>>> +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
>>> +{
>>> + void __iomem *base;
>>> + struct device *dev = &adev->dev;
>>> + struct debug_drvdata *drvdata;
>>> + struct resource *res = &adev->res;
>>> + struct device_node *np = adev->dev.of_node;
>>> + int ret;
>>> +
>>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>>> + if (!drvdata)
>>> + return -ENOMEM;
>>> +
>>> + drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
>>> + if (per_cpu(debug_drvdata, drvdata->cpu)) {
>>> + dev_err(dev, "CPU%d drvdata has been initialized\n",
>>> + drvdata->cpu);
>>
>> May be we could warn about a possible issue in the DT ?
>
> So can I understand the suggestion is to add warning in function
> of_coresight_get_cpu() when cannot find CPU number, and here directly
> bail out?
No. One could have single CPU DT, where he doesn't need to provide the CPU number.
Hence, it doesn't make sense to WARN in of_coresight_get_cpu().
But when we hit the case above, we find that the some node was registered for
the given CPU (be it 0 or any other), which is definitely an error in DT. Due to
1) Hasn't specified the CPU number for more than one node
OR
2) CPU number duplicated in the more than one nodes.
Cheers
Suzuki
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 6/8] coresight: add support for CPU debug module
From: Leo Yan @ 2017-04-19 14:28 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Mathieu Poirier, Stephen Boyd, linux-doc, linux-kernel,
devicetree, linux-arm-kernel, linux-arm-msm, linux-soc,
Mike Leach, Sudeep Holla
In-Reply-To: <5c5cb6f8-1dcb-8a9d-1605-c006656005eb@arm.com>
Hi Suzuki,
On Wed, Apr 19, 2017 at 02:23:04PM +0100, Suzuki K Poulose wrote:
> Hi Leo,
>
> This version looks good to me. I have two minor comments below.
Thanks for reviewing. Will take the suggestions. Just check a bit for
last comment.
[...]
> >+static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> >+{
> >+ void __iomem *base;
> >+ struct device *dev = &adev->dev;
> >+ struct debug_drvdata *drvdata;
> >+ struct resource *res = &adev->res;
> >+ struct device_node *np = adev->dev.of_node;
> >+ int ret;
> >+
> >+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> >+ if (!drvdata)
> >+ return -ENOMEM;
> >+
> >+ drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> >+ if (per_cpu(debug_drvdata, drvdata->cpu)) {
> >+ dev_err(dev, "CPU%d drvdata has been initialized\n",
> >+ drvdata->cpu);
>
> May be we could warn about a possible issue in the DT ?
So can I understand the suggestion is to add warning in function
of_coresight_get_cpu() when cannot find CPU number, and here directly
bail out?
Thanks,
Leo Yan
^ permalink raw reply
* Re: [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Olof Johansson @ 2017-04-19 14:24 UTC (permalink / raw)
To: Lyra Zhang
Cc: Arnd Bergmann, arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
Catalin Marinas, Will Deacon, Mathieu Poirier,
Orson Zhai (??????),
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Chunyan Zhang
In-Reply-To: <1492603726250.cnoz1xemvxpkp3sd4toaurm2-z5hGa2qSFaSios+IgheDglaTQe2KTcn/@public.gmane.org>
Hi,
On Wed, Apr 19, 2017 at 08:09:00PM +0800, Lyra Zhang wrote:
> Hi Arnd, Olof, Could you please take this patch through arm-soc git if
> there are no further comments? (The three other patches in this series
> have been taken by Greg.) Thanks, Chunyan On
First, something bad seems to have happened with this email, the formatting
was all wrapped and it was hard to read. You might want to look into it so
you can avoid more problems like it in the future.
That being said, we can apply the patches but please re-send the series to
arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org with any acks received added, etc.
Thanks!
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3] PM / OPP: Use - instead of @ for DT entries
From: Olof Johansson @ 2017-04-19 14:22 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, arm, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Beno??t Cousson,
Tony Lindgren, Rob Herring, Mark Rutland, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Maxime Ripard, Chen-Yu Tsai,
Masahiro
In-Reply-To: <734c5d5a66ef8a5505f368fc68a8ab9c02d710f9.1492492253.git.viresh.kumar@linaro.org>
Hi Viresh,
On Tue, Apr 18, 2017 at 10:44:50AM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (uniphier)
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Tony Lindgren <tony@atomide.com>
We've already turned down other patches that does this in a sweeping manner
like this, since they tend to be conflict prone with other DT changes.
Please split per platform and merge with each maintainer.
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Sudeep Holla @ 2017-04-19 13:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: Sudeep Holla, Rafael Wysocki, ulf.hansson, Kevin Hilman,
Viresh Kumar, Nishanth Menon, Stephen Boyd, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, robh+dt, lina.iyer,
rnayak, devicetree
In-Reply-To: <20170419114740.GD5436@vireshk-i7>
On 19/04/17 12:47, Viresh Kumar wrote:
> On 18-04-17, 17:01, Sudeep Holla wrote:
>> Understood. I would incline towards reusing regulators we that's what is
>
> It can be just a regulator, but it can be anything else as well. That
> entity may have its own clock/volt/current tunables, etc.
>
Agreed.
>> changed behind the scene. Calling this operating performance point
>> is misleading and doesn't align well with existing specs/features.
>
> Yeah, but there are no voltage levels available here and that doesn't
> fit as a regulator then.
>
We can't dismiss just based on that. We do have systems where
performance index is mapped to clocks though it may not be 1:1 mapping.
I am not disagreeing here, just trying to understand it better.
>> Understood. We have exactly same thing with SCPI but it controls both
>> frequency and voltage referred as operating points. In general, this OPP
>> terminology is used in SCPI/ACPI/SCMI specifications as both frequency
>> and voltage control. I am bit worried that this binding might introduce
>> confusions on the definitions. But it can be reworded/renamed easily if
>> required.
>
> Yeah, so far we have been looking at OPPs as freq-voltage pairs ONLY
> and that is changing. I am not sure if it going in the wrong
> direction really. Without frequency also it is an operating point for
> the domain. Isn't it?
>
Yes, I completely agree. I am not saying the direction is wrong. I am
saying it's confusing and binding needs to be more clear.
On the contrary(playing devil's advocate here), we can treat all
existing regulators alone as OPP then if you strip the voltages and
treat it as abstract number. So if the firmware handles more than just
regulators, I agree. At the same time, I would have preferred firmware
to even abstract the frequency like ACPI CPPC. It would be good to get
more information on what exactly that firmware handles.
I am just more cautious here since we are designing generic bindings and
changing generic code, we need to understand what that firmware supports
and how it may evolve(so that we can maintain DT compatibility)
I did a brief check and wanted to check if this is SMD/RPM regulators ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller
From: Philipp Zabel @ 2017-04-19 13:49 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Greg Kroah-Hartman, Wolfram Sang, Rob Herring,
Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
linux-i2c, devicetree, linux-iio, linux-doc, Andrew Morton,
Colin Ian King, Paul Gortmaker, kernel
In-Reply-To: <da90526b-7274-c52c-07e8-9f0d75cf1cbf@axentia.se>
On Wed, 2017-04-19 at 14:00 +0200, Peter Rosin wrote:
[...]
> >> +int mux_control_select(struct mux_control *mux, int state)
> >
> > If we let two of these race, ...
>
> The window for this "race" is positively huge. If there are several
> mux consumers of a single mux controller, it is self-evident that
> if one of them grabs the mux for a long time, the others will suffer.
>
> The design is that the rwsem is reader-locked for the full duration
> of a select/deselect operation by the mux consumer.
I was not clear. I meant: I think this can also happen if we let them
race with the same state target.
> >> +{
> >> + int ret;
> >> +
> >> + if (down_read_trylock(&mux->lock)) {
> >> + if (mux->cached_state == state)
> >> + return 0;
This check makes it clear that a second select call is not intended to
block if the intended state is already selected. But if the instance we
will lose the race against has not yet updated cached_state, ...
> >> + /* Sigh, the mux needs updating... */
> >> + up_read(&mux->lock);
> >> + }
> >> +
> >> + /* ...or it's just contended. */
> >> + down_write(&mux->lock);
... we are blocking here until the other instance calls up_read. Even
though in this case (same state target) we would only have to block
until the other instance calls downgrade_write after the mux control is
set to the correct state.
Basically there is a small window before down_write with no lock at all,
where multiple instances can already have decided they must change the
mux (to the same state). If this happens, they go on to block each other
unnecessarily.
> > ... then the last to get to down_write will just wait here forever (or
> > until the first consumer calls mux_control_deselect, which may never
> > happen)?
>
> It is vital that the mux consumer call _deselect when it is done with
> the mux. Not doing so will surely starve out any other mux consumers.
> The whole thing is designed around the fact that mux consumers should
> deselect the mux as soon as it's no longer needed.
I'd like to use this for video bus multiplexers. Those would not be
selected for the duration of an i2c transfer, but for the duration of a
running video capture stream, or for the duration of an enabled display
path. While I currently have no use case for multiple consumers
controlling the same mux, this scenario is what shapes my perspective.
For such long running selections the consumer should have the option to
return -EBUSY instead of blocking when the lock can't be taken.
regards
Philipp
^ permalink raw reply
* [PATCH] ARM: dts: aspeed-g4: fix AHB window size of the SMC controllers
From: Cédric Le Goater @ 2017-04-19 13:43 UTC (permalink / raw)
To: Joel Stanley
Cc: Mark Rutland, devicetree, Russell King, Rob Herring,
Cédric Le Goater, linux-arm-kernel
The window of the Aspeed AST2400 SMC Controllers to map chips on the
AHB Bus has a 256MB size. The full window range is
[ 0x20000000 - 0x2FFFFFFF ] for the FMC controller
[ 0x30000000 - 0x3FFFFFFF ] for the SPI controller
This change requires CONFIG_VMSPLIT_2G to be set.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 4e3f055b365c..a7b6e04d5f1b 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -26,7 +26,7 @@
fmc: flash-controller@1e620000 {
reg = < 0x1e620000 0x94
- 0x20000000 0x02000000 >;
+ 0x20000000 0x10000000 >;
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2400-fmc";
@@ -41,7 +41,7 @@
spi: flash-controller@1e630000 {
reg = < 0x1e630000 0x18
- 0x30000000 0x02000000 >;
+ 0x30000000 0x10000000 >;
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2400-spi";
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox