Re: renesas-drivers-2016-06-28-v4.7-rc5

[Kuninori Morimoto]

Hi Geert

> I have pushed renesas-drivers-2016-06-28-v4.7-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 and (b) branches with driver code submitted
> or planned for submission to maintainers into the development branch of
> Simon Horman's renesas.git tree.
> 
> Today's version is based on renesas-devel-20160627-v4.7-rc5.

Can we have new version of below branches for -rc5 branch ?
Or for next new renesas-drivers ?

salvator-x-hdmi-prototype-drivers-X
salvator-x-hdmi-prototype-integration-X

My picky opinion is that
it is easy to understand that above additional branch has
same/similar naming of base branch...

ex) salvator-x-hdmi-prototype-drivers-20160627-v4.7-rc5

Re: [PATCH 3/6] ASoC: simple-card-utils: add asoc_simple_card_parse_dailink_name()

[Kuninori Morimoto]

Hi Mark

> From: Kuninori Morimoto 
> 
> Current simple-card is creating dai_link->name / dai_link->stream_name.
> These are based on CPU + Codec name.
> It can be "fe.CPU" or "be.Codec" if it was DPCM.
> This patch adds simple card common function for it.
> 
> Signed-off-by: Kuninori Morimoto 
> ---
(snip)
> diff --git a/sound/soc/generic/simple-card-utils.c 
> b/sound/soc/generic/simple-card-utils.c
> index 3f6b725..14d3a75 100644
> --- a/sound/soc/generic/simple-card-utils.c
> +++ b/sound/soc/generic/simple-card-utils.c
> @@ -52,3 +52,33 @@ int asoc_simple_card_parse_daifmt(struct device *dev,
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(asoc_simple_card_parse_daifmt);
> +
> +int asoc_simple_card_parse_dailink_name(struct device *dev,
> + struct snd_soc_dai_link *dai_link)
> +{
> + char *name = NULL;
> + int ret = -ENOMEM;
> +
> + if (dai_link->dynamic && dai_link->cpu_dai_name)
> + name = devm_kasprintf(dev, GFP_KERNEL,
> +   "fe.%s", dai_link->cpu_dai_name);
> +
> + else if (dai_link->no_pcm && dai_link->codec_dai_name)
> + name = devm_kasprintf(dev, GFP_KERNEL,
> +   "be.%s", dai_link->codec_dai_name);
> + else if (dai_link->cpu_dai_name && dai_link->codec_dai_name)
> + name = devm_kasprintf(dev, GFP_KERNEL,
> +   "%s-%s",
> +   dai_link->cpu_dai_name,
> +   dai_link->codec_dai_name);
> +
> + if (name) {
> + ret = 0;
> +
> + dai_link->name =
> + dai_link->stream_name = name;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(asoc_simple_card_parse_dailink_name);

Please let me know if your favored style is name format should be
handled on each sound card, not in utils.c
I can arrange it.

[PATCH 5/6] drm/rcar-du: use drm_crtc_handle_vblank()

[Gustavo Padovan]

From: Gustavo Padovan 

Remove legacy usage of drm_handle_vblank()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda..e39fcef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -552,7 +552,7 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
 
if (status & DSSR_FRM) {
-   drm_handle_vblank(rcrtc->crtc.dev, rcrtc->index);
+   drm_crtc_handle_vblank(>crtc);
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
}
-- 
2.5.5

[PATCH 2/2] ARM: dts: r8a7792: add EtherAVB support

[Sergei Shtylyov]

Define the generic R8A7792 part of the EtherAVB device node.

Based on the commit 89aac8af1a60 ("ARM: dts: r8a7794: add EtherAVB support").

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792.dtsi |   12 
 1 file changed, 12 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -444,6 +444,18 @@
power-domains = < R8A7792_PD_ALWAYS_ON>;
};
 
+   avb: ethernet@e680 {
+   compatible = "renesas,etheravb-r8a7792",
+"renesas,etheravb-rcar-gen2";
+   reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
+   interrupts = ;
+   clocks = <_clks R8A7792_CLK_ETHERAVB>;
+   power-domains = < R8A7792_PD_ALWAYS_ON>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
/* Special CPG clocks */
cpg_clocks: cpg_clocks@e615 {
compatible = "renesas,r8a7792-cpg-clocks",

[PATCH 1/2] ARM: dts: r8a7792: add EtherAVB clocks

[Sergei Shtylyov]

Add the EtherAVB clock and its parent, HP clock to the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792.dtsi |   16 
 1 file changed, 16 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -464,6 +464,13 @@
clock-div = <6>;
clock-mult = <1>;
};
+   hp_clk: hp {
+   compatible = "fixed-factor-clock";
+   clocks = <_clocks R8A7792_CLK_PLL1>;
+   #clock-cells = <0>;
+   clock-div = <12>;
+   clock-mult = <1>;
+   };
p_clk: p {
compatible = "fixed-factor-clock";
clocks = <_clocks R8A7792_CLK_PLL1>;
@@ -531,6 +538,15 @@
clock-output-names = "hscif1", "hscif0", "scif3",
 "scif2", "scif1", "scif0";
};
+   mstp8_clks: mstp8_clks@e6150990 {
+   compatible = "renesas,r8a7792-mstp-clocks",
+"renesas,cpg-mstp-clocks";
+   reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
+   clocks = <_clk>;
+   #clock-cells = <1>;
+   clock-indices = ;
+   clock-output-names = "etheravb";
+   };
mstp9_clks: mstp9_clks@e6150994 {
compatible = "renesas,r8a7792-mstp-clocks",
 "renesas,cpg-mstp-clocks";

[PATCH 0/2] Add R8A7792 EtherAVB support

[Sergei Shtylyov]

Hello.

   Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160704-v4.7-rc6' tag plus the R8A7792 PFC/GPIO patchsets.
We're adding the R8A7792 EtherAVB clocks and device nodes. They have been
tested on the Blanche board (along with the EtherAVB patches)...

[1/2] ARM: dts: r8a7792: add EtherAVB clocks
[2/2] ARM: dts: r8a7792: add EtherAVB support

WBR, Sergei

[PATCH 1/2] ARM: dts: r8a7792: add GPIO clocks

[Sergei Shtylyov]

Describe the GPIO clocks in the R8A7792 device tree.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792.dtsi |   21 +
 1 file changed, 21 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -363,6 +363,27 @@
clock-output-names = "hscif1", "hscif0", "scif3",
 "scif2", "scif1", "scif0";
};
+   mstp9_clks: mstp9_clks@e6150994 {
+   compatible = "renesas,r8a7792-mstp-clocks",
+"renesas,cpg-mstp-clocks";
+   reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>;
+   clocks = <_clk>, <_clk>, <_clk>, <_clk>,
+<_clk>, <_clk>, <_clk>, <_clk>,
+<_clk>, <_clk>, <_clk>, <_clk>;
+   #clock-cells = <1>;
+   clock-indices = <
+   R8A7792_CLK_GPIO7 R8A7792_CLK_GPIO6
+   R8A7792_CLK_GPIO5 R8A7792_CLK_GPIO4
+   R8A7792_CLK_GPIO3 R8A7792_CLK_GPIO2
+   R8A7792_CLK_GPIO1 R8A7792_CLK_GPIO0
+   R8A7792_CLK_GPIO11 R8A7792_CLK_GPIO10
+   R8A7792_CLK_GPIO9 R8A7792_CLK_GPIO8
+   >;
+   clock-output-names =
+   "gpio7", "gpio6", "gpio5", "gpio4",
+   "gpio3", "gpio2", "gpio1", "gpio0",
+   "gpio11", "gpio10", "gpio9", "gpio8";
+   };
};
 
/* External root clock */

[PATCH 0/2] Add R8A7792 GPIO support

[Sergei Shtylyov]

Hello.

   Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160704-v4.7-rc6' tag. We're adding the R8A7792 GPIO clocks and
device nodes. These patches depend on the R8A7792/Blanche PFC patchset in order
to compile and on the R8a7792 PFC driver patchset in order to work properly.

[1/2] ARM: dts: r8a7792: add GPIO clocks
[2/2] ARM: dts: r8a7792: add GPIO support

WBR, Sergei

[PATCH v2 3/3] ARM: dts: blanche: add Ethernet pins

[Sergei Shtylyov]

Add the (previously omitted) pin data for the SMSC LAN89218 Ethernet chip
to the Blanche board's device tree: the chip's IRQ output is connected to
the SoC's IRQ0 pin and its nCS input is connected to the SoC's EX_CS0# pin.

Signed-off-by: Sergei Shtylyov 

---
 arch/arm/boot/dts/r8a7792-blanche.dts |   15 +++
 1 file changed, 15 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792-blanche.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -50,6 +50,9 @@
reg-io-width = <4>;
vddvario-supply = <_3v>;
vdd33a-supply = <_3v>;
+
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
};
 };
 
