* [RESEND PATCH 3/4] ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
From: Arnd Bergmann @ 2017-12-21 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171124162750.18756-3-javierm@redhat.com>
On Fri, Nov 24, 2017 at 5:27 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Applied, thanks
Arnd
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Icenowy Zheng @ 2017-12-21 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221145512.llxvzkcrjpquhczi@flea.lan>
? 2017?12?21???? CST ??10:55:12?Maxime Ripard ???
> Hi Kyle,
>
> On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> > Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> > thermal calibration data, add node to describe it.
> >
> > a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> > supported in an external driver for FreeBSD.
> >
> > Signed-off-by: Kyle Evans <kevans91@ksu.edu>
>
> The patch looks fine in itself, but we've had a number of issues with
> the register layout (and access patterns) in the past, so I'd rather
> have something that works in Linux too if possible.
I think for A83T it can just refer H3.
>
> Maxime
^ permalink raw reply
* [RESEND PATCH 1/4] ARM: dts: efm32: Add generic compatible string for I2C EEPROM
From: Arnd Bergmann @ 2017-12-21 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171124162750.18756-1-javierm@redhat.com>
On Fri, Nov 24, 2017 at 5:27 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Applied to next/dt, thanks
Arnd
^ permalink raw reply
* [PATCH 2/2] ARM: sun8i: v3s: enable EHCI/OHCI for Lichee Pi Zero
From: Icenowy Zheng @ 2017-12-21 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221150537.20304-1-icenowy@aosc.io>
As the USB port on Lichee Pi Zero works in the OTG mode, enable the
EHCI/OHCI controllers for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..cf2d9fe3bbb7 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -77,6 +77,10 @@
};
};
+&ehci0 {
+ status = "okay";
+};
+
&mmc0 {
pinctrl-0 = <&mmc0_pins_a>;
pinctrl-names = "default";
@@ -86,6 +90,10 @@
status = "okay";
};
+&ohci0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-0 = <&uart0_pins_a>;
pinctrl-names = "default";
--
2.14.2
^ permalink raw reply related
* [PATCH 1/2] ARM: sun8i: v3s: add EHCI/OHCI0 device nodes
From: Icenowy Zheng @ 2017-12-21 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221150537.20304-1-icenowy@aosc.io>
The USB PHY 0 on V3s SoC can also be routed to a pair of EHCI/OHCI
controllers.
Add the device nodes for the controllers.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 443b083c6adc..cc315dc742d2 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -264,6 +264,25 @@
#phy-cells = <1>;
};
+ ehci0: usb at 01c1a000 {
+ compatible = "allwinner,sun8i-v3s-ehci", "generic-ehci";
+ reg = <0x01c1a000 0x100>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
+ resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
+ status = "disabled";
+ };
+
+ ohci0: usb at 01c1a400 {
+ compatible = "allwinner,sun8i-v3s-ohci", "generic-ohci";
+ reg = <0x01c1a400 0x100>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
+ <&ccu CLK_USB_OHCI0>;
+ resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
+ status = "disabled";
+ };
+
ccu: clock at 1c20000 {
compatible = "allwinner,sun8i-v3s-ccu";
reg = <0x01c20000 0x400>;
--
2.14.2
^ permalink raw reply related
* [PATCH 0/2] Add EHCI/OHCI nodes for V3s and Lichee Pi Zero
From: Icenowy Zheng @ 2017-12-21 15:05 UTC (permalink / raw)
To: linux-arm-kernel
As the PHY dual-route property is added to 4.15-rc, the EHCI/OHCI nodes
are now necessary.
Please apply these patches to 4.15, Thanks!
Icenowy Zheng (2):
ARM: sun8i: v3s: add EHCI/OHCI0 device nodes
ARM: sun8i: v3s: enable EHCI/OHCI for Lichee Pi Zero
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 8 ++++++++
arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++++++++++++++++++
2 files changed, 27 insertions(+)
--
2.14.2
^ permalink raw reply
* [GIT PULL] tee async tee supplicant communication for v4.16
From: Arnd Bergmann @ 2017-12-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129102715.dsxcsq6s5tvnep2s@jax>
On Wed, Nov 29, 2017 at 11:27 AM, Jens Wiklander
<jens.wiklander@linaro.org> wrote:
> ----------------------------------------------------------------
> Enable async communication with tee supplicant
>
> This pull request enables asynchronous communication with TEE supplicant
> by introducing meta parameters in the user space API. The meta
> parameters can be used to tag requests with an id that can be matched
> against an asynchronous response as is done here in the OP-TEE driver.
>
> Asynchronous supplicant communication is needed by OP-TEE to implement
> GlobalPlatforms TEE Sockets API Specification v1.0.1. The specification
> is available at https://www.globalplatform.org/specificationsdevice.asp.
>
> This change is backwards compatible allowing older supplicants to work
> with newer kernels and vice versa.
>
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [PATCH 0/2] ARM: dts: Some am43x fixes
From: Tony Lindgren @ 2017-12-21 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215171643.8345-1-d-gerlach@ti.com>
* Dave Gerlach <d-gerlach@ti.com> [171215 09:19]:
> Hi,
> This series has two fixes for am43x based platforms. First patch disables OPP50
> on am437x-idk-evm which the board supply does not support. Second patch is for
> am43x-epos-evm and adds dcdc2 regulator as the missing cpu0-supply which
> enables CPUFreq on this platform.
Applying both into omap-for-v4.16/dt thanks.
Tony
^ permalink raw reply
* [PATCH 0/2] arm64: dts: renesas: Remove renesas,no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-21 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221112830.4ehdp237zsddfvrv@verge.net.au>
Hi Simon,
On 12/21/2017 01:28 PM, Simon Horman wrote:
> On Wed, Dec 20, 2017 at 03:22:10PM +0200, Vladimir Zapolskiy wrote:
>> The present change is a bug fix for AVB link iteratively up/down.
>
> If this is a bug please consider including Fixes tags in the patches.
>
would you prefer to get v2 with the Fixes tags added or short replies
to v1 with the requested information?
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Maxime Ripard @ 2017-12-21 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219210523.10428-1-kevans91@ksu.edu>
Hi Kyle,
On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> thermal calibration data, add node to describe it.
>
> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> supported in an external driver for FreeBSD.
>
> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
The patch looks fine in itself, but we've had a number of issues with
the register layout (and access patterns) in the past, so I'd rather
have something that works in Linux too if possible.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171221/cf6e2c93/attachment.sig>
^ permalink raw reply
* [PATCH v5 4/5] DTS: gta04: add uart2 child node for w2sg00x4
From: Tony Lindgren @ 2017-12-21 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b1c7a8319eaf61a46eebd7a366ea745b7a54634.1512114577.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [171130 23:52]:
> GTA04 has a W2SG0004/84 connected to UART2 of the OMAP3
> processor. A GPIO can pulse the on/off toggle switch.
>
> The VSIM regulator is used to power on/off the LNA of an external
> active GPS antenna so that a driver can turn the LNA off if GPS is
> not needed to save battery energy.
>
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Sounds like Greg's going to take the whole series, so for this
patch:
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..1ad744a25c36 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -477,6 +477,13 @@
> &uart2 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart2_pins>;
> +
> + gps: gps {
> + compatible = "wi2wi,w2sg0004";
> + lna-supply = <&vsim>; /* LNA regulator */
> + /* GPIO_145: trigger for on/off-impulse for w2sg0004 */
> + enable-gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>;
> + };
> };
>
> &uart3 {
> --
> 2.12.2
>
^ permalink raw reply
* [PATCH] ARM: dts: imx: Add memory node unit name
From: Marco Franchi @ 2017-12-21 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221090736.3ac9d5db@karo-electronics.de>
Hi Lothar,
2017-12-21 6:07 GMT-02:00 Lothar Wa?mann <LW@karo-electronics.de>:
> Hi,
>
> On Wed, 6 Dec 2017 13:59:49 -0200 Marco Franchi wrote:
>> Fix the following warnings from dtc by adding the unit name to memory
>> nodes:
>>
>> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>>
>> Converted using the following command:
>>
>> perl -p0777i -e 's/memory \{\n\t\treg = \<0x+([0-9a-f])/memory\@$1$\0000000 \{\n\t\treg = <0x$1/m' `find ./arch/arm/boot/dts -name "imx*"`
>>
>> The files below were manually fixed:
>> -imx1-ads.dts
>> -imx1-apf9328.dts
>>
> The imx*.dtsi files all have this:
> | memory { device_type = "memory"; reg = <0 0>; };
> Thus you will end up with a 'memory' node with a reg = <0 0> entry and
> an additional 'memory at ...' node with the correct 'reg' values.
You are right. The .dtb files were composed by two different memory nodes.
Do you have some recommendation to take off this specific warning?
>
>
> Lothar Wa?mann
Marco Franchi
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Andrew Lunn @ 2017-12-21 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdas5JJ4KHE4g=sPXag=3vQt4TS5EcZBsy=LRfw8tqcgOw@mail.gmail.com>
On Thu, Dec 21, 2017 at 01:32:21PM +0100, Linus Walleij wrote:
> On Thu, Dec 21, 2017 at 12:12 AM, Russell King
> <rmk+kernel@armlinux.org.uk> wrote:
>
> > The 88e1545 PHY has its interrupts wired to the VF610, so we might as
> > well use them.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> > This is certainly not correct, as all PHYs on this device share the
> > same interrupt line, but we can't specify the pinmux settings
> > individually on each PHY. How should this be handled?
>
> I do not know the details of the Marvell switch.
Hi Linus
The 88e1545 is a discreet quad PHY. It is connected to the switch, but
not integrated into the switch. All its interrupt handling is done
with a GPIO onto the Freescale processor, via a GPIO. There is nothing
DSA related here at all with respect to the interrupt. It is just a
normal GPIO interrupt. What is a bit odd is that it one shared
interrupt for all four PHYs.
What you described with an irqchip inside the switch is what we
actually do for the internal PHYs on Marvell devices. And it is what i
recommend for all DSA drivers. Expose standard IRQs, and let phylib
use them in its normal way.
Andrew
^ permalink raw reply
* [PATCH 1/2] thermal: mtk: Cleanup unused defines
From: Zhang Rui @ 2017-12-21 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <feb1e2bd-bee8-0950-7ecf-8e8c0e157f57@gmail.com>
On Thu, 2017-12-21 at 11:01 +0100, Matthias Brugger wrote:
>
> On 12/01/2017 11:43 AM, Matthias Brugger wrote:
> >
> > The mtk_thermal has some defiens which are never used within the
> > driver.
> > This patch delets them.
> >
> > Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> > ---
> Rui, Eduardo, do you have any comments on this patch?
>
No, I don't have any.
I suppose Eduardo will review them soon as I need the thermal soc
material for next merge window.
thanks,
rui
> Regards,
> Matthias
>
> >
> > ?drivers/thermal/mtk_thermal.c | 9 +--------
> > ?1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/drivers/thermal/mtk_thermal.c
> > b/drivers/thermal/mtk_thermal.c
> > index 1e61c09153c9..c75661a3801a 100644
> > --- a/drivers/thermal/mtk_thermal.c
> > +++ b/drivers/thermal/mtk_thermal.c
> > @@ -32,15 +32,10 @@
> > ?#include <linux/types.h>
> > ?
> > ?/* AUXADC Registers */
> > -#define AUXADC_CON0_V 0x000
> > -#define AUXADC_CON1_V 0x004
> > ?#define AUXADC_CON1_SET_V 0x008
> > ?#define AUXADC_CON1_CLR_V 0x00c
> > ?#define AUXADC_CON2_V 0x010
> > ?#define AUXADC_DATA(channel) (0x14 + (channel) * 4)
> > -#define AUXADC_MISC_V 0x094
> > -
> > -#define AUXADC_CON1_CHANNEL(x) BIT(x)
> > ?
> > ?#define APMIXED_SYS_TS_CON1 0x604
> > ?
> > @@ -158,8 +153,6 @@
> > ?/* The number of sensing points per bank */
> > ?#define MT2712_NUM_SENSORS_PER_ZONE 4
> > ?
> > -#define THERMAL_NAME????"mtk-thermal"
> > -
> > ?struct mtk_thermal;
> > ?
> > ?struct thermal_bank_cfg {
> > @@ -765,7 +758,7 @@ static struct platform_driver
> > mtk_thermal_driver = {
> > ? .probe = mtk_thermal_probe,
> > ? .remove = mtk_thermal_remove,
> > ? .driver = {
> > - .name = THERMAL_NAME,
> > + .name = "mtk-thermal",
> > ? .of_match_table = mtk_thermal_of_match,
> > ? },
> > ?};
> >
^ permalink raw reply
* [PATCH RESEND 1/1] cpufreq: imx6q: switch to Use clk_bulk_get to refine clk operations
From: Dong Aisheng @ 2017-12-21 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170914214032.GE11836@ubuntu>
Hi Rafael,
On Thu, Sep 14, 2017 at 02:40:32PM -0700, Viresh Kumar wrote:
> On 31-08-17, 19:43, Dong Aisheng wrote:
> > Use clk_bulk_get to ease the driver clocks handling.
> >
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Anson Huang <anson.huang@nxp.com>
> > Cc: Leonard Crestez <leonard.crestez@nxp.com>
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> > --
> > The original one is here which depends on clk_bulk APIs.
> > https://patchwork.kernel.org/patch/9737337/
> > Now the clk_bulk APIs are already in kernel, so resend the patch.
> > (Patch title changed a bit to be more specific.)
> > ---
> > drivers/cpufreq/imx6q-cpufreq.c | 125 ++++++++++++++++++----------------------
> > 1 file changed, 56 insertions(+), 69 deletions(-)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
Would you help pick it?
I did not see it in latest kernel.
It still applies.
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate
From: Maxime Ripard @ 2017-12-21 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221112411.21550-1-net147@gmail.com>
Hi,
On Thu, Dec 21, 2017 at 10:24:11PM +1100, Jonathan Liu wrote:
> There are several issues in sun4i_tmds_determine_rate:
> - doesn't check if the best match was already set before comparing it
> with the enumerated parameters which could result in integer divide
> by zero
> - doesn't consider rate halving when determining closest match if it
> can't match the requested rate exactly
> - sets best_div to i which corresponds to rate halving when it should be
> set to j which corresponds to the divider
>
> Fix these issues.
>
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jonathan Liu <net147@gmail.com>
Please make separate patches for each of these issues, if possible
detailing how do you reproduce them.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171221/555a6fd4/attachment.sig>
^ permalink raw reply
* [PATCH net-next v7 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
From: Kunihiko Hayashi @ 2017-12-21 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221113254.GB9930@lunn.ch>
Hello Andrew,
On Thu, 21 Dec 2017 12:32:54 +0100 Andrew Lunn <andrew@lunn.ch> wrote:
> > +Optional properties:
> > + - resets: A phandle to the reset control for the MAC
> > + - local-mac-address: See ethernet.txt in the same directory.
> > +
> > +Required subnode:
> > + - mdio: Device tree subnode with the following required properties:
> > +
> > +Example:
>
> It sounds like there should be some properties before the Example.
Indeed, this is my carelessness.
>
> Andrew
>
> > +
> > + ether: ethernet at 65000000 {
> > + compatible = "socionext,uniphier-ld20-ave4";
> > + reg = <0x65000000 0x8500>;
> > + interrupts = <0 66 4>;
> > + phy-mode = "rgmii";
> > + phy-handle = <ðphy>;
> > + clocks = <&sys_clk 6>;
> > + resets = <&sys_rst 6>;
> > + local-mac-address = [00 00 00 00 00 00];
>
> Typically you would put a blank line here, before the mdio node.
Okay, I'll put it.
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + ethphy: ethphy at 1 {
> > + reg = <1>;
> > + };
> > + };
> > + };
>
> Andrew
Thank you,
---
Best Regards,
Kunihiko Hayashi
^ permalink raw reply
* [PATCH v3 4/5] ARM: davinci: convert to common clock framework
From: Sekhar Nori @ 2017-12-21 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d7e4751-490b-5dfc-ef75-195fe41719b7@lechnology.com>
On Wednesday 20 December 2017 04:42 AM, David Lechner wrote:
> On 12/19/2017 07:47 AM, Sekhar Nori wrote:
>> Hi David,
>>
>> On Saturday 09 December 2017 07:45 AM, David Lechner wrote:
>>> This converts the clocks in mach-davinci to the common clock framework.
>>>
>>> Most of the patch just involves renaming struct clk to struct
>>> davinci_clk.
>>> There is also a struct clk_hw added to provide the bridge between the
>>> existing clock implementation and the common clock framework.
>>>
>>> The clk_get_parent and clk_set_parent callbacks are dropped because all
>>> clocks currently (effectivly) have a single parent, in which case the
>>> common clock framework does not want you to implement these functions
>>> yourself.
>>>
>>> clk_unregister() is dropped because it is not used anywhere in
>>> mach-davinci.
>>>
>>> EXPORT_SYMBOL() is removed from functions not used outside of
>>> mach-davinci.
>>>
>>> Fixed checkpatch.pl warning about bare use of unsigned in dump_clock().
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>
>> The cleanups leading upto this patch look fine, but I am not sure about
>> this patch itself. Ideally, we should have moved to drivers/clk also.
>> And shared code with keystone too since the PSC and PLL implementations
>> of the two architectures are quite similar.
>>
>> I could think of this as an intermediate step while we get there, but I
>> am afraid of the churn that would cause. For example, if we reuse
>> keystone driver, we will be using clk_psc and we can get rid of the
>> davinci_clk that this patch introduces.
>>
>> So unless there is big roadblock to moving to drivers/clk, we should
>> probably do that in one shot.
>>
>
> Yes, this is intended as an intermediate step. My thinking was that it
> would be better to do one thing at a time, so if something breaks, it
> will be easier to find the problem than if we try to do everything at
> once. But, you are right, there will be quite a few extra intermediate
> steps required, for example, I have realized that in order to use the
> davinci_clk concurrently with other clocks in the common clock
> framework, at least the parent pointer and children linked list will
> have to be removed, introducing another intermediate step.
Thats right, we have two clock lists now, one within mach-davinci and
another in drivers/clk.
> While avoiding the davinci_clk step would be ideal, there is quite a bit
> that needs to be done first before this will be possible. And the
> downside I see to doing it this way is that no one will be able to test
> any of the preparatory patches because they depend on the common clock
> framework. We won't even be able to compile them until all the pieces
> are in place and we can enable the common clock kernel configuration
> option.
Thats right, the whole conversion needs to be one big series. I dont
think we can queue just the preparatory patches without the actual
conversion as the preparation might change with the conversion.
Its a big change no doubt, we have to time it right and make sure it
gets tested in linux-next for quite a while before getting merged.
> Here is a list of some of the issues I know about so far preventing me
> from doing everything at once at this point in time:
>
> * Reentrancy of clk_enable() on non-SMP systems is broken in the common
> clock framework [1][2], but this reentrancy is needed for the DA8xx USB
> PHY PLL clock [3].
I see. I will look at those threads in detail, but looks like you have
the attention of clock framework maintainers so hopefully that will be
solved soon.
> * drivers/remoteproc/da8xx_remoteproc.c calls
> davinci_clk_reset_{assert,deassert}() in arch/arm/mach-davinci/clock.c.
> This needs to be moved to the PSC driver in drivers/clk. The reset
> framework in drivers/reset looks ideal for handling this, but it is
> currently device tree only and it looks like we need it to work on
> non-device tree boards. So, our options are: to move this hack to the
> PSC driver in drivers/clk/ *or* to update the reset framework to work
> with non-device tree boards *or* convert all of the mach-davinci boards
> to device tree only.
The second option "update the reset framework to work with non-device
tree boards" is what we should aim for. The last option is not happening
anytime soon ;)
>
> * The device tree bindings for "ti,keystone,psc-clock" are not the best
> and I am really not keen on reusing them. What makes sense to me would
> be to define a device tree node that represents the entire PSC IP block
> with child nodes for each clock output. Something like this:
>
> power-controller at 2350000 {
> ????compatible = "ti,davinci-psc";
> ????reg = <0x2350000 0xb00>;
>
> ????...
>
> ????clkhyperlink0: clkhyperlink0 {
> ??????? #clock-cells = <0>;
> ??????? clock-output-names = "hyperlink-0";
> ??????? clocks = <&chipclk12>;
> ??????? power-domain = <5>;
> ??????? module-domain = <12>;
> ????};
>
> ????...
> };
>
> But the keystone bindings assign the entire PSC register space to each
> clock individually (twice). And the really ugly part is that the module
> domain and the power domain numbers of each PSC "clock" is embedded in
> the register address. So, if you have reg = <0x02350030 0xb00>,
> <0x02350014 0x400>; what this really means is that the clock driver will
> iomap 0x02350000 (notice the 00 instead of the 30 and 14 at the end of
> each register and that the base 0x02350000 is essentially listed twice
> with two different sizes) and it means that this particular clock has a
Okay, I do see the unnecessary ioremap going on and the wasted virtual
memory space. But I dont quite see that the same base (0x02350000) is
being remapped again and again. From whatever I can see in
of_psc_clk_init(), it just maps the addresses for "control" and "domain"
provided in device tree (keystone-clocks.dtsi)
> module domain of 12 (0x30 / 4 = 12, 4 comes from the fact these are
> 32-bit registers) and a power domain of 5 (0x14 / 4 = 5). You can find
> the numbers 12 and 5 easily in the SRM, but the numbers used in the
> device tree bindings are pretty meaningless. Furthermore, the driver
> itself stores the base address in a global variable which won't work for
> DA8XX since it has two PSCs instead of one. So, for this case, I'm
Yeah, I see this issue.
> really tempted to just write a new driver with better device tree
> bindings rather than trying to fix up the keystone driver to make it
> compatible with davinci and better device tree bindings while still
> maintaining backwards compatibility with wacky device tree bindings.
I think thats fine to do as well. We can also look at reusing some code
(for example functions like psc_config() while using different
bindings). I dont see any backward compatibility need here since DA850
is a new device altogether. We cannot change existing keystone bindings,
but can definitely reuse existing keystone code where it suits while
creating new bindings.
We may decide that keeping davinci PSC code handling separate is easier
overall (considering we have to support non-device-tree-mode too, which
keystone does not). This is something that will have to be looked into
along with CCF maintainers.
> * The keystone PLL driver and device tree bindings are in better shape,
> but they cannot be used as-is with davinci family processors since the
> registers are laid out differently. I have a work-in-progress patch for
> this that I started quite a while back [4][5].
Okay, I hadnt done a detailed comparison, but from the patches you have,
it does look bad. I guess we are looking at drivers/clock/davinci here.
And we can use the analysis you have to justify it.
> * All of the keystone clock drivers are currently device tree only, so
> they will need to be modified *or* as mentioned above all mach-davinci
> boards could be converted to device tree only.
The later is not going to happen soon, so it will have to be the former.
>
> [1]: https://patchwork.kernel.org/patch/10108437/
> [2]: https://patchwork.kernel.org/patch/10115483/
> [3]: https://patchwork.kernel.org/patch/9449741/
> [4]:
> https://github.com/dlech/ev3dev-kernel/commit/5e7bf2070aa03283b605d7b86864758d24f83aa8
>
> [5]:
> https://github.com/dlech/ev3dev-kernel/commit/1e34686ff57a673c8655eaedacec4d65d48f93b3
>
>
>
> ---
>
> Also, a bit more background on my motivation here. Really, all I want is
> to be able to use the "pwm-clock" device tree bindings to supply a clock
> to a Bluetooth chip. But the driver for it requires the common clock
> framework.
Okay.
>
> This is just a spare time project for me, which is why I have just done
> the bare minimum to get CONFIG_COMMON_CLK enabled rather than trying to
> fix all of the hard problems to do thing the "right way". As you have
> seen above, there is still quite a bit of work remaining to be done,
> especially when doing this just for fun. It is probably just wishful
> thinking, but I kind of hoped that if I was able to get things this far,
> maybe some other interested parties might be able to help with one of
> the various pieces.
All I can say is that issue has been noted within TI and I believe
(hope) that help is on the way!
If we do go the completely separate clock driver route, I think even
migrating outside of mach-davinci should not be that tough.
>
> One way or another, I suppose I will get my Bluetooth clock eventually. :-)
Sure! Thanks for all your work on this platform so far!
Regards,
Sekhar
^ permalink raw reply
* [PATCH 4/4] ARM: dts: vf610-zii-dev-rev-b: add interrupts for 88e1545 PHY
From: Linus Walleij @ 2017-12-21 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eRnWr-0006VS-1m@rmk-PC.armlinux.org.uk>
On Thu, Dec 21, 2017 at 12:12 AM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> The 88e1545 PHY has its interrupts wired to the VF610, so we might as
> well use them.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> This is certainly not correct, as all PHYs on this device share the
> same interrupt line, but we can't specify the pinmux settings
> individually on each PHY. How should this be handled?
I do not know the details of the Marvell switch.
Sorry for any possible misunderstandings below.
What I did with the Realtek switch I was playing around
with was to create a separate irqchip, also in the device tree,
embedded inside the DSA switch, then referenced the
IRQs from that chip as 0, 1 .. n.
The patches are here:
DTS:
https://marc.info/?l=linux-netdev&m=150992420713391&w=2
Driver:
https://marc.info/?l=linux-netdev&m=150992421113393&w=2
Note that this RFC is wrong: it assigns the IRQs to ports
instead of PHYs, but the idea with an IRQchip inside the
DSA is pretty solid IMO. (I will rewrite it using your method
of a separate mdio bus node and phy-handle references.)
Anyway I was inspired to this model from certain PCI bridges that
contain an IRQ demuxer and thus instantiate an irqchip for
this, that is then part of the bridge itself.
Then for the pin control, I guess the irqchip inside the bridge
should be the entity taking the IRQ from the GPIO-backed
irq controller and also the pin control handle. As pin control
handles are tied to Linux devices, that requires it
to be a device proper though. I don't know if it's possible
to properly spawn a device for this irqchip from the switch,
but I guess it is what I would try.
I hope this helps.
Yours,
Linus Walleij
^ permalink raw reply
* Applied "spi: pxa2xx: avoid redundant gpio_to_desc(desc_to_gpio()) round-trip" to the spi tree
From: Mark Brown @ 2017-12-21 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221003731.21633-1-linux@rasmusvillemoes.dk>
The patch
spi: pxa2xx: avoid redundant gpio_to_desc(desc_to_gpio()) round-trip
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 221886646f75964ca31cf60f1811b2c9c4e965a5 Mon Sep 17 00:00:00 2001
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Thu, 21 Dec 2017 01:37:31 +0100
Subject: [PATCH] spi: pxa2xx: avoid redundant gpio_to_desc(desc_to_gpio())
round-trip
gpio_free(gpio) simply does gpiod_free(gpio_to_desc(gpio)), so it's
simpler and cleaner to use gpiod_free directly.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-pxa2xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4cb515a3104c..c209dc1047b5 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1237,7 +1237,7 @@ static int setup_cs(struct spi_device *spi, struct chip_data *chip,
* different chip_info, release previously requested GPIO
*/
if (chip->gpiod_cs) {
- gpio_free(desc_to_gpio(chip->gpiod_cs));
+ gpiod_free(chip->gpiod_cs);
chip->gpiod_cs = NULL;
}
@@ -1417,7 +1417,7 @@ static void cleanup(struct spi_device *spi)
if (drv_data->ssp_type != CE4100_SSP && !drv_data->cs_gpiods &&
chip->gpiod_cs)
- gpio_free(desc_to_gpio(chip->gpiod_cs));
+ gpiod_free(chip->gpiod_cs);
kfree(chip);
}
--
2.15.0
^ permalink raw reply related
* [PATCH 2/2] mmc: sunxi: Add runtime_pm support
From: Ulf Hansson @ 2017-12-21 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <412579f183c42f6fe2ea04f294dfb788be5e4875.1513766964.git-series.maxime.ripard@free-electrons.com>
On 20 December 2017 at 11:50, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> So far, even if our card was not in use, we didn't shut down our main
> clock, which meant that it was still output on the MMC bus.
>
> While this obviously means that we could save some power there, it also
> created issues when it comes with EMC control since we'll have a perfect
> peak at the card clock rate.
>
> Let's implement runtime_pm with autosuspend so that we will shut down the
> clock when it's not been in use for quite some time.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/mmc/host/sunxi-mmc.c | 90 ++++++++++++++++++++++++-------------
> 1 file changed, 60 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 3ce46ebd3488..c6a0bd0e0476 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -35,6 +35,7 @@
> #include <linux/of_gpio.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> #include <linux/regulator/consumer.h>
> #include <linux/reset.h>
> #include <linux/scatterlist.h>
> @@ -1217,29 +1218,11 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
> return ret;
> }
>
> - ret = clk_prepare_enable(host->clk_mmc);
> - if (ret) {
> - dev_err(&pdev->dev, "Enable mmc clk err %d\n", ret);
> - goto error_disable_clk_ahb;
> - }
> -
> - ret = clk_prepare_enable(host->clk_output);
> - if (ret) {
> - dev_err(&pdev->dev, "Enable output clk err %d\n", ret);
> - goto error_disable_clk_mmc;
> - }
> -
> - ret = clk_prepare_enable(host->clk_sample);
> - if (ret) {
> - dev_err(&pdev->dev, "Enable sample clk err %d\n", ret);
> - goto error_disable_clk_output;
> - }
> -
Actually, I think you should keep all the above. Perhaps you may want
to move it to a separate helper function though, which the
->runtime_resume() callbacks can invoke as well.
More reasons to why, see the comment in the ->probe() function.
> if (!IS_ERR(host->reset)) {
> ret = reset_control_reset(host->reset);
> if (ret) {
> dev_err(&pdev->dev, "reset err %d\n", ret);
> - goto error_disable_clk_sample;
> + goto error_disable_clk_ahb;
> }
> }
>
> @@ -1258,12 +1241,6 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
> error_assert_reset:
> if (!IS_ERR(host->reset))
> reset_control_assert(host->reset);
> -error_disable_clk_sample:
> - clk_disable_unprepare(host->clk_sample);
> -error_disable_clk_output:
> - clk_disable_unprepare(host->clk_output);
> -error_disable_clk_mmc:
> - clk_disable_unprepare(host->clk_mmc);
> error_disable_clk_ahb:
> clk_disable_unprepare(host->clk_ahb);
> return ret;
> @@ -1280,6 +1257,7 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "mmc alloc host failed\n");
> return -ENOMEM;
> }
> + platform_set_drvdata(pdev, mmc);
>
> host = mmc_priv(mmc);
> host->mmc = mmc;
> @@ -1340,12 +1318,16 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
> if (ret)
> goto error_free_dma;
>
> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> + pm_runtime_use_autosuspend(&pdev->dev);
> + pm_runtime_enable(&pdev->dev);
> +
This means in case you don't have CONFIG_PM set when compiling this
driver, the clocks will never be enabled using runtime PM.
I think it's good practice to deal with this, therefore I think you
should enable the clocks as before, and instead indicate that the
device is already runtime resumed.
In other words, before you call pm_runtime_enable(), invoke
pm_runtime_set_active().
> ret = mmc_add_host(mmc);
> if (ret)
> goto error_free_dma;
>
> dev_info(&pdev->dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
> - platform_set_drvdata(pdev, mmc);
> +
> return 0;
>
> error_free_dma:
> @@ -1361,27 +1343,75 @@ static int sunxi_mmc_remove(struct platform_device *pdev)
> struct sunxi_mmc_host *host = mmc_priv(mmc);
>
> mmc_remove_host(mmc);
> + pm_runtime_force_suspend(&pdev->dev);
Do you need the clocks to be enabled, while calling disable_irq() and
sunxi_mmc_reset_host()?
In such case you need to call pm_runtime_get_sync() here. Then move
pm_runtime_force_suspend() a few lines below, and later call
pm_runtime_put_noidle().
> disable_irq(host->irq);
> sunxi_mmc_reset_host(host);
>
> if (!IS_ERR(host->reset))
> reset_control_assert(host->reset);
>
> - clk_disable_unprepare(host->clk_sample);
> + dma_free_coherent(&pdev->dev, PAGE_SIZE, host->sg_cpu, host->sg_dma);
> + mmc_free_host(mmc);
> +
> + return 0;
> +}
> +
> +static int sunxi_mmc_runtime_resume(struct device *dev)
> +{
> + struct mmc_host *mmc = dev_get_drvdata(dev);
> + struct sunxi_mmc_host *host = mmc_priv(mmc);
> + int ret;
> +
> + ret = clk_prepare_enable(host->clk_mmc);
> + if (ret) {
> + dev_err(dev, "Enable mmc clk err %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(host->clk_output);
> + if (ret) {
> + dev_err(dev, "Enable output clk err %d\n", ret);
> + goto error_disable_clk_mmc;
> + }
> +
> + ret = clk_prepare_enable(host->clk_sample);
> + if (ret) {
> + dev_err(dev, "Enable sample clk err %d\n", ret);
> + goto error_disable_clk_output;
> + }
> +
> + return 0;
> +
> +error_disable_clk_output:
> clk_disable_unprepare(host->clk_output);
> +error_disable_clk_mmc:
> clk_disable_unprepare(host->clk_mmc);
> - clk_disable_unprepare(host->clk_ahb);
> + return ret;
> +}
>
> - dma_free_coherent(&pdev->dev, PAGE_SIZE, host->sg_cpu, host->sg_dma);
> - mmc_free_host(mmc);
> +static int sunxi_mmc_runtime_suspend(struct device *dev)
> +{
> + struct mmc_host *mmc = dev_get_drvdata(dev);
> + struct sunxi_mmc_host *host = mmc_priv(mmc);
> +
> + clk_disable_unprepare(host->clk_sample);
> + clk_disable_unprepare(host->clk_output);
> + clk_disable_unprepare(host->clk_mmc);
>
> return 0;
> }
>
> +static const struct dev_pm_ops sunxi_mmc_pm_ops = {
> + SET_RUNTIME_PM_OPS(sunxi_mmc_runtime_suspend,
> + sunxi_mmc_runtime_resume,
> + NULL)
> +};
> +
> static struct platform_driver sunxi_mmc_driver = {
> .driver = {
> .name = "sunxi-mmc",
> .of_match_table = of_match_ptr(sunxi_mmc_of_match),
> + .pm = &sunxi_mmc_pm_ops,
> },
> .probe = sunxi_mmc_probe,
> .remove = sunxi_mmc_remove,
> --
> git-series 0.9.1
Otherwise this looks good to me!
BTW, isn't system wide suspend/resume() also important to save power
for? That's rather simple to implement, after you have enabled runtime
PM support.
Kind regards
Uffe
^ permalink raw reply
* [PATCH 3/4] ARM: dts: vf610-zii-dev-rev-b: add PHYs for switch2
From: Linus Walleij @ 2017-12-21 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1eRnWl-0006VL-TL@rmk-PC.armlinux.org.uk>
On Thu, Dec 21, 2017 at 12:11 AM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Switch 2 has an 88e1545 PHY behind it, which is a quad PHY. Only the
> first three PHYs are used, the remaining PHY is unused. When we wire
> up the SFF sockets in a later commit, the omission of this causes the
> fourth PHY to be used for port 3. Specifying the PHYs in DT avoids
> the auto-probing of the bus, and discovery of this PHY.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Ah this is elegant and what Andrew requested me to do for
another switch as well. Makes perfect sense. FWIW:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/3] [v11] pinctrl: qcom: add support for sparse GPIOs
From: Linus Walleij @ 2017-12-21 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513797033-9494-1-git-send-email-timur@codeaurora.org>
Hi Timur,
thank you for your perseverance. I am sorry that I am sometimes not
fast to respond :(
On Wed, Dec 20, 2017 at 8:10 PM, Timur Tabi <timur@codeaurora.org> wrote:
> Patch 1 reverts an old patch that triggers a get_direction of every
> pin upon init, without attempting to request the pins first. The
> direction is already being queried when the pin is requested.
>
> Patch 2 adds support to pinctrl-msm for "unavailable" GPIOs.
I have applied both of these to the pinctrl "devel" branch so we
can see if all is fine.
They have Stephen's ACK so I am happy with them, I am just
still slightly worried about possible regressions because of
patch 1.
> Patch 3 extends that support to pinctrl-qdf2xxx. A recent ACPI change
> on QDF2400 platforms blocks access to most pins, so the driver can only
> register a subset.
I see this one is still under discussion.
If nothing drastic happens with patch 1/2 in linux-next
it should be fine if you just resend this single patch in subsequent
submissions.
I think it may be worthwhile to keep Andrew Cooks in the loop for
future submissions as he's trying to solve similar problems for
AMD.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] of: usb: Fix definition of of_usb_get_dr_mode_by_phy
From: Suzuki K Poulose @ 2017-12-21 12:06 UTC (permalink / raw)
To: linux-arm-kernel
Declaration of of_usb_get_dr_mode_by_phy only depends on CONFIG_OF
and not on CONFIG_USB_SUPPORT, which actually defines it. This can
break the build like below, if USB_SUPPORT is not selected :
drivers/phy/renesas/phy-rcar-gen3-usb2.o: In function `rcar_gen3_phy_usb2_probe':
drivers/phy/renesas/phy-rcar-gen3-usb2.c:444: undefined reference to `of_usb_get_dr_mode_by_phy'
drivers/phy/renesas/phy-rcar-gen3-usb2.c:444:(.text+0x2d4): relocation
truncated to fit: R_AARCH64_CALL26 against undefined symbol `of_usb_get_dr_mode_by_phy'
drivers/phy/renesas/phy-rcar-gen3-usb2.c:444: undefined reference to `of_usb_get_dr_mode_by_phy'
drivers/phy/renesas/phy-rcar-gen3-usb2.c:444:(.text+0x3bc): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `of_usb_get_dr_mode_by_phy'
make: *** [Makefile:993: vmlinux] Error 1
Fixes: commit 98bfb39466954c69d2 ("usb: of: add an api to get dr_mode by the phy node")
Cc: linux-renesas-soc at vger.kernel.org
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb at vger.kernel.org
Cc: Bin Liu <b-liu@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
include/linux/usb/of.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index 6cbe7a5c2b57..181245e5fe36 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -13,7 +13,6 @@
#include <linux/usb/phy.h>
#if IS_ENABLED(CONFIG_OF)
-enum usb_dr_mode of_usb_get_dr_mode_by_phy(struct device_node *np, int arg0);
bool of_usb_host_tpl_support(struct device_node *np);
int of_usb_update_otg_caps(struct device_node *np,
struct usb_otg_caps *otg_caps);
@@ -21,11 +20,6 @@ struct device_node *usb_of_get_child_node(struct device_node *parent,
int portnum);
struct device *usb_of_get_companion_dev(struct device *dev);
#else
-static inline enum usb_dr_mode
-of_usb_get_dr_mode_by_phy(struct device_node *np, int arg0)
-{
- return USB_DR_MODE_UNKNOWN;
-}
static inline bool of_usb_host_tpl_support(struct device_node *np)
{
return false;
@@ -48,7 +42,13 @@ static inline struct device *usb_of_get_companion_dev(struct device *dev)
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
+enum usb_dr_mode of_usb_get_dr_mode_by_phy(struct device_node *np, int arg0);
#else
+static inline enum usb_dr_mode
+of_usb_get_dr_mode_by_phy(struct device_node *np, int arg0)
+{
+ return USB_DR_MODE_UNKNOWN;
+}
static inline enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
{
return USBPHY_INTERFACE_MODE_UNKNOWN;
--
2.13.6
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-21 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221103440.GJ28046@linaro.org>
Hello Akashi,
On Thu, Dec 21, 2017 at 4:04 PM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> Bhupesh,
>
> Can you test the patch attached below, please?
>
> It is intended to retain already-reserved regions (ACPI reclaim memory
> in this case) in system ram (i.e. memblock.memory) without explicitly
> exporting them via usable-memory-range.
> (I still have to figure out what the side-effect of this patch is.)
>
> Thanks,
> -Takahiro AKASHI
>
> On Thu, Dec 21, 2017 at 01:30:43AM +0530, Bhupesh Sharma wrote:
>> On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>> > On 19 December 2017 at 07:09, AKASHI Takahiro
>> > <takahiro.akashi@linaro.org> wrote:
>> >> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
>> >>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
>> >>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>> >>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
>> >>> > > <takahiro.akashi@linaro.org> wrote:
>> >>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>> >>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
>> >>> > > >> <takahiro.akashi@linaro.org> wrote:
>> >>> > > >> > Bhupesh, Ard,
>> >>> > > >> >
>> >>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>> >>> > > >> >> Hi Ard, Akashi
>> >>> > > >> >>
>> >>> > > >> > (snip)
>> >>> > > >> >
>> >>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>> >>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>> >>> > > >> >> identify its own usable memory and exclude, at its boot time, any
>> >>> > > >> >> other memory areas that are part of the panicked kernel's memory.
>> >>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>> >>> > > >> >> , for details)
>> >>> > > >> >
>> >>> > > >> > Right.
>> >>> > > >> >
>> >>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>> >>> > > >> >> with the crashkernel memory range:
>> >>> > > >> >>
>> >>> > > >> >> /* add linux,usable-memory-range */
>> >>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>> >>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>> >>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>> >>> > > >> >> address_cells, size_cells);
>> >>> > > >> >>
>> >>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>> >>> > > >> >> , for details)
>> >>> > > >> >>
>> >>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>> >>> > > >> >> they are marked as System RAM or as RESERVED. As,
>> >>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
>> >>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>> >>> > > >> >>
>> >>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
>> >>> > > >> >> ACPI memory and crashes while trying to access the same:
>> >>> > > >> >>
>> >>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>> >>> > > >> >> -r`.img --reuse-cmdline -d
>> >>> > > >> >>
>> >>> > > >> >> [snip..]
>> >>> > > >> >>
>> >>> > > >> >> Reserved memory range
>> >>> > > >> >> 000000000e800000-000000002e7fffff (0)
>> >>> > > >> >>
>> >>> > > >> >> Coredump memory ranges
>> >>> > > >> >> 0000000000000000-000000000e7fffff (0)
>> >>> > > >> >> 000000002e800000-000000003961ffff (0)
>> >>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
>> >>> > > >> >> 000000003ed60000-000000003fbfffff (0)
>> >>> > > >> >> 0000001040000000-0000001ffbffffff (0)
>> >>> > > >> >> 0000002000000000-0000002ffbffffff (0)
>> >>> > > >> >> 0000009000000000-0000009ffbffffff (0)
>> >>> > > >> >> 000000a000000000-000000affbffffff (0)
>> >>> > > >> >>
>> >>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>> >>> > > >> >> memory cap'ing passed to the crash kernel inside
>> >>> > > >> >> 'arch/arm64/mm/init.c' (see below):
>> >>> > > >> >>
>> >>> > > >> >> static void __init fdt_enforce_memory_region(void)
>> >>> > > >> >> {
>> >>> > > >> >> struct memblock_region reg = {
>> >>> > > >> >> .size = 0,
>> >>> > > >> >> };
>> >>> > > >> >>
>> >>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>> >>> > > >> >>
>> >>> > > >> >> if (reg.size)
>> >>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>> >>> > > >> >> comment this out */
>> >>> > > >> >> }
>> >>> > > >> >
>> >>> > > >> > Please just don't do that. It can cause a fatal damage on
>> >>> > > >> > memory contents of the *crashed* kernel.
>> >>> > > >> >
>> >>> > > >> >> 5). Both the above temporary solutions fix the problem.
>> >>> > > >> >>
>> >>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
>> >>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>> >>> > > >> >> fail.
>> >>> > > >> >>
>> >>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>> >>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>> >>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>> >>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>> >>> > > >> >> dt node 'linux,usable-memory-range'
>> >>> > > >> >
>> >>> > > >> > I still don't understand why we need to carry over the information
>> >>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>> >>> > > >> > such regions are free to be reused by the kernel after some point of
>> >>> > > >> > initialization. Why does crash dump kernel need to know about them?
>> >>> > > >> >
>> >>> > > >>
>> >>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
>> >>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>> >>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
>> >>> > > >> kernel, those regions needs to be preserved, which is why they are
>> >>> > > >> memblock_reserve()'d now.
>> >>> > > >
>> >>> > > > For my better understandings, who is actually accessing such regions
>> >>> > > > during boot time, uefi itself or efistub?
>> >>> > > >
>> >>> > >
>> >>> > > No, only the kernel. This is where the ACPI tables are stored. For
>> >>> > > instance, on QEMU we have
>> >>> > >
>> >>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>> >>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>> >>> > > 01000013)
>> >>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>> >>> > > BXPC 00000001)
>> >>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>> >>> > > BXPC 00000001)
>> >>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>> >>> > > BXPC 00000001)
>> >>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>> >>> > > BXPC 00000001)
>> >>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>> >>> > > BXPC 00000001)
>> >>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>> >>> > > BXPC 00000001)
>> >>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>> >>> > > BXPC 00000001)
>> >>> > >
>> >>> > > covered by
>> >>> > >
>> >>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>> >>> > > ...
>> >>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>> >>> >
>> >>> > OK. I mistakenly understood those regions could be freed after exiting
>> >>> > UEFI boot services.
>> >>> >
>> >>> > >
>> >>> > > >> So it seems that kexec does not honour the memblock_reserve() table
>> >>> > > >> when booting the next kernel.
>> >>> > > >
>> >>> > > > not really.
>> >>> > > >
>> >>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
>> >>> > > >> > on crash dump kernel?)
>> >>> > > >> >
>> >>> > > >>
>> >>> > > >> I don't think so. And the change to the handling of ACPI reclaim
>> >>> > > >> regions only revealed the bug, not created it (given that other
>> >>> > > >> memblock_reserve regions may be affected as well)
>> >>> > > >
>> >>> > > > As whether we should honor such reserved regions over kexec'ing
>> >>> > > > depends on each one's specific nature, we will have to take care one-by-one.
>> >>> > > > As a matter of fact, no information about "reserved" memblocks is
>> >>> > > > exposed to user space (via proc/iomem).
>> >>> > > >
>> >>> > >
>> >>> > > That is why I suggested (somewhere in this thread?) to not expose them
>> >>> > > as 'System RAM'. Do you think that could solve this?
>> >>> >
>> >>> > Memblock-reserv'ing them is necessary to prevent their corruption and
>> >>> > marking them under another name in /proc/iomem would also be good in order
>> >>> > not to allocate them as part of crash kernel's memory.
>> >>> >
>> >>> > But I'm not still convinced that we should export them in useable-
>> >>> > memory-range to crash dump kernel. They will be accessed through
>> >>> > acpi_os_map_memory() and so won't be required to be part of system ram
>> >>> > (or memblocks), I guess.
>> >>> > -> Bhupesh?
>> >>>
>> >>> I forgot how arm64 kernel retrieve the memory ranges and initialize
>> >>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
>> >>> the memory according to the efi memmap? For kdump kernel anything other
>> >>> than usable memory (which is from the dt node instead) should be
>> >>> reinitialized according to efi passed info, no?
>> >>
>> >> All the regions exported in efi memmap will be added to memblock.memory
>> >> in (u)efi_init() and then trimmed down to the exact range specified as
>> >> usable-memory-range by fdt_enforce_memory_region().
>> >>
>> >> Now I noticed that the current fdt_enforce_memory_region() may not work well
>> >> with multiple entries in usable-memory-range.
>> >>
>> >
>> > In any case, the root of the problem is that memory regions lose their
>> > 'memory' annotation due to the way the memory map is mangled before
>> > being supplied to the kexec kernel.
>> >
>> > Would it be possible to classify all memory that we want to hide from
>> > the kexec kernel as NOMAP instead? That way, it will not be mapped
>> > implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
>> > so this seems to be the most appropriate way to deal with the host
>> > kernel's memory contents.
>>
>> Hmm. wouldn't appending the acpi reclaim regions to
>> 'linux,usable-memory-range' in the dtb being passed to the crashkernel
>> be better? Because its indirectly achieving a similar objective
>> (although may be a subset of all System RAM regions on the primary
>> kernel's memory).
>>
>> I am not aware of the background about the current kexec-tools
>> implementation where we add only the crashkernel range to the dtb
>> being passed to the crashkernel.
>>
>> Probably Akashi can answer better, as to how we arrived at this design
>> approach and why we didn't want to expose all System RAM regions (i.e.
>> ! NOMPAP regions) to the crashkernel.
>>
>> I am suspecting that some issues were seen/meet when the System RAM (!
>> NOMAP regions) were exposed to the crashkernel, and that's why we
>> finalized on this design approach, but this is something which is just
>> my guess.
>>
>> Regards,
>> Bhupesh
>>
>> >>> >
>> >>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> >>> > via a kernel command line parameter, "memmap=".
>> >>>
>> >>> memmap= is only used in old kexec-tools, now we are passing them via
>> >>> e820 table.
>> >>
>> >> Thanks. I remember that you have explained it before.
>> >>
>> >> -Takahiro AKASHI
>> >>
>> >>> [snip]
>> >>>
>> >>> Thanks
>> >>> Dave
>
> ===8<==
> From 74e2451fea83d546feae76160ba7de426913fe03 Mon Sep 17 00:00:00 2001
> From: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Date: Thu, 21 Dec 2017 19:14:23 +0900
> Subject: [PATCH] arm64: kdump: mark unusable memory as NOMAP
>
> ---
> arch/arm64/mm/init.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 00e7b900ca41..8175db94257b 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -352,11 +352,17 @@ static void __init fdt_enforce_memory_region(void)
> struct memblock_region reg = {
> .size = 0,
> };
> + u64 idx;
> + phys_addr_t start, end;
>
> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>
> - if (reg.size)
> - memblock_cap_memory_range(reg.base, reg.size);
> + if (reg.size) {
> + for_each_free_mem_range(idx, NUMA_NO_NODE, MEMBLOCK_NONE,
> + &start, &end, NULL)
> + memblock_mark_nomap(start, end - start);
> + memblock_clear_nomap(reg.base, reg.size);
> + }
> }
>
> void __init arm64_memblock_init(void)
> --
> 2.15.1
>
Thanks for the patch. After applying this on top of
4.15.0-rc4-next-20171220, there seems to be a improvement and the
crashkernel boot no longer hangs while trying to access the acpi
tables.
However I notice a minor issue. Please see the log below for
reference, the following message keeps spamming the console but I see
the crashkernel boot proceed further.:
[ 0.000000] ACPI: NUMA: SRAT: PXM 3 -> MPIDR 0x70303 -> Node 3
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x3fffffff]
[ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x2000000000-0x2fffffffff]
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x1000000000-0x1fffffffff]
[ 0.000000] ACPI: SRAT: Node 3 PXM 3 [mem 0xa000000000-0xafffffffff]
[ 0.000000] ACPI: SRAT: Node 2 PXM 2 [mem 0x9000000000-0x9fffffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffe200-0x1ffbffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffc400-0x1ffbffe1ff]
[ 0.000000] NUMA: NODE_DATA(1) on node 0
[ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffa600-0x1ffbffc3ff]
[ 0.000000] NUMA: NODE_DATA(2) on node 0
[ 0.000000] NUMA: NODE_DATA [mem 0x1ffbff8800-0x1ffbffa5ff]
[ 0.000000] NUMA: NODE_DATA(3) on node 0
[ 0.000000] [ffff7fe008000000-ffff7fe00800ffff] potential offnode
page_structs
[ 0.000000] [ffff7fe008010000-ffff7fe00801ffff] potential offnode
page_structs
[ 0.000000] [ffff7fe008020000-ffff7fe00802ffff] potential offnode
page_structs
[ 0.000000] [ffff7fe008030000-ffff7fe00803ffff] potential offnode
page_structs
[ 0.000000] [ffff7fe008040000-ffff7fe00804ffff] potential offnode
page_structs
[ 0.000000] [ffff7fe008050000-ffff7fe00805ffff] potential offnode
page_structs
[snip..]
[ 0.000000] [ffff7fe0081f0000-ffff7fe0081fffff] potential offnode
page_structs
This WARNING message seems to come from vmemmap_verify() inside
'mm/sparse-vmemmap.c'
Regards,
Bhupesh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox