RE: renesas sdhi driver and DMA

2017-10-10 Thread Chris Brandt
Hi Wolfram,

On Tuesday, October 10, 2017, Wolfram Sang wrote:
> Isn't it SYS-DMAC compatible (sigh)?

And to answer your question, it's a completely different IP than the 
SYS-DMAC. It's still a multi-channel linked-list descriptor based system 
like SYS-DMAC, but a complete different set of registers.

However, it's a nice piece of IP so we'll probably continue to use it 
for future RZ/A devices.


Chris


[RFC] mmc: tmio: fix tuning for stubborn cards

2017-10-10 Thread Niklas Söderlund
The commit 43b0b361b0170030 ("mmc: tmio: always get number of taps")
changed the behavior of the tuning. Before the commit the SCC was only
enabled for the first tuning attempt (host->init_tuning(host)), if that
failed the hardware where reset and tuning retried. In the second
attempt the SCC where never configured and tuning would succeed for some
stubborn cards. This patch restore this behavior which allows a troubled
card I have to be used.

Without this patch:
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure failed
mmc0: tuning execution failed: -110
mmc0: error -110 whilst initialising SD card
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure failed
mmc0: tuning execution failed: -110
mmc0: error -110 whilst initialising SD card

With this patch:
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: timeout waiting for hardware interrupt (CMD19)
sh_mobile_sdhi ee10.sd: Tuning procedure with SCC enabled failed, retry 
with SCC disabled
mmc0: new ultra high speed SDR50 SDHC card at address 
mmcblk0: mmc0: SU04G 3.69 GiB
 mmcblk0: p1 p2

Fixes: 43b0b361b0170030 ("mmc: tmio: always get number of taps")
Signed-off-by: Niklas Söderlund 
---
 drivers/mmc/host/tmio_mmc_core.c | 50 ++--
 1 file changed, 33 insertions(+), 17 deletions(-)

Hi Wolfram,

I'm pretty sure this is not a proper fix for the underlying problem, but 
at least it restores the previous behavior and get the card working. I 
mostly post this RFC to share my findings and so we have some code to 
try and help us figure out what really is happening here.

// Niklas

diff --git a/drivers/mmc/host/tmio_mmc_core.c b/drivers/mmc/host/tmio_mmc_core.c
index 12cf8288d6635eaf..e7e6a0f3f2610301 100644
--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -819,10 +819,35 @@ static void tmio_mmc_hw_reset(struct mmc_host *mmc)
host->hw_reset(host);
 }
 
+static int __tmio_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
+{
+   struct tmio_mmc_host *host = mmc_priv(mmc);
+   unsigned int i;
+   int ret;
+
+   bitmap_zero(host->taps, host->tap_num * 2);
+
+   /* Issue CMD19 twice for each tap */
+   for (i = 0; i < 2 * host->tap_num; i++) {
+   if (host->prepare_tuning)
+   host->prepare_tuning(host, i % host->tap_num);
+
+   ret = mmc_send_tuning(mmc, opcode, NULL);
+   if (ret && ret != -EILSEQ)
+   return ret;
+   if (ret == 0)
+   set_bit(i, host->taps);
+
+   mdelay(1);
+   }
+
+   return host->select_tuning(host);
+}
+
 static int tmio_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode)
 {
struct tmio_mmc_host *host = mmc_priv(mmc);
-   int i, ret = 0;
+   int ret = 0;
 
if (!host->init_tuning || !host->select_tuning)
/* Tuning is not supported */
@@ -839,24 +864,15 @@ static int tmio_mmc_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
goto out;
}
 
