Re: [PATCH mmc-utils] use proper type for RPMB blocks_cnt

[Chris Ball]

Hi Wolfram,

On Fri, Nov 30, 2018 at 01:54:47PM +0100, Wolfram Sang wrote:
> The JEDEC standard is confusing. The number of max blocks for reading
> RPMB is determined by CMD23 which can hold an unsigned int and not only
> u16. It is true that the current maximum is 64K of blocks, yet this may
> be extended in the future. Let's not apply a limit here which should be
> checked by the card.
> 
> Signed-off-by: Wolfram Sang 

Thanks, applied to mmc-utils master.

-- 
Chris Ball   

Re: [PATCH mmc-utils] fix GCC7 build by refactoring trimming routines

[Chris Ball]

Hi everyone, I'm very sorry for the delay in responding to these patches
and the duplicated effort it caused.

On Mon, Dec 03, 2018 at 03:24:42PM +0100, Wolfram Sang wrote:
> Hi Avri, hi Chris,
> 
> > > I got a compile error with GCC7. When trimming white spaces from strings
> > > lsmmc uses strncpy with overlapping memory areas. This is not allowed.
> > > In addition, the implementation was not efficient with calling strlen
> > > and strncpy once per iteration. Refactor the code to be valid and more
> > > effective.
> > > 
> > > Signed-off-by: Wolfram Sang 

Thanks, I've applied this fix of Wolfram's to mmc-utils master.

> Thanks for the pointer. Chris, how do you feel with maintaining
> mmc-utils? Would you maybe be willing to share maintenance with someone?

Yep, that'd make sense.

-- 
Chris Ball   

Re: [PATCH v4 2/5] dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock

[Rob Herring]

On Fri,  7 Dec 2018 11:27:43 +, Biju Das wrote:
> The pcf85263 RTC is compatible with the pcf85363 RTC.
> 
> The difference between the pcf85263 and pcf85363 RTC is that the latter has
> 64 bytes more RAM. This renders them incompatible from a DT point of view.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Geert Uytterhoeven 
> ---
> V1-->V2
>   * Incorporated Simon's review comment.
> V2-->V3
>   * No Change.
> V3-->V4
>   * No Change.
> ---
>  Documentation/devicetree/bindings/rtc/pcf85363.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH 2/3] arm64: defconfig: Enable scu-simple-card driver

[Simon Horman]

On Fri, Dec 07, 2018 at 09:28:22AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Dec 6, 2018 at 10:58 PM Simon Horman  
> wrote:
> > Enable the scu-simple-card which is used by
> > the R-Car E3 (r8a77990) based Ebisu board.
> >
> > Signed-off-by: Simon Horman 
> > ---
> >  arch/arm64/configs/defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> > index f88190463481..9d0b42d96f03 100644
> > --- a/arch/arm64/configs/defconfig
> > +++ b/arch/arm64/configs/defconfig
> > @@ -491,6 +491,7 @@ CONFIG_SND_SOC_RT5514=m
> >  CONFIG_SND_SOC_RT5514_SPI=m
> >  CONFIG_SND_SOC_RT5645=m
> >  CONFIG_SND_SIMPLE_CARD=m
> > +CONFIG_SND_SIMPLE_SCU_CARD=y
> 
> Shouldn't this be "m"?

Thanks Geert,

I'll look into an incremental update for that.

> 
> >  CONFIG_SND_AUDIO_GRAPH_CARD=m
> >  CONFIG_I2C_HID=m
> >  CONFIG_USB=y
> 
> 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
> 

pwm: rcar: improve calculation of divider

[Uwe Kleine-König]

Hello,

while looking at the driver I noticed another patch opportunity: In
rcar_pwm_get_clock_division() there is a loop:

for (div = 0; div <= RCAR_PWM_MAX_DIVISION; div++) {
max = (unsigned long long)NSEC_PER_SEC * RCAR_PWM_MAX_CYCLE *
(1 << div);
do_div(max, clk_rate);
if (period_ns <= max)
break;
}

The value of div should be calculatable without a loop. Something like:

   divider = NSEC_PER_SEC * RCAR_PWM_MAX_CYCLE;
   tmp = (unsigned long long)period_ns * clk_rate + (divider - 1);
   do_div(tmp, divider);
   div = ilog2(tmp - 1) + 1;

You might want to check if my maths are right, I didn't test.

Best regards
Uwe

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

Re: [RFC] watchdog: renesas_wdt: don't keep timer value during suspend/resume

[Wolfram Sang]

Hi Guenter, all,

> > After discussing this mail thread [1] again, we concluded that giving
> > userspace enough time to prepare is our favourite option. So, do not
> > keep the time value when suspended but reset it when resuming.
> > 
> > [1] https://patchwork.kernel.org/patch/10252209/
> > 
> > Signed-off-by: Wolfram Sang 
> 
> Above exchange says it all, no need to repeat.
> 
> Reviewed-by: Guenter Roeck 

Thanks.

I can relate to the policy argument, though. Regardless of this patch, I
wonder if we can make it configurable from userspace. A draft:

#define WDIOF_RESUME_OPTS   0x0800

#define WDIOS_RESUME_KEEP   0x0008
#define WDIOS_RESUME_RESET  0x0010

and then in watchdog_ioctl() under WDIOC_SETOPTIONS:

if (!(wdd->info->options & WDIOF_RESUME_OPTS))
err = -EOPNOTSUPP;
goto break;

if (val & WDIOS_RESUME_KEEP)
wdd->status |= WDOG_KEEP_TIMER_WHEN_RESUME;

if (val & WDIOS_RESUME_RESET)
wdd->status ~= ~WDOG_KEEP_TIMER_WHEN_RESUME;

So, drivers with WDIOF_RESUME_OPTS could act on the
WDOG_KEEP_TIMER_WHEN_RESUME flag.

Opinions?

Thanks,

   Wolfram

Re: [PATCH] arm64: dts: renesas: enable HS400 on R-Car Gen3

[Niklas Söderlund]

Hi Simon, Wolfram,

On 2018-12-05 22:36:13 +0100, Niklas Söderlund wrote:
> Hi Wolfram,
> 
> On 2018-12-05 21:46:28 +0100, Wolfram Sang wrote:
> > On Fri, Nov 02, 2018 at 12:57:19PM +0100, Simon Horman wrote:
> > > On Thu, Nov 01, 2018 at 08:45:29PM +0100, Wolfram Sang wrote:
> > > > 
> > > > > This patch have quiet a few dependencies I'm afraid, let me know if 
> > > > > you 
> > > > > wish to be notified once they all upstream. I don't think it's a good 
> > > > > idea to pick this up before all dependencies are resolved.
> > > > 
> > > > Yes, we should do that. Ping Simon once all dependencies are in next. It
> > > > is still fine to have this patch here in case people want to test. BTW
> > > > did you mention your branch somewhere where you collected all these
> > > > patches to make HS400 working/enabled?
> > > > 
> > > > For this patch already:
> > > > 
> > > > Reviewed-by: Wolfram Sang 
> > > > Tested-by: Wolfram Sang 
> > > 
> > > Thanks, I am marking this as deferred.
> > > 
> > > Please repost or ping me once the dependencies are present in
> > > an rc release.
> > 
> > Niklas, are we done now, so we can ask Simon to pick up the DTS change?
> > 
> 
> Almost :-)
> 
> I'm  waiting for Geert to take the SD quirk patches before pinging Simon 
> to take this one. Spoke to him today about that so I hope it will not be 
> to long.
> 

I just confirmation that the clock patches have been pulled into 
clk-next so this patch is ready to be consumed by you Simon.

Would it be possible to get this in this cycle or is it to late? I know 
you wished to close your tree for v4.21 at the end of this week which it 
technically is now ;-)