@@ -67,6 +70,18 @@
groups = "scif3_data";
function = "scif3";
};
+
+   lan89218_pins: lan89218 {
+   intc {
+   groups = "intc_irq0";
+   function = "intc";
+   };
+   lbsc {
+   groups = "lbsc_ex_cs0";
+   function = "lbsc";
+   };
+   };
+
 };
 
  {

[PATCH v2 2/3] ARM: dts: blanche: add SCIF0/3 pins

[Sergei Shtylyov]

Add the (previously omitted) SCIF0/3 pin data to the Blanche board's
device tree.

Signed-off-by: Sergei Shtylyov 
Reviewed-by: Geert Uytterhoeven 

---
Changes in version 2:
- added Geert's tag.

 arch/arm/boot/dts/r8a7792-blanche.dts |   18 ++
 1 file changed, 18 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792-blanche.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7792-blanche.dts
+++ renesas/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -57,10 +57,28 @@
clock-frequency = <2000>;
 };
 
+ {
+   scif0_pins: scif0 {
+   groups = "scif0_data";
+   function = "scif0";
+   };
+
+   scif3_pins: scif3 {
+   groups = "scif3_data";
+   function = "scif3";
+   };
+};
+
  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
status = "okay";
 };
 
  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
status = "okay";
 };