-   bitmap_zero(host->taps, host->tap_num * 2);
-
-   /* Issue CMD19 twice for each tap */
-   for (i = 0; i < 2 * host->tap_num; i++) {
-   if (host->prepare_tuning)
-   host->prepare_tuning(host, i % host->tap_num);
-
-   ret = mmc_send_tuning(mmc, opcode, NULL);
-   if (ret && ret != -EILSEQ)
-   goto out;
-   if (ret == 0)
-   set_bit(i, host->taps);
-
-   mdelay(1);
+   ret = __tmio_mmc_execute_tuning(mmc, opcode);
+   if (ret) {
+   /* Tuning failed with SCC enabled, reset hardware and retry */
+   dev_info(>pdev->dev,
+"Tuning procedure with SCC enabled failed, retry with 
SCC disabled\n");
+   host->hw_reset(host);
+   ret = __tmio_mmc_execute_tuning(mmc, opcode);
}
 
-   ret = host->select_tuning(host);
-
 out:
if (ret < 0) {
dev_warn(>pdev->dev, "Tuning procedure failed\n");
-- 
2.14.2



RE: renesas sdhi driver and DMA

2017-10-10 Thread Chris Brandt
Hi Wolfram,

> > [] (tmio_mmc_dma_callback) from []
> (rzadma_tasklet+0x23/0x98)
> 
> For SYS-DMAC, this is a callback called by the dmaengine core once the
> DMA is completed. My guess is you call it directly from an interrupt
> handler? It would be easier to talk over code here, I guess.
> 
> > Is it now a requirement that I have to register my DMA channel
> > interrupts as devm_request_threaded_irq?
> >
> > Will that fix my issue?
> 
> I can't say yet if this alone will do. Likely not. Can you share the
> code already?

The interrupt handler is starting a tasklet, and then the tasklet calls 
the callback. I thought tasklets didn't run in an interrupt context?


As a code snippet, here is the irq hander and the tasket. Of course I 
can send the entire file if you want as well if you need to see more.


static void dma_irq_handle_channel(struct rzadma_channel *rzadmac)
{
u32 chstat, chctrl;
struct rzadma_engine *rzadma = rzadmac->rzadma;
int channel = rzadmac->channel;

chstat = rzadma_ch_readl(rzadmac, CHSTAT, 1);
if (chstat & CHSTAT_ER) {
dev_dbg(rzadma->dev, "CHSTAT_%d = %08X\n", channel, chstat);
rzadma_ch_writel(rzadmac,
CHCTRL_DEFAULT,
CHCTRL, 1);
goto schedule;
}
if (!(chstat & CHSTAT_END))
return;

chctrl = rzadma_ch_readl(rzadmac, CHCTRL, 1);
dev_dbg(rzadma->dev,"2. chctrl_%d=%08X\n", channel, chctrl);
rzadma_ch_writel(rzadmac,
chctrl | CHCTRL_CLREND | CHCTRL_CLRRQ,
CHCTRL, 1);
schedule:
/* Tasklet irq */
tasklet_schedule(>dma_tasklet);
}


static void rzadma_tasklet(unsigned long data)
{
struct rzadma_channel *rzadmac = (void *)data;
struct rzadma_engine *rzadma = rzadmac->rzadma;
struct rzadma_desc *desc;
unsigned long flags;

/* Protection of critical section */
spin_lock_irqsave(>lock, flags);

if (list_empty(>ld_active)) {
/* Someone might have called terminate all */
goto out;
}

desc = list_first_entry(>ld_active, struct rzadma_desc, node);

if (desc->desc.callback)
desc->desc.callback(desc->desc.callback_param);

dma_cookie_complete(>desc);

if (list_empty(>ld_active)) {
goto out;
}else{
list_move_tail(rzadmac->ld_active.next, >ld_free);
}

if (!list_empty(>ld_queue)) {
desc = list_first_entry(>ld_queue, struct rzadma_desc,
node);
if (rzadma_xfer_desc(desc) < 0){
dev_err(rzadma->dev, "%s: channel: %d couldn't xfer 
desc\n",
 __func__, rzadmac->channel);
}else{
list_move_tail(rzadmac->ld_queue.next, 
>ld_active);
}
}
out:
spin_unlock_irqrestore(>lock, flags);
}



> Isn't it SYS-DMAC compatible (sigh)?

My first goal is to just get this DMA platform driver we made a couple 
years ago working with DT (ie, you can't go passing in slave IDs anymore 
via platform data structures).

Technically, it is working now (after I revert your patch), but I 
probably have more things that have to change before I can think about 
submitting it upstream for review.


Thank you!

Chris



Re: [PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

2017-10-10 Thread Tony Lindgren
* Geert Uytterhoeven  [171003 11:32]:
> On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven  
> wrote:
> > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven  
> > wrote:
> >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre  
> >> wrote:
> >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
> >>> Please send it to RMK's patch system.
> >>
> >> Done (I hope so ;-)
> >
> > Failed. Retrying.
> 
> Yiha ;-)
> 
> http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1

This also fixes the spamming I started seeing with next-20171009:

Tested-by: Tony Lindgren 


renesas sdhi driver and DMA

2017-10-10 Thread Chris Brandt
Hello Wolfram,

For my RZ/A1 DMA driver (it's a work in progress), the patch

52ad9a8e854c ("mmc: host: tmio: ensure end of DMA and SD access are in sync")

now causes a "BUG: scheduling while atomic"

Starting logging: BUG: scheduling while atomic: S01logging/434/0x0100
CPU: 0 PID: 434 Comm: S01logging Not tainted 4.9.49-g845fe5990-dirty #29
Hardware name: Generic R7S72100 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0xb/0xc)
[] (show_stack) from [] (__schedule_bug+0x39/0x58)
[] (__schedule_bug) from [] (__schedule+0x21/0x238)
[] (__schedule) from [] (schedule+0x51/0x58)
[] (schedule) from [] (schedule_timeout+0x15/0xcc)
[] (schedule_timeout) from [] (wait_for_common+0x9b/0xbc)
[] (wait_for_common) from [] 
(tmio_mmc_dma_callback+0xb/0x74)
[] (tmio_mmc_dma_callback) from [] 
(rzadma_tasklet+0x23/0x98)
[] (rzadma_tasklet) from [] (tasklet_action+0x3f/0x5c)
[] (tasklet_action) from [] (__do_softirq+0x7f/0x144)
[] (__do_softirq) from [] (__handle_domain_irq+0x51/0x6a)
[] (__handle_domain_irq) from [] (gic_handle_irq+0x37/0x58)
[] (gic_handle_irq) from [] (__irq_svc+0x65/0x94)


I noticed that in rcar-dmac.c, the DMA channel IRQs are threaded:

ret = devm_request_threaded_irq(dmac->dev, irq, rcar_dmac_isr_channel,
rcar_dmac_isr_channel_thread, 0,
irqname, rchan);

Is it now a requirement that I have to register my DMA channel 
interrupts as devm_request_threaded_irq?

Will that fix my issue?

Thank you,
Chris



Re: [PATCH 2/2] usb: renesas_usbhs: add support for R-Car D3

2017-10-10 Thread Rob Herring
On Tue, Oct 03, 2017 at 08:09:14PM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for R-Car D3. This SoC needs to release
> the PLL reset by the UGCTRL register. So, since this is not the same
> as other R-Car Gen3 SoCs, this patch adds a new type as
> "USBHS_TYPE_RCAR_GEN3_WITH_PLL".
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  .../devicetree/bindings/usb/renesas_usbhs.txt  |  1 +
>  drivers/usb/renesas_usbhs/common.c | 10 -
>  drivers/usb/renesas_usbhs/rcar3.c  | 48 
> ++
>  drivers/usb/renesas_usbhs/rcar3.h  |  1 +
>  include/linux/usb/renesas_usbhs.h  |  5 ++-
>  5 files changed, 62 insertions(+), 3 deletions(-)

Acked-by: Rob Herring 


Re: [PATCH v2 04/18] arm64: dts: m3ulcb-kf: initial device tree

2017-10-10 Thread Vladimir Barinov

Hi Simon,

On 09.10.2017 10:18, Simon Horman wrote:

On Fri, Oct 06, 2017 at 11:18:00AM +0200, Simon Horman wrote:

On Fri, Oct 06, 2017 at 05:47:25AM +0300, Vladimir Barinov wrote:

Hi Simon, Geert,

Do you need extra actions from my side to accept this patch?

Yes, I need patch 3/18.
Could you repost it?

I see you have done so, thanks.

I have applied this patch with Geert's tag.  I had to apply the patch
manually so please check that I did so correctly once I have pushed the
next branch to the renesas tree a little later today.

I've verified that all is correct.
Thank you.

--
Regards,
Vladimir



[PATCH/RFC 1/5] dt-bindings: mfd: bd9571mwv: Document rohm,ddr-backup-power

2017-10-10 Thread Geert Uytterhoeven
Document the new optional "rohm,ddr-backup-power" property.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt 
b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
index 9ab216a851d5619b..7ea3f2db41d4e501 100644
--- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
+++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
@@ -25,6 +25,12 @@ Required properties:
Each child node is defined using the standard
binding for regulators.
 
+Optional properties:
+  - rohm,ddr-backup-power : Value to use for DDR-Backup Power.  This controls
+   which DDR rails need to be kept powered when backup
+   mode is enabled, cfr. the KEEPON_DDR* bits in the
+   documentation for the "BKUP Mode Cnt" register.
+
 Example:
 
pmic: pmic@30 {
@@ -36,6 +42,7 @@ Example:
#interrupt-cells = <2>;
gpio-controller;
#gpio-cells = <2>;
+   rohm,ddr-backup-power = <15>;
 
regulators {
dvfs: dvfs {
-- 
2.7.4



[PATCH/RFC 0/5] arm64: dts: renesas: Salvator-X/XS: Enable DDR Backup Mode

2017-10-10 Thread Geert Uytterhoeven
Hi all,

The ROHM BD9571MWV PMIC on the Renesas Salvator-X/XS development boards
supports DDR Backup Power, which means that the DDR power rails can be
kept powered while the main SoC is powered down.

Currently performing a system suspend/resume cycle involves several
manual steps:
  1. Configure the PMIC for Backup Mode, using
 "i2cset -f -y 7 0x30 0x20 0x0f",
  2. Switch off SW23 (the ACC switch, which now changes role from power
 switch to wake-up switch) to prepare for suspend,
  3. Suspend to RAM, using "echo mem > /sys/power/state",
  4. Switch on SW23 to resume.

Especially the first step is cumbersome, as it relies on
  1. Intimate knowledge about the PMIC and actual board design,
  2. direct i2c access,
  3. having the i2cset utility available.
In addition, it has to be redone after system resume.

This patch series integrates Backup Mode configuration into the PMIC
driver, using a sysfs virtual file.  E.g. it can be enabled using:

echo on > 
/sys/devices/platform/soc/e60b.i2c/i2c-7/7-0030/bd9571mwv-regulator.3.auto/backup_mode

Backup Mode state is retained across suspend/resume cycles.

Which DDR rails are to be kept powered is board-specific, and controlled
using the optional "rohm,ddr-backup-power" property in the board DTS
file.

Note that the last patch depends on "[PATCH/RFC] arm64: dts: renesas:
salvator-common: Add BD9571 PMIC".

Thanks for your comments!

Geert Uytterhoeven (5):
  dt-bindings: mfd: bd9571mwv: Document rohm,ddr-backup-power
  mfd: bd9571mwv: Add DDR Backup Power register bit definitions
  mfd: bd9571mwv: Allow DDR Backup Power register access
  regulator: bd9571mwv: Add support for backup mode
  arm64: dts: renesas: salvator-common: Configure PMIC for DDR Backup
  Power

 .../devicetree/bindings/mfd/bd9571mwv.txt  |   7 ++
 arch/arm64/boot/dts/renesas/salvator-common.dtsi   |   1 +
 drivers/mfd/bd9571mwv.c|   2 +
 drivers/regulator/bd9571mwv-regulator.c| 121 -
 include/linux/mfd/bd9571mwv.h  |   5 +
 5 files changed, 134 insertions(+), 2 deletions(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

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

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


[PATCH/RFC 2/5] mfd: bd9571mwv: Add DDR Backup Power register bit definitions

2017-10-10 Thread Geert Uytterhoeven
Add definitions for the KEEPON_* bits in the "BKUP Mode Cnt" register,
which control the DDR rails to be kept powered when backup mode is
enabled.

Signed-off-by: Geert Uytterhoeven 
---
 include/linux/mfd/bd9571mwv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mfd/bd9571mwv.h b/include/linux/mfd/bd9571mwv.h
index f0708ba4cbbae2dc..eb05569f752bb089 100644
--- a/include/linux/mfd/bd9571mwv.h
+++ b/include/linux/mfd/bd9571mwv.h
@@ -33,6 +33,11 @@
 #define BD9571MWV_I2C_MD2_E1_BIT_2 0x12
 
 #define BD9571MWV_BKUP_MODE_CNT0x20
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_MASKGENMASK(3, 0)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR0BIT(0)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR1BIT(1)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR0C   BIT(2)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR1C   BIT(3)
 #define BD9571MWV_BKUP_MODE_STATUS 0x21
 #define BD9571MWV_BKUP_RECOVERY_CNT0x22
 #define BD9571MWV_BKUP_CTRL_TIM_CNT0x23
-- 
2.7.4



[PATCH/RFC 4/5] regulator: bd9571mwv: Add support for backup mode

2017-10-10 Thread Geert Uytterhoeven
The BD9571MWV PMIC supports backup mode, which keeps one or more DDR
rails powered while the main SoC is powered down.

Which DDR rails are to be kept powered is board-specific, and controlled
using the optional "rohm,ddr-backup-power" DT property.  In the absence
of this property, backup mode is not available.

Backup mode is not enabled automatically, as e.g. on Renesas
Salvator-X(S) boards enabling backup mode changes the role of the ACC
switch from a power switch to a wake-up switch.  Hence enabling it
prevents the board from being powered off using the ACC switch, which
may confuse the user.

Backup mode can be enabled or disabled by the user using the
"backup_mode" sysfs file, e.g.

echo on > 
/sys/devices/platform/soc/e60b.i2c/i2c-7/7-0030/bd9571mwv-regulator.3.auto/backup_mode

If enabled by the boot loader, initial backup mode state is retained.
As state is lost by PSCI system suspend, it is restored during system
resume.

Signed-off-by: Geert Uytterhoeven 
---
What's the right place to document regulator sysfs files?
---
 drivers/regulator/bd9571mwv-regulator.c | 121 +++-
 1 file changed, 119 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/bd9571mwv-regulator.c 
b/drivers/regulator/bd9571mwv-regulator.c
index c67a83d53c4cb76b..c7ff67938c3eb48a 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -24,6 +24,14 @@
 
 #include 
 
+struct bd9571mwv_reg {
+   struct bd9571mwv *bd;
+
+   /* DDR Backup Power */
+   u8 bkup_mode_cnt_keepon;/* from "rohm,ddr-backup-power" */
+   u8 bkup_mode_cnt_shadow;
+};
+
 enum bd9571mwv_regulators { VD09, VD18, VD25, VD33, DVFS };
 
 #define BD9571MWV_REG(_name, _of, _id, _ops, _vr, _vm, _nv, _min, _step, 
_lmin)\
@@ -131,14 +139,99 @@ static struct regulator_desc regulators[] = {
  0x80, 60, 1, 0x3c),
 };
 
+static int bd9571mwv_bkup_mode_set(struct bd9571mwv_reg *bdreg, u8 mode)
+{
+   int ret;
+
+   ret = regmap_write(bdreg->bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
+   if (ret) {
+   dev_err(bdreg->bd->dev,
+   "Failed to configure backup mode 0x%x (ret=%i)\n",
+   mode, ret);
+   return ret;
+   }
+
+   bdreg->bkup_mode_cnt_shadow = mode;
+   return 0;
+}
+
+static ssize_t backup_mode_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct bd9571mwv_reg *bdreg = dev_get_drvdata(dev);
+   int enabled = bdreg->bkup_mode_cnt_shadow &
+ BD9571MWV_BKUP_MODE_CNT_KEEPON_MASK;
+
+   return sprintf(buf, "%s\n", enabled ? "on" : "off");
+}
+
+static ssize_t backup_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+   struct bd9571mwv_reg *bdreg = dev_get_drvdata(dev);
+   bool enable;
+   ssize_t ret;
+   u8 mode;
+
+   if (!count)
+   return 0;
+
+   ret = kstrtobool(buf, );
+   if (ret)
+   return ret;
+
+   mode = bdreg->bkup_mode_cnt_shadow &
+  ~BD9571MWV_BKUP_MODE_CNT_KEEPON_MASK;
+   if (enable)
+   mode |= bdreg->bkup_mode_cnt_keepon;
+
+   if (mode == bdreg->bkup_mode_cnt_shadow)
+   return count;
+
+   ret = bd9571mwv_bkup_mode_set(bdreg, mode);
+   if (ret)
+   return ret;
+
+   return count;
+}
+
+DEVICE_ATTR_RW(backup_mode);
+
+#ifdef CONFIG_PM_SLEEP
+static int bd9571mwv_resume(struct device *dev)
+{
+   struct bd9571mwv_reg *bdreg = dev_get_drvdata(dev);
+
+   return bd9571mwv_bkup_mode_set(bdreg, bdreg->bkup_mode_cnt_shadow);
+}
+
+static const struct dev_pm_ops bd9571mwv_pm  = {
+   SET_SYSTEM_SLEEP_PM_OPS(NULL, bd9571mwv_resume)
+};
+
+#define DEV_PM_OPS _pm
+#else
+#define DEV_PM_OPS NULL
+#endif /* CONFIG_PM_SLEEP */
+
 static int bd9571mwv_regulator_probe(struct platform_device *pdev)
 {
struct bd9571mwv *bd = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = { };
+   struct bd9571mwv_reg *bdreg;
struct regulator_dev *rdev;
-   int i;
+   unsigned int val;
+   int i, ret;
+
+   bdreg = devm_kzalloc(>dev, sizeof(*bdreg), GFP_KERNEL);
+   if (!bdreg)
+   return -ENOMEM;
+
+   bdreg->bd = bd;
 
-   platform_set_drvdata(pdev, bd);
+   platform_set_drvdata(pdev, bdreg);
 
config.dev = >dev;
config.dev->of_node = bd->dev->of_node;
@@ -155,6 +248,28 @@ static int bd9571mwv_regulator_probe(struct 
platform_device *pdev)
}
}
 
+   val = 0;
+   of_property_read_u32(bd->dev->of_node, "rohm,ddr-backup-power", );
+   if (val & ~BD9571MWV_BKUP_MODE_CNT_KEEPON_MASK) {
+   

[PATCH/RFC 3/5] mfd: bd9571mwv: Allow DDR Backup Power register access

2017-10-10 Thread Geert Uytterhoeven
Enable read/write access to the BD9571MWV_BKUP_MODE_CNT register, which
is a.o. used to configure DDR Backup Power.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/mfd/bd9571mwv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 64e088dfe7b05b5b..503979c81dae11bb 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -29,6 +29,7 @@ static const struct mfd_cell bd9571mwv_cells[] = {
 
 static const struct regmap_range bd9571mwv_readable_yes_ranges[] = {
regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
regmap_reg_range(BD9571MWV_AVS_SET_MONI, BD9571MWV_AVS_DVFS_VID(3)),
regmap_reg_range(BD9571MWV_VD18_VID, BD9571MWV_VD33_VID),
regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_VINIT),
@@ -44,6 +45,7 @@ static const struct regmap_access_table 
bd9571mwv_readable_table = {
 };
 
 static const struct regmap_range bd9571mwv_writable_yes_ranges[] = {
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
regmap_reg_range(BD9571MWV_AVS_VD09_VID(0), BD9571MWV_AVS_VD09_VID(3)),
regmap_reg_range(BD9571MWV_DVFS_SETVID, BD9571MWV_DVFS_SETVID),
regmap_reg_range(BD9571MWV_GPIO_DIR, BD9571MWV_GPIO_OUT),
-- 
2.7.4



[PATCH/RFC 5/5] arm64: dts: renesas: salvator-common: Configure PMIC for DDR Backup Power

2017-10-10 Thread Geert Uytterhoeven
On Salvator-X(S), all of DDR0, DDR1, DDR0C, and DDR1C need to be kept
powered when backup mode is enabled.

Reflect this in the rohm,ddr-backup-power property for the BD9571MWV
PMIC.

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

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index c171718bac7f52a1..68245d87c305855c 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -366,6 +366,7 @@
#interrupt-cells = <2>;
gpio-controller;
#gpio-cells = <2>;
+   rohm,ddr-backup-power = <15>;
 
regulators {
dvfs: dvfs {
-- 
2.7.4



[PATCH/RFC] arm64: dts: renesas: salvator-common: Add BD9571 PMIC

2017-10-10 Thread Geert Uytterhoeven
Add a device node for the ROHM BD9571MWV PMIC, based on the example in
the DT binding documentation, but using INTC-EX instead.

Signed-off-by: Geert Uytterhoeven 
---
Do we need to describe more regulators?

This depends on:
  - [PATCH] pinctrl: sh-pfc: r8a7796: Add support for INTC-EX IRQ pins,
  - [PATCH] pinctrl: sh-pfc: r8a7795: Add INTC-EX pins, groups and
function.
---
 arch/arm64/boot/dts/renesas/salvator-common.dtsi | 29 
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi 
b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 3dcb26b1cb6bdec0..c171718bac7f52a1 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -353,6 +353,30 @@
 
 _dvfs {
status = "okay";
+
+   pmic: pmic@30 {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   compatible = "rohm,bd9571mwv";
+   reg = <0x30>;
+   interrupt-parent = <_ex>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   regulators {
+   dvfs: dvfs {
+   regulator-name = "dvfs";
+   regulator-min-microvolt = <75>;
+   regulator-max-microvolt = <103>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   };
+   };
 };
 
  {
@@ -407,6 +431,11 @@
function = "i2c2";
};
 
+   irq0_pins: irq0 {
+   groups = "intc_ex_irq0";
+   function = "intc_ex";
+   };
+
pwm1_pins: pwm1 {
groups = "pwm1_a";
function = "pwm1";
-- 
2.7.4



Re: [PATCH v2 2/2] arm64: dts: r8a7796: Add OPPs table for cpu devices

2017-10-10 Thread Geert Uytterhoeven
Hi Sudeep,

On Tue, Oct 10, 2017 at 4:33 PM, Sudeep Holla  wrote:
> On 09/10/17 12:57, Geert Uytterhoeven wrote:
>> On Thu, Oct 5, 2017 at 5:04 PM, Sudeep Holla  wrote:
>>> On 05/10/17 14:26, Simon Horman wrote:
 From: Dien Pham 

 Current, OPP tables are defined temporary,
 they are being evaluated and adjust in future.
>>
 --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
 +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
 @@ -46,6 +46,8 @@
   power-domains = < R8A7796_PD_CA57_CPU0>;
   next-level-cache = <_CA57>;
   enable-method = "psci";
 + clocks =< CPG_CORE R8A7796_CLK_Z>;
 + operating-points-v2 = <_opp>;
   };

   a57_1: cpu@1 {
 @@ -55,6 +57,7 @@
   power-domains = < R8A7796_PD_CA57_CPU1>;
   next-level-cache = <_CA57>;
   enable-method = "psci";
>>>
>>> Just curious why clocks are not specified in secondaries ?
>>
>> Thanks for noticing, it would indeed be good to describe the clock dependency
>> for all CPU cores.
>>
>>> Does this continue work if I hotplug out CPUs in ascending order and
>>> then hotplug back in descending order ? Also the current driver or OS
>>> may deal with that but not a good assumption when write DT
>>
>> Yes that works, as Linux doesn't handle CPU hotplug details.
>> CPU hotplug is controlled by PSCI, i.e. out of control of the Linux kernel.
>> So it doesn't matter at all what is described here ;-)
>>
>
> Ah no, sorry for not being clear earlier. I was referring to below code
> snippet in drivers/cpufreq/cpufreq-dt.c
>
> 162 cpu_clk = clk_get(cpu_dev, NULL);
>
> 163 if (IS_ERR(cpu_clk)) {
>
> 164 ret = PTR_ERR(cpu_clk);
>
> 165 dev_err(cpu_dev, "%s: failed to get clk: %d\n",
> __func__, ret);
> 166 return ret;
>
> 167 }
>
> Now on systems using r8a7796.dtsi, if you hotplug out all A53s and
> hotplug back in A53_3 first, that should trigger cpufreq_driver->init
> from cpufreq_online which should result in execution above code.
>
> If that takes patch of__of_clk_get_by_name, then that may be problem.
> I was originally point at this when I referred hotplug and was not PSCI
> related.

IC.

That's something we cannot try, as the secure firmware doesn't enable the A53
cores, only the A57 cores.

And disabling all A57 cores is also not possible, as at least one of them
has to be kept running.

Gr{oetje,eeting}s,

Geert

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

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


Re: [PATCH v2 2/2] arm64: dts: r8a7796: Add OPPs table for cpu devices

2017-10-10 Thread Sudeep Holla


On 09/10/17 12:57, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Thu, Oct 5, 2017 at 5:04 PM, Sudeep Holla  wrote:
>> On 05/10/17 14:26, Simon Horman wrote:
>>> From: Dien Pham 
>>>
>>> Current, OPP tables are defined temporary,
>>> they are being evaluated and adjust in future.
> 
>>> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
>>> @@ -46,6 +46,8 @@
>>>   power-domains = < R8A7796_PD_CA57_CPU0>;
>>>   next-level-cache = <_CA57>;
>>>   enable-method = "psci";
>>> + clocks =< CPG_CORE R8A7796_CLK_Z>;
>>> + operating-points-v2 = <_opp>;
>>>   };
>>>
>>>   a57_1: cpu@1 {
>>> @@ -55,6 +57,7 @@
>>>   power-domains = < R8A7796_PD_CA57_CPU1>;
>>>   next-level-cache = <_CA57>;
>>>   enable-method = "psci";
>>
>> Just curious why clocks are not specified in secondaries ?
> 
> Thanks for noticing, it would indeed be good to describe the clock dependency
> for all CPU cores.
> 
>> Does this continue work if I hotplug out CPUs in ascending order and
>> then hotplug back in descending order ? Also the current driver or OS
>> may deal with that but not a good assumption when write DT
> 
> Yes that works, as Linux doesn't handle CPU hotplug details.
> CPU hotplug is controlled by PSCI, i.e. out of control of the Linux kernel.
> So it doesn't matter at all what is described here ;-)
> 

Ah no, sorry for not being clear earlier. I was referring to below code
snippet in drivers/cpufreq/cpufreq-dt.c

162 cpu_clk = clk_get(cpu_dev, NULL);

163 if (IS_ERR(cpu_clk)) {

164 ret = PTR_ERR(cpu_clk);

165 dev_err(cpu_dev, "%s: failed to get clk: %d\n",
__func__, ret);
166 return ret;

167 }

Now on systems using r8a7796.dtsi, if you hotplug out all A53s and
hotplug back in A53_3 first, that should trigger cpufreq_driver->init
from cpufreq_online which should result in execution above code.

If that takes patch of__of_clk_get_by_name, then that may be problem.
I was originally point at this when I referred hotplug and was not PSCI
related.

-- 
Regards,
Sudeep


Re: mmc: exceeding card's volts

2017-10-10 Thread Geert Uytterhoeven
Hi Wolfram,

On Tue, Oct 10, 2017 at 12:32 PM, Wolfram Sang  wrote:
>> During next boot, everything was back to normal again...
>
> Double-checking: Normal means also no tuning error?

Correct.

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] extcon: Split out extcon header file for consumer and provider device

2017-10-10 Thread Yoshihiro Shimoda
Hi,

> From: Chanwoo Choi, Sent: Tuesday, October 10, 2017 7:18 PM
> 
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
> 
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
>   device driver. This header file contains the following APIs:
>   : Register/unregister the notifier to catch the change of extcon device
>   : Get the extcon device instance
>   : Get the extcon device name
>   : Get the state of each external connector
>   : Get the property value of each external connector
>   : Get the property capability of each external connector
> 
> - extcon-provider.h includes the extcon API and data structure for extcon
>   provider device driver. This header file contains the following APIs:
>   : Include 'include/linux/extcon.h'
>   : Allocate the memory for extcon device instance
>   : Register/unregister extcon device
>   : Set the state of each external connector
>   : Set the property value of each external connector
>   : Set the property capability of each external connector
> 
> Cc: Felipe Balbi 
> Cc: Kishon Vijay Abraham I 
> Cc: Greg Kroah-Hartman 
> Acked-by: Sebastian Reichel 
> Acked-by: Chen-Yu Tsai 
> Acked-by: Charles Keepax 
> Acked-by: Lee Jones 
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Don't touch drivers/usb/renesas_usbhs/common.h.
> - Add acked-by from Sebastian Reichel (for drivers/power/supply/)
> - Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
> - Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
> - Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)
< snip >
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-

and

< snip >
>  drivers/usb/gadget/udc/renesas_usb3.c |   2 +-

Acked-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda



Re: mmc: exceeding card's volts

2017-10-10 Thread Wolfram Sang

> During next boot, everything was back to normal again...

Double-checking: Normal means also no tuning error?



signature.asc
Description: PGP signature


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

2017-10-10 Thread Felipe Balbi

Hi,

Chanwoo Choi  writes:
> The extcon has two type of extcon devices as following.
> - 'extcon provider deivce' adds new extcon device and detect the
>state/properties of external connector. Also, it notifies the
>state/properties to the extcon consumer device.
> - 'extcon consumer device' gets the change state/properties
>from extcon provider device.
> Prior to that, include/linux/extcon.h contains all exported API for
> both provider and consumer device driver. To clarify the meaning of
> header file and to remove the wrong use-case on consumer device,
> this patch separates into extcon.h and extcon-provider.h.
>
> [Description for include/linux/{extcon.h|extcon-provider.h}]
> - extcon.h includes the extcon API and data structure for extcon consumer
>   device driver. This header file contains the following APIs:
>   : Register/unregister the notifier to catch the change of extcon device
>   : Get the extcon device instance
>   : Get the extcon device name
>   : Get the state of each external connector
>   : Get the property value of each external connector
>   : Get the property capability of each external connector
>
> - extcon-provider.h includes the extcon API and data structure for extcon
>   provider device driver. This header file contains the following APIs:
>   : Include 'include/linux/extcon.h'
>   : Allocate the memory for extcon device instance
>   : Register/unregister extcon device
>   : Set the state of each external connector
>   : Set the property value of each external connector
>   : Set the property capability of each external connector
>
> Cc: Felipe Balbi 

Acked-by: Felipe Balbi 

-- 
balbi


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

2017-10-10 Thread Chanwoo Choi
The extcon has two type of extcon devices as following.
- 'extcon provider deivce' adds new extcon device and detect the
   state/properties of external connector. Also, it notifies the
   state/properties to the extcon consumer device.
- 'extcon consumer device' gets the change state/properties
   from extcon provider device.
Prior to that, include/linux/extcon.h contains all exported API for
both provider and consumer device driver. To clarify the meaning of
header file and to remove the wrong use-case on consumer device,
this patch separates into extcon.h and extcon-provider.h.

[Description for include/linux/{extcon.h|extcon-provider.h}]
- extcon.h includes the extcon API and data structure for extcon consumer
  device driver. This header file contains the following APIs:
  : Register/unregister the notifier to catch the change of extcon device
  : Get the extcon device instance
  : Get the extcon device name
  : Get the state of each external connector
  : Get the property value of each external connector
  : Get the property capability of each external connector

- extcon-provider.h includes the extcon API and data structure for extcon
  provider device driver. This header file contains the following APIs:
  : Include 'include/linux/extcon.h'
  : Allocate the memory for extcon device instance
  : Register/unregister extcon device
  : Set the state of each external connector
  : Set the property value of each external connector
  : Set the property capability of each external connector

Cc: Felipe Balbi 
Cc: Kishon Vijay Abraham I 
Cc: Greg Kroah-Hartman 
Acked-by: Sebastian Reichel 
Acked-by: Chen-Yu Tsai 
Acked-by: Charles Keepax 
Acked-by: Lee Jones 
Signed-off-by: Chanwoo Choi 
---
Changes from v1:
- Don't touch drivers/usb/renesas_usbhs/common.h.
- Add acked-by from Sebastian Reichel (for drivers/power/supply/)
- Add acked-by from Chen-Yu Tsai (for phy-sun4i-usb.c & extcon-axp288.c)
- Add acked-by from Charles Keepax (for drivers/extcon/extcon-arizona.c)
- Add acked-by from Lee Jones (fo include/linux/mfd/palmas.h)

 drivers/extcon/extcon-adc-jack.c  |   2 +-
 drivers/extcon/extcon-arizona.c   |   2 +-
 drivers/extcon/extcon-axp288.c|   2 +-
 drivers/extcon/extcon-gpio.c  |   2 +-
 drivers/extcon/extcon-intel-cht-wc.c  |   2 +-
 drivers/extcon/extcon-intel-int3496.c |   2 +-
 drivers/extcon/extcon-max14577.c  |   2 +-
 drivers/extcon/extcon-max3355.c   |   2 +-
 drivers/extcon/extcon-max77693.c  |   2 +-
 drivers/extcon/extcon-max77843.c  |   2 +-
 drivers/extcon/extcon-max8997.c   |   2 +-
 drivers/extcon/extcon-qcom-spmi-misc.c|   2 +-
 drivers/extcon/extcon-rt8973a.c   |   2 +-
 drivers/extcon/extcon-sm5502.c|   2 +-
 drivers/extcon/extcon-usb-gpio.c  |   2 +-
 drivers/extcon/extcon-usbc-cros-ec.c  |   2 +-
 drivers/extcon/extcon.h   |   2 +-
 drivers/phy/allwinner/phy-sun4i-usb.c |   2 +-
 drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c |   2 +-
 drivers/phy/renesas/phy-rcar-gen3-usb2.c  |   2 +-
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c |   2 +-
 drivers/power/supply/qcom_smbb.c  |   2 +-
 drivers/usb/gadget/udc/renesas_usb3.c |   2 +-
 drivers/usb/phy/phy-tahvo.c   |   2 +-
 include/linux/extcon-provider.h   | 142 ++
 include/linux/extcon.h| 109 +---
 include/linux/mfd/palmas.h|   2 +-
 27 files changed, 172 insertions(+), 129 deletions(-)
 create mode 100644 include/linux/extcon-provider.h

diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 6f6537ab0a79..3877d86c746a 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /**
  * struct adc_jack_data - internal data for adc_jack device driver
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index f84da4a17724..da0e9bc4262f 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index f4fd03e58e37..981fba56bc18 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index ebed22f22d75..ab770adcca7e 100644
--- a/drivers/extcon/extcon-gpio.c
+++ 

mmc: exceeding card's volts

2017-10-10 Thread Geert Uytterhoeven
Hi all,

For the first time ever, I saw a dangerous looking "exceeding card's volts"
on Salvator-X with R-Car M3-W ES1.0:

 NET: Registered protocol family 15
 can: controller area network core (rev 20170425 abi 9)
 NET: Registered protocol family 29
+renesas_sdhi_internal_dmac ee14.sd: Tuning procedure failed
+mmc0: tuning execution failed: -5
+mmc0: error -5 whilst initialising MMC card
 can: raw protocol (rev 20170425)
 can: broadcast manager protocol (rev 20170425 t)
 can: netlink gateway (rev 20170425) max_hops=1
+renesas_sdhi_internal_dmac ee14.sd: exceeding card's volts
 renesas_irqc e61c.interrupt-controller: adding to PM domain always-on
+mmc0: error -110 whilst initialising MMC card
 renesas_irqc e61c.interrupt-controller: driving 6 irqs

During next boot, everything was back to normal again...

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 v5 2/4] phy: rcar-gen3-usb2: use enum phy_mode in the role_store()

2017-10-10 Thread Yoshihiro Shimoda
This patch modifies the role_store() to use "enum phy_mode" instead
of the local "bool" for host/device mode selection.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index e00e99a..7314b49 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -219,33 +219,40 @@ static bool rcar_gen3_is_host(struct rcar_gen3_chan *ch)
return !(readl(ch->base + USB2_COMMCTRL) & USB2_COMMCTRL_OTG_PERI);
 }
 
+static enum phy_mode rcar_gen3_get_phy_mode(struct rcar_gen3_chan *ch)
+{
+   if (rcar_gen3_is_host(ch))
+   return PHY_MODE_USB_HOST;
+   else
+   return PHY_MODE_USB_DEVICE;
+}
+
 static ssize_t role_store(struct device *dev, struct device_attribute *attr,
  const char *buf, size_t count)
 {
struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
-   bool is_b_device, is_host, new_mode_is_host;
+   bool is_b_device;
+   enum phy_mode cur_mode, new_mode;
 
if (!ch->has_otg || !ch->phy->init_count)
return -EIO;
 
-   /*
-* is_b_device: true is B-Device. false is A-Device.
-* If {new_mode_}is_host: true is Host mode. false is Peripheral mode.
-*/
-   is_b_device = rcar_gen3_check_id(ch);
-   is_host = rcar_gen3_is_host(ch);
if (!strncmp(buf, "host", strlen("host")))
-   new_mode_is_host = true;
+   new_mode = PHY_MODE_USB_HOST;
else if (!strncmp(buf, "peripheral", strlen("peripheral")))
-   new_mode_is_host = false;
+   new_mode = PHY_MODE_USB_DEVICE;
else
return -EINVAL;
 
+   /* is_b_device: true is B-Device. false is A-Device. */
+   is_b_device = rcar_gen3_check_id(ch);
+   cur_mode = rcar_gen3_get_phy_mode(ch);
+
/* If current and new mode is the same, this returns the error */
-   if (is_host == new_mode_is_host)
+   if (cur_mode == new_mode)
return -EINVAL;
 
-   if (new_mode_is_host) { /* And is_host must be false */
+   if (new_mode == PHY_MODE_USB_HOST) { /* And is_host must be false */
if (!is_b_device)   /* A-Peripheral */
rcar_gen3_init_from_a_peri_to_a_host(ch);
else/* B-Peripheral */
-- 
1.9.1



[PATCH v5 3/4] phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins

2017-10-10 Thread Yoshihiro Shimoda
This patch adds SoC-specific parameter to avoid reading/writing
specific registers wrongly if this driver runs on a SoC which doesn't
have dedicated pins (e.g. R-Car D3). This patch also changes the
value "has_otg" to "has_otg_pins" for slightly easier reading of
the code.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 7314b49..eb9786e 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,6 +81,8 @@
 #define USB2_ADPCTRL_IDPULLUP  BIT(5)  /* 1 = ID sampling is enabled */
 #define USB2_ADPCTRL_DRVVBUS   BIT(4)
 
+#define RCAR_GEN3_PHY_HAS_DEDICATED_PINS   1
+
 struct rcar_gen3_chan {
void __iomem *base;
struct extcon_dev *extcon;
@@ -87,7 +90,7 @@ struct rcar_gen3_chan {
struct regulator *vbus;
struct work_struct work;
bool extcon_host;
-   bool has_otg;
+   bool has_otg_pins;
 };
 
 static void rcar_gen3_phy_usb2_work(struct work_struct *work)
@@ -234,7 +237,7 @@ static ssize_t role_store(struct device *dev, struct 
device_attribute *attr,
bool is_b_device;
enum phy_mode cur_mode, new_mode;
 
-   if (!ch->has_otg || !ch->phy->init_count)
+   if (!ch->has_otg_pins || !ch->phy->init_count)
return -EIO;
 
if (!strncmp(buf, "host", strlen("host")))
@@ -272,7 +275,7 @@ static ssize_t role_show(struct device *dev, struct 
device_attribute *attr,
 {
struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
 
-   if (!ch->has_otg || !ch->phy->init_count)
+   if (!ch->has_otg_pins || !ch->phy->init_count)
return -EIO;
 
return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
@@ -311,7 +314,7 @@ static int rcar_gen3_phy_usb2_init(struct phy *p)
writel(USB2_OC_TIMSET_INIT, usb2_base + USB2_OC_TIMSET);
 
/* Initialize otg part */
-   if (channel->has_otg)
+   if (channel->has_otg_pins)
rcar_gen3_init_otg(channel);
 
return 0;
@@ -385,9 +388,17 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void 
*_ch)
 }
 
 static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
-   { .compatible = "renesas,usb2-phy-r8a7795" },
-   { .compatible = "renesas,usb2-phy-r8a7796" },
-   { .compatible = "renesas,rcar-gen3-usb2-phy" },
+   {
+   .compatible = "renesas,usb2-phy-r8a7795",
+   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
+   },
+   {
+   .compatible = "renesas,usb2-phy-r8a7796",
+   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
+   },
+   {
+   .compatible = "renesas,rcar-gen3-usb2-phy",
+   },
{ }
 };
 MODULE_DEVICE_TABLE(of, rcar_gen3_phy_usb2_match_table);
@@ -433,7 +444,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
if (of_usb_get_dr_mode_by_phy(dev->of_node, 0) == USB_DR_MODE_OTG) {
int ret;
 
-   channel->has_otg = true;
+   channel->has_otg_pins = 
(uintptr_t)of_device_get_match_data(dev);
channel->extcon = devm_extcon_dev_allocate(dev,
rcar_gen3_phy_cable);
if (IS_ERR(channel->extcon))
@@ -475,7 +486,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
dev_err(dev, "Failed to register PHY provider\n");
ret = PTR_ERR(provider);
goto error;
-   } else if (channel->has_otg) {
+   } else if (channel->has_otg_pins) {
int ret;
 
ret = device_create_file(dev, _attr_role);
@@ -495,7 +506,7 @@ static int rcar_gen3_phy_usb2_remove(struct platform_device 
*pdev)
 {
struct rcar_gen3_chan *channel = platform_get_drvdata(pdev);
 
-   if (channel->has_otg)
+   if (channel->has_otg_pins)
device_remove_file(>dev, _attr_role);
 
pm_runtime_disable(>dev);
-- 
1.9.1



[PATCH v5 0/4] phy: rcar-gen3-usb2: add support for r8a77995

2017-10-10 Thread Yoshihiro Shimoda
This patch set is based on the latest phy.git / next branch
(the commit id = 415060b21f318e009d865b4bcbf8f220ebc36964)

After this patch set is applied, a usb 2.0 host node that is combined
with usb 2.0 peripheral needs 'dr_mode = "otg";' property.

Changes from v4:
 - Remove the role_show() modification in patch 2.
 - Remove a new function rcar_gen3_otg_change_role() in patch 2 because adding
   this will be complecated patch code and this is unnecessary for now.
 - Add a new function rcar_gen3_get_phy_mode() to get current phy mode
   for comparing the new mode into a line in patch 2.
 - Rebase patch 3.

Changes from v3:
 - Use enum phy_mode in patch 2.
 - Remove "can_role_swap" parameter and revise the commit log in patch 2
   because a case of "can_role_swap = true" and "has_otg = false" is
   not supported for role swap at the moment.
 - Changes the name of "has_otg" to "has_otg_pins" in patch 3.
 - Use of_device_get_match_data() instead of of_match_device()
 - Add "Reviewed-by:" into patch No.1, 2 and 4. (Simon-san, Thanks!)
  - Since patch No.3 is changed in big at v4, I dropped his "Reviewed-by".

Changes from v2:
 - Revise the commit log ("SoCs" is not third-person singular present).

Changes from v1:
 - Revise typo "wronly" to "wrongly".
 - Remove RCAR_GEN3_PHY_HAS_DEDICATED_PINS from generic gen3 entry in
   patch 3/4
 - Remove the driver change from patch 4/4.
 - Revise the commit log of patch 4/4.

Yoshihiro Shimoda (4):
  phy: rcar-gen3-usb2: check dr_mode for otg mode
  phy: rcar-gen3-usb2: use enum phy_mode in the role_store()
  phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins
  phy: rcar-gen3-usb2: add binding for r8a77995

 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  2 +
 drivers/phy/renesas/phy-rcar-gen3-usb2.c   | 70 ++
 2 files changed, 48 insertions(+), 24 deletions(-)

-- 
1.9.1



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

2017-10-10 Thread Yoshihiro Shimoda
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 r8a77995.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index ace9cce..99b651b 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -8,6 +8,8 @@ Required properties:
  SoC.
  "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796
  SoC.
+ "renesas,usb2-phy-r8a77995" if the device is a part of an
+ R8A77995 SoC.
  "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible 
device.
 
  When compatible with the generic version, nodes must list the
-- 
1.9.1



[PATCH v5 1/4] phy: rcar-gen3-usb2: check dr_mode for otg mode

2017-10-10 Thread Yoshihiro Shimoda
The previous code assumed a channel has otg capability if a channel
has interrupt property. But, it is not good because:
 - Battery charging feature also needs interrupt property.
 - Some R-Car Gen3 SoCs (e.g. R-Car D3) don't have OTG capability.

So, this patch checks whether usb 2.0 host node has dr_mode property or
not. If it has 'dr_mode = "otg";', this driver enables otg capability.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 54c3429..e00e99a 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -1,7 +1,7 @@
 /*
  * Renesas R-Car Gen3 for USB2.0 PHY driver
  *
- * Copyright (C) 2015 Renesas Electronics Corporation
+ * Copyright (C) 2015-2017 Renesas Electronics Corporation
  *
  * This is based on the phy-rcar-gen2 driver:
  * Copyright (C) 2014 Renesas Solutions Corp.
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*** USB2.0 Host registers (original offset is +0x200) ***/
@@ -415,13 +416,16 @@ static int rcar_gen3_phy_usb2_probe(struct 
platform_device *pdev)
/* call request_irq for OTG */
irq = platform_get_irq(pdev, 0);
if (irq >= 0) {
-   int ret;
-
INIT_WORK(>work, rcar_gen3_phy_usb2_work);
irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
   IRQF_SHARED, dev_name(dev), channel);
if (irq < 0)
dev_err(dev, "No irq handler (%d)\n", irq);
+   }
+
+   if (of_usb_get_dr_mode_by_phy(dev->of_node, 0) == USB_DR_MODE_OTG) {
+   int ret;
+
channel->has_otg = true;
channel->extcon = devm_extcon_dev_allocate(dev,
rcar_gen3_phy_cable);
-- 
1.9.1



Re: [PATCH 0/3] iommu/ipmmu-vmsa: R-Car Gen3 IPMMU DT binding update

2017-10-10 Thread Joerg Roedel
On Fri, Sep 22, 2017 at 06:44:54AM +0900, Magnus Damm wrote:
> iommu/ipmmu-vmsa: R-Car Gen3 IPMMU DT binding update
> 
> [PATCH 1/3] iommu/ipmmu-vmsa: Document R-Car M3-W IPMMU DT bindings
> [PATCH 2/3] iommu/ipmmu-vmsa: Document R-Car V3M IPMMU DT bindings
> [PATCH 3/3] iommu/ipmmu-vmsa: Document R-Car D3 IPMMU DT bindings

I guess this goes upstream through the devicetree repository?


Joerg



Re: [PATCH] ARM: dts: r8a779x: add '#reset-cells' in cpg-mssr

2017-10-10 Thread Geert Uytterhoeven
Hi Arnd,

On Tue, Oct 10, 2017 at 11:07 AM, Arnd Bergmann  wrote:
> On Tue, Oct 10, 2017 at 10:45 AM, Arnd Bergmann  wrote:
>> With the latest dtc, we get many warnings about the missing
>> '#reset-cells' property in these controllers, e.g.:
>>
>> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (resets_property): Missing 
>> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
>> (referred from /can@e6e8:resets[0])
>> arch/arm/boot/dts/r8a7792-blanche.dtb: Warning (resets_property): Missing 
>> property '#reset-cells' in node /soc/clock-controller@e615 or bad 
>> phandle (referred from /soc/dma-controller@e670:resets[0])
>> arch/arm/boot/dts/r8a7792-wheat.dtb: Warning (resets_property): Missing 
>> property '#reset-cells' in node /soc/clock-controller@e615 or bad 
>> phandle (referred from /soc/ethernet@e680:resets[0])
>> arch/arm/boot/dts/r8a7793-gose.dtb: Warning (resets_property): Missing 
>> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
>> (referred from /gpio@e605:resets[0])
>> arch/arm/boot/dts/r8a7794-alt.dtb: Warning (resets_property): Missing 
>> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
>> (referred from /i2c@e650:resets[0])
>> arch/arm/boot/dts/r8a7794-silk.dtb: Warning (resets_property): Missing 
>> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
>> (referred from /interrupt-controller@e61c:resets[0])
>>
>> This adds it for the three r8a779x chips that were lacking it. The
>> binding mandates this as <1>, so this is the value I use.
>>
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  arch/arm/boot/dts/r8a7790.dtsi | 1 +
>>  arch/arm/boot/dts/r8a7792.dtsi | 1 +
>>  arch/arm/boot/dts/r8a7794.dtsi | 1 +
>
> It seems I missed the same problem in r8a7793. I'll do some more tests to
> see if there is more of the same, and will send an updated patch once
> I'm more confident I have the right version.

Thanks for catching this!

Seems I completely missed adding the #reset-cells for all but r8a7791.dtsi,
despite the commit message saying otherwise.

r8a7793.dtsi is the only extra missing one.

Fixes: 34fbd2b12761d111 ("ARM: dts: r8a7790: Add reset control properties")
Fixes: 6e11a322f1d7505d ("ARM: dts: r8a7792: Add reset control properties")
Fixes: 84fb19e1d201ba86 ("ARM: dts: r8a7793: Add reset control properties")
Fixes: 615beb759ca494a4 ("ARM: dts: r8a7794: Add reset control properties")

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] ARM: shmobile: rcar-gen2: fix non-SMP build

2017-10-10 Thread Sergei Shtylyov

Hello!

On 10/10/2017 11:12 AM, Simon Horman wrote:


From: Arnd Bergmann 

A bugfix for the SMP case broke the build for the UP case:

arch/arm/mach-shmobile/headsmp-apmu.o: In function `shmobile_boot_apmu':
(.text+0x34): undefined reference to `secondary_startup'

The assembler file mixes code that is used for SMP with code
that we also need on a single-CPU build, so I'm leaving it
always enabled in the Makefile, but enclose the SMP code
in an #ifdef.

3fd45a136ff6 ("ARM: shmobile: rcar-gen2: Make sure CNTVOFF is initialized on 
CA7/15")


   "Fixes:"?


Signed-off-by: Arnd Bergmann 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 

[...]

MBR, Sergei


Re: [PATCH] ARM: dts: r8a779x: add '#reset-cells' in cpg-mssr

2017-10-10 Thread Arnd Bergmann
On Tue, Oct 10, 2017 at 10:45 AM, Arnd Bergmann  wrote:
> With the latest dtc, we get many warnings about the missing
> '#reset-cells' property in these controllers, e.g.:
>
> arch/arm/boot/dts/r8a7790-lager.dtb: Warning (resets_property): Missing 
> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
> (referred from /can@e6e8:resets[0])
> arch/arm/boot/dts/r8a7792-blanche.dtb: Warning (resets_property): Missing 
> property '#reset-cells' in node /soc/clock-controller@e615 or bad phandle 
> (referred from /soc/dma-controller@e670:resets[0])
> arch/arm/boot/dts/r8a7792-wheat.dtb: Warning (resets_property): Missing 
> property '#reset-cells' in node /soc/clock-controller@e615 or bad phandle 
> (referred from /soc/ethernet@e680:resets[0])
> arch/arm/boot/dts/r8a7793-gose.dtb: Warning (resets_property): Missing 
> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
> (referred from /gpio@e605:resets[0])
> arch/arm/boot/dts/r8a7794-alt.dtb: Warning (resets_property): Missing 
> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
> (referred from /i2c@e650:resets[0])
> arch/arm/boot/dts/r8a7794-silk.dtb: Warning (resets_property): Missing 
> property '#reset-cells' in node /clock-controller@e615 or bad phandle 
> (referred from /interrupt-controller@e61c:resets[0])
>
> This adds it for the three r8a779x chips that were lacking it. The
> binding mandates this as <1>, so this is the value I use.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/arm/boot/dts/r8a7790.dtsi | 1 +
>  arch/arm/boot/dts/r8a7792.dtsi | 1 +
>  arch/arm/boot/dts/r8a7794.dtsi | 1 +

It seems I missed the same problem in r8a7793. I'll do some more tests to
see if there is more of the same, and will send an updated patch once
I'm more confident I have the right version.

   Arnd


[PATCH] ARM: dts: r8a779x: add '#reset-cells' in cpg-mssr

2017-10-10 Thread Arnd Bergmann
With the latest dtc, we get many warnings about the missing
'#reset-cells' property in these controllers, e.g.:

arch/arm/boot/dts/r8a7790-lager.dtb: Warning (resets_property): Missing 
property '#reset-cells' in node /clock-controller@e615 or bad phandle 
(referred from /can@e6e8:resets[0])
arch/arm/boot/dts/r8a7792-blanche.dtb: Warning (resets_property): Missing 
property '#reset-cells' in node /soc/clock-controller@e615 or bad phandle 
(referred from /soc/dma-controller@e670:resets[0])
arch/arm/boot/dts/r8a7792-wheat.dtb: Warning (resets_property): Missing 
property '#reset-cells' in node /soc/clock-controller@e615 or bad phandle 
(referred from /soc/ethernet@e680:resets[0])
arch/arm/boot/dts/r8a7793-gose.dtb: Warning (resets_property): Missing property 
'#reset-cells' in node /clock-controller@e615 or bad phandle (referred from 
/gpio@e605:resets[0])
arch/arm/boot/dts/r8a7794-alt.dtb: Warning (resets_property): Missing property 
'#reset-cells' in node /clock-controller@e615 or bad phandle (referred from 
/i2c@e650:resets[0])
arch/arm/boot/dts/r8a7794-silk.dtb: Warning (resets_property): Missing property 
'#reset-cells' in node /clock-controller@e615 or bad phandle (referred from 
/interrupt-controller@e61c:resets[0])

This adds it for the three r8a779x chips that were lacking it. The
binding mandates this as <1>, so this is the value I use.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/boot/dts/r8a7790.dtsi | 1 +
 arch/arm/boot/dts/r8a7792.dtsi | 1 +
 arch/arm/boot/dts/r8a7794.dtsi | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 17a48199b7a9..8215a971cf17 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1186,6 +1186,7 @@
clock-names = "extal", "usb_extal";
#clock-cells = <2>;
#power-domain-cells = <0>;
+   #reset-cells = <1>;
};
 
prr: chipid@ff44 {
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index 549eafe8ff12..cde709e3a916 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -828,6 +828,7 @@
clock-names = "extal";
#clock-cells = <2>;
#power-domain-cells = <0>;
+   #reset-cells = <1>;
};
};
 
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 19cff0dd90cf..a406d56234ba 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1098,6 +1098,7 @@
clock-names = "extal", "usb_extal";
#clock-cells = <2>;
#power-domain-cells = <0>;
+   #reset-cells = <1>;
};
 
rst: reset-controller@e616 {
-- 
2.9.0



RE: [PATCH 2/4] ARM: dts: iwg20d-q7: Enable HS-USB

2017-10-10 Thread Biju Das


> -Original Message-
> From: Simon Horman [mailto:ho...@verge.net.au]
> Sent: 10 October 2017 08:31
> To: Sergei Shtylyov 
> Cc: Biju Das ; Rob Herring ;
> Mark Rutland ; Yoshihiro Shimoda
> ; Magnus Damm
> ; Chris Paterson ;
> Fabrizio Castro ;
> devicet...@vger.kernel.org; linux-renesas-soc@vger.kernel.org
> Subject: Re: [PATCH 2/4] ARM: dts: iwg20d-q7: Enable HS-USB
>
> On Mon, Oct 09, 2017 at 07:18:24PM +0300, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 10/09/2017 04:21 PM, Biju Das wrote:
> >
> > >Enable HS-USB device for the iWave G20D-Q7 carrier board based on
> > >RZ/G1M.
> > >Also disable the host mode support on usb otg port by default to
> > >avoid pin conflicts.
> > >
> > >Signed-off-by: Biju Das 
> > >Signed-off-by: Chris Paterson 
> > >---
> > >  arch/arm/boot/dts/iwg20d-q7-common.dtsi | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > >diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > >b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > >index 1c072c0..e6b50c6 100644
> > >--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > >+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> > [...]
> > >@@ -72,7 +78,7 @@
> > >  };
> > >   {
> > >-status = "okay";
> > >+status = "disabled";
> >
> >I think you may just omit this prop -- you most prolly have it
> > "disabloed" in the R8A7743's DT.
>
> Yes, I expect so too.

Thanks for the comments. I will send v2 with dropping "status" property .

> > >  pinctrl-0 = <_pins>;
> > >  pinctrl-names = "default";
> > >  };
> >



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.


[GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.15

2017-10-10 Thread Simon Horman
Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM based SoC updates for v4.15.

This pull request is based on the previous round of
such requests, tagged as renesas-soc-for-v4.15,
which I have already sent a pull-request for.

This pull request fixes a bug introduced in renesas-soc-for-v4.15.


The following changes since commit 3fd45a136ff61bb54deab70fb2d534a85e40481f:

  ARM: shmobile: rcar-gen2: Make sure CNTVOFF is initialized on CA7/15 
(2017-09-18 08:10:44 +0200)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git 
tags/renesas-soc2-for-v4.15

for you to fetch changes up to dc15ca962757ca72a4492b2e13be2eecc6dcd716:

  ARM: shmobile: rcar-gen2: fix non-SMP build (2017-10-06 11:35:34 +0200)


Second Round of Renesas ARM Based SoC Updates for v4.15

Fix to allow UP build of shmobile.

Arnd Bergmann says:

  A bugfix for the SMP case broke the build for the UP case:

  arch/arm/mach-shmobile/headsmp-apmu.o: In function `shmobile_boot_apmu':
  (.text+0x34): undefined reference to `secondary_startup'

  The assembler file mixes code that is used for SMP with code
  that we also need on a single-CPU build, so I'm leaving it
  always enabled in the Makefile, but enclose the SMP code
  in an #ifdef.


Arnd Bergmann (1):
  ARM: shmobile: rcar-gen2: fix non-SMP build

 arch/arm/mach-shmobile/headsmp-apmu.S | 2 ++
 1 file changed, 2 insertions(+)


[PATCH] ARM: shmobile: rcar-gen2: fix non-SMP build

2017-10-10 Thread Simon Horman
From: Arnd Bergmann 

A bugfix for the SMP case broke the build for the UP case:

arch/arm/mach-shmobile/headsmp-apmu.o: In function `shmobile_boot_apmu':
(.text+0x34): undefined reference to `secondary_startup'

The assembler file mixes code that is used for SMP with code
that we also need on a single-CPU build, so I'm leaving it
always enabled in the Makefile, but enclose the SMP code
in an #ifdef.

3fd45a136ff6 ("ARM: shmobile: rcar-gen2: Make sure CNTVOFF is initialized on 
CA7/15")
Signed-off-by: Arnd Bergmann 
Acked-by: Geert Uytterhoeven 
Signed-off-by: Simon Horman 
---
 arch/arm/mach-shmobile/headsmp-apmu.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/headsmp-apmu.S 
b/arch/arm/mach-shmobile/headsmp-apmu.S
index db4743d2bf91..5672b5849401 100644
--- a/arch/arm/mach-shmobile/headsmp-apmu.S
+++ b/arch/arm/mach-shmobile/headsmp-apmu.S
@@ -31,7 +31,9 @@ ENTRY(shmobile_init_cntvoff)
ret lr
 ENDPROC(shmobile_init_cntvoff)
 
+#ifdef CONFIG_SMP
 ENTRY(shmobile_boot_apmu)
bl  shmobile_init_cntvoff
b   secondary_startup
 ENDPROC(shmobile_boot_apmu)
+#endif
-- 
2.1.4



Re: [PATCH v2 8/8] arm64: dts: renesas: eagle: add EtherAVB support

2017-10-10 Thread Simon Horman
On Tue, Oct 10, 2017 at 09:48:42AM +0200, Simon Horman wrote:
> On Tue, Oct 10, 2017 at 09:33:46AM +0200, Simon Horman wrote:
> > On Mon, Oct 09, 2017 at 08:57:42PM +0300, Sergei Shtylyov wrote:
> > > On 10/05/2017 12:05 PM, Simon Horman wrote:
> > > 
> > > >>>On 9/21/2017 4:08 PM, Geert Uytterhoeven wrote:
> > > >>>>>Define the Eagle board  dependent part of the EtherAVB device node.
> > > >>>>>Enable DHCP  and NFS root for the kernel booting.
> > > >>>>>
> > > >>>>>Based  on the original (and large) patch by Vladimir Barinov.
> > > >>>>>
> > > >>>>>Signed-off-by: Vladimir Barinov <vladimir.bari...@cogentembedded.com>
> > > >>>>>Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> > > >>>>
> > > >>>>
> > > >>>>>--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > > >>>>>+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > > >>>
> > > >>>[...]
> > > >>>>>
> > > >>>>>@@ -43,3 +44,14 @@
> > > >>>>>{
> > > >>>>>  status = "okay";
> > > >>>>>   };
> > > >>>>>+
> > > >>>>>+ {
> > > >>>>>+   renesas,no-ether-link;
> > > >>>>>+   phy-handle = <>;
> > > >>>>>+   status = "okay";
> > > >>>>>+
> > > >>>>>+   phy0: ethernet-phy@0 {
> > > >>>>>+   rxc-skew-ps = <1500>;
> > > >>>>>+   reg = <0>;
> > > >>>>
> > > >>>>
> > > >>>>Any specific reason why you don't want to wire up the interrupt?
> > > >>>>
> > > >>>>  interrupt-parent = <>;
> > > >>>
> > > >>>
> > > >>>I thought it's quite obvious -- we don't have GPIOs yet, and GPIOs 
> > > >>> seem
> > > >>>to require PFC.
> > > >>
> > > >>Of course. And these can be added later.
> > > >>
> > > >>Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
> > > >
> > > >Thanks, applied.
> > > 
> > >Unfortunately, you applied an outdated version of this patch. :-(
> > 
> > Sorry, I think patchwork has been playing up of late - or my use of it!
> > 
> > Could you repost the correct patch so I am sure to get the right one
> > the second time around?
> 
> Please ignore that request. I'll go ahead and apply v2.

Done, please check renesas-next-20171010-v4.14-rc1


RE: [PATCH v4 2/4] phy: rcar-gen3-usb2: cleanup the role_{store,show}()

2017-10-10 Thread Yoshihiro Shimoda
Hi Simon-san,

Thank you for the comments!

> From: Simon Horman, Sent: Tuesday, October 10, 2017 4:46 PM
> 
> On Tue, Oct 10, 2017 at 02:58:28PM +0900, Yoshihiro Shimoda wrote:
> > This patch cleanups the role_{store,show}() and replaces the local
> > "bool" for host/device mode selection with the "enum phy_mode" in
> > the role_store().
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 58 
> > ++--
> >  1 file changed, 40 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
> > b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > index e00e99a..7619468 100644
> > --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > @@ -219,14 +219,10 @@ static bool rcar_gen3_is_host(struct rcar_gen3_chan 
> > *ch)
> > return !(readl(ch->base + USB2_COMMCTRL) & USB2_COMMCTRL_OTG_PERI);
> >  }
> >
> > -static ssize_t role_store(struct device *dev, struct device_attribute 
> > *attr,
> > - const char *buf, size_t count)
> > +static ssize_t rcar_gen3_otg_change_role(struct rcar_gen3_chan *ch,
> > +enum phy_mode mode)
> >  {
> > -   struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> > -   bool is_b_device, is_host, new_mode_is_host;
> > -
> > -   if (!ch->has_otg || !ch->phy->init_count)
> > -   return -EIO;
> > +   bool is_b_device, is_host;
> >
> > /*
> >  * is_b_device: true is B-Device. false is A-Device.
> > @@ -234,18 +230,13 @@ static ssize_t role_store(struct device *dev, struct 
> > device_attribute *attr,
> >  */
> > is_b_device = rcar_gen3_check_id(ch);
> > is_host = rcar_gen3_is_host(ch);
> > -   if (!strncmp(buf, "host", strlen("host")))
> > -   new_mode_is_host = true;
> > -   else if (!strncmp(buf, "peripheral", strlen("peripheral")))
> > -   new_mode_is_host = false;
> > -   else
> > -   return -EINVAL;
> >
> > /* If current and new mode is the same, this returns the error */
> > -   if (is_host == new_mode_is_host)
> > +   if ((is_host && mode == PHY_MODE_USB_HOST) ||
> > +   (!is_host && mode == PHY_MODE_USB_DEVICE))
> 
> Maybe it is not worth the effort, but it seems that if
> rcar_gen3_is_host returned enum phy_mode then the above
> could be changed into a single comparison.

It's a nice idea! Since role_show() below should not be changed,
I will add rcar_gen3_is_phy_mode_host() and changed the above code
into a single comparison.

> > return -EINVAL;
> >
> > -   if (new_mode_is_host) { /* And is_host must be false */
> > +   if (mode == PHY_MODE_USB_HOST) { /* And is_host must be false */
> > if (!is_b_device)   /* A-Peripheral */
> > rcar_gen3_init_from_a_peri_to_a_host(ch);
> > else/* B-Peripheral */
> > @@ -257,6 +248,32 @@ static ssize_t role_store(struct device *dev, struct 
> > device_attribute *attr,
> > rcar_gen3_init_for_peri(ch);
> > }
> >
> > +   return 0;
> > +}
> > +
> > +static ssize_t role_store(struct device *dev, struct device_attribute 
> > *attr,
> > + const char *buf, size_t count)
> > +{
> > +   struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> > +   enum phy_mode mode;
> > +   ssize_t ret = -EIO;
> > +
> > +   if (!ch->phy->init_count)
> > +   return -EIO;
> > +
> > +   if (!strncmp(buf, "host", strlen("host")))
> > +   mode = PHY_MODE_USB_HOST;
> > +   else if (!strncmp(buf, "peripheral", strlen("peripheral")))
> > +   mode = PHY_MODE_USB_DEVICE;
> > +   else
> > +   return -EINVAL;
> > +
> > +   if (ch->has_otg)
> > +   ret = rcar_gen3_otg_change_role(ch, mode);
> > +
> > +   if (ret < 0)
> > +   return ret;
> > +
> > return count;
> >  }
> >
> > @@ -264,12 +281,17 @@ static ssize_t role_show(struct device *dev, struct 
> > device_attribute *attr,
> >  char *buf)
> >  {
> > struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> > +   bool is_host;
> >
> > -   if (!ch->has_otg || !ch->phy->init_count)
> > +   if (!ch->phy->init_count)
> > +   return -EIO;
> > +
> > +   if (ch->has_otg)
> > +   is_host = rcar_gen3_is_host(ch);
> > +   else
> > return -EIO;
> >
> > -   return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
> > -   "peripheral");
> > +   return sprintf(buf, "%s\n", is_host ? "host" : "peripheral");
> >  }
> 
> I'm not sure why the above hunk is necessary.
> They function seems logically the same before and after.

Indeed. So, I will keep rcar_gen3_is_host() as bool and
remove the role_show() modification.

Best regards,
Yoshihiro Shimoda

> >  static DEVICE_ATTR_RW(role);
> >
> > --
> > 1.9.1
> >


[PATCH 2/2 v2] pinctrl: sh-pfc: r8a77995: add Audio SSI pin support

2017-10-10 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Signed-off-by: Kuninori Morimoto 
---
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
index 2d93c4e..f8fa2c8 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
@@ -1325,6 +1325,50 @@ enum {
SCIF_CLK_MARK,
 };
 
+/* - SSI ---*/
+static const unsigned int ssi3_data_pins[] = {
+   /* SDATA3 */
+   RCAR_GP_PIN(4, 3),
+};
+static const unsigned int ssi3_data_mux[] = {
+   SSI_SDATA3_MARK,
+};
+static const unsigned int ssi34_ctrl_pins[] = {
+   /* SCK34,  WS34 */
+   RCAR_GP_PIN(4, 2), RCAR_GP_PIN(4, 4),
+};
+static const unsigned int ssi34_ctrl_mux[] = {
+   SSI_SCK34_MARK, SSI_WS34_MARK,
+};
+static const unsigned int ssi4_ctrl_a_pins[] = {
+   /* SCK4_A, WS4_A */
+   RCAR_GP_PIN(4, 5), RCAR_GP_PIN(4, 7),
+};
+static const unsigned int ssi4_ctrl_a_mux[] = {
+   SSI_SCK4_A_MARK, SSI_WS4_A_MARK,
+};
+static const unsigned int ssi4_data_a_pins[] = {
+   /* SDATA4_A */
+   RCAR_GP_PIN(4, 6),
+};
+static const unsigned int ssi4_data_a_mux[] = {
+   SSI_SDATA4_A_MARK,
+};
+static const unsigned int ssi4_ctrl_b_pins[] = {
+   /* SCK4_B, WS4_B */
+   RCAR_GP_PIN(2, 15), RCAR_GP_PIN(2, 20),
+};
+static const unsigned int ssi4_ctrl_b_mux[] = {
+   SSI_SCK4_B_MARK, SSI_WS4_B_MARK,
+};
+static const unsigned int ssi4_data_b_pins[] = {
+   /* SDATA4_B */
+   RCAR_GP_PIN(2, 16),
+};
+static const unsigned int ssi4_data_b_mux[] = {
+   SSI_SDATA4_B_MARK,
+};
+
 /* - USB0 --- 
*/
 static const unsigned int usb0_pins[] = {
/* PWEN, OVC */
@@ -1385,6 +1429,12 @@ enum {
SH_PFC_PIN_GROUP(scif5_data_b),
SH_PFC_PIN_GROUP(scif5_clk_b),
SH_PFC_PIN_GROUP(scif_clk),
+   SH_PFC_PIN_GROUP(ssi3_data),
+   SH_PFC_PIN_GROUP(ssi34_ctrl),
+   SH_PFC_PIN_GROUP(ssi4_ctrl_a),
+   SH_PFC_PIN_GROUP(ssi4_data_a),
+   SH_PFC_PIN_GROUP(ssi4_ctrl_b),
+   SH_PFC_PIN_GROUP(ssi4_data_b),
SH_PFC_PIN_GROUP(usb0),
 };
 
@@ -1479,6 +1529,15 @@ enum {
"scif_clk",
 };
 
+static const char * const ssi_groups[] = {
+   "ssi3_data",
+   "ssi34_ctrl",
+   "ssi4_ctrl_a",
+   "ssi4_data_a",
+   "ssi4_ctrl_b",
+   "ssi4_data_b",
+};
+
 static const char * const usb0_groups[] = {
"usb0",
 };
@@ -1498,6 +1557,7 @@ enum {
SH_PFC_FUNCTION(scif4),
SH_PFC_FUNCTION(scif5),
SH_PFC_FUNCTION(scif_clk),
+   SH_PFC_FUNCTION(ssi),
SH_PFC_FUNCTION(usb0),
 };
 
-- 
1.9.1



[PATCH 1/2 v2] pinctrl: sh-pfc: r8a77995: add Audio clock pin support

2017-10-10 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Signed-off-by: Kuninori Morimoto 
---
 drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
index 442ff0f..2d93c4e 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77995.c
@@ -936,6 +936,36 @@ enum {
PINMUX_GPIO_GP_ALL(),
 };
 
+/* - AUDIO CLOCK - 
*/
+static const unsigned int audio_clk_a_pins[] = {
+   /* CLK A */
+   RCAR_GP_PIN(4, 1),
+};
+static const unsigned int audio_clk_a_mux[] = {
+   AUDIO_CLKA_MARK,
+};
+static const unsigned int audio_clk_b_pins[] = {
+   /* CLK B */
+   RCAR_GP_PIN(2, 27),
+};
+static const unsigned int audio_clk_b_mux[] = {
+   AUDIO_CLKB_MARK,
+};
+static const unsigned int audio_clkout_pins[] = {
+   /* CLKOUT */
+   RCAR_GP_PIN(4, 5),
+};
+static const unsigned int audio_clkout_mux[] = {
+   AUDIO_CLKOUT_MARK,
+};
+static const unsigned int audio_clkout1_pins[] = {
+   /* CLKOUT1 */
+   RCAR_GP_PIN(4, 22),
+};
+static const unsigned int audio_clkout1_mux[] = {
+   AUDIO_CLKOUT1_MARK,
+};
+
 /* - EtherAVB --- 
*/
 static const unsigned int avb0_link_pins[] = {
/* AVB0_LINK */
@@ -1305,6 +1335,10 @@ enum {
 };
 
 static const struct sh_pfc_pin_group pinmux_groups[] = {
+   SH_PFC_PIN_GROUP(audio_clk_a),
+   SH_PFC_PIN_GROUP(audio_clk_b),
+   SH_PFC_PIN_GROUP(audio_clkout),
+   SH_PFC_PIN_GROUP(audio_clkout1),
SH_PFC_PIN_GROUP(avb0_link),
SH_PFC_PIN_GROUP(avb0_magic),
SH_PFC_PIN_GROUP(avb0_phy_int),
@@ -1354,6 +1388,13 @@ enum {
SH_PFC_PIN_GROUP(usb0),
 };
 
+static const char * const audio_clk_groups[] = {
+   "audio_clk_a",
+   "audio_clk_b",
+   "audio_clkout",
+   "audio_clkout1",
+};
+
 static const char * const avb0_groups[] = {
"avb0_link",
"avb0_magic",
@@ -1443,6 +1484,7 @@ enum {
 };
 
 static const struct sh_pfc_function pinmux_functions[] = {
+   SH_PFC_FUNCTION(audio_clk),
SH_PFC_FUNCTION(avb0),
SH_PFC_FUNCTION(i2c0),
SH_PFC_FUNCTION(i2c1),
-- 
1.9.1



[PATCH 0/2 v2] pinctrl: sh-pfc: r8a77995: add Audio pin support

2017-10-10 Thread Kuninori Morimoto

Hi Geert, Simon

These are v2 of r8a77995 Audio pin support.
main fix is "clka" -> "clk_a"

Kuninori Morimoto (2):
  pinctrl: sh-pfc: r8a77995: add Audio clock pin support
  pinctrl: sh-pfc: r8a77995: add Audio SSI pin support

 drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 102 ++
 1 file changed, 102 insertions(+)

-- 
1.9.1



Best regards
---
Kuninori Morimoto


Re: [PATCH v2 8/8] arm64: dts: renesas: eagle: add EtherAVB support

2017-10-10 Thread Simon Horman
On Tue, Oct 10, 2017 at 09:33:46AM +0200, Simon Horman wrote:
> On Mon, Oct 09, 2017 at 08:57:42PM +0300, Sergei Shtylyov wrote:
> > On 10/05/2017 12:05 PM, Simon Horman wrote:
> > 
> > >>>On 9/21/2017 4:08 PM, Geert Uytterhoeven wrote:
> > >Define the Eagle board  dependent part of the EtherAVB device node.
> > >Enable DHCP  and NFS root for the kernel booting.
> > >
> > >Based  on the original (and large) patch by Vladimir Barinov.
> > >
> > >Signed-off-by: Vladimir Barinov 
> > >Signed-off-by: Sergei Shtylyov 
> > 
> > 
> > >--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > >+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > >>>
> > >>>[...]
> > >
> > >@@ -43,3 +44,14 @@
> > >{
> > >  status = "okay";
> > >   };
> > >+
> > >+ {
> > >+   renesas,no-ether-link;
> > >+   phy-handle = <>;
> > >+   status = "okay";
> > >+
> > >+   phy0: ethernet-phy@0 {
> > >+   rxc-skew-ps = <1500>;
> > >+   reg = <0>;
> > 
> > 
> > Any specific reason why you don't want to wire up the interrupt?
> > 
> >   interrupt-parent = <>;
> > >>>
> > >>>
> > >>>I thought it's quite obvious -- we don't have GPIOs yet, and GPIOs 
> > >>> seem
> > >>>to require PFC.
> > >>
> > >>Of course. And these can be added later.
> > >>
> > >>Reviewed-by: Geert Uytterhoeven 
> > >
> > >Thanks, applied.
> > 
> >Unfortunately, you applied an outdated version of this patch. :-(
> 
> Sorry, I think patchwork has been playing up of late - or my use of it!
> 
> Could you repost the correct patch so I am sure to get the right one
> the second time around?

Please ignore that request. I'll go ahead and apply v2.


Re: [PATCH v4 2/4] phy: rcar-gen3-usb2: cleanup the role_{store,show}()

2017-10-10 Thread Simon Horman
On Tue, Oct 10, 2017 at 02:58:28PM +0900, Yoshihiro Shimoda wrote:
> This patch cleanups the role_{store,show}() and replaces the local
> "bool" for host/device mode selection with the "enum phy_mode" in
> the role_store().
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 58 
> ++--
>  1 file changed, 40 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
> b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> index e00e99a..7619468 100644
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -219,14 +219,10 @@ static bool rcar_gen3_is_host(struct rcar_gen3_chan *ch)
>   return !(readl(ch->base + USB2_COMMCTRL) & USB2_COMMCTRL_OTG_PERI);
>  }
>  
> -static ssize_t role_store(struct device *dev, struct device_attribute *attr,
> -   const char *buf, size_t count)
> +static ssize_t rcar_gen3_otg_change_role(struct rcar_gen3_chan *ch,
> +  enum phy_mode mode)
>  {
> - struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> - bool is_b_device, is_host, new_mode_is_host;
> -
> - if (!ch->has_otg || !ch->phy->init_count)
> - return -EIO;
> + bool is_b_device, is_host;
>  
>   /*
>* is_b_device: true is B-Device. false is A-Device.
> @@ -234,18 +230,13 @@ static ssize_t role_store(struct device *dev, struct 
> device_attribute *attr,
>*/
>   is_b_device = rcar_gen3_check_id(ch);
>   is_host = rcar_gen3_is_host(ch);
> - if (!strncmp(buf, "host", strlen("host")))
> - new_mode_is_host = true;
> - else if (!strncmp(buf, "peripheral", strlen("peripheral")))
> - new_mode_is_host = false;
> - else
> - return -EINVAL;
>  
>   /* If current and new mode is the same, this returns the error */
> - if (is_host == new_mode_is_host)
> + if ((is_host && mode == PHY_MODE_USB_HOST) ||
> + (!is_host && mode == PHY_MODE_USB_DEVICE))

Maybe it is not worth the effort, but it seems that if
rcar_gen3_is_host returned enum phy_mode then the above
could be changed into a single comparison.

>   return -EINVAL;
>  
> - if (new_mode_is_host) { /* And is_host must be false */
> + if (mode == PHY_MODE_USB_HOST) { /* And is_host must be false */
>   if (!is_b_device)   /* A-Peripheral */
>   rcar_gen3_init_from_a_peri_to_a_host(ch);
>   else/* B-Peripheral */
> @@ -257,6 +248,32 @@ static ssize_t role_store(struct device *dev, struct 
> device_attribute *attr,
>   rcar_gen3_init_for_peri(ch);
>   }
>  
> + return 0;
> +}
> +
> +static ssize_t role_store(struct device *dev, struct device_attribute *attr,
> +   const char *buf, size_t count)
> +{
> + struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> + enum phy_mode mode;
> + ssize_t ret = -EIO;
> +
> + if (!ch->phy->init_count)
> + return -EIO;
> +
> + if (!strncmp(buf, "host", strlen("host")))
> + mode = PHY_MODE_USB_HOST;
> + else if (!strncmp(buf, "peripheral", strlen("peripheral")))
> + mode = PHY_MODE_USB_DEVICE;
> + else
> + return -EINVAL;
> +
> + if (ch->has_otg)
> + ret = rcar_gen3_otg_change_role(ch, mode);
> +
> + if (ret < 0)
> + return ret;
> +
>   return count;
>  }
>  
> @@ -264,12 +281,17 @@ static ssize_t role_show(struct device *dev, struct 
> device_attribute *attr,
>char *buf)
>  {
>   struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> + bool is_host;
>  
> - if (!ch->has_otg || !ch->phy->init_count)
> + if (!ch->phy->init_count)
> + return -EIO;
> +
> + if (ch->has_otg)
> + is_host = rcar_gen3_is_host(ch);
> + else
>   return -EIO;
>  
> - return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
> - "peripheral");
> + return sprintf(buf, "%s\n", is_host ? "host" : "peripheral");
>  }

I'm not sure why the above hunk is necessary.
They function seems logically the same before and after.

>  static DEVICE_ATTR_RW(role);
>  
> -- 
> 1.9.1
> 


Re: [RFC PATCH] mmc: tmio: check mmc_regulator_get_supply return value

2017-10-10 Thread Ulf Hansson
On 22 September 2017 at 13:22, Fabrizio Castro
 wrote:
> mmc_regulator_get_supply returns -EPROBE_DEFER if either vmmc or
> vqmmc regulators had their probing deferred.
> vqmmc regulator is needed by UHS to work properly, therefore this
> patch checks the value returned by mmc_regulator_get_supply to
> make sure we have a reference to both vmmc and vqmmc (if found in
> the DT).
>
> Signed-off-by: Fabrizio Castro 

Thanks, applied for next!

Kind regards
Uffe

> ---
>
> I believe this patch is in order for UHS to work properly on the RZ/G1 
> platforms
> as the signal voltage needs to be switched from 3.3V to 1.8V, and therefore we
> need to make sure we hold a reference to vqmmc. Without this patch there is a
> chance that the regulator driver gets probed later on and therefore we end up
> without control over the power regulator. I have seen an RZ/G1E based platform
> failing the transition to UHS because of this.
> However, there are side effects to it as the mmc devices will be enumerated
> in a different order (due to -EPROBE_DEFER), this means this patch would 
> likely
> break existing platforms.
> Please, let me know your comments.
>
>  drivers/mmc/host/tmio_mmc_core.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_core.c 
> b/drivers/mmc/host/tmio_mmc_core.c
> index 88a9435..3df0413 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -1153,8 +1153,11 @@ static int tmio_mmc_init_ocr(struct tmio_mmc_host 
> *host)
>  {
> struct tmio_mmc_data *pdata = host->pdata;
> struct mmc_host *mmc = host->mmc;
> +   int err;
>
> -   mmc_regulator_get_supply(mmc);
> +   err = mmc_regulator_get_supply(mmc);
> +   if (err)
> +   return err;
>
> /* use ocr_mask if no regulator */
> if (!mmc->ocr_avail)
> --
> 2.7.4
>


Re: [RFC][PATCH 3/4] pinctrl: sh-pfc: r8a77995: add Audio clock pin support

2017-10-10 Thread Kuninori Morimoto

Hi Geert

> >> I think it's best to follow what's done in the other R-Car Gen3 SoCs.
> >> Else we may end up in trouble if a board shows up that can support both
> >> R-Car D3 and another R-Car Gen3 SoC (cfr. Salvator-X(S) and ULCB
> >> with R-Car H3 and M3-W).
> >
> > Yeah agree.
> > But unfortunately, both "clka" / "clk_a" are already used, right ?
> > I think we want to have "clk_a" ?
> 
> Yes. "clk_a" is what used on all R-Car SoCs, except for R-Car E2.

OK, will post v2

Best regards
---
Kuninori Morimoto


Re: [PATCH v2 8/8] arm64: dts: renesas: eagle: add EtherAVB support

2017-10-10 Thread Simon Horman
On Mon, Oct 09, 2017 at 08:57:42PM +0300, Sergei Shtylyov wrote:
> On 10/05/2017 12:05 PM, Simon Horman wrote:
> 
> >>>On 9/21/2017 4:08 PM, Geert Uytterhoeven wrote:
> >Define the Eagle board  dependent part of the EtherAVB device node.
> >Enable DHCP  and NFS root for the kernel booting.
> >
> >Based  on the original (and large) patch by Vladimir Barinov.
> >
> >Signed-off-by: Vladimir Barinov 
> >Signed-off-by: Sergei Shtylyov 
> 
> 
> >--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> >+++ renesas/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> >>>
> >>>[...]
> >
> >@@ -43,3 +44,14 @@
> >{
> >  status = "okay";
> >   };
> >+
> >+ {
> >+   renesas,no-ether-link;
> >+   phy-handle = <>;
> >+   status = "okay";
> >+
> >+   phy0: ethernet-phy@0 {
> >+   rxc-skew-ps = <1500>;
> >+   reg = <0>;
> 
> 
> Any specific reason why you don't want to wire up the interrupt?
> 
>   interrupt-parent = <>;
> >>>
> >>>
> >>>I thought it's quite obvious -- we don't have GPIOs yet, and GPIOs seem
> >>>to require PFC.
> >>
> >>Of course. And these can be added later.
> >>
> >>Reviewed-by: Geert Uytterhoeven 
> >
> >Thanks, applied.
> 
>Unfortunately, you applied an outdated version of this patch. :-(

Sorry, I think patchwork has been playing up of late - or my use of it!

Could you repost the correct patch so I am sure to get the right one
the second time around?


Re: [RFC PATCH] mmc: sunxi: drop superfluous error message

2017-10-10 Thread Ulf Hansson
On 8 October 2017 at 16:50, Wolfram Sang
 wrote:
> This error message can go because a) currently nothing else than
> EPROBE_DEFER is returned and b) if this is going to change a much more
> detailed error message should come from mmc_regulator_get_supply()
> anyhow.
>
> Signed-off-by: Wolfram Sang 

Thanks, applied for next!

Kind regards
Uffe

> ---
>
> While I think this patch is correct as is (because of this discussion [1]), I
> still wonder about the intention of the now removed message. Because a not
> supplied vmmc is not determined by the return value of *_get_supply(), but by 
> a
> check if mmc->supply.vmmc is populated afterwards. So, if this was the 
> original
> intention such a check would need to be implemented on top of this patch.
>
> [1] https://patchwork.kernel.org/patch/9965823/
>
>  drivers/mmc/host/sunxi-mmc.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 53c970fe087397..cc98355dbdb9cc 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1175,11 +1175,8 @@ static int sunxi_mmc_resource_request(struct 
> sunxi_mmc_host *host,
> return -EINVAL;
>
> ret = mmc_regulator_get_supply(host->mmc);
> -   if (ret) {
> -   if (ret != -EPROBE_DEFER)
> -   dev_err(>dev, "Could not get vmmc supply\n");
> +   if (ret)
> return ret;
> -   }
>
> host->reg_base = devm_ioremap_resource(>dev,
>   platform_get_resource(pdev, IORESOURCE_MEM, 0));
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/4] ARM: dts: iwg20d-q7: Enable HS-USB

2017-10-10 Thread Simon Horman
On Mon, Oct 09, 2017 at 07:18:24PM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 10/09/2017 04:21 PM, Biju Das wrote:
> 
> >Enable HS-USB device for the iWave G20D-Q7 carrier board based on
> >RZ/G1M.
> >Also disable the host mode support on usb otg port by default to avoid
> >pin conflicts.
> >
> >Signed-off-by: Biju Das 
> >Signed-off-by: Chris Paterson 
> >---
> >  arch/arm/boot/dts/iwg20d-q7-common.dtsi | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> >diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi 
> >b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> >index 1c072c0..e6b50c6 100644
> >--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> >+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
> [...]
> >@@ -72,7 +78,7 @@
> >  };
> >   {
> >-status = "okay";
> >+status = "disabled";
> 
>I think you may just omit this prop -- you most prolly have it
> "disabloed" in the R8A7743's DT.

Yes, I expect so too.

> > pinctrl-0 = <_pins>;
> > pinctrl-names = "default";
> >  };
> 
> MBR, Sergei
> 


Re: [PATCH v2 2/2] arm64: dts: r8a7796: Add OPPs table for cpu devices

2017-10-10 Thread Simon Horman
On Mon, Oct 09, 2017 at 01:56:17PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Oct 5, 2017 at 3:26 PM, Simon Horman  
> wrote:
> > From: Dien Pham 
> >
> > Current, OPP tables are defined temporary,
> > they are being evaluated and adjust in future.
> >
> > Based in part on work by Hien Dang.
> 
> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> 
> > @@ -108,6 +116,56 @@
> > };
> > };
> >
> > +   cluster0_opp: opp_table0 {
> > +   compatible = "operating-points-v2";
> > +   opp-shared;
> > +
> > +   opp@5 {
> 
> As reported before, with "make dtbs W=1":
> 
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dtb: Warning
> (unit_address_vs_reg): Node /opp_table0/opp@5 has a unit name,
> but no reg property
> 
> etc.
> 
> opp-5

Thanks, will fix.


Re: [PATCH v2 2/2] arm64: dts: r8a7796: Add OPPs table for cpu devices

2017-10-10 Thread Simon Horman
On Thu, Oct 05, 2017 at 04:04:47PM +0100, Sudeep Holla wrote:
> 
> 
> On 05/10/17 14:26, Simon Horman wrote:
> > From: Dien Pham 
> > 
> > Current, OPP tables are defined temporary,
> > they are being evaluated and adjust in future.
> > 
> 
> I assume these OPPs will continue to work in future but just not optimal.

Yes, that is my understanding.

> > Based in part on work by Hien Dang.
> > 
> > Signed-off-by: Dien Pham 
> > Signed-off-by: Takeshi Kihara 
> > Signed-off-by: Simon Horman 
> > ---
> > v2 [Simon Horman]
> > - Only provide one operating points node for each operating-points-v2 node
> >   as per the binding; other nodes were unused and have been removed
> > 
> > v1 [Simon Horman]
> > - consolidated several patches into one
> > 
> > v0 [Dien Pham]
> > ---
> >  arch/arm64/boot/dts/renesas/r8a7796.dtsi | 58 
> > 
> >  1 file changed, 58 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
> > b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > index 57ac5ca6ed98..2d9edc61437c 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > @@ -46,6 +46,8 @@
> > power-domains = < R8A7796_PD_CA57_CPU0>;
> > next-level-cache = <_CA57>;
> > enable-method = "psci";
> > +   clocks =< CPG_CORE R8A7796_CLK_Z>;
> > +   operating-points-v2 = <_opp>;
> > };
> >  
> > a57_1: cpu@1 {
> > @@ -55,6 +57,7 @@
> > power-domains = < R8A7796_PD_CA57_CPU1>;
> > next-level-cache = <_CA57>;
> > enable-method = "psci";
> 
> Just curious why clocks are not specified in secondaries ?
> Does this continue work if I hotplug out CPUs in ascending order and
> then hotplug back in descending order ? Also the current driver or OS
> may deal with that but not a good assumption when write DT

Good point. I expect that this is an oversight.


Re: [PATCH v3 1/6] clk: renesas: rcar-gen3: Add Z clock divider support

2017-10-10 Thread Simon Horman
On Mon, Oct 09, 2017 at 10:02:34AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Oct 5, 2017 at 3:23 PM, Simon Horman  
> wrote:
> > From: Takeshi Kihara 
> >
> > This patch adds Z clock divider support for R-Car Gen3 SoC.
> >
> > Signed-off-by: Takeshi Kihara 
> > Signed-off-by: Simon Horman 
> > ---
> >
> > v2 [Simon Horman]
> > * Use DIV_ROUND_CLOSEST_ULL instead of open-coding the same behaviour
> >   using div_u64()
> > * Do not round rate to 100MHz in cpg_z_clk_recalc_rate
> > * Remove calculation for PLL post-divider, this is bogus.
> >   Instead do not round to closest in cpg_z_clk_round_rate()
> > * Drop check for !prate in cpg_z_clk_round_rate
> 
> Thanks for the updates!
> 
> > --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> > +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> 
> > +static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
> > +  unsigned long parent_rate)
> > +{
> > +   struct cpg_z_clk *zclk = to_z_clk(hw);
> > +   unsigned int mult;
> > +
> > +   mult = 32 - FIELD_GET(CPG_FRQCRC_ZFC_MASK, clk_readl(zclk->reg));
> > +   return DIV_ROUND_CLOSEST_ULL(parent_rate * mult, 32);
> 
> While parent_rate is unsigned long and thus 64-bit on arm64, this will work
> fine on R-Car Gen3.  However, if someone ever tries to reuse this on a
> 32-bit platform, the multiplication may overflow.
> Hence I recommend to make this a 64-bit multiplication explicitly, i.e.
> 
> return DIV_ROUND_CLOSEST_ULL((u64)parent_rate * mult, 32);

Thanks, will do.

> > +}
> > +
> > +static long cpg_z_clk_round_rate(struct clk_hw *hw, unsigned long rate,
> > +unsigned long *parent_rate)
> > +{
> > +   unsigned long prate = *parent_rate;
> > +   unsigned int mult;
> > +
> > +   mult = div_u64((u64)rate * 32, prate);
> 
> You can avoid the cast by making the constant 64-bit:
> 
> mult = div_u64(rate * 32ULL, prate);

Thanks, that looks a bit nicer.

> > +   mult = clamp(mult, 1U, 32U);
> > +
> > +   return *parent_rate * mult / 32;
> 
> Again, *parent_rate is 64-bit on arm64, but not on 32-bit platforms.
> 
> > +   /*
> > +* Note: There is no HW information about the worst case latency.
> > +*
> > +* Using experimental measurements, it seems that no more than
> > +* ~10 iterations are needed, independently of the CPU rate.
> > +* Since this value might be dependent of external xtal rate, pll1
> > +* rate or even the other emulation clocks rate, use 1000 as a
> 
> another emulated clock rate?
> (Yeah, copied from Gen2 ;-)

It seem so.

> Reviewed-by: Geert Uytterhoeven 


Re: [PATCH v3 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support

2017-10-10 Thread Simon Horman
On Tue, Oct 10, 2017 at 08:56:35AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Mon, Oct 9, 2017 at 10:02 AM, Geert Uytterhoeven
>  wrote:
> > On Thu, Oct 5, 2017 at 3:23 PM, Simon Horman  
> > wrote:
> >> From: Takeshi Kihara 
> >>
> >> This patch adds Z2 clock divider support for R-Car Gen3 SoC.
> >>
> >> Signed-off-by: Takeshi Kihara 
> >> Signed-off-by: Simon Horman 
> >> ---
> >> v2 [Simon Horman]
> >> * Consolidate Z and Z2 clock ops
> >> * Allow setting of Z2 clock
> >
> > Thanks for the update!
> >
> >> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
> >> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
> >
> >> @@ -88,8 +90,8 @@ static int cpg_z_clk_set_rate(struct clk_hw *hw, 
> >> unsigned long rate,
> >> if (clk_readl(zclk->kick_reg) & CPG_FRQCRB_KICK)
> >> return -EBUSY;
> >>
> >> -   val = clk_readl(zclk->reg) & ~CPG_FRQCRC_ZFC_MASK;
> >> -   val |= FIELD_PREP(CPG_FRQCRC_ZFC_MASK, 32 - mult);
> >> +   val = clk_readl(zclk->reg) & ~zclk->mask;
> >> +   val |= ((32 - mult) << __bf_shf(zclk->mask)) & zclk->mask;
> >
> > Any special reason you're now open coding FIELD_PREP()?
> 
> Now I know: to circumvent the
> BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), ...) in
> __BF_FIELD_CHECK(), called from FIELD_PREP().

Yes, that is correct.
A comment is probably in order.

> Given  is intended to work with constant masks
> only, I think it's best to not use it, and replace __bf_shf() by __ffs().

I see there has been some discussion of this elsewhere.
Perhaps its best to let that cool down before I repost.

> 
> > Reviewed-by: Geert Uytterhoeven 
> 
> Oops, looks like you forgot to replace CPG_FRQCRC_ZFC_MASK in
> cpg_z_clk_recalc_rate() by zclk->mask.
> Sorry for missing that.

Thanks, will fix.


Re: [RFC][PATCH 3/4] pinctrl: sh-pfc: r8a77995: add Audio clock pin support

2017-10-10 Thread Geert Uytterhoeven
Hi Morimoto-san,

On Tue, Oct 10, 2017 at 9:06 AM, Kuninori Morimoto
 wrote:
>> >> >  - audio_clka
>> >> >  - audio_clkb
>> >> >  + audio_clk_a
>> >> >  + audio_clk_b
>> >>
>> >> It's debatable.
>> >> The datasheet uses "CLKA" and "CLKOUT", while the pinctrl drivers tend
>> >> to use "clk_a" (with underscore) and "clkout" (without underscore).
>> >>
>> >> Except for r8a7794, which uses the "clka" form. Oops...
>> >> As this is DT ABI, we cannot easily change it. But if you want, we can add
>> >> aliases.
>> >
>> > I have no strong opinion about this "clka" vs "clk_a".
>> > I will do nothing if you are OK on this current patch (= "clka"),
>> > I will post v2 patch if you say "clk_a" is good.
>>
>> I think it's best to follow what's done in the other R-Car Gen3 SoCs.
>> Else we may end up in trouble if a board shows up that can support both
>> R-Car D3 and another R-Car Gen3 SoC (cfr. Salvator-X(S) and ULCB
>> with R-Car H3 and M3-W).
>
> Yeah agree.
> But unfortunately, both "clka" / "clk_a" are already used, right ?
> I think we want to have "clk_a" ?

Yes. "clk_a" is what used on all R-Car SoCs, except for R-Car E2.

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: [RFC][PATCH 3/4] pinctrl: sh-pfc: r8a77995: add Audio clock pin support

2017-10-10 Thread Kuninori Morimoto

Hi Geert

> >> >  - audio_clka
> >> >  - audio_clkb
> >> >  + audio_clk_a
> >> >  + audio_clk_b
> >>
> >> It's debatable.
> >> The datasheet uses "CLKA" and "CLKOUT", while the pinctrl drivers tend
> >> to use "clk_a" (with underscore) and "clkout" (without underscore).
> >>
> >> Except for r8a7794, which uses the "clka" form. Oops...
> >> As this is DT ABI, we cannot easily change it. But if you want, we can add
> >> aliases.
> >
> > I have no strong opinion about this "clka" vs "clk_a".
> > I will do nothing if you are OK on this current patch (= "clka"),
> > I will post v2 patch if you say "clk_a" is good.
> 
> I think it's best to follow what's done in the other R-Car Gen3 SoCs.
> Else we may end up in trouble if a board shows up that can support both
> R-Car D3 and another R-Car Gen3 SoC (cfr. Salvator-X(S) and ULCB
> with R-Car H3 and M3-W).

Yeah agree.
But unfortunately, both "clka" / "clk_a" are already used, right ?
I think we want to have "clk_a" ?

Best regards
---
Kuninori Morimoto


Re: [PATCH 00/11] mmc: document mmc_regulator_get_supply and fix users

2017-10-10 Thread Ulf Hansson
On 7 October 2017 at 12:36, Wolfram Sang
 wrote:
> Fix the drivers and add some docs according to the outcome of this discussion
> [1] we had recently. The motivation from the patch description:
>
> Bail out everytime when mmc_regulator_get_supply() returns an errno, not only
> when probing gets deferred. This is currently a no-op, because this function
> only returns -EPROBE_DEFER or 0 right now. But if it will throw another error
> somewhen, it will be for a reason. (This still doesn't change that getting
> regulators is optional, so 0 can still mean no regulators found). So, let us 
> a)
> be future proof and b) have driver code which is easier to understand.
>
> The patches have been created with coccinelle. A branch can be found here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
> renesas/mmc-get-supply-docs
>
> Looking forward to comments!
>
> Kind regards,
>
>Wolfram
>
> [1] https://patchwork.kernel.org/patch/9965823/
>
> Wolfram Sang (11):
>   mmc: add kerneldoc to mmc_regulator_get_supply()
>   mmc: cavium: catch all errors when getting regulators
>   mmc: dw_mmc: catch all errors when getting regulators
>   mmc: meson-gx-mmc: catch all errors when getting regulators
>   mmc: meson-mx-sdio: catch all errors when getting regulators
>   mmc: mmci: catch all errors when getting regulators
>   mmc: mtk-sd: catch all errors when getting regulators
>   mmc: mxcmmc: catch all errors when getting regulators
>   mmc: omap_hsmmc: catch all errors when getting regulators
>   mmc: sdhci: catch all errors when getting regulators
>   mmc: usdhi6rol0: catch all errors when getting regulators
>
>  drivers/mmc/core/core.c  | 10 ++
>  drivers/mmc/host/cavium.c|  2 +-
>  drivers/mmc/host/dw_mmc.c|  2 +-
>  drivers/mmc/host/meson-gx-mmc.c  |  2 +-
>  drivers/mmc/host/meson-mx-sdio.c |  2 +-
>  drivers/mmc/host/mmci.c  |  2 +-
>  drivers/mmc/host/mtk-sd.c|  2 +-
>  drivers/mmc/host/mxcmmc.c|  2 +-
>  drivers/mmc/host/omap_hsmmc.c|  2 +-
>  drivers/mmc/host/sdhci.c |  2 +-
>  drivers/mmc/host/usdhi6rol0.c|  2 +-
>  11 files changed, 20 insertions(+), 10 deletions(-)
>
> --

Looks good to me, however as pointed out by Fabrizio, you could run a
round of checkpatch (mainly about commit message format).

Or perhaps even coccinelle needs an update to be adopted to
requirement from checkpatch?

Kind regards
Uffe


Re: [PATCH v3 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support

2017-10-10 Thread Geert Uytterhoeven
Hi Simon,

On Mon, Oct 9, 2017 at 10:02 AM, Geert Uytterhoeven
 wrote:
> On Thu, Oct 5, 2017 at 3:23 PM, Simon Horman  
> wrote:
>> From: Takeshi Kihara 
>>
>> This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>>
>> Signed-off-by: Takeshi Kihara 
>> Signed-off-by: Simon Horman 
>> ---
>> v2 [Simon Horman]
>> * Consolidate Z and Z2 clock ops
>> * Allow setting of Z2 clock
>
> Thanks for the update!
>
>> --- a/drivers/clk/renesas/rcar-gen3-cpg.c
>> +++ b/drivers/clk/renesas/rcar-gen3-cpg.c
>
>> @@ -88,8 +90,8 @@ static int cpg_z_clk_set_rate(struct clk_hw *hw, unsigned 
>> long rate,
>> if (clk_readl(zclk->kick_reg) & CPG_FRQCRB_KICK)
>> return -EBUSY;
>>
>> -   val = clk_readl(zclk->reg) & ~CPG_FRQCRC_ZFC_MASK;
>> -   val |= FIELD_PREP(CPG_FRQCRC_ZFC_MASK, 32 - mult);
>> +   val = clk_readl(zclk->reg) & ~zclk->mask;
>> +   val |= ((32 - mult) << __bf_shf(zclk->mask)) & zclk->mask;
>
> Any special reason you're now open coding FIELD_PREP()?

Now I know: to circumvent the
BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), ...) in
__BF_FIELD_CHECK(), called from FIELD_PREP().

Given  is intended to work with constant masks
only, I think it's best to not use it, and replace __bf_shf() by __ffs().

> Reviewed-by: Geert Uytterhoeven 

Oops, looks like you forgot to replace CPG_FRQCRC_ZFC_MASK in
cpg_z_clk_recalc_rate() by zclk->mask.
Sorry for missing that.

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: [RFC][PATCH 3/4] pinctrl: sh-pfc: r8a77995: add Audio clock pin support

2017-10-10 Thread Geert Uytterhoeven
Hi Morimoto-san,

On Tue, Oct 10, 2017 at 2:07 AM, Kuninori Morimoto
 wrote:
>> >  - audio_clka
>> >  - audio_clkb
>> >  + audio_clk_a
>> >  + audio_clk_b
>>
>> It's debatable.
>> The datasheet uses "CLKA" and "CLKOUT", while the pinctrl drivers tend
>> to use "clk_a" (with underscore) and "clkout" (without underscore).
>>
>> Except for r8a7794, which uses the "clka" form. Oops...
>> As this is DT ABI, we cannot easily change it. But if you want, we can add
>> aliases.
>
> I have no strong opinion about this "clka" vs "clk_a".
> I will do nothing if you are OK on this current patch (= "clka"),
> I will post v2 patch if you say "clk_a" is good.

I think it's best to follow what's done in the other R-Car Gen3 SoCs.
Else we may end up in trouble if a board shows up that can support both
R-Car D3 and another R-Car Gen3 SoC (cfr. Salvator-X(S) and ULCB
with R-Car H3 and M3-W).

Do you agree?

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


[PATCH v4 1/4] phy: rcar-gen3-usb2: check dr_mode for otg mode

2017-10-10 Thread Yoshihiro Shimoda
The previous code assumed a channel has otg capability if a channel
has interrupt property. But, it is not good because:
 - Battery charging feature also needs interrupt property.
 - Some R-Car Gen3 SoCs (e.g. R-Car D3) don't have OTG capability.

So, this patch checks whether usb 2.0 host node has dr_mode property or
not. If it has 'dr_mode = "otg";', this driver enables otg capability.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 54c3429..e00e99a 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -1,7 +1,7 @@
 /*
  * Renesas R-Car Gen3 for USB2.0 PHY driver
  *
- * Copyright (C) 2015 Renesas Electronics Corporation
+ * Copyright (C) 2015-2017 Renesas Electronics Corporation
  *
  * This is based on the phy-rcar-gen2 driver:
  * Copyright (C) 2014 Renesas Solutions Corp.
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*** USB2.0 Host registers (original offset is +0x200) ***/
@@ -415,13 +416,16 @@ static int rcar_gen3_phy_usb2_probe(struct 
platform_device *pdev)
/* call request_irq for OTG */
irq = platform_get_irq(pdev, 0);
if (irq >= 0) {
-   int ret;
-
INIT_WORK(>work, rcar_gen3_phy_usb2_work);
irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
   IRQF_SHARED, dev_name(dev), channel);
if (irq < 0)
dev_err(dev, "No irq handler (%d)\n", irq);
+   }
+
+   if (of_usb_get_dr_mode_by_phy(dev->of_node, 0) == USB_DR_MODE_OTG) {
+   int ret;
+
channel->has_otg = true;
channel->extcon = devm_extcon_dev_allocate(dev,
rcar_gen3_phy_cable);
-- 
1.9.1



[PATCH v4 2/4] phy: rcar-gen3-usb2: cleanup the role_{store,show}()

2017-10-10 Thread Yoshihiro Shimoda
This patch cleanups the role_{store,show}() and replaces the local
"bool" for host/device mode selection with the "enum phy_mode" in
the role_store().

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 58 ++--
 1 file changed, 40 insertions(+), 18 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index e00e99a..7619468 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -219,14 +219,10 @@ static bool rcar_gen3_is_host(struct rcar_gen3_chan *ch)
return !(readl(ch->base + USB2_COMMCTRL) & USB2_COMMCTRL_OTG_PERI);
 }
 
-static ssize_t role_store(struct device *dev, struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t rcar_gen3_otg_change_role(struct rcar_gen3_chan *ch,
+enum phy_mode mode)
 {
-   struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
-   bool is_b_device, is_host, new_mode_is_host;
-
-   if (!ch->has_otg || !ch->phy->init_count)
-   return -EIO;
+   bool is_b_device, is_host;
 
/*
 * is_b_device: true is B-Device. false is A-Device.
@@ -234,18 +230,13 @@ static ssize_t role_store(struct device *dev, struct 
device_attribute *attr,
 */
is_b_device = rcar_gen3_check_id(ch);
is_host = rcar_gen3_is_host(ch);
-   if (!strncmp(buf, "host", strlen("host")))
-   new_mode_is_host = true;
-   else if (!strncmp(buf, "peripheral", strlen("peripheral")))
-   new_mode_is_host = false;
-   else
-   return -EINVAL;
 
/* If current and new mode is the same, this returns the error */
-   if (is_host == new_mode_is_host)
+   if ((is_host && mode == PHY_MODE_USB_HOST) ||
+   (!is_host && mode == PHY_MODE_USB_DEVICE))
return -EINVAL;
 
-   if (new_mode_is_host) { /* And is_host must be false */
+   if (mode == PHY_MODE_USB_HOST) { /* And is_host must be false */
if (!is_b_device)   /* A-Peripheral */
rcar_gen3_init_from_a_peri_to_a_host(ch);
else/* B-Peripheral */
@@ -257,6 +248,32 @@ static ssize_t role_store(struct device *dev, struct 
device_attribute *attr,
rcar_gen3_init_for_peri(ch);
}
 
+   return 0;
+}
+
+static ssize_t role_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
+   enum phy_mode mode;
+   ssize_t ret = -EIO;
+
+   if (!ch->phy->init_count)
+   return -EIO;
+
+   if (!strncmp(buf, "host", strlen("host")))
+   mode = PHY_MODE_USB_HOST;
+   else if (!strncmp(buf, "peripheral", strlen("peripheral")))
+   mode = PHY_MODE_USB_DEVICE;
+   else
+   return -EINVAL;
+
+   if (ch->has_otg)
+   ret = rcar_gen3_otg_change_role(ch, mode);
+
+   if (ret < 0)
+   return ret;
+
return count;
 }
 
@@ -264,12 +281,17 @@ static ssize_t role_show(struct device *dev, struct 
device_attribute *attr,
 char *buf)
 {
struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
+   bool is_host;
 
-   if (!ch->has_otg || !ch->phy->init_count)
+   if (!ch->phy->init_count)
+   return -EIO;
+
+   if (ch->has_otg)
+   is_host = rcar_gen3_is_host(ch);
+   else
return -EIO;
 
-   return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
-   "peripheral");
+   return sprintf(buf, "%s\n", is_host ? "host" : "peripheral");
 }
 static DEVICE_ATTR_RW(role);
 
-- 
1.9.1



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

2017-10-10 Thread Yoshihiro Shimoda
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 r8a77995.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index ace9cce..99b651b 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -8,6 +8,8 @@ Required properties:
  SoC.
  "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796
  SoC.
+ "renesas,usb2-phy-r8a77995" if the device is a part of an
+ R8A77995 SoC.
  "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible 
device.
 
  When compatible with the generic version, nodes must list the
-- 
1.9.1



[PATCH v4 3/4] phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins

2017-10-10 Thread Yoshihiro Shimoda
This patch adds SoC-specific parameter to avoid reading/writing
specific registers wrongly if this driver runs on a SoC which doesn't
have dedicated pins (e.g. R-Car D3). This patch also changes the
value "has_otg" to "has_otg_pins" for slightly easier reading of
the code.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Simon Horman 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 7619468..d097539 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,6 +81,8 @@
 #define USB2_ADPCTRL_IDPULLUP  BIT(5)  /* 1 = ID sampling is enabled */
 #define USB2_ADPCTRL_DRVVBUS   BIT(4)
 
+#define RCAR_GEN3_PHY_HAS_DEDICATED_PINS   1
+
 struct rcar_gen3_chan {
void __iomem *base;
struct extcon_dev *extcon;
@@ -87,7 +90,7 @@ struct rcar_gen3_chan {
struct regulator *vbus;
struct work_struct work;
bool extcon_host;
-   bool has_otg;
+   bool has_otg_pins;
 };
 
 static void rcar_gen3_phy_usb2_work(struct work_struct *work)
@@ -268,7 +271,7 @@ static ssize_t role_store(struct device *dev, struct 
device_attribute *attr,
else
return -EINVAL;
 
-   if (ch->has_otg)
+   if (ch->has_otg_pins)
ret = rcar_gen3_otg_change_role(ch, mode);
 
if (ret < 0)
@@ -286,7 +289,7 @@ static ssize_t role_show(struct device *dev, struct 
device_attribute *attr,
if (!ch->phy->init_count)
return -EIO;
 
-   if (ch->has_otg)
+   if (ch->has_otg_pins)
is_host = rcar_gen3_is_host(ch);
else
return -EIO;
@@ -326,7 +329,7 @@ static int rcar_gen3_phy_usb2_init(struct phy *p)
writel(USB2_OC_TIMSET_INIT, usb2_base + USB2_OC_TIMSET);
 
/* Initialize otg part */
-   if (channel->has_otg)
+   if (channel->has_otg_pins)
rcar_gen3_init_otg(channel);
 
return 0;
@@ -400,9 +403,17 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void 
*_ch)
 }
 
 static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
-   { .compatible = "renesas,usb2-phy-r8a7795" },
-   { .compatible = "renesas,usb2-phy-r8a7796" },
-   { .compatible = "renesas,rcar-gen3-usb2-phy" },
+   {
+   .compatible = "renesas,usb2-phy-r8a7795",
+   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
+   },
+   {
+   .compatible = "renesas,usb2-phy-r8a7796",
+   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
+   },
+   {
+   .compatible = "renesas,rcar-gen3-usb2-phy",
+   },
{ }
 };
 MODULE_DEVICE_TABLE(of, rcar_gen3_phy_usb2_match_table);
@@ -448,7 +459,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
if (of_usb_get_dr_mode_by_phy(dev->of_node, 0) == USB_DR_MODE_OTG) {
int ret;
 
-   channel->has_otg = true;
+   channel->has_otg_pins = 
(uintptr_t)of_device_get_match_data(dev);
channel->extcon = devm_extcon_dev_allocate(dev,
rcar_gen3_phy_cable);
if (IS_ERR(channel->extcon))
@@ -490,7 +501,7 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
dev_err(dev, "Failed to register PHY provider\n");
ret = PTR_ERR(provider);
goto error;
-   } else if (channel->has_otg) {
+   } else if (channel->has_otg_pins) {
int ret;
 
ret = device_create_file(dev, _attr_role);
@@ -510,7 +521,7 @@ static int rcar_gen3_phy_usb2_remove(struct platform_device 
*pdev)
 {
struct rcar_gen3_chan *channel = platform_get_drvdata(pdev);
 
-   if (channel->has_otg)
+   if (channel->has_otg_pins)
device_remove_file(>dev, _attr_role);
 
pm_runtime_disable(>dev);
-- 
1.9.1



[PATCH v4 0/4] phy: rcar-gen3-usb2: add support for r8a77995

2017-10-10 Thread Yoshihiro Shimoda
This patch set is based on the latest phy.git / next branch
(the commit id = 415060b21f318e009d865b4bcbf8f220ebc36964)

After this patch set is applied, a usb 2.0 host node that is combined
with usb 2.0 peripheral needs 'dr_mode = "otg";' property.

Changes from v3:
 - Use enum phy_mode in patch 2.
 - Remove "can_role_swap" parameter and revise the commit log in patch 2
   because a case of "can_role_swap = true" and "has_otg = false" is
   not supported for role swap at the moment.
 - Changes the name of "has_otg" to "has_otg_pins" in patch 3.
 - Use of_device_get_match_data() instead of of_match_device()
 - Add "Reviewed-by:" into patch No.1, 2 and 4. (Simon-san, Thanks!)
  - Since patch No.3 is changed in big at v4, I dropped his "Reviewed-by".

Changes from v2:
 - Revise the commit log ("SoCs" is not third-person singular present).

Changes from v1:
 - Revise typo "wronly" to "wrongly".
 - Remove RCAR_GEN3_PHY_HAS_DEDICATED_PINS from generic gen3 entry in
   patch 3/4
 - Remove the driver change from patch 4/4.
 - Revise the commit log of patch 4/4.


Yoshihiro Shimoda (4):
  phy: rcar-gen3-usb2: check dr_mode for otg mode
  phy: rcar-gen3-usb2: cleanup the role_{store,show}()
  phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins
  phy: rcar-gen3-usb2: add binding for r8a77995

 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  2 +
 drivers/phy/renesas/phy-rcar-gen3-usb2.c   | 95 +++---
 2 files changed, 68 insertions(+), 29 deletions(-)

-- 
1.9.1



RE: [PATCH v3 2/4] phy: rcar-gen3-usb2: split the two meaning of "has_otg"

2017-10-10 Thread Yoshihiro Shimoda
Hi,

Thank you for the comment!
I will submit v4 patch soon. But, I wrote some comments below.

> From: Kishon Vijay Abraham I, Sent: Monday, October 9, 2017 7:07 PM
> 
> Hi,
> 
> On Friday 01 September 2017 08:11 AM, Yoshihiro Shimoda wrote:
> > The has_otg on previous code has the two meaning:
> >  - The channel has dedicated otg pins (ID, VBUS).
> >  - The channel can swap the role via sysfs.
> >
> > However, some SoCs (e.g. R-Car D3) doesn't have such dedicated pins,
> > but the SoCs can swap the role. So, this patch split the two meaning
> > of has_otg as "has dedicated otg pins" and adds a new value
> > "can_role_swap". For now, the behavior is the same as before.
> 
> Might not be directly related to $patch, but in general certain cleanups can 
> be
> done..
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 61 
> > ++--
> >  1 file changed, 42 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
> > b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > index e00e99a..4ea9902 100644
> > --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > @@ -87,7 +87,8 @@ struct rcar_gen3_chan {
> > struct regulator *vbus;
> > struct work_struct work;
> > bool extcon_host;
> > -   bool has_otg;
> > +   bool has_otg;   /* has dedicated pins (ID, VBUS) */
> > +   bool can_role_swap;
> >  };
> >
> >  static void rcar_gen3_phy_usb2_work(struct work_struct *work)
> > @@ -219,14 +220,10 @@ static bool rcar_gen3_is_host(struct rcar_gen3_chan 
> > *ch)
> > return !(readl(ch->base + USB2_COMMCTRL) & USB2_COMMCTRL_OTG_PERI);
> >  }
> >
> > -static ssize_t role_store(struct device *dev, struct device_attribute 
> > *attr,
> > - const char *buf, size_t count)
> > +static ssize_t rcar_gen3_otg_change_role(struct rcar_gen3_chan *ch,
> > +bool new_mode_is_host)
> 
> replace new_mode_is_host with enum mode.

I got it. I will replace it in v4 patch.

> >  {
> > -   struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> > -   bool is_b_device, is_host, new_mode_is_host;
> > -
> > -   if (!ch->has_otg || !ch->phy->init_count)
> > -   return -EIO;
> > +   bool is_b_device, is_host;
> >
> > /*
> >  * is_b_device: true is B-Device. false is A-Device.
> > @@ -234,12 +231,6 @@ static ssize_t role_store(struct device *dev, struct 
> > device_attribute *attr,
> >  */
> > is_b_device = rcar_gen3_check_id(ch);
> > is_host = rcar_gen3_is_host(ch);
> > -   if (!strncmp(buf, "host", strlen("host")))
> > -   new_mode_is_host = true;
> > -   else if (!strncmp(buf, "peripheral", strlen("peripheral")))
> > -   new_mode_is_host = false;
> > -   else
> > -   return -EINVAL;
> >
> > /* If current and new mode is the same, this returns the error */
> > if (is_host == new_mode_is_host)
> > @@ -257,6 +248,32 @@ static ssize_t role_store(struct device *dev, struct 
> > device_attribute *attr,
> > rcar_gen3_init_for_peri(ch);
> > }
> >
> > +   return 0;
> > +}
> > +
> > +static ssize_t role_store(struct device *dev, struct device_attribute 
> > *attr,
> > + const char *buf, size_t count)
> > +{
> > +   struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> > +   bool new_mode_is_host;
> > +   ssize_t ret = -EIO;
> > +
> > +   if (!ch->phy->init_count)
> > +   return -EIO;
> > +
> > +   if (!strncmp(buf, "host", strlen("host")))
> > +   new_mode_is_host = true;
> > +   else if (!strncmp(buf, "peripheral", strlen("peripheral")))
> > +   new_mode_is_host = false;
> 
> set the enum mode here.

I will set it in v4 patch.

> > +   else
> > +   return -EINVAL;
> > +
> > +   if (ch->has_otg)
> > +   ret = rcar_gen3_otg_change_role(ch, new_mode_is_host);
> 
> Aren't you using sysfs to change the role here?

Oops! The patch set doesn't take care about a case of "can_role_swap = true" 
and "has_otg = false".
So, I will remove the "can_role_swap" parameter in v4 patch.

> > +
> > +   if (ret < 0)
> > +   return ret;
> > +
> > return count;
> >  }
> >
> > @@ -264,12 +281,17 @@ static ssize_t role_show(struct device *dev, struct 
> > device_attribute *attr,
> >  char *buf)
> >  {
> > struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
> > +   bool is_host;
> >
> > -   if (!ch->has_otg || !ch->phy->init_count)
> > +   if (!ch->phy->init_count)
> > return -EIO;
> >
> > -   return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
> > -   "peripheral");
> > +   if (ch->has_otg)
> > +   is_host = rcar_gen3_is_host(ch);
> > +   else
> > +   return -EIO;
> > +
> > +   return sprintf(buf, "%s\n", is_host ? "host" : "peripheral");
> >  }
> >  static