RE: [PATCH 1/2] usb: gadget: udc: renesas_usb3: add property "renesas,ignore-id"

[Yoshihiro Shimoda]

Hi Simon-san,

> From: Simon Horman, Sent: Wednesday, April 11, 2018 4:28 PM
> 
> On Tue, Apr 10, 2018 at 09:13:53PM +0900, Yoshihiro Shimoda wrote:

> > This patch adds a new property to ignore the ID signal on a board.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  Documentation/devicetree/bindings/usb/renesas_usb3.txt |  2 ++
> >  drivers/usb/gadget/udc/renesas_usb3.c  | 10 ++
> >  2 files changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> > index 2c071bb..53949bd 100644
> > --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> > +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> > @@ -19,6 +19,8 @@ Required properties:
> >  Optional properties:
> >- phys: phandle + phy specifier pair
> >- phy-names: must be "usb"
> > +  - renesas,ignore-id: when a board doesn't use ID pin, you can add this
> > +  property to ignore the ID state.
> >
> >  Example of R-Car H3 ES1.x:
> > usb3_peri0: usb@ee02 {
> > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > b/drivers/usb/gadget/udc/renesas_usb3.c
> > index 409cde4..59e1485 100644
> > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > @@ -350,6 +350,7 @@ struct renesas_usb3 {
> > bool extcon_host;   /* check id and set EXTCON_USB_HOST */
> > bool extcon_usb;/* check vbus and set EXTCON_USB */
> > bool forced_b_device;
> > +   bool ignore_id;
> >  };
> >
> >  #define gadget_to_renesas_usb3(_gadget)\
> > @@ -645,6 +646,9 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
> >
> >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> >  {
> > +   if (usb3->ignore_id && !usb3->forced_b_device)
> > +   return;
> > +
> > if (host)
> > usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
> > else
> > @@ -675,6 +679,9 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> > bool host, bool a_dev)
> >
> >  static bool usb3_is_a_device(struct renesas_usb3 *usb3)
> >  {
> > +   if (usb3->ignore_id)
> > +   return false;
> > +
> > return !(usb3_read(usb3, USB3_USB_OTG_STA) & USB_OTG_IDMON);
> >  }
> >
> > @@ -2632,6 +2639,9 @@ static int renesas_usb3_probe(struct platform_device 
> > *pdev)
> > if (ret < 0)
> > goto err_add_udc;
> >
> > +   if (of_property_read_bool(pdev->dev.of_node, "renesas,no-id"))
> > +   usb3->ignore_id = true;
> 
> I wonder if this is better expressed as:
> 
>   usb3->ignore_id = of_property_read_bool(pdev->dev.of_node,
>   "renesas,no-id"));

Thank you for the pointed out! I agree with you.
However, I would like to recall this adding property for now because
I'm thinking that the OF graph of usb-connector can assume this via 
connector-type
instead of such a local property. So, I'll try to use the usb-connector 
bindings on
this driver.

Best regards,
Yoshihiro Shimoda

> > +
> > ret = device_create_file(>dev, _attr_role);
> > if (ret < 0)
> > goto err_dev_create;
> > --
> > 1.9.1
> >

Re: [PATCH v2 1/2] MAINTAINERS: remove me as maintainer for I2C host drivers

[Wolfram Sang]

On Tue, Apr 10, 2018 at 09:49:13PM +0200, Wolfram Sang wrote:
> The number of I2C host controller drivers keeps increasing, and although
> I had some success acquiring specific driver maintainers, my bandwidth
> is by far not enough to act as a fallback for the rest of the drivers.
> To reflect this status-quo in MAINTAINERS, add a seperate entry for I2C
> host drivers, let the I2C list (= community) be the contact point, and
> mark this section as "Odd fixes".
> 
> Signed-off-by: Wolfram Sang 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers

[Wolfram Sang]

On Tue, Apr 10, 2018 at 09:49:14PM +0200, Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> Intentionally missing i2c-riic here, Chris Brandt will add himself for
> that one later.
> 
> Signed-off-by: Wolfram Sang 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

Re: [PATCH 4/4] soc: renesas: rcar-rst: Add support for R-Car E3

[Geert Uytterhoeven]

Hi Shimoda-san,

Thanks for your patch!

On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds definition of reset vector for the R8A77990 SoC.

The description doesn't seem to match what the patch does?

> Signed-off-by: Takeshi Kihara 
> [shimoda: rebase]
> Signed-off-by: Yoshihiro Shimoda 

The actual patch contents are fine, so:
Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH 3/4] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

[Geert Uytterhoeven]

Hi Shimoda-san,

On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
> A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.

Thanks for your patch!

> NOTE:
> - The 3DG power domain resume order of R-Car E3 is [3DG-B] -> [3DG-A],

So 3DG-B is the parent of 3DG-A?
I have to take your word on this, as I cannot find this in the documentation.

>   which is different from R-Car H3, M3 and M3N SoCs.

M3-W and M3-N?

> Signed-off-by: Takeshi Kihara 
> [shimoda: add SPDX-License-Identifier]
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH 2/4] soc: renesas: Add r8a77990 SYSC PM Domain Binding Definitions

[Geert Uytterhoeven]

On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds power domain indices for R-Car E3.
>
> Signed-off-by: Takeshi Kihara 
> [shimoda: add commit log and SPDX-License-Identifier]
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH 1/4] soc: renesas: identify R-Car E3

[Geert Uytterhoeven]

On Wed, Apr 11, 2018 at 11:36 AM, Yoshihiro Shimoda
 wrote:
> From: Takeshi Kihara 
>
> This patch adds support for identifying the R-Car E3 (R8A77990) SoC.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH 3/3] arm64: renesas: Add Renesas R8A77990 Kconfig support

[Geert Uytterhoeven]

On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda
 wrote:
> Add configuration option for the R-Car E3 (R8A77990) SoC.
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH 2/3] dt-bindings: arm: Document Renesas Ebisu board DT bindings

[Geert Uytterhoeven]

On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda
 wrote:
> This patch adds device tree bindings documentation for Renesas
> Ebisu board (RTP0RC77990SEB0010S).
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

[PATCH v3 0/5] V3M-Eagle HDMI output enablement

[Jacopo Mondi]

Hello,
   I have rebased the Eagle display enablement on top of (part of) Sergei's
series:
 [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

Simon: you can skip "[1/5]  arm64: dts: renesas: r8a77970: add FCPVD support"
as you already collected that

Sergei: I re-sent your series because there was an additional comment from
Laurent on [3/5]. I felt it was wrong to send a follow up patch on a series
still not collected by Simon, so I've resent it. Hope this time is ok with you.
Also, please note that [5/5] of your original series shall be re-sent using
the newly introduced (still in-review) LVDS decoder. Please see [5/5] of this
series as an example.

Niklas: [5/5] of this series is a fixup of your patches and mine. I added
your signed-off-by, hope it is ok.

The series depends on THC63LVD1024 driver, currently submitted for inclusion
"[PATCH v8 0/2]  drm: Add Thine THC63LVD1024 LVDS decoder bridge"
currently available at:
git://jmondi.org/linux lvds-bridge/linus-master/v8

Thanks
   j

v2 -> v3:
- Use Sergei's series for patches [1-4] with a minor comment from Laurent
- Remove the lvds-decoder node label and add Laurent's Reviewed-by in [5/5]

v1 -> v2:
- Add Laurent's reviewed by tags
- Fixup patch 5, 6 and 7 of v1
- Remove DU digital output pin muxing
- Update thc63lvd1024 to use the new bindings with mandatory power supply
- Minor fixes (changes are described individually in each patch)

Jacopo Mondi (1):
  arm64: dts: renesas: eagle: Enable HDMI output

Sergei Shtylyov (4):
  arm64: dts: renesas: r8a77970: add FCPVD support
  arm64: dts: renesas: r8a77970: add VSPD support
  arm64: dts: renesas: r8a77970: add DU support
  arm64: dts: renesas: r8a77970: add LVDS support

 arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 93 ++
 arch/arm64/boot/dts/renesas/r8a77970.dtsi  | 75 +
 2 files changed, 168 insertions(+)

--
2.7.4

Re: [PATCH 1/3] dt-bindings: arm: Document R-Car E3 SoC DT bindings

[Geert Uytterhoeven]

On Wed, Apr 11, 2018 at 11:35 AM, Yoshihiro Shimoda
 wrote:
> This patch adds device tree bindings documentation for Renesas R-Car
> E3 (r8a77990).
>
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH v2 3/4] arm64: dts: renesas: r8a77970: add LVDS support

[niklas soderlund]

Hi Jacopo, Sergei,

On 2018-04-11 11:53:28 +0200, Jacopo Mondi wrote:
> Hi Sergei, Niklas
> 
> On Tue, Apr 10, 2018 at 08:12:36PM +0300, Sergei Shtylyov wrote:
> > On 04/10/2018 03:13 PM, jacopo mondi wrote:
> >
> > >>> From: Niklas Söderlund 
> > >>>
> > >>> Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
> > >>> the it to the LVDS output of the DU.
> > >>>
> > >>> Signed-off-by: Niklas Söderlund 
> > >>> Signed-off-by: Jacopo Mondi 
> > >>> Reviewed-by: Laurent Pinchart 
> > >>>
> > >>> ---
> > >>> v1 -> v2:
> > >>> - Rebased on the modified endpoint name and changed patch subject to
> > >>>   comply with other patches in the series from Sergei.
> > >>
> > >>Stop, what was wrong with my R8A77970 LVDS patch, reposted on the 
> > >> popular
> > >> demand? :-)
> > >>
> > >
> > > Nothing wrong, I found out about your right now.
> > > I see a very small difference as
> > >  lvds@feb9 vs lvds-encoder@feb9
> >
> >Yes, I thought the latter was closer to a "generic" name that DT spec 
> > requires...
> >
> > > You can add your signed-off-by ofc if you think that's the case.
> >
> >Didn't understand what you mean here...
> 
> Don't worry, I will resend this and use (part of) your series
> [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support
> 
> But please note that:
> [1/5] from your series has already been collected by Simon
> I have to reapply Laurent's comment on this series to your one (so I
> have to resend it anyhow)
> [5/5] from your series shall be resent to take into account the newly
> developed LVDS decoder driver (once it has been accepted)
> 
> I have anyway to repost your patches then, and as I did in this series
> you are ofc listed as author already, so I have missed what's the
> difference actually except from LVDS patch I collected from Niklas and not
> from your series.
> 
> Niklas I picked up patches 1-3 of this series from your tree.
> 1 and 2 are patches from Sergei's series
> 3 is from you but was also in Sergei's series and I picked yours as it
> was there already. Can I rebase on top of Sergei's one instead?

Yes please do so. And sorry for this mess, it is my fault as I missed 
one of Sergei's patches when integrating changes I made to 
r8a77970-eagle.dts. For this series always pick Sergei's patches over 
mine :-)

Once more sorry for the mess to both of you.

> 
> Thanks
>j



-- 
Regards,
Niklas Söderlund

RE: [PATCH] gpio: dwapb: Add support for 32 interrupts

[Phil Edworthy]

Hi Andy,

On 05 April 2018 10:43, Phil Edworthy wrote:
> On 30 March 2018 22:26 Andy Shevchenko wrote:
> > On Wed, Mar 28, 2018 at 5:22 PM, Phil Edworthy wrote:
> > > The DesignWare GPIO IP can be configured for either 1 or 32
> > > interrupts,
> >
> > 1 to 32, or just a choice between two?
> Just a choice of 1 or 32.
Sorry, I was wrong about this... the manual does not say 1 or 32. It says:
"Port A can be configured to generate multiple interrupt signals or
a single combined interrupt flag. When set to 1, the component generates a
single combined interrupt flag."

There is no other text describing this option, but I believe all GPIOs on
port A will have an interrupt. In our case we have 32 GPIOs on port A
and 32 interrupts connected to them.

