Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Frank,

On Friday, 23 February 2018 21:43:17 EET Frank Rowand wrote:
> On 02/23/18 01:00, Laurent Pinchart wrote:
> > On Friday, 23 February 2018 04:38:06 EET Frank Rowand wrote:
> >> On 02/22/18 14:10, Frank Rowand wrote:
> >>> Hi Laurent, Rob,
> >>> 
> >>> Thanks for the prompt spin to address my concerns.  There are some small
> >>> technical issues.
> >>> 
> >>> I did not read the v3 patch until today.  v3 through v6 are still using
> >>> the old overlay apply method which uses an expanded device tree as
> >>> input.
> >>> 
> >>> Rob, I don't see my overlay patches in you for-next branch, and I have
> >>> not seen an "Applied" message from you.  What is the status of the
> >>> overlay patches?
> >>> 
> >>> Comments in the patch below.
> >>> 
> >>> On 02/22/18 05:13, Laurent Pinchart wrote:
>  The internal LVDS encoders now have their own DT bindings. Before
>  switching the driver infrastructure to those new bindings, implement
>  backward-compatibility through live DT patching.
>  
>  Patching is disabled and will be enabled along with support for the new
>  DT bindings in the DU driver.
>  
>  Signed-off-by: Laurent Pinchart
>  
>  ---
>  Changes since v5:
>  
>  - Use a private copy of rcar_du_of_changeset_add_property()
>  
>  Changes since v3:
>  
>  - Use the OF changeset API
>  - Use of_graph_get_endpoint_by_regs()
>  - Replace hardcoded constants by sizeof()
>  
>  Changes since v2:
>  
>  - Update the SPDX headers to use C-style comments in header files
>  - Removed the manually created __local_fixups__ node
>  - Perform manual fixups on live DT instead of overlay
>  
>  Changes since v1:
>  
>  - Select OF_FLATTREE
>  - Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
>  - Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
>  - Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
>  - Pass void begin and end pointers to rcar_du_of_get_overlay()
>  - Use of_get_parent() instead of accessing the parent pointer directly
>  - Find the LVDS endpoints nodes based on the LVDS node instead of the
>    root of the overlay
>  - Update to the -lvds compatible string format
>  ---
>  
>   drivers/gpu/drm/rcar-du/Kconfig|   2 +
>   drivers/gpu/drm/rcar-du/Makefile   |   7 +-
>   drivers/gpu/drm/rcar-du/rcar_du_of.c   | 342 +
>   drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 +
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
>   9 files changed, 661 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts
>  
>  diff --git a/drivers/gpu/drm/rcar-du/Kconfig
>  b/drivers/gpu/drm/rcar-du/Kconfig index 5d0b4b7119af..3f83352a7313
>  100644
>  --- a/drivers/gpu/drm/rcar-du/Kconfig
>  +++ b/drivers/gpu/drm/rcar-du/Kconfig
> >> 
> >> < snip >
> >> 
> >>> becomes:
> >>>   ret = of_overlay_fdt_apply(dtb->begin, _id);
> >>> 
> >>> If my overlay patches do not exist, there are other small errors
> >>> in the code block above.  I'll ignore them for the moment.

If you have time to not ignore them I'd appreciate your comments :-) I'd like 
to get this patch series merged in v4.17, and for that I want to be prepared 
to submit it on top of your overlay patches if they make it to mainline, or 
without them if they don't.

> >>> A quick scan of the rest of the code looks OK.  I'll read through it
> >>> more carefully, but wanted to get this reply out without further
> >>> delay.
> >> 
> >> < snip >
> >> 
> >> I was hoping to be able to convert the .dts files to use sugar syntax
> >> instead of hand coding the fragment nodes, but for this specific set
> >> of files I failed, since the labels that would have been required do
> >> not already exist in the base .dts files that that overlays would be
> >> applied against.
> > 
> > And even if they existed in the base .dts in the kernel sources, there's
> > no guarantee that the .dtb on the systems we want to patch would contain
> > symbol, so that 

Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Frank Rowand]

On 02/23/18 01:00, Laurent Pinchart wrote:
> Hi Frank,
> 
> On Friday, 23 February 2018 04:38:06 EET Frank Rowand wrote:
>> On 02/22/18 14:10, Frank Rowand wrote:
>>> Hi Laurent, Rob,
>>>
>>> Thanks for the prompt spin to address my concerns.  There are some small
>>> technical issues.
>>>
>>> I did not read the v3 patch until today.  v3 through v6 are still using
>>> the old overlay apply method which uses an expanded device tree as input.
>>>
>>> Rob, I don't see my overlay patches in you for-next branch, and I have
>>> not seen an "Applied" message from you.  What is the status of the
>>> overlay patches?
>>>
>>> Comments in the patch below.
>>>
>>> On 02/22/18 05:13, Laurent Pinchart wrote:
 The internal LVDS encoders now have their own DT bindings. Before
 switching the driver infrastructure to those new bindings, implement
 backward-compatibility through live DT patching.

 Patching is disabled and will be enabled along with support for the new
 DT bindings in the DU driver.

 Signed-off-by: Laurent Pinchart
 
 ---
 Changes since v5:

 - Use a private copy of rcar_du_of_changeset_add_property()

 Changes since v3:

 - Use the OF changeset API
 - Use of_graph_get_endpoint_by_regs()
 - Replace hardcoded constants by sizeof()

 Changes since v2:

 - Update the SPDX headers to use C-style comments in header files
 - Removed the manually created __local_fixups__ node
 - Perform manual fixups on live DT instead of overlay

 Changes since v1:

 - Select OF_FLATTREE
 - Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
 - Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
 - Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
 - Pass void begin and end pointers to rcar_du_of_get_overlay()
 - Use of_get_parent() instead of accessing the parent pointer directly
 - Find the LVDS endpoints nodes based on the LVDS node instead of the
   root of the overlay
 - Update to the -lvds compatible string format
 ---

  drivers/gpu/drm/rcar-du/Kconfig|   2 +
  drivers/gpu/drm/rcar-du/Makefile   |   7 +-
  drivers/gpu/drm/rcar-du/rcar_du_of.c   | 342 +++
  drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 +
  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
  9 files changed, 661 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts

 diff --git a/drivers/gpu/drm/rcar-du/Kconfig
 b/drivers/gpu/drm/rcar-du/Kconfig index 5d0b4b7119af..3f83352a7313
 100644
 --- a/drivers/gpu/drm/rcar-du/Kconfig
 +++ b/drivers/gpu/drm/rcar-du/Kconfig
>>
>> < snip >
>>
>>> becomes:
>>> ret = of_overlay_fdt_apply(dtb->begin, _id);
>>>
>>> If my overlay patches do not exist, there are other small errors
>>> in the code block above.  I'll ignore them for the moment.
>>>
>>> A quick scan of the rest of the code looks OK.  I'll read through it
>>> more carefully, but wanted to get this reply out without further
>>> delay.
>>
>> < snip >
>>
>> I was hoping to be able to convert the .dts files to use sugar syntax
>> instead of hand coding the fragment nodes, but for this specific set
>> of files I failed, since the labels that would have been required do
>> not already exist in the base .dts files that that overlays would be
>> applied against.
> 
> And even if they existed in the base .dts in the kernel sources, there's no 
> guarantee that the .dtb on the systems we want to patch would contain symbol, 
> so that wouldn't have been an option anyway, would it ?

Correct.  And even more troublesome is that some of the fragments are
targeted at node "/", which dtc does not even allow a label on (at the
moment).


> 
>> Oh well.  It was an interesting exercise anyway, trying to be crafty.
> 

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Frank Rowand]

On 02/23/18 01:25, Laurent Pinchart wrote:
> Hi Frank,
> 
> On Friday, 23 February 2018 05:20:43 EET Frank Rowand wrote:
>> On 02/22/18 02:25, Laurent Pinchart wrote:
>>> On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote:
 On 02/20/18 15:10, Laurent Pinchart wrote:
> Hello,
>
> This patch series addresses a design mistake that dates back from the
> initial DU support. Support for the LVDS encoders, which are IP cores
> separate from the DU, was bundled in the DU driver. Worse, both the DU
> and LVDS were described through a single DT node.
>
> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS
> encoders, and deprecate their description inside the DU bindings. To
> retain backward compatibility with existing DT, patches 03/16 to 08/16
> then patch the device tree at runtime to convert the legacy bindings to
> the new ones.
>
> With the DT side addressed, patch 09/16 converts the LVDS support code
> to a separate bridge driver. Patches 11/16 to 16/16 then update all the
> device tree sources to the new DU and LVDS encoders bindings.
>
> I decided to go for live DT patching in patch 08/16 because implementing
> support for both the legacy and new bindings in the driver would have
> been very intrusive, and prevented further cleanups. This version relies
> more heavily on overlays to avoid touching the internals of the OF core
> compared to v2, even if manual fixes to the device tree are still
> needed.
>
> Compared to v3, this series uses the OF changeset API to update
> properties instead of accessing the internals of the property structure.
> This removes the local implementation of functions to look up nodes by
> path and update properties. In order to do this, I pulled in Pantelis'
> patch series titled "[PATCH v2 0/5] of: dynamic: Changesets helpers &
> fixes" at Rob's request, and rebased it while taking two small review
> comments into account.

 Wait a minute!  Why are you putting a patch set to modify core devicetree
 in the middle of a driver series.  Please pull it out to a separate
 series.
