Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

Gently Ping. Dear Kishon, Could you please review this patch for 'drivers/phy/*'? Regards, Chanwoo Choi On 2017년 10월 12일 12:40, Chanwoo Choi wrote: > Dear Kishon, > > Could you please review this patch? > After that, I'll make the immutable brand and then send the pull request > for

Re: [PATCH v3] i2c: riic: remove fixed clock restriction

> Actually, if you want to hold off on this patch, I'm almost done with a > real fix which is to calculate any frequency based on current parent > clock and rise/fall timings specified in the DT as you suggested. Sounds awesome! So, I'll wait a little how the formula goes. We can always fall

Re: [PATCH] i2c: rcar: document R8A77970 bindings

On Fri, Oct 13, 2017 at 03:23:55PM +0300, Sergei Shtylyov wrote: > R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible I2C controller, > so document the SoC specific bindings. > > Signed-off-by: Sergei Shtylyov > Applied to for-next, thanks!

Re: [PATCH] i2c: sh_mobile: Use of_device_get_match_data() helper

On Wed, Oct 04, 2017 at 02:17:05PM +0200, Geert Uytterhoeven wrote: > Use the of_device_get_match_data() helper instead of open coding. > > Signed-off-by: Geert Uytterhoeven Huh, how did I miss this so far? Applied to for-next, thanks! signature.asc Description: PGP

RE: [PATCH v3] i2c: riic: remove fixed clock restriction

Hi Wolfram, On Monday, October 16, 2017, Chris Brandt wrote: > Most systems with this i2c are going to have a clock of either 33.33MHz or > 32MHz. That 4% difference is not reason enough to warrant that the driver > to completely fail. > > Signed-off-by: Chris Brandt >

Re: [PATCH] clk: renesas: rz: clk-rz is meant for RZ/A1

On Thu, Oct 12, 2017 at 11:37:48AM +0200, Geert Uytterhoeven wrote: > The RZ family of Renesas SoCs has several different subfamilies (RZ/A, > RZ/G, RZ/N, and RZ/T). Clarify that the renesas,rz-cpg-clocks DT > bindings and clk-rz driver apply to RZ/A1 only. > > Signed-off-by: Geert Uytterhoeven

Re: [PATCH v6 4/4] phy: rcar-gen3-usb2: add binding for r8a77995

On Thu, Oct 12, 2017 at 03:34:48PM +0900, Yoshihiro Shimoda wrote: > This patch adds binding for r8a77995 (R-Car D3). Since r8a77995 doesn't > have dedicated pins (ID, VBUS), this will match against the generic > fallback on R-Car D3. > > For now, this driver doesn't support usb role swap for

Re: [PATCH] dt-bindings: PCI: rcar: Correct example to match reality

On Wed, Oct 11, 2017 at 03:50:13PM +0200, Geert Uytterhoeven wrote: > Correct the USB subnodes in the example, cfr. commit f7d569c1e6a6fa73 > ("ARM: dts: r8a779x: Fix PCI bus dtc warnings"): > 1. Drop the bogus 'device_type = "pci"' properties, > 2. Correct the unit addresses. > > Update

[PATCH v3] thermal: rcar_gen3_thermal: fix initialization sequence for H3 ES2.0

The initialization sequence for H3 (r8a7795) ES1.x and ES2.0 is different. H3 ES2.0 and later uses the same sequence as M3 (r8a7796) ES1.0. Fix this by not looking at compatible strings and instead defaulting to the r8a7796 initialization sequence and use soc_device_match() to check for H3 ES1.x.

renesas-drivers-2017-10-17-v4.14-rc5

I have pushed renesas-drivers-2017-10-17-v4.14-rc5 to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git This tree is meant to ease development of platform support and drivers for Renesas ARM SoCs. It is created by merging (a) the for-next branches of various subsystem trees

Re: [PATCH net-next 3/3] net: sh_eth: implement R-Car Gen[12] fallback compatibility strings

On 10/17/2017 10:47 AM, Simon Horman wrote: Implement fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For

Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings

On 10/17/2017 10:47 AM, Simon Horman wrote: Add fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example,