Thanks
Phil

Re: [PATCH v2 3/4] arm64: dts: renesas: r8a77970: add LVDS support

[jacopo mondi]

Hi Sergei, Niklas

On Tue, Apr 10, 2018 at 08:12:36PM +0300, Sergei Shtylyov wrote:
> On 04/10/2018 03:13 PM, jacopo mondi wrote:
>
> >>> From: Niklas Söderlund 
> >>>
> >>> Add the LVDS device to r8a77970.dtsi in a disabled state. Also connect
> >>> the it to the LVDS output of the DU.
> >>>
> >>> Signed-off-by: Niklas Söderlund 
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Laurent Pinchart 
> >>>
> >>> ---
> >>> v1 -> v2:
> >>> - Rebased on the modified endpoint name and changed patch subject to
> >>>   comply with other patches in the series from Sergei.
> >>
> >>Stop, what was wrong with my R8A77970 LVDS patch, reposted on the 
> >> popular
> >> demand? :-)
> >>
> >
> > Nothing wrong, I found out about your right now.
> > I see a very small difference as
> >  lvds@feb9 vs lvds-encoder@feb9
>
>Yes, I thought the latter was closer to a "generic" name that DT spec 
> requires...
>
> > You can add your signed-off-by ofc if you think that's the case.
>
>Didn't understand what you mean here...

Don't worry, I will resend this and use (part of) your series
[PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

But please note that:
[1/5] from your series has already been collected by Simon
I have to reapply Laurent's comment on this series to your one (so I
have to resend it anyhow)
[5/5] from your series shall be resent to take into account the newly
developed LVDS decoder driver (once it has been accepted)

I have anyway to repost your patches then, and as I did in this series
you are ofc listed as author already, so I have missed what's the
difference actually except from LVDS patch I collected from Niklas and not
from your series.

Niklas I picked up patches 1-3 of this series from your tree.
1 and 2 are patches from Sergei's series
3 is from you but was also in Sergei's series and I picked yours as it
was there already. Can I rebase on top of Sergei's one instead?

Thanks
   j


signature.asc
Description: PGP signature

[PATCH 2/2] arm64: dts: renesas: Add Renesas Ebisu board support

[Yoshihiro Shimoda]

From: Takeshi Kihara 

Basic support for the Renesas Ebisu board based on R-Car E3:
  - Memory,
  - Main crystal,
  - Serial console,

Signed-off-by: Takeshi Kihara 
[shimoda: rebase and add SPDX-License-Identifier]
Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/Makefile   |  1 +
 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 37 ++
 2 files changed, 38 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts

diff --git a/arch/arm64/boot/dts/renesas/Makefile 
b/arch/arm64/boot/dts/renesas/Makefile
index 5ede060..a235961 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -10,4 +10,5 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb r8a77965-salvator-xs.dtb
 dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
 dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb
+dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
 dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts 
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
new file mode 100644
index 000..63ee134
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Device Tree Source for the ebisu board
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include "r8a77990.dtsi"
+
+/ {
+   model = "Renesas Ebisu board based on r8a77990";
+   compatible = "renesas,ebisu", "renesas,r8a77990";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   bootargs = "ignore_loglevel";
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@4800 {
+   device_type = "memory";
+   /* first 128MB is reserved for secure area. */
+   reg = <0x0 0x4800 0x0 0x3800>;
+   };
+};
+
+_clk {
+   clock-frequency = <4800>;
+};
+
+ {
+   status = "okay";
+};
-- 
1.9.1

[PATCH 0/2] arm64: dts: renesas: Add support for R-Car E3 and Ebisu board

[Yoshihiro Shimoda]

This patch is based on the renesas-drivers-2018-04-03-v4.16 tag of
renesas-drivers.git.

This code doesn't use dt-bindings definitions to avoid dependency.

Takeshi Kihara (1):
  arm64: dts: renesas: Add Renesas Ebisu board support

Yoshihiro Shimoda (1):
  arm64: dts: renesas: Add Renesas R8A77990 SoC support

 arch/arm64/boot/dts/renesas/Makefile   |   1 +
 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts |  37 +++
 arch/arm64/boot/dts/renesas/r8a77990.dtsi  | 131 +
 3 files changed, 169 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77990.dtsi

-- 
1.9.1

[PATCH 1/2] arm64: dts: renesas: Add Renesas R8A77990 SoC support

[Yoshihiro Shimoda]

This patch adds basic support for the Renesas R-Car E3 (R8A77990) SoC:
  - PSCI
  - CPU (single)
  - Cache controller
  - Main clocks and controller
  - Interrupt controller
  - Timer
  - PMU
  - Reset controller
  - Product register
  - System controller
  - UART for console

Inspried by a patch by Takeshi Kihara in the BSP.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 131 ++
 1 file changed, 131 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r8a77990.dtsi

diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
new file mode 100644
index 000..310bfd9
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -0,0 +1,131 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Device Tree Source for the r8a77990 SoC
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "renesas,r8a77990";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 1 core only at this point */
+   a53_0: cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0>;
+   device_type = "cpu";
+   power-domains = < 5>;
+   next-level-cache = <_CA53>;
+   enable-method = "psci";
+   };
+
+   L2_CA53: cache-controller@0 {
+   compatible = "cache";
+   reg = <0>;
+   power-domains = < 21>;
+   cache-unified;
+   cache-level = <2>;
+   };
+   };
+
+   extal_clk: extal {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   /* This value must be overridden by the board */
+   clock-frequency = <0>;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   soc: soc {
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   gic: interrupt-controller@f101 {
+   compatible = "arm,gic-400";
+   #interrupt-cells = <3>;
+   #address-cells = <0>;
+   interrupt-controller;
+   reg = <0x0 0xf101 0 0x1000>,
+ <0x0 0xf102 0 0x2>,
+ <0x0 0xf104 0 0x2>,
+ <0x0 0xf106 0 0x2>;
+   interrupts = ;
+   clocks = < CPG_MOD 408>;
+   clock-names = "clk";
+   power-domains = < 32>;
+   resets = < 408>;
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   };
+
+   pmu_a53 {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ;
+   interrupt-affinity = <_0>;
+   };
+
+   cpg: clock-controller@e615 {
+   compatible = "renesas,r8a77990-cpg-mssr";
+   reg = <0 0xe615 0 0x1000>;
+   clocks = <_clk>;
+   clock-names = "extal";
+   #clock-cells = <2>;
+   #power-domain-cells = <0>;
+   #reset-cells = <1>;
+   };
+
+   rst: reset-controller@e616 {
+   compatible = "renesas,r8a77990-rst";
+   reg = <0 0xe616 0 0x0200>;
+   };
+
+   prr: chipid@fff00044 {
+   compatible = "renesas,prr";
+   reg = <0 0xfff00044 0 4>;
+   };
+
+   sysc: system-controller@e618 {
+   compatible = "renesas,r8a77990-sysc";
+   reg = <0 0xe618 0 0x0400>;
+   #power-domain-cells = <1>;
+   };
+
+   scif2: serial@e6e88000 {
+   compatible = "renesas,scif-r8a77990",
+"renesas,rcar-gen3-scif", "renesas,scif";
+   reg = <0 0xe6e88000 0 64>;
+   interrupts = ;
+   clocks = < CPG_MOD 310>;
+   clock-names = "fck";
+   power-domains = < 32>;
+   

[PATCH 1/2] clk: renesas: Add r8a77990 CPG Core Clock Definitions

[Yoshihiro Shimoda]

From: Takeshi Kihara 

This patch adds all R-Car E3 Clock Pulse Generator Core Clock Outputs.

Note that internal CPG clocks (S0, S1, S2, S3, SDSRC) are not included,
as they are used as internal clock sources only, and never referenced
from DT.

Signed-off-by: Takeshi Kihara 
[shimoda: add SPDX-License-Identifier]
Signed-off-by: Yoshihiro Shimoda 
---
 include/dt-bindings/clock/r8a77990-cpg-mssr.h | 63 +++
 1 file changed, 63 insertions(+)
 create mode 100644 include/dt-bindings/clock/r8a77990-cpg-mssr.h

diff --git a/include/dt-bindings/clock/r8a77990-cpg-mssr.h 
b/include/dt-bindings/clock/r8a77990-cpg-mssr.h
new file mode 100644
index 000..c806fce
--- /dev/null
+++ b/include/dt-bindings/clock/r8a77990-cpg-mssr.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+#ifndef __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
+#define __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__
+
+#include 
+
+/* r8a77990 CPG Core Clocks */
+#define R8A77990_CLK_Z20
+#define R8A77990_CLK_ZR1
+#define R8A77990_CLK_ZG2
+#define R8A77990_CLK_ZTR   3
+#define R8A77990_CLK_ZT4
+#define R8A77990_CLK_ZX5
+#define R8A77990_CLK_S0D1  6
+#define R8A77990_CLK_S0D3  7
+#define R8A77990_CLK_S0D6  8
+#define R8A77990_CLK_S0D12 9
+#define R8A77990_CLK_S0D24 10
+#define R8A77990_CLK_S1D1  11
+#define R8A77990_CLK_S1D2  12
+#define R8A77990_CLK_S1D4  13
+#define R8A77990_CLK_S2D1  14
+#define R8A77990_CLK_S2D2  15
+#define R8A77990_CLK_S2D4  16
+#define R8A77990_CLK_S3D1  17
+#define R8A77990_CLK_S3D2  18
+#define R8A77990_CLK_S3D4  19
+#define R8A77990_CLK_S0D6C 20
+#define R8A77990_CLK_S3D1C 21
+#define R8A77990_CLK_S3D2C 22
+#define R8A77990_CLK_S3D4C 23
+#define R8A77990_CLK_LB24
+#define R8A77990_CLK_CL25
+#define R8A77990_CLK_ZB3   26
+#define R8A77990_CLK_ZB3D2 27
+#define R8A77990_CLK_CR28
+#define R8A77990_CLK_CRD2  29
+#define R8A77990_CLK_SD0H  30
+#define R8A77990_CLK_SD0   31
+#define R8A77990_CLK_SD1H  32
+#define R8A77990_CLK_SD1   33
+#define R8A77990_CLK_SD3H  34
+#define R8A77990_CLK_SD3   35
+#define R8A77990_CLK_RPC   36
+#define R8A77990_CLK_RPCD2 37
+#define R8A77990_CLK_ZA2   38
+#define R8A77990_CLK_ZA8   39
+#define R8A77990_CLK_Z2D   40
+#define R8A77990_CLK_CANFD 41
+#define R8A77990_CLK_MSO   42
+#define R8A77990_CLK_R 43
+#define R8A77990_CLK_OSC   44
+#define R8A77990_CLK_LV0   45
+#define R8A77990_CLK_LV1   46
+#define R8A77990_CLK_CSI0  47
+#define R8A77990_CLK_POST3 48
+#define R8A77990_CLK_CP49
+#define R8A77990_CLK_CPEX  50
+
+#endif /* __DT_BINDINGS_CLOCK_R8A77990_CPG_MSSR_H__ */
-- 
1.9.1

[PATCH 0/2] clk: renesas: Add support for R-Car E3

[Yoshihiro Shimoda]

This patch is based on the renesas-drivers-2018-04-03-v4.16 tag of
renesas-drivers.git.

Takeshi Kihara (1):
  clk: renesas: Add r8a77990 CPG Core Clock Definitions

Yoshihiro Shimoda (1):
  clk: renesas: cpg-mssr: Add support for R-Car E3

 .../devicetree/bindings/clock/renesas,cpg-mssr.txt |   3 +-
 drivers/clk/renesas/Kconfig|   5 +
 drivers/clk/renesas/Makefile   |   1 +
 drivers/clk/renesas/r8a77990-cpg-mssr.c| 291 +
 drivers/clk/renesas/renesas-cpg-mssr.c |   6 +
 drivers/clk/renesas/renesas-cpg-mssr.h |   1 +
 include/dt-bindings/clock/r8a77990-cpg-mssr.h  |  63 +
 7 files changed, 369 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/renesas/r8a77990-cpg-mssr.c
 create mode 100644 include/dt-bindings/clock/r8a77990-cpg-mssr.h

-- 
1.9.1

[PATCH 2/2] clk: renesas: cpg-mssr: Add support for R-Car E3

[Yoshihiro Shimoda]

Initial support for R-Car E3 (r8a77990), including core and module
clocks.

Based on the Table 8.2g of "R-Car Series, 3rd Generation User's Manual:
Hardware ((Rev. 0.80, Oct 31, 2017) with Manual Errata on Feb. 28, 2018".

Inspried by patches by Takeshi Kihara in the BSP.

Signed-off-by: Yoshihiro Shimoda 
---
 .../devicetree/bindings/clock/renesas,cpg-mssr.txt |   3 +-
 drivers/clk/renesas/Kconfig|   5 +
 drivers/clk/renesas/Makefile   |   1 +
 drivers/clk/renesas/r8a77990-cpg-mssr.c| 291 +
 drivers/clk/renesas/renesas-cpg-mssr.c |   6 +
 drivers/clk/renesas/renesas-cpg-mssr.h |   1 +
 6 files changed, 306 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/renesas/r8a77990-cpg-mssr.c

diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt 
b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
index c3473df..26b7bae 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -26,6 +26,7 @@ Required Properties:
   - "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
   - "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
   - "renesas,r8a77980-cpg-mssr" for the r8a77980 SoC (R-Car V3H)
+  - "renesas,r8a77990-cpg-mssr" for the r8a77995 SoC (R-Car E3)
   - "renesas,r8a77995-cpg-mssr" for the r8a77995 SoC (R-Car D3)
 
   - reg: Base address and length of the memory resource used by the CPG/MSSR
@@ -36,7 +37,7 @@ Required Properties:
   - clock-names: List of external parent clock names. Valid names are:
   - "extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7792,
 r8a7793, r8a7794, r8a7795, r8a7796, r8a77965, r8a77970,
-r8a77980, r8a77995)
+r8a77980, r8a77990, r8a77995)
   - "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
   - "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7793,
 r8a7794)
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index f32896fa..f9ba71311 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -19,6 +19,7 @@ config CLK_RENESAS
select CLK_R8A77965 if ARCH_R8A77965
select CLK_R8A77970 if ARCH_R8A77970
select CLK_R8A77980 if ARCH_R8A77980
+   select CLK_R8A77990 if ARCH_R8A77990
select CLK_R8A77995 if ARCH_R8A77995
select CLK_SH73A0 if ARCH_SH73A0
 
@@ -116,6 +117,10 @@ config CLK_R8A77980
bool "R-Car V3H clock support" if COMPILE_TEST
select CLK_RCAR_GEN3_CPG
 
+config CLK_R8A77990
+   bool "R-Car E3 clock support" if COMPILE_TEST
+   select CLK_RCAR_GEN3_CPG
+
 config CLK_R8A77995
bool "R-Car D3 clock support" if COMPILE_TEST
select CLK_RCAR_GEN3_CPG
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index a4edea9..fe5bac9 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_CLK_R8A7796) += r8a7796-cpg-mssr.o
 obj-$(CONFIG_CLK_R8A77965) += r8a77965-cpg-mssr.o
 obj-$(CONFIG_CLK_R8A77970) += r8a77970-cpg-mssr.o
 obj-$(CONFIG_CLK_R8A77980) += r8a77980-cpg-mssr.o