>>>
>>> Because Rob asked for the driver-local implementation of the property add
>>> function to be replaced by Pantelis' series. I want to get the LVDS
>>> changes in v4.17 and asked Rob whether I could then take the OF changeset
>>> patches merged through the DRM tree, and he didn't object. If that causes
>>> an issue I'll switch back to the driver-local implementation to get the
>>> driver changes merged, split the OF changeset series out, and then move
>>> to the OF changeset API once merged. Would you prefer that ?
>>
>> You have already created a new version of the R-Car patches without the
>> set of patches that I was objecting to here.  So this is somewhat just
>> an academic comment.
>>
>> As I mentioned in the v6 thread, I am coming back here to clean up loose
>> ends, and explain why I had the reaction I had.  Basically, this is a
>> process issue to me.
>>
>> (1) The patch set from Pantelis is "hidden" in the driver patch series.
>> When viewing collapsed threads (which is my normal mode to avoid getting
>> overwhelmed by the vast volume of email I scan), the Pantelis patch set
>> is totally invisible.  If the R-Car driver patch series had not had me
>> on the to: list, there is a very good chance I would not have noticed
>> it.  Or noticed in a more delayed time frame.  And the same applies to
>> anyone else who might be subscribed to the devicetree mail list.  If
>> the Pantelis patch series was split out into a separate patch set then
>> it would be more visible on the list.
>>
>> (2) There is no good way to indicate in the email subject lines for
>> the Pantelis patches that they are version 3 of the series, since
>> they are also version 4 of the R-Car patch series.  If one reads the
>> patch 0/0 header carefully, and/or the other Pantelis patch comment
>> headers carefully, and then does a little detective work, it is
>> possible to find version 2 of the Pantelis patch series, and thus
>> be able to track the full history.  If just glancing at each
>> individual patch email subject, scanning the patch comment, and
>> spending more time reading the body of the patch, it would be
>> very easy to overlook the existence of the previous versions on
>> the mail list.
>>
>> (2b) Small quibble:  if the Pantelis patches were in a separate series,
>> with v3 in the subject header, then you would have normally put
>> a "changes since v2" section in the patch comment header, which would
>> have been more visible and less cryptic than what you wrote, which was:
>>
>>...
>>
>>Signed-off-by: Pantelis Antoniou 
>>[Fixed memory leak in __of_changeset_add_update_property_copy()]
>>Signed-off-by: Laurent Pinchart
>> 
>>---
>> 

Re: [PATCH] ARM: dts: porter: Add missing PMIC nodes

[Simon Horman]

On Sun, Feb 18, 2018 at 04:07:51PM +0100, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> CC Steve Twiss
> 
> On Sat, Feb 17, 2018 at 3:07 AM, Marek Vasut  wrote:
> > Add PMIC nodes to Porter and connect CPU DVFS supply. There is
> > one DA9063 and one DA9210 on Porter, the only difference from
> > the other boards is that DA9063 is at I2C address 0x5a rather
> > than 0x58 .
> >
> > Signed-off-by: Marek Vasut 
> 
> Thanks for your patch!
> 
> > --- a/arch/arm/boot/dts/r8a7791-porter.dts
> > +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> > @@ -354,10 +354,47 @@
> > clock-frequency = <40>;
> >  };
> >
> > + {
> > +   status = "okay";
> > +   clock-frequency = <10>;
> > +
> > +   pmic@5a {
> > +   compatible = "dlg,da9063";
> 
> Does it matter that this is a DA9063L ("Variant 6B")?
> Do we need a new compatible value, or can this be detected at runtime?

Hi Marek,

could you follow up on this?

> > +   reg = <0x5a>;
> > +   interrupt-parent = <>;
> > +   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> > +   interrupt-controller;
> > +
> > +   rtc {
> > +   compatible = "dlg,da9063-rtc";
> > +   };
> > +
> > +   wdt {
> > +   compatible = "dlg,da9063-watchdog";
> > +   };
> > +   };
> > +
> > +   vdd_dvfs: regulator@68 {
> > +   compatible = "dlg,da9210";
> > +   reg = <0x68>;
> > +   interrupt-parent = <>;
> > +   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> > +
> > +   regulator-min-microvolt = <100>;
> > +   regulator-max-microvolt = <100>;
> > +   regulator-boot-on;
> > +   regulator-always-on;
> > +   };
> > +};
> > +
> >   {
> > status = "okay";
> >  };
> >
> > + {
> > +   cpu0-supply = <_dvfs>;
> > +};
> > +
> >  /* composite video input */
> >   {
> > status = "okay";
> 
> 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 00/02] ARM: dts: silk: Add EEPROM and GPIO keys

[Simon Horman]

On Mon, Feb 19, 2018 at 08:49:33PM +0900, Magnus Damm wrote:
> ARM: dts: silk: Add EEPROM and GPIO keys
> 
> [PATCH 01/02] ARM: dts: silk: Add r1ex24002 EEPROM to DT
> [PATCH 02/02] ARM: dts: silk: Add GPIO keys to DT
> 
> This series updates the DTS for the R-Car E2-based Silk board to support an
> EEPROM connected via I2C and GPIO based tactile switches. Based on the Gose
> board support and adjusted to fit the board schematics.
> 
> Signed-off-by: Magnus Damm 

Thanks, applied.

Re: [PATCH] ARM: dts: marzen: Add SDHI0 VCCQ Regulator

[Simon Horman]

On Mon, Feb 19, 2018 at 09:37:58PM +0900, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Add support for the on-board voltage regulator hooked up to GPIO3_20
> on r8a7779 Marzen. The board schematics describes the regulator as U4
> TPS2110A. Input wise, U4 has D0 fixed to ground, D1 tied to GPIO3_20
> while IN1 is fixed to 3.3V and IN2 is fixed to 1.8V. OUT goes to the
> pull-ups for the data pins of SDHI0.
> 
> Signed-off-by: Magnus Damm 

Thanks Magnus, applied.

Re: [PATCH v2] arm64: dts: renesas: Add support for Salvator-XS with R-Car M3-N

[Simon Horman]

On Mon, Feb 19, 2018 at 07:20:55PM +0100, Geert Uytterhoeven wrote:
> From: Takeshi Kihara 
> 
> Add initial support for the Renesas Salvator-XS (Salvator-X 2nd version)
> development board equipped with an R-Car M3-N SiP.
> 
> Most features are enabled through the shared salvator-xs.dtsi board
> description.  The memory configuration is specific to the M3-N SiP.
> 
> Signed-off-by: Takeshi Kihara 
> [geert: Switch to SPDX-License-Identifier, update patch description]
> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - Fix patch prefix.

Thanks, applied.

Re: [PATCH] arm64: defconfig: enable R8A77965 SoC

[Vladimir Zapolskiy]

Hi Simon,

On 02/23/2018 10:51 AM, Simon Horman wrote:
> Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.

If I'm not mistaken in my tardy note, then M3-W is R8A7796 and R8A77965 is 
M3-N, no?

--
With best wishes,
Vladimir

Re: [PATCH v2 19/19] ARM64: dts: r8a77965: Add EtherAVB device node

[Simon Horman]

On Fri, Feb 23, 2018 at 08:06:11AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Feb 22, 2018 at 4:54 PM, Simon Horman  wrote:
> > On Wed, Feb 21, 2018 at 09:53:58PM +0300, Sergei Shtylyov wrote:
> >> On 02/21/2018 09:23 PM, Simon Horman wrote:
> >>
> >> > ...
> >> >
> >>  +clocks = < CPG_MOD 812>;
> >>  +power-domains = < 32>;
> >>  +resets = < 812>;
> >>  +phy-mode = "rgmii-txid";
> >> >>>
> >> >>>Why not just "rgmii"? TX delay is a board specific detail, no?
> >> >>>
> >> >> I admit I took this one straight from r8a7796 dtsi.
> >> >> Would you like to me resend and change this?
> >> >
> >> >Yes, unless Simon would fix it while merging...
> >> 
> >>  Can I confirm the desired change is s/rgmii-txid/rgmii/ ?
> >> >>>
> >> >>>Yes.
> >> >>
> >> >>Apparently that means that this prop should be overridden in the 
> >> >> board file
> >> >> (which may not be an easy task given the board is Salvator-XS again).
> >> >>
> >> >> [...]
> >> >
> >> > Can we override it in r8a77965-salvator-x.dts or 
> >> > r8a77965-salvator-xs.dts?
> >>
> >>In salvator-common.dtsi most probably -- it has the PHY data for Ether 
> >> AVB.
> >>
> >> > I feel that I'm missing an important point here.
> >>
> >>Well, r8a779{5|6}.dtsi also have phy-mode = "rgmii-txid" (which was
> >>unjustified in my current understanding). Thus such board override
> >>wouldn't hurt them. But we lack a patch modifying salvator-common.dtsi
> >>in htis series, so I'm now thinking a respin of this series is needed
> >>anyway... sorry for being unclear. :-)
> >
> > While I've applied other patches in this series I have
> > not applied this one - mainly to allow this discussion to conclude.
> >
> > Is an appropriate solution to do the following?
> >
> > 1) Atomically update
> >a) r8a779{5|6}.dtsi to use "rgmii" and
> >b) salvator-common.dtsi to use "rgmii-txid"
> > 2) Update this patch to use "rgmii"
> 
> No need for atomics.
> It can all be done by patches touching single files only:
>   1) Add "rgmii-txid" to board .dts(i) files,
>   2) Change s/rgmii-txid/rgmii/ in SoC .dtsi files.

Sounds good.

Jacopo would you care to:

a) Implement the above rgmii-txid / rgmii update.
b) Rebase this patch on top of that update and [PATCH v2 0/7] R-Car M3-N
   DTS fixes

Re: [PATCH] arm64: defconfig: enable R8A77965 SoC

[Simon Horman]

On Fri, Feb 23, 2018 at 10:19:45AM +0100, Geert Uytterhoeven wrote:
> On Fri, Feb 23, 2018 at 9:51 AM, Simon Horman
>  wrote:
> > Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.
> >
> > Signed-off-by: Simon Horman 
> 
> Acked-by: Geert Uytterhoeven 

I have applied this to the topic/renesas-defconfig branch which is included
in the devel branch and tags of the Renesas tree as a convenience to
developers.  The branch is not, however, included in the next branch or
tags nor is it targeted at upstream.

Re: [PATCH] arm64: defconfig: enable R8A77965 SoC

[Simon Horman]

On Fri, Feb 23, 2018 at 10:19:45AM +0100, Geert Uytterhoeven wrote:
> On Fri, Feb 23, 2018 at 9:51 AM, Simon Horman
>  wrote:
> > Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.
> >
> > Signed-off-by: Simon Horman 
> 
> Acked-by: Geert Uytterhoeven 

Thanks, applied.

Re: [PATCH v2 0/7] R-Car M3-N DTS fixes

[Simon Horman]

