* Re: [PATCH] PM / Domains: Fix DT example
From: Ulf Hansson @ 2017-04-25 8:01 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, Kevin Hilman, linaro-kernel,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Vincent Guittot, devicetree@vger.kernel.org
In-Reply-To: <533b52e0ea175bf6bb893370c7f8c0309aae235a.1493104411.git.viresh.kumar@linaro.org>
On 25 April 2017 at 09:18, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> The power-domain provider's #power-domain-cells field is set to 0 and
> yet the children is using an index to point the power domain. Fix it by
> removing the index field.
>
> Fixes: 70bb510e4279 ("dt/bindings / PM/Domains: Update binding for PM domain idle states")
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/power/power_domain.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 940707d095cc..14bd9e945ff6 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -81,7 +81,7 @@ domain provided by the 'parent' power controller.
> child: power-controller@12341000 {
> compatible = "foo,power-controller";
> reg = <0x12341000 0x1000>;
> - power-domains = <&parent 0>;
> + power-domains = <&parent>;
> #power-domain-cells = <0>;
> domain-idle-states = <&DOMAIN_PWR_DN>;
> };
> --
> 2.12.0.432.g71c3a4f4ba37
>
^ permalink raw reply
* Re: [PATCH v7 4/5] i2c: aspeed: added driver for Aspeed I2C
From: Brendan Higgins @ 2017-04-25 8:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Joel Stanley, Vladimir Zapolskiy,
Kachalov Anton, Cédric Le Goater, linux-i2c, devicetree,
Linux Kernel Mailing List, OpenBMC Maillist, Ryan Chen
In-Reply-To: <1493086864.25766.266.camel@kernel.crashing.org>
Adding Ryan to thread.
>> +static int __aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus,
>> + struct platform_device *pdev)
>> +{
>
> Minor nit ... I'm really not fan of those underscores.
>
> We use __ functions in some cases in the kernel for low level
> helpers, usually when it's a low level variant of an existing
> function or an "unlocked" variant, but I don't think generalizing
> it to pretty much everything in the driver is worthwhile here.
>
> If you want to be explicit about locking, I would suggest you
> use a comment in front of the function explaining if it
> expects to be called with the lock held.
>
> We tend to only do that when *both* functions exist and one is
> implemented in term of the other.
Okay, I guess that makes sense. Sorry, I thought the "unlocked"
variant might refer to a function that you have to pay close attention
to the context in which it is called; with as many functions as I have
that require the lock to be held, I would like there to be some way to
say the function is "unsafe," but I guess if there is no convention to
do that, then there is no convention to do that.
^ permalink raw reply
* Re: [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Lee Jones @ 2017-04-25 7:57 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Thomas Gleixner, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
Liam Girdwood, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170424160103.9447-8-icenowy-h8G6r0blFSE@public.gmane.org>
On Tue, 25 Apr 2017, Icenowy Zheng wrote:
> As axp20x-regulator now supports AXP803, add a cell for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> Changes in v4:
> - Added a trailing comma for new cell, for easier further cell addition.
> Changes in v3:
> - Make the new cell one-liner.
>
> drivers/mfd/axp20x.c | 3 ++-
> drivers/regulator/axp20x-regulator.c | 6 +++---
These 2 changes are orthogonal, thus there is no reason to send them
bundled into a single patch. Doing so complicates things greatly.
Please resubmit the two changes separately, so that they may be
absorbed by our respective subsystems.
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 1dc6235778eb..917b6ddc4f15 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
> .name = "axp20x-pek",
> .num_resources = ARRAY_SIZE(axp803_pek_resources),
> .resources = axp803_pek_resources,
> - }
> + },
> + { .name = "axp20x-regulator" },
> };
>
> static struct mfd_cell axp806_cells[] = {
> diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
> index 9356ec8a9a1f..e2608fe770b9 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -311,13 +311,13 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
> AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
> AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
> - AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
> + AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
> AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> - AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
> + AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
> AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
> AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> - AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
> + AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
> };
>
> static const struct regulator_linear_range axp806_dcdca_ranges[] = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 RFC 0/5] *** SPI Slave mode support ***
From: Jiada Wang @ 2017-04-25 7:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAMuHMdVQS494-BAc-W-XOOLK8Xow85n+Cgih0FG+t4QxCFxhMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert
On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote:
> Hi Jiada,
>
> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote:
>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
>>>> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>>>>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org wrote:
>>>>>>> From: Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>>>>>>>
>>>>>>> v1:
>>>>>>> add Slave mode support in SPI core
>>>>>>> spidev create slave device when SPI controller work in slave mode
>>>>>>> spi-imx support to work in slave mode
>>>>>> Adding Geert who also had a series doing this in progress that was
>>>>>> getting very near to being merged.
>>>>> Thank you!
>>>>>
>>>>> Actually my plan is to fix the last remaining issues and resubmit for
>>>>> v4.13.
>>>> I noticed your patch set for SPI slave support,
>>>> (I am sure you can find out some of the change
>>>> in this patch set is based on your work).
>>>> we have similar requirement to add slave mode support to ecspi IP on imx6
>>>> Soc.
>>>>
>>>> Our use case is to use spidev as an interface to communicate with
>>>> external
>>>> SPI master devices.
>>>> meanwhile the SPI bus controller can also act as master device to send
>>>> data
>>>> to other
>>>> SPI slave devices on the board.
>>> That sounds a bit hackish to me. SPI was never meant to be a multi-master
>>> bus.
>>> While it can be done, you will need external synchronization (signals) to
>>> avoid conflicts between the SPI masters.
>> It doesn't need to be a multi-master bus,
>> for example A is master device for slave device B.
>> while B has its own slave device C
>> for each SPI connection A<=> B, and B<=> C, there is only one master
>> device.
>>
>> and I think from use case point of view, it's very normal,
>> one CPU upon receives command from external SPI master device,
>> it writes data to its own slave device (EEPROM) connected to it.
> So "A<=> B" and "B<=> C" are two distinct SPI buses?
> Or do they share some signals?
>
> Your comment seems to suggest otherwise:
the use case of
"A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and
MOSI lines,
but there is no SS line between A and C. so for each SPI slave device,
there is only one
master device.
so I think the question becomes whether the above mentioned hardware
setup is valid or not.
Thanks,
Jiada
>>>> I found in your implementation, SPI bus controller is limited to either work in master mode or
>>>> slave mode, is there any reasoning to not configure SPI mode based on SPI devices use case?
> If they are distinct, it should work. Then B has two SPI controllers: one slave
> controller controlled by A, and one master controller to control C.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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
* [PATCH] PM / Domains: Fix DT example
From: Viresh Kumar @ 2017-04-25 7:18 UTC (permalink / raw)
To: Rafael Wysocki, Kevin Hilman, Ulf Hansson
Cc: linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
Viresh Kumar, devicetree-u79uwXL29TY76Z2rM5mHXA
The power-domain provider's #power-domain-cells field is set to 0 and
yet the children is using an index to point the power domain. Fix it by
removing the index field.
Fixes: 70bb510e4279 ("dt/bindings / PM/Domains: Update binding for PM domain idle states")
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/power/power_domain.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 940707d095cc..14bd9e945ff6 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -81,7 +81,7 @@ domain provided by the 'parent' power controller.
child: power-controller@12341000 {
compatible = "foo,power-controller";
reg = <0x12341000 0x1000>;
- power-domains = <&parent 0>;
+ power-domains = <&parent>;
#power-domain-cells = <0>;
domain-idle-states = <&DOMAIN_PWR_DN>;
};
--
2.12.0.432.g71c3a4f4ba37
--
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 related
* Re: [PATCHv2 2/3] ARM: drm: Intel FPGA VIP Frame Buffer II drm driver
From: Jani Nikula @ 2017-04-25 7:17 UTC (permalink / raw)
To: daniel.vetter-ral2JQCrhuEAvxtiuMwx3w,
dinguyen-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
tien.hock.loh-ral2JQCrhuEAvxtiuMwx3w, Ong-CC+yJ3UmIYqDUpFQwHEjaQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <1493086006-4392-3-git-send-email-hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Tue, 25 Apr 2017, hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
> +++ b/drivers/gpu/drm/ivip/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Makefile for the drm device driver. This driver provides support for the
> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> +
> +ccflags-y := -Iinclude/drm
Just a drive-by observation, there are patches on the list removing such
ccflags from existing drivers. You shouldn't need this. Just make sure
all your #includes begin with <drm/.
BR,
Jani.
> +
> +obj-$(CONFIG_DRM_IVIP) += ivip.o
> +ivip-objs := intel_vip_of.o intel_vip_core.o \
> +intel_vip_conn.o
--
Jani Nikula, Intel Open Source Technology Center
--
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 2/4] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Geert Uytterhoeven @ 2017-04-25 7:15 UTC (permalink / raw)
To: zoobab
Cc: Linus Walleij, Nandor Han, Greg KH, David S. Miller,
Mauro Carvalho Chehab, Daniel Vetter, Alexandre Courbot,
Rob Herring, Mark Rutland, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Semi Malinen
In-Reply-To: <CANjd3ndZkVi5OA0eqDewrpqVLQpT11QbVOA98F=ghMhcwPu2hQ@mail.gmail.com>
Hi Benjamin,
On Tue, Apr 25, 2017 at 9:07 AM, Benjamin Henrion <zoobab@gmail.com> wrote:
> On Mon, Apr 24, 2017 at 3:47 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> On Thu, Apr 13, 2017 at 12:27 PM, Nandor Han <nandor.han@ge.com> wrote:
>>
>>> This is a simple driver that provides a /sys/class/gpio
>>> interface for controlling and configuring the GPIO lines.
>>> It does not provide support for chip select or interrupts.
>>>
>>> Signed-off-by: Nandor Han <nandor.han@ge.com>
>>> Signed-off-by: Semi Malinen <semi.malinen@ge.com>
>>
>> I almost want to make the driver depend on !GPIO_SYSFS because
>> of this commit message.
>>
>> DO NOT USE OR ENCOURAGE THE USE OF THE GPIO SYSFS
>> INTERFACE.
>>
>> Use the character device.
>
> I doubt you will be able to convince the majority of people toggling
> GPIOs via a simple shell script to switch to write a complex C
> program. Not to mention cross compilation and the libraries
> dependencies here.
>
> Is there some good cli tools to access the new char device? If they
> are shipped with most distros, that would reduce the pain.
https://github.com/brgl/libgpiod
A bit early to expect it to be shipped with all distros, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: Remove the te-gpios property in the TM2 boards
From: Inki Dae @ 2017-04-25 7:12 UTC (permalink / raw)
To: Hoegeun Kwon, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, kgene-DgEjT+Ai2ygdnm+yROfE0A,
krzk-DgEjT+Ai2ygdnm+yROfE0A
Cc: javier-JPH+aEBZ4P+UEJcrhfAQsw, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
a.hajda-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <1493085261-3488-1-git-send-email-hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017년 04월 25일 10:54에 Hoegeun Kwon 이(가) 쓴 글:
> The decon uses HW-TRIGGER, so TE interrupt is not necessary.
> Therefore, remove the te-gpios property in the TM2 dts.
>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3ff9527..23191eb 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -60,7 +60,6 @@
> vci-supply = <&ldo28_reg>;
> reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> - te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
Reviewed-by: Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Thanks,
Inki Dae
> };
> };
>
>
--
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 2/4] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Benjamin Henrion @ 2017-04-25 7:07 UTC (permalink / raw)
To: Linus Walleij
Cc: Nandor Han, Greg KH, David S. Miller, Geert Uytterhoeven,
Mauro Carvalho Chehab, Daniel Vetter, Alexandre Courbot,
Rob Herring, Mark Rutland, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Semi Malinen
In-Reply-To: <CACRpkdZHMWH2W-i4MGZ7NKzPHUURRmC-5YwiK7cVLCHKDsb7sw@mail.gmail.com>
On Mon, Apr 24, 2017 at 3:47 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Apr 13, 2017 at 12:27 PM, Nandor Han <nandor.han@ge.com> wrote:
>
>> This is a simple driver that provides a /sys/class/gpio
>> interface for controlling and configuring the GPIO lines.
>> It does not provide support for chip select or interrupts.
>>
>> Signed-off-by: Nandor Han <nandor.han@ge.com>
>> Signed-off-by: Semi Malinen <semi.malinen@ge.com>
>
> I almost want to make the driver depend on !GPIO_SYSFS because
> of this commit message.
>
> DO NOT USE OR ENCOURAGE THE USE OF THE GPIO SYSFS
> INTERFACE.
>
> Use the character device.
I doubt you will be able to convince the majority of people toggling
GPIOs via a simple shell script to switch to write a complex C
program. Not to mention cross compilation and the libraries
dependencies here.
Is there some good cli tools to access the new char device? If they
are shipped with most distros, that would reduce the pain.
Best,
--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
^ permalink raw reply
* Re: [PATCH 11/13] phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module
From: Hauke Mehrtens @ 2017-04-25 7:06 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420153606.fdhedc7ovvhc66qd@rob-hp-laptop>
On 04/20/2017 05:36 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:40PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> This driver starts the DWC2 core(s) built into the XWAY SoCs and provides
>> the PHY interfaces for each core. The phy instances can be passed to the
>> dwc2 driver, which already supports the generic phy interface.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../bindings/phy/phy-lantiq-rcu-usb2.txt | 59 ++++
>> arch/mips/lantiq/xway/reset.c | 43 ---
>> arch/mips/lantiq/xway/sysctrl.c | 24 +-
>> drivers/phy/Kconfig | 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-lantiq-rcu-usb2.c | 325 +++++++++++++++++++++
>> 6 files changed, 405 insertions(+), 55 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> create mode 100644 drivers/phy/phy-lantiq-rcu-usb2.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> new file mode 100644
>> index 000000000000..0ec9f790b6e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> @@ -0,0 +1,59 @@
>> +Lantiq XWAY SoC RCU USB 1.1/2.0 PHY binding
>> +===========================================
>> +
>> +This binding describes the USB PHY hardware provided by the RCU module on the
>> +Lantiq XWAY SoCs.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be one of
>> + "lantiq,ase-rcu-usb2-phy"
>> + "lantiq,danube-rcu-usb2-phy"
>> + "lantiq,xrx100-rcu-usb2-phy"
>> + "lantiq,xrx200-rcu-usb2-phy"
>> + "lantiq,xrx300-rcu-usb2-phy"
>
> The first x in xrx seems to be a wildcard. Don't use wildcards in
> compatible strings.
Yes that is correct, I will replace it in the newly introduced
compatible strings with the full names without wild cards.
>
>> +- lantiq,rcu-syscon : A phandle to the RCU module and the offsets to the
>> + USB PHY configuration and USB MAC registers.
>
> Same comment as gphy.
>
>> +- address-cells : should be 1
>> +- size-cells : should be 0
>> +- phy-cells : from the generic PHY bindings, must be 1
>
> Missing the '#'
>
>> +
>> +Optional properties (controller (parent) node):
>> +- vbus-gpio : References a GPIO which enables VBUS all given USB
>> + ports.
>
> -gpios is preferred form.
>
>> +
>> +Required nodes : A sub-node is required for each USB PHY port.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (port (child) node):
>
> Where's the sub nodes in the example?
Sorry, this was from an older version, I will update this.
>
>> +- reg : The ID of the USB port, usually 0 or 1.
>> +- clocks : References to the (PMU) "ctrl" and "phy" clk gates.
>> +- clock-names : Must be one of the following:
>> + "ctrl"
>> + "phy"
>> +- resets : References to the RCU USB configuration reset bits.
>> +- reset-names : Must be one of the following:
>> + "analog-config" (optional)
>> + "statemachine-soft" (optional)
>> +
>> +Optional properties (port (child) node):
>> +- vbus-gpio : References a GPIO which enables VBUS for the USB port.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Example for the USB PHYs on an xRX200 SoC:
>> + usb_phys0: rcu-usb2-phy@0 {
>
> usb-phy@...
>
>> + compatible = "lantiq,xrx200-rcu-usb2-phy";
>
> Extra spaces.
>
>> + reg = <0>;
>> +
>> + lantiq,rcu-syscon = <&rcu0 0x18 0x38>;
>> + clocks = <&pmu PMU_GATE_USB0_CTRL>,
>> + <&pmu PMU_GATE_USB0_PHY>;
>> + clock-names = "ctrl", "phy";
>> + vbus-gpios = <&gpio 32 GPIO_ACTIVE_HIGH>;
>> + resets = <&rcu_reset1 4>, <&rcu_reset0 4>;
>> + reset-names = "phy", "ctrl";
>> + #phy-cells = <0>;
>> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 09/13] MIPS: lantiq: Add a GPHY driver which uses the RCU syscon-mfd
From: Hauke Mehrtens @ 2017-04-25 7:05 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420152754.3tkjxjvoiuatbvpo@rob-hp-laptop>
On 04/20/2017 05:27 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:38PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> Compared to the old xrx200_phy_fw driver the new version has multiple
>> enhancements. The name of the firmware files does not have to be added
>> to all .dts files anymore - one now configures the GPHY mode (FE or GE)
>> instead. Each GPHY can now also boot separate firmware (thus mixing of
>> GE and FE GPHYs is now possible).
>> The new implementation is based on the RCU syscon-mfd and uses the
>> reeset_controller framework instead of raw RCU register reads/writes.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../devicetree/bindings/mips/lantiq/rcu-gphy.txt | 54 +++++
>> arch/mips/lantiq/xway/sysctrl.c | 4 +-
>> drivers/soc/lantiq/Makefile | 1 +
>> drivers/soc/lantiq/gphy.c | 242 +++++++++++++++++++++
>> include/dt-bindings/mips/lantiq_rcu_gphy.h | 15 ++
>> 5 files changed, 314 insertions(+), 2 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
>> create mode 100644 drivers/soc/lantiq/gphy.c
>> create mode 100644 include/dt-bindings/mips/lantiq_rcu_gphy.h
>>
>> diff --git a/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt b/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
>> new file mode 100644
>> index 000000000000..d525c7ce9f0b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/lantiq/rcu-gphy.txt
>> @@ -0,0 +1,54 @@
>> +Lantiq XWAY SoC GPHY binding
>> +============================
>> +
>> +This binding describes a software-defined ethernet PHY, provided by the RCU
>> +module on newer Lantiq XWAY SoCs (xRX200 and newer).
>> +This depends on binary firmware blobs which must be provided by userspace.
>
> Where the blobs come from is not relevant.
>
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be one of
>> + "lantiq,xrx200a1x-rcu-gphy"
>> + "lantiq,xrx200a2x-rcu-gphy"
>> + "lantiq,xrx300-rcu-gphy"
>> + "lantiq,xrx330-rcu-gphy"
>> +- lantiq,rcu-syscon : A phandle and offset to the GPHY address registers in
>> + the RCU
>> +- resets : Must reference the RCU GPHY reset bit
>> +- reset-names : One entry, value must be "gphy" or optional "gphy2"
>> +
>> +Optional properties (port (child) node):
>> +- lantiq,gphy-mode : GPHY_MODE_GE (default) or GPHY_MODE_FE as defined in
>> + <dt-bindings/mips/lantiq_xway_gphy.h>
>> +- clocks : A reference to the (PMU) GPHY clock gate
>> +- clock-names : If clocks is given then this must be "gphy"
>
> Kind of pointless to have a name for a single clock.
The documentation misses the 2. clock. ;-) Will add it.
>
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Example for the GPHys on the xRX200 SoCs:
>> +
>> +#include <dt-bindings/mips/lantiq_rcu_gphy.h>
>> + gphy0: rcu_gphy@0 {
>
> Use generic node names: phy@...
I will change this
>
>> + compatible = "lantiq,xrx200a2x-rcu-gphy";
>> + reg = <0>;
>> +
>> + lantiq,rcu-syscon = <&rcu0 0x20>;
>
> Could the phy just be a child of the rcu? Then you don't need a phandle
> here and 0x20 becomes the reg address.
The RCU is a register block which does many things. This register is
specific to this ghpy, but there are some register in the RCU block
which are shared between multiple drivers. Can I support both, provide
some parts of this block as syscon and some as direct register blocks?
>
>> + resets = <&rcu_reset0 31>, <&rcu_reset1 7>;
>> + reset-names = "gphy", "gphy2";
>> + lantiq,gphy-mode = <GPHY_MODE_GE>;
>> + clocks = <&pmu0 XRX200_PMU_GATE_GPHY>;
>> + clock-names = "gphy";
>> + };
>> +
>> + gphy1: rcu_gphy@1 {
>> + compatible = "lantiq,xrx200a2x-rcu-gphy";
>> + reg = <0>;
>> +
>> + lantiq,rcu-syscon = <&rcu0 0x68>;
>> + resets = <&rcu_reset0 29>, <&rcu_reset1 6>;
>> + reset-names = "gphy", "gphy2";
>> + lantiq,gphy-mode = <GPHY_MODE_FE>;
>> + clocks = <&pmu0 XRX200_PMU_GATE_GPHY>;
>> + clock-names = "gphy";
>> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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 08/13] reset: Add a reset controller driver for the Lantiq XWAY based SoCs
From: Hauke Mehrtens @ 2017-04-25 7:00 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420145405.7s3iapxggr5575d2@rob-hp-laptop>
On 04/20/2017 04:54 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:37PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> The reset controllers (on xRX200 and newer SoCs have two of them) are
>> provided by the RCU module. This was initially implemented as a simple
>> reset controller. However, the RCU module provides more functionality
>> (ethernet GPHYs, USB PHY, etc.), which makes it a MFD device.
>> The old reset controller driver implementation from
>> arch/mips/lantiq/xway/reset.c did not honor this fact.
>>
>> For some devices the request and the status bits are different.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../devicetree/bindings/reset/lantiq,rcu-reset.txt | 43 ++++
>> arch/mips/lantiq/xway/reset.c | 68 ------
>> drivers/reset/Kconfig | 6 +
>> drivers/reset/Makefile | 1 +
>> drivers/reset/reset-lantiq-rcu.c | 231 +++++++++++++++++++++
>> 5 files changed, 281 insertions(+), 68 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
>> create mode 100644 drivers/reset/reset-lantiq-rcu.c
>>
>> diff --git a/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
>> new file mode 100644
>> index 000000000000..7f097d16bbb7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/lantiq,rcu-reset.txt
>> @@ -0,0 +1,43 @@
>> +Lantiq XWAY SoC RCU reset controller binding
>> +============================================
>> +
>> +This binding describes a reset-controller found on the RCU module on Lantiq
>> +XWAY SoCs.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be "lantiq,rcu-reset"
>> +- lantiq,rcu-syscon : A phandle to the RCU syscon, the reset register
>> + offset and the status register offset.
>> +- #reset-cells : Specifies the number of cells needed to encode the
>> + reset line, should be 1.
>> +
>> +Optional properties:
>> +- reset-status : The request status bit. For some bits the request bit
>> + and the status bit are different. This is depending
>> + on the SoC. If the reset-status bit does not match
>> + the reset-request bit, put the reset number into the
>> + reset-request property and the status bit at the same
>> + index into the reset-status property. If no
>> + reset-request bit is given here, the driver assume
>> + status and request bit are the same.
>> +- reset-request : The reset request bit, to map it to the reset-status
>> + bit.
>
> These should either be implied by SoC specific compatible or be made
> part of the reset cells. In the latter case, you still need the SoC
> specific compatible.
Currently the reset framework only supports a single reset cell to my
knowledge, but I haven't looked into the details, I could extend it to
make it support two.
The SoC which needs this has two reset control register sets and the
bits are specific for each register set. Would a specific compatible
string for each register set ok?
>
>> +-------------------------------------------------------------------------------
>> +Example for the reset-controllers on the xRX200 SoCs:
>> + rcu_reset0: rcu_reset {
>> + compatible = "lantiq,rcu-reset";
>> + lantiq,rcu-syscon = <&rcu0 0x10 0x14>;
>> + #reset-cells = <1>;
>> + reset-request = <31>, <29>, <21>, <19>, <16>, <12>;
>> + reset-status = <30>, <28>, <16>, <25>, <5>, <24>;
>> + };
>> +
>> + rcu_reset1: rcu_reset {
>> + compatible = "lantiq,rcu-reset";
>
> These 2 blocks are identical? Given different registers sizes, I'd say
> not. So they should have different compatible strings.
I will remove the second one.
>
>> + lantiq,rcu-syscon = <&rcu0 0x48 0x24>;
>> + #reset-cells = <1>;
>> + };
--
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 06/13] MIPS: lantiq: Convert the xbar driver to a platform_driver
From: Hauke Mehrtens @ 2017-04-25 6:56 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
john-Pj+rj9U5foFAfugRpC6u6w, linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420144848.hwvtrhnwxcsxyv7x@rob-hp-laptop>
On 04/20/2017 04:48 PM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 09:29:35PM +0200, Hauke Mehrtens wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> This allows using the xbar driver on ARX300 based SoCs which require the
>> same xbar setup as the xRX200 chipsets because the xbar driver
>> initialization is not guarded by an xRX200 specific
>> of_machine_is_compatible condition anymore. Additionally the new driver
>> takes a syscon phandle to configure the XBAR endianness bits in RCU
>> (before this was done in arch/mips/lantiq/xway/reset.c and also
>> guarded by an xRX200 specific if-statement).
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
>> ---
>> .../devicetree/bindings/mips/lantiq/xbar.txt | 22 +++++
>> MAINTAINERS | 1 +
>> arch/mips/lantiq/xway/reset.c | 4 -
>> arch/mips/lantiq/xway/sysctrl.c | 41 ---------
>> drivers/soc/Makefile | 1 +
>> drivers/soc/lantiq/Makefile | 1 +
>> drivers/soc/lantiq/xbar.c | 100 +++++++++++++++++++++
>> 7 files changed, 125 insertions(+), 45 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mips/lantiq/xbar.txt
>> create mode 100644 drivers/soc/lantiq/Makefile
>> create mode 100644 drivers/soc/lantiq/xbar.c
>>
>> diff --git a/Documentation/devicetree/bindings/mips/lantiq/xbar.txt b/Documentation/devicetree/bindings/mips/lantiq/xbar.txt
>> new file mode 100644
>> index 000000000000..86e53ff3b0d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/lantiq/xbar.txt
>> @@ -0,0 +1,22 @@
>> +Lantiq XWAY SoC XBAR binding
>> +============================
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties:
>> +- compatible : Should be "lantiq,xbar-xway"
>
> This compatible is already in use so it is fine, but you should also
> have per SoC compatible strings.
I will add a new SoC specific one.
What does per SoC device tree mean? Does it mean for the same silicon,
for the same silicon revision, for the same fusing of a silicon or for
the same marketing name?
I would like to make it per silicon or per silicon revision for the IP
cores which I know are different.
Hauke
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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 1/3] mtd: nand: Cleanup/rework the atmel_nand driver
From: Boris Brezillon @ 2017-04-25 6:53 UTC (permalink / raw)
To: Brian Norris
Cc: Richard Weinberger, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Nicolas Ferre, Alexandre Belloni, Haavard Skinnemoen,
Hans-Christian Egtvedt, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Wenyou Yang, Josh Wu, David Woodhouse, Marek Vasut,
Cyrille Pitchen,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA, Masahiro Yamada
In-Reply-To: <20170425010930.GA120971-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, 24 Apr 2017 18:09:30 -0700
Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Mar 16, 2017 at 09:02:40AM +0100, Boris Brezillon wrote:
>
> > diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
> > new file mode 100644
> > index 000000000000..f71b9e5d7d9d
> > --- /dev/null
> > +++ b/drivers/mtd/nand/atmel/nand-controller.c
> > @@ -0,0 +1,2198 @@
> [...]
>
> > +static int
> > +atmel_hsmc_nand_controller_legacy_init(struct atmel_hsmc_nand_controller *nc)
> > +{
> > + struct regmap_config regmap_conf = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .val_bits = 32,
>
> You assigned val_bits twice. Is that just a harmless mistake, or did you
> mean to set something else?
Nope, I didn't mean to set another field to 32. I'll just apply the fix
you provided.
Thanks,
Boris
--
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 11/13] phy: Add an USB PHY driver for the Lantiq SoCs using the RCU module
From: Hauke Mehrtens @ 2017-04-25 6:51 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, john-Pj+rj9U5foFAfugRpC6u6w,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
hauke.mehrtens-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <CAFBinCAB=vaDpzCoMFX8w9j0R04i6Zr4mbjDtteKsQ_LkKAaLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/17/2017 11:23 PM, Martin Blumenstingl wrote:
> On Mon, Apr 17, 2017 at 9:29 PM, Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org> wrote:
>> From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>>
>> This driver starts the DWC2 core(s) built into the XWAY SoCs and provides
>> the PHY interfaces for each core. The phy instances can be passed to the
>> dwc2 driver, which already supports the generic phy interface.
>>
>> Signed-off-by: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
> you should probably send this patch to the PHY maintainer as well
> (Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>)
>
>> ---
>> .../bindings/phy/phy-lantiq-rcu-usb2.txt | 59 ++++
>> arch/mips/lantiq/xway/reset.c | 43 ---
>> arch/mips/lantiq/xway/sysctrl.c | 24 +-
>> drivers/phy/Kconfig | 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-lantiq-rcu-usb2.c | 325 +++++++++++++++++++++
>> 6 files changed, 405 insertions(+), 55 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> create mode 100644 drivers/phy/phy-lantiq-rcu-usb2.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> new file mode 100644
>> index 000000000000..0ec9f790b6e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-lantiq-rcu-usb2.txt
>> @@ -0,0 +1,59 @@
>> +Lantiq XWAY SoC RCU USB 1.1/2.0 PHY binding
>> +===========================================
>> +
>> +This binding describes the USB PHY hardware provided by the RCU module on the
>> +Lantiq XWAY SoCs.
>> +
>> +
>> +-------------------------------------------------------------------------------
>> +Required properties (controller (parent) node):
>> +- compatible : Should be one of
>> + "lantiq,ase-rcu-usb2-phy"
>> + "lantiq,danube-rcu-usb2-phy"
>> + "lantiq,xrx100-rcu-usb2-phy"
>> + "lantiq,xrx200-rcu-usb2-phy"
>> + "lantiq,xrx300-rcu-usb2-phy"
>> +- lantiq,rcu-syscon : A phandle to the RCU module and the offsets to the
>> + USB PHY configuration and USB MAC registers.
>> +- address-cells : should be 1
>> +- size-cells : should be 0
>> +- phy-cells : from the generic PHY bindings, must be 1
>> +
>> +Optional properties (controller (parent) node):
>> +- vbus-gpio : References a GPIO which enables VBUS all given USB
>> + ports.
> the PHY framework already handles this if you wrap the GPIO in a
> "regulator-fixed" node, see [0] how to define a fixed regulator with a
> GPIO (the regulator in this example has two states: off = 0V and on =
> 5V, probably exactly what you need) and [1] how to pass it to the PHY
> (phy-core.c handles this already, no driver specific code needed)
Thanksy, I will change the code and use a regulator.
......
>> diff --git a/arch/mips/lantiq/xway/reset.c b/arch/mips/lantiq/xway/reset.c
>> index 3f30fb81a50f..5aec1f54275b 100644
>> --- a/arch/mips/lantiq/xway/reset.c
>> +++ b/arch/mips/lantiq/xway/reset.c
> could these arch/mips/lantiq/xway/reset.c changes to into PATCH #3 as well?
I do not get this.
......
> [0] https://github.com/torvalds/linux/blob/2fbbc4bf69f293df317559a267f4120f290b8fc4/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi#L67
> [1] https://github.com/torvalds/linux/blob/2fbbc4bf69f293df317559a267f4120f290b8fc4/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi#L133
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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
* [PATCH V2 2/2] clk: rockchip: fix the incorrect ids
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, zhengxing, mturquette, sboyd
Cc: devicetree, linux-kernel, linux-clk, linux-arm-kernel,
linux-rockchip, Eddie Cai
In-Reply-To: <1493102470-22965-1-git-send-email-eddie.cai.linux@gmail.com>
the ids of clk_testout1 and clk_testout2 is incorrect now. let's correct it
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c
index 73121b14..f3656ba 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1066,13 +1066,13 @@ enum rk3399_pmu_plls {
/* cif_testout */
MUX(0, "clk_testout1_pll_src", mux_pll_src_cpll_gpll_npll_p, 0,
RK3399_CLKSEL_CON(38), 6, 2, MFLAGS),
- COMPOSITE(0, "clk_testout1", mux_clk_testout1_p, 0,
+ COMPOSITE(SCLK_TESTCLKOUT1, "clk_testout1", mux_clk_testout1_p, 0,
RK3399_CLKSEL_CON(38), 5, 1, MFLAGS, 0, 5, DFLAGS,
RK3399_CLKGATE_CON(13), 14, GFLAGS),
MUX(0, "clk_testout2_pll_src", mux_pll_src_cpll_gpll_npll_p, 0,
RK3399_CLKSEL_CON(38), 14, 2, MFLAGS),
- COMPOSITE(0, "clk_testout2", mux_clk_testout2_p, 0,
+ COMPOSITE(SCLK_TESTCLKOUT2, "clk_testout2", mux_clk_testout2_p, 0,
RK3399_CLKSEL_CON(38), 13, 1, MFLAGS, 8, 5, DFLAGS,
RK3399_CLKGATE_CON(13), 15, GFLAGS),
--
1.9.1
^ permalink raw reply related
* [PATCH V2 1/2] clk: rockchip: add ids for camera
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, zhengxing, mturquette, sboyd
Cc: devicetree, linux-kernel, linux-clk, linux-arm-kernel,
linux-rockchip, Eddie Cai
In-Reply-To: <1493102470-22965-1-git-send-email-eddie.cai.linux@gmail.com>
we use SCLK_TESTCLKOUT1 and SCLK_TESTCLKOUT2 for camera, so add those ids.
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
---
include/dt-bindings/clock/rk3399-cru.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
index 220a60f..22cb1df 100644
--- a/include/dt-bindings/clock/rk3399-cru.h
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -132,6 +132,8 @@
#define SCLK_RMII_SRC 166
#define SCLK_PCIEPHY_REF100M 167
#define SCLK_DDRC 168
+#define SCLK_TESTCLKOUT1 169
+#define SCLK_TESTCLKOUT2 170
#define DCLK_VOP0 180
#define DCLK_VOP1 181
--
1.9.1
^ permalink raw reply related
* [PATCH V2 0/2] correct ids for clk_testout
From: Eddie Cai @ 2017-04-25 6:41 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
heiko-4mtYJXux2i+zQB+pC5nmwQ, zhengxing-TNX95d0MmH7DzftRWevZcw,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Eddie Cai
we use clk_testout1 and clk_testout2 for camera. e.g. mipi 24M mclk. the ids of
clk_testout1 and clk_testout2 is wrong. it's time to correct it.
Eddie Cai (2):
clk: rockchip: add ids for camera
clk: rockchip: fix the incorrect ids
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
include/dt-bindings/clock/rk3399-cru.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
--
1.9.1
--
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] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)
From: Stefan Wahren @ 2017-04-25 6:22 UTC (permalink / raw)
To: Eric Anholt, Lee Jones, Florian Fainelli, Olof Johansson,
Rob Herring, Mark Rutland, devicetree
Cc: linux-rpi-kernel, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, Gerd Hoffmann
In-Reply-To: <20170424200037.25615-1-eric@anholt.net>
Am 24.04.2017 um 22:00 schrieb Eric Anholt:
> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
> now, so it's useful to be able to test that mode on an upstream
> kernel. It's also been useful for me to use the same board for 32-bit
> and 64-bit development.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/bcm2837-rpi-3.b.dts | 1 +
> 2 files changed, 2 insertions(+)
> create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3.b.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 011808490fed..eded842d9978 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
> bcm2835-rpi-b-plus.dtb \
> bcm2835-rpi-a-plus.dtb \
> bcm2836-rpi-2-b.dtb \
> + bcm2837-rpi-3-b.dtb \
> bcm2835-rpi-zero.dtb
> dtb-$(CONFIG_ARCH_BCM_5301X) += \
> bcm4708-asus-rt-ac56u.dtb \
> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3.b.dts b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
> new file mode 100644
> index 000000000000..8c8aa4d1e9b3
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts
> @@ -0,0 +1 @@
> +#include "arm64/broadcom/bcm2837-rpi-3.b.dts"
Looks like a typo in the dts filename and in the include ( dot instead
of dash ).
^ permalink raw reply
* [PATCH v2 4/4] of: detect invalid phandle in overlay
From: frowand.list-Re5JQEeQqe8AvxtiuMwx3w @ 2017-04-25 6:20 UTC (permalink / raw)
To: Rob Herring, stephen.boyd-QSEj5FYQhm4dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493101210-11745-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
Overlays are not allowed to modify phandle values of previously existing
nodes because there is no information available to allow fixup up
properties that use the previously existing phandle.
Signed-off-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
---
drivers/of/overlay.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index ca0b85f5deb1..20ab49d2f7a4 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -130,6 +130,10 @@ static int of_overlay_apply_single_device_node(struct of_overlay *ov,
/* NOTE: Multiple mods of created nodes not supported */
tchild = of_get_child_by_name(target, cname);
if (tchild != NULL) {
+ /* new overlay phandle value conflicts with existing value */
+ if (child->phandle)
+ return -EINVAL;
+
/* apply overlay recursively */
ret = of_overlay_apply_one(ov, tchild, child);
of_node_put(tchild);
--
Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
--
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 related
* [PATCH v2 3/4] of: be consistent in form of file mode
From: frowand.list @ 2017-04-25 6:20 UTC (permalink / raw)
To: Rob Herring, stephen.boyd; +Cc: devicetree, linux-kernel
In-Reply-To: <1493101210-11745-1-git-send-email-frowand.list@gmail.com>
From: Frank Rowand <frank.rowand@sony.com>
checkpatch whined about using S_IRUGO instead of octal equivalent
when adding phandle sysfs code, so used octal in that patch.
Change other instances of the S_* constants in the same file to
the octal form.
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
---
drivers/of/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 9e70d283cdc5..865e54355733 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -168,7 +168,7 @@ int __of_add_property_sysfs(struct device_node *np, struct property *pp)
sysfs_bin_attr_init(&pp->attr);
pp->attr.attr.name = safe_name(&np->kobj, pp->name);
- pp->attr.attr.mode = secure ? S_IRUSR : S_IRUGO;
+ pp->attr.attr.mode = secure ? 0400 : 0444;
pp->attr.size = secure ? 0 : pp->length;
pp->attr.read = of_node_property_read;
--
Frank Rowand <frank.rowand@sony.com>
^ permalink raw reply related
* [PATCH v2 2/4] of: make __of_attach_node() static
From: frowand.list-Re5JQEeQqe8AvxtiuMwx3w @ 2017-04-25 6:20 UTC (permalink / raw)
To: Rob Herring, stephen.boyd-QSEj5FYQhm4dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493101210-11745-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
__of_attach_node() is not used outside of drivers/of/dynamic.c. Make
it static and remove it from drivers/of/of_private.h.
Signed-off-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
---
drivers/of/dynamic.c | 2 +-
drivers/of/of_private.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 59545b8fbf46..0b9cf6d5914c 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -216,7 +216,7 @@ int of_property_notify(int action, struct device_node *np,
return of_reconfig_notify(action, &pr);
}
-void __of_attach_node(struct device_node *np)
+static void __of_attach_node(struct device_node *np)
{
np->child = NULL;
np->sibling = np->parent->child;
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 33f11a5384f3..b1ff70e1fdda 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -79,7 +79,6 @@ extern int __of_update_property(struct device_node *np,
extern void __of_update_property_sysfs(struct device_node *np,
struct property *newprop, struct property *oldprop);
-extern void __of_attach_node(struct device_node *np);
extern int __of_attach_node_sysfs(struct device_node *np);
extern void __of_detach_node(struct device_node *np);
extern void __of_detach_node_sysfs(struct device_node *np);
--
Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
--
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 related
* [PATCH v2 1/4] of: remove *phandle properties from expanded device tree
From: frowand.list-Re5JQEeQqe8AvxtiuMwx3w @ 2017-04-25 6:20 UTC (permalink / raw)
To: Rob Herring, stephen.boyd-QSEj5FYQhm4dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493101210-11745-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
Remove "phandle", "linux,phandle", and "ibm,phandle" properties from
the internal device tree. The phandle will still be in the struct
device_node phandle field.
This is to resolve the issue found by Stephen Boyd [1] when he changed
the type of struct property.value from void * to const void *. As
a result of the type change, the overlay code had compile errors
where the resolver updates phandle values.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1702.1/04160.html
- Add sysfs infrastructure to report np->phandle, as if it was a property.
- Do not create "phandle" "ibm,phandle", and "linux,phandle" properties
in the expanded device tree.
- Remove phandle properties in of_attach_node(), for nodes dynamically
attached to the live tree. Add the phandle sysfs entry for these nodes.
- When creating an overlay changeset, duplicate the node phandle in
__of_node_dup().
- Remove no longer needed checks to exclude "phandle" and "linux,phandle"
properties in several locations.
- A side effect of these changes is that the obsolete "linux,phandle" and
"ibm,phandle" properties will no longer appear in /proc/device-tree (they
will appear as "phandle").
Signed-off-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
---
drivers/of/base.c | 51 +++++++++++++++++++++++++++++++++++++++++++---
drivers/of/dynamic.c | 54 +++++++++++++++++++++++++++++++++++++------------
drivers/of/fdt.c | 40 +++++++++++++++++++++---------------
drivers/of/of_private.h | 1 +
drivers/of/overlay.c | 4 +---
drivers/of/resolver.c | 23 +--------------------
include/linux/of.h | 1 +
7 files changed, 117 insertions(+), 57 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d7c4629a3a2d..9e70d283cdc5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -116,6 +116,19 @@ static ssize_t of_node_property_read(struct file *filp, struct kobject *kobj,
return memory_read_from_buffer(buf, count, &offset, pp->value, pp->length);
}
+static ssize_t of_node_phandle_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr, char *buf,
+ loff_t offset, size_t count)
+{
+ phandle phandle;
+ struct device_node *np;
+
+ np = container_of(bin_attr, struct device_node, attr_phandle);
+ phandle = cpu_to_be32(np->phandle);
+ return memory_read_from_buffer(buf, count, &offset, &phandle,
+ sizeof(phandle));
+}
+
/* always return newly allocated name, caller must free after use */
static const char *safe_name(struct kobject *kobj, const char *orig_name)
{
@@ -164,6 +177,38 @@ int __of_add_property_sysfs(struct device_node *np, struct property *pp)
return rc;
}
+/*
+ * In the imported device tree (fdt), phandle is a property. In the
+ * internal data structure it is instead stored in the struct device_node.
+ * Make phandle visible in sysfs as if it was a property.
+ */
+int __of_add_phandle_sysfs(struct device_node *np)
+{
+ int rc;
+
+ if (IS_ENABLED(CONFIG_PPC_PSERIES))
+ return 0;
+
+ if (!IS_ENABLED(CONFIG_SYSFS))
+ return 0;
+
+ if (!of_kset || !of_node_is_attached(np))
+ return 0;
+
+ if (!np->phandle || np->phandle == 0xffffffff)
+ return 0;
+
+ sysfs_bin_attr_init(&pp->attr);
+ np->attr_phandle.attr.name = "phandle";
+ np->attr_phandle.attr.mode = 0444;
+ np->attr_phandle.size = sizeof(np->phandle);
+ np->attr_phandle.read = of_node_phandle_read;
+
+ rc = sysfs_create_bin_file(&np->kobj, &np->attr_phandle);
+ WARN(rc, "error adding attribute phandle to node %s\n", np->full_name);
+ return rc;
+}
+
int __of_attach_node_sysfs(struct device_node *np)
{
const char *name;
@@ -193,6 +238,8 @@ int __of_attach_node_sysfs(struct device_node *np)
if (rc)
return rc;
+ __of_add_phandle_sysfs(np);
+
for_each_property_of_node(np, pp)
__of_add_property_sysfs(np, pp);
@@ -2097,9 +2144,7 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
int id, len;
/* Skip those we do not want to proceed */
- if (!strcmp(pp->name, "name") ||
- !strcmp(pp->name, "phandle") ||
- !strcmp(pp->name, "linux,phandle"))
+ if (!strcmp(pp->name, "name"))
continue;
np = of_find_node_by_path(pp->value);
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 888fdbc09992..59545b8fbf46 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -218,19 +218,6 @@ int of_property_notify(int action, struct device_node *np,
void __of_attach_node(struct device_node *np)
{
- const __be32 *phandle;
- int sz;
-
- np->name = __of_get_property(np, "name", NULL) ? : "<NULL>";
- np->type = __of_get_property(np, "device_type", NULL) ? : "<NULL>";
-
- phandle = __of_get_property(np, "phandle", &sz);
- if (!phandle)
- phandle = __of_get_property(np, "linux,phandle", &sz);
- if (IS_ENABLED(CONFIG_PPC_PSERIES) && !phandle)
- phandle = __of_get_property(np, "ibm,phandle", &sz);
- np->phandle = (phandle && (sz >= 4)) ? be32_to_cpup(phandle) : 0;
-
np->child = NULL;
np->sibling = np->parent->child;
np->parent->child = np;
@@ -243,11 +230,47 @@ void __of_attach_node(struct device_node *np)
int of_attach_node(struct device_node *np)
{
struct of_reconfig_data rd;
+ struct property *prev;
+ struct property *prop;
+ struct property *save_next;
unsigned long flags;
+ const __be32 *phandle;
+ int sz;
memset(&rd, 0, sizeof(rd));
rd.dn = np;
+ np->name = __of_get_property(np, "name", NULL) ? : "<NULL>";
+ np->type = __of_get_property(np, "device_type", NULL) ? : "<NULL>";
+
+ phandle = __of_get_property(np, "phandle", &sz);
+ if (!phandle)
+ phandle = __of_get_property(np, "linux,phandle", &sz);
+ if (IS_ENABLED(CONFIG_PPC_PSERIES) && !phandle)
+ phandle = __of_get_property(np, "ibm,phandle", &sz);
+ np->phandle = (phandle && (sz >= 4)) ? be32_to_cpup(phandle) : 0;
+
+ /* remove phandle properties from node */
+ prev = NULL;
+ for (prop = np->properties; prop != NULL; ) {
+ save_next = prop->next;
+ if (!strcmp(prop->name, "phandle") ||
+ !strcmp(prop->name, "ibm,phandle") ||
+ !strcmp(prop->name, "linux,phandle")) {
+ if (prev)
+ prev->next = prop->next;
+ else
+ np->properties = prop->next;
+ prop->next = np->deadprops;
+ np->deadprops = prop;
+ } else {
+ prev = prop;
+ }
+ prop = save_next;
+ }
+
+ __of_add_phandle_sysfs(np);
+
mutex_lock(&of_mutex);
raw_spin_lock_irqsave(&devtree_lock, flags);
__of_attach_node(np);
@@ -429,6 +452,7 @@ struct device_node *__of_node_dup(const struct device_node *np, const char *fmt,
/* Iterate over and duplicate all properties */
if (np) {
struct property *pp, *new_pp;
+ node->phandle = np->phandle;
for_each_property_of_node(np, pp) {
new_pp = __of_prop_dup(pp, GFP_KERNEL);
if (!new_pp)
@@ -441,6 +465,10 @@ struct device_node *__of_node_dup(const struct device_node *np, const char *fmt,
}
}
}
+
+ node->name = __of_get_property(node, "name", NULL) ? : "<NULL>";
+ node->type = __of_get_property(node, "device_type", NULL) ? : "<NULL>";
+
return node;
err_prop:
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e5ce4b59e162..270f31b0c259 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -181,6 +181,8 @@ static void populate_properties(const void *blob,
const __be32 *val;
const char *pname;
u32 sz;
+ int prop_is_phandle = 0;
+ int prop_is_ibm_phandle = 0;
val = fdt_getprop_by_offset(blob, cur, &pname, &sz);
if (!val) {
@@ -196,11 +198,6 @@ static void populate_properties(const void *blob,
if (!strcmp(pname, "name"))
has_name = true;
- pp = unflatten_dt_alloc(mem, sizeof(struct property),
- __alignof__(struct property));
- if (dryrun)
- continue;
-
/* We accept flattened tree phandles either in
* ePAPR-style "phandle" properties, or the
* legacy "linux,phandle" properties. If both
@@ -208,23 +205,34 @@ static void populate_properties(const void *blob,
* will get weird. Don't do that.
*/
if (!strcmp(pname, "phandle") ||
- !strcmp(pname, "linux,phandle")) {
- if (!np->phandle)
- np->phandle = be32_to_cpup(val);
- }
+ !strcmp(pname, "linux,phandle"))
+ prop_is_phandle = 1;
/* And we process the "ibm,phandle" property
* used in pSeries dynamic device tree
* stuff
*/
- if (!strcmp(pname, "ibm,phandle"))
- np->phandle = be32_to_cpup(val);
+ if (!strcmp(pname, "ibm,phandle")) {
+ prop_is_phandle = 1;
+ prop_is_ibm_phandle = 1;
+ }
+
+ if (!prop_is_phandle)
+ pp = unflatten_dt_alloc(mem, sizeof(struct property),
+ __alignof__(struct property));
- pp->name = (char *)pname;
- pp->length = sz;
- pp->value = (__be32 *)val;
- *pprev = pp;
- pprev = &pp->next;
+ if (dryrun)
+ continue;
+
+ if (!prop_is_phandle) {
+ pp->name = (char *)pname;
+ pp->length = sz;
+ pp->value = (__be32 *)val;
+ *pprev = pp;
+ pprev = &pp->next;
+ } else if (prop_is_ibm_phandle || !np->phandle) {
+ np->phandle = be32_to_cpup(val);
+ }
}
/* With version 0x10 we may not have the name property,
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 18bbb4517e25..33f11a5384f3 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -47,6 +47,7 @@ extern int of_property_notify(int action, struct device_node *np,
extern void of_node_release(struct kobject *kobj);
extern int __of_changeset_apply(struct of_changeset *ocs);
extern int __of_changeset_revert(struct of_changeset *ocs);
+extern int __of_add_phandle_sysfs(struct device_node *np);
#else /* CONFIG_OF_DYNAMIC */
static inline int of_property_notify(int action, struct device_node *np,
struct property *prop, struct property *old_prop)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 7827786718d8..ca0b85f5deb1 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -101,9 +101,7 @@ static int of_overlay_apply_single_property(struct of_overlay *ov,
tprop = of_find_property(target, prop->name, NULL);
/* special properties are not meant to be updated (silent NOP) */
- if (of_prop_cmp(prop->name, "name") == 0 ||
- of_prop_cmp(prop->name, "phandle") == 0 ||
- of_prop_cmp(prop->name, "linux,phandle") == 0)
+ if (!of_prop_cmp(prop->name, "name"))
return 0;
propn = __of_prop_dup(prop, GFP_KERNEL);
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 7ae9863cb0a4..624cbaeae0a4 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -71,30 +71,11 @@ static void adjust_overlay_phandles(struct device_node *overlay,
int phandle_delta)
{
struct device_node *child;
- struct property *prop;
- phandle phandle;
/* adjust node's phandle in node */
if (overlay->phandle != 0 && overlay->phandle != OF_PHANDLE_ILLEGAL)
overlay->phandle += phandle_delta;
- /* copy adjusted phandle into *phandle properties */
- for_each_property_of_node(overlay, prop) {
-
- if (of_prop_cmp(prop->name, "phandle") &&
- of_prop_cmp(prop->name, "linux,phandle"))
- continue;
-
- if (prop->length < 4)
- continue;
-
- phandle = be32_to_cpup(prop->value);
- if (phandle == OF_PHANDLE_ILLEGAL)
- continue;
-
- *(uint32_t *)prop->value = cpu_to_be32(overlay->phandle);
- }
-
for_each_child_of_node(overlay, child)
adjust_overlay_phandles(child, phandle_delta);
}
@@ -197,9 +178,7 @@ static int adjust_local_phandle_references(struct device_node *local_fixups,
for_each_property_of_node(local_fixups, prop_fix) {
/* skip properties added automatically */
- if (!of_prop_cmp(prop_fix->name, "name") ||
- !of_prop_cmp(prop_fix->name, "phandle") ||
- !of_prop_cmp(prop_fix->name, "linux,phandle"))
+ if (!of_prop_cmp(prop_fix->name, "name"))
continue;
if ((prop_fix->length % 4) != 0 || prop_fix->length == 0)
diff --git a/include/linux/of.h b/include/linux/of.h
index 21e6323de0f3..4e86e05853f3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -61,6 +61,7 @@ struct device_node {
struct kobject kobj;
unsigned long _flags;
void *data;
+ struct bin_attribute attr_phandle;
#if defined(CONFIG_SPARC)
const char *path_component_name;
unsigned int unique_id;
--
Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
--
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 related
* [PATCH v2 0/4] of: remove *phandle properties from expanded device tree
From: frowand.list @ 2017-04-25 6:20 UTC (permalink / raw)
To: Rob Herring, stephen.boyd; +Cc: devicetree, linux-kernel
From: Frank Rowand <frank.rowand@sony.com>
Remove "phandle" and "linux,phandle" properties from the internal
device tree. The phandle will still be in the struct device_node
phandle field.
This is to resolve the issue found by Stephen Boyd [1] when he changed
the type of struct property.value from void * to const void *. As
a result of the type change, the overlay code had compile errors
where the resolver updates phandle values.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1702.1/04160.html
Patch 1 is the phandle related changes.
Patches 2 - 4 are minor fixups for issues that became visible
while implementing patch 1.
Changes from v1:
- Remove phandle properties in of_attach_node(), before attaching
the node to the live tree.
- Add the phandle sysfs entry for the node in of_attach_node().
- When creating an overlay changeset, duplicate the node phandle in
__of_node_dup().
Frank Rowand (4):
of: remove *phandle properties from expanded device tree
of: make __of_attach_node() static
of: be consistent in form of file mode
of: detect invalid phandle in overlay
drivers/of/base.c | 53 ++++++++++++++++++++++++++++++++++++++++++----
drivers/of/dynamic.c | 56 ++++++++++++++++++++++++++++++++++++-------------
drivers/of/fdt.c | 40 +++++++++++++++++++++--------------
drivers/of/of_private.h | 2 +-
drivers/of/overlay.c | 8 ++++---
drivers/of/resolver.c | 23 +-------------------
include/linux/of.h | 1 +
7 files changed, 123 insertions(+), 60 deletions(-)
--
Frank Rowand <frank.rowand@sony.com>
^ permalink raw reply
* Re: [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: icenowy-h8G6r0blFSE @ 2017-04-25 5:47 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Thomas Gleixner, Rob Herring, Maxime Ripard, Lee Jones,
Liam Girdwood, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <CAGb2v673CL6TaZxkNR9SZDiG5G3cMqU1-=XeMj5gyDbQq4YzVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
在 2017-04-25 10:17，Chen-Yu Tsai 写道：
> On Tue, Apr 25, 2017 at 12:01 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> wrote:
>> As axp20x-regulator now supports AXP803, add a cell for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> ---
>> Changes in v4:
>> - Added a trailing comma for new cell, for easier further cell
>> addition.
>> Changes in v3:
>> - Make the new cell one-liner.
>>
>> drivers/mfd/axp20x.c | 3 ++-
>> drivers/regulator/axp20x-regulator.c | 6 +++---
>
> Squashed in wrong patch?
Oh seems so...
>
> ChenYu
--
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
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