+obj-$(CONFIG_CLK_R8A77990) += r8a77990-cpg-mssr.o
 obj-$(CONFIG_CLK_R8A77995) += r8a77995-cpg-mssr.o
 obj-$(CONFIG_CLK_SH73A0)   += clk-sh73a0.o
 
diff --git a/drivers/clk/renesas/r8a77990-cpg-mssr.c 
b/drivers/clk/renesas/r8a77990-cpg-mssr.c
new file mode 100644
index 000..d345458
--- /dev/null
+++ b/drivers/clk/renesas/r8a77990-cpg-mssr.c
@@ -0,0 +1,291 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * r8a77990 Clock Pulse Generator / Module Standby and Software Reset
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ *
+ * Based on r8a7795-cpg-mssr.c
+ *
+ * Copyright (C) 2015 Glider bvba
+ * Copyright (C) 2015 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "renesas-cpg-mssr.h"
+#include "rcar-gen3-cpg.h"
+
+enum clk_ids {
+   /* Core Clock Outputs exported to DT */
+   LAST_DT_CORE_CLK = R8A77990_CLK_CPEX,
+
+   /* External Input Clocks */
+   CLK_EXTAL,
+
+   /* Internal Core Clocks */
+   CLK_MAIN,
+   CLK_PLL0,
+   CLK_PLL1,
+   CLK_PLL3,
+   CLK_PLL0D4,
+   CLK_PLL0D6,
+   CLK_PLL0D8,
+   CLK_PLL0D20,
+   CLK_PLL0D24,
+   CLK_PLL1D2,
+   CLK_PE,
+   CLK_S0,
+   CLK_S1,
+   CLK_S2,
+   CLK_S3,
+   CLK_SDSRC,
+
+   /* Module Clocks */
+   MOD_CLK_BASE
+};
+
+static const struct cpg_core_clk r8a77990_core_clks[] __initconst = {
+   /* External Clock Inputs */
+   DEF_INPUT("extal", CLK_EXTAL),
+
+   /* Internal Core Clocks */
+   DEF_BASE(".main",  CLK_MAIN, 

[PATCH 4/4] soc: renesas: rcar-rst: Add support for R-Car E3

[Yoshihiro Shimoda]

From: Takeshi Kihara 

This patch adds definition of reset vector for the R8A77990 SoC.

Signed-off-by: Takeshi Kihara 
[shimoda: rebase]
Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/reset/renesas,rst.txt | 1 +
 drivers/soc/renesas/Kconfig | 3 ++-
 drivers/soc/renesas/rcar-rst.c  | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt 
b/Documentation/devicetree/bindings/reset/renesas,rst.txt
index 7be61ef..67e83b0 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rst.txt
+++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
@@ -30,6 +30,7 @@ Required properties:
  - "renesas,r8a77965-rst" (R-Car M3-N)
  - "renesas,r8a77970-rst" (R-Car V3M)
  - "renesas,r8a77980-rst" (R-Car V3H)
+ - "renesas,r8a77990-rst" (R-Car E3)
  - "renesas,r8a77995-rst" (R-Car D3)
   - reg: Address start and address range for the device.
 
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 36bec60..1d824cb 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -4,7 +4,8 @@ config SOC_RENESAS
select SOC_BUS
select RST_RCAR if ARCH_RCAR_GEN1 || ARCH_RCAR_GEN2 || \
   ARCH_R8A7795 || ARCH_R8A7796 || ARCH_R8A77965 || \
-  ARCH_R8A77970 || ARCH_R8A77980 || ARCH_R8A77995
+  ARCH_R8A77970 || ARCH_R8A77980 || ARCH_R8A77990 || \
+  ARCH_R8A77995
select SYSC_R8A7743 if ARCH_R8A7743
select SYSC_R8A7745 if ARCH_R8A7745
select SYSC_R8A77470 if ARCH_R8A77470
diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
index 66d7dba..d9c1034 100644
--- a/drivers/soc/renesas/rcar-rst.c
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -60,6 +60,7 @@ struct rst_config {
{ .compatible = "renesas,r8a77965-rst", .data = _rst_gen3 },
{ .compatible = "renesas,r8a77970-rst", .data = _rst_gen3 },
{ .compatible = "renesas,r8a77980-rst", .data = _rst_gen3 },
+   { .compatible = "renesas,r8a77990-rst", .data = _rst_gen3 },
{ .compatible = "renesas,r8a77995-rst", .data = _rst_gen3 },
{ /* sentinel */ }
 };
-- 
1.9.1

[PATCH 3/4] soc: renesas: rcar-sysc: Add support for R-Car E3 power areas

[Yoshihiro Shimoda]

From: Takeshi Kihara 

This patch adds Cortex-A53 CPU{0,1}, Cortex-A53 SCU, Cortex-R7, A3VC,
A2VC1 and 3DG-{A,B} power domain areas for the R8A77990 SoC.

NOTE:
- The 3DG power domain resume order of R-Car E3 is [3DG-B] -> [3DG-A],
  which is different from R-Car H3, M3 and M3N SoCs.

Signed-off-by: Takeshi Kihara 
[shimoda: add SPDX-License-Identifier]
Signed-off-by: Yoshihiro Shimoda 
---
 .../bindings/power/renesas,rcar-sysc.txt   |  1 +
 drivers/soc/renesas/Kconfig|  5 
 drivers/soc/renesas/Makefile   |  1 +
 drivers/soc/renesas/r8a77990-sysc.c| 33 ++
 drivers/soc/renesas/rcar-sysc.c|  3 ++
 drivers/soc/renesas/rcar-sysc.h|  1 +
 6 files changed, 44 insertions(+)
 create mode 100644 drivers/soc/renesas/r8a77990-sysc.c

diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt 
b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
index 3e91d20..180ae65 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
@@ -21,6 +21,7 @@ Required properties:
   - "renesas,r8a77965-sysc" (R-Car M3-N)
   - "renesas,r8a77970-sysc" (R-Car V3M)
   - "renesas,r8a77980-sysc" (R-Car V3H)
+  - "renesas,r8a77990-sysc" (R-Car E3)
   - "renesas,r8a77995-sysc" (R-Car D3)
   - reg: Address start and address range for the device.
   - #power-domain-cells: Must be 1.
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 96dd936..36bec60 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -18,6 +18,7 @@ config SOC_RENESAS
select SYSC_R8A77965 if ARCH_R8A77965
select SYSC_R8A77970 if ARCH_R8A77970
select SYSC_R8A77980 if ARCH_R8A77980
+   select SYSC_R8A77990 if ARCH_R8A77990
select SYSC_R8A77995 if ARCH_R8A77995
 
 if SOC_RENESAS
@@ -75,6 +76,10 @@ config SYSC_R8A77980
bool "R-Car V3H System Controller support" if COMPILE_TEST
select SYSC_RCAR
 
+config SYSC_R8A77990
+   bool "R-Car E3 System Controller support" if COMPILE_TEST
+   select SYSC_RCAR
+
 config SYSC_R8A77995
bool "R-Car D3 System Controller support" if COMPILE_TEST
select SYSC_RCAR
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
index a86ece7..7dc0f20 100644
--- a/drivers/soc/renesas/Makefile
+++ b/drivers/soc/renesas/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SYSC_R8A7796)+= r8a7796-sysc.o
 obj-$(CONFIG_SYSC_R8A77965)+= r8a77965-sysc.o
 obj-$(CONFIG_SYSC_R8A77970)+= r8a77970-sysc.o
 obj-$(CONFIG_SYSC_R8A77980)+= r8a77980-sysc.o
+obj-$(CONFIG_SYSC_R8A77990)+= r8a77990-sysc.o
 obj-$(CONFIG_SYSC_R8A77995)+= r8a77995-sysc.o
 
 # Family
diff --git a/drivers/soc/renesas/r8a77990-sysc.c 
b/drivers/soc/renesas/r8a77990-sysc.c
new file mode 100644
index 000..bd4114b
--- /dev/null
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Renesas R-Car E3 System Controller
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "rcar-sysc.h"
+
+static const struct rcar_sysc_area r8a77990_areas[] __initconst = {
+   { "always-on",  0, 0, R8A77990_PD_ALWAYS_ON, -1, PD_ALWAYS_ON },
+   { "ca53-scu",   0x140, 0, R8A77990_PD_CA53_SCU,  R8A77990_PD_ALWAYS_ON,
+ PD_SCU },
+   { "ca53-cpu0",  0x200, 0, R8A77990_PD_CA53_CPU0, R8A77990_PD_CA53_SCU,
+ PD_CPU_NOCR },
+   { "ca53-cpu1",  0x200, 1, R8A77990_PD_CA53_CPU1, R8A77990_PD_CA53_SCU,
+ PD_CPU_NOCR },
+   { "cr7",0x240, 0, R8A77990_PD_CR7,  R8A77990_PD_ALWAYS_ON },
+   { "a3vc",   0x380, 0, R8A77990_PD_A3VC, R8A77990_PD_ALWAYS_ON },
+   { "a2vc1",  0x3c0, 1, R8A77990_PD_A2VC1,R8A77990_PD_A3VC },
+   { "3dg-b",  0x100, 1, R8A77990_PD_3DG_B,R8A77990_PD_ALWAYS_ON },
+   { "3dg-a",  0x100, 0, R8A77990_PD_3DG_A,R8A77990_PD_3DG_B },
+};
+
+const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
+   .areas = r8a77990_areas,
+   .num_areas = ARRAY_SIZE(r8a77990_areas),
+};
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 99203bd..95120ac 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -296,6 +296,9 @@ static void __init rcar_sysc_pd_setup(struct rcar_sysc_pd 
*pd)
 #ifdef CONFIG_SYSC_R8A77980
{ .compatible = "renesas,r8a77980-sysc", .data = _sysc_info },
 #endif