On Fri, Feb 23, 2018 at 02:40:52PM +0100, Jacopo Mondi wrote:
> Hello,
>in this second iteration I have fixed two remarks from Geert received on
> v1:
> - Extend "du" address length to include third channel
> - Move usb2_phy1 device node next to usb2_phy0
> 
> Two minor nits were not addressed:
> - "placeholder" comment position not changed to maintain consistency with
>   placeholders in M3-W. When they'll get changed, let's change all of them at
>   the same time.
> - The addresses block sizes (and multiple address range blocks) are still 
> there
>   (next time we can consider dropping the unit address from place-holder nodes
>   and do not add any "reg" property at all, until DTC won't start complaining
>   about this as well)
> 
> All patches but the newly introduced 7/7 now have Geert's Reviewed-by tag.
> 
> Simon: as per v1, this series is based on my M3-N enablement series, last
> patch on Ether-AVB excluded.
> 
> Thanks
>j
> 
> v1 -> v2:
> - Extend "du" address length to include third channel
> - Move usb2_phy1 node next to usb2_phy0
> 
> Jacopo Mondi (7):
>   arm64: dts: renesas: r8a77965: Add "reg" properties
>   arm64: dts: renesas: r8a77965: Add #address-cells and #size-cells
>   arm64: dts: renesas: r8a77965: Remove stale reg property
>   arm64: dts: renesas: r8a77965: Add #phy-cells property
>   arm64: dts: renesas: r8a77965: Add #pwm-cells property
>   arm64: dts: renesas: r8a77965: Add #interrupt-cells property
>   arm64: dts: renesas: r8a77965: Move usb2_phy1 up
> 
>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 89 
> +--

Thanks, applied.

Re: [PATCH] PCI: rcar-gen2: remove duplicated bit-wise or of RCAR_PCI_INT_SIGRETABORT

[Lorenzo Pieralisi]

On Fri, Feb 23, 2018 at 12:29:49PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Bit pattern RCAR_PCI_INT_SIGRETABORT is being bit-wise or'd twice;
> remove the redundant 2nd RCAR_PCI_INT_SIGRETABORT.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/pci/host/pci-rcar-gen2.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-rcar-gen2.c 
> b/drivers/pci/host/pci-rcar-gen2.c

Applied to pci/rcar for v4.17, thanks !

Lorenzo

> index a28370bb2b2a..dd4f1a6b57c5 100644
> --- a/drivers/pci/host/pci-rcar-gen2.c
> +++ b/drivers/pci/host/pci-rcar-gen2.c
> @@ -52,7 +52,6 @@
>  #define RCAR_PCI_INT_B   (1 << 17)
>  #define RCAR_PCI_INT_PME (1 << 19)
>  #define RCAR_PCI_INT_ALLERRORS (RCAR_PCI_INT_SIGTABORT   | \
> - RCAR_PCI_INT_SIGRETABORT| \
>   RCAR_PCI_INT_SIGRETABORT| \
>   RCAR_PCI_INT_REMABORT   | \
>   RCAR_PCI_INT_PERR   | \
> -- 
> 2.15.1
> 

Re: [PATCH v2 3/9] serial: imx: Fix out-of-bounds access through serial port index

[Uwe Kleine-König]

On Fri, Feb 23, 2018 at 02:38:31PM +0100, Geert Uytterhoeven wrote:
> The imx_ports[] array is indexed using a value derived from the
> "serialN" alias in DT, or from platform data, which may lead to an
> out-of-bounds access.
> 
> Fix this by adding a range check.
> 
> Fixes: ff05967a07225ab6 ("serial/imx: add of_alias_get_id() reference back")
> Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Uwe Kleine-König 

Thanks for your time
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

[PATCH v2 1/9] serial: arc_uart: Fix out-of-bounds access through DT alias

[Geert Uytterhoeven]

The arc_uart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_ARC_NR_PORTS), so this can even be triggered using a
legitimate DTB.

Fixes: ea28fd56fcde69af ("serial/arc-uart: switch to devicetree based probing")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Use ARRAY_SIZE().
---
 drivers/tty/serial/arc_uart.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/tty/serial/arc_uart.c b/drivers/tty/serial/arc_uart.c
index 2599f9ecccfe7769..d904a3a345e74785 100644
--- a/drivers/tty/serial/arc_uart.c
+++ b/drivers/tty/serial/arc_uart.c
@@ -593,6 +593,11 @@ static int arc_serial_probe(struct platform_device *pdev)
if (dev_id < 0)
dev_id = 0;
 
+   if (dev_id >= ARRAY_SIZE(arc_uart_ports)) {
+   dev_err(>dev, "serial%d out of range\n", dev_id);
+   return -EINVAL;
+   }
+
uart = _uart_ports[dev_id];
port = >port;
 
-- 
2.7.4

[PATCH v2 9/9] serial: xuartps: Fix out-of-bounds access through DT alias

[Geert Uytterhoeven]

The cdns_uart_port[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Fixes: 928e9263492069ee ("tty: xuartps: Initialize ports according to aliases")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference.
---
 drivers/tty/serial/xilinx_uartps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c 
b/drivers/tty/serial/xilinx_uartps.c
index b9b2bc76bcac606c..abcb4d09a2d866d0 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1110,7 +1110,7 @@ static struct uart_port *cdns_uart_get_port(int id)
struct uart_port *port;
 
/* Try the given port id if failed use default method */
-   if (cdns_uart_port[id].mapbase != 0) {
+   if (id < CDNS_UART_NR_PORTS && cdns_uart_port[id].mapbase != 0) {
/* Find the next unused port */
for (id = 0; id < CDNS_UART_NR_PORTS; id++)
if (cdns_uart_port[id].mapbase == 0)
-- 
2.7.4

[PATCH v2 4/9] serial: mxs-auart: Fix out-of-bounds access through serial port index

[Geert Uytterhoeven]

The auart_port[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.

Fix this by adding a range check.

Fixes: 1ea6607d4cdc9179 ("serial: mxs-auart: Allow device tree probing")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Use ARRAY_SIZE(),
  - Update patch description for platform data.
---
 drivers/tty/serial/mxs-auart.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 079dc47aa142d8e1..caa8a41b6e71df9e 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1663,6 +1663,10 @@ static int mxs_auart_probe(struct platform_device *pdev)
s->port.line = pdev->id < 0 ? 0 : pdev->id;
else if (ret < 0)
return ret;
+   if (s->port.line >= ARRAY_SIZE(auart_port)) {
+   dev_err(>dev, "serial%d out of range\n", s->port.line);
+   return -EINVAL;
+   }
 
if (of_id) {
pdev->id_entry = of_id->data;
-- 
2.7.4

[PATCH v2 0/7] R-Car M3-N DTS fixes

[Jacopo Mondi]

Hello,
   in this second iteration I have fixed two remarks from Geert received on
v1:
- Extend "du" address length to include third channel
- Move usb2_phy1 device node next to usb2_phy0

Two minor nits were not addressed:
- "placeholder" comment position not changed to maintain consistency with
  placeholders in M3-W. When they'll get changed, let's change all of them at
  the same time.
- The addresses block sizes (and multiple address range blocks) are still there
  (next time we can consider dropping the unit address from place-holder nodes
  and do not add any "reg" property at all, until DTC won't start complaining
  about this as well)

All patches but the newly introduced 7/7 now have Geert's Reviewed-by tag.

Simon: as per v1, this series is based on my M3-N enablement series, last
patch on Ether-AVB excluded.

Thanks
   j

v1 -> v2:
- Extend "du" address length to include third channel
- Move usb2_phy1 node next to usb2_phy0

Jacopo Mondi (7):
  arm64: dts: renesas: r8a77965: Add "reg" properties
  arm64: dts: renesas: r8a77965: Add #address-cells and #size-cells
  arm64: dts: renesas: r8a77965: Remove stale reg property
  arm64: dts: renesas: r8a77965: Add #phy-cells property
  arm64: dts: renesas: r8a77965: Add #pwm-cells property
  arm64: dts: renesas: r8a77965: Add #interrupt-cells property
  arm64: dts: renesas: r8a77965: Move usb2_phy1 up

 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 89 +--
 1 file changed, 84 insertions(+), 5 deletions(-)

--
2.7.4

[PATCH v2 1/7] arm64: dts: renesas: r8a77965: Add "reg" properties

[Jacopo Mondi]

Add "reg" properties to place-holder nodes with unit address defined for
R-Car M3-N SoC.

This silences the following DTC compiler warning:
Warning (unit_address_vs_reg): Node /soc/... has a unit name,
but no reg property

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 

---
v1 -> v2:
- Extend "du" address length to include third channel
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 51 +++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 55f05f7..4286453 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -317,6 +317,7 @@
};
 
intc_ex: interrupt-controller@e61c {
+   reg = <0 0xe61c 0 0x200>;
/* placeholder */
};
 
@@ -520,130 +521,163 @@
};
 
avb: ethernet@e680 {
+   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
/* placeholder */
};
 
csi20: csi2@fea8 {
+   reg = <0 0xfea8 0 0x1>;
/* placeholder */
};
 
csi40: csi2@feaa {
+   reg = <0 0xfeaa 0 0x1>;
/* placeholder */
};
 
vin0: video@e6ef {
+   reg = <0 0xe6ef 0 0x1000>;
/* placeholder */
};
 
vin1: video@e6ef1000 {
+   reg = <0 0xe6ef1000 0 0x1000>;
/* placeholder */
};
 
vin2: video@e6ef2000 {
+   reg = <0 0xe6ef2000 0 0x1000>;
/* placeholder */
};
 
vin3: video@e6ef3000 {
+   reg = <0 0xe6ef3000 0 0x1000>;
/* placeholder */
};
 
vin4: video@e6ef4000 {
+   reg = <0 0xe6ef4000 0 0x1000>;
/* placeholder */
};
 
vin5: video@e6ef5000 {
+   reg = <0 0xe6ef5000 0 0x1000>;
/* placeholder */
};
 
vin6: video@e6ef6000 {
+   reg = <0 0xe6ef6000 0 0x1000>;
/* placeholder */
};
 
vin7: video@e6ef7000 {
+   reg = <0 0xe6ef7000 0 0x1000>;
/* placeholder */
};
 
ohci0: usb@ee08 {
+   reg = <0 0xee08 0 0x100>;
/* placeholder */
};
 
ehci0: usb@ee080100 {
+   reg = <0 0xee080100 0 0x100>;
/* placeholder */
};
 
usb2_phy0: usb-phy@ee080200 {
+   reg = <0 0xee080200 0 0x700>;
/* placeholder */
};
 
ohci1: usb@ee0a {
+   reg = <0 0xee0a 0 0x100>;
/* placeholder */
};
 
ehci1: usb@ee0a0100 {
+   reg = <0 0xee0a0100 0 0x100>;
/* placeholder */
};
 
i2c0: i2c@e650 {
+   reg = <0 0xe650 0 0x40>;
/* placeholder */
};
 
i2c1: i2c@e6508000 {
+   reg = <0 0xe6508000 0 0x40>;
/* placeholder */
};
 
i2c2: i2c@e651 {
+   reg = <0 0xe651 0 0x40>;
/* placeholder */
};
 
i2c3: i2c@e66d {
+   reg = <0 0xe66d 0 0x40>;
/* placeholder */
};
 
i2c4: i2c@e66d8000 {
+   reg = <0 0xe66d8000 0 0x40>;
/* placeholder */
};
 
i2c5: i2c@e66e {
+   reg = <0 0xe66e 0 0x40>;
/* placeholder */
};
 
i2c6: i2c@e66e8000 {
+   reg = <0 0xe66e8000 0 0x40>;
/* placeholder */
};
 
i2c_dvfs: i2c@e60b {
+   reg = <0 0xe60b 0 0x425>;
/* placeholder */
};
 
pwm0: pwm@e6e3 {
+   reg = <0 0xe6e3 0 8>;
/* placeholder */
};
 
pwm1: pwm@e6e31000 {
+   reg = <0 

[PATCH v2 2/7] arm64: dts: renesas: r8a77965: Add #address-cells and #size-cells

[Jacopo Mondi]

Add "#address-cells" and "#size-cells" properties to all place-holder nodes
that have children nodes defined by salvator-x[s].dtsi device tree.

This silences the following DTC compiler warnings:
Warning (reg_format): "reg" property in /soc/.. has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells
value for /soc/...
Warning (avoid_default_addr_size): Relying on default #size-cells value
for /soc/...

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 4286453..61efb2d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -521,6 +521,9 @@
};
 
avb: ethernet@e680 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
/* placeholder */
};
@@ -528,11 +531,21 @@
csi20: csi2@fea8 {
reg = <0 0xfea8 0 0x1>;
/* placeholder */
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 
csi40: csi2@feaa {
reg = <0 0xfeaa 0 0x1>;
/* placeholder */
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 
vin0: video@e6ef {
@@ -611,6 +624,9 @@
};
 
i2c2: i2c@e651 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
reg = <0 0xe651 0 0x40>;
/* placeholder */
};
@@ -621,6 +637,9 @@
};
 
i2c4: i2c@e66d8000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
reg = <0 0xe66d8000 0 0x40>;
/* placeholder */
};
@@ -636,6 +655,9 @@
};
 