[PATCH v2 1/3] ARM: dts: r8a7792: add PFC support

[Sergei Shtylyov]

Define the generic R8A7792 part of the PFC device node.

Signed-off-by: Sergei Shtylyov 
Reviewed-by: Geert Uytterhoeven 

---
Changes in version 2:
- killed extra empty line;
- added Geert's tag.

 arch/arm/boot/dts/r8a7792.dtsi |5 +
 1 file changed, 5 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7792.dtsi
+++ renesas/arch/arm/boot/dts/r8a7792.dtsi
@@ -108,6 +108,11 @@
#power-domain-cells = <1>;
};
 
+   pfc: pin-controller@e606 {
+   compatible = "renesas,pfc-r8a7792";
+   reg = <0 0xe606 0 0x144>;
+   };
+
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a7792",
 "renesas,rcar-dmac";

Re: [PATCH 1/2] pinctrl: sh-pfc: fix overly long lines

[Sergei Shtylyov]

On 07/04/2016 10:15 PM, Sergei Shtylyov wrote:


The PORT_GP_CFG_() macros take up more than 80 columns -- and not for
a good reason. Make the header file checkpatch.pl-proof at least in this
respect...

Signed-off-by: Sergei Shtylyov 


Reviewed-by: Geert Uytterhoeven 

But it doesn't apply, due to "pinctrl: sh-pfc: Initial R8A7796 PFC support"


   ... and *still* not merged? Or am I looking at a wrong tree? :-/


which was submitted one day earlier.


   I don't think that matters... What matters are the order of merges.


  Moreover, I couldn't find this patch in my mail and in the mail archive 