+#ifdef CONFIG_SYSC_R8A77990
+   { .compatible = "renesas,r8a77990-sysc", .data = _sysc_info },
+#endif
 #ifdef CONFIG_SYSC_R8A77995
{ .compatible = "renesas,r8a77995-sysc", .data = _sysc_info },
 #endif
diff --git 

[PATCH 0/4] soc: renesas: Add support for R-Car E3

[Yoshihiro Shimoda]

This patch is based on the renesas-drivers-2018-04-03-v4.16 tag of
renesas-drivers.git.

Takeshi Kihara (4):
  soc: renesas: identify R-Car E3
  soc: renesas: Add r8a77990 SYSC PM Domain Binding Definitions
  soc: renesas: rcar-sysc: Add support for R-Car E3 power areas
  soc: renesas: rcar-rst: Add support for R-Car E3

 .../bindings/power/renesas,rcar-sysc.txt   |  1 +
 .../devicetree/bindings/reset/renesas,rst.txt  |  1 +
 drivers/soc/renesas/Kconfig|  8 +-
 drivers/soc/renesas/Makefile   |  1 +
 drivers/soc/renesas/r8a77990-sysc.c| 33 ++
 drivers/soc/renesas/rcar-rst.c |  1 +
 drivers/soc/renesas/rcar-sysc.c|  3 ++
 drivers/soc/renesas/rcar-sysc.h|  1 +
 drivers/soc/renesas/renesas-soc.c  |  8 ++
 include/dt-bindings/power/r8a77990-sysc.h  | 26 +
 10 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/renesas/r8a77990-sysc.c
 create mode 100644 include/dt-bindings/power/r8a77990-sysc.h

-- 
1.9.1

[PATCH 2/4] soc: renesas: Add r8a77990 SYSC PM Domain Binding Definitions

[Yoshihiro Shimoda]

From: Takeshi Kihara 

This patch adds power domain indices for R-Car E3.

Signed-off-by: Takeshi Kihara 
[shimoda: add commit log and SPDX-License-Identifier]
Signed-off-by: Yoshihiro Shimoda 
---
 include/dt-bindings/power/r8a77990-sysc.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/dt-bindings/power/r8a77990-sysc.h

diff --git a/include/dt-bindings/power/r8a77990-sysc.h 
b/include/dt-bindings/power/r8a77990-sysc.h
new file mode 100644
index 000..944d85b
--- /dev/null
+++ b/include/dt-bindings/power/r8a77990-sysc.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+#ifndef __DT_BINDINGS_POWER_R8A77990_SYSC_H__
+#define __DT_BINDINGS_POWER_R8A77990_SYSC_H__
+
+/*
+ * These power domain indices match the numbers of the interrupt bits
+ * representing the power areas in the various Interrupt Registers
+ * (e.g. SYSCISR, Interrupt Status Register)
+ */
+
+#define R8A77990_PD_CA53_CPU0  5
+#define R8A77990_PD_CA53_CPU1  6
+#define R8A77990_PD_CR713
+#define R8A77990_PD_A3VC   14
+#define R8A77990_PD_3DG_A  17
+#define R8A77990_PD_3DG_B  18
+#define R8A77990_PD_CA53_SCU   21
+#define R8A77990_PD_A2VC1  26
+
+/* Always-on power area */
+#define R8A77990_PD_ALWAYS_ON  32
+
+#endif /* __DT_BINDINGS_POWER_R8A77990_SYSC_H__ */
-- 
1.9.1

[PATCH 1/4] soc: renesas: identify R-Car E3

[Yoshihiro Shimoda]

From: Takeshi Kihara 

This patch adds support for identifying the R-Car E3 (R8A77990) SoC.

Signed-off-by: Takeshi Kihara 
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/soc/renesas/renesas-soc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/soc/renesas/renesas-soc.c 
b/drivers/soc/renesas/renesas-soc.c
index 3912a71..d44d0e6 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -164,6 +164,11 @@ struct renesas_soc {
.id = 0x56,
 };
 
+static const struct renesas_soc soc_rcar_e3 __initconst __maybe_unused = {
+   .family = _rcar_gen3,
+   .id = 0x57,
+};
+
 static const struct renesas_soc soc_rcar_d3 __initconst __maybe_unused = {
.family = _rcar_gen3,
.id = 0x58,
@@ -236,6 +241,9 @@ struct renesas_soc {
 #ifdef CONFIG_ARCH_R8A77980
{ .compatible = "renesas,r8a77980", .data = _rcar_v3h },
 #endif
+#ifdef CONFIG_ARCH_R8A77990
+   { .compatible = "renesas,r8a77990", .data = _rcar_e3 },
+#endif
 #ifdef CONFIG_ARCH_R8A77995
{ .compatible = "renesas,r8a77995", .data = _rcar_d3 },
 #endif
-- 
1.9.1

[PATCH 3/3] arm64: renesas: Add Renesas R8A77990 Kconfig support

[Yoshihiro Shimoda]

Add configuration option for the R-Car E3 (R8A77990) SoC.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/Kconfig.platforms | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 2b1535c..d5aeac3 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -208,6 +208,12 @@ config ARCH_R8A77980
help
  This enables support for the Renesas R-Car V3H SoC.
 
+config ARCH_R8A77990
+   bool "Renesas R-Car E3 SoC Platform"
+   depends on ARCH_RENESAS
+   help
+ This enables support for the Renesas R-Car E3 SoC.
+
 config ARCH_R8A77995
bool "Renesas R-Car D3 SoC Platform"
depends on ARCH_RENESAS
-- 
1.9.1

[PATCH 0/3] arm64: renesas: Add Renesas R8A77990 support

[Yoshihiro Shimoda]

This patch is based on the renesas-drivers-2018-04-03-v4.16 tag of
renesas-drivers.git.

Yoshihiro Shimoda (3):
  dt-bindings: arm: Document R-Car E3 SoC DT bindings
  dt-bindings: arm: Document Renesas Ebisu board DT bindings
  arm64: renesas: Add Renesas R8A77990 Kconfig support

 Documentation/devicetree/bindings/arm/shmobile.txt | 4 
 arch/arm64/Kconfig.platforms   | 6 ++
 2 files changed, 10 insertions(+)

-- 
1.9.1

[PATCH 2/3] dt-bindings: arm: Document Renesas Ebisu board DT bindings

[Yoshihiro Shimoda]

This patch adds device tree bindings documentation for Renesas
Ebisu board (RTP0RC77990SEB0010S).

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 5d21d48..61b486f 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -71,6 +71,8 @@ Boards:
 compatible = "renesas,draak", "renesas,r8a77995"
   - Eagle (RTP0RC77970SEB0010S)
 compatible = "renesas,eagle", "renesas,r8a77970"
+  - Ebisu (RTP0RC77990SEB0010S)
+compatible = "renesas,ebisu", "renesas,r8a77990"
   - Genmai (RTK772100BC0BR)
 compatible = "renesas,genmai", "renesas,r7s72100"
   - GR-Peach (X28A-M01-E/F)
-- 
1.9.1

[PATCH 1/3] dt-bindings: arm: Document R-Car E3 SoC DT bindings

[Yoshihiro Shimoda]

This patch adds device tree bindings documentation for Renesas R-Car
E3 (r8a77990).

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt 
b/Documentation/devicetree/bindings/arm/shmobile.txt
index 4401369..5d21d48 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -47,6 +47,8 @@ SoCs:
 compatible = "renesas,r8a77970"
   - R-Car V3H (R8A77980)
 compatible = "renesas,r8a77980"
+  - R-Car E3 (R8A77990)
+compatible = "renesas,r8a77990"
   - R-Car D3 (R8A77995)
 compatible = "renesas,r8a77995"
 
-- 
1.9.1

[PATCH] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

If a device is part of a PM Domain (e.g. power and/or clock domain), its
power state is managed using Runtime PM.  Without Runtime PM, the device
may not be powered up, causing subtle failures, crashes, or system
lock-ups when the device is accessed by the guest.

Fix this by adding Runtime PM support, powering the device when the VFIO
device is opened by the guest.

Note that while more fine-grained power management could be implemented
on the guest side, if exported, this would be inherently unsafe, as
abusing it may kill the whole system.

Signed-off-by: Geert Uytterhoeven 
---
This depends on "[PATCH v3 2/2] vfio: platform: Add generic DT reset
support" due to a small contextual change (addition of "#include
").

 drivers/vfio/platform/vfio_platform_common.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index ef9b9e3220ebe939..4db0a143992c3353 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -249,6 +250,8 @@ static void vfio_platform_release(void *device_data)
const char *extra_dbg = NULL;
int ret;
 
+   pm_runtime_put(vdev->device);
+
ret = vfio_platform_call_reset(vdev, _dbg);
if (ret && vdev->reset_required) {
dev_warn(vdev->device, "reset driver is required and 
reset call failed in release (%d) %s\n",
@@ -291,6 +294,10 @@ static int vfio_platform_open(void *device_data)
 ret, extra_dbg ? extra_dbg : "");
goto err_rst;
}
+
+   ret = pm_runtime_get_sync(vdev->device);
+   if (ret < 0)
+   goto err_rst;
}
 
vdev->refcnt++;
@@ -706,6 +713,7 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
 
mutex_init(>igate);
 
+   pm_runtime_enable(vdev->device);
return 0;
 
 put_iommu:
@@ -723,6 +731,7 @@ struct vfio_platform_device 
*vfio_platform_remove_common(struct device *dev)
vdev = vfio_del_group_dev(dev);
 
if (vdev) {
+   pm_runtime_disable(vdev->device);
vfio_platform_put_reset(vdev);
vfio_iommu_group_put(dev->iommu_group, dev);
}
-- 
2.7.4

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

On Wed, Apr 11, 2018 at 11:15 AM, Geert Uytterhoeven
 wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM.  Without Runtime PM, the device
> may not be powered up, causing subtle failures, crashes, or system
> lock-ups when the device is accessed by the guest.
>
> Fix this by adding Runtime PM support, powering the device when the VFIO
> device is opened by the guest.
>
> Note that while more fine-grained power management could be implemented
> on the guest side, if exported, this would be inherently unsafe, as
> abusing it may kill the whole system.
>
> Signed-off-by: Geert Uytterhoeven 

Please ignore, this was sent accidentally with another series.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

[PATCH v3 1/2] vfio: platform: Fix reset module leak in error path

[Geert Uytterhoeven]

If the IOMMU group setup fails, the reset module is not released.

Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by 
default")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Eric Auger 
Reviewed-by: Simon Horman 
---
v3:
  - Add Reviewed-by,

v2:
  - Add Reviewed-by.
---
 drivers/vfio/platform/vfio_platform_common.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 35469af87f88678e..b60bb5326668498c 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -680,18 +680,23 @@ int vfio_platform_probe_common(struct 
vfio_platform_device *vdev,
group = vfio_iommu_group_get(dev);
if (!group) {
pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put_reset;
}
 
ret = vfio_add_group_dev(dev, _platform_ops, vdev);
-   if (ret) {
-   vfio_iommu_group_put(group, dev);
-   return ret;
-   }
+   if (ret)
+   goto put_iommu;
 
mutex_init(>igate);
 
return 0;
+
+put_iommu:
+   vfio_iommu_group_put(group, dev);
+put_reset:
+   vfio_platform_put_reset(vdev);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(vfio_platform_probe_common);
 
-- 
2.7.4

[PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Geert Uytterhoeven]

Vfio-platform requires reset support, provided either by ACPI, or, on DT
platforms, by a device-specific reset driver matching against the
device's compatible value.

On many SoCs, devices are connected to an SoC-internal reset controller.
If the reset hierarchy is described in DT using "resets" properties,
such devices can be reset in a generic way through the reset controller
subsystem.  Hence add support for this, avoiding the need to write
device-specific reset drivers for each single device on affected SoCs.

Devices that do require a more complex reset procedure can still provide
a device-specific reset driver, as that takes precedence.

Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
becomes a no-op (as in: "No reset function found for device") if reset
controller support is disabled.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Philipp Zabel 
---
v3:
  - Add Reviewed-by,
  - Merge similar checks in vfio_platform_has_reset(),

v2:
  - Don't store error values in vdev->reset_control,
  - Use of_reset_control_get_exclusive() instead of
__of_reset_control_get(),
  - Improve description.
---
 drivers/vfio/platform/vfio_platform_common.c  | 20 ++--
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index b60bb5326668498c..ef9b9e3220ebe939 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -112,11 +113,13 @@ static bool vfio_platform_has_reset(struct 
vfio_platform_device *vdev)
if (VFIO_PLATFORM_IS_ACPI(vdev))
return vfio_platform_acpi_has_reset(vdev);
 
-   return vdev->of_reset ? true : false;
+   return vdev->of_reset || vdev->reset_control;
 }
 
 static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
 {
+   struct reset_control *rstc;
+
if (VFIO_PLATFORM_IS_ACPI(vdev))
return vfio_platform_acpi_has_reset(vdev) ? 0 : -ENOENT;
 
@@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
vfio_platform_device *vdev)
vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>reset_module);
}
+   if (vdev->of_reset)
+   return 0;
+
+   rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
+   if (!IS_ERR(rstc)) {
+   vdev->reset_control = rstc;
+   return 0;
+   }
 