i2c_dvfs: i2c@e60b {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
reg = <0 0xe60b 0 0x425>;
/* placeholder */
};
@@ -681,6 +703,9 @@
/* placeholder */
 
ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
port@0 {
reg = <0>;
du_out_rgb: endpoint {
-- 
2.7.4

[PATCH v2 3/7] arm64: dts: renesas: r8a77965: Remove stale reg property

[Jacopo Mondi]

Remove "reg" property from cache-controller-0 device node as it does not
have any unit address.

This silences the following DTC compiler warning:
Warning (unit_address_vs_reg): Node /cpus/cache-controller-0 has a reg
or ranges property, but no unit name

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 61efb2d..0536b94 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -47,7 +47,6 @@
 
L2_CA57: cache-controller-0 {
compatible = "cache";
-   reg = <0>;
power-domains = < 12>;
cache-unified;
cache-level = <2>;
-- 
2.7.4

[PATCH v2 6/7] arm64: dts: renesas: r8a77965: Add #interrupt-cells property

[Jacopo Mondi]

Add "#interrupt-cells" property and "interrupt-controller" label to
"interrupt-controller@e61c" device node.

This silences the following DTC compiler warnings:
Warning (interrupts_property): Missing interrupt-controller or
interrupt-map property in /soc/interrupt-controller@e61c
Warning (interrupts_property): Missing #interrupt-cells in
interrupt-parent /soc/interrupt-controller@e61c000

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 5dff176..0118956 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -316,6 +316,8 @@
};
 
intc_ex: interrupt-controller@e61c {
+   #interrupt-cells = <2>;
+   interrupt-controller;
reg = <0 0xe61c 0 0x200>;
/* placeholder */
};
-- 
2.7.4

[PATCH v2 5/7] arm64: dts: renesas: r8a77965: Add #pwm-cells property

[Jacopo Mondi]

Add "#pwm-cells" property to "pwm@e6e31000" device node.

This silences the following DTC compiler warning:
Warning (pwms_property): Missing property '#pwm-cells' in node
/soc/pwm@e6e31000 or bad phandle (referred from /backlight:pwms[0])

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 1a21967..5dff176 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -668,6 +668,7 @@
 
pwm1: pwm@e6e31000 {
reg = <0 0xe6e31000 0 8>;
+   #pwm-cells = <2>;
/* placeholder */
};
 
-- 
2.7.4

[PATCH v2 4/7] arm64: dts: renesas: r8a77965: Add #phy-cells property

[Jacopo Mondi]

Add "#phy-cells" property to "usb-phy@e65ee000" device node.

This silences the following DTC compiler warning:
Warning (phys_property): Missing property '#phy-cells' in node
/soc/usb-phy@e65ee000 or bad phandle (referred from
/soc/usb@ee02:phys[0])

Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 0536b94..1a21967 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -795,6 +795,7 @@
 
usb3_phy0: usb-phy@e65ee000 {
reg = <0 0xe65ee000 0 0x90>;
+   #phy-cells = <0>;
/* placeholder */
};
 
-- 
2.7.4

[PATCH v2 7/7] arm64: dts: renesas: r8a77965: Move usb2_phy1 up

[Jacopo Mondi]

Move "usb2_ph1" place-holder device node next to "usb2_phy0" one.

Signed-off-by: Jacopo Mondi 
---
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 0118956..8c9648a 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -604,6 +604,11 @@
/* placeholder */
};
 
+   usb2_phy1: usb-phy@ee0a0200 {
+   reg = <0 0xee0a0200 0 0x700>;
+   /* placeholder */
+   };
+
ohci1: usb@ee0a {
reg = <0 0xee0a 0 0x100>;
/* placeholder */
@@ -771,11 +776,6 @@
};
};
 