Re: [PATCH net-next 2/3] net: sh_eth: rename name structures as rcar_gen[12]_*

Hello! On 10/17/2017 10:47 AM, Simon Horman wrote: Rename structures describing R-Car SoCs as rcar_gen[12]_* rather than r8a77[79]x_*. This seems a little easier on the eyes will make things slightly cleaner in a follow-up ^ "And" missing here? patch that adds

Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings

Hello! On 10/17/2017 10:47 AM, Simon Horman wrote: Add fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For

RE: [PATCH] usb: renesas_usbhs: Add compatible string for r8a7743/5

Hi, Biju Das writes: > Hi, > >> -Original Message- >> From: devicetree-ow...@vger.kernel.org [mailto:devicetree- >> ow...@vger.kernel.org] On Behalf Of Felipe Balbi >> Sent: 17 October 2017 09:26 >> To: Biju Das ; Greg Kroah-Hartman >>

RE: [PATCH] usb: renesas_usbhs: Add compatible string for r8a7743/5

Hi, > -Original Message- > From: devicetree-ow...@vger.kernel.org [mailto:devicetree- > ow...@vger.kernel.org] On Behalf Of Felipe Balbi > Sent: 17 October 2017 09:26 > To: Biju Das ; Greg Kroah-Hartman > ; Rob Herring

RE: [PATCH 2/2] ARM: dts: r8a7743: Add xhci support to SoC dtsi

Hi Shimoda-San, > Hi Biju-san, > > IIUC, when we submitted a patch for dts[i] file, we don't need to submit such > a > patch to usb maintainers. Thanks. I will take care this in future. Regards, Biju Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,

Re: [PATCH] usb: renesas_usbhs: Add compatible string for r8a7743/5

Hi, Biju Das writes: > This patch adds support for r8a7743/5 SoC. The Renesas RZ/G1[ME] > (R8A7743/5) usbhs is identical to the R-Car Gen2 family. > > This doesn't change the driver, so it does nothing by itself. But it does > mean that checkpatch won't complain about