(marc.info) too -- I'm only seeing your comments to that patch. Where can I 
find the patch itself?


MBR, Sergei

Re: [PATCH 1/2] pinctrl: sh-pfc: fix overly long lines

[Sergei Shtylyov]

On 07/01/2016 10:50 AM, Geert Uytterhoeven wrote:


The PORT_GP_CFG_() macros take up more than 80 columns -- and not for
a good reason. Make the header file checkpatch.pl-proof at least in this
respect...

Signed-off-by: Sergei Shtylyov 


Reviewed-by: Geert Uytterhoeven 

But it doesn't apply, due to "pinctrl: sh-pfc: Initial R8A7796 PFC support"


   ... and *still* not merged? Or am I looking at a wrong tree? :-/


which was submitted one day earlier.


   I don't think that matters... What matters are the order of merges.


Gr{oetje,eeting}s,

Geert


MBR, Sergei

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Geert Uytterhoeven]

Hi Ulf,

On Wed, Jun 29, 2016 at 7:30 PM, Ulf Hansson  wrote:
> On 28 June 2016 at 18:26, Geert Uytterhoeven  wrote:
>> This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on
>
> Thanks for reporting!
>
>> sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller 
>> is a
>> child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
>> simple-pm-bus, cfr.
>>
>> arch/arm/boot/dts/r8a73a4-ape6evm.dts
>> arch/arm/boot/dts/r8a73a4.dtsi
>> arch/arm/boot/dts/sh73a0-kzm9g.dts
>> arch/arm/boot/dts/sh73a0.dtsi
>>
>> During resume, the bus clock is not enabled, causing an imprecise abort
>> when accessing the Ethernet controller's registers. With some debug code
>> added:
>
> I was looking into this in some more detail.
>
> As you are stating that Ethernet device is a child device to the local
> bus device, I would have expected that the pm_runtime_get_sync()
> invoked during ->probe() in the Ethernet driver should cause its
> parent device (the bus device) to be "forced" resumed.
>
> That's because the pm_runtime_get_sync() should trigger an increased
> usage count of the parent device. Later, when
> pm_runtime_force_resume() validates the count for the bus device, it
> should be 2 and thus it should lead to that it decides to *not* defer
> the resume of the device. Apparently this isn't happening for some
> reason...
>
> Perhaps there's a pm_suspend_ignore_children() set for the parent?
> Or perhaps the parent/child relationship isn't set up correctly?

No, ignore_children = 0. I've dumped all fields from the bus' prepare
callback I had added for Kevin's test:

PM: Suspending system (mem)
simple-pm-bus fec1.bus: simple_pm_bus_prepare
can_wakeup = 0
async_suspend = 0
is_prepared = 0
is_suspended = 0
is_noirq_suspended = 0
is_late_suspended = 0
early_init = 1
direct_complete = 0
wakeup_path = 0
syscore = 0
no_pm_callbacks = 0
timer_expires = 0
usage_count = 1
child_count = 1
disable_depth = 0
idle_notification = 0
request_pending = 0
deferred_resume = 0
run_wake = 0
runtime_auto = 1
ignore_children = 0
no_callbacks = 0
irq_safe = 0
use_autosuspend = 0
timer_autosuspends = 0
memalloc_noio = 1
request = 0
runtime_status = 0
runtime_error = 0
autosuspend_delay = 0
last_busy = 429493
active_jiffies = 0
suspended_jiffies = 430
accounting_timestamp = 429493
PM: suspend of devices complete after 4.394 msecs

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

[Geert Uytterhoeven]

Hi Kevin,