-   usb2_phy1: usb-phy@ee0a0200 {
-   reg = <0 0xee0a0200 0 0x700>;
-   /* placeholder */
-   };
-
sdhi0: sd@ee10 {
reg = <0 0xee10 0 0x2000>;
/* placeholder */
-- 
2.7.4

Re: [PATCH v2 9/9] serial: xuartps: Fix out-of-bounds access through DT alias

[Michal Simek]

On 23.2.2018 14:38, Geert Uytterhoeven wrote:
> The cdns_uart_port[] array is indexed using a value derived from the
> "serialN" alias in DT, which may lead to an out-of-bounds access.
> 
> Fix this by adding a range check.
> 
> Fixes: 928e9263492069ee ("tty: xuartps: Initialize ports according to 
> aliases")
> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - Fix Fixes reference.
> ---
>  drivers/tty/serial/xilinx_uartps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/xilinx_uartps.c 
> b/drivers/tty/serial/xilinx_uartps.c
> index b9b2bc76bcac606c..abcb4d09a2d866d0 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -1110,7 +1110,7 @@ static struct uart_port *cdns_uart_get_port(int id)
>   struct uart_port *port;
>  
>   /* Try the given port id if failed use default method */
> - if (cdns_uart_port[id].mapbase != 0) {
> + if (id < CDNS_UART_NR_PORTS && cdns_uart_port[id].mapbase != 0) {
>   /* Find the next unused port */
>   for (id = 0; id < CDNS_UART_NR_PORTS; id++)
>   if (cdns_uart_port[id].mapbase == 0)
> 

Reviewed-by: Michal Simek 

Thanks,
Michal

[PATCH v2 7/9] serial: sh-sci: Fix out-of-bounds access through DT alias

[Geert Uytterhoeven]

The sci_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_SH_SCI_NR_UARTS), so this can even be triggered using a
legitimate DTB.

Fixes: 97ed9790c514066b ("serial: sh-sci: Remove unused platform data 
capabilities field")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Use ARRAY_SIZE().
---
 drivers/tty/serial/sh-sci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 4d14f321cbec95e0..f6a6610d434efc33 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3096,6 +3096,10 @@ static struct plat_sci_port *sci_parse_dt(struct 
platform_device *pdev,
dev_err(>dev, "failed to get alias id (%d)\n", id);
return NULL;
}
+   if (id >= ARRAY_SIZE(sci_ports)) {
+   dev_err(>dev, "serial%d out of range\n", id);
+   return NULL;
+   }
 
sp = _ports[id];
*dev_id = id;
-- 
2.7.4

[PATCH v2 2/9] serial: fsl_lpuart: Fix out-of-bounds access through DT alias

[Geert Uytterhoeven]

The lpuart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Fixes: c9e2e946fb0ba5d2 ("tty: serial: add Freescale lpuart driver support")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Use ARRAY_SIZE().
---
 drivers/tty/serial/fsl_lpuart.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 8cf112f2efc30707..51e47a63d61accef 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -2145,6 +2145,10 @@ static int lpuart_probe(struct platform_device *pdev)
dev_err(>dev, "failed to get alias id, errno %d\n", ret);
return ret;
}
+   if (ret >= ARRAY_SIZE(lpuart_ports)) {
+   dev_err(>dev, "serial%d out of range\n", ret);
+   return -EINVAL;
+   }
sport->port.line = ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sport->port.membase = devm_ioremap_resource(>dev, res);
-- 
2.7.4

[PATCH v2 3/9] serial: imx: Fix out-of-bounds access through serial port index

[Geert Uytterhoeven]

The imx_ports[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.

Fix this by adding a range check.

Fixes: ff05967a07225ab6 ("serial/imx: add of_alias_get_id() reference back")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Add blank line,
  - Use ARRAY_SIZE(),
  - Update patch description for platform data.
---
 drivers/tty/serial/imx.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 1d7ca382bc12b238..7c9bdc8e34ac9109 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2042,6 +2042,12 @@ static int serial_imx_probe(struct platform_device *pdev)
else if (ret < 0)
return ret;
 
+   if (sport->port.line >= ARRAY_SIZE(imx_ports)) {
+   dev_err(>dev, "serial%d out of range\n",
+   sport->port.line);
+   return -EINVAL;
+   }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(>dev, res);
if (IS_ERR(base))
-- 
2.7.4

[PATCH v2 5/9] serial: pxa: Fix out-of-bounds access through serial port index

[Geert Uytterhoeven]

The serial_pxa_ports[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.

Fix this by adding a range check.

Fixes: 699c20f3e6310aa2 ("serial: pxa: add OF support")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Fix off-by-one error (use ">="),
  - Update patch description for platform data.
---
 drivers/tty/serial/pxa.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index baf552944d5686e8..eda3c7710d6a745f 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -885,6 +885,10 @@ static int serial_pxa_probe(struct platform_device *dev)
sport->port.line = dev->id;
else if (ret < 0)
goto err_clk;
+   if (sport->port.line >= ARRAY_SIZE(serial_pxa_ports)) {
+   dev_err(>dev, "serial%d out of range\n", sport->port.line);
+   return -EINVAL;
+   }
snprintf(sport->name, PXA_NAME_LEN - 1, "UART%d", sport->port.line + 1);
 
sport->port.membase = ioremap(mmres->start, resource_size(mmres));
-- 
2.7.4

[PATCH v2 8/9] serial: sirf: Fix out-of-bounds access through DT alias

[Geert Uytterhoeven]

The sirf_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.

Fix this by adding a range check.

Fixes: a6ffe8966acbb66b ("serial: sirf: use dynamic method allocate uart 
structure")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Use ARRAY_SIZE().
---
 drivers/tty/serial/sirfsoc_uart.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/tty/serial/sirfsoc_uart.c 
b/drivers/tty/serial/sirfsoc_uart.c
index 9925b00a97772a1b..38622f2a30a92e7d 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -1283,6 +1283,11 @@ static int sirfsoc_uart_probe(struct platform_device 
*pdev)
goto err;
}
sirfport->port.line = of_alias_get_id(np, "serial");
+   if (sirfport->port.line >= ARRAY_SIZE(sirf_ports)) {
+   dev_err(>dev, "serial%d out of range\n",
+   sirfport->port.line);
+   return -EINVAL;
+   }
sirf_ports[sirfport->port.line] = sirfport;
sirfport->port.iotype = UPIO_MEM;
sirfport->port.flags = UPF_BOOT_AUTOCONF;
-- 
2.7.4

[PATCH v2 0/9] serial: Fix out-of-bounds accesses through DT aliases

[Geert Uytterhoeven]

Hi all,

Serial drivers used on DT platforms use the "serialN" alias in DT to
obtain the serial port index for a specific port.  Drivers typically use
a fixed-size array for keeping track of all available serial ports.
However, several drivers do not perform any validation on the index
obtained from DT, which may lead to out-of-bounds accesses of these
fixed-size arrays.

While the DTB passed to the kernel might be considered trusted, some of
these out-of-bounds accesses can be triggered by a legitimate DTB:
  - In some drivers the size of the array is defined by a Kconfig
symbol, so a user who doesn't need all serial ports may lower this
value rightfully,
  - Tomorrow's new SoC may have more serial ports than the fixed-size
array in today's driver can accommodate, which the user may forget
to enlarge.

Hence this series fixes that by adding checks for out-of-range aliases,
logging an error message when triggered.

Changes compared to v1:
  - Fix Fixes references,
  - Use ARRAY_SIZE(),
  - Fix off-by-one error in patch [5/9],
  - Document where the non-DT case is also fixed by a patch.

Tested on r8a7791/koelsch (sh-sci), all other drivers were
compile-tested only.

Thanks for your comments!

Geert Uytterhoeven (9):
  serial: arc_uart: Fix out-of-bounds access through DT alias
  serial: fsl_lpuart: Fix out-of-bounds access through DT alias
  serial: imx: Fix out-of-bounds access through serial port index
  serial: mxs-auart: Fix out-of-bounds access through serial port index
  serial: pxa: Fix out-of-bounds access through serial port index
  serial: samsung: Fix out-of-bounds access through serial port index
  serial: sh-sci: Fix out-of-bounds access through DT alias
  serial: sirf: Fix out-of-bounds access through DT alias
  serial: xuartps: Fix out-of-bounds access through DT alias

 drivers/tty/serial/arc_uart.c  | 5 +
 drivers/tty/serial/fsl_lpuart.c| 4 
 drivers/tty/serial/imx.c   | 6 ++
 drivers/tty/serial/mxs-auart.c | 4 
 drivers/tty/serial/pxa.c   | 4 
 drivers/tty/serial/samsung.c   | 4 
 drivers/tty/serial/sh-sci.c| 4 
 drivers/tty/serial/sirfsoc_uart.c  | 5 +
 drivers/tty/serial/xilinx_uartps.c | 2 +-
 9 files changed, 37 insertions(+), 1 deletion(-)

-- 
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 v2 6/9] serial: samsung: Fix out-of-bounds access through serial port index

[Geert Uytterhoeven]

The s3c24xx_serial_ports[] array is indexed using a value derived from
the "serialN" alias in DT, or from an incrementing probe index, which
may lead to an out-of-bounds access.

Fix this by adding a range check.

Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_SAMSUNG_UARTS), so this can even be triggered using
a legitimate DTB or legitimate board code.

Fixes: 13a9f6c64fdc55eb ("serial: samsung: Consider DT alias when probing 
ports")
Signed-off-by: Geert Uytterhoeven 
---
v2:
  - Fix Fixes reference,
  - Use ARRAY_SIZE(),
  - Update patch description for non-DT case.
---
 drivers/tty/serial/samsung.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index f9fecc5ed0cee826..3f2f8c118ce09d56 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1818,6 +1818,10 @@ static int s3c24xx_serial_probe(struct platform_device 
*pdev)
 
dbg("s3c24xx_serial_probe(%p) %d\n", pdev, index);
 
+   if (index >= ARRAY_SIZE(s3c24xx_serial_ports)) {
+   dev_err(>dev, "serial%d out of range\n", index);
+   return -EINVAL;
+   }
ourport = _serial_ports[index];
 
ourport->drv_data = s3c24xx_get_driver_data(pdev);
-- 
2.7.4

Re: [PATCH] PCI: rcar-gen2: remove duplicated bit-wise or of RCAR_PCI_INT_SIGRETABORT

[Geert Uytterhoeven]

On Fri, Feb 23, 2018 at 1:29 PM, Colin King  wrote:
> From: Colin Ian King 
>
> Bit pattern RCAR_PCI_INT_SIGRETABORT is being bit-wise or'd twice;
> remove the redundant 2nd RCAR_PCI_INT_SIGRETABORT.
>
> Signed-off-by: Colin Ian King 

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/6] arm64: dts: renesas: r8a77965: Add "reg" properties

[Geert Uytterhoeven]

Hi Jacopo,

On Fri, Feb 23, 2018 at 1:22 PM, jacopo mondi  wrote:
> On Fri, Feb 23, 2018 at 10:19:21AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  
>> wrote:
>> > Add "reg" properties to place-holder nodes with unit address defined for
>> > R-Car M3-N SoC.
>> >
>> > This silences the following DTC compiler warning:
>> > Warning (unit_address_vs_reg): Node /soc/... has a unit name,
>> > but no reg property
>> >
>> > Signed-off-by: Jacopo Mondi 
>>
>> A few minor nits below...
>>
>> Reviewed-by: Geert Uytterhoeven 
>>
>> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>>
>> > @@ -520,130 +521,163 @@
>> > };
>> >
>> > avb: ethernet@e680 {
>> > +   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 
>> > 0x1>;
>>
>> The first reg part would be sufficient for a placeholder.
>> I think even setting the size to zero would work...
>
> Not sure I fully got your point here.
>
> Do you mean I have to remove the second (and third, fourth...)  addresses 
> range block
> in all placeholder device nodes with multiple blocks (avb, du, rcar-sound) ?

No, you don't have to.

> Do you mean I have to set to 0 the address length in all placeholder nodes?
> What's the point if they have to be added back once the device is
> enabled?

No, you don't have to.

The point is to do the minimum amount of work for the placeholders.
But since you've already done the work (and I've done the work to review it),
it doesn't make sense to remove all of this, to be redone later.

For a new future SoC+board combination, we may consider this.
Actually we could get rid of the "reg" requirement as well, if would drop
the unit addresses from the placeholders (e.g. "avb: ethernet { ... }", and
"vin2: video-2 { ...}"). Even less to look up in the datasheet...
(to be broken by Rob adding more dtc checks ;-)

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] PCI: rcar-gen2: remove duplicated bit-wise or of RCAR_PCI_INT_SIGRETABORT

[Colin King]

From: Colin Ian King 

Bit pattern RCAR_PCI_INT_SIGRETABORT is being bit-wise or'd twice;
remove the redundant 2nd RCAR_PCI_INT_SIGRETABORT.

Signed-off-by: Colin Ian King 
---
 drivers/pci/host/pci-rcar-gen2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index a28370bb2b2a..dd4f1a6b57c5 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -52,7 +52,6 @@
 #define RCAR_PCI_INT_B (1 << 17)
 #define RCAR_PCI_INT_PME   (1 << 19)
 #define RCAR_PCI_INT_ALLERRORS (RCAR_PCI_INT_SIGTABORT | \
-   RCAR_PCI_INT_SIGRETABORT| \
RCAR_PCI_INT_SIGRETABORT| \
RCAR_PCI_INT_REMABORT   | \
RCAR_PCI_INT_PERR   | \
-- 
2.15.1

Re: [PATCH 1/6] arm64: dts: renesas: r8a77965: Add "reg" properties

[jacopo mondi]

Hi Geert,

On Fri, Feb 23, 2018 at 10:19:21AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  
> wrote:
> > Add "reg" properties to place-holder nodes with unit address defined for
> > R-Car M3-N SoC.
> >
> > This silences the following DTC compiler warning:
> > Warning (unit_address_vs_reg): Node /soc/... has a unit name,
> > but no reg property
> >
> > Signed-off-by: Jacopo Mondi 
>
> A few minor nits below...
>
> Reviewed-by: Geert Uytterhoeven 
>
> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
>
> > @@ -520,130 +521,163 @@
> > };
> >
> > avb: ethernet@e680 {
> > +   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 
> > 0x1>;
>
> The first reg part would be sufficient for a placeholder.
> I think even setting the size to zero would work...

Not sure I fully got your point here.

Do you mean I have to remove the second (and third, fourth...)  addresses range 
block
in all placeholder device nodes with multiple blocks (avb, du, rcar-sound) ?

Do you mean I have to set to 0 the address length in all placeholder nodes?
What's the point if they have to be added back once the device is
enabled?

>
> > du: display@feb0 {
> > +   reg = <0 0xfeb0 0 0x7>,
>
> Unlike M3-W, the M3-N DU has a third channel, so the size is too small.
>

Will fix in v2

> > + <0 0xfeb9 0 0x14>;
> > /* placeholder */
>
> > @@ -703,38 +745,47 @@
> > };
> >
> > usb2_phy1: usb-phy@ee0a0200 {
> > +   reg = <0 0xee0a0200 0 0x700>;
> > /* placeholder */
> > };
>
> To be moved up, next to the other usb2 devices?

Will add a patch to move this next to other usb2 device nodes in v2.

I will send v2 as soon as first review comment gets clarified.

Thanks
   j

>
> 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] v4l: vsp1: Print the correct blending unit name in debug messages