-   return vdev->of_reset ? 0 : -ENOENT;
+   return PTR_ERR(rstc);
 }
 
 static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
@@ -138,6 +149,8 @@ static void vfio_platform_put_reset(struct 
vfio_platform_device *vdev)
 
if (vdev->of_reset)
module_put(vdev->reset_module);
+
+   reset_control_put(vdev->reset_control);
 }
 
 static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
@@ -217,6 +230,9 @@ static int vfio_platform_call_reset(struct 
vfio_platform_device *vdev,
} else if (vdev->of_reset) {
dev_info(vdev->device, "reset\n");
return vdev->of_reset(vdev);
+   } else if (vdev->reset_control) {
+   dev_info(vdev->device, "reset\n");
+   return reset_control_reset(vdev->reset_control);
}
 
dev_warn(vdev->device, "no reset function found!\n");
diff --git a/drivers/vfio/platform/vfio_platform_private.h 
b/drivers/vfio/platform/vfio_platform_private.h
index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -60,6 +60,7 @@ struct vfio_platform_device {
const char  *compat;
const char  *acpihid;
struct module   *reset_module;
+   struct reset_control*reset_control;
struct device   *device;
 
/*
-- 
2.7.4

[PATCH v3 0/2] vfio: platform: Improve reset support

[Geert Uytterhoeven]

Hi all,

This patch series improves reset support for vfio-platform:
  - The first patch fixes a bug I ran into while working on this.
  - The second patch implements generic DT reset controller support, for
devices that are connected to an SoC-internal reset controller and
can be reset in a generic way.  This avoids having to write/change a
vfio-specific reset driver for each and every device to be
passed-through to a guest.

Changes compared to v2:
  - Add Reviewed-by,
  - Merge similar checks in vfio_platform_has_reset().

Changes compared to v1:
  - Add Reviewed-by,
  - Don't store error values in vdev->reset_control,
  - Use of_reset_control_get_exclusive() instead of
__of_reset_control_get(),
  - Improve description.

This has been tested on R-Car H3/Salvator-XS by exporting a GPIO module
to a QEMU+KWM guest: the GPIO module is reset before QEMU opens the vfio
device, and reset again after QEMU has released it, as can be witnessed
by the LEDs connected to the GPIOs.

Thanks!

Geert Uytterhoeven (2):
  vfio: platform: Fix reset module leak in error path
  vfio: platform: Add generic DT reset support

 drivers/vfio/platform/vfio_platform_common.c  | 35 +--
 drivers/vfio/platform/vfio_platform_private.h |  1 +
 2 files changed, 29 insertions(+), 7 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

[PATCH] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

If a device is part of a PM Domain (e.g. power and/or clock domain), its
power state is managed using Runtime PM.  Without Runtime PM, the device
may not be powered up, causing subtle failures, crashes, or system
lock-ups when the device is accessed by the guest.

Fix this by adding Runtime PM support, powering the device when the VFIO
device is opened by the guest.

Note that while more fine-grained power management could be implemented
on the guest side, if exported, this would be inherently unsafe, as
abusing it may kill the whole system.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/vfio/platform/vfio_platform_common.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 3c13327b2777f8ec..9d46fce2446daebe 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -255,6 +256,8 @@ static void vfio_platform_release(void *device_data)
const char *extra_dbg = NULL;
int ret;
 
+   pm_runtime_put(vdev->device);
+
ret = vfio_platform_call_reset(vdev, _dbg);
if (ret && vdev->reset_required) {
dev_warn(vdev->device, "reset driver is required and 
reset call failed in release (%d) %s\n",
@@ -297,6 +300,10 @@ static int vfio_platform_open(void *device_data)
 ret, extra_dbg ? extra_dbg : "");
goto err_rst;
}
+
+   ret = pm_runtime_get_sync(vdev->device);
+   if (ret < 0)
+   goto err_rst;
}
 
vdev->refcnt++;
@@ -712,6 +719,7 @@ int vfio_platform_probe_common(struct vfio_platform_device 
*vdev,
 
mutex_init(>igate);
 
+   pm_runtime_enable(vdev->device);
return 0;
 
 put_iommu:
@@ -729,6 +737,7 @@ struct vfio_platform_device 
*vfio_platform_remove_common(struct device *dev)
vdev = vfio_del_group_dev(dev);
 
if (vdev) {
+   pm_runtime_disable(vdev->device);
vfio_platform_put_reset(vdev);
vfio_iommu_group_put(dev->iommu_group, dev);
}
-- 
2.7.4

Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995

[jacopo mondi]

Hello Kaneko-san,

On Tue, Apr 03, 2018 at 09:43:02PM +0900, Yoshihiro Kaneko wrote:
> This series adds thermal support for r8a77995.
> R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
> Therefore this series adds r8a77995 support to rcar_thermal driver not
> rcar_gen3_thermal driver.

I tested this on D3 Draak.

I generated load expecting the detected temperature to rise.

It took a while, and I only see a slight increase of the temperature
reported by the 'temp' attribute.

# cat /sys/class/thermal/thermal_zone0/temp
3

# while :; do cat /dev/urandom > /dev/null; done
...(wait 2 minutes)

# cat /sys/class/thermal/thermal_zone0/temp
35000

(wait 30 seconds)

# cat /sys/class/thermal/thermal_zone0/temp
3

Is this result ok for your testing?

Thanks
  j
>
> This series is based on the next branch of Zhang Rui's linux tree.
>
> v3 [Yoshihiro Kaneko]
> * As suggested by Geert Uytterhoeven
> rcar_thermal.c:
> - make use_of_thermal in structure rcar_thermal_chip a single bit
> - add feature bits to rcar_thermal_chip
> - add the number of interrupts to rcar_thermal_chip
> - remove rcar_thermal_type in rcar_thermal_cip
> - make variable chip in rcar_thermal_probe() a const
>
> rcar-thermal.txt:
> * No change
>
> r8a77995.dtsi:
> * No change
>
>
> v2 [Yoshihiro Kaneko]
> * As suggested by Geert Uytterhoeven
> rcar_thermal.c:
> - remove rcar_of_data macro
> - store a pointer to rcar_thermal_chip in rcar_thermal_priv
> - remove unnecessary cast in rcar_thermal_dt_ids
>
> rcar-thermal.txt:
> - drop the fallback for D3
> - update the paragraph about interrupts
>
> r8a77995.dtsi:
> - fix the base address and the register addresses
> - drop the fallback
>
> Yoshihiro Kaneko (3):
>   thermal: rcar_thermal: add r8a77995 support
>   dt-bindings: thermal: rcar-thermal: add R8A77995 support
>   arm64: dts: renesas: r8a77995: add thermal device support
>
>  .../devicetree/bindings/thermal/rcar-thermal.txt   |   7 +-
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi  |  30 
>  drivers/thermal/rcar_thermal.c | 154 
> -
>  3 files changed, 157 insertions(+), 34 deletions(-)
>
> --
> 1.9.1
>


signature.asc
Description: PGP signature

RE: [PATCH] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Yoshihiro Shimoda]

Hi Heikki,

Thank you for the comments!

> From: Heikki Krogerus, Sent: Wednesday, April 11, 2018 5:02 PM
> 
> On Wed, Apr 11, 2018 at 03:15:23AM +, Yoshihiro Shimoda wrote:
> > > > +   host_node = of_parse_phandle(pdev->dev.of_node, "renesas,host", 
> > > > 0);
> > > > +   if (!host_node)
> > > > +   return -ENODEV;
> > > > +
> > > > +   pdev_host = of_find_device_by_node(host_node);
> > > > +   if (!pdev_host)
> > > > +   return -ENODEV;
> > > > +
> > > > +   of_node_put(host_node);
> > >
> > > Isn't what Heikki tried to solve with graphs and stuff like that?
> >
> > Heikki prepared "device connection" framework (devcon) [1] to get a device 
> > pointer.
> > However, IIUC, we need to improve the framework for device tree environment 
> > because:
> >  - The devcon needs each dev_name() through the endpoint array of struct 
> > device_connection.
> >  - Each dev_name() on device tree environment will be  > register>.,
> >f.e. "ee02.usb". So, I don???t think adding such strings to a driver 
> > is a good way.
> 
> That is how the build-in connection descriptions are handled, but in
> this case you want to describe them in your bindings, and to do that you
> should use remote-endpoints, ie. OF graph bindings: bindings/graph.txt

I understood it. As I mentioned other thread, I'll try to use the usb-connector 
bindings.

> > So, I wrote such a code by using existing APIs.
> > Should I improve the framework first somehow? Or, is my understanding 
> > incorrect?
> 
> You don't necessarily need to propose any changes to the device
> connection framework at this point, but you do need to use graph for
> describing that connection. Once we add device graph handling to the
> device connection framework, it is no problem to update this driver.

I got it.

> Of course, if you have time and interest in preparing a proposal for
> graph handling to the device connection framework, I would appreciate
> it.

I'll try to add graph handling to the device connection framework by
end of next week. If failed, I'll inform in this thread.

Best regards,
Yoshihiro Shimoda

> 
> Thanks,
> 
> --
> heikki

RE: [PATCH] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Yoshihiro Shimoda]

Hi Heikki,

> From: Heikki Krogerus, Sent: Wednesday, April 11, 2018 4:26 PM
> 
> On Tue, Apr 10, 2018 at 09:03:46PM +0900, Yoshihiro Shimoda wrote:

> > +Example of R-Car H3 ES2.0:
> > +   usb3_peri0: usb@ee02 {
> > +   compatible = "renesas,r8a7795-usb3-peri",
> > +"renesas,rcar-gen3-usb3-peri";
> > +   reg = <0 0xee02 0 0x400>;
> > +   interrupts = ;
> > +   clocks = < CPG_MOD 328>;
> > +   power-domains = < R8A7795_PD_ALWAYS_ON>;
> > +   resets = < 328>;
> > +
> > +   usb3-role-sw {
> > +   compatible = "renesas,rcar-usb3-role-switch";
> > +   renesas,host = <>;
> 
> I pretty sure you should model that connection using OF graph
> bindings. That way I believe this will also fit nicely to the
> usb-connector bindings. Check bindings/connector/usb-connector.txt

Oh, I didn't know the usb-connector bindings has been merged into the 
linux-next.
Thank you for the suggestion. I will try to use it.

Best regards,
Yoshihiro Shimoda

> > +   };
> > +   };
> 
> 
> Br,
> 
> --
> heikki

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

[Geert Uytterhoeven]

Hi Philipp,

On Wed, Apr 11, 2018 at 10:22 AM, Philipp Zabel  wrote:
> On Tue, 2018-04-10 at 17:53 +0200, Geert Uytterhoeven wrote:
>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>> platforms, by a device-specific reset driver matching against the
>> device's compatible value.
>>
>> On many SoCs, devices are connected to an SoC-internal reset controller.
>> If the reset hierarchy is described in DT using "resets" properties,
>> such devices can be reset in a generic way through the reset controller
>> subsystem.  Hence add support for this, avoiding the need to write
>> device-specific reset drivers for each single device on affected SoCs.
>>
>> Devices that do require a more complex reset procedure can still provide
>> a device-specific reset driver, as that takes precedence.
>>
>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>> becomes a no-op (as in: "No reset function found for device") if reset
>> controller support is disabled.
>>
>> Signed-off-by: Geert Uytterhoeven 
>
> Reviewed-by: Philipp Zabel 

Thanks!

>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
> [...]
>> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct 
>> vfio_platform_device *vdev)
>>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>>   >reset_module);
>>   }
>> + if (vdev->of_reset)
>> + return 0;
>> +
>> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
>
> If vdev->device->of_node == NULL, this will return -EINVAL ...
>
>> + if (!IS_ERR(rstc)) {
>> + vdev->reset_control = rstc;
>> + return 0;
>> + }
>>
>> - return vdev->of_reset ? 0 : -ENOENT;
>> + return PTR_ERR(rstc);
>
> ... instead of -ENOENT, if that makes any difference.

Not really. The single caller (vfio_platform_probe_common()) already returns
-EINVAL if no IOMMU group is found, so this should be handled fine.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

[Geert Uytterhoeven]

Hi Simon,

On Wed, Apr 11, 2018 at 10:22 AM, Simon Horman  wrote:
> On Tue, Apr 10, 2018 at 05:53:47PM +0200, Geert Uytterhoeven wrote:
>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>> platforms, by a device-specific reset driver matching against the
>> device's compatible value.
>>
>> On many SoCs, devices are connected to an SoC-internal reset controller.
>> If the reset hierarchy is described in DT using "resets" properties,
>> such devices can be reset in a generic way through the reset controller
>> subsystem.  Hence add support for this, avoiding the need to write
>> device-specific reset drivers for each single device on affected SoCs.
>>
>> Devices that do require a more complex reset procedure can still provide
>> a device-specific reset driver, as that takes precedence.
>>
>> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
>> becomes a no-op (as in: "No reset function found for device") if reset
>> controller support is disabled.
>>
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>> v2:
>>   - Don't store error values in vdev->reset_control,
>>   - Use of_reset_control_get_exclusive() instead of
>> __of_reset_control_get(),
>>   - Improve description.

>> --- a/drivers/vfio/platform/vfio_platform_common.c
>> +++ b/drivers/vfio/platform/vfio_platform_common.c
>> @@ -17,6 +17,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -112,11 +113,19 @@ static bool vfio_platform_has_reset(struct 
>> vfio_platform_device *vdev)
>>   if (VFIO_PLATFORM_IS_ACPI(vdev))
>>   return vfio_platform_acpi_has_reset(vdev);
>>
>> - return vdev->of_reset ? true : false;
>> + if (vdev->of_reset)
>> + return true;
>> +
>> + if (vdev->reset_control)
>> + return true;
>> +
>> + return false;
>
> I wonder if the above would be better expressed as:
>
> return vdev->of_reset || vdev->reset_control;

Makes sense, now both checks are of the same type.

>> @@ -217,6 +236,9 @@ static int vfio_platform_call_reset(struct 
>> vfio_platform_device *vdev,
>>   } else if (vdev->of_reset) {
>>   dev_info(vdev->device, "reset\n");
>>   return vdev->of_reset(vdev);
>> + } else if (vdev->reset_control) {
>> + dev_info(vdev->device, "reset\n");
>
> Would it be useful to differentiate between the above two informational
> messages?

Probably not, there's also no differentiation with the message for the
ACPI case above (out of visible context).

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995

[Kuninori Morimoto]

Hi Jacopo

> > This series adds thermal support for r8a77995.
> > R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
> > Therefore this series adds r8a77995 support to rcar_thermal driver not
> > rcar_gen3_thermal driver.
> >
> > This series is based on the next branch of Zhang Rui's linux tree.
> 
> Seems like I cannot find Zhang's tree anywhere. My google-fu is surely
> bad, but can you paste a link to the tree here below, please?

I don't know detail, but in general
you can find maintainer git repository from kernel.org

https://www.kernel.org/

you can find "Cgit" link, and find Zhang's one ?
Maybe you want is this ?

kernel/git/rzhang/linux.git Thermal Management  rzhang

Best regards
---
Kuninori Morimoto

Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995

[Geert Uytterhoeven]

Hi Jacopo,

On Wed, Apr 11, 2018 at 10:12 AM, jacopo mondi  wrote:
> On Tue, Apr 03, 2018 at 09:43:02PM +0900, Yoshihiro Kaneko wrote:
>> This series adds thermal support for r8a77995.
>> R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
>> Therefore this series adds r8a77995 support to rcar_thermal driver not
>> rcar_gen3_thermal driver.
>>
>> This series is based on the next branch of Zhang Rui's linux tree.
>
> Seems like I cannot find Zhang's tree anywhere. My google-fu is surely
> bad, but can you paste a link to the tree here below, please?

That tree is included in renesas-drivers:

  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995

[jacopo mondi]

I am sorry

On Wed, Apr 11, 2018 at 10:12:58AM +0200, jacopo mondi wrote:
> Hello Kaneko-san
>
> On Tue, Apr 03, 2018 at 09:43:02PM +0900, Yoshihiro Kaneko wrote:
> > This series adds thermal support for r8a77995.
> > R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
> > Therefore this series adds r8a77995 support to rcar_thermal driver not
> > rcar_gen3_thermal driver.
> >
> > This series is based on the next branch of Zhang Rui's linux tree.
>
> Seems like I cannot find Zhang's tree anywhere. My google-fu is surely
> bad, but can you paste a link to the tree here below, please?

It is clearly this one
https://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git/

Sorry for the noise :)
>
> Thanks
>j
>
> >
> > v3 [Yoshihiro Kaneko]
> > * As suggested by Geert Uytterhoeven
> > rcar_thermal.c:
> > - make use_of_thermal in structure rcar_thermal_chip a single bit
> > - add feature bits to rcar_thermal_chip
> > - add the number of interrupts to rcar_thermal_chip
> > - remove rcar_thermal_type in rcar_thermal_cip
> > - make variable chip in rcar_thermal_probe() a const
> >
> > rcar-thermal.txt:
> > * No change
> >
> > r8a77995.dtsi:
> > * No change
> >
> >
> > v2 [Yoshihiro Kaneko]
> > * As suggested by Geert Uytterhoeven
> > rcar_thermal.c:
> > - remove rcar_of_data macro
> > - store a pointer to rcar_thermal_chip in rcar_thermal_priv
> > - remove unnecessary cast in rcar_thermal_dt_ids
> >
> > rcar-thermal.txt:
> > - drop the fallback for D3
> > - update the paragraph about interrupts
> >
> > r8a77995.dtsi:
> > - fix the base address and the register addresses
> > - drop the fallback
> >
> > Yoshihiro Kaneko (3):
> >   thermal: rcar_thermal: add r8a77995 support
> >   dt-bindings: thermal: rcar-thermal: add R8A77995 support
> >   arm64: dts: renesas: r8a77995: add thermal device support
> >
> >  .../devicetree/bindings/thermal/rcar-thermal.txt   |   7 +-
> >  arch/arm64/boot/dts/renesas/r8a77995.dtsi  |  30 
> >  drivers/thermal/rcar_thermal.c | 154 
> > -
> >  3 files changed, 157 insertions(+), 34 deletions(-)
> >
> > --
> > 1.9.1
> >




signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers

[Simon Horman]

On Tue, Apr 10, 2018 at 09:49:14PM +0200, Wolfram Sang wrote:
> From: Wolfram Sang 
> 
> Intentionally missing i2c-riic here, Chris Brandt will add himself for
> that one later.
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

Re: [PATCH v2 1/2] MAINTAINERS: remove me as maintainer for I2C host drivers

[Simon Horman]

On Tue, Apr 10, 2018 at 09:49:13PM +0200, Wolfram Sang wrote:
> The number of I2C host controller drivers keeps increasing, and although
> I had some success acquiring specific driver maintainers, my bandwidth
> is by far not enough to act as a fallback for the rest of the drivers.
> To reflect this status-quo in MAINTAINERS, add a seperate entry for I2C
> host drivers, let the I2C list (= community) be the contact point, and
> mark this section as "Odd fixes".
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

[Philipp Zabel]

On Tue, 2018-04-10 at 17:53 +0200, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
> 
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem.  Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
> 
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
> 
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Philipp Zabel 

> ---
> v2:
>   - Don't store error values in vdev->reset_control,
>   - Use of_reset_control_get_exclusive() instead of
> __of_reset_control_get(),
>   - Improve description.
> ---
>  drivers/vfio/platform/vfio_platform_common.c  | 26 --
>  drivers/vfio/platform/vfio_platform_private.h |  1 +
>  2 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..3c13327b2777f8ec 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
[...]
> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct 
> vfio_platform_device *vdev)
>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>   >reset_module);
>   }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);

If vdev->device->of_node == NULL, this will return -EINVAL ...

> + if (!IS_ERR(rstc)) {
> + vdev->reset_control = rstc;
> + return 0;
> + }
>  
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(rstc);

... instead of -ENOENT, if that makes any difference.

regards
Philipp

Re: [PATCH v2 2/2] vfio: platform: Add generic DT reset controller support

[Simon Horman]

On Tue, Apr 10, 2018 at 05:53:47PM +0200, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
> 
> On many SoCs, devices are connected to an SoC-internal reset controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset controller
> subsystem.  Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
> 
> Devices that do require a more complex reset procedure can still provide
> a device-specific reset driver, as that takes precedence.
> 
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - Don't store error values in vdev->reset_control,
>   - Use of_reset_control_get_exclusive() instead of
> __of_reset_control_get(),
>   - Improve description.
> ---
>  drivers/vfio/platform/vfio_platform_common.c  | 26 --
>  drivers/vfio/platform/vfio_platform_private.h |  1 +
>  2 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index b60bb5326668498c..3c13327b2777f8ec 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -112,11 +113,19 @@ static bool vfio_platform_has_reset(struct 
> vfio_platform_device *vdev)
>   if (VFIO_PLATFORM_IS_ACPI(vdev))
>   return vfio_platform_acpi_has_reset(vdev);
>  
> - return vdev->of_reset ? true : false;
> + if (vdev->of_reset)
> + return true;
> +
> + if (vdev->reset_control)
> + return true;
> +
> + return false;

I wonder if the above would be better expressed as:

return vdev->of_reset || vdev->reset_control;

>  }
>  
>  static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
>  {
> + struct reset_control *rstc;
> +
>   if (VFIO_PLATFORM_IS_ACPI(vdev))
>   return vfio_platform_acpi_has_reset(vdev) ? 0 : -ENOENT;
>  
> @@ -127,8 +136,16 @@ static int vfio_platform_get_reset(struct 
> vfio_platform_device *vdev)
>   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
>   >reset_module);
>   }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, NULL);
> + if (!IS_ERR(rstc)) {
> + vdev->reset_control = rstc;
> + return 0;
> + }
>  
> - return vdev->of_reset ? 0 : -ENOENT;
> + return PTR_ERR(rstc);
>  }
>  
>  static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> @@ -138,6 +155,8 @@ static void vfio_platform_put_reset(struct 
> vfio_platform_device *vdev)
>  
>   if (vdev->of_reset)
>   module_put(vdev->reset_module);
> +
> + reset_control_put(vdev->reset_control);
>  }
>  
>  static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
> @@ -217,6 +236,9 @@ static int vfio_platform_call_reset(struct 
> vfio_platform_device *vdev,
>   } else if (vdev->of_reset) {
>   dev_info(vdev->device, "reset\n");
>   return vdev->of_reset(vdev);
> + } else if (vdev->reset_control) {
> + dev_info(vdev->device, "reset\n");

Would it be useful to differentiate between the above two informational
messages?

> + return reset_control_reset(vdev->reset_control);
>   }
>  
>   dev_warn(vdev->device, "no reset function found!\n");
> diff --git a/drivers/vfio/platform/vfio_platform_private.h 
> b/drivers/vfio/platform/vfio_platform_private.h
> index 85ffe5d9d1abd94e..a56e80ae5986540b 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -60,6 +60,7 @@ struct vfio_platform_device {
>   const char  *compat;
>   const char  *acpihid;
>   struct module   *reset_module;
> + struct reset_control*reset_control;
>   struct device   *device;
>  
>   /*
> -- 
> 2.7.4
> 

Re: [PATCH/RFT v3 0/3] thermal: add support for r8a77995

[jacopo mondi]

Hello Kaneko-san

On Tue, Apr 03, 2018 at 09:43:02PM +0900, Yoshihiro Kaneko wrote:
> This series adds thermal support for r8a77995.
> R-Car D3 (r8a77995) have a thermal sensor module which is similar to Gen2.
> Therefore this series adds r8a77995 support to rcar_thermal driver not
> rcar_gen3_thermal driver.
>
> This series is based on the next branch of Zhang Rui's linux tree.

Seems like I cannot find Zhang's tree anywhere. My google-fu is surely
bad, but can you paste a link to the tree here below, please?

Thanks
   j

>
> v3 [Yoshihiro Kaneko]
> * As suggested by Geert Uytterhoeven
> rcar_thermal.c:
> - make use_of_thermal in structure rcar_thermal_chip a single bit
> - add feature bits to rcar_thermal_chip
> - add the number of interrupts to rcar_thermal_chip
> - remove rcar_thermal_type in rcar_thermal_cip
> - make variable chip in rcar_thermal_probe() a const
>
> rcar-thermal.txt:
> * No change
>
> r8a77995.dtsi:
> * No change
>
>
> v2 [Yoshihiro Kaneko]
> * As suggested by Geert Uytterhoeven
> rcar_thermal.c:
> - remove rcar_of_data macro
> - store a pointer to rcar_thermal_chip in rcar_thermal_priv
> - remove unnecessary cast in rcar_thermal_dt_ids
>
> rcar-thermal.txt:
> - drop the fallback for D3
> - update the paragraph about interrupts
>
> r8a77995.dtsi:
> - fix the base address and the register addresses
> - drop the fallback
>
> Yoshihiro Kaneko (3):
>   thermal: rcar_thermal: add r8a77995 support
>   dt-bindings: thermal: rcar-thermal: add R8A77995 support
>   arm64: dts: renesas: r8a77995: add thermal device support
>
>  .../devicetree/bindings/thermal/rcar-thermal.txt   |   7 +-
>  arch/arm64/boot/dts/renesas/r8a77995.dtsi  |  30 
>  drivers/thermal/rcar_thermal.c | 154 
> -
>  3 files changed, 157 insertions(+), 34 deletions(-)
>
> --
> 1.9.1
>


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] vfio: platform: Fix reset module leak in error path

[Simon Horman]

On Tue, Apr 10, 2018 at 05:53:46PM +0200, Geert Uytterhoeven wrote:
> If the IOMMU group setup fails, the reset module is not released.
> 
> Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by 
> default")
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Eric Auger 

Reviewed-by: Simon Horman 

Re: [PATCH] MAINTAINERS: I'll maintain Renesas R-Car I2C host drivers

[Simon Horman]

There seems to be some room to enhance the subject, but otherwise:

Reviewed-by: Simon Horman 

On Tue, Apr 10, 2018 at 04:13:47PM +0200, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang 
> ---
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2f7ccdcf76f7..3bb87e65889c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11897,6 +11897,12 @@ L:   linux-...@vger.kernel.org
>  S:   Supported
>  F:   drivers/iio/adc/rcar_gyro_adc.c
>  
> +RENESAS R-CAR I2C DRIVERS
> +M:   Wolfram Sang 
> +S:   Supported
> +F:   drivers/i2c/busses/i2c-rcar.c
> +F:   drivers/i2c/busses/i2c-sh_mobile.c
> +
>  RENESAS USB PHY DRIVER
>  M:   Yoshihiro Shimoda 
>  L:   linux-renesas-soc@vger.kernel.org
> -- 
> 2.11.0
> 

Re: [PATCH] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Heikki Krogerus]

On Wed, Apr 11, 2018 at 03:15:23AM +, Yoshihiro Shimoda wrote:
> > > +   host_node = of_parse_phandle(pdev->dev.of_node, "renesas,host", 
> > > 0);
> > > +   if (!host_node)
> > > +   return -ENODEV;
> > > +
> > > +   pdev_host = of_find_device_by_node(host_node);
> > > +   if (!pdev_host)
> > > +   return -ENODEV;
> > > +
> > > +   of_node_put(host_node);
> > 
> > Isn't what Heikki tried to solve with graphs and stuff like that?
> 
> Heikki prepared "device connection" framework (devcon) [1] to get a device 
> pointer.
> However, IIUC, we need to improve the framework for device tree environment 
> because:
>  - The devcon needs each dev_name() through the endpoint array of struct 
> device_connection.
>  - Each dev_name() on device tree environment will be  register>.,
>f.e. "ee02.usb". So, I don???t think adding such strings to a driver 
> is a good way.

That is how the build-in connection descriptions are handled, but in
this case you want to describe them in your bindings, and to do that you
should use remote-endpoints, ie. OF graph bindings: bindings/graph.txt

> So, I wrote such a code by using existing APIs.
> Should I improve the framework first somehow? Or, is my understanding 
> incorrect?

You don't necessarily need to propose any changes to the device
connection framework at this point, but you do need to use graph for
describing that connection. Once we add device graph handling to the
device connection framework, it is no problem to update this driver.

Of course, if you have time and interest in preparing a proposal for
graph handling to the device connection framework, I would appreciate
it.


Thanks,

-- 
heikki

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

[Simon Horman]

On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> fix this user (until a better, system-wide solution is in place).
> 
> Signed-off-by: Wolfram Sang 
> Acked-by: Daniel Thompson 

Reviewed-by: Simon Horman 

> ---
> 
> Changes since V1:
>   * rebased to top-of-linus-tree
>   * added tag from Daniel, thanks!
> 
> Through which tree does this need to go?
> 
>  drivers/video/backlight/pwm_bl.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index 1c2289ddd555..0fa7d2bd0e48 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
>  
>   /*
>* If the GPIO is not known to be already configured as output, that
> -  * is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
> -  * change the direction to output and set the GPIO as active.
> +  * is, if gpiod_get_direction returns either 1 or -EINVAL, change the
> +  * direction to output and set the GPIO as active.
>* Do not force the GPIO to active when it was already output as it
>* could cause backlight flickering or we would enable the backlight too
>* early. Leave the decision of the initial backlight state for later.
>*/
>   if (pb->enable_gpio &&
> - gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)
> + gpiod_get_direction(pb->enable_gpio) != 0)
>   gpiod_direction_output(pb->enable_gpio, 1);
>  
>   pb->power_supply = devm_regulator_get(>dev, "power");
> -- 
> 2.11.0
> 