-- 
Regards,
Niklas Söderlund

Re: [git pull] clk: renesas: Updates for v4.21 (take two)

[Stephen Boyd]

Quoting Geert Uytterhoeven (2018-12-07 04:22:03)
> Hi Mike, Stephen,
> 
> The following changes since commit eb38c119dd91c61de26f67050671a84064554f7d:
> 
>   clk: renesas: r7s9210: Add USB clocks (2018-11-13 09:58:51 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/clk-renesas-for-v4.21-tag2
> 
> for you to fetch changes up to 36c4da4f552a126bb29a95dc5c9608795491e32a:
> 
>   clk: renesas: rcar-gen3: Add HS400 quirk for SD clock (2018-12-07 11:45:06 
> +0100)
> 

Thanks. Pulled into clk-next.

[PATCH] ARM: shmobile: Fix R-Car Gen2 regulator quirk

[Marek Vasut]

The quirk code currently detects all compatible I2C chips with a shared
IRQ line on all I2C busses, adds them into a list, and registers a bus
notifier. For every chip for which the bus notifier triggers, the quirk
code performs I2C transfer on that I2C bus for all addresses in the list.
The problem is that this may generate transfers to non-existing chips on
systems with multiple I2C busses.

This patch adds a check to verify that the I2C bus to which the chip with
shared IRQ is attached to matches the I2C bus of the chip which triggered
the bus notifier and only starts the I2C transfer if they match.

Signed-off-by: Marek Vasut 
Cc: Geert Uytterhoeven 
Cc: Kuninori Morimoto 
Cc: Simon Horman 
Cc: Wolfram Sang 
Cc: Yoshihiro Shimoda 
Cc: linux-renesas-soc@vger.kernel.org
---
 arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c 
b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
index d4774d8ff997..f78e5348bd4c 100644
--- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
@@ -40,6 +40,7 @@
 struct regulator_quirk {
struct list_headlist;
const struct of_device_id   *id;
+   struct device_node  *np;
struct of_phandle_args  irq_args;
struct i2c_msg  i2c_msg;
boolshared; /* IRQ line is shared */
@@ -102,6 +103,9 @@ static int regulator_quirk_notify(struct notifier_block *nb,
if (!pos->shared)
continue;
 
+   if (pos->np->parent != client->dev.parent->of_node)
+   continue;
+
dev_info(>dev, "clearing %s@0x%02x interrupts\n",
 pos->id->compatible, pos->i2c_msg.addr);
 
@@ -167,6 +171,7 @@ static int __init rcar_gen2_regulator_quirk(void)
memcpy(>i2c_msg, id->data, sizeof(quirk->i2c_msg));
 
quirk->id = id;
+   quirk->np = np;
quirk->i2c_msg.addr = addr;
 
ret = of_irq_parse_one(np, 0, argsa);
-- 
2.18.0

Re: [PATCH 1/2] ARM: dts: stout: Convert to new LVDS DT bindings

[Marek Vasut]

On 12/05/2018 06:41 AM, Laurent Pinchart wrote:
> Hi Marek,
> 
> On Wednesday, 5 December 2018 03:10:18 EET Marek Vasut wrote:
>> On 12/03/2018 11:48 PM, Laurent Pinchart wrote:
>>> On Tuesday, 4 December 2018 00:24:32 EET Marek Vasut wrote:
 On 12/03/2018 10:48 PM, Laurent Pinchart wrote:
> On Monday, 3 December 2018 17:12:41 EET Geert Uytterhoeven wrote:
>> As of commit 6d2ca85279becdff ("dt-bindings: display: renesas:
>> Deprecate LVDS support in the DU bindings"), the internal LVDS encoder
>> has DT bindings separate from the DU.  The Lager device tree was ported
>> over to the new model, but the Stout device tree was forgotten.
>>
>> Fixes: 15a1ff30d8f9bd83 ("ARM: dts: r8a7790: Convert to new LVDS DT
>> bindings") Signed-off-by: Geert Uytterhoeven 
>> ---
>> Compile-tested only.
>
> I can't test the patch either but it looks fine to me.
>
> Reviewed-by: Laurent Pinchart 
>
> I assume you will send this directly to Simon, so I don't plan to take
> the patch in my tree.

 I have a Stout if you need me to test something.
>>>
>>> Could you test HDMI output ? We just need to ensure that everything is
>>> probed correctly, so display anything on the HDMI output will do.
>>
>> Sure, can you push me a branch somewhere, so I don't have to hunt down
>> patches ?
> 
> Only this patch should be needed. You can get it from https://
> patchwork.kernel.org/patch/10709781/ and apply it on top of v4.19. Please 
> don't use v4.20-rc is there's one missing regression fix there (it has been 
> merged in the media tree and should make it to the final release).

On R8A7790 H2 ES3.0 Stout

Tested-by: Marek Vasut 

-- 
Best regards,
Marek Vasut

[PATCH] pinctrl: sh-pfc: r8a77990: Add support for pull-up only pins

[Geert Uytterhoeven]

The R-Car Gen3 HardWare Manual Errata for Rev. 1.00 (Jul 2, 2018) states
that the USB30_OVC pin supports pull-up only.  It has a bit assigned in
the pull-enable register (PUEN5), but not in the pull-up/down control
register (PUD5).

Add a check for this, to prevent configuring a prohibited setting.

Reported-by: Yoshihiro Shimoda 
Fixes: 83f6941a42a5e773 ("pinctrl: sh-pfc: r8a77990: Add bias pinconf support")
Signed-off-by: Geert Uytterhoeven 
---
To be queued in sh-pfc-for-v4.22.

 drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c 
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 8c06d72753890e32..784d4400c3e0e7ea 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -4914,6 +4914,17 @@ static const struct pinmux_bias_reg pinmux_bias_regs[] = 
{
{ /* sentinel */ },
 };
 
+static bool pin_has_pud(unsigned int pin)
+{
+   /* Some pins are pull-up only */
+   switch (pin) {
+   case RCAR_GP_PIN(6, 9): /* USB30_OVC  */
+   return false;
+   }
+
+   return true;
+}
+
 static unsigned int r8a77990_pinmux_get_bias(struct sh_pfc *pfc,
 unsigned int pin)
 {
@@ -4926,7 +4937,7 @@ static unsigned int r8a77990_pinmux_get_bias(struct 
sh_pfc *pfc,
 
if (!(sh_pfc_read(pfc, reg->puen) & BIT(bit)))
return PIN_CONFIG_BIAS_DISABLE;
-   else if (sh_pfc_read(pfc, reg->pud) & BIT(bit))
+   else if (!pin_has_pud(pin) || (sh_pfc_read(pfc, reg->pud) & BIT(bit)))
return PIN_CONFIG_BIAS_PULL_UP;
else
return PIN_CONFIG_BIAS_PULL_DOWN;
@@ -4947,11 +4958,13 @@ static void r8a77990_pinmux_set_bias(struct sh_pfc 
*pfc, unsigned int pin,
if (bias != PIN_CONFIG_BIAS_DISABLE)
enable |= BIT(bit);
 
-   updown = sh_pfc_read(pfc, reg->pud) & ~BIT(bit);
-   if (bias == PIN_CONFIG_BIAS_PULL_UP)
-   updown |= BIT(bit);
+   if (pin_has_pud(pin)) {
+   updown = sh_pfc_read(pfc, reg->pud) & ~BIT(bit);
+   if (bias == PIN_CONFIG_BIAS_PULL_UP)
+   updown |= BIT(bit);
 
-   sh_pfc_write(pfc, reg->pud, updown);
+   sh_pfc_write(pfc, reg->pud, updown);
+   }
sh_pfc_write(pfc, reg->puen, enable);
 }
 
-- 
2.17.1

Re: [git pull] pinctrl: sh-pfc: Updates for v4.21 (take two)

[Linus Walleij]

On Fri, Dec 7, 2018 at 1:21 PM Geert Uytterhoeven
 wrote:

> The following changes since commit b59d0e782706785b7042539e820e95df3be4d04c:
>
>   pinctrl: Add RZ/A2 pin and gpio controller (2018-11-23 09:30:27 +0100)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/sh-pfc-for-v4.21-tag2
>
> for you to fetch changes up to 3f3327dbc5596076f94695d8d4cc66da3d5027fb:
>
>   pinctrl: rzn1: Fix of_get_child_count() error check (2018-12-04 10:33:49 
> +0100)

Merged this "take two" version into my devel branch!

Thanks!
Linus Walleij

[git pull] clk: renesas: Updates for v4.21 (take two)

[Geert Uytterhoeven]

Hi Mike, Stephen,

The following changes since commit eb38c119dd91c61de26f67050671a84064554f7d:

  clk: renesas: r7s9210: Add USB clocks (2018-11-13 09:58:51 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/clk-renesas-for-v4.21-tag2

for you to fetch changes up to 36c4da4f552a126bb29a95dc5c9608795491e32a:

  clk: renesas: rcar-gen3: Add HS400 quirk for SD clock (2018-12-07 11:45:06 
+0100)


clk: renesas: Updates for v4.21 (take two)

  - Add support for CPEX (timer) clocks on various R-Car Gen3 and RZ/G2
SoCs,
  - Add support for SDHI HS400 clocks on early revisions of R-Car H3 and
M3-W,
  - Miscellaneous fixes based on the Hardware Manual Errata.

Thanks for pulling!


Geert Uytterhoeven (12):
  dt-bindings: clock: r8a7795: Remove CSIREF clock
  dt-bindings: clock: r8a7796: Remove CSIREF clock
  clk: renesas: r8a774a1: Add CPEX clock
  clk: renesas: r8a7795: Add CPEX clock
  clk: renesas: r8a7796: Add CPEX clock
  clk: renesas: r8a77965: Add CPEX clock
  clk: renesas: r8a77970: Add CPEX clock
  clk: renesas: r8a77995: Correct parent clock of DU
  clk: renesas: r8a77995: Remove non-existent VIN5-7 module clocks
  clk: renesas: r8a77995: Remove non-existent SSP clocks
  clk: renesas: r8a77995: Add missing CPEX clock
  clk: renesas: r8a77995: Simplify PLL3 multiplier/divider

Niklas Söderlund (3):
  clk: renesas: rcar-gen3: Set state when registering SD clocks
  clk: renesas: rcar-gen3: Add documentation for SD clocks
  clk: renesas: rcar-gen3: Add HS400 quirk for SD clock

Takeshi Kihara (1):
  clk: renesas: r8a77990: Correct parent clock of DU

 drivers/clk/renesas/r8a774a1-cpg-mssr.c   |  1 +
 drivers/clk/renesas/r8a7795-cpg-mssr.c|  1 +
 drivers/clk/renesas/r8a7796-cpg-mssr.c|  1 +
 drivers/clk/renesas/r8a77965-cpg-mssr.c   |  1 +
 drivers/clk/renesas/r8a77970-cpg-mssr.c   |  1 +
 drivers/clk/renesas/r8a77990-cpg-mssr.c   |  4 +-
 drivers/clk/renesas/r8a77995-cpg-mssr.c   | 15 +++-
 drivers/clk/renesas/rcar-gen3-cpg.c   | 55 ---
 include/dt-bindings/clock/r8a7795-cpg-mssr.h  |  2 +-
 include/dt-bindings/clock/r8a7796-cpg-mssr.h  |  2 +-
 include/dt-bindings/clock/r8a77995-cpg-mssr.h |  5 ++-
 11 files changed, 51 insertions(+), 37 deletions(-)

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

[git pull] pinctrl: sh-pfc: Updates for v4.21 (take two)

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit b59d0e782706785b7042539e820e95df3be4d04c:

  pinctrl: Add RZ/A2 pin and gpio controller (2018-11-23 09:30:27 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/sh-pfc-for-v4.21-tag2

for you to fetch changes up to 3f3327dbc5596076f94695d8d4cc66da3d5027fb:

  pinctrl: rzn1: Fix of_get_child_count() error check (2018-12-04 10:33:49 
+0100)


pinctrl: sh-pfc: Updates for v4.21 (take two)

  - Two small fixes for RZ/N1.

Thanks for pulling!


Phil Edworthy (2):
  pinctrl: rzn1: Fix check for used MDIO bus
  pinctrl: rzn1: Fix of_get_child_count() error check

 drivers/pinctrl/pinctrl-rzn1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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

[git pull] pinctrl: sh-pfc: Updates for v4.21

[Geert Uytterhoeven]

Hi Linus,

The following changes since commit b59d0e782706785b7042539e820e95df3be4d04c:

  pinctrl: Add RZ/A2 pin and gpio controller (2018-11-23 09:30:27 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
tags/sh-pfc-for-v4.21-tag2

for you to fetch changes up to 3f3327dbc5596076f94695d8d4cc66da3d5027fb:

  pinctrl: rzn1: Fix of_get_child_count() error check (2018-12-04 10:33:49 
+0100)


pinctrl: sh-pfc: Updates for v4.21 (take two)

  - Two small fixes for RZ/N1.

Thanks for pulling!


Phil Edworthy (2):
  pinctrl: rzn1: Fix check for used MDIO bus
  pinctrl: rzn1: Fix of_get_child_count() error check

 drivers/pinctrl/pinctrl-rzn1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig

[Biju Das]

The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
support enable the driver in the shmobile_defconfig multiplatform
configuration.

Signed-off-by: Biju Das 
Reviewed-by: Geert Uytterhoeven 
---
V1-->V2
* No change.
V2-->V3
* No change.
V3-->V4
* No Change.
---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 9e5a5ad..fdac4e4 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -177,6 +177,7 @@ CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_PCF85363=y
 CONFIG_RTC_DRV_BQ32K=y
 CONFIG_RTC_DRV_S35390A=y
 CONFIG_RTC_DRV_RX8581=y
-- 
2.7.4

[PATCH v4 5/5] ARM: dts: iwg23s-sbc: Enable RTC

[Biju Das]

Enable NXP pcf85263 real time clock for the iWave SBC based on RZ/G1C.

Signed-off-by: Biju Das 
Reviewed-by: Geert Uytterhoeven 
---
V1-->V2
* No change
V2-->V3
* No change
V3-->V4
* No change
---
 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts 
b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
index 40b7f98..77d1824 100644
--- a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
+++ b/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
@@ -84,12 +84,30 @@
clock-frequency = <2000>;
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   rtc@51 {
+   compatible = "nxp,pcf85263";
+   reg = <0x51>;
+   };
+};
+
  {
avb_pins: avb {
groups = "avb_mdio", "avb_gmii_tx_rx";
function = "avb";
};
 
+   i2c3_pins: i2c3 {
+   groups = "i2c3_c";
+   function = "i2c3";
+   };
+
mmc_pins_uhs: mmc_uhs {
groups = "mmc_data8", "mmc_ctrl";
function = "mmc";
-- 
2.7.4

[PATCH v4 3/5] rtc: pcf85363: Add support for NXP pcf85263 rtc

[Biju Das]

Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
with pcf85363,except that pcf85363 has additional 64 bytes of RAM.

1 byte of nvmem is supported and exposed in sysfs (# is the instance
number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem

Signed-off-by: Biju Das 
---
V1-->V2
* Incorporated Alexandre and Geert's review comment.
V2-->V3
* Incorporated Geert's review comment.
V3-->V4
* Incorporated Geert's and Alexandre's review comment.
---
 drivers/rtc/rtc-pcf85363.c | 94 +-
 1 file changed, 76 insertions(+), 18 deletions(-)

diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
index c04a1ed..a398807 100644
--- a/drivers/rtc/rtc-pcf85363.c
+++ b/drivers/rtc/rtc-pcf85363.c
@@ -120,6 +120,11 @@ struct pcf85363 {
struct regmap   *regmap;
 };
 
+struct pcf85x63_config {
+   struct regmap_config regmap;
+   unsigned int num_nvram;
+};
+
 static int pcf85363_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
@@ -311,25 +316,75 @@ static int pcf85363_nvram_write(void *priv, unsigned int 
offset, void *val,
 val, bytes);
 }
 
-static const struct regmap_config regmap_config = {
-   .reg_bits = 8,
-   .val_bits = 8,
-   .max_register = 0x7f,
+static int pcf85x63_nvram_read(void *priv, unsigned int offset, void *val,
+  size_t bytes)
+{
+   struct pcf85363 *pcf85363 = priv;
+   unsigned int tmp_val;
+   int ret;
+
+   ret = regmap_read(pcf85363->regmap, CTRL_RAMBYTE, _val);
+   (*(unsigned char *) val) = (unsigned char) tmp_val;
+
+   return ret;
+}
+
+static int pcf85x63_nvram_write(void *priv, unsigned int offset, void *val,
+   size_t bytes)
+{
+   struct pcf85363 *pcf85363 = priv;
+   unsigned char tmp_val;
+
+   tmp_val = *((unsigned char *)val);
+   return regmap_write(pcf85363->regmap, CTRL_RAMBYTE,
+   (unsigned int)tmp_val);
+}
+
+static const struct pcf85x63_config pcf_85263_config = {
+   .regmap = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = 0x2f,
+   },
+   .num_nvram = 1
+};
+
+static const struct pcf85x63_config pcf_85363_config = {
+   .regmap = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = 0x7f,
+   },
+   .num_nvram = 2
 };
 
 static int pcf85363_probe(struct i2c_client *client,
  const struct i2c_device_id *id)
 {
struct pcf85363 *pcf85363;
-   struct nvmem_config nvmem_cfg = {
-   .name = "pcf85363-",
-   .word_size = 1,
-   .stride = 1,
-   .size = NVRAM_SIZE,
-   .reg_read = pcf85363_nvram_read,
-   .reg_write = pcf85363_nvram_write,
+   const struct pcf85x63_config *config = _85363_config;
+   const void *data = of_device_get_match_data(>dev);
+   static struct nvmem_config nvmem_cfg[] = {
+   {
+   .name = "pcf85x63-",
+   .word_size = 1,
+   .stride = 1,
+   .size = 1,
+   .reg_read = pcf85x63_nvram_read,
+   .reg_write = pcf85x63_nvram_write,
+   }, {
+   .name = "pcf85363-",
+   .word_size = 1,
+   .stride = 1,
+   .size = NVRAM_SIZE,
+   .reg_read = pcf85363_nvram_read,
+   .reg_write = pcf85363_nvram_write,
+   },
};
-   int ret;
+   int ret, i;
+
+   if (data)
+   config = data;
 
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
return -ENODEV;
@@ -339,7 +394,7 @@ static int pcf85363_probe(struct i2c_client *client,
if (!pcf85363)
return -ENOMEM;
 
-   pcf85363->regmap = devm_regmap_init_i2c(client, _config);
+   pcf85363->regmap = devm_regmap_init_i2c(client, >regmap);
if (IS_ERR(pcf85363->regmap)) {
dev_err(>dev, "regmap allocation failed\n");
return PTR_ERR(pcf85363->regmap);
@@ -370,15 +425,18 @@ static int pcf85363_probe(struct i2c_client *client,
 
ret = rtc_register_device(pcf85363->rtc);
 
-   nvmem_cfg.priv = pcf85363;
-   rtc_nvmem_register(pcf85363->rtc, _cfg);
+   for (i = 0; i < config->num_nvram; i++) {
+   nvmem_cfg[i].priv = pcf85363;
+   rtc_nvmem_register(pcf85363->rtc, _cfg[i]);
+   }
 
return ret;
 }
 
 static const struct of_device_id dev_ids[] = {
-   { .compatible = "nxp,pcf85363" },
-   {}
+   { .compatible = "nxp,pcf85263", .data = _85263_config },
+   { .compatible = 

[PATCH v4 2/5] dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock

[Biju Das]

The pcf85263 RTC is compatible with the pcf85363 RTC.

The difference between the pcf85263 and pcf85363 RTC is that the latter has
64 bytes more RAM. This renders them incompatible from a DT point of view.

Signed-off-by: Biju Das 
Reviewed-by: Geert Uytterhoeven 
---
V1-->V2
* Incorporated Simon's review comment.
V2-->V3
* No Change.
V3-->V4
* No Change.
---
 Documentation/devicetree/bindings/rtc/pcf85363.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt 
b/Documentation/devicetree/bindings/rtc/pcf85363.txt
index 76fdabc..94adc1c 100644
--- a/Documentation/devicetree/bindings/rtc/pcf85363.txt
+++ b/Documentation/devicetree/bindings/rtc/pcf85363.txt
@@ -1,8 +1,8 @@
-NXP PCF85363 Real Time Clock
+NXP PCF85263/PCF85363 Real Time Clock
 
 
 Required properties:
-- compatible: Should contain "nxp,pcf85363".
+- compatible: Should contain "nxp,pcf85263" or "nxp,pcf85363".
 - reg: I2C address for chip.
 
 Optional properties:
-- 
2.7.4

[PATCH v4 0/5] Add NXP pcf85263 real-time clock support

[Biju Das]

This patch set aims to add support for NXP pcf85263 real-time clock.
pcf85263 rtc is compatible with pcf85363 rtc except that pcf85363 has
64 bytes additional RAM.

1 byte of nvmem is supported in pcf85263 and is exposed through sysfs.

The details of pcf85363 and pcf85263 can be found in the below data sheets.

https://www.nxp.com/docs/en/data-sheet/PCF85363A.pdf

https://www.nxp.com/docs/en/data-sheet/PCF85263A.pdf

This patch is tested against linux-next.

V1-->V2
   * Incorporated simon's review comment for binding patch.
   * Incorporated Geert and Alexandre's review comments.
V2-->V3
   * Incorporated Geert's review comments.
V3-->V4
   * Incorporated Geert and Alexandre's review comments.

Biju Das (5):
  nvmem: check invalid number of bytes in nvmem_device_{read,write}
  dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock
  rtc: pcf85363: Add support for NXP pcf85263 rtc
  ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
  ARM: dts: iwg23s-sbc: Enable RTC

 Documentation/devicetree/bindings/rtc/pcf85363.txt |  4 +-
 arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts  | 18 +
 arch/arm/configs/shmobile_defconfig|  1 +
 drivers/nvmem/core.c   | 26 +-
 drivers/rtc/rtc-pcf85363.c | 94 +-
 5 files changed, 122 insertions(+), 21 deletions(-)

-- 
2.7.4

[PATCH v4 1/5] nvmem: check invalid number of bytes in nvmem_device_{read,write}

[Biju Das]

Add check in nvmem_device_{read,write}()to ensure that nvmem core never
passes an invalid number of bytes.

Signed-off-by: Biju Das 
---
V3-->V4
* New patch.
---
 drivers/nvmem/core.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index d9fd110..db7de33 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -1433,10 +1433,21 @@ int nvmem_device_read(struct nvmem_device *nvmem,
  size_t bytes, void *buf)
 {
int rc;
+   size_t new_bytes;
 
if (!nvmem)
return -EINVAL;
 
+   /* Stop the user from reading */
+   if ((offset >= nvmem->size) || (bytes == 0))
+   return 0;
+
+   if (unlikely(check_add_overflow(bytes, offset, _bytes)))
+   return -EOVERFLOW;
+
+   if (new_bytes > nvmem->size)
+   bytes = nvmem->size - offset;
+
rc = nvmem_reg_read(nvmem, offset, buf, bytes);
 
if (rc)
@@ -1461,16 +1472,29 @@ int nvmem_device_write(struct nvmem_device *nvmem,
   size_t bytes, void *buf)
 {
int rc;
+   size_t new_bytes;
 
if (!nvmem)
return -EINVAL;
 
+   /* Stop the user from writing */
+   if (offset >= nvmem->size)
+   return -ENOSPC;
+
+   if (bytes == 0)
+   return 0;
+
+   if (unlikely(check_add_overflow(bytes, offset, _bytes)))
+   return -EOVERFLOW;
+
+   if (new_bytes > nvmem->size)
+   bytes = nvmem->size - offset;
+
rc = nvmem_reg_write(nvmem, offset, buf, bytes);
 
if (rc)
return rc;
 
-
return bytes;
 }
 EXPORT_SYMBOL_GPL(nvmem_device_write);
-- 
2.7.4

Re: [PATCH 2/5] pwm: rcar: Add support "atomic" API

[Uwe Kleine-König]

Hello,

On Fri, Dec 07, 2018 at 10:57:48AM +0100, Geert Uytterhoeven wrote:
> > Is the documentation for this hardware publically available?
> 
> Please check Section 59 of the "User's Manual: Hardware" at
> https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz/rzg/rzg1m.html

Thanks.

So the ugly things here are:

 a) if the pwm is stopped (PWMCR.ENO = 0) the output is set to high after
completion of the currently running period.
 b) setting a duty_cycle of 0 is forbidden

both are bad. A workaround for both is implementation of something
similar to the switch to a gpio suggested by Michal for imx. But this
cannot be done reliably because the current period's end isn't
observable.

Alternatively a confirmation from the Renesas engineers that PWMCNT.PHO
can be set to 0 with the intended effect despite being forbidden in the
reference manual would be great. Did someone with access to such
hardware test what happens if the PHO field is set to 0? Maybe the
forbidden value is just a wrong copy from the CYCO field?

I think it would be a good idea to add the link to the documentation
into a comment at the top of the driver.

@Thierry: Given that nobody seems to have an overview about the features
and ugly implementation details of all the PWMs, what about documenting
them in the driver files in a greppable way. For the rcar driver
something like:

 - duty-counter-bits: 10
 - period-counter-bits: 10
 - hardware-polarity-support: false
 - uglyness:
   - OUTPUT-ACTIVE-ON-DISABLE
   - NO-ZERO-DUTY-CYCLE

Best regards
Uwe

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

Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc

[Geert Uytterhoeven]

Hi Biju,

On Fri, Dec 7, 2018 at 11:16 AM Biju Das  wrote:
> > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
> > On Fri, Dec 7, 2018 at 10:34 AM Biju Das  wrote:
> > > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > > pcf85263 rtc
> > > > I think it is probably better to ensure the nvmem core never passes
> > > > an invalid number of bytes. All the ther RTC drivers make that
> > assumption.
> > >
> > > In that case, I will do following checks in
> > > nvmem_device_{read,write}() before calling nvmem_reg_{read,write}(),
> > >
> > > nvmem_device_read
> > >
> > > /* Stop the user from reading */
> > > if (offset  >= nvmem->size)
> > > return 0;
> > >
> > > if (bytes == 0)
> > > return -EINVAL;
> >
> > Why not 0?
>
> Ok. Will merge with above check.
>
> if ((offset  >= nvmem->size)  && (bytes == 0))

"||" ;-)

> return 0;

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 v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc

[Biju Das]

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
>
> Hi Biju,
>
> On Fri, Dec 7, 2018 at 10:34 AM Biju Das  wrote:
> > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > pcf85263 rtc
> > >
> > > On 06/12/2018 15:49:57+, Biju Das wrote:
>
> > > > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > > > pcf85263 rtc
>
> > > > > On Thu, Dec 6, 2018 at 4:24 PM Biju Das
> > > > > 
> > > wrote:
> > > > > > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for
> > > > > > > NXP
> > > > > > > pcf85263 rtc CC nvmem maintainer Given bytes should be 1,
> > > > > > > val should be a pointer to a single byte...
> > > > > > > What if bytes == 0?
> > > > > >
> > > > > > I doubt we get "bytes==0" because of the checks in "
> > > > > drivers/nvmem/core.c"
> > > > > > Function " bin_attr_nvmem_read/ bin_attr_nvmem_write".
> > > > >
> > > > > Depends. There are other functions calling
> > > > > nvmem_reg_{read,write}(),
> > > e.g.
> > > > > nvmem_device_{read,write}().
> > > >
> > > > OK. In that case, I will return (-EINVAL)  for "bytes !=1"
> > >
> > > I think it is probably better to ensure the nvmem core never passes
> > > an invalid number of bytes. All the ther RTC drivers make that
> assumption.
> >
> > In that case, I will do following checks in
> > nvmem_device_{read,write}() before calling nvmem_reg_{read,write}(),
> >
> > nvmem_device_read
> >
> > /* Stop the user from reading */
> > if (offset  >= nvmem->size)
> > return 0;
> >
> > if (bytes == 0)
> > return -EINVAL;
>
> Why not 0?

Ok. Will merge with above check.

if ((offset  >= nvmem->size)  && (bytes == 0))
return 0;

> >
> > if (offset + bytes > nvmem->size)
>
> This might overflow, please use check_add_overflow().

Will use check_add_overflow() and then the  result is compared with 
nvmem->size, if the check operation is successful.

> > bytes = nvmem->size - offset;
> >
> > nvmem_device_write
> >
> > /* Stop the user from writing */
> > if (offset  >= nvmem->size)
> > return -EFBIG;
>
> ENOSPC?

OK, Will change it to ENOSPC.

> + same comments as for read.
>
> Oh, and offset is unsigned int instead of loff_t.
> Nobody's envisioning nvmem devices larger than 4 GiB?

Regards,
Biju


[https://www2.renesas.eu/media/email/unicef.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



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

Re: [PATCH 2/5] pwm: rcar: Add support "atomic" API

[Geert Uytterhoeven]

Hi Uwe,

On Fri, Dec 7, 2018 at 10:08 AM Uwe Kleine-König
 wrote:
> On Fri, Dec 07, 2018 at 05:29:30PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds support for "atomic" API. Behavior is the same as
> > when using legacy APIs.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  drivers/pwm/pwm-rcar.c | 32 
> >  1 file changed, 32 insertions(+)
> >
> > diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
> > index 9cf4567..a5ea0f3 100644
> > --- a/drivers/pwm/pwm-rcar.c
> > +++ b/drivers/pwm/pwm-rcar.c
> > @@ -200,12 +200,44 @@ static void rcar_pwm_disable(struct pwm_chip *chip, 
> > struct pwm_device *pwm)
> >   rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
> >  }
> >
> > +static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > +   struct pwm_state *state)
> > +{
> > + struct rcar_pwm_chip *rp = to_rcar_pwm_chip(chip);
> > + int div, ret;
> > +
> > + div = rcar_pwm_get_clock_division(rp, state->period);
> > + if (div < 0)
> > + return div;
> > +
> > + rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
> > +
> > + rcar_pwm_calc_counter(rp, div, state->duty_cycle, state->period);
> > + ret = rcar_pwm_set_counter(rp);
> > + if (!ret)
> > + rcar_pwm_set_clock_control(rp, div);
> > +
> > + /* The SYNC should be set to 0 even if rcar_pwm_set_counter failed */
> > + rcar_pwm_update(rp, RCAR_PWMCR_SYNC, 0, RCAR_PWMCR);
> > +
> > + if (!ret && state->enabled)
> > + ret = rcar_pwm_enable(chip, pwm);
> > +
> > + if (!state->enabled) {
> > + rcar_pwm_disable(chip, pwm);
> > + ret = 0;
> > + }
> > +
> > + return ret;
>
> state->polarity isn't used here which is a bug I think.
>
> Is the documentation for this hardware publically available?

Please check Section 59 of the "User's Manual: Hardware" at
https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz/rzg/rzg1m.html

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

Re: [PATCH 2/4] mtd: spi-nor: Add support for is25lp016d

[Tudor.Ambarus]

On 11/01/2018 02:35 PM, Fabrizio Castro wrote:
> The is25lp016d is found on the iwg23s from iWave, therefore
> add driver support for it so that we can upstream board support.
> 
> Signed-off-by: Fabrizio Castro 

Reviewed-by: Tudor Ambarus 

> ---
>  drivers/mtd/spi-nor/spi-nor.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 9407ca5..85d869b 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1352,6 +1352,8 @@ static const struct flash_info spi_nor_ids[] = {
>   { "is25cd512",  INFO(0x7f9d20, 0, 32 * 1024,   2, SECT_4K) },
>   { "is25lq040b", INFO(0x9d4013, 0, 64 * 1024,   8,
>   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + { "is25lp016d", INFO(0x9d6015, 0, 64 * 1024,  32,
> + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>   { "is25lp080d", INFO(0x9d6014, 0, 64 * 1024,  16,
>   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>   { "is25lp128",  INFO(0x9d6018, 0, 64 * 1024, 256,
> 

RE: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc

[Biju Das]

Hi Alexandre,

Thanks for the feedback.

> Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
>
> On 06/12/2018 15:49:57+, Biju Das wrote:
> > Hi Geert,
> >
> > Thanks for the feedback.
> >
> > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > pcf85263 rtc
> > >
> > > Hi Biju,
> > >
> > > On Thu, Dec 6, 2018 at 4:24 PM Biju Das 
> wrote:
> > > > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > > > pcf85263 rtc CC nvmem maintainer
> > > > >
> > > > > On Thu, Dec 6, 2018 at 10:04 AM Biju Das
> > > > > 
> > > wrote:
> > > > > > Add support for NXP pcf85263 real-time clock. pcf85263 rtc is
> > > > > > compatible with pcf85363,except that pcf85363 has additional
> > > > > > 64 bytes of
> > > > > RAM.
> > >
> > > > > > --- a/drivers/rtc/rtc-pcf85363.c
> > > > > > +++ b/drivers/rtc/rtc-pcf85363.c
> > > > > > @@ -120,6 +120,11 @@ struct pcf85363 {
> > > > > > struct regmap   *regmap;
> > > > > >  };
> > > > > >
> > > > > > +struct pcf85x63_config {
> > > > > > +   struct regmap_config regmap;
> > > > > > +   unsigned int num_nvram; };
> > > > > > +
> > > > > >  static int pcf85363_rtc_read_time(struct device *dev, struct
> > > > > > rtc_time
> > > > > > *tm)  {
> > > > > > struct pcf85363 *pcf85363 = dev_get_drvdata(dev); @@
> > > > > > -311,25
> > > > > > +316,68 @@ static int pcf85363_nvram_write(void *priv,
> > > > > > +unsigned int
> > > > > offset, void *val,
> > > > > >  val, bytes);  }
> > > > > >
> > > > > > -static const struct regmap_config regmap_config = {
> > > > > > -   .reg_bits = 8,
> > > > > > -   .val_bits = 8,
> > > > > > -   .max_register = 0x7f,
> > > > > > +static int pcf85x63_nvram_read(void *priv, unsigned int
> > > > > > +offset, void
> > > *val,
> > > > > > +  size_t bytes)
> > > > >
> > > > > Given bytes should be 1, val should be a pointer to a single byte...
> > > > > What if bytes == 0?
> > > >
> > > > I doubt we get "bytes==0" because of the checks in "
> > > drivers/nvmem/core.c"
> > > > Function " bin_attr_nvmem_read/ bin_attr_nvmem_write".
> > >
> > > Depends. There are other functions calling nvmem_reg_{read,write}(),
> e.g.
> > > nvmem_device_{read,write}().
> >
> > OK. In that case, I will return (-EINVAL)  for "bytes !=1"
> >
>
> I think it is probably better to ensure the nvmem core never passes an invalid
> number of bytes. All the ther RTC drivers make that assumption.

In that case, I will do following checks in nvmem_device_{read,write}() before 
calling nvmem_reg_{read,write}(),

nvmem_device_read

/* Stop the user from reading */
if (offset  >= nvmem->size)
return 0;

if (bytes == 0)
return -EINVAL;

if (offset + bytes > nvmem->size)
bytes = nvmem->size - offset;

nvmem_device_write

/* Stop the user from writing */
if (offset  >= nvmem->size)
return -EFBIG;

if (bytes == 0)
return -EINVAL;

if (offset + bytes > nvmem->size)
bytes = nvmem->size - offset;

regards,
Biju





[https://www2.renesas.eu/media/email/unicef.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



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

Re: [PATCH 5/5] pwm: rcar: add workaround to output "pseudo" low level

[Uwe Kleine-König]

On Fri, Dec 07, 2018 at 05:29:33PM +0900, Yoshihiro Shimoda wrote:
> This PWM Timer cannot output low because setting 0x000 is prohibited
> on PWMCNT.PH0 (High-Level Period) bitfields. So, avoiding
> the prohibited, this patch adds a workaround function to change
> the value from 0 to 1 as pseudo low level.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/pwm/pwm-rcar.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
> index e479b6a..888cb37 100644
> --- a/drivers/pwm/pwm-rcar.c
> +++ b/drivers/pwm/pwm-rcar.c
> @@ -166,6 +166,20 @@ static void rcar_pwm_disable(struct rcar_pwm_chip *rp)
>   rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
>  }
>  
> +static void rcar_pwm_workaround_output_low(struct rcar_pwm_chip *rp)
> +{
> + /*
> +  * This PWM Timer cannot output low because setting 0x000 is
> +  * prohibited on PWMCNT.PH0 (High-Level Period) bitfields. So, avoiding
> +  * the prohibited, this function changes the value from 0 to 1 as
> +  * pseudo low level.
> +  *
> +  * TODO: Add GPIO handling to output low level.
> +  */
> + if ((rp->pwmcnt & RCAR_PWMCNT_PH0_MASK) == 0)
> + rp->pwmcnt |= 1;

In my eyes this is too broken to do. Not sure I have the complete
picture, but given a small period (say 2) this 1 cycle might result in
50 % duty cycle. Depending on how the hardware behaves if you disable
it, better do this instead.

Are you aware of the series adding such gpio support to the imx driver?

@Thierry: So there are three drivers now that could benefit for a
generic approach.

Best regards
Uwe

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

Re: [PATCH 2/5] pwm: rcar: Add support "atomic" API

[Uwe Kleine-König]

Hello,

On Fri, Dec 07, 2018 at 05:29:30PM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for "atomic" API. Behavior is the same as
> when using legacy APIs.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/pwm/pwm-rcar.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
> index 9cf4567..a5ea0f3 100644
> --- a/drivers/pwm/pwm-rcar.c
> +++ b/drivers/pwm/pwm-rcar.c
> @@ -200,12 +200,44 @@ static void rcar_pwm_disable(struct pwm_chip *chip, 
> struct pwm_device *pwm)
>   rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
>  }
>  
> +static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +   struct pwm_state *state)
> +{
> + struct rcar_pwm_chip *rp = to_rcar_pwm_chip(chip);
> + int div, ret;
> +
> + div = rcar_pwm_get_clock_division(rp, state->period);
> + if (div < 0)
> + return div;
> +
> + rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
> +
> + rcar_pwm_calc_counter(rp, div, state->duty_cycle, state->period);
> + ret = rcar_pwm_set_counter(rp);
> + if (!ret)
> + rcar_pwm_set_clock_control(rp, div);
> +
> + /* The SYNC should be set to 0 even if rcar_pwm_set_counter failed */
> + rcar_pwm_update(rp, RCAR_PWMCR_SYNC, 0, RCAR_PWMCR);
> +
> + if (!ret && state->enabled)
> + ret = rcar_pwm_enable(chip, pwm);
> +
> + if (!state->enabled) {
> + rcar_pwm_disable(chip, pwm);
> + ret = 0;
> + }
> +
> + return ret;

state->polarity isn't used here which is a bug I think.

Is the documentation for this hardware publically available?

If the pwm runs at say 30% duty cycle and then pwm_apply is called with

.period = 1000,
.duty_cycle = 600,
.enabled = false,

can it happen that for some time a duty cycle of 60% is provided? If so,
that's a bug.

Out of interest: How does the output behave if you disable the hardware?
Does it give a 0, or high-z?

Best regards
Uwe

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

Re: [PATCH 1/5] pwm: rcar: add rcar_pwm_calc_counter() to calculate PWMCNT value only

[Uwe Kleine-König]

Hello,

On Fri, Dec 07, 2018 at 05:29:29PM +0900, Yoshihiro Shimoda wrote:
> -static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp, int div, int 
> duty_ns,
> - int period_ns)
> +static void rcar_pwm_calc_counter(struct rcar_pwm_chip *rp, int div,
> +   int duty_ns, int period_ns)
>  {
>   unsigned long long one_cycle, tmp;  /* 0.01 nanoseconds */
>   unsigned long clk_rate = clk_get_rate(rp->clk);
> @@ -120,11 +121,17 @@ static int rcar_pwm_set_counter(struct rcar_pwm_chip 
> *rp, int div, int duty_ns,
>   do_div(tmp, one_cycle);
>   ph = tmp & RCAR_PWMCNT_PH0_MASK;
>  
> + rp->pwmcnt = cyc | ph;

Wouldn't it be more natural to let rcar_pwm_calc_counter return cyc | ph
and then ...

> +}
> +
> +static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp)
> +{
>   /* Avoid prohibited setting */
> - if (cyc == 0 || ph == 0)
> + if ((rp->pwmcnt & RCAR_PWMCNT_CYC0_MASK) == 0 ||
> + (rp->pwmcnt & RCAR_PWMCNT_PH0_MASK) == 0)
>   return -EINVAL;
>  
> - rcar_pwm_write(rp, cyc | ph, RCAR_PWMCNT);
> + rcar_pwm_write(rp, rp->pwmcnt, RCAR_PWMCNT);
>  
>   return 0;
>  }
> @@ -159,7 +166,8 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>  
>   rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
>  
> - ret = rcar_pwm_set_counter(rp, div, duty_ns, period_ns);
> + rcar_pwm_calc_counter(rp, div, duty_ns, period_ns);
> + ret = rcar_pwm_set_counter(rp);
>   if (!ret)
>   rcar_pwm_set_clock_control(rp, div);

... pass this value to rcar_pwm_set_counter as u32. (Or pass div,
duty_ns and period_ns to rcar_pwm_set_counter and let this then call
rcar_pwm_calc_counter. Then you don't need a new member in the struct
rcar_pwm_chip.

Best regards
Uwe

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

[PATCH 3/5] pwm: rcar: Use "atomic" API on rcar_pwm_resume()

[Yoshihiro Shimoda]

To remove legacy API related functions in the future, this patch
uses "atomic" related function instead. No change in behavior.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/pwm/pwm-rcar.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index a5ea0f3..1bcb662 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -319,18 +319,16 @@ static int rcar_pwm_suspend(struct device *dev)
 static int rcar_pwm_resume(struct device *dev)
 {
struct pwm_device *pwm = rcar_pwm_dev_to_pwm_dev(dev);
+   struct pwm_state state;
 
if (!test_bit(PWMF_REQUESTED, >flags))
return 0;
 
pm_runtime_get_sync(dev);
 
-   rcar_pwm_config(pwm->chip, pwm, pwm->state.duty_cycle,
-   pwm->state.period);
-   if (pwm_is_enabled(pwm))
-   rcar_pwm_enable(pwm->chip, pwm);
+   pwm_get_state(pwm, );
 
-   return 0;
+   return rcar_pwm_apply(pwm->chip, pwm, );
 }
 #endif /* CONFIG_PM_SLEEP */
 static SIMPLE_DEV_PM_OPS(rcar_pwm_pm_ops, rcar_pwm_suspend, rcar_pwm_resume);
-- 
1.9.1

[PATCH 5/5] pwm: rcar: add workaround to output "pseudo" low level

[Yoshihiro Shimoda]

This PWM Timer cannot output low because setting 0x000 is prohibited
on PWMCNT.PH0 (High-Level Period) bitfields. So, avoiding
the prohibited, this patch adds a workaround function to change
the value from 0 to 1 as pseudo low level.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/pwm/pwm-rcar.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index e479b6a..888cb37 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -166,6 +166,20 @@ static void rcar_pwm_disable(struct rcar_pwm_chip *rp)
rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
 }
 
+static void rcar_pwm_workaround_output_low(struct rcar_pwm_chip *rp)
+{
+   /*
+* This PWM Timer cannot output low because setting 0x000 is
+* prohibited on PWMCNT.PH0 (High-Level Period) bitfields. So, avoiding
+* the prohibited, this function changes the value from 0 to 1 as
+* pseudo low level.
+*
+* TODO: Add GPIO handling to output low level.
+*/
+   if ((rp->pwmcnt & RCAR_PWMCNT_PH0_MASK) == 0)
+   rp->pwmcnt |= 1;
+}
+
 static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
  struct pwm_state *state)
 {
@@ -179,6 +193,7 @@ static int rcar_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
 
rcar_pwm_calc_counter(rp, div, state->duty_cycle, state->period);
+   rcar_pwm_workaround_output_low(rp);
ret = rcar_pwm_set_counter(rp);
if (!ret)
rcar_pwm_set_clock_control(rp, div);
-- 
1.9.1

[PATCH 2/5] pwm: rcar: Add support "atomic" API

[Yoshihiro Shimoda]

This patch adds support for "atomic" API. Behavior is the same as
when using legacy APIs.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/pwm/pwm-rcar.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 9cf4567..a5ea0f3 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -200,12 +200,44 @@ static void rcar_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
rcar_pwm_update(rp, RCAR_PWMCR_EN0, 0, RCAR_PWMCR);
 }
 
+static int rcar_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct rcar_pwm_chip *rp = to_rcar_pwm_chip(chip);
+   int div, ret;
+
+   div = rcar_pwm_get_clock_division(rp, state->period);
+   if (div < 0)
+   return div;
+
+   rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
+
+   rcar_pwm_calc_counter(rp, div, state->duty_cycle, state->period);
+   ret = rcar_pwm_set_counter(rp);
+   if (!ret)
+   rcar_pwm_set_clock_control(rp, div);
+
+   /* The SYNC should be set to 0 even if rcar_pwm_set_counter failed */
+   rcar_pwm_update(rp, RCAR_PWMCR_SYNC, 0, RCAR_PWMCR);
+
+   if (!ret && state->enabled)
+   ret = rcar_pwm_enable(chip, pwm);
+
+   if (!state->enabled) {
+   rcar_pwm_disable(chip, pwm);
+   ret = 0;
+   }
+
+   return ret;
+}
+
 static const struct pwm_ops rcar_pwm_ops = {
.request = rcar_pwm_request,
.free = rcar_pwm_free,
.config = rcar_pwm_config,
.enable = rcar_pwm_enable,
.disable = rcar_pwm_disable,
+   .apply = rcar_pwm_apply,
.owner = THIS_MODULE,
 };
 
-- 
1.9.1

[PATCH 1/5] pwm: rcar: add rcar_pwm_calc_counter() to calculate PWMCNT value only

[Yoshihiro Shimoda]

To add a workaround in the future, this patch adds a function
rcar_pwm_calc_counter() from rcar_pwm_set_counter().
The rcar_pwm_calc_counter() calculates PWMCNT value only, and
rcar_pwm_set_counter() set the PWMCNT register by using
the calculated value. No change in behavior.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/pwm/pwm-rcar.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index a41812f..9cf4567 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -36,6 +36,7 @@ struct rcar_pwm_chip {
struct pwm_chip chip;
void __iomem *base;
struct clk *clk;
+   u32 pwmcnt;
 };
 
 static inline struct rcar_pwm_chip *to_rcar_pwm_chip(struct pwm_chip *chip)
@@ -102,8 +103,8 @@ static void rcar_pwm_set_clock_control(struct rcar_pwm_chip 
*rp,
rcar_pwm_write(rp, value, RCAR_PWMCR);
 }
 
-static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp, int div, int duty_ns,
-   int period_ns)
+static void rcar_pwm_calc_counter(struct rcar_pwm_chip *rp, int div,
+ int duty_ns, int period_ns)
 {
unsigned long long one_cycle, tmp;  /* 0.01 nanoseconds */
unsigned long clk_rate = clk_get_rate(rp->clk);
@@ -120,11 +121,17 @@ static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp, 
int div, int duty_ns,
do_div(tmp, one_cycle);
ph = tmp & RCAR_PWMCNT_PH0_MASK;
 
+   rp->pwmcnt = cyc | ph;
+}
+
+static int rcar_pwm_set_counter(struct rcar_pwm_chip *rp)
+{
/* Avoid prohibited setting */
-   if (cyc == 0 || ph == 0)
+   if ((rp->pwmcnt & RCAR_PWMCNT_CYC0_MASK) == 0 ||
+   (rp->pwmcnt & RCAR_PWMCNT_PH0_MASK) == 0)
return -EINVAL;
 
-   rcar_pwm_write(rp, cyc | ph, RCAR_PWMCNT);
+   rcar_pwm_write(rp, rp->pwmcnt, RCAR_PWMCNT);
 
return 0;
 }
@@ -159,7 +166,8 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
 
-   ret = rcar_pwm_set_counter(rp, div, duty_ns, period_ns);
+   rcar_pwm_calc_counter(rp, div, duty_ns, period_ns);
+   ret = rcar_pwm_set_counter(rp);
if (!ret)
rcar_pwm_set_clock_control(rp, div);
 
-- 
1.9.1

[PATCH 0/5] pwm: rcar: Add support "atomic" API and workaround

[Yoshihiro Shimoda]

This patch adds support for PWM "atomic" API.

This patch also adds a workaround to output "pseudo" low level.
Otherwise, the PWM backlight driver doesn't work correctly, especially
it cannot output maximum brightness actually.

Yoshihiro Shimoda (5):
  pwm: rcar: add rcar_pwm_calc_counter() to calculate PWMCNT value only
  pwm: rcar: Add support "atomic" API
  pwm: rcar: Use "atomic" API on rcar_pwm_resume()
  pwm: rcar: remove legacy APIs
  pwm: rcar: add workaround to output "pseudo" low level

 drivers/pwm/pwm-rcar.c | 108 -
 1 file changed, 62 insertions(+), 46 deletions(-)

-- 
1.9.1

Re: [PATCH 2/3] arm64: defconfig: Enable scu-simple-card driver

[Geert Uytterhoeven]

Hi Simon,

On Thu, Dec 6, 2018 at 10:58 PM Simon Horman  wrote:
> Enable the scu-simple-card which is used by
> the R-Car E3 (r8a77990) based Ebisu board.
>
> Signed-off-by: Simon Horman 
> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index f88190463481..9d0b42d96f03 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -491,6 +491,7 @@ CONFIG_SND_SOC_RT5514=m
>  CONFIG_SND_SOC_RT5514_SPI=m
>  CONFIG_SND_SOC_RT5645=m
>  CONFIG_SND_SIMPLE_CARD=m
> +CONFIG_SND_SIMPLE_SCU_CARD=y

Shouldn't this be "m"?

>  CONFIG_SND_AUDIO_GRAPH_CARD=m
>  CONFIG_I2C_HID=m
>  CONFIG_USB=y

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: phandles using absolute paths in DT overlays

[Geert Uytterhoeven]

Hi David,

Thanks for your answer!

On Fri, Dec 7, 2018 at 2:44 AM David Gibson  wrote:
> On Thu, Dec 06, 2018 at 01:56:45PM +0100, Geert Uytterhoeven wrote:
> > Some early revisions of SoCs may have hardware bugs that need to be
> > fixed up in DT.  Currently we are handling this by including DTS files
> > and fixing up nodes and properties, to create different DTB files for
> > different SoC revisons (see arch/arm64/boot/dts/renesas/*es1*).
> >
> > As an alternative, I'm envisioning the use of DT overlays and the
> > fdtoverlay tool, in the hope of simplifying the generation of DTBs for
> > the various SoC/board combinations.
> >
> > Ideally, such DTBs would not contain symbols, to avoid inflating DTB
> > size.  Hence if fixup overlays would not contain symbolic references,
> > there would be no need for symbols.
> >
> > For anchors, the "&{/path/to/node@address}" syntax is working fine.
> > For phandles, while documented on
> > https://elinux.org/Device_Tree_Mysteries, and while working fine for the
> > non-overlay case, dtc seems to have issues interpreting the DTB:
> >
> > $ scripts/dtc/dtc -I dtb -O dts my.dtb  | less
> > : ERROR (property_name_chars):
> > /__fixups__:/path/to/node@deadbeef: Bad character '/' in property
> > name
> > ERROR: Input tree has errors, aborting (use -f to force output)
> >
> > With -f, the fixup generated seems to contain the expected value, though:
> >
> > __fixups__ {
> > /path/to/node@deadbeef = "/fragment@0/__overlay__:power-domains:0";
> > };
> >
> > When using ftdoverlay, the situation is worse:
> >
> > Failed to apply my.dtb (-1)
> >
> > Are these known issues?
>
> Unfortunately, this can't work with the current overlay format.  We
> have a specific syntax to allow the target of an overlay fragment to
> specified as a path, but phandle references by path won't work.
>
> The problem is that the encoding of the fixups node has the fixup
> target as a property name, and as the error says '/' is an illegal
> character in property names - for a bunch of good reasons, so we can't
> just go and remove that restriction.

For the uneducated, can you please explain why '/' is an illegal character,
and why it can't be special cased for phandle references by path in overlays?

> So to allow this we'd need to come up with a different encoding for
> path-targeted fixups and add support for it in the various pieces of
> the chain.
>
> One way to do that would be to entirely rework the overlay format to
> something more sensible, which would have a number of other benefits.

IC.

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