On Fri, Jul 1, 2016 at 12:40 AM, Kevin Hilman  wrote:
> Geert Uytterhoeven  writes:
>> On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson  wrote:
>>> When the pm_runtime_force_suspend|resume() helpers were invented, we still
>>> had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as separate Kconfig options.
>>>
>>> To make sure these helpers worked for all combinations and without
>>> introducing too much of complexity, the device was always resumed in
>>> pm_runtime_force_resume().
>>>
>>> More precisely, when CONFIG_PM_SLEEP was set and CONFIG_PM_RUNTIME was
>>> unset, we needed to resume the device as the subsystem/driver couldn't
>>> rely on using runtime PM to do it.
>>>
>>> As the CONFIG_PM_RUNTIME option was merged into CONFIG_PM a while ago, it
>>> removed this combination, of using CONFIG_PM_SLEEP without the earlier
>>> CONFIG_PM_RUNTIME.
>>>
>>> For this reason we can now rely on the subsystem/driver to use runtime PM
>>> to resume the device, instead of forcing that to be done in all cases. In
>>> other words, let's defer this to a later point when it's actually needed.
>>>
>>> Signed-off-by: Ulf Hansson 
>>> ---
>>>  drivers/base/power/runtime.c | 11 +++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
>>> index 09e4eb1..1db7b46 100644
>>> --- a/drivers/base/power/runtime.c
>>> +++ b/drivers/base/power/runtime.c
>>> @@ -1509,6 +1509,17 @@ int pm_runtime_force_resume(struct device *dev)
>>> if (!pm_runtime_status_suspended(dev))
>>> goto out;
>>>
>>> +   /*
>>> +* The PM core increases the runtime PM usage count in the system PM
>>> +* prepare phase. If the count is greather than 1 at this point, 
>>> someone
>>> +* else has also increased it. In that case, invoke the runtime 
>>> resume
>>> +* callback for the device as that is likely what is expected. In 
>>> other
>>> +* case we trust the subsystem/driver to runtime resume the device 
>>> when
>>> +* it's actually needed.
>>> +*/
>>> +   if (atomic_read(>power.usage_count) < 2)
>>> +   goto out;
>>> +
>>> ret = pm_runtime_set_active(dev);
>>> if (ret)
>>> goto out;
>>
>> This patch (commit eb13a0a1b6d5d5c2 in pm/linux-next) breaks resume on
>> sh73a0/kzm9g and r8a73a4/ape6evm. On these boards, the Ethernet controller 
>> is a
>> child of a local bus (bsc), whose clock (zb) is controlled through pm_clk and
>> simple-pm-bus, cfr.
>>
>> arch/arm/boot/dts/r8a73a4-ape6evm.dts
>> arch/arm/boot/dts/r8a73a4.dtsi
>> arch/arm/boot/dts/sh73a0-kzm9g.dts
>> arch/arm/boot/dts/sh73a0.dtsi
>>
>> During resume, the bus clock is not enabled, causing an imprecise abort
>> when accessing the Ethernet controller's registers.
>
> I have a hunch (without too much digging) that this may be an odd
> interaction with the direct_complete stuff since the simple-pm-bus has
> no callbacks.
>
> For kicks, could you add something like the hack below (untested) which
> will avoid the direct_complete path, and at least help indicate if
> that path is worth investigating further.

Thanks!
()
> diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
> index c5eb46cbf388..63b95fb21510 100644
> --- a/drivers/bus/simple-pm-bus.c
> +++ b/drivers/bus/simple-pm-bus.c
> @@ -36,6 +36,15 @@ static int simple_pm_bus_remove(struct platform_device 
> *pdev)
> return 0;
>  }
>
> +static int simple_pm_bus_prepare(struct device *dev)
> +{
> +   return pm_generic_prepare(dev);

This causes an infinite loop, as pm_generic_prepare just calls
dev->driver->pm->prepare(dev);

> +}
> +
> +static const struct dev_pm_ops simple_pm_bus_ops = {
> +   .prepare = simple_pm_bus_prepare,
> +};
> +
>  static const struct of_device_id simple_pm_bus_of_match[] = {
> { .compatible = "simple-pm-bus", },
> { /* sentinel */ }
> @@ -48,6 +57,7 @@ static struct platform_driver simple_pm_bus_driver = {
> .driver = {
> .name = "simple-pm-bus",
> .of_match_table = simple_pm_bus_of_match,
> +   .pm = _pm_bus_ops,
> },
>  };

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/2] arm64: dts: r8a7795: add FDP1 device nodes