Re: [PATCH 1/2] usb: gadget: udc: renesas_usb3: add property "renesas,ignore-id"

[Simon Horman]

On Tue, Apr 10, 2018 at 09:13:53PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new property to ignore the ID signal on a board.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/usb/renesas_usb3.txt |  2 ++
>  drivers/usb/gadget/udc/renesas_usb3.c  | 10 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> index 2c071bb..53949bd 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> @@ -19,6 +19,8 @@ Required properties:
>  Optional properties:
>- phys: phandle + phy specifier pair
>- phy-names: must be "usb"
> +  - renesas,ignore-id: when a board doesn't use ID pin, you can add this
> +property to ignore the ID state.
>  
>  Example of R-Car H3 ES1.x:
>   usb3_peri0: usb@ee02 {
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 409cde4..59e1485 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -350,6 +350,7 @@ struct renesas_usb3 {
>   bool extcon_host;   /* check id and set EXTCON_USB_HOST */
>   bool extcon_usb;/* check vbus and set EXTCON_USB */
>   bool forced_b_device;
> + bool ignore_id;
>  };
>  
>  #define gadget_to_renesas_usb3(_gadget)  \
> @@ -645,6 +646,9 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
>  
>  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
>  {
> + if (usb3->ignore_id && !usb3->forced_b_device)
> + return;
> +
>   if (host)
>   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
>   else
> @@ -675,6 +679,9 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> bool host, bool a_dev)
>  
>  static bool usb3_is_a_device(struct renesas_usb3 *usb3)
>  {
> + if (usb3->ignore_id)
> + return false;
> +
>   return !(usb3_read(usb3, USB3_USB_OTG_STA) & USB_OTG_IDMON);
>  }
>  
> @@ -2632,6 +2639,9 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>   if (ret < 0)
>   goto err_add_udc;
>  
> + if (of_property_read_bool(pdev->dev.of_node, "renesas,no-id"))
> + usb3->ignore_id = true;

I wonder if this is better expressed as:

usb3->ignore_id = of_property_read_bool(pdev->dev.of_node,
"renesas,no-id"));