[Kieran Bingham]

Hi Laurent,

Thankyou for the patch (update).

On 22/02/18 20:52, Laurent Pinchart wrote:
> The DRM pipelines can use either the BRU or the BRS for blending. Make
> sure the right name is used in debugging messages to avoid confusion.
> 
> Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 

> ---
> Changes since v1:
> 
> - Create a macro to get the right entity name instead of duplicating the
>   same code all over the driver
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index ac85942162c1..b8fee1834253 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -27,6 +27,7 @@
>  #include "vsp1_pipe.h"
>  #include "vsp1_rwpf.h"
>  
> +#define BRU_NAME(e)  (e)->type == VSP1_ENTITY_BRU ? "BRU" : "BRS"
>  
>  /* 
> -
>   * Interrupt Handling
> @@ -88,7 +89,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
>   struct v4l2_subdev_format format;
> - const char *bru_name;
>   unsigned long flags;
>   unsigned int i;
>   int ret;
> @@ -99,7 +99,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   drm_pipe = >drm->pipe[pipe_index];
>   pipe = _pipe->pipe;
>   bru = to_bru(>bru->subdev);
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
>  
>   if (!cfg) {
>   /*
> @@ -165,7 +164,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>   }
>  
>   format.pad = pipe->bru->source_pad;
> @@ -181,7 +180,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>  
>   format.pad = RWPF_PAD_SINK;
>   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
> @@ -473,9 +472,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, format.pad);
> + format.format.code, BRU_NAME(pipe->bru), format.pad);
>  
>   sel.pad = bru_input;
>   sel.target = V4L2_SEL_TGT_COMPOSE;
> @@ -486,10 +485,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev,
> - "%s: set selection (%u,%u)/%ux%u on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
>   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> - sel.pad);
> + BRU_NAME(pipe->bru), sel.pad);
>  
>   return 0;
>  }
> @@ -514,12 +512,9 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   struct vsp1_entity *entity;
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
> - const char *bru_name;
>   unsigned int i;
>   int ret;
>  
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
> -
>   /* Prepare the display list. */
>   dl = vsp1_dl_list_get(pipe->output->dlm);
>  
> @@ -570,7 +565,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   rpf->entity.sink_pad = i;
>  
>   dev_dbg(vsp1->dev, "%s: connecting RPF.%u to %s:%u\n",
> - __func__, rpf->entity.index, bru_name, i);
> + __func__, rpf->entity.index, BRU_NAME(pipe->bru), i);
>  
>   ret = vsp1_du_setup_rpf_pipe(vsp1, pipe, rpf, i);
>   if (ret < 0)
> 

Re: [PATCH 6/6] arm64: dts: renesas: r8a77965: Add #interrupt-cells property

[Simon Horman]

On Fri, Feb 23, 2018 at 11:06:07AM +0100, jacopo mondi wrote:
> Hi Geert,
> 
> On Fri, Feb 23, 2018 at 10:27:16AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  
> > wrote:
> > > Add "#interrupt-cells" property and "interrupt-controller" label to
> > > "interrupt-controller@e61c" device node.
> > >
> > > This silences the following DTC compiler warnings:
> > > Warning (interrupts_property): Missing interrupt-controller or
> > > interrupt-map property in /soc/interrupt-controller@e61c
> > > Warning (interrupts_property): Missing #interrupt-cells in
> > > interrupt-parent /soc/interrupt-controller@e61c000
> > >
> > > Signed-off-by: Jacopo Mondi 
> >
> > Reviewed-by: Geert Uytterhoeven 
> >
> > > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > > @@ -316,6 +316,8 @@
> > > };
> > >
> > > intc_ex: interrupt-controller@e61c {
> > > +   #interrupt-cells = <2>;
> > > +   interrupt-controller;
> > > reg = <0 0xe61c 0 0x200>;
> > > /* placeholder */
> >
> > (bikeshedding) Should the placeholder be at the top of the node?
> 
> I would like it more too, but in M3-W dtsi:
> 
>   pciec0: pcie@fe00 {
>   reg = <0 0xfe00 0 0x8>;
>   /* placeholder */
>   };
> 
> So I kept using the same style everywhere here.
> 
> I can change it everywhere in this series to have placeholder at the
> beginning of the node definition if you agree with that!

Either way is fine by me. But if we do change it lets change it everywhere.

Re: [PATCH 4/4] arm64: dts: r8a7795: Add PWM device nodes

[Sergei Shtylyov]

On 2/23/2018 1:09 PM, Sergei Shtylyov wrote:


From: Ryo Kodama 

Signed-off-by: Ryo Kodama 
Signed-off-by: Harunobu Kurokawa 
[uli: adapted to new MSTP clock scheme]
Signed-off-by: Ulrich Hecht 


   Sorry, I didn't realize I was replying to a month-old patch (with the A/B 
issue already commented on).


MBR, Sergei

Re: [PATCH 4/4] arm64: dts: r8a7795: Add PWM device nodes

[Sergei Shtylyov]

Hello!

On 1/19/2016 3:18 PM, Ulrich Hecht wrote:


From: Ryo Kodama 

Signed-off-by: Ryo Kodama 
Signed-off-by: Harunobu Kurokawa 
[uli: adapted to new MSTP clock scheme]
Signed-off-by: Ulrich Hecht 


[...]

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 265d12f..04661cf 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -93,6 +93,15 @@
  };
  
   {

+   pwm1_pins: pwm1 {
+   renesas,groups = "pwm1_a", "pwm1_b";


   Why both PWM1_A and PWM1_B? Aren't you supposed to select one?


+   renesas,function = "pwm1";
+   };
+   pwm2_pins: pwm2 {
+   renesas,groups = "pwm2_a", "pwm2_b";


   Same here...


+   renesas,function = "pwm2";
+   };
+
scif1_pins: scif1 {
renesas,groups = "scif1_data_a", "scif1_ctrl";
renesas,function = "scif1";

[...]

MBR, Sergei

Re: [PATCH 6/6] arm64: dts: renesas: r8a77965: Add #interrupt-cells property

[jacopo mondi]

Hi Geert,

On Fri, Feb 23, 2018 at 10:27:16AM +0100, Geert Uytterhoeven wrote:
> On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  
> wrote:
> > Add "#interrupt-cells" property and "interrupt-controller" label to
> > "interrupt-controller@e61c" device node.
> >
> > This silences the following DTC compiler warnings:
> > Warning (interrupts_property): Missing interrupt-controller or
> > interrupt-map property in /soc/interrupt-controller@e61c
> > Warning (interrupts_property): Missing #interrupt-cells in
> > interrupt-parent /soc/interrupt-controller@e61c000
> >
> > Signed-off-by: Jacopo Mondi 
>
> Reviewed-by: Geert Uytterhoeven 
>
> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > @@ -316,6 +316,8 @@
> > };
> >
> > intc_ex: interrupt-controller@e61c {
> > +   #interrupt-cells = <2>;
> > +   interrupt-controller;
> > reg = <0 0xe61c 0 0x200>;
> > /* placeholder */
>
> (bikeshedding) Should the placeholder be at the top of the node?

I would like it more too, but in M3-W dtsi:

pciec0: pcie@fe00 {
reg = <0 0xfe00 0 0x8>;
/* placeholder */
};

So I kept using the same style everywhere here.

I can change it everywhere in this series to have placeholder at the
beginning of the node definition if you agree with that!

Thanks
   j

>
> > };
>
> 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 v4 11/16] ARM: dts: r8a7791: Convert to new LVDS DT bindings

[Sergei Shtylyov]

On 2/21/2018 2:10 AM, Laurent Pinchart wrote:


The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 


[...]

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 008a260f86a5..8660f8a329c7 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi

[...]

@@ -1126,6 +1123,33 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {


   I suggest that we use the label "lvds" w/o #, compatible with the manual...

[...]

MBR, Sergei

Re: [PATCH v4 11/16] ARM: dts: r8a7791: Convert to new LVDS DT bindings

[Laurent Pinchart]

Hi Sergei,

On Friday, 23 February 2018 11:32:54 EET Sergei Shtylyov wrote:
> On 2/21/2018 2:10 AM, Laurent Pinchart wrote:
> > The internal LVDS encoder now has DT bindings separate from the DU. Port
> > the device tree over to the new model.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > Changes since v3:
> > 
> > - Added power-domains and resets properties to LVDS nodes
> > 
> > Changes since v2:
> > 
> > - Fixed LVDS compatible string
> > 
> > Changes since v1:
> > 
> > - Remove the DU reg-names property
> > ---
> > 
> >   arch/arm/boot/dts/r8a7791-koelsch.dts | 10 --
> >   arch/arm/boot/dts/r8a7791-porter.dts  | 16 +---
> >   arch/arm/boot/dts/r8a7791.dtsi| 36 +
> >   3 files changed, 51 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > b/arch/arm/boot/dts/r8a7791-koelsch.dts index a50924d12b6f..c42ff25e3aa3
> > 100644
> > --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> > @@ -337,8 +337,7 @@
> > 
> > clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
> > 
> >  <_clk>, <_clk>;
> > 
> > -   clock-names = "du.0", "du.1", "lvds.0",
> > - "dclkin.0", "dclkin.1";
> > +   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
> 
> Er, you only deleted the LVDS clock name but not LVDS clock itself?

Oops :-/ Will be fixed in the next version. Does it show that I don't have a 
Koelsch board to run tests ? :-)

> > diff --git a/arch/arm/boot/dts/r8a7791.dtsi
> > b/arch/arm/boot/dts/r8a7791.dtsi index 008a260f86a5..8660f8a329c7 100644
> > --- a/arch/arm/boot/dts/r8a7791.dtsi
> > +++ b/arch/arm/boot/dts/r8a7791.dtsi
> 
> [...]

-- 
Regards,

Laurent Pinchart

Re: [PATCH v4 11/16] ARM: dts: r8a7791: Convert to new LVDS DT bindings