[Simon Horman]

On Fri, Jul 01, 2016 at 03:37:23PM +0100, Kieran Bingham wrote:
> Hi Simon,
> 
> The bindings for this have now been acked by RobH.

Thanks, I have queued these up for v4.9.

There was a small amount of fuzz when applying the first patch,
please check to make sure it has been applied correctly once
it hits the devel branch of the renesas tree.

Re: [PATCH v2 0/4] arm64: dts: r8a7795: Add HSUSB device node and enable channel 0 of USB2.0

[Simon Horman]

On Tue, Jun 28, 2016 at 11:25:04AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> > From: Yoshihiro Shimoda
> > Sent: Monday, May 30, 2016 12:30 PM
> > 
> > Hi Simon-san,
> > 
> > > From: Simon Horman
> > > Sent: Monday, May 30, 2016 10:23 AM
> > >
> > > On Thu, May 26, 2016 at 11:46:36AM +0900, Simon Horman wrote:
> > > > On Tue, May 24, 2016 at 07:34:14PM +0900, Yoshihiro Shimoda wrote:
> > > > > This patch is based on the renesas-drivers / 
> > > > > renesas-drivers-2016-05-17-v4.6 tag.
> > > >
> > > > Thanks, I have queued this up for v4.8.
> > > > Please let me know if that was not your intention.
> > >
> > > Hi Shimoda-san,
> > >
> > > unfortunately I have observed a problem with patch 3/4 ("arm64: dts:
> > > salvator-x: enable USB 2.0 Host channel 0") after rebasing the
> > > arm64-dt-for-v4.8 branch of the renesas tree on v4.7-rc1.
> > >
> > > The problem I see occurs when booting using "defconfig" to an NFS-root
> > > Debian user-space as per the boot log below. It appears to be readily
> > > reproducible in my environment.
> > 
> > Thank you for the report!
> > I also reproduced this issue if I set the SW15 to pin 1-2 side on the board 
> > (this is the default setting).
> > (My environment is NFS-rootfs and Yocto user-space.)
> > If I set the SW15 to pin 2-3 side (as the commit log mentioned), this issue 
> > disappeared.
> > Anyway, I will investigate this issue later.
> 
> I found a root cause and I sent fixed patch to the phy maintainer:
> http://thread.gmane.org/gmane.linux.kernel.renesas-soc/5187
> 
> However, I guess there is a bad timing to submit this patch set now,
> So, I intend to resubmit the integration patches after the fixed patch is 
> merged
> into the phy maintainer's repo.
> (In other words, the integration patches should be for v4.9)

Understood.

Please feel free to send the integration patches for v4.9 at any time:
there is no need to wait for rc1 or anything like that.

RE: [PATCH 4/7] bus: arm-cci: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

 
>
>On Fri, Jul 01, 2016 at 11:29:58AM +0100, Suzuki K Poulose wrote:
>> On 01/07/16 10:41, Peter Chen wrote:
>> >of_node_put needs to be called when the device node which is got from
>> >of_parse_phandle has finished using.
>> >
>> >Cc: Will Deacon 
>> >Cc: Suzuki K Poulose 
>> >Signed-off-by: Peter Chen 
>>
>> Thanks for the fix.
>>
>> >---
>> >  drivers/bus/arm-cci.c | 5 -
>> >  1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c index
>> >a49b283..e7b0b8c 100644
>> >--- a/drivers/bus/arm-cci.c
>> >+++ b/drivers/bus/arm-cci.c
>> >@@ -1912,9 +1912,12 @@ static int __cci_ace_get_port(struct device_node *dn,
>int type)
>> >cci_portn = of_parse_phandle(dn, "cci-control-port", 0);
>> >for (i = 0; i < nb_cci_ports; i++) {
>> >ace_match = ports[i].type == type;
>> >-   if (ace_match && cci_portn == ports[i].dn)
>> >+   if (ace_match && cci_portn == ports[i].dn) {
>> >+   of_node_put(cci_portn);
>> >return i;
>> >+   }
>> >}
>> >+   of_node_put(cci_portn);
>>
>> nit: Could we please do some thing like this ?
>>  if (ace_match && cci_portn == ports[i].dn)
>>  break;
>>  }
>>
>>  of_node_put(cci_portn);
>>  return (i < nb_cci_ports) ? i : -ENODEV ;
>>
>> Either way,
>>
>> Reviewed-by: Suzuki K Poulose 
>
>Please route this via arm-soc once you've addressed Suzuki's comment.
>