> +
>   ret = device_create_file(>dev, _attr_role);
>   if (ret < 0)
>   goto err_dev_create;
> -- 
> 1.9.1
> 

Re: [PATCH] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Heikki Krogerus]

On Tue, Apr 10, 2018 at 09:03:46PM +0900, Yoshihiro Shimoda wrote:
> This patch adds role switch support for R-Car SoCs. Some R-Car SoCs
> (e.g. R-Car H3) have USB 3.0 dual-role device controller which has
> the USB 3.0 xHCI host and Renesas USB 3.0 peripheral.
> 
> Unfortunately, the mode change register contains the USB 3.0 peripheral
> controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
> manages this register. However, in peripheral mode, the host should
> stop. Also the host hardware needs to reinitialize its own registers
> when the mode changes from peripheral to host mode. Otherwise,
> the host cannot work correctly (e.g. detect a device as high-speed).
> 
> To achieve this by a driver, this role switch driver manages
> the mode change register and attach/release the xhci-plat driver.
> The renesas_usb3 udc driver should call devm_of_platform_populate()
> to probe this driver.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../bindings/usb/renesas,rcar-usb3-role-sw.txt |  23 +++
>  drivers/usb/roles/Kconfig  |  12 ++
>  drivers/usb/roles/Makefile |   1 +
>  drivers/usb/roles/rcar-usb3-role-switch.c  | 200 
> +
>  4 files changed, 236 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
>  create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt 
> b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
> new file mode 100644
> index 000..752bc16
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
> @@ -0,0 +1,23 @@
> +Renesas Electronics R-Car USB 3.0 role switch driver
> +
> +A renesas_usb3's node can contain this node.
> +
> +Required properties:
> + - compatible: Must contain "renesas,rcar-usb3-role-switch".
> + - renesas,host: phandle of the usb3.0 host.
> +
> +Example of R-Car H3 ES2.0:
> + usb3_peri0: usb@ee02 {
> + compatible = "renesas,r8a7795-usb3-peri",
> +  "renesas,rcar-gen3-usb3-peri";
> + reg = <0 0xee02 0 0x400>;
> + interrupts = ;
> + clocks = < CPG_MOD 328>;
> + power-domains = < R8A7795_PD_ALWAYS_ON>;
> + resets = < 328>;
> +
> + usb3-role-sw {
> + compatible = "renesas,rcar-usb3-role-switch";
> + renesas,host = <>;

I pretty sure you should model that connection using OF graph
bindings. That way I believe this will also fit nicely to the
usb-connector bindings. Check bindings/connector/usb-connector.txt

> + };
> + };