Re: [PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings

On Tue, Oct 17, 2017 at 9:47 AM, Simon Horman wrote: > Add fallback compatibility strings for R-Car Gen 1 and 2. > > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the

Re: [PATCH net-next 3/3] net: sh_eth: implement R-Car Gen[12] fallback compatibility strings

On Tue, Oct 17, 2017 at 9:47 AM, Simon Horman wrote: > Implement fallback compatibility strings for R-Car Gen 1 and 2. > > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the

Re: [PATCH net-next 2/3] net: sh_eth: rename name structures as rcar_gen[12]_*

On Tue, Oct 17, 2017 at 9:47 AM, Simon Horman wrote: > Rename structures describing R-Car SoCs as rcar_gen[12]_* > rather than r8a77[79]x_*. This seems a little easier on the > eyes will make things slightly cleaner in a follow-up > patch that adds

Re: [PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c

Hi Shimoda-san, On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda wrote: > Since this driver checks if the return value of dma_map_sg() is minus > or not and keeps to enable the DMAC, it may cause kernel panic when > the dma_map_sg() returns 0. So, this patch

Re: [PATCH v2 1/3] dt-bindings: mmc: renesas_sdhi: provide example in bindings documentation

On Mon, Oct 16, 2017 at 11:13:32AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Mon, Oct 16, 2017 at 9:58 AM, Simon Horman > wrote: > > Provide an example of the usage of the DT bindings for TMIO > > in their documentation. The example given is for the r8a7790

Re: [PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full

Hi Shimoda-san, CC iommu On Tue, Oct 17, 2017 at 9:30 AM, Yoshihiro Shimoda wrote: > Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling") > deletes the bounce buffer handling, a request data size will be referred > to max_{req,seg}_size instead

Re: [PATCH 3/4] ARM: dts: iwg22d-sodimm-dbhd-ca: Add device tree for HDMI DB

On Fri, Oct 13, 2017 at 02:03:15PM +0100, Fabrizio Castro wrote: > Add file r8a7745-iwg22d-sodimm-dbhd-ca.dts to provide support for > iW-RainboW-G22D with HDMI daughter board plugged in. > > The interfaces defined in the new .dts file are: scif1, scif5, > and hscif2. > > Signed-off-by: Fabrizio

Re: [PATCH 1/4] ARM: dts: iwg22d: Use /dev/ttySC3 as debug console

On Mon, Oct 16, 2017 at 08:34:35AM +, Biju Das wrote: > Hi, > > Looks like the chosen node "stdout-path = "serial0:115200n8";" is not updated > with this patch. > > So either drop the patch or fix the chosen node. Please repost this patch with the above resolved.

Re: [PATCH 2/4] ARM: dts: iwg22d: Add /dev/ttySC5 support

Please include some text in the changelog, ideally describing the motivation (why not what) for this patch. On Fri, Oct 13, 2017 at 02:03:14PM +0100, Fabrizio Castro wrote: > Signed-off-by: Fabrizio Castro > Signed-off-by: Chris Paterson

Re: [PATCH 1/2] dt-bindings: usb-xhci: Document r8a7743 support

On Mon, Oct 16, 2017 at 11:12:48AM +0100, Biju Das wrote: > From: Fabrizio Castro > > Document r8a7743 xhci support. The driver will use the fallback > compatible string "renesas,rcar-gen2-xhci", therefore no driver > change is needed. > > Signed-off-by: Fabrizio

[PATCH net-next 1/3] dt-bindings: net: sh_eth: add R-Car Gen[12] fallback compatibility strings

Add fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791

[PATCH net-next 3/3] net: sh_eth: implement R-Car Gen[12] fallback compatibility strings

Implement fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than

[PATCH net-next 2/3] net: sh_eth: rename name structures as rcar_gen[12]_*

Rename structures describing R-Car SoCs as rcar_gen[12]_* rather than r8a77[79]x_*. This seems a little easier on the eyes will make things slightly cleaner in a follow-up patch that adds fallback-compatibility strings for these SoCs. Note that R-Car Gen2 and RZ/G1 have many compatible IP blocks.

[PATCH net-next 0/3] net: sh_eth: add R-Car Gen[12] fallback compatibility strings

Add fallback compatibility strings for R-Car Gen 1 and 2. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than r8a7791

[PATCH 1/2] mmc: renesas_sdhi: fix swiotlb buffer is full

Since the commit de3ee99b097d ("mmc: Delete bounce buffer handling") deletes the bounce buffer handling, a request data size will be referred to max_{req,seg}_size instead of MMC_QUEUE_BOUNCESZ (64k bytes). In other hand, renesas_sdhi_internal_dmac.c will set very big value of max_{req,seg}_size

[PATCH 2/2] mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c

Since this driver checks if the return value of dma_map_sg() is minus or not and keeps to enable the DMAC, it may cause kernel panic when the dma_map_sg() returns 0. So, this patch fixes the issue. Reported-by: Dirk Behme Fixes: 2a68ea7896e3 ("mmc: renesas-sdhi: add

[PATCH 0/2] mmc: renesas_sdhi: bugfixes for v4.14

This patch set is based on mainline v4.14-rc5. Yoshihiro Shimoda (2): mmc: renesas_sdhi: fix swiotlb buffer is full mmc: renesas_sdhi: fix kernel panic in _internal_dmac.c drivers/mmc/host/renesas_sdhi_internal_dmac.c | 22 +- 1 file changed, 13 insertions(+), 9

Re: [PATCH 09/10] [RFC] ravb: Remove obsolete explicit clock handling for WoL

Hi Sergei, On Mon, Oct 16, 2017 at 10:17 PM, Sergei Shtylyov wrote: > On 10/16/2017 04:55 PM, Geert Uytterhoeven wrote: >> Currently, if Wake-on-LAN is enabled, the EtherAVB device's module clock >> is manually kept running during system suspend, to make sure

[PATCH 05/11] ARM: dts: r8a7778: Use R-Car SDHI Gen1 fallback compat string

Use newly added R-Car SDHI Gen1 fallback compat string in the DT of the r8a7778 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 10/11] ARM: dts: r8a7793: Use R-Car SDHI Gen2 fallback compat string

Use newly added R-Car SDHI Gen2 fallback compat string in the DT of the r8a7793 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 11/11] ARM: dts: r8a7794: Use R-Car SDHI Gen2 fallback compat string

Use newly added R-Car SDHI Gen2 fallback compat string in the DT of the r8a7794 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 08/11] ARM: dts: r8a7791: Use R-Car SDHI Gen2 fallback compat string

Use newly added R-Car SDHI Gen2 fallback compat string in the DT of the r8a7791 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 06/11] ARM: dts: r8a7779: Use R-Car SDHI Gen1 fallback compat string