Hi Will, how to route patch via arm-soc?

Does it mean sending patch by adding a...@kernel.org at To or Cc list?

Peter

Re: [PATCH 4/7] bus: arm-cci: add missing of_node_put after calling of_parse_phandle

[Will Deacon]

On Mon, Jul 04, 2016 at 02:48:08AM +, Peter Chen wrote:
> >Please route this via arm-soc once you've addressed Suzuki's comment.
> 
> Hi Will, how to route patch via arm-soc?
> 
> Does it mean sending patch by adding a...@kernel.org at To or Cc list?

Yes. I just wanted to make it clear that I don't intend to pick this up
(since I'd just send it to arm-soc anyway!).

Will

Re: [PATCH 07/39 v2] ASoC: simple-card-utils: add asoc_simple_card_parse_card_name()

[Kuninori Morimoto]

Hi Mark

Thank you for your feedback

> > This function tries to get card name from snd_soc_of_parse_card_name().
> > and it tries to set card->name from dai_link if card still doesn't have 
> > name.
> > So, above is optional 2nd try.
> > Or, do you mean this if (!card->name) can goes to simple-card, instead of 
> > utils ?
> > I have no objection about it , but it can be double handling ?
> > Because other simple family have same situation.
> 
> If we try to dereference card->dai_link without checking to see if it's
> set then we'll crash.

Ahh, do you mean we need like this ?

if (!card->name && card->dai_link)
card->name = card->dai_link->name;

Re: [PATCH 07/39 v2] ASoC: simple-card-utils: add asoc_simple_card_parse_card_name()

[Mark Brown]

On Mon, Jul 04, 2016 at 12:20:29AM +, Kuninori Morimoto wrote:

> > > > > > +   if (!card->name)
> > > > > > +   card->name = card->dai_link->name;

> > > > > This will unconditionally defererence dai_link but it's optional - we
> > > > > can have analogue only cards.

> > > > This is not new feature. Current simple-card already has it.

> > > Right, but simple-card does need DAIs IIRC while this is intended to be
> > > more general.  All it needs is a check before the dereference to be safe
> > > so it's trivial to handle.

> > Sorry, I'm not 100% understand.
> > Do you mean we don't need handle card->name ? (= we should remove above ?)
> > If so, we can't register card on simple-card. Because 
> > snd_soc_register_card()
> > requests it.

> This function tries to get card name from snd_soc_of_parse_card_name().
> and it tries to set card->name from dai_link if card still doesn't have name.
> So, above is optional 2nd try.
> Or, do you mean this if (!card->name) can goes to simple-card, instead of 
> utils ?
> I have no objection about it , but it can be double handling ?
> Because other simple family have same situation.

If we try to dereference card->dai_link without checking to see if it's
set then we'll crash.


signature.asc
Description: PGP signature

RE: [PATCH 2/7] arm: mach-shmobile: pm-rmobile: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

 
>On Fri, Jul 1, 2016 at 11:41 AM, Peter Chen  wrote:
>> of_node_put needs to be called when the device node which is got from
>> of_parse_phandle has finished using.
>>
>> Cc: Simon Horman 
>> Cc: Magnus Damm 
>> Signed-off-by: Peter Chen 
>
>NAKed-by: Geert Uytterhoeven 
>
>> --- a/arch/arm/mach-shmobile/pm-rmobile.c
>> +++ b/arch/arm/mach-shmobile/pm-rmobile.c
>> @@ -209,6 +209,7 @@ static void __init add_special_pd(struct device_node *np,
>enum pd_types type)
>> special_pds[num_special_pds].pd = pd;
>
>The pd pointer is stored in the line above, and released later in 
>put_special_pds().
>
>> special_pds[num_special_pds].type = type;
>> num_special_pds++;
>> +   of_node_put(pd);
>
>Hence it must not be released here, as that would cause a double release when
>put_special_pds() is executed.
>

Thanks, Geert, it is my careless.

Please forget this patch.

Peter

[PATCH v2] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs

[Kuninori Morimoto]

From: Kuninori Morimoto 

thermal_add_hwmon_sysfs()/thermal_remove_hwmon_sysfs() need
EXPORT_SYMBOL_GPL(). Otherwise we will have ERROR

>> ERROR: "thermal_remove_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] 
>> undefined!
>> ERROR: "thermal_add_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] undefined!

Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - EXPORT_SYMBOL -> EXPORT_SYMBOL_GPL

 drivers/thermal/thermal_hwmon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 06fd2ed9..c41c774 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -232,6 +232,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
 
return result;
 }