Br,

-- 
heikki

Re: [PATCH 5/5] mmc: renesas_sdhi_internal_dmac: remove superfluous WARN

[Simon Horman]

On Tue, Apr 10, 2018 at 11:38:31AM +0200, Wolfram Sang wrote:
> The WARN can never trigger because we limited the max_seg number in
> renesas_sdhi_of_data already. Remove it and update the comment.
> 
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers

[Wolfram Sang]

> I guess that's why you're not adding a catch-all "RENESAS I2C DRIVERS"
> section?

Yes.



signature.asc
Description: PGP signature

Re: [PATCH 3/5] mmc: renesas_sdhi: Fix alignment check of sg buffer

[Simon Horman]

On Tue, Apr 10, 2018 at 11:38:29AM +0200, Wolfram Sang wrote:
> From: Masaharu Hayakawa 
> 
> Sometimes sg->offset is not used for buffer addresses allocated by
> dma_map_sg(), so alignment checks should be done on the allocated buffer
> addresses. Delete the alignment check for sg->offset that is done before
> dma_map_sg(). Instead, it performs the alignment check for
> sg->dma_address after dma_map_sg().
> 
> Signed-off-by: Masaharu Hayakawa 
> [Niklas: broke this commit in two and tidied small style issue]
> Signed-off-by: Niklas Söderlund 
> [rebased to mmc/next]
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

Re: [PATCH 2/5] mmc: renesas_sdhi: use helpers to access struct scatterlist members

[Simon Horman]

On Tue, Apr 10, 2018 at 11:38:28AM +0200, Wolfram Sang wrote:
> From: Niklas Söderlund 
> 
> Instead of directly accessing the members of struct scatterlist use the
> helpers mmc_get_dma_dir() and sg_dma_address() in
> renesas_sdhi_internal_dmac_start_dma(). Based on previous work by
> Masaharu Hayakawa.
> 
> Signed-off-by: Niklas Söderlund 
> [rebased to mmc/next]
> Signed-off-by: Wolfram Sang 

Reviewed-by: Simon Horman 

Re: [PATCH 1/5] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

[Simon Horman]

On Tue, Apr 10, 2018 at 11:38:27AM +0200, Wolfram Sang wrote:
> Early revisions of certain SoCs cannot do multiple DMA RX streams in
> parallel. To avoid data corruption, only allow one DMA RX channel and
> fall back to PIO, if needed.
> 
> Signed-off-by: Wolfram Sang 
> Reviewed-by: Yoshihiro Shimoda 
> Tested-by: Nguyen Viet Dung 
> ---
>  drivers/mmc/host/renesas_sdhi_internal_dmac.c | 35 
> ---
>  1 file changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c 
> b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> index 8e0acd197c43..9c50d64cd10c 100644
> --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> @@ -9,6 +9,7 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -62,6 +63,17 @@
>   *   need a custom accessor.
>   */
>  
> +static unsigned long global_flags;

Is the restriction on concurrent DMA RX streams global or per-device?

> +/*
> + * Workaround for avoiding to use RX DMAC by multiple channels.
> + * On R-Car H3 ES1.* and M3-W ES1.0, when multiple SDHI channels use
> + * RX DMAC simultaneously, sometimes hundreds of bytes data are not
> + * stored into the system memory even if the DMAC interrupt happened.
> + * So, this driver then uses one RX DMAC channel only.
> + */
> +#define SDHI_INTERNAL_DMAC_ONE_RX_ONLY   0
> +#define SDHI_INTERNAL_DMAC_RX_IN_USE 1
> +
>  /* Definitions for sampling clocks */
>  static struct renesas_sdhi_scc rcar_gen3_scc_taps[] = {
>   {
> @@ -126,6 +138,10 @@ renesas_sdhi_internal_dmac_abort_dma(struct 
> tmio_mmc_host *host) {
>   renesas_sdhi_internal_dmac_dm_write(host, DM_CM_RST,
>   RST_RESERVED_BITS | val);
>  
> +
> + if (host->data && host->data->flags & MMC_DATA_READ)
> + clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
>   renesas_sdhi_internal_dmac_enable_dma(host, true);
>  }
>  
> @@ -155,6 +171,9 @@ renesas_sdhi_internal_dmac_start_dma(struct tmio_mmc_host 
> *host,
>   if (data->flags & MMC_DATA_READ) {
>   dtran_mode |= DTRAN_MODE_CH_NUM_CH1;
>   dir = DMA_FROM_DEVICE;
> + if (test_bit(SDHI_INTERNAL_DMAC_ONE_RX_ONLY, _flags) &&
> + test_and_set_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, 
> _flags))
> + goto force_pio;
>   } else {
>   dtran_mode |= DTRAN_MODE_CH_NUM_CH0;
>   dir = DMA_TO_DEVICE;
> @@ -208,6 +227,9 @@ static void 
> renesas_sdhi_internal_dmac_complete_tasklet_fn(unsigned long arg)
>   renesas_sdhi_internal_dmac_enable_dma(host, false);
>   dma_unmap_sg(>pdev->dev, host->sg_ptr, host->sg_len, dir);
>  
> + if (dir == DMA_FROM_DEVICE)
> + clear_bit(SDHI_INTERNAL_DMAC_RX_IN_USE, _flags);
> +

Is clear_bit() expensive? If so it might be worth avoiding on SoCs that
don't have the restriction covered by this patch.

> +
>   tmio_mmc_do_data_irq(host);
>  out:
>   spin_unlock_irq(>lock);
> @@ -251,18 +273,25 @@ static const struct tmio_mmc_dma_ops 
> renesas_sdhi_internal_dmac_dma_ops = {
>   * implementation as others may use a different implementation.
>   */
>  static const struct soc_device_attribute gen3_soc_whitelist[] = {
> -{ .soc_id = "r8a7795", .revision = "ES1.*" },
> +{ .soc_id = "r8a7795", .revision = "ES1.*",
> +   .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
>  { .soc_id = "r8a7795", .revision = "ES2.0" },
> -{ .soc_id = "r8a7796", .revision = "ES1.0" },
> +{ .soc_id = "r8a7796", .revision = "ES1.0",
> +   .data = (void *)BIT(SDHI_INTERNAL_DMAC_ONE_RX_ONLY) },
>  { .soc_id = "r8a77995", .revision = "ES1.0" },
>  { /* sentinel */ }
>  };
>  
>  static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
>  {
> - if (!soc_device_match(gen3_soc_whitelist))
> + const struct soc_device_attribute *soc = 
> soc_device_match(gen3_soc_whitelist);
> +
> + if (!soc)
>   return -ENODEV;
>  
> + if (soc->data)
> + global_flags |= (unsigned long)soc->data;
> +
>   return renesas_sdhi_probe(pdev, _sdhi_internal_dmac_dma_ops);
>  }
>  
> -- 
> 2.11.0
> 

Re: [PATCH v2 2/2] MAINTAINERS: add maintainer for Renesas I2C related drivers

[Geert Uytterhoeven]

Hi Wolfram,

On Tue, Apr 10, 2018 at 9:49 PM, Wolfram Sang  wrote:
> From: Wolfram Sang 
>
> Intentionally missing i2c-riic here, Chris Brandt will add himself for
> that one later.

I guess that's why you're not adding a catch-all "RENESAS I2C DRIVERS"
section?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [PATCH 4/4] usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udc

[Simon Horman]

On Tue, Apr 10, 2018 at 09:44:31AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> > From: Simon Horman, Sent: Tuesday, April 10, 2018 6:34 PM
> > 
> > On Tue, Apr 10, 2018 at 01:28:33AM +, Yoshihiro Shimoda wrote:
> > > Hi Simon-san,
> > >
> > > > From: Simon Horman, Sent: Monday, April 9, 2018 8:58 PM
> > > >
> > > > On Mon, Apr 02, 2018 at 09:21:34PM +0900, Yoshihiro Shimoda wrote:
> > > > > This patch fixes an issue that this driver cannot call phy_init()
> > > > > if a gadget driver is alreadly loaded because usb_add_gadget_udc()
> > > > > might call renesas_usb3_start() via .udc_start.
> > > > >
> > > > > Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for 
> > > > > generic phy")
> > > > > Cc:  # v4.15+
> > > > > Signed-off-by: Yoshihiro Shimoda 
> > > > > ---
> > > > >  drivers/usb/gadget/udc/renesas_usb3.c | 16 
> > > > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > >
> > > > Reviewed-by: Simon Horman 
> > > >
> > > >
> > > > Please see some suggestions for follow-up lower-priority patches below.
> > >
> > > Thank you for the review and suggestions!
> > >
> > > > >
> > > > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > > > index 738b734..671bac3 100644
> > > > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > > > @@ -2632,6 +2632,14 @@ static int renesas_usb3_probe(struct 
> > > > > platform_device *pdev)
> > > > >   if (ret < 0)
> > > > >   goto err_alloc_prd;
> > > > >
> > > > > + /*
> > > > > +  * This is an optional. So, if this driver cannot get a phy,
> > > > > +  * this driver will not handle a phy anymore.
> > > > > +  */
> > > >
> > > > nit: s/an optional/optional/
> > >
> > > Oops. I will fix and submit v2 patches.
> > >
> > > > > + usb3->phy = devm_phy_get(>dev, "usb");
> > > > > + if (IS_ERR(usb3->phy))
> > > > > + usb3->phy = NULL;
> > > >
> > > > I think this will unintentionally ignore errors other than the
> > > > non-existence of the device, f.e. a memory allocation failure
> > > > in devm_phy_get().
> > > >
> > > > So perhaps something like this, as per phy_optional_get(), would be 
> > > > better?
> > > >
> > > > usb3->phy = devm_phy_get(>dev, "usb");
> > > > if (IS_ERR(usb3->phy) && (PTR_ERR(usb3->phy) == -ENODEV))
> > > > usb3->phy = NULL;
> > >
> > > Thank you for the suggestion. I agree with you.
> > > I think I should use devm_phy_optional_get() instead of dev_phy_get(), as 
> > > you mentioned :)
> > > So, I will fix the code by using devm_phy_optional_get() first, and then 
> > > fix this.
> > 
> > Thanks, I agree that would be a good fix.
> > 
> > But perhaps it is better as a follow-up?
> 
> Oops. Yes, I changed my mind after prepared the patch v2 and submitted v2.
> I should have sent an email about this to you...
> Anyway, thank you very much for reviewing the v2 patches!

v2 looks good to me :)