Use newly added R-Car SDHI Gen1 fallback compat string in the DT of the r8a7779 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 00/11] arm64: dts: renesas: Use R-Car SDHI Gen[123] fallback compat strings

Use recently posted R-Car SDHI Gen 1, 2 and 3 fallback compat strings in the DT of Renesas ARM and arm64 based SoCs. Based on renesas-devel-20171016-v4.14-rc5 Has a binding documentation but no run-time dependency on "[PATCH v3 0/3] mmc: renesas_sdhi: add R-Car Gen[123] fallback compatibility

[PATCH 07/11] ARM: dts: r8a7790: Use R-Car SDHI Gen2 fallback compat string

Use newly added R-Car SDHI Gen2 fallback compat string in the DT of the r8a7790 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 09/11] ARM: dts: r8a7792: Use R-Car SDHI Gen2 fallback compat string

Use newly added R-Car SDHI Gen2 fallback compat string in the DT of the r8a7792 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 04/11] ARM: dts: r8a7745: Use R-Car SDHI Gen2 fallback compat string

Use newly added R-Car SDHI Gen2 fallback compat string in the DT of the r8a7745 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 01/11] arm64: dts: renesas: r8a7795: Use R-Car SDHI Gen3 fallback compat string

Use newly added R-Car SDHI Gen3 fallback compat string in the DT of the r8a7795 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 03/11] ARM: dts: r8a7743: Use R-Car SDHI Gen2 fallback compat string

Use newly added R-Car SDHI Gen2 fallback compat string in the DT of the r8a7743 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

[PATCH 02/11] arm64: dts: renesas: r8a7796: Use R-Car SDHI Gen3 fallback compat string

Use newly added R-Car SDHI Gen3 fallback compat string in the DT of the r8a7796 SoC. This should have no run-time effect as the driver matches against the per-SoC compat string before considering the fallback compat string. Signed-off-by: Simon Horman ---

RE: mainline 4.14-rc4: renesas_sdhi_internal_dmac ee100000.sd: swiotlb buffer is full?

Hi Dirk-san, > From: Dirk Behme, Sent: Tuesday, October 17, 2017 2:08 PM > > Limiting the thread to Renesas only, again, to discuss the other issue: > > On 17.10.2017 06:51, Yoshihiro Shimoda wrote: > > Hi Linus-san, > > > >> From: Linus Walleij, Sent: Monday, October 16, 2017 9:22 PM > >> > >>

[PATCH v3 1/3] dt-bindings: mmc: renesas_sdhi: provide example in bindings documentation

Provide an example of the usage of the DT bindings for TMIO in their documentation. The example given is for the r8a7790 (R-Car H2). Signed-off-by: Simon Horman Reviewed-by: Geert Uytterhoeven --- v3 * Updated example to newer upstream DTS

[PATCH v3 2/3] dt-bindings: mmc: renesas_sdhi: add R-Car Gen[123] fallback compatibility strings

Add fallback compatibility strings for R-Car Gen 1, 2 and 3. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe that r8a7790 is older than

[PATCH v3 0/3] mmc: renesas_sdhi: add R-Car Gen[123] fallback compatibility strings

Add fallback compatibility strings for R-Car Gen 1, 2 and 3 to the SDHI bindings and driver. In the case of Renesas R-Car hardware we know that there are generations of SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship between IP blocks might be. For example, I believe