[Sergei Shtylyov]

Hello!

On 2/21/2018 2:10 AM, Laurent Pinchart wrote:


The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
Changes since v3:

- Added power-domains and resets properties to LVDS nodes

Changes since v2:

- Fixed LVDS compatible string

Changes since v1:

- Remove the DU reg-names property
---
  arch/arm/boot/dts/r8a7791-koelsch.dts | 10 --
  arch/arm/boot/dts/r8a7791-porter.dts  | 16 +---
  arch/arm/boot/dts/r8a7791.dtsi| 36 +--
  3 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index a50924d12b6f..c42ff25e3aa3 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -337,8 +337,7 @@
  
  	clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,

 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";


   Er, you only deleted the LVDS clock name but not LVDS clock itself?

[...]

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 008a260f86a5..8660f8a329c7 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi

[...]

MBR, Sergei

Re: [PATCH 6/6] arm64: dts: renesas: r8a77965: Add #interrupt-cells property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#interrupt-cells" property and "interrupt-controller" label to
> "interrupt-controller@e61c" device node.
>
> This silences the following DTC compiler warnings:
> Warning (interrupts_property): Missing interrupt-controller or
> interrupt-map property in /soc/interrupt-controller@e61c
> Warning (interrupts_property): Missing #interrupt-cells in
> interrupt-parent /soc/interrupt-controller@e61c000
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -316,6 +316,8 @@
> };
>
> intc_ex: interrupt-controller@e61c {
> +   #interrupt-cells = <2>;
> +   interrupt-controller;
> reg = <0 0xe61c 0 0x200>;
> /* placeholder */

(bikeshedding) Should the placeholder be at the top of the node?

> };

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 5/6] arm64: dts: renesas: r8a77965: Add #pwm-cells property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#pwm-cells" property to "pwm@e6e31000" device node.
>
> This silences the following DTC compiler warning:
> Warning (pwms_property): Missing property '#pwm-cells' in node
> /soc/pwm@e6e31000 or bad phandle (referred from /backlight:pwms[0])
>
> Signed-off-by: Jacopo Mondi 

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 4/6] arm64: dts: renesas: r8a77965: Add #phy-cells property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#phy-cells" property to "usb-phy@e65ee000" device node.
>
> This silences the following DTC compiler warning:
> Warning (phys_property): Missing property '#phy-cells' in node
> /soc/usb-phy@e65ee000 or bad phandle (referred from
> /soc/usb@ee02:phys[0])
>
> Signed-off-by: Jacopo Mondi 

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/6] arm64: dts: renesas: r8a77965: Remove stale reg property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Remove "reg" property from cache-controller-0 device node as it does not
> have any unit address.
>
> This silences the following DTC compiler warning:
> Warning (unit_address_vs_reg): Node /cpus/cache-controller-0 has a reg
> or ranges property, but no unit name
>
> Signed-off-by: Jacopo Mondi 

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/6] arm64: dts: renesas: r8a77965: Add #address-cells and #size-cells

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#address-cells" and "#size-cells" properties to all place-holder nodes
> that have children nodes defined by salvator-x[s].dtsi device tree.
>
> This silences the following DTC compiler warnings:
> Warning (reg_format): "reg" property in /soc/.. has invalid length (4 bytes)
> (#address-cells == 2, #size-cells == 1)
> Warning (avoid_default_addr_size): Relying on default #address-cells
> value for /soc/...
> Warning (avoid_default_addr_size): Relying on default #size-cells value
> for /soc/...
>
> Signed-off-by: Jacopo Mondi 

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] arm64: renesas_defconfig: enable R8A77965 SoC

[Geert Uytterhoeven]

On Fri, Feb 23, 2018 at 9:51 AM, Simon Horman
 wrote:
> Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 renesas_defconfig.
>
> Signed-off-by: Simon Horman 

Acked-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/6] arm64: dts: renesas: r8a77965: Add "reg" properties

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "reg" properties to place-holder nodes with unit address defined for
> R-Car M3-N SoC.
>
> This silences the following DTC compiler warning:
> Warning (unit_address_vs_reg): Node /soc/... has a unit name,
> but no reg property
>
> Signed-off-by: Jacopo Mondi 

A few minor nits below...

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi

> @@ -520,130 +521,163 @@
> };
>
> avb: ethernet@e680 {
> +   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 
> 0x1>;

The first reg part would be sufficient for a placeholder.
I think even setting the size to zero would work...

> du: display@feb0 {
> +   reg = <0 0xfeb0 0 0x7>,

Unlike M3-W, the M3-N DU has a third channel, so the size is too small.

> + <0 0xfeb9 0 0x14>;
> /* placeholder */

> @@ -703,38 +745,47 @@
> };
>
> usb2_phy1: usb-phy@ee0a0200 {
> +   reg = <0 0xee0a0200 0 0x700>;
> /* placeholder */
> };

To be moved up, next to the other usb2 devices?

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 v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Frank,

On Friday, 23 February 2018 04:38:06 EET Frank Rowand wrote:
> On 02/22/18 14:10, Frank Rowand wrote:
> > Hi Laurent, Rob,
> > 
> > Thanks for the prompt spin to address my concerns.  There are some small
> > technical issues.
> > 
> > I did not read the v3 patch until today.  v3 through v6 are still using
> > the old overlay apply method which uses an expanded device tree as input.
> > 
> > Rob, I don't see my overlay patches in you for-next branch, and I have
> > not seen an "Applied" message from you.  What is the status of the
> > overlay patches?
> > 
> > Comments in the patch below.
> > 
> > On 02/22/18 05:13, Laurent Pinchart wrote:
> >> The internal LVDS encoders now have their own DT bindings. Before
> >> switching the driver infrastructure to those new bindings, implement
> >> backward-compatibility through live DT patching.
> >> 
> >> Patching is disabled and will be enabled along with support for the new
> >> DT bindings in the DU driver.
> >> 
> >> Signed-off-by: Laurent Pinchart
> >> 
> >> ---
> >> Changes since v5:
> >> 
> >> - Use a private copy of rcar_du_of_changeset_add_property()
> >> 
> >> Changes since v3:
> >> 
> >> - Use the OF changeset API
> >> - Use of_graph_get_endpoint_by_regs()
> >> - Replace hardcoded constants by sizeof()
> >> 
> >> Changes since v2:
> >> 
> >> - Update the SPDX headers to use C-style comments in header files
> >> - Removed the manually created __local_fixups__ node
> >> - Perform manual fixups on live DT instead of overlay
> >> 
> >> Changes since v1:
> >> 
> >> - Select OF_FLATTREE
> >> - Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
> >> - Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
> >> - Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
> >> - Pass void begin and end pointers to rcar_du_of_get_overlay()
> >> - Use of_get_parent() instead of accessing the parent pointer directly
> >> - Find the LVDS endpoints nodes based on the LVDS node instead of the
> >>   root of the overlay
> >> - Update to the -lvds compatible string format
> >> ---
> >> 
> >>  drivers/gpu/drm/rcar-du/Kconfig|   2 +
> >>  drivers/gpu/drm/rcar-du/Makefile   |   7 +-
> >>  drivers/gpu/drm/rcar-du/rcar_du_of.c   | 342 +++
> >>  drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
> >>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 +
> >>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
> >>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
> >>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
> >>  .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
> >>  9 files changed, 661 insertions(+), 1 deletion(-)
> >>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
> >>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
> >>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> >>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
> >>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
> >>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
> >>  create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts
> >> 
> >> diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> >> b/drivers/gpu/drm/rcar-du/Kconfig index 5d0b4b7119af..3f83352a7313
> >> 100644
> >> --- a/drivers/gpu/drm/rcar-du/Kconfig
> >> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> 
> < snip >
> 
> > becomes:
> > ret = of_overlay_fdt_apply(dtb->begin, _id);
> > 
> > If my overlay patches do not exist, there are other small errors
> > in the code block above.  I'll ignore them for the moment.
> > 
> > A quick scan of the rest of the code looks OK.  I'll read through it
> > more carefully, but wanted to get this reply out without further
> > delay.
> 
> < snip >
> 
> I was hoping to be able to convert the .dts files to use sugar syntax
> instead of hand coding the fragment nodes, but for this specific set
> of files I failed, since the labels that would have been required do
> not already exist in the base .dts files that that overlays would be
> applied against.

And even if they existed in the base .dts in the kernel sources, there's no 
guarantee that the .dtb on the systems we want to patch would contain symbol, 
so that wouldn't have been an option anyway, would it ?

> Oh well.  It was an interesting exercise anyway, trying to be crafty.

-- 
Regards,

Laurent Pinchart

[PATCH] arm64: renesas_defconfig: enable R8A77965 SoC

[Simon Horman]

Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 renesas_defconfig.

Signed-off-by: Simon Horman 
---
 arch/arm64/configs/renesas_defconfig | 1 +
 1 file changed, 1 insertion(+)

  Not for upstream merge

diff --git a/arch/arm64/configs/renesas_defconfig 
b/arch/arm64/configs/renesas_defconfig
index 386211464efa..03fb7c982314 100644
--- a/arch/arm64/configs/renesas_defconfig
+++ b/arch/arm64/configs/renesas_defconfig
@@ -33,6 +33,7 @@ CONFIG_BLK_DEV_INTEGRITY=y
 CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_R8A7795=y
 CONFIG_ARCH_R8A7796=y
+CONFIG_ARCH_R8A77965=y
 CONFIG_ARCH_R8A77970=y
 CONFIG_ARCH_R8A77980=y
 CONFIG_ARCH_R8A77995=y
-- 
2.11.0

[PATCH] arm64: defconfig: enable R8A77965 SoC

[Simon Horman]

Enable the Renesas R-Car M3-W (R8A77965) SoC in the ARM64 defconfig.

Signed-off-by: Simon Horman 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ceafd26f0fab..c8b59543f670 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -51,6 +51,7 @@ CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_R8A7795=y
 CONFIG_ARCH_R8A7796=y
+CONFIG_ARCH_R8A77965=y
 CONFIG_ARCH_R8A77970=y
 CONFIG_ARCH_R8A77980=y
 CONFIG_ARCH_R8A77995=y
-- 
2.11.0

Re: [PATCH v2] v4l: vsp1: Print the correct blending unit name in debug messages

[Niklas Söderlund]

Hi Laurent,

Thanks for your patch.

On 2018-02-22 22:52:26 +0200, Laurent Pinchart wrote:
> The DRM pipelines can use either the BRU or the BRS for blending. Make
> sure the right name is used in debugging messages to avoid confusion.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Niklas Söderlund 

> ---
> Changes since v1:
> 
> - Create a macro to get the right entity name instead of duplicating the
>   same code all over the driver
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index ac85942162c1..b8fee1834253 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -27,6 +27,7 @@
>  #include "vsp1_pipe.h"
>  #include "vsp1_rwpf.h"
>  
> +#define BRU_NAME(e)  (e)->type == VSP1_ENTITY_BRU ? "BRU" : "BRS"
>  
>  /* 
> -
>   * Interrupt Handling
> @@ -88,7 +89,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
>   struct v4l2_subdev_format format;
> - const char *bru_name;
>   unsigned long flags;
>   unsigned int i;
>   int ret;
> @@ -99,7 +99,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   drm_pipe = >drm->pipe[pipe_index];
>   pipe = _pipe->pipe;
>   bru = to_bru(>bru->subdev);
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
>  
>   if (!cfg) {
>   /*
> @@ -165,7 +164,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>   }
>  
>   format.pad = pipe->bru->source_pad;
> @@ -181,7 +180,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>  
>   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, bru_name, i);
> + format.format.code, BRU_NAME(pipe->bru), i);
>  
>   format.pad = RWPF_PAD_SINK;
>   ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
> @@ -473,9 +472,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
>   __func__, format.format.width, format.format.height,
> - format.format.code, format.pad);
> + format.format.code, BRU_NAME(pipe->bru), format.pad);
>  
>   sel.pad = bru_input;
>   sel.target = V4L2_SEL_TGT_COMPOSE;
> @@ -486,10 +485,9 @@ static int vsp1_du_setup_rpf_pipe(struct vsp1_device 
> *vsp1,
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev,
> - "%s: set selection (%u,%u)/%ux%u on BRU pad %u\n",
> + dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
>   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> - sel.pad);
> + BRU_NAME(pipe->bru), sel.pad);
>  
>   return 0;
>  }
> @@ -514,12 +512,9 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   struct vsp1_entity *entity;
>   struct vsp1_entity *next;
>   struct vsp1_dl_list *dl;
> - const char *bru_name;
>   unsigned int i;
>   int ret;
>  
> - bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
> -
>   /* Prepare the display list. */
>   dl = vsp1_dl_list_get(pipe->output->dlm);
>  
> @@ -570,7 +565,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned 
> int pipe_index)
>   rpf->entity.sink_pad = i;
>  
>   dev_dbg(vsp1->dev, "%s: connecting RPF.%u to %s:%u\n",
> - __func__, rpf->entity.index, bru_name, i);
> + __func__, rpf->entity.index, BRU_NAME(pipe->bru), i);
>  
>   ret = vsp1_du_setup_rpf_pipe(vsp1, pipe, rpf, i);
>   if (ret < 0)
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH v11 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Simon Horman]