+EXPORT_SYMBOL_GPL(thermal_add_hwmon_sysfs);
 
 void thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz)
 {
@@ -270,3 +271,4 @@ void thermal_remove_hwmon_sysfs(struct thermal_zone_device 
*tz)
hwmon_device_unregister(hwmon->device);
kfree(hwmon);
 }
+EXPORT_SYMBOL_GPL(thermal_remove_hwmon_sysfs);
-- 
1.9.1

Re: [PATCH] thermal: hwmon: EXPORT_SYMBOL for thermal hwmon sysfs

[Kuninori Morimoto]

Hi Geert

> > +EXPORT_SYMBOL(thermal_add_hwmon_sysfs);
> 
> EXPORT_SYMBOL_GPL?
> That seems to be prevalent in the thermal subsystem, except for a few cases
> in cpu_cooling.c and thermal_helpers.c.

Thanks.
Will fix in v2

Re: [PATCH] thermal: hwmon: EXPORT_SYMBOL for thermal hwmon sysfs

[Geert Uytterhoeven]

Hi Morimoto-san,

On Mon, Jul 4, 2016 at 2:31 AM, Kuninori Morimoto
 wrote:
> From: Kuninori Morimoto 
>
> thermal_add_hwmon_sysfs()/thermal_remove_hwmon_sysfs() need
> EXPORT_SYMBOL(). Otherwise we will have ERROR
>
>>> ERROR: "thermal_remove_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] 
>>> undefined!
>>> ERROR: "thermal_add_hwmon_sysfs" [drivers/thermal/rcar_thermal.ko] 
>>> undefined!
>
> Signed-off-by: Kuninori Morimoto 
> ---
>  drivers/thermal/thermal_hwmon.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
> index 06fd2ed9..8eecba8 100644
> --- a/drivers/thermal/thermal_hwmon.c
> +++ b/drivers/thermal/thermal_hwmon.c
> @@ -232,6 +232,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device 
> *tz)
>
> return result;
>  }
> +EXPORT_SYMBOL(thermal_add_hwmon_sysfs);

EXPORT_SYMBOL_GPL?
That seems to be prevalent in the thermal subsystem, except for a few cases
in cpu_cooling.c and thermal_helpers.c.

>  void thermal_remove_hwmon_sysfs(struct thermal_zone_device *tz)
>  {
> @@ -270,3 +271,4 @@ void thermal_remove_hwmon_sysfs(struct 
> thermal_zone_device *tz)
> hwmon_device_unregister(hwmon->device);
> kfree(hwmon);
>  }
> +EXPORT_SYMBOL(thermal_remove_hwmon_sysfs);

EXPORT_SYMBOL_GPL?

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