On Thu, Feb 22, 2018 at 11:37:20AM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Hans Verkuil 

I have marked this patch as deferred as it depends on the binding for
"renesas,r7s72100-ceu".  Please repost or otherwise ping me once that
dependency has been accepted.

Re: [PATCH v5 00/26] Fix watchdog on Renesas R-Car Gen2 and RZ/G1

[Simon Horman]

On Thu, Feb 22, 2018 at 09:38:39AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Feb 21, 2018 at 7:32 PM, Simon Horman  wrote:
> > On Wed, Feb 21, 2018 at 05:30:12PM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Feb 21, 2018 at 5:13 PM, Simon Horman  wrote:
> >> > On Tue, Feb 20, 2018 at 01:51:28PM +0100, Geert Uytterhoeven wrote:
> >> >> On Mon, Feb 12, 2018 at 6:44 PM, Fabrizio Castro
> >> >>  wrote:
> >> >> > this series has been around for some time as RFC, and it has collected
> >> >> > useful comments from the community along the way.
> >> >> > The solution proposed by this patch set works for most R-Car Gen2 and
> >> >> > RZ/G1 devices, but not all of them. We now know that for some R-Car
> >> >> > Gen2 early revisions there is no proper software fix. Anyway, no
> >> >> > product has been built around early revisions, but development boards
> >> >> > mounting early revisions (basically prototypes) are still out there.
> >> >> > As a result, this series isn't enabling the internal watchdog on R-Car
> >> >> > Gen2 boards, developers may enable it in board specific device trees
> >> >> > if needed.
> >> >> > This series has been tested by me on the iwg20d, iwg22d, Lager, Alt,
> >> >> > and Koelsch boards.
> >> >> >
> >> >> > The problem
> >> >> > ===
> >> >> > To deal with SMP on R-Car Gen2 and RZ/G1, we install a reset vector
> >> >> > to ICRAM1 and we program the [S]BAR registers so that when we turn ON
> >> >> > the non-boot CPUs they are redirected to the reset vector installed by
> >> >> > Linux in ICRAM1, and eventually they continue the execution to RAM,
> >> >> > where the SMP bring-up code will take care of the rest.
> >> >> > The content of the [S]BAR registers survives a watchdog triggered 
> >> >> > reset,
> >> >> > and as such after the watchdog fires the boot core will try and 
> >> >> > execute
> >> >> > the SMP bring-up code instead of jumping to the bootrom code.
> >> >> >
> >> >> > The fix
> >> >> > ===
> >> >> > The main strategy for the solution is to let the reset vector decide
> >> >> > if it needs to jump to shmobile_boot_fn or to the bootrom code.
> >> >> > In a watchdog triggered reset scenario, since the [S]BAR registers 
> >> >> > keep
> >> >> > their values, the boot CPU will jump into the newly designed reset
> >> >> > vector, the assembly routine will eventually test WOVF (a bit in 
> >> >> > register
> >> >> > RWTCSRA that indicates if the watchdog counter has overflown, the 
> >> >> > value
> >> >> > of this bit gets retained in this scenario), and jump to the bootrom 
> >> >> > code
> >> >> > which will in turn load up the bootloader, etc.
> >> >> > When bringing up SMP or using CPU hotplug, the reset vector will jump
> >> >> > to shmobile_boot_fn instead.
> >> >> >
> >> >> > Thank you All for your help.
> >> >> >
> >> >> > Best regards,
> >> >> >
> >> >> > Fabrizio Castro (26):
> >> >> >   ARM: shmobile: Add watchdog support
> >> >> >   ARM: dts: r8a7743: Adjust SMP routine size
> >> >> >   ARM: dts: r8a7745: Adjust SMP routine size
> >> >> >   ARM: dts: r8a7790: Adjust SMP routine size
> >> >> >   ARM: dts: r8a7791: Adjust SMP routine size
> >> >> >   ARM: dts: r8a7792: Adjust SMP routine size
> >> >> >   ARM: dts: r8a7793: Adjust SMP routine size
> >> >> >   ARM: dts: r8a7794: Adjust SMP routine size
> >> >> >   soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2
> >> >> >   ARM: shmobile: rcar-gen2: Add watchdog support
> >> >> >   dt-bindings: watchdog: renesas-wdt: Add R-Car Gen2 support
> >> >> >   watchdog: renesas_wdt: Add R-Car Gen2 support
> >> >> >   watchdog: renesas_wdt: Add restart handler
> >> >> >   ARM: shmobile: defconfig: Enable RENESAS_WDT_GEN
> >> >> >   clk: renesas: r8a7743: Add rwdt clock
> >> >> >   clk: renesas: r8a7745: Add rwdt clock
> >> >> >   clk: renesas: r8a7790: Add rwdt clock
> >> >> >   clk: renesas: r8a7791/r8a7793: Add rwdt clock
> >> >> >   clk: renesas: r8a7794: Add rwdt clock
> >> >> >   ARM: dts: r8a7743: Add watchdog support to SoC dtsi
> >> >> >   ARM: dts: r8a7745: Add watchdog support to SoC dtsi
> >> >> >   ARM: dts: r8a7790: Add watchdog support to SoC dtsi
> >> >> >   ARM: dts: r8a7791: Add watchdog support to SoC dtsi
> >> >> >   ARM: dts: r8a7794: Add watchdog support to SoC dtsi
> >> >> >   ARM: dts: iwg20m: Add watchdog support to SoM dtsi
> >> >> >   ARM: dts: iwg22m: Add watchdog support to SoM dtsi
> >> >> >
> >> >> >  .../devicetree/bindings/watchdog/renesas-wdt.txt   | 19 ++--
> >> >> >  arch/arm/boot/dts/r8a7743-iwg20m.dtsi  |  5 ++
> >> >> >  arch/arm/boot/dts/r8a7743.dtsi | 12 -
> >> >> >  arch/arm/boot/dts/r8a7745-iwg22m.dtsi  |  5 ++
> >> >> >  arch/arm/boot/dts/r8a7745.dtsi | 12 -
> >> >> >  arch/arm/boot/dts/r8a7790.dtsi | 12 -
> >> >> >  arch/arm/boot/dts/r8a7791.dtsi | 12 

Overlay sugar syntax (was: Re: [PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes)

[Geert Uytterhoeven]

Hi Frank,

On Fri, Feb 23, 2018 at 3:38 AM, Frank Rowand  wrote:
> I was hoping to be able to convert the .dts files to use sugar syntax
> instead of hand coding the fragment nodes, but for this specific set
> of files I failed, since the labels that would have been required do
> not already exist in the base .dts files that that overlays would be
> applied against.

Indeed, hence the fixup overlays use "target-path".

BTW, is there any specific reason there is no sugar syntax support in dtc
for absolute target paths? I guess to prevent adding stuff to a random
existing node, and to encourage people to use a "connector" API defined in
term of labels?

I'm also in the process of converting my collection of DT overlays to sugar
syntax, and lack of support for "target-path" is the sole thing that holds
me back from completing this. So for now I use a mix of sugar and
traditional overlay syntax.

In particular, I need "target-path" for two things:
  1. To refer to the root node, for adding devices that should live at
 (a board subnode of) the root node, like:
   - devices connected to GPIO controllers provided by other base or
 overlay devices (e.g. LEDs, displays, buttons, ...),
   - clock providers for other overlays devices (e.g. fixed-clock).
  2. To refer to the aliases node, for adding mandatory serialX aliases.

The former is the real blocker for me.

The latter doesn't work with plain upstream (hacky patches available), so
I'm working on getting rid of the serialX requirement in the serial driver.

Thanks!

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