Re: [PATCH] i2c: mvtwsi: Add support for DM clocks and resets

[Heiko Schocher]

Hello Samuel,

On 12.09.21 17:21, Samuel Holland wrote:
> The controller may need to have clocks/resets enabled for it to work.
> Add support for this. Since the clocks/resets are optional on some
> platforms (per the device tree binding), do not prevent probing the
> controller if they are missing.
> 
> Signed-off-by: Samuel Holland 
> ---
> 
>  drivers/i2c/mvtwsi.c | 13 +
>  1 file changed, 13 insertions(+)

Reviewed-by: Heiko Schocher 

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH] i2c: rcar_i2c: Enable configuring SCL rise and fall times

[Marek Vasut]

On 9/21/21 6:13 AM, Heiko Schocher wrote:

Hello Adam,

On 20.09.21 14:21, Adam Ford wrote:

On Tue, Aug 24, 2021 at 9:10 AM Adam Ford  wrote:


The Linux i2c driver supports i2c-scl-rising-time-ns,
and i2c-scl-falling-time-ns, but U-Boot uses hard-coded values
for these values.

Update the calculation by fetching them from the device tree if
present and use the previous values as the default if they are
missing.

Signed-off-by: Adam Ford 


Do I have the right people in copy?  I was hoping to get some feedback
on this.  My boards use the i2c-scl-rising-time-ns to help properly
set the i2c clocking.


No, I think all fine, for me the patch is okay, so:

Reviewed-by: Heiko Schocher 

Ah, I see, in patchwork the patch is assigned to Marek... added Marek
to cc.

@Marek: Is it okay for you, if I pickup the patch, when new u-boot
version is out? Else you can pick it up.


Looks good, pick it for next please.

Re: [PATCH] i2c: rcar_i2c: Enable configuring SCL rise and fall times

[Heiko Schocher]

Hello Adam,

On 20.09.21 14:21, Adam Ford wrote:
> On Tue, Aug 24, 2021 at 9:10 AM Adam Ford  wrote:
>>
>> The Linux i2c driver supports i2c-scl-rising-time-ns,
>> and i2c-scl-falling-time-ns, but U-Boot uses hard-coded values
>> for these values.
>>
>> Update the calculation by fetching them from the device tree if
>> present and use the previous values as the default if they are
>> missing.
>>
>> Signed-off-by: Adam Ford 
>>
> Do I have the right people in copy?  I was hoping to get some feedback
> on this.  My boards use the i2c-scl-rising-time-ns to help properly
> set the i2c clocking.

No, I think all fine, for me the patch is okay, so:

Reviewed-by: Heiko Schocher 

Ah, I see, in patchwork the patch is assigned to Marek... added Marek
to cc.

@Marek: Is it okay for you, if I pickup the patch, when new u-boot
version is out? Else you can pick it up.

Thanks!

bye,
Heiko
> 
> thanks
> adam
> 
>> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
>> index 14bb6603d5..d9ece5e3a8 100644
>> --- a/drivers/i2c/rcar_i2c.c
>> +++ b/drivers/i2c/rcar_i2c.c
>> @@ -64,6 +64,8 @@ enum rcar_i2c_type {
>>  struct rcar_i2c_priv {
>> void __iomem*base;
>> struct clk  clk;
>> +   u32 fall_ns;
>> +   u32 rise_ns;
>> u32 intdelay;
>> u32 icccr;
>> enum rcar_i2c_type  type;
>> @@ -278,7 +280,7 @@ static int rcar_i2c_set_speed(struct udevice *dev, uint 
>> bus_freq_hz)
>>  *  = F[sum * ick / 10]
>>  *  = F[(ick / 100) * sum / 1000]
>>  */
>> -   sum = 35 + 200 + priv->intdelay;
>> +   sum = priv->fall_ns + priv->rise_ns + priv->intdelay;
>> round = (ick + 50) / 100 * sum;
>> round = (round + 500) / 1000;
>>
>> @@ -323,6 +325,10 @@ static int rcar_i2c_probe(struct udevice *dev)
>> int ret;
>>
>> priv->base = dev_read_addr_ptr(dev);
>> +   priv->rise_ns = dev_read_u32_default(dev,
>> +"i2c-scl-rising-time-ns", 200);
>> +   priv->fall_ns = dev_read_u32_default(dev,
>> +"i2c-scl-falling-time-ns", 35);
>> priv->intdelay = dev_read_u32_default(dev,
>>   "i2c-scl-internal-delay-ns", 
>> 5);
>> priv->type = dev_get_driver_data(dev);
>> --
>> 2.25.1
>>

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH 2/3] dt-bindings: pwm: pwm-at91: Add PWM bindings for A5D2

[Dan Sneddon]

Document the bindings needed for the PWM device on the SAMA5D2.

Signed-off-by: Dan Sneddon 
---
 doc/device-tree-bindings/pwm/pwm-at91.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 doc/device-tree-bindings/pwm/pwm-at91.txt

diff --git a/doc/device-tree-bindings/pwm/pwm-at91.txt 
b/doc/device-tree-bindings/pwm/pwm-at91.txt
new file mode 100644
index 00..a03da404f5
--- /dev/null
+++ b/doc/device-tree-bindings/pwm/pwm-at91.txt
@@ -0,0 +1,16 @@
+Microchip AT91 PWM controller for SAMA5D2
+
+Required properties:
+  - compatible: Should be "atmel,sama5d2-pwm"
+  - reg: Physical base address and length of the controller's registers.
+  - clocks: Should contain a clock identifier for the PWM's parent clock.
+  - #pwm-cells: Should be 3.
+
+Example:
+
+pwm0: pwm@f802c000 {
+   compatible = "atmel,sama5d2-pwm";
+   reg = <0xf802c000 0x4000>;
+   clocks = <_clk>;
+   #pwm-cells = <3>;
+};
-- 
2.17.1

[PATCH 1/3] pwm: Add PWM driver for SAMA5D2

[Dan Sneddon]

Add support for the PWM found on the SAMA5D2 family of devices.

Signed-off-by: Dan Sneddon 
---
 drivers/pwm/Kconfig|   6 ++
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-at91.c | 207 +
 3 files changed, 214 insertions(+)
 create mode 100644 drivers/pwm/pwm-at91.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index cf7f4c6840..691bbcd469 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -91,3 +91,9 @@ config PWM_TI_EHRPWM
default y
help
  PWM driver support for the EHRPWM controller found on TI SOCs.
+
+config PWM_AT91
+   bool "Enable support for PWM found on AT91 SoC's"
+   depends on DM_PWM && ARCH_AT91
+   help
+ Support for PWM hardware on AT91 based SoC.
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 10d244bfb7..6cdcbdb996 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_PWM_SIFIVE)  += pwm-sifive.o
 obj-$(CONFIG_PWM_TEGRA)+= tegra_pwm.o
 obj-$(CONFIG_PWM_SUNXI)+= sunxi_pwm.o
 obj-$(CONFIG_PWM_TI_EHRPWM)+= pwm-ti-ehrpwm.o
+obj-$(CONFIG_PWM_AT91) += pwm-at91.o
diff --git a/drivers/pwm/pwm-at91.c b/drivers/pwm/pwm-at91.c
new file mode 100644
index 00..95597aee55
--- /dev/null
+++ b/drivers/pwm/pwm-at91.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * PWM support for Microchip AT91 architectures.
+ *
+ * Copyright (C) 2021 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Dan Sneddon 
+ *
+ * Based on drivers/pwm/pwm-atmel.c from Linux.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PERIOD_BITS 16
+#define PWM_MAX_PRES 10
+#define NSEC_PER_SEC 10L
+
+#define PWM_ENA 0x04
+#define PWM_CHANNEL_OFFSET 0x20
+#define PWM_CMR 0x200
+#define PWM_CMR_CPRE_MSK GENMASK(3, 0)
+#define PWM_CMR_CPOL BIT(9)
+#define PWM_CDTY 0x204
+#define PWM_CPRD 0x20C
+
+struct at91_pwm_priv {
+   void __iomem *base;
+   struct clk pclk;
+   u32 clkrate;
+};
+
+static int at91_pwm_calculate_cprd_and_pres(struct udevice *dev,
+   unsigned long clkrate,
+   uint period_ns, uint duty_ns,
+   unsigned long *cprd, u32 *pres)
+{
+   u64 cycles = period_ns;
+   int shift;
+
+   /* Calculate the period cycles and prescale value */
+   cycles *= clkrate;
+   do_div(cycles, NSEC_PER_SEC);
+
+   /*
+* The register for the period length is period_bits bits wide.
+* So for each bit the number of clock cycles is wider divide the input
+* clock frequency by two using pres and shift cprd accordingly.
+*/
+   shift = fls(cycles) - PERIOD_BITS;
+
+   if (shift > PWM_MAX_PRES) {
+   return -EINVAL;
+   } else if (shift > 0) {
+   *pres = shift;
+   cycles >>= *pres;
+   } else {
+   *pres = 0;
+   }
+
+   *cprd = cycles;
+
+   return 0;
+}
+
+static void at91_pwm_calculate_cdty(uint period_ns, uint duty_ns,
+   unsigned long clkrate, unsigned long cprd,
+u32 pres, unsigned long *cdty)
+{
+   u64 cycles = duty_ns;
+
+   cycles *= clkrate;
+   do_div(cycles, NSEC_PER_SEC);
+   cycles >>= pres;
+   *cdty = cprd - cycles;
+}
+
+/**
+ * Returns: channel status after set operation
+ */
+static bool at91_pwm_set(void __iomem *base, uint channel, bool enable)
+{
+   u32 val, cur_status;
+
+   val = ioread32(base + PWM_ENA);
+   cur_status = !!(val & BIT(channel));
+
+   /* if channel is already in that state, do nothing */
+   if (!(enable ^ cur_status))
+   return cur_status;
+
+   if (enable)
+   val |= BIT(channel);
+   else
+   val &= ~(BIT(channel));
+
+   iowrite32(val, base + PWM_ENA);
+
+   return cur_status;
+}
+
+static int at91_pwm_set_enable(struct udevice *dev, uint channel, bool enable)
+{
+   struct at91_pwm_priv *priv = dev_get_priv(dev);
+
+   at91_pwm_set(priv->base, channel, enable);
+
+   return 0;
+}
+
+static int at91_pwm_set_config(struct udevice *dev, uint channel,
+  uint period_ns, uint duty_ns)
+{
+   struct at91_pwm_priv *priv = dev_get_priv(dev);
+   unsigned long cprd, cdty;
+   u32 pres, val;
+   int channel_enabled;
+   int ret;
+
+   ret = at91_pwm_calculate_cprd_and_pres(dev, priv->clkrate, period_ns,
+  duty_ns, , );
+   if (ret)
+   return ret;
+
+   at91_pwm_calculate_cdty(period_ns, duty_ns, priv->clkrate, cprd, pres, 
);
+
+   /* disable the channel */
+   channel_enabled = at91_pwm_set(priv->base, channel, false);
+
+   /* It is necessary to preserve CPOL, 

[PATCH 3/3] ARM:dts: sama5d2: Add pwm definition

[Dan Sneddon]

Add the PWM on the SAMA5D2.

Signed-off-by: Dan Sneddon 
---
 arch/arm/dts/sama5d2.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/sama5d2.dtsi b/arch/arm/dts/sama5d2.dtsi
index 6fb2cb25f9..ba1b69e629 100644
--- a/arch/arm/dts/sama5d2.dtsi
+++ b/arch/arm/dts/sama5d2.dtsi
@@ -671,6 +671,14 @@
status = "disabled";
};
 
+   pwm0: pwm@f802c000 {
+   compatible = "atmel,sama5d2-pwm";
+   reg = <0xf802c000 0x4000>;
+   clocks = <_clk>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
rstc@f8048000 {
compatible = "atmel,sama5d3-rstc";
reg = <0xf8048000 0x10>;
-- 
2.17.1

[PATCH 0/3] Add SAMA5D2 PWM Support

[Dan Sneddon]

Add support for the PWM found on SAMA5D2 SoCs.

Dan Sneddon (3):
  pwm: Add PWM driver for SAMA5D2
  dt-bindings: pwm: pwm-at91: Add PWM bindings for A5D2
  ARM:dts: sama5d2: Add pwm definition

 arch/arm/dts/sama5d2.dtsi |   8 +
 doc/device-tree-bindings/pwm/pwm-at91.txt |  16 ++
 drivers/pwm/Kconfig   |   6 +
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-at91.c| 207 ++
 5 files changed, 238 insertions(+)
 create mode 100644 doc/device-tree-bindings/pwm/pwm-at91.txt
 create mode 100644 drivers/pwm/pwm-at91.c

-- 
2.17.1

[PATCH] rtc: ds1307: Handle oscillator-stop bit correctly

[Mark Tomlinson]

The DS1307 driver was originally based on the DS1337 driver. However,
the functionality of the clock set/get functions has diverged. In the
original DS1337 driver, the set/get functions did the following:
  1) Setting the clock ensured the oscillator was enabled.
  2) Getting the clock checked and reset the oscillator-stop flag.
The DS1307 does not have and oscillator-stop flag, but the driver tried
(incorrectly) to emulate this by ensuring the oscillator was running. It
really makes no sense to start a stopped clock without setting it.

This patch makes the DS1307 driver behave like the original DS1337
driver again. For the DS1307 itself, this is just a removal of code,
since there is no oscillator-fail bit to check or reset, and the clock
is started when it is set. Since the DS1307 driver can now also be used
for the DS1337 and DS1340 which do have this bit, add code to handle the
oscillator-stop bit in the same was the original DS1337 driver did --
i.e. report that the oscillator had stopped and clear the flag.

This means that setting the date using the date command (which does both
a get and a set) will now clear the oscillator-stop flag in addition to
setting and starting the clock.

The old-style (non-DM) code has also been updated. Note that this does
not support the DS1337, as there is a separate driver for this. Also
note that the original (DM) code used the wrong control-register address
for the DS1337.

Signed-off-by: Mark Tomlinson 
---
Note that this patch is based on 'next' rather than 'master' as it is
dependent on a patch which has not yet made it to master.

 drivers/rtc/ds1307.c | 106 ---
 1 file changed, 29 insertions(+), 77 deletions(-)

diff --git a/drivers/rtc/ds1307.c b/drivers/rtc/ds1307.c
index 3be97c9d93..7fe4f590c5 100644
--- a/drivers/rtc/ds1307.c
+++ b/drivers/rtc/ds1307.c
@@ -41,6 +41,12 @@ enum ds_type {
 #define RTC_YR_REG_ADDR0x06
 #define RTC_CTL_REG_ADDR   0x07
 
+#define DS1337_CTL_REG_ADDR0x0e
+#define DS1337_STAT_REG_ADDR   0x0f
+#define DS1340_STAT_REG_ADDR   0x09
+
+#define RTC_STAT_BIT_OSF   0x80
+
 #define RTC_SEC_BIT_CH 0x80/* Clock Halt (in Register 0)   */
 
 /* DS1307-specific bits */
@@ -92,10 +98,10 @@ int rtc_get (struct rtc_time *tmp)
 {
int rel = 0;
uchar sec, min, hour, mday, wday, mon, year;
-
-#ifdef CONFIG_RTC_MCP79411
-read_rtc:
+#ifdef CONFIG_RTC_DS1340
+   uchar status;
 #endif
+
sec = rtc_read (RTC_SEC_REG_ADDR);
min = rtc_read (RTC_MIN_REG_ADDR);
hour = rtc_read (RTC_HR_REG_ADDR);
@@ -108,32 +114,16 @@ read_rtc:
"hr: %02x min: %02x sec: %02x\n",
year, mon, mday, wday, hour, min, sec);
 
-#ifdef CONFIG_RTC_DS1307
-   if (sec & RTC_SEC_BIT_CH) {
-   printf ("### Warning: RTC oscillator has stopped\n");
-   /* clear the CH flag */
-   rtc_write (RTC_SEC_REG_ADDR,
-  rtc_read (RTC_SEC_REG_ADDR) & ~RTC_SEC_BIT_CH);
+#ifdef CONFIG_RTC_DS1340
+   status = rtc_read (DS1340_STAT_REG_ADDR);
+   if (status & RTC_STAT_BIT_OSF) {
+   printf("### Warning: RTC oscillator has stopped\n");
+   /* clear the OSF flag */
+   rtc_write (DS1340_STAT_REG_ADDR, status & ~RTC_STAT_BIT_OSF);
rel = -1;
}
 #endif
 
-#ifdef CONFIG_RTC_MCP79411
-   /* make sure that the backup battery is enabled */
-   if (!(wday & MCP7941X_BIT_VBATEN)) {
-   rtc_write(RTC_DAY_REG_ADDR,
- wday | MCP7941X_BIT_VBATEN);
-   }
-
-   /* clock halted?  turn it on, so clock can tick. */
-   if (!(sec & MCP7941X_BIT_ST)) {
-   rtc_write(RTC_SEC_REG_ADDR, MCP7941X_BIT_ST);
-   printf("Started RTC\n");
-   goto read_rtc;
-   }
-#endif
-
-
tmp->tm_sec  = bcd2bin (sec & 0x7F);
tmp->tm_min  = bcd2bin (min & 0x7F);
tmp->tm_hour = bcd2bin (hour & 0x3F);
@@ -248,6 +238,11 @@ static int ds1307_rtc_set(struct udevice *dev, const 
struct rtc_time *tm)
if (ret < 0)
return ret;
 
+   if (type == ds_1337) {
+   /* Ensure oscillator is enabled */
+   dm_i2c_reg_write(dev, DS1337_CTL_REG_ADDR, 0);
+   }
+
return 0;
 }
 
@@ -257,62 +252,19 @@ static int ds1307_rtc_get(struct udevice *dev, struct 
rtc_time *tm)
uchar buf[7];
enum ds_type type = dev_get_driver_data(dev);
 
-read_rtc:
ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
if (ret < 0)
return ret;
 
-   if (type == ds_1307) {
-   if (buf[RTC_SEC_REG_ADDR] & RTC_SEC_BIT_CH) {
-   printf("### Warning: RTC oscillator has stopped\n");
-   /* clear the CH flag */
-   buf[RTC_SEC_REG_ADDR] &= ~RTC_SEC_BIT_CH;
-   dm_i2c_reg_write(dev, RTC_SEC_REG_ADDR,
-

Re: [PATCH] reboot-mode: migrate uclass to livetree

[Simon Glass]

On Mon, 20 Sept 2021 at 10:27, Patrick Delaunay
 wrote:
>
> Use dev_ function to support a live tree.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  drivers/reboot-mode/reboot-mode-uclass.c | 20 ++--
>  1 file changed, 6 insertions(+), 14 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH] remoteproc: migrate uclass to livetree

[Simon Glass]

On Mon, 20 Sept 2021 at 09:56, Patrick Delaunay
 wrote:
>
> Use dev_ function to read the name and boolean to support a live tree.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  drivers/remoteproc/rproc-uclass.c | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH] demo: migrate uclass to livetree

[Simon Glass]

On Mon, 20 Sept 2021 at 09:58, Patrick Delaunay
 wrote:
>
> Use dev_ function to read the sides and colour to support a live tree.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  drivers/demo/demo-uclass.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

[Simon Glass]

Hi Mark,

On Mon, 20 Sept 2021 at 02:49, Mark Kettenis  wrote:
>
> > From: Simon Glass 
> > Date: Sun, 19 Sep 2021 21:15:57 -0600
> >
> > Hi Mark,
> >
> > On Sat, 18 Sept 2021 at 07:55, Mark Kettenis  wrote:
> > >
> > > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > > Macs.  This builds a basic U-Boot that can be used as a payload
> > > for the m1n1 boot loader being developed by the Asahi Linux
> > > project.
> > >
> > > Signed-off-by: Mark Kettenis 
> > > ---
> > >  arch/arm/Kconfig|  22 
> > >  arch/arm/Makefile   |   1 +
> > >  arch/arm/mach-apple/Kconfig |  18 
> > >  arch/arm/mach-apple/Makefile|   4 +
> > >  arch/arm/mach-apple/board.c | 158 
> > >  arch/arm/mach-apple/lowlevel_init.S |  16 +++
> > >  configs/apple_m1_defconfig  |  14 +++
> > >  include/configs/apple.h |  38 +++
> > >  8 files changed, 271 insertions(+)
> > >  create mode 100644 arch/arm/mach-apple/Kconfig
> > >  create mode 100644 arch/arm/mach-apple/Makefile
> > >  create mode 100644 arch/arm/mach-apple/board.c
> > >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> > >  create mode 100644 configs/apple_m1_defconfig
> > >  create mode 100644 include/configs/apple.h
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index b5bd3284cd..7cdea1f615 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -895,6 +895,26 @@ config ARCH_NEXELL
> > > select DM
> > > select GPIO_EXTRA_HEADER
> > >
> > > +config ARCH_APPLE
> > > +   bool "Apple SoCs"
> > > +   select ARM64
> > > +   select LINUX_KERNEL_IMAGE_HEADER
> > > +   select POSITION_INDEPENDENT
> > > +   select BLK
> > > +   select DM
> > > +   select DM_KEYBOARD
> > > +   select DM_SERIAL
> > > +   select DM_USB
> > > +   select DM_VIDEO
> > > +   select CMD_USB
> > > +   select MISC
> > > +   select OF_CONTROL
> > > +   select OF_BOARD
> > > +   select USB
> > > +   imply CMD_DM
> > > +   imply CMD_GPT
> > > +   imply DISTRO_DEFAULTS
> >
> > Suggest sorting these
>
> As in sort all the selects alphabetically and sort all the implies
> alphabetically seperately?

I suppose so.

>
> Does my use of impy here even make sense?

It allows people to disable it, whereas select does not. It looks OK to me.

>
> This whole Kconfig stuff is a bit alien to me and I must say that it
> isn't obvious what "best-practice" is in this area...

We try to avoid select so only use it if it really cannot build/run
without that feature. From what I can tell you have done that.

I know this is a different project, but there are some ideas here:

https://docs.zephyrproject.org/1.14.0/guides/kconfig/index.html

[..]

> > > +int dram_init(void)
> > > +{
> > > +   int index, node, ret;
> > > +   fdt_addr_t base;
> > > +   fdt_size_t size;
> > > +
> > > +   ret = fdtdec_setup_mem_size_base();
> > > +   if (ret)
> > > +   return ret;
> > > +
> > > +   /* Update RAM mapping. */
> >
> > Do you want the period at the end of that?
>
> Given that Bin brought up the same thing, I gather that not having a
> full stop at the end of single-line comments is preferred?

Yes, the periods just clutter things and people start adding them only
when it is a valid sentence, etc. Best to just leave them out.

>
> > > +   index = ARRAY_SIZE(apple_mem_map) - 3;
> > > +   apple_mem_map[index].virt = gd->ram_base;
> > > +   apple_mem_map[index].phys = gd->ram_base;
> > > +   apple_mem_map[index].size = gd->ram_size;
> > > +
> > > +   node = fdt_path_offset(gd->fdt_blob, "/chosen/framebuffer");
> >
> > Can you use the ofnode interface here and below?
>
> I can try...

Something like:

ofnode node;

node = ofnode_path("/chosen/framebuffer");

then use ofnode_get_addr_size()

>
> > > +   if (node < 0)
> > > +   return 0;
> > > +
> > > +   base = fdtdec_get_addr_size(gd->fdt_blob, node, "reg", );
> > > +   if (base == FDT_ADDR_T_NONE)
> > > +   return 0;
> > > +
> > > +   /* Add framebuffer mapping. */
> > > +   index = ARRAY_SIZE(apple_mem_map) - 2;
> > > +   apple_mem_map[index].virt = base;
> > > +   apple_mem_map[index].phys = base;
> > > +   apple_mem_map[index].size = size;
> > > +   apple_mem_map[index].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL_NC) |
> > > +   PTE_BLOCK_INNER_SHARE | PTE_BLOCK_PXN | PTE_BLOCK_UXN;
> > > +
> > > +   return 0;
> > > +}

[..]

> > > diff --git a/arch/arm/mach-apple/lowlevel_init.S 
> > > b/arch/arm/mach-apple/lowlevel_init.S
> > > new file mode 100644
> > > index 00..0f5313163e
> > > --- /dev/null
> > > +++ b/arch/arm/mach-apple/lowlevel_init.S
> > > @@ -0,0 +1,16 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * (C) Copyright 2021 Mark Kettenis 
> > > + */
> > > +
> > > +.align 8
> 

Re: [PATCH] Makefile: Add a warning about ad-hoc CONFIG options

[Simon Glass]

Hi Tom,

On Mon, 20 Sept 2021 at 09:20, Tom Rini  wrote:
>
> On Sat, Sep 18, 2021 at 12:21:21PM -0600, Simon Glass wrote:
>
> > The Kconfig feature was added in 2014. Some 7 years later there are still
> > quite a few CONFIG options that have not been migrated. It is time to
> > close this out.
> >
> > Add a deadline and a warning for boards to migrate to Kconfig.
> >
> > Signed-off-by: Simon Glass 
>
> I agree with the sentiment.  But we aren't at the point where even aside
> from environment and a few outstanding migrations I've posted but not
> yet pulled, that any platform is 100% clean.  There's still even
> migrated-but-in-config.h symbols seemingly everywhere.

Indeed!

So perhaps the trigger for this would be to have one board that
doesn't have a config.h ?

Regards,
Simon

Re: [PATCH 3/5] misc: Add Apple DART driver

[Simon Glass]

Hi Mark,

On Mon, 20 Sept 2021 at 02:33, Mark Kettenis  wrote:
>
> > From: Simon Glass 
> > Date: Sun, 19 Sep 2021 21:16:00 -0600
> >
> > Hi Mark,
> >
> > On Sat, 18 Sept 2021 at 07:55, Mark Kettenis  wrote:
> > >
> > > The DART is an IOMMU that is used on Apple's M1 SoC.  This driver
> > > supports the DART in bypass mode as well as in a mode where it
> > > creates a 1:1 mapping of a subset of RAM as not all DARTs support
> > > bypass mode.  The USB3 ports integrated on the SoC use a DART
> > > that supports bypass mode.  The 1:1 mapping will be used in the
> > > future to support other devices such as the PCIe host bridge
> > > of the M1 SoC.
> > >
> > > Signed-off-by: Mark Kettenis 
> > > ---
> > >  drivers/misc/Kconfig  |   7 ++
> > >  drivers/misc/Makefile |   1 +
> > >  drivers/misc/apple_dart.c | 171 ++
> > >  3 files changed, 179 insertions(+)
> > >  create mode 100644 drivers/misc/apple_dart.c
> > >

[..]

> > > +
> > > +struct apple_dart_priv {
> >
> > How about s/apple_dart/dart/ ?
> >
> > It makes the code easier to read.
>
> I think using apple_dart_ consistently as a prefix makes more sense.

OK I don't mind too much. I just prefer shorter code and sometimes
people use globally unique things in drivers when it really doesn't
help anything.

>
> > > +   struct clk_bulk clks;
> > > +   void *base;
> > > +};
> > > +
> > > +dma_addr_t apple_dart_bus_start;
> > > +phys_addr_t apple_dart_phys_start;
> > > +phys_size_t apple_dart_size = SZ_512M;
> >
> > Try to avoid variables in drivers. Can these go in a priv struct?
>
> Not really since the intent is that these variables specify a global
> "window" that is mapped 1:1 into all the DARTs.

So there are multiple DART devices? In that can you could store this
info in a priv struct attached to the uclass.

[..]

> > > +static int apple_dart_bind(struct udevice *dev)
> > > +{
> > > +   void *base;
> > > +   int sid, i;
> > > +
> > > +   base = dev_read_addr_ptr(dev);
> > > +   if (!base)
> > > +   return -EINVAL;
> > > +
> > > +   u32 params2 = readl(base + DART_PARAMS2);
> > > +   if (params2 & DART_PARAMS2_BYPASS_SUPPORT) {
> > > +   for (sid = 0; sid < 16; sid++) {
> > > +   writel(DART_TCR_BYPASS_DART | 
> > > DART_TCR_BYPASS_DAPF,
> > > +  base + DART_TCR(sid));
> > > +   for (i = 0; i < 4; i++)
> > > +   writel(0, base + DART_TTBR(sid, i));
> > > +   }
> > > +   }
> >
> > Not allowed hardware access in bind(). Can this more to probe() ?
>
> Well, I need to make sure that this happens before other drivers get
> probed (in particular the xhci-dwc3 driver).  Is there a better
> mechanism to achieve that?

If those drivers have something in the DT indicating that they need
this, then you can add a uclass_get_device_by_phandle() in those
drivers.

If not, then you can probe all the DART devices with uclass_probe_all().

Having said that, I see you are using UCLASS_MISC. I suspect this
should have its own UCLASS_IOMMU.

[..]

> >
> > > +   memset(l2, 0, SZ_16K);
> > > +
> > > +   for (j = 0; j < 2048; j++) {
> > > +   l2[j] = phys | 0x3;
> > > +   phys += SZ_16K;
> > > +   }
> > > +   flush_dcache_range((unsigned long)l2,
> > > +  (unsigned long)l2 + SZ_16K);
> > > +
> > > +   l1[i++] = (phys_addr_t)l2 | 0x8 | 0x3;
> >
> > Do you need the cast? What are the magic numbers here? Can you use an
> > enum/#define ?
>
> Not sure if we know the exact meaning of those bits yet.  But there is
> a Linux driver now, so maybe I need to look at it again.

Oh well, a comment that we don't know is fine, too. People can fix it
later if it becomes known.

[..]

Regards,
Simon

Re: [PATCH v2 1/1] fs: avoid superfluous messages

[Simon Glass]

On Mon, 20 Sept 2021 at 06:15, Heinrich Schuchardt
 wrote:
>
> Output like the following is quite irritating:
>
> => bootefi hello
> Scanning disk mmc2.blk...
> No valid Btrfs found
> Bad magic number for SquashFS image.
> ** Unrecognized filesystem type **
> Scanning disk mmc1.blk...
> No valid Btrfs found
> Bad magic number for SquashFS image.
> ** Unrecognized filesystem type **
> Scanning disk mmc0.blk...
> No valid Btrfs found
> Bad magic number for SquashFS image.
> ** Unrecognized filesystem type **
>
> Albeit a whole disk may be formatted with a filesystem in most cases
> a partition table is used and the whole disk (partition number 0) doesn't
> contain a filesytem. Some partitions may only contain a blob. Not seeing a
> filesytem on the whole disk or on any partition is only worth a debug
> message.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> Explicitly mention in the commit message that a whole disk may
> carry a filesystem.
> ---
>  fs/fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Re: [PATCHv5] drivers: tpm2: update reset gpio semantics

[Ilias Apalodimas]

On Thu, Jun 03, 2021 at 12:40:26PM +0200, Jorge Ramirez-Ortiz wrote:
> Use the more generic reset-gpios property name.
> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> Acked-by: Michal Simek 
> ---
> 
>  v5: added Acked-by: Michal Simek
>  
>  .../tpm2/tis-tpm2-spi.txt |  3 ++-
>  drivers/tpm/tpm2_tis_spi.c| 23 ---
>  2 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt 
> b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> index 3a2ee4bd17..16f870225f 100644
> --- a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> +++ b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> @@ -6,7 +6,8 @@ Required properties:
>  - reg: SPI Chip select
>  
>  Optional properties:
> -- gpio-reset : Reset GPIO (if not connected to the SoC reset line)
> +- reset-gpios: Reset GPIO (if not connected to the SoC reset 
> line)
> +- gpio-reset : Reset GPIO (deprecated, use reset-gpios instead)
>  - spi-max-frequency  : See spi-bus.txt
>  
>  Example:
> diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> index 4b33ac8fd3..1d24d32d86 100644
> --- a/drivers/tpm/tpm2_tis_spi.c
> +++ b/drivers/tpm/tpm2_tis_spi.c
> @@ -589,18 +589,25 @@ static int tpm_tis_spi_probe(struct udevice *dev)
>   if (CONFIG_IS_ENABLED(DM_GPIO)) {
>   struct gpio_desc reset_gpio;
>  
> - ret = gpio_request_by_name(dev, "gpio-reset", 0,
> + ret = gpio_request_by_name(dev, "reset-gpios", 0,
>  _gpio, GPIOD_IS_OUT);
>   if (ret) {
> - log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
> - __func__);
> - } else {
> - dm_gpio_set_value(_gpio, 1);
> - mdelay(1);
> - dm_gpio_set_value(_gpio, 0);
> + /* legacy reset */
> + ret = gpio_request_by_name(dev, "gpio-reset", 0,
> +_gpio, GPIOD_IS_OUT);
> + if (ret) {
> + log(LOGC_NONE, LOGL_NOTICE,
> + "%s: missing reset GPIO\n", __func__);
> + goto init;
> + }
> + log(LOGC_NONE, LOGL_NOTICE,
> + "%s: gpio-reset is deprecated\n", __func__);
>   }
> + dm_gpio_set_value(_gpio, 1);
> + mdelay(1);
> + dm_gpio_set_value(_gpio, 0);
>   }
> -
> +init:
>   /* Ensure a minimum amount of time elapsed since reset of the TPM */
>   mdelay(drv_data->time_before_first_cmd_ms);
>  

Acked-by: Ilias Apalodimas 

[PATCH] reboot-mode: migrate uclass to livetree

[Patrick Delaunay]

Use dev_ function to support a live tree.

Signed-off-by: Patrick Delaunay 
---

 drivers/reboot-mode/reboot-mode-uclass.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/reboot-mode/reboot-mode-uclass.c 
b/drivers/reboot-mode/reboot-mode-uclass.c
index bb7a355fbf..2b38aa26b8 100644
--- a/drivers/reboot-mode/reboot-mode-uclass.c
+++ b/drivers/reboot-mode/reboot-mode-uclass.c
@@ -10,8 +10,6 @@
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 int dm_reboot_mode_update(struct udevice *dev)
 {
struct reboot_mode_ops *ops = reboot_mode_get_ops(dev);
@@ -66,25 +64,20 @@ int dm_reboot_mode_pre_probe(struct udevice *dev)
return -EINVAL;
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
-   const int node = dev_of_offset(dev);
const char *mode_prefix = "mode-";
const int mode_prefix_len = strlen(mode_prefix);
-   int property;
+   struct ofprop property;
const u32 *propvalue;
const char *propname;
 
-   plat_data->env_variable = fdt_getprop(gd->fdt_blob,
- node,
- "u-boot,env-variable",
- NULL);
+   plat_data->env_variable = dev_read_string(dev, "u-boot,env-variable");
if (!plat_data->env_variable)
plat_data->env_variable = "reboot-mode";
 
plat_data->count = 0;
 
-   fdt_for_each_property_offset(property, gd->fdt_blob, node) {
-   propvalue = fdt_getprop_by_offset(gd->fdt_blob,
- property, , NULL);
+   dev_for_each_property(property, dev) {
+   propvalue = dev_read_prop_by_prop(, , NULL);
if (!propvalue) {
dev_err(dev, "Could not get the value for property 
%s\n",
propname);
@@ -100,9 +93,8 @@ int dm_reboot_mode_pre_probe(struct udevice *dev)
 
struct reboot_mode_mode *next = plat_data->modes;
 
-   fdt_for_each_property_offset(property, gd->fdt_blob, node) {
-   propvalue = fdt_getprop_by_offset(gd->fdt_blob,
- property, , NULL);
+   dev_for_each_property(property, dev) {
+   propvalue = dev_read_prop_by_prop(, , NULL);
if (!propvalue) {
dev_err(dev, "Could not get the value for property 
%s\n",
propname);
-- 
2.25.1

[PATCH V2 5/6] ARM: rmobile: beacon: Enable reference clocks for USB and AVB

[Adam Ford]

Both Ethernet and USB drivers get their reference clocks from
the versaclock.  Enable that driver and the common clock driver
by default.

Signed-off-by: Adam Ford 
---
 arch/arm/mach-rmobile/Kconfig.64 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index 19fc3cab3a..1ab660cb63 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -82,6 +82,8 @@ config TARGET_BEACON_RZG2M
select PINCTRL_PFC_R8A774E1
imply MULTI_DTB_FIT
imply MULTI_DTB_FIT_USER_DEFINED_AREA
+   imply CLK_VERSACLOCK
+   imply CLK_CCF
 
 config TARGET_CONDOR
bool "Condor board"
-- 
2.25.1

[PATCH V2 3/6] ARM: rmobile: beacon: Remove duplicated for RZ/G2 M/N/H

[Adam Ford]

Now that TARGET_BEACON_RZG2M can handle all the work that
was done with TARGET_BEACON_RZG2N and TARGET_BEACON_RZG2H,
remove them since they just create more duplicate code.

Signed-off-by: Adam Ford 
---
V2:  Rebase.

 arch/arm/mach-rmobile/Kconfig.64  | 14 +-
 board/beacon/beacon-rzg2m/Kconfig |  2 +-
 configs/r8a774b1_beacon_defconfig | 73 ---
 configs/r8a774e1_beacon_defconfig | 73 ---
 4 files changed, 2 insertions(+), 160 deletions(-)

diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index 2bde898928..19fc3cab3a 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -71,14 +71,8 @@ choice
prompt "Renesas ARM64 SoCs board select"
optional
 
-config TARGET_BEACON_RZG2H
-   bool "Beacon EmbeddedWorks RZ/G2H Dev Kit"
-   select R8A774E1
-   select RZ_G2
-   select PINCTRL_PFC_R8A774E1
-
 config TARGET_BEACON_RZG2M
-   bool "Beacon EmbeddedWorks RZ/G2M Dev Kit"
+   bool "Beacon EmbeddedWorks RZ/G2 Dev Kit"
select R8A774A1
select R8A774B1
select R8A774E1
@@ -89,12 +83,6 @@ config TARGET_BEACON_RZG2M
imply MULTI_DTB_FIT
imply MULTI_DTB_FIT_USER_DEFINED_AREA
 
-config TARGET_BEACON_RZG2N
-   bool "Beacon EmbeddedWorks RZ/G2N Dev Kit"
-   select R8A774B1
-   select RZ_G2
-   select PINCTRL_PFC_R8A774B1
-
 config TARGET_CONDOR
bool "Condor board"
imply R8A77980
diff --git a/board/beacon/beacon-rzg2m/Kconfig 
b/board/beacon/beacon-rzg2m/Kconfig
index 99c23a3d14..c03857cf2f 100644
--- a/board/beacon/beacon-rzg2m/Kconfig
+++ b/board/beacon/beacon-rzg2m/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_BEACON_RZG2H || TARGET_BEACON_RZG2M || TARGET_BEACON_RZG2N
+if TARGET_BEACON_RZG2M
 
 config SYS_SOC
default "rmobile"
diff --git a/configs/r8a774b1_beacon_defconfig 
b/configs/r8a774b1_beacon_defconfig
deleted file mode 100644
index 6f1a6085ec..00
--- a/configs/r8a774b1_beacon_defconfig
+++ /dev/null
@@ -1,73 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_RMOBILE=y
-CONFIG_SYS_TEXT_BASE=0x5000
-CONFIG_SYS_MALLOC_F_LEN=0x2000
-CONFIG_ENV_OFFSET=0x0
-CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a774b1-beacon-rzg2n-kit"
-CONFIG_RCAR_GEN3=y
-CONFIG_TARGET_BEACON_RZG2N=y
-# CONFIG_SPL is not set
-CONFIG_LTO=y
-CONFIG_FIT=y
-CONFIG_SUPPORT_RAW_INITRD=y
-# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
-CONFIG_DEFAULT_FDT_FILE="r8a774b1-beacon-rzg2n-kit.dtb"
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-CONFIG_CMD_GPIO=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_MMC=y
-CONFIG_CMD_MTD=y
-CONFIG_CMD_PART=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_USB=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_OF_CONTROL=y
-CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_IN_MMC=y
-CONFIG_SYS_MMC_ENV_DEV=1
-CONFIG_SYS_MMC_ENV_PART=2
-CONFIG_VERSION_VARIABLE=y
-CONFIG_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_CLK=y
-CONFIG_CLK_RENESAS=y
-CONFIG_RCAR_GPIO=y
-CONFIG_DM_PCA953X=y
-CONFIG_DM_I2C=y
-CONFIG_SYS_I2C_RCAR_I2C=y
-CONFIG_SYS_I2C_RCAR_IIC=y
-CONFIG_MMC_IO_VOLTAGE=y
-CONFIG_MMC_UHS_SUPPORT=y
-CONFIG_MMC_HS200_SUPPORT=y
-CONFIG_RENESAS_SDHI=y
-CONFIG_MTD=y
-CONFIG_DM_MTD=y
-CONFIG_DM_SPI_FLASH=y
-CONFIG_SPI_FLASH_WINBOND=y
-CONFIG_BITBANGMII=y
-CONFIG_PHY_REALTEK=y
-CONFIG_DM_ETH=y
-CONFIG_RENESAS_RAVB=y
-CONFIG_DM_REGULATOR=y
-CONFIG_DM_REGULATOR_FIXED=y
-CONFIG_DM_REGULATOR_GPIO=y
-CONFIG_SPECIFY_CONSOLE_INDEX=y
-CONFIG_SCIF_CONSOLE=y
-CONFIG_SPI=y
-CONFIG_DM_SPI=y
-CONFIG_RENESAS_RPC_SPI=y
-CONFIG_USB=y
-CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_GENERIC=y
-CONFIG_USB_STORAGE=y
-CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/r8a774e1_beacon_defconfig 
b/configs/r8a774e1_beacon_defconfig
deleted file mode 100644
index 9cde39f467..00
--- a/configs/r8a774e1_beacon_defconfig
+++ /dev/null
@@ -1,73 +0,0 @@
-CONFIG_ARM=y
-CONFIG_ARCH_RMOBILE=y
-CONFIG_SYS_TEXT_BASE=0x5000
-CONFIG_SYS_MALLOC_F_LEN=0x2000
-CONFIG_ENV_OFFSET=0x0
-CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="r8a774e1-beacon-rzg2h-kit"
-CONFIG_RCAR_GEN3=y
-CONFIG_TARGET_BEACON_RZG2H=y
-# CONFIG_SPL is not set
-CONFIG_LTO=y
-CONFIG_FIT=y
-CONFIG_SUPPORT_RAW_INITRD=y
-# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
-CONFIG_DEFAULT_FDT_FILE="r8a774e1-beacon-rzg2h-kit.dtb"
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-CONFIG_CMD_GPIO=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_MMC=y
-CONFIG_CMD_MTD=y
-CONFIG_CMD_PART=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_USB=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_OF_CONTROL=y
-CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_IN_MMC=y
-CONFIG_SYS_MMC_ENV_DEV=1
-CONFIG_SYS_MMC_ENV_PART=2
-CONFIG_VERSION_VARIABLE=y
-CONFIG_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_CLK=y
-CONFIG_CLK_RENESAS=y
-CONFIG_RCAR_GPIO=y
-CONFIG_DM_PCA953X=y

[PATCH V2 4/6] ARM: rmobile: Beacon: Remove dead code

[Adam Ford]

There are a few do-nothing functions that can be removed.
Remove them.

Signed-off-by: Adam Ford 
---
 board/beacon/beacon-rzg2m/beacon-rzg2m.c | 10 --
 configs/r8a774a1_beacon_defconfig|  1 +
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c 
b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
index b3521fcbc1..df6044a429 100644
--- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
+++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
@@ -10,16 +10,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-void s_init(void)
-{
-}
-
-/* Kconfig forces this on, so just return 0 */
-int board_early_init_f(void)
-{
-   return 0;
-}
-
 int board_init(void)
 {
/* address of boot parameters */
diff --git a/configs/r8a774a1_beacon_defconfig 
b/configs/r8a774a1_beacon_defconfig
index 11c99d4850..aaea9b4c30 100644
--- a/configs/r8a774a1_beacon_defconfig
+++ b/configs/r8a774a1_beacon_defconfig
@@ -13,6 +13,7 @@ CONFIG_FIT=y
 CONFIG_SUPPORT_RAW_INITRD=y
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 CONFIG_DEFAULT_FDT_FILE="r8a774a1-beacon-rzg2m-kit.dtb"
+# CONFIG_BOARD_EARLY_INIT_F is not set
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
-- 
2.25.1

[PATCH V2 6/6] ARM: rmobile: Rename r8a774a1_beacon_defconfig to rzg2_beacon_defconfig

[Adam Ford]

Now that the three M/N/H variants can be built from one config,
rename the defconfig file to be more generic since it supports multiple
RZ/G2.

Signed-off-by: Adam Ford 
---
V2:  new to series

 configs/{r8a774a1_beacon_defconfig => rzg2_beacon_defconfig} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/configs/r8a774a1_beacon_defconfig b/configs/rzg2_beacon_defconfig
similarity index 100%
rename from configs/r8a774a1_beacon_defconfig
rename to configs/rzg2_beacon_defconfig
-- 
2.25.1

[PATCH V2 2/6] ARM: rmobile: beacon: Support RZ/G2 [M/N/H] on TARGET_BEACON_RZG2M

[Adam Ford]

The three different boards share the same board file and only differ
in terms of which SoC is being used.  By enabling FIT on
TARGET_BEACON_RZG2M, it can support all three boards and elimate
duplicate code.

Signed-off-by: Adam Ford 
---
 arch/arm/mach-rmobile/Kconfig.64  | 8 
 configs/r8a774a1_beacon_defconfig | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64
index a6dcce180b..2bde898928 100644
--- a/arch/arm/mach-rmobile/Kconfig.64
+++ b/arch/arm/mach-rmobile/Kconfig.64
@@ -80,8 +80,14 @@ config TARGET_BEACON_RZG2H
 config TARGET_BEACON_RZG2M
bool "Beacon EmbeddedWorks RZ/G2M Dev Kit"
select R8A774A1
+   select R8A774B1
+   select R8A774E1
select RZ_G2
select PINCTRL_PFC_R8A774A1
+   select PINCTRL_PFC_R8A774B1
+   select PINCTRL_PFC_R8A774E1
+   imply MULTI_DTB_FIT
+   imply MULTI_DTB_FIT_USER_DEFINED_AREA
 
 config TARGET_BEACON_RZG2N
bool "Beacon EmbeddedWorks RZ/G2N Dev Kit"
@@ -177,11 +183,13 @@ source "board/hoperun/hihope-rzg2/Kconfig"
 source "board/silinux/ek874/Kconfig"
 
 config MULTI_DTB_FIT_UNCOMPRESS_SZ
+   default 0x8 if TARGET_BEACON_RZG2M
default 0x8 if TARGET_HIHOPE_RZG2
default 0x8 if TARGET_SALVATOR_X
default 0x8 if TARGET_ULCB
 
 config MULTI_DTB_FIT_USER_DEF_ADDR
+   default 0x4900 if TARGET_BEACON_RZG2M
default 0x4900 if TARGET_HIHOPE_RZG2
default 0x4900 if TARGET_SALVATOR_X
default 0x4900 if TARGET_ULCB
diff --git a/configs/r8a774a1_beacon_defconfig 
b/configs/r8a774a1_beacon_defconfig
index 7ba4ac05f5..11c99d4850 100644
--- a/configs/r8a774a1_beacon_defconfig
+++ b/configs/r8a774a1_beacon_defconfig
@@ -31,6 +31,9 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
+CONFIG_OF_LIST="r8a774a1-beacon-rzg2m-kit r8a774b1-beacon-rzg2n-kit 
r8a774e1-beacon-rzg2h-kit"
+CONFIG_MULTI_DTB_FIT_LZO=y
+CONFIG_MULTI_DTB_FIT_USER_DEFINED_AREA=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_MMC_ENV_DEV=1
-- 
2.25.1

[PATCH V2 1/6] ARM: rmobile: Enable board detection when FIT is enabled

[Adam Ford]

There are three boards from Beacon, RZ/G2 M/N/H which all
use the same board file, but different device trees.
Add code to automatically select the proper device tree
based on the CPU type.

Signed-off-by: Adam Ford 
---
 board/beacon/beacon-rzg2m/beacon-rzg2m.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c 
b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
index c12ff77fb2..b3521fcbc1 100644
--- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
+++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
@@ -36,3 +36,19 @@ void reset_cpu(void)
 {
writel(RST_CODE, RST_CA57RESCNT);
 }
+
+#if IS_ENABLED(CONFIG_MULTI_DTB_FIT)
+int board_fit_config_name_match(const char *name)
+{
+   if (!strcmp(rzg_get_cpu_name(), "R8A774A1") && !strcmp(name, 
"r8a774a1-beacon-rzg2m-kit"))
+   return 0;
+
+   if (!strcmp(rzg_get_cpu_name(), "R8A774B1") && !strcmp(name, 
"r8a774b1-beacon-rzg2n-kit"))
+   return 0;
+
+   if (!strcmp(rzg_get_cpu_name(), "R8A774E1") && !strcmp(name, 
"r8a774e1-beacon-rzg2h-kit"))
+   return 0;
+
+   return -1;
+}
+#endif
-- 
2.25.1

Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable

[Ilias Apalodimas]

Hi Michal,

[...]
>  Thanks for explaining.  This got me to re-read the existing tests and 
>  while
>  none of it is as clear as I would like, your example here is just as 
>  clear as the
>  rest, so it's fine and I'll pick it up soon.
> >>>
> >>> I see this patch is not yet applied on the repo, could you please let me 
> >>> know when this will be applied?
> >>
> >> Ilias, since you've said you'd review TPM related patches, does this:
> >> https://patchwork.ozlabs.org/project/uboot/patch/1624340962-91190-1-git-send-email-t.karthik.re...@xilinx.com/
> >> work for you?  Thanks.
> >>
> >
> > I am not too familiar with the pytest framework we have, but couldn't
> > we do this automatically?
> > IOW instead of explicitly adding a variable, do a 'tpm info' and if
> > that doesn't return a valid device, skip the tests.
>
> Unfortunately not. Because imagine how this will work if you have tpm on
> board but there is bug in the driver that it is not probed. Then tpm
> info will return no device and all tests will be silently skipped.

Looking at tpm_info I think it's the other way around, isn't it ?
tpm_info will call get_tpm(), which in theory will fail if there's no
TPM probed or not present.  So even in that case the self-tests will
fail.

OTOH the 'tpm info' command just returns a CMD Success/Failure, so
it's not easy to figure out if a TPM is indeed present or not without
refactoring the cmdline interface.  So I think this is reasonable for
now

Acked-by: Ilias Apalodimas 

>
> It would be much better it the test itself was designed from the
> beginning that you need to state that board has TPM. But it wasn't
> that's why we designed this patch in a way that you declare that you
> want to skip these tests which is OK.
>
> It doesn't make any sense to go back and start to have multiple
> defconfigs for different configurations where all boards works quite
> well with one defconfig. That's why we enable TPM because it on SOM but
> we need to be able to disable these tests on others.
>
> Thanks,
> Michal
>
>
>

[PATCH] drivers: pmic: Add sysreset driver to da9063 pmic device

[Alexandre Ghiti]

This pmic device is present on the SiFive Unmatched board and this
new driver adds the possibility to reset it.

Signed-off-by: Alexandre Ghiti 
---
 configs/sifive_unmatched_defconfig |  2 ++
 drivers/power/pmic/da9063.c| 49 ++
 2 files changed, 51 insertions(+)

diff --git a/configs/sifive_unmatched_defconfig 
b/configs/sifive_unmatched_defconfig
index 978818b688..9ab058be39 100644
--- a/configs/sifive_unmatched_defconfig
+++ b/configs/sifive_unmatched_defconfig
@@ -43,3 +43,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_PCI=y
 CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_DA9063=y
diff --git a/drivers/power/pmic/da9063.c b/drivers/power/pmic/da9063.c
index 25101d18f7..b04879d9c5 100644
--- a/drivers/power/pmic/da9063.c
+++ b/drivers/power/pmic/da9063.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,6 +88,7 @@ static int da9063_bind(struct udevice *dev)
 {
ofnode regulators_node;
int children;
+   int ret;
 
regulators_node = dev_read_subnode(dev, "regulators");
if (!ofnode_valid(regulators_node)) {
@@ -101,6 +103,14 @@ static int da9063_bind(struct udevice *dev)
if (!children)
debug("%s: %s - no child found\n", __func__, dev->name);
 
+   if (CONFIG_IS_ENABLED(SYSRESET)) {
+   ret = device_bind_driver(dev, "da9063-sysreset",
+"da9063-sysreset", NULL);
+   if (ret)
+   debug("%s: %s - failed to bind sysreset driver\n",
+ __func__, dev->name);
+   }
+
/* Always return success for this device */
return 0;
 }
@@ -129,3 +139,42 @@ U_BOOT_DRIVER(pmic_da9063) = {
.probe = da9063_probe,
.ops = _ops,
 };
+
+#ifdef CONFIG_SYSRESET
+#include 
+
+static int da9063_sysreset_request(struct udevice *dev, enum sysreset_t type)
+{
+   struct udevice *pmic_dev = dev->parent;
+   uint ret;
+
+   if (type != SYSRESET_WARM && type != SYSRESET_COLD)
+   return -EPROTONOSUPPORT;
+
+   ret = pmic_reg_write(pmic_dev, DA9063_REG_PAGE_CON, 0x00);
+   if (ret < 0)
+   return ret;
+
+   /* Sets the WAKE_UP bit */
+   ret = pmic_reg_write(pmic_dev, DA9063_REG_CONTROL_F, 0x04);
+   if (ret < 0)
+   return ret;
+
+   /* Powerdown! */
+   ret = pmic_reg_write(pmic_dev, DA9063_REG_CONTROL_A, 0x68);
+   if (ret < 0)
+   return ret;
+
+   return -EINPROGRESS;
+}
+
+static struct sysreset_ops da9063_sysreset_ops = {
+   .request = da9063_sysreset_request,
+};
+
+U_BOOT_DRIVER(da9063_sysreset) = {
+   .name = "da9063-sysreset",
+   .id = UCLASS_SYSRESET,
+   .ops = _sysreset_ops,
+};
+#endif
-- 
2.30.2

Re: Modules for carrier boards [Was: Re: Question about extension board used in U-boot]

[François Ozog]

Le lun. 20 sept. 2021 à 13:32, Daniel Thompson 
a écrit :

> On Sat, Sep 18, 2021 at 08:49:48AM +0200, François Ozog wrote:
> > Hi Paul
> >
> > Too posting because I think we also need to address this at a higher
> level.
> >
> > i think we discussed this topic quite a while back. I may be wrong but it
> > may be Bill Mills who proposed to have an eeprom on the extensions that
> the
> > carrier board can use to detect and fetch proper overlay. Another way
> would
> > be that the contract between the extension board and the carrier board
> > includes an i2c accessible storage to fetch an overlay that would
> identify
> > the board and give all details.
>
> What you're describing sounds exactly like Raspberry Pi HATs work:
> https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md
>
> Similarly Beagleboard capes use rely on I2C EEPROMs for make them
> discoverable, although I don't think all have to have a built-in
> overlay (IIRC because they joined the party too early).
>
I believe this would be a great SystemReady addition: define details of the
DT lifecycle and probably adopt one of the two models. Or worst case define
a consolidated one.
I hope this is also adoptable by  96boards…

>
> In other words there's plenty of prior art here and, as new hardware
> standards come out, it should be much easier for them to find this prior
> art. However I'm near certain mistakes will still be made...
>
>
> > Bottom line, a software only solution seems not entirely satisfying.
> > In that suboptimal case, U-Boot shall be able to assemble a DT for itself
> > and another for OS (may be same in some cases) through scripting. And in
> > this case, come your questions  below.
>
> Sub-optimal or not[1] the u-boot extension board code still looks like it
> would be a good starting point even for boards with non-discoverable
> extensions (96Boards CE 1.0 for example).
>
> If implementing on a board with non-discoverable extensions then I would
> consider implementing "extension scan" to report non-discoverable modules
> (e.g. from an internal list) and proposing patches to that "extension
> apply all" would not enable non-discoverable boards (so that non-
> discoverable boards would have to be enabled by injecting a "extension
> apply " into the boot scripts).
>
> Of course, I may have overlooked a better existing mechanism in u-boot
> but that's what I would start with until I was corrected by
> maintainers ;-) .
>
>
> Daniel.
>
>
> [1] And also extremely off-topic for Paul since his (a) boards are
> discoverable and (b) the extension framework can't fire up early
> enough for TPM extensions ;-) .
>
>
>
> > Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <
> paul...@debian.org>
> > a écrit :
> >
> > > Hi all,
> > >
> > >
> > > I have some questions about how to implement extension board usage.
> > > My case is on imx8mm-cl-iot-gate. It can add three different types of
> > > extension boards.
> > > One of the extension boards is SPI extension which have 3 empty slots.
> > > And you can add
> > > some small boards onto it. One of them is a "TPM2" module.
> > >
> > >
> > > My first question is if I want to use tpm2 in U-boot for measured boot.
> > > How to implement this right? Currently I just modify the dts used by
> > > U-boot to let it drive
> > > the extension board. And let it drive the TPM. But it is not good for
> > > upstreaming because
> > > when other types of extension boards installed then it is not working.
> > > Where to implement this? What is the best practice of this?
> >
> >
> > > The second question is about extension manager.
> > > I have read the extension.rst. I think I'll implement this anyway
> > > because then
> > > I can have a command to query what type of extension boards I have.
> > > And if the extension board is the 3 slots one. I can then detect which
> > > slot is the TPM.
> > > I'll implement this anyway because the "extension" command is
> convenient
> > > for users.
> > > But it seems to me that it only solves the problem for Linux kernel.
> > > It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
> > > extension board.
> > > But it is too late for U-boot itself, right?
> > >
> > >
> > > The third question is I'm also dong SystemReady IR certificate. That
> means
> > > the dtb for Linux is directly provided by U-boot. We use U-boot dtb
> > > directly to Linux
> > > kernel. In this case, how to modify that dts dynamically to feed to the
> > > Linux kernel by
> > > the extension manager?
> > > What is the best practice if I want to use U-boot dts for Linux in
> > > implementation?
> > >
> > >
> > > Thanks a lot.
> > >
> > >
> > > Yours,
> > > Paul
> > >
> > >
> > > --
> > François-Frédéric Ozog | *Director Business Development*
> > T: +33.67221.6485
> > francois.o...@linaro.org | Skype: ffozog
> > ___
> > boot-architecture mailing list
> > boot-architect...@lists.linaro.org
> > 

[PATCH] demo: migrate uclass to livetree

[Patrick Delaunay]

Use dev_ function to read the sides and colour to support a live tree.

Signed-off-by: Patrick Delaunay 
---

 drivers/demo/demo-uclass.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/demo/demo-uclass.c b/drivers/demo/demo-uclass.c
index 815f8de645..09f9a47d4d 100644
--- a/drivers/demo/demo-uclass.c
+++ b/drivers/demo/demo-uclass.c
@@ -10,15 +10,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 UCLASS_DRIVER(demo) = {
.name   = "demo",
.id = UCLASS_DEMO,
@@ -67,10 +63,9 @@ int demo_set_light(struct udevice *dev, int light)
 int demo_parse_dt(struct udevice *dev)
 {
struct dm_demo_pdata *pdata = dev_get_plat(dev);
-   int dn = dev_of_offset(dev);
 
-   pdata->sides = fdtdec_get_int(gd->fdt_blob, dn, "sides", 0);
-   pdata->colour = fdt_getprop(gd->fdt_blob, dn, "colour", NULL);
+   pdata->sides = dev_read_s32_default(dev, "sides", 0);
+   pdata->colour = dev_read_string(dev, "colour");
if (!pdata->sides || !pdata->colour) {
debug("%s: Invalid device tree data\n", __func__);
return -EINVAL;
-- 
2.25.1

[PATCH] remoteproc: migrate uclass to livetree

[Patrick Delaunay]

Use dev_ function to read the name and boolean to support a live tree.

Signed-off-by: Patrick Delaunay 
---

 drivers/remoteproc/rproc-uclass.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/remoteproc/rproc-uclass.c 
b/drivers/remoteproc/rproc-uclass.c
index 64c47c1e72..87e1ec7ad7 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -9,19 +9,15 @@
 #define pr_fmt(fmt) "%s: " fmt, __func__
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-DECLARE_GLOBAL_DATA_PTR;
-
 /**
  * for_each_remoteproc_device() - iterate through the list of rproc devices
  * @fn: check function to call per match, if this function returns fail,
@@ -121,21 +117,13 @@ static int rproc_pre_probe(struct udevice *dev)
 
if (!dev_get_plat(dev)) {
 #if CONFIG_IS_ENABLED(OF_CONTROL)
-   int node = dev_of_offset(dev);
-   const void *blob = gd->fdt_blob;
bool tmp;
-   if (!blob) {
-   debug("'%s' no dt?\n", dev->name);
-   return -EINVAL;
-   }
debug("'%s': using fdt\n", dev->name);
-   uc_pdata->name = fdt_getprop(blob, node,
-"remoteproc-name", NULL);
+   uc_pdata->name = dev_read_string(dev, "remoteproc-name");
 
/* Default is internal memory mapped */
uc_pdata->mem_type = RPROC_INTERNAL_MEMORY_MAPPED;
-   tmp = fdtdec_get_bool(blob, node,
- "remoteproc-internal-memory-mapped");
+   tmp = dev_read_bool(dev, "remoteproc-internal-memory-mapped");
if (tmp)
uc_pdata->mem_type = RPROC_INTERNAL_MEMORY_MAPPED;
 #else
-- 
2.25.1

Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable

[Michal Simek]

Hi

On 9/18/21 11:48 AM, Ilias Apalodimas wrote:
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 15:08, Tom Rini  wrote:
>>
>> On Fri, Sep 17, 2021 at 11:49:51AM +, T Karthik Reddy wrote:
>>> Hi Tom,
>>>
 -Original Message-
 From: Tom Rini 
 Sent: Thursday, August 5, 2021 6:53 PM
 To: T Karthik Reddy 
 Cc: Ashok Reddy Soma ; u-boot@lists.denx.de;
 miquel.ray...@bootlin.com; git 
 Subject: Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env variable

 On Thu, Aug 05, 2021 at 05:56:50AM +, T Karthik Reddy wrote:
> Hello Tom Rini,
>
>> -Original Message-
>> From: Tom Rini 
>> Sent: Wednesday, August 4, 2021 8:52 PM
>> To: Ashok Reddy Soma 
>> Cc: u-boot@lists.denx.de; miquel.ray...@bootlin.com; git
>> ; T Karthik Reddy 
>> Subject: Re: [PATCH] test/py: tpm2: Skip tpm pytest based on env
>> variable
>>
>> On Fri, Jul 23, 2021 at 06:18:26AM -0600, Ashok Reddy Soma wrote:
>>
>>> From: T Karthik Reddy 
>>>
>>> Tpm test cases relies on tpm device setup. Provide an environment
>>> variable "env__tpm_device_test_skip = True" to skip the test case
>>> if tpm device is not present.
>>> Only needed will have to add variable to the py-test framework.
>>> Test runs successfully even this variable is absent.
>>>
>>> Signed-off-by: T Karthik Reddy 
>>> Signed-off-by: Ashok Reddy Soma 
>>
>> Why is this not using boardenv_* like other tests do to disable running?
>
> What I meant here was this test doesn't depend on configuration value
> from boardenv_*. But it uses env__tpm_device_test_skip variable from
 the configuration file.
> I referred test/py/tests/test_sleep.py for writing this test case, hence
 copied comments as well.
> Should I change this NOTE in comment section?

 Thanks for explaining.  This got me to re-read the existing tests and while
 none of it is as clear as I would like, your example here is just as clear 
 as the
 rest, so it's fine and I'll pick it up soon.
>>>
>>> I see this patch is not yet applied on the repo, could you please let me 
>>> know when this will be applied?
>>
>> Ilias, since you've said you'd review TPM related patches, does this:
>> https://patchwork.ozlabs.org/project/uboot/patch/1624340962-91190-1-git-send-email-t.karthik.re...@xilinx.com/
>> work for you?  Thanks.
>>
> 
> I am not too familiar with the pytest framework we have, but couldn't
> we do this automatically?
> IOW instead of explicitly adding a variable, do a 'tpm info' and if
> that doesn't return a valid device, skip the tests.

Unfortunately not. Because imagine how this will work if you have tpm on
board but there is bug in the driver that it is not probed. Then tpm
info will return no device and all tests will be silently skipped.

It would be much better it the test itself was designed from the
beginning that you need to state that board has TPM. But it wasn't
that's why we designed this patch in a way that you declare that you
want to skip these tests which is OK.

It doesn't make any sense to go back and start to have multiple
defconfigs for different configurations where all boards works quite
well with one defconfig. That's why we enable TPM because it on SOM but
we need to be able to disable these tests on others.

Thanks,
Michal

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Sat, Sep 18, 2021 at 01:15:07PM +0200, Mark Kettenis wrote:
> > From: Simon Glass 
> > Date: Sat, 18 Sep 2021 03:27:48 -0600
> > 
> > Hi Tom,
> > 
> > On Fri, 17 Sept 2021 at 11:26, Tom Rini  wrote:
> > >
> > > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > > Hi Mark,
> > > >
> > > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis  
> > > > wrote:
> > > > >
> > > > > > From: Simon Glass 
> > > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis 
> > > > > >  wrote:
> > > > > > >
> > > > > > > > From: Moiz Imtiaz 
> > > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > > >
> > > > > > > > >I wonder if rpi is not using the devicetree compiled with 
> > > > > > > > >U-Boot, but
> > > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > > >
> > > > > > > > Not sure, but seems like this is the case. I checked and there 
> > > > > > > > isn't any
> > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. 
> > > > > > > > I tried to
> > > > > > > > add the dtb and other dts dtsi
> > > > > > > > files
> > > > > > > > from the raspberry pi Linux and compile them with 
> > > > > > > > CONFIG_OF_SEPARATE and
> > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the 
> > > > > > > > U-Boot and
> > > > > > > > it would just give a blank screen*. I wonder why there isn't 
> > > > > > > > any device
> > > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not 
> > > > > > > > supported by
> > > > > > > > RPI4?
> > > > > > >
> > > > > > > The issue with the rpi4 is that the addresses of devices move 
> > > > > > > around
> > > > > > > based on the version of the Raspberry Pi firmware you're using.  
> > > > > > > And
> > > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > > pretty much has to use the device tree passed by the firmware 
> > > > > > > since
> > > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > > combinations of firmware and hardware.
> > > > > > >
> > > > > > > Simon, this sort of thing is exactly the reason why I think the 
> > > > > > > idea
> > > > > > > of having all U-Boot configuration information in a single device 
> > > > > > > tree
> > > > > > > with the hardware description doesn't work everywhere.
> > > > > >
> > > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > > >
> > > > > As long as that configuration is optional, yes, maybe.
> > > > >
> > > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > > it could provide a devicetree to whatever is next.
> > > > >
> > > > > Not hopeless.  If that device tree provides a hardware description
> > > > > that is complete enough to boot Linux, it should be good enough to run
> > > > > U-Boot.
> > > >
> > > > Not in general. I hope I have covered this in enormous detail in the
> > > > devicetree patch. But if you don't need verified boot, SPL or some
> > > > other feature that needs config, then perhaps you will get away with
> > > > it.
> > >
> > > Wait, why does SPL _need_ it?  If something provides us with a device
> > > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > > smaller DT to use.
> > 
> > Yes, although if the filtering is not done I am not sure what SPL
> > would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> > proper) from a prior boot stage at present.
> 
> I still think that if there is some sort of prior stage firmware,
> there typically is no need for SPL.  And if there is, DRAM is probably
> set up already and there are no space constraints so using the full DT
> isn't an issue.

This isn't strictly true.  You can look at the TI Keystone 3 platforms
where there's both R5 and A72 cores and it's still an intentional
software design to use SPL at the A72 stage.  I think this is explained
in the U-Boot docs, but if not I think it has been on the mailing list,
perhaps?  But that's just an FYI really.

> > >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > > but means whatever loaded us needs to have enabled any early clocks we
> > > need.  But even then, it's just going to be output related?  And some
> > > "was already configured" path could be used.
> > 
> > My point is that ignoring U-Boot's devicetree requirements doesn't
> > work in general. It may work in specific cases. It cannot work for
> > 

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Sat, Sep 18, 2021 at 12:26:00PM +0200, François Ozog wrote:
> Le sam. 18 sept. 2021 à 12:10, Mark Kettenis  a
> écrit :
> 
> > > From: Moiz Imtiaz 
> > > Date: Sat, 18 Sep 2021 14:47:51 +0500
> > >
> > > >Nice!  If you want to write something up extending the >documentation on
> > > >how you made this work for Pi it would be much appreciated.
> > >
> > > Sure, would love to do a PR.
> > >
> > > I basically replaced the dtb that pi loads with control Dtb of uboot, but
> > > will do a PR of documentation addition in respect to pi_4, detailing
> > > everything shortly :)
> >
> > Sorry, but I don't think this is safe.  The Raspberry Pi firmware
> > makes changes to the device tree and it is unclear what requirements
> > it has in terms of names of nodes and compatible strings since the
> > firmware is closed source.  It should be fine to add stuff to the DTB
> > that came with the firmware, but replacing it altogether is probably
> > going to break things in subtle ways.  So I don't think that is
> > something we should advocate by documenting it in U-Boot.
>
> The way I see the chain of trust is: I don’t know how the GPU firmware is
> checked (or even if it is checked), The GPU firmware does not check or
> measure the booted kernel from kernel=xyz that it gets from the unverified
> config.txt which have been building a hardware description from unverified
> files from the file system.
> 
> Bottom line, trying to create a secure boot flow on RPI4 may lead into
> impression of security while it is not supported at hardware level.
> Impression of security can be worse than no security at all.

In general, there's always the questionable value of enabling some level
of "secure" boot on platforms where we don't have a root of trust
starting from the hardware, nor hardware assist later on.  But there is
some value in documenting how to enable the commodity (versus
SoC-specific) functionality on very common reference platforms.
Sometimes even more so even on platforms you can't otherwise potentially
lock yourself out of.

-- 
Tom


signature.asc
Description: PGP signature

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Sat, Sep 18, 2021 at 03:27:48AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 11:26, Tom Rini  wrote:
> >
> > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis  
> > > wrote:
> > > >
> > > > > From: Simon Glass 
> > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis 
> > > > >  wrote:
> > > > > >
> > > > > > > From: Moiz Imtiaz 
> > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > >
> > > > > > > >I wonder if rpi is not using the devicetree compiled with 
> > > > > > > >U-Boot, but
> > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > >
> > > > > > > Not sure, but seems like this is the case. I checked and there 
> > > > > > > isn't any
> > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I 
> > > > > > > tried to
> > > > > > > add the dtb and other dts dtsi
> > > > > > > files
> > > > > > > from the raspberry pi Linux and compile them with 
> > > > > > > CONFIG_OF_SEPARATE and
> > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the 
> > > > > > > U-Boot and
> > > > > > > it would just give a blank screen*. I wonder why there isn't any 
> > > > > > > device
> > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not 
> > > > > > > supported by
> > > > > > > RPI4?
> > > > > >
> > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > combinations of firmware and hardware.
> > > > > >
> > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > of having all U-Boot configuration information in a single device 
> > > > > > tree
> > > > > > with the hardware description doesn't work everywhere.
> > > > >
> > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > >
> > > > As long as that configuration is optional, yes, maybe.
> > > >
> > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > it could provide a devicetree to whatever is next.
> > > >
> > > > Not hopeless.  If that device tree provides a hardware description
> > > > that is complete enough to boot Linux, it should be good enough to run
> > > > U-Boot.
> > >
> > > Not in general. I hope I have covered this in enormous detail in the
> > > devicetree patch. But if you don't need verified boot, SPL or some
> > > other feature that needs config, then perhaps you will get away with
> > > it.
> >
> > Wait, why does SPL _need_ it?  If something provides us with a device
> > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > smaller DT to use.
> 
> Yes, although if the filtering is not done I am not sure what SPL
> would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> proper) from a prior boot stage at present.

The need to filter the DT down for SPL tends to be because we don't
otherwise have enough initialized memory to retrieve / work with / etc
the DT.  That can't be true if some other stage is handing us something.

> >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > but means whatever loaded us needs to have enabled any early clocks we
> > need.  But even then, it's just going to be output related?  And some
> > "was already configured" path could be used.
> 
> My point is that ignoring U-Boot's devicetree requirements doesn't
> work in general. It may work in specific cases. It cannot work for
> verified boot of course.

I'm trying to not belabor the point here, since you've said you'll post
some bindings for review, but it's not _our_ device tree.  That breaks
the whole blasted point of having "a" device tree, rather than everyone
having their own device tree.  So figuring out a good path forward for
verified boot is something that'll require a little more thinking quite
possibly and explaining how you do it on something again modern and
potentially hardware-assisted.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] Makefile: Add a warning about ad-hoc CONFIG options

[Tom Rini]

On Sat, Sep 18, 2021 at 12:21:21PM -0600, Simon Glass wrote:

> The Kconfig feature was added in 2014. Some 7 years later there are still
> quite a few CONFIG options that have not been migrated. It is time to
> close this out.
> 
> Add a deadline and a warning for boards to migrate to Kconfig.
> 
> Signed-off-by: Simon Glass 

I agree with the sentiment.  But we aren't at the point where even aside
from environment and a few outstanding migrations I've posted but not
yet pulled, that any platform is 100% clean.  There's still even
migrated-but-in-config.h symbols seemingly everywhere.

-- 
Tom


signature.asc
Description: PGP signature

Re: Two jobs at once on denx-vulcan?

[Simon Glass]

Hi Harald,

On Mon, 20 Sept 2021 at 02:12, Harald Seiler  wrote:
>
> Hi,
>
> On Sat, 2021-09-18 at 10:37 -0600, Simon Glass wrote:
> > Hi,
> >
> > Is there something screwy with this? It seems that denx-vulcan does
> > two builds at once?
> >
> > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/323540
>
> Hm, I did some changes to the vulcan runner which might have caused
> this... But still, even if it is running multiple jobs in parallel, they
> should still be isolated, so how does this lead to a build failure?

I'm not sure that it does, but I do see this at the above link:

Error: Unable to create
'/builds/u-boot/custodians/u-boot-dm/.git/logs/HEAD.lock': File
exists.

Re doing multiple builds, have you set it up so it doesn't take on the
very large builds? I would love to enable multiple builds for the qemu
steps since they mostly use a single CPU, but am not sure how to do
it.

Regards,
Simon

Re: [PATCH v2] board: freescale: lx216x : increase fdt blob size

[Tom Rini]

On Mon, Sep 20, 2021 at 03:45:33PM +0200, Wasim Khan wrote:

> From: Wasim Khan 
> 
> Increase fdt blob size for lx2160 and lx2162 series
> to fix below errors/warnings during device tree fixup.
> 
> Unable to update property /soc/spi@210:status, err=FDT_ERR_NOSPACE
> Unable to update property /soc/spi@211:status, err=FDT_ERR_NOSPACE
> Unable to update property /soc/spi@212:status, err=FDT_ERR_NOSPACE
> WARNING: could not set reg FDT_ERR_NOSPACE.
> WARNING unable to set iommus: FDT_ERR_NOSPACE
> 
> Signed-off-by: Wasim Khan 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v2] board: freescale: lx216x : increase fdt blob size

[Wasim Khan]

From: Wasim Khan 

Increase fdt blob size for lx2160 and lx2162 series
to fix below errors/warnings during device tree fixup.

Unable to update property /soc/spi@210:status, err=FDT_ERR_NOSPACE
Unable to update property /soc/spi@211:status, err=FDT_ERR_NOSPACE
Unable to update property /soc/spi@212:status, err=FDT_ERR_NOSPACE
WARNING: could not set reg FDT_ERR_NOSPACE.
WARNING unable to set iommus: FDT_ERR_NOSPACE

Signed-off-by: Wasim Khan 
---
Change in v2:
- Return error code if fdt_increase_size() fails

 board/freescale/lx2160a/lx2160a.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/freescale/lx2160a/lx2160a.c 
b/board/freescale/lx2160a/lx2160a.c
index f505e82fb9..ba3d62a002 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -828,10 +828,18 @@ int ft_board_setup(void *blob, struct bd_info *bd)
u64 mc_memory_base = 0;
u64 mc_memory_size = 0;
u16 total_memory_banks;
+   int err;
 #if CONFIG_IS_ENABLED(TARGET_LX2160ARDB)
u8 board_rev;
 #endif
 
+   err = fdt_increase_size(blob, 512);
+   if (err) {
+   printf("%s fdt_increase_size: err=%s\n", __func__,
+  fdt_strerror(err));
+   return err;
+   }
+
ft_cpu_setup(blob, bd);
 
fdt_fixup_mc_ddr(_memory_base, _memory_size);
-- 
2.25.1

[PATCH 3/4] usb: ehci-ci: remove redundant PORTSC flag definitions

[Matthias Schiffer]

These definitions are unused, all boards that define portsc flags use
the equivalent PORT_* definitions instead.

Signed-off-by: Markus Niebel 
Signed-off-by: Matthias Schiffer 
---
 include/usb/ehci-ci.h | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/include/usb/ehci-ci.h b/include/usb/ehci-ci.h
index efb2eec5ce7..bf5d26faa53 100644
--- a/include/usb/ehci-ci.h
+++ b/include/usb/ehci-ci.h
@@ -249,17 +249,6 @@ struct usb_ehci {
  * For MXC SOCs
  */
 
-/* values for portsc field */
-#define MXC_EHCI_PHY_LOW_POWER_SUSPEND (1 << 23)
-#define MXC_EHCI_FORCE_FS  (1 << 24)
-#define MXC_EHCI_UTMI_8BIT (0 << 28)
-#define MXC_EHCI_UTMI_16BIT(1 << 28)
-#define MXC_EHCI_SERIAL(1 << 29)
-#define MXC_EHCI_MODE_UTMI (0 << 30)
-#define MXC_EHCI_MODE_PHILIPS  (1 << 30)
-#define MXC_EHCI_MODE_ULPI (2 << 30)
-#define MXC_EHCI_MODE_SERIAL   (3 << 30)
-
 /* values for flags field */
 #define MXC_EHCI_INTERFACE_DIFF_UNI(0 << 0)
 #define MXC_EHCI_INTERFACE_DIFF_BI (1 << 0)
-- 
2.17.1

[PATCH 4/4] usb: ehci-mx6: use phy_type from device tree

[Matthias Schiffer]

Allow using different PHY interfaces for multiple USB controllers. When no
value is set in DT, we fall back to CONFIG_MXC_USB_PORTSC for now to stay
compatible with current board configurations.

This also adds support for the HSIC mode of the i.MX7.

Signed-off-by: Markus Niebel 
Signed-off-by: Matthias Schiffer 
---
 drivers/usb/host/ehci-mx6.c | 25 +++--
 include/usb/ehci-ci.h   |  1 +
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index c3e4170513e..1bd6147c76a 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ehci.h"
 
@@ -435,6 +436,7 @@ struct ehci_mx6_priv_data {
struct clk clk;
struct phy phy;
enum usb_init_type init_type;
+   enum usb_phy_interface phy_type;
 #if !defined(CONFIG_PHY)
int portnr;
void __iomem *phy_addr;
@@ -443,6 +445,24 @@ struct ehci_mx6_priv_data {
 #endif
 };
 
+static u32 mx6_portsc(enum usb_phy_interface phy_type)
+{
+   switch (phy_type) {
+   case USBPHY_INTERFACE_MODE_UTMI:
+   return PORT_PTS_UTMI;
+   case USBPHY_INTERFACE_MODE_UTMIW:
+   return PORT_PTS_UTMI | PORT_PTS_PTW;
+   case USBPHY_INTERFACE_MODE_ULPI:
+   return PORT_PTS_ULPI;
+   case USBPHY_INTERFACE_MODE_SERIAL:
+   return PORT_PTS_SERIAL;
+   case USBPHY_INTERFACE_MODE_HSIC:
+   return PORT_PTS_HSIC;
+   default:
+   return CONFIG_MXC_USB_PORTSC;
+   }
+}
+
 static int mx6_init_after_reset(struct ehci_ctrl *dev)
 {
struct ehci_mx6_priv_data *priv = dev->priv;
@@ -479,7 +499,7 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev)
return 0;
 
setbits_le32(>usbmode, CM_HOST);
-   writel(CONFIG_MXC_USB_PORTSC, >portsc);
+   writel(mx6_portsc(priv->phy_type), >portsc);
setbits_le32(>portsc, USB_EN);
 
mdelay(10);
@@ -641,6 +661,7 @@ static int ehci_usb_probe(struct udevice *dev)
 
priv->ehci = ehci;
priv->init_type = type;
+   priv->phy_type = usb_get_phy_mode(dev_ofnode(dev));
 
 #if CONFIG_IS_ENABLED(CLK)
ret = clk_get_by_index(dev, 0, >clk);
@@ -690,7 +711,7 @@ static int ehci_usb_probe(struct udevice *dev)
 
if (priv->init_type == USB_INIT_HOST) {
setbits_le32(>usbmode, CM_HOST);
-   writel(CONFIG_MXC_USB_PORTSC, >portsc);
+   writel(mx6_portsc(priv->phy_type), >portsc);
setbits_le32(>portsc, USB_EN);
}
 
diff --git a/include/usb/ehci-ci.h b/include/usb/ehci-ci.h
index bf5d26faa53..2cdb3146e86 100644
--- a/include/usb/ehci-ci.h
+++ b/include/usb/ehci-ci.h
@@ -23,6 +23,7 @@
 #define PORT_PTS_ULPI  (2 << 30)
 #define PORT_PTS_SERIAL(3 << 30)
 #define PORT_PTS_PTW   (1 << 28)
+#define PORT_PTS_HSIC  (1 << 25)
 #define PORT_PFSC  (1 << 24) /* Defined on Page 39-44 of the 
mpc5151 ERM */
 #define PORT_PTS_PHCD  (1 << 23)
 #define PORT_PP(1 << 12)
-- 
2.17.1

[PATCH 2/4] include/configs: replace MXC_EHCI_MODE_SERIAL with PORT_PTS_SERIAL

[Matthias Schiffer]

The MXC_EHCI_MODE_ definitions are redundant. Replace MXC_EHCI_MODE_SERIAL
with the equivalent PORT_PTS_SERIAL.

Only the zmx25 platform is affected.

Signed-off-by: Markus Niebel 
Signed-off-by: Matthias Schiffer 
---
 include/configs/zmx25.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/zmx25.h b/include/configs/zmx25.h
index 88a885463d4..8b571da021a 100644
--- a/include/configs/zmx25.h
+++ b/include/configs/zmx25.h
@@ -57,7 +57,7 @@
 #define CONFIG_USB_EHCI_MXC
 #define CONFIG_EHCI_HCD_INIT_AFTER_RESET
 #define CONFIG_MXC_USB_PORT1
-#define CONFIG_MXC_USB_PORTSC  MXC_EHCI_MODE_SERIAL
+#define CONFIG_MXC_USB_PORTSC  PORT_PTS_SERIAL
 #define CONFIG_MXC_USB_FLAGS   (MXC_EHCI_INTERNAL_PHY | MXC_EHCI_IPPUE_DOWN)
 #define CONFIG_EHCI_IS_TDI
 #endif /* CONFIG_CMD_USB */
-- 
2.17.1

[PATCH 1/4] usb: add support for ULPI/SERIAL/HSIC PHY modes

[Matthias Schiffer]

Import usb_phy_interface enum values and DT match strings from the Linux
kernel.

Signed-off-by: Markus Niebel 
Signed-off-by: Matthias Schiffer 
---
 drivers/usb/common/common.c | 3 +++
 include/linux/usb/phy.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index 2a47f40bbab..43564c9fbaf 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -80,6 +80,9 @@ static const char *const usbphy_modes[] = {
[USBPHY_INTERFACE_MODE_UNKNOWN] = "",
[USBPHY_INTERFACE_MODE_UTMI]= "utmi",
[USBPHY_INTERFACE_MODE_UTMIW]   = "utmi_wide",
+   [USBPHY_INTERFACE_MODE_ULPI]= "ulpi",
+   [USBPHY_INTERFACE_MODE_SERIAL]  = "serial",
+   [USBPHY_INTERFACE_MODE_HSIC]= "hsic",
 };
 
 enum usb_phy_interface usb_get_phy_mode(ofnode node)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 1e1217a9583..14b2c7eb2e6 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -16,6 +16,9 @@ enum usb_phy_interface {
USBPHY_INTERFACE_MODE_UNKNOWN,
USBPHY_INTERFACE_MODE_UTMI,
USBPHY_INTERFACE_MODE_UTMIW,
+   USBPHY_INTERFACE_MODE_ULPI,
+   USBPHY_INTERFACE_MODE_SERIAL,
+   USBPHY_INTERFACE_MODE_HSIC,
 };
 
 #if CONFIG_IS_ENABLED(DM_USB)
-- 
2.17.1

Re: Please pull u-boot-marvell/next (watchdog related)

[Stefan Roese]

Hi Tom,

On 20.09.21 15:05, Tom Rini wrote:

On Mon, Sep 20, 2021 at 10:27:31AM +0200, Stefan Roese wrote:


Hi Tom,

please pull the following watchdog related fix:



Applied to u-boot/master (yes, master, I saw it said next in the subject
but I also saw the emails on the patch), thanks!



Thanks. Copy-paste error - the fix was destined for master of course.

Thanks,
Stefan

Re: Please pull u-boot-marvell/next (watchdog related)

[Tom Rini]

On Mon, Sep 20, 2021 at 10:27:31AM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following watchdog related fix:
> 

Applied to u-boot/master (yes, master, I saw it said next in the subject
but I also saw the emails on the patch), thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/5] ARM: rmobile: Enable board detection when FIT is enabled

[Marek Vasut]

On 9/20/21 2:11 PM, Adam Ford wrote:

On Mon, Aug 30, 2021 at 10:40 AM Adam Ford  wrote:


There are three boards from Beacon, RZ/G2 M/N/H which all
use the same board file, but different device trees.
Add code to automatically select the proper device tree
based on the CPU type.

Signed-off-by: Adam Ford 



Marek,

I was wondering if you had any feedback on this series.  You asked if
I could consolidate all three of my RZ/G2 boards to reduce the amount
of duplicated code, so this series attempts to do that.


Please rebase/resend, it was likely missed, sorry.

Re: [PATCH v4 4/5] env: Allow environment files to use the C preprocessor

[Wolfgang Denk]

Dear Simon,

In message 
<20210919125937.v4.4.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> you 
wrote:
>
> +To add additional text to a variable you can use var+=value. This text is
> +merged into the variable during the make process and made available as a
> +single value to U-Boot.

Explained after use.  Move documentation to previous patch?

> + # Deal with +=
> + if (match(var, "(.*)[+]$", var_arr)) {
> + var = var_arr[1]
> + env = vars[var] env
> + }


Hm...  this is (so far) a legal command:

=> setenv foobar+ foo+=bar


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Summit meetings tend to be like panda matings. The expectations  are
always high, and the results usually disappointing."   - Robert Orben

Re: [PATCH v4 3/5] env: Allow U-Boot scripts to be placed in a .env file

[Wolfgang Denk]

Dear Simon,

In message 
<20210919125937.v4.3.If789ba3e2667c46c03eda3386ca84a863baeda55@changeid> you 
wrote:
>
...
> +It is also possible to create an environment file with the name
> +`board//env/.env` for your board. If that file is not present
> +then U-Boot will look for `oard//env/common.env` so that you can

a/oard/board/

> +have a common environment for all vendor boards.

Actually it would be nice to look for `board//env/common.env`
first, and then for `board//env/.env` - and if both
exost, they should be concatenated, so a vendor can keep all common
definitions in the common.env, and have only board specific
definitions in the .env files - otherwise he would have to
repeat everything in the board files, and the common file makes
little sense.

> +This is a plain text file where you can type your environment variables in
> +the form `var=value`. Blank lines and multi-line variables are supported.
> +The conversion script looks for a line that starts with a letter or number
> +and has an equals sign immediately afterwards. Spaces before the = are not
> +permitted. It is a good idea to indent your scripts so that only the 'var='
> +appears at the start of a line.

This is not correct.  Variable names can be more complex:

=> setenv _foo 1
=> setenv ,bar 2
=> setenv /baz 3

etc.

> +For example, for snapper9260 you would create a text file called
> +`board/bluewater/env/snapper9260.env` containing the environment text.
> +
> +Example::
> +
> +stdout=serial
> +#ifdef CONFIG_LCD
> +stdout+=,lcd

Is that a new feature?  I didn't see it documented anywhere?

> +#endif
> +bootcmd=
> +/* U-Boot script for booting */
> +
> +if [ -z ${tftpserverip} ]; then
> +echo "Use 'setenv tftpserverip a.b.c.d' to set IP address."
> +fi
> +
> +usb start; setenv autoload n; bootp;
> +tftpboot ${tftpserverip}:
> +bootm
> +failed=
> +/* Print a message when boot fails */
> +echo CONFIG_SYS_BOARD boot failed - please check your image
> +echo Load address is CONFIG_SYS_LOAD_ADDR

You _must_ define a clear syntax for the file, including indentation
rules.  Otherwise there is plenty chance for incorrect arsing.


> + # Is this the start of a new environment variable?
> + if (match($0, "^([^ =][^ =]*)=(.*)", arr)) {

This is not what you document above.

> + if (length(env) != 0) {
> + # Record the value of the variable now completed
> + vars[var] = env
> + }

What in case of length == 0 ?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Imitation is the sincerest form of plagarism.

Re: [PATCH v3 1/3] ARM: amlogic: add JetHub common config header

[Neil Armstrong]

On 20/09/2021 10:40, Vyacheslav Bocharov wrote:
> JetHub devices uses its own boot sequence with "rescue" button
> 
> Signed-off-by: Vyacheslav Bocharov 
> ---
>  include/configs/jethub.h | 40 
>  1 file changed, 40 insertions(+)
>  create mode 100644 include/configs/jethub.h
> 
> diff --git a/include/configs/jethub.h b/include/configs/jethub.h
> new file mode 100644
> index 00..35f85095ac
> --- /dev/null
> +++ b/include/configs/jethub.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Configuration for JetHome devices
> + * Copyright (C) 2021 Vyacheslav Bocharov
> + * Author: Vyacheslav Bocharov 
> + */
> +
> +#ifndef __JETHUB_CONFIG_H
> +#define __JETHUB_CONFIG_H
> +
> +#if defined(CONFIG_MESON_AXG)
> +#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
> + "bootcmd_rescue=" \
> + "if gpio input 10; then " \
> + "run bootcmd_usb0;" \
> + "fi;\0"
> +#else
> +#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
> + "bootcmd_rescue=" \
> + "if test \"${userbutton}\" = \"true\"; then " \
> + "run bootcmd_mmc0; " \
> + "fi;\0"
> +#endif
> +
> +#define BOOTENV_DEV_NAME_RESCUE(devtypeu, devtypel, instance) \
> + "rescue "
> +
> +#ifndef BOOT_TARGET_DEVICES
> +#define BOOT_TARGET_DEVICES(func) \
> + func(RESCUE, rescue, na) \
> + func(MMC, mmc, 1) \
> + func(MMC, mmc, 0) \
> + BOOT_TARGET_DEVICES_USB(func) \
> + func(PXE, pxe, na) \
> + func(DHCP, dhcp, na)
> +#endif
> +
> +#include 
> +
> +#endif /* __JETHUB_CONFIG_H */
> 

Reviewed-by: Neil Armstrong 

Re: [PATCH] i2c: rcar_i2c: Enable configuring SCL rise and fall times

[Adam Ford]

On Tue, Aug 24, 2021 at 9:10 AM Adam Ford  wrote:
>
> The Linux i2c driver supports i2c-scl-rising-time-ns,
> and i2c-scl-falling-time-ns, but U-Boot uses hard-coded values
> for these values.
>
> Update the calculation by fetching them from the device tree if
> present and use the previous values as the default if they are
> missing.
>
> Signed-off-by: Adam Ford 
>
Do I have the right people in copy?  I was hoping to get some feedback
on this.  My boards use the i2c-scl-rising-time-ns to help properly
set the i2c clocking.

thanks
adam

> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 14bb6603d5..d9ece5e3a8 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -64,6 +64,8 @@ enum rcar_i2c_type {
>  struct rcar_i2c_priv {
> void __iomem*base;
> struct clk  clk;
> +   u32 fall_ns;
> +   u32 rise_ns;
> u32 intdelay;
> u32 icccr;
> enum rcar_i2c_type  type;
> @@ -278,7 +280,7 @@ static int rcar_i2c_set_speed(struct udevice *dev, uint 
> bus_freq_hz)
>  *  = F[sum * ick / 10]
>  *  = F[(ick / 100) * sum / 1000]
>  */
> -   sum = 35 + 200 + priv->intdelay;
> +   sum = priv->fall_ns + priv->rise_ns + priv->intdelay;
> round = (ick + 50) / 100 * sum;
> round = (round + 500) / 1000;
>
> @@ -323,6 +325,10 @@ static int rcar_i2c_probe(struct udevice *dev)
> int ret;
>
> priv->base = dev_read_addr_ptr(dev);
> +   priv->rise_ns = dev_read_u32_default(dev,
> +"i2c-scl-rising-time-ns", 200);
> +   priv->fall_ns = dev_read_u32_default(dev,
> +"i2c-scl-falling-time-ns", 35);
> priv->intdelay = dev_read_u32_default(dev,
>   "i2c-scl-internal-delay-ns", 5);
> priv->type = dev_get_driver_data(dev);
> --
> 2.25.1
>

Re: [PATCH v4 2/5] doc: Move environment documentation to rST

[Wolfgang Denk]

Dear Simon,

In message <20210919185950.3813952-3-...@chromium.org> you wrote:
> Move this from the README to rST format.

Just a few nitpicks...

> diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
> new file mode 100644
> index 000..be785a8f717
> --- /dev/null
> +++ b/doc/usage/environment.rst
> @@ -0,0 +1,382 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Environment Variables
> +=
> +
> +
> +U-Boot supports user configuration using Environment Variables which
> +can be made persistent by saving to Flash memory.

...by saving to persistent storage, for example flash memory.

> +Environment Variables are set using "setenv", printed using
> +"printenv", and saved to Flash using "saveenv". Using "setenv"

Environment Variables are set using "env set" (alias "setenv"),
printed using "env print" (alias "printenv"), and saved to
persistent storage using "env save" (alias "saveenv").
Using "env set" ...

> +Some configuration options can be set using Environment Variables.

This probably needs an explanation what "configuration options'
means here?


> +Image locations
> +---
> +
> +The following image location variables contain the location of images
> +used in booting. The "Image" column gives the role of the image and is
> +not an environment variable name. The other columns are environment
> +variable names. "File Name" gives the name of the file on a TFTP
> +server, "RAM Address" gives the location in RAM the image will be
> +loaded to, and "Flash Location" gives the image's address in NOR
> +flash or offset in NAND flash.
> +
> +*Note* - these variables don't have to be defined for all boards, some
> +boards currently use other variables for these purposes, and some
> +boards use these variables for other purposes.
> +
> += ==  ==
> +Image File Name  RAM Address  Flash Location
> += ==  ==
> +u-bootu-boot u-boot_addr_ru-boot_addr
> +Linux kernel  bootfile   kernel_addr_rkernel_addr
> +device tree blob  fdtfilefdt_addr_r   fdt_addr
> +ramdisk   ramdiskfileramdisk_addr_r   ramdisk_addr
> += ==  ==

Maybe it should be pointed out that this is just a commonly used set
of variable names, used in some other variable definitions, but is
in no way hard coded anywhere in U-Boot code.

OK, I see that "bootfile" and ""fdtfile" are now actually used in
some code - but IMO this is a bad idea and should be fixed.


> +Automatically updated variables
> +---
> +
> +The following environment variables may be used and automatically
> +updated by the network boot commands ("bootp" and "rarpboot"),
> +depending the information provided by your boot server:
> +
> +=  ===
> +Variable   Notes
> +=  ===
> +bootfile   see above
> +dnsip  IP address of your Domain Name Server
> +dnsip2 IP address of your secondary Domain Name Server
> +gatewayip  IP address of the Gateway (Router) to use
> +hostname   Target hostname
> +ipaddr See above
> +netmaskSubnet Mask
> +rootpath   Pathname of the root filesystem on the NFS server
> +serverip   see above
> +=  ===

This list is incomplete; for example, sysboot sets bootfile, too.

For completeness, .flags etc. should be documented, too [but yes,
this is a separate task of course].


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I wrote my name at the top of the page. I wrote down  the  number  of
the  question  ``1''.  After much reflection I put a bracket round it
thus ``(1)''. But thereafter I could not think of anything  connected
with it that was either relevant or true.
- Sir Winston Churchill _My Early Life_ ch. 2

[PATCH v2 1/1] fs: avoid superfluous messages

[Heinrich Schuchardt]

Output like the following is quite irritating:

=> bootefi hello
Scanning disk mmc2.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc1.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc0.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **

Albeit a whole disk may be formatted with a filesystem in most cases
a partition table is used and the whole disk (partition number 0) doesn't
contain a filesytem. Some partitions may only contain a blob. Not seeing a
filesytem on the whole disk or on any partition is only worth a debug
message.

Signed-off-by: Heinrich Schuchardt 
---
v2:
Explicitly mention in the commit message that a whole disk may
carry a filesystem.
---
 fs/fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fs.c b/fs/fs.c
index 7c682582c8..023f89cafe 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -37,7 +37,7 @@ static int fs_type = FS_TYPE_ANY;
 static inline int fs_probe_unsupported(struct blk_desc *fs_dev_desc,
  struct disk_partition *fs_partition)
 {
-   log_err("** Unrecognized filesystem type **\n");
+   log_debug("Unrecognized filesystem type\n");
return -1;
 }
 
-- 
2.30.2

Re: [PATCH 1/5] ARM: rmobile: Enable board detection when FIT is enabled

[Adam Ford]

On Mon, Aug 30, 2021 at 10:40 AM Adam Ford  wrote:
>
> There are three boards from Beacon, RZ/G2 M/N/H which all
> use the same board file, but different device trees.
> Add code to automatically select the proper device tree
> based on the CPU type.
>
> Signed-off-by: Adam Ford 
>

Marek,

I was wondering if you had any feedback on this series.  You asked if
I could consolidate all three of my RZ/G2 boards to reduce the amount
of duplicated code, so this series attempts to do that.

adam
> diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c 
> b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> index c12ff77fb2..b3521fcbc1 100644
> --- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> +++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> @@ -36,3 +36,19 @@ void reset_cpu(void)
>  {
> writel(RST_CODE, RST_CA57RESCNT);
>  }
> +
> +#if IS_ENABLED(CONFIG_MULTI_DTB_FIT)
> +int board_fit_config_name_match(const char *name)
> +{
> +   if (!strcmp(rzg_get_cpu_name(), "R8A774A1") && !strcmp(name, 
> "r8a774a1-beacon-rzg2m-kit"))
> +   return 0;
> +
> +   if (!strcmp(rzg_get_cpu_name(), "R8A774B1") && !strcmp(name, 
> "r8a774b1-beacon-rzg2n-kit"))
> +   return 0;
> +
> +   if (!strcmp(rzg_get_cpu_name(), "R8A774E1") && !strcmp(name, 
> "r8a774e1-beacon-rzg2h-kit"))
> +   return 0;
> +
> +   return -1;
> +}
> +#endif
> --
> 2.25.1
>

Re: [PATCH] board: freescale: lx216x : increase fdt blob size

[Tom Rini]

On Fri, Sep 17, 2021 at 02:18:28PM +0200, Wasim Khan wrote:

> From: Wasim Khan 
> 
> Increase fdt blob size for lx2160 and lx2162 series
> to fix below errors/warnings during device tree fixup.
> 
> Unable to update property /soc/spi@210:status, err=FDT_ERR_NOSPACE
> Unable to update property /soc/spi@211:status, err=FDT_ERR_NOSPACE
> Unable to update property /soc/spi@212:status, err=FDT_ERR_NOSPACE
> WARNING: could not set reg FDT_ERR_NOSPACE.
> WARNING unable to set iommus: FDT_ERR_NOSPACE
> 
> Signed-off-by: Wasim Khan 
> ---
>  board/freescale/lx2160a/lx2160a.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/board/freescale/lx2160a/lx2160a.c 
> b/board/freescale/lx2160a/lx2160a.c
> index f505e82fb9..d03168d6a2 100644
> --- a/board/freescale/lx2160a/lx2160a.c
> +++ b/board/freescale/lx2160a/lx2160a.c
> @@ -828,10 +828,18 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>   u64 mc_memory_base = 0;
>   u64 mc_memory_size = 0;
>   u16 total_memory_banks;
> + int err;
>  #if CONFIG_IS_ENABLED(TARGET_LX2160ARDB)
>   u8 board_rev;
>  #endif
>  
> + err = fdt_increase_size(blob, 512);
> + if (err) {
> + printf("%s fdt_increase_size: err=%s\n", __func__,
> +fdt_strerror(err));
> + return 1;
> + }
> +
>   ft_cpu_setup(blob, bd);

This should return the error we got from fdt_increase_size rather than
1.

-- 
Tom


signature.asc
Description: PGP signature

Modules for carrier boards [Was: Re: Question about extension board used in U-boot]

[Daniel Thompson]

On Sat, Sep 18, 2021 at 08:49:48AM +0200, François Ozog wrote:
> Hi Paul
> 
> Too posting because I think we also need to address this at a higher level.
> 
> i think we discussed this topic quite a while back. I may be wrong but it
> may be Bill Mills who proposed to have an eeprom on the extensions that the
> carrier board can use to detect and fetch proper overlay. Another way would
> be that the contract between the extension board and the carrier board
> includes an i2c accessible storage to fetch an overlay that would identify
> the board and give all details.

What you're describing sounds exactly like Raspberry Pi HATs work:
https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md

Similarly Beagleboard capes use rely on I2C EEPROMs for make them
discoverable, although I don't think all have to have a built-in
overlay (IIRC because they joined the party too early).

In other words there's plenty of prior art here and, as new hardware
standards come out, it should be much easier for them to find this prior
art. However I'm near certain mistakes will still be made...


> Bottom line, a software only solution seems not entirely satisfying.
> In that suboptimal case, U-Boot shall be able to assemble a DT for itself
> and another for OS (may be same in some cases) through scripting. And in
> this case, come your questions  below.

Sub-optimal or not[1] the u-boot extension board code still looks like it
would be a good starting point even for boards with non-discoverable
extensions (96Boards CE 1.0 for example).

If implementing on a board with non-discoverable extensions then I would
consider implementing "extension scan" to report non-discoverable modules
(e.g. from an internal list) and proposing patches to that "extension
apply all" would not enable non-discoverable boards (so that non-
discoverable boards would have to be enabled by injecting a "extension
apply " into the boot scripts).

Of course, I may have overlooked a better existing mechanism in u-boot
but that's what I would start with until I was corrected by
maintainers ;-) .


Daniel.


[1] And also extremely off-topic for Paul since his (a) boards are
discoverable and (b) the extension framework can't fire up early
enough for TPM extensions ;-) .



> Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) 
> a écrit :
> 
> > Hi all,
> >
> >
> > I have some questions about how to implement extension board usage.
> > My case is on imx8mm-cl-iot-gate. It can add three different types of
> > extension boards.
> > One of the extension boards is SPI extension which have 3 empty slots.
> > And you can add
> > some small boards onto it. One of them is a "TPM2" module.
> >
> >
> > My first question is if I want to use tpm2 in U-boot for measured boot.
> > How to implement this right? Currently I just modify the dts used by
> > U-boot to let it drive
> > the extension board. And let it drive the TPM. But it is not good for
> > upstreaming because
> > when other types of extension boards installed then it is not working.
> > Where to implement this? What is the best practice of this?
> 
> 
> > The second question is about extension manager.
> > I have read the extension.rst. I think I'll implement this anyway
> > because then
> > I can have a command to query what type of extension boards I have.
> > And if the extension board is the 3 slots one. I can then detect which
> > slot is the TPM.
> > I'll implement this anyway because the "extension" command is convenient
> > for users.
> > But it seems to me that it only solves the problem for Linux kernel.
> > It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
> > extension board.
> > But it is too late for U-boot itself, right?
> >
> >
> > The third question is I'm also dong SystemReady IR certificate. That means
> > the dtb for Linux is directly provided by U-boot. We use U-boot dtb
> > directly to Linux
> > kernel. In this case, how to modify that dts dynamically to feed to the
> > Linux kernel by
> > the extension manager?
> > What is the best practice if I want to use U-boot dts for Linux in
> > implementation?
> >
> >
> > Thanks a lot.
> >
> >
> > Yours,
> > Paul
> >
> >
> > --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.o...@linaro.org | Skype: ffozog
> ___
> boot-architecture mailing list
> boot-architect...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH v4 3/5] sf: Tidy up code to avoid #ifdef

[Pratyush Yadav]

Hi Simon,

On 19/09/21 03:49PM, Simon Glass wrote:
> Update this code to use IS_ENABLED() instead.
> 
> Signed-off-by: Simon Glass 
> 
> Reviewed-by: Pratyush Yadav 

Nitpick: Trailers shouldn't have a blank line between them. I see it for 
this patch and 4/5 as well. It probably doesn't matter, but I wonder if 
it will trip up some tools that work on commit trailers like 
git-interpret-trailers. Something you might want to fix in your 
workflow...

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v2 2/3] ARM: amlogic: add JetHub D1/H1 device support

[Vyacheslav]

20.09.2021 09:43, Neil Armstrong wrote:

Hi,

On 19/09/2021 17:52, Vyacheslav Bocharov wrote:

Add support for new home automation devices.


While applying I had a few warnings:


+   if (!env_get("serial")) {
+   len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,


ERROR: trailing whitespace
#777: FILE: board/amlogic/jethub-j80/jethub-j80.c:48:
+^I^Ilen = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial, $

CHECK: Alignment should match open parenthesis
#778: FILE: board/amlogic/jethub-j80/jethub-j80.c:49:
+   len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
+   EFUSE_SN_SIZE);

CHECK: Alignment should match open parenthesis
#785: FILE: board/amlogic/jethub-j80/jethub-j80.c:56:
+   len = meson_sm_read_efuse(EFUSE_USID_OFFSET, usid,
+   EFUSE_USID_SIZE);


I'll double-check everything and resend a new version of the patches.



This file isn't part of any MAINTAINERS file, either add it to the s400 one or 
the j80 one.


I'll add it to jethub-j80/MAINTAINERS.

Thanks!

Re: Rename of the u-boot-atmel custodian tree

[Eugen.Hristev]

On 8/26/21 10:17 AM, Eugen Hristev - M18282 wrote:
> Hello everyone,
> 
> I plan to rename the u-boot-atmel tree to u-boot-at91 .
> 
> It's been more than 5 years since Atmel is part of Microchip, and the
> name is slowly being changed to reflect the new reality.
> 
> It makes more sense to have the custodian tree named u-boot-at91 , as
> this tree is used only for patches related to the at91 boards and
> drivers (not any other former Atmel product, nor any other Microchip
> product ). I won't be naming it u-boot-microchip since Microchip does
> much more than just the former Atmel MPUs (AT91 architecture) .
> 
> This means, however, that all remotes to this tree have to be updated.
> I do not see any other side effect at this moment.
> 
> I will wait some more time , few weeks or one month, before making this
> change, to allow anyone to comment on this.
> 
> Thanks,
> Eugen
> 


Former u-boot-atmel tree is now u-boot-at91, available at :

https://source.denx.de/u-boot/custodians/u-boot-at91

Tom, do you know how can we update the U-boot denx wiki ?
https://www.denx.de/wiki/U-Boot/Custodians

Eugen

Re: [PATCH 1/2] include: dt-bindings: mfd: add atmel flexcom include file

[Eugen.Hristev]

On 8/27/21 1:44 PM, Eugen Hristev wrote:
> Add dt-bindings include file for Atmel Flexcom hardware block.
> This file is copied from Linux kernel.
> It is used in devicetrees from Linux.
> 
> Signed-off-by: Eugen Hristev 
> ---

Applied series to u-boot-atmel/next

Re: [PATCH] ARM: at91: remove references to RM9200DK

[Eugen.Hristev]

On 8/25/21 1:27 PM, Eugen Hristev wrote:
> The AT91 RM9200DK board was removed long time ago.
> Remove existing references that were not cleaned up.
> 
> Fixes: 1c85752258 ("ARM: remove broken "at91rm9200dk" board")
> Signed-off-by: Eugen Hristev 
> ---


Applied to u-boot-atmel/next

Re: [PATCH] net: remove unused CONFIG_DRIVER_AT91EMAC_*

[Eugen.Hristev]

On 8/28/21 4:37 PM, Ramon Fried wrote:
> On Wed, Aug 25, 2021 at 1:28 PM Eugen Hristev
>  wrote:
>>
>> AT91EMAC driver is unused, thus removing.
>>
>> Signed-off-by: Eugen Hristev 
>> ---

>> 2.25.1
>>
> Reviewd-by: Ramon Fried 
> 

Applied to u-boot-atmel/next

Re: [PATCH] board: pm926x: remove unused CONFIG_SYS_AT91_CPU_NAME

[Eugen.Hristev]

On 8/24/21 4:02 PM, Eugen Hristev wrote:
> CONFIG_SYS_AT91_CPU_NAME looks to be unused.
> Remove it and remove it from config_whitelist.txt
> 
> Signed-off-by: Eugen Hristev 
> ---

Applied to u-boot-atmel/next

Re: [PATCH 1/5] arm: apple: Add initial support for Apple's M1 SoC

[Mark Kettenis]

> From: Simon Glass 
> Date: Sun, 19 Sep 2021 21:15:57 -0600
> 
> Hi Mark,
> 
> On Sat, 18 Sept 2021 at 07:55, Mark Kettenis  wrote:
> >
> > Add support for Apple's M1 SoC that is used in "Apple Silicon"
> > Macs.  This builds a basic U-Boot that can be used as a payload
> > for the m1n1 boot loader being developed by the Asahi Linux
> > project.
> >
> > Signed-off-by: Mark Kettenis 
> > ---
> >  arch/arm/Kconfig|  22 
> >  arch/arm/Makefile   |   1 +
> >  arch/arm/mach-apple/Kconfig |  18 
> >  arch/arm/mach-apple/Makefile|   4 +
> >  arch/arm/mach-apple/board.c | 158 
> >  arch/arm/mach-apple/lowlevel_init.S |  16 +++
> >  configs/apple_m1_defconfig  |  14 +++
> >  include/configs/apple.h |  38 +++
> >  8 files changed, 271 insertions(+)
> >  create mode 100644 arch/arm/mach-apple/Kconfig
> >  create mode 100644 arch/arm/mach-apple/Makefile
> >  create mode 100644 arch/arm/mach-apple/board.c
> >  create mode 100644 arch/arm/mach-apple/lowlevel_init.S
> >  create mode 100644 configs/apple_m1_defconfig
> >  create mode 100644 include/configs/apple.h
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index b5bd3284cd..7cdea1f615 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -895,6 +895,26 @@ config ARCH_NEXELL
> > select DM
> > select GPIO_EXTRA_HEADER
> >
> > +config ARCH_APPLE
> > +   bool "Apple SoCs"
> > +   select ARM64
> > +   select LINUX_KERNEL_IMAGE_HEADER
> > +   select POSITION_INDEPENDENT
> > +   select BLK
> > +   select DM
> > +   select DM_KEYBOARD
> > +   select DM_SERIAL
> > +   select DM_USB
> > +   select DM_VIDEO
> > +   select CMD_USB
> > +   select MISC
> > +   select OF_CONTROL
> > +   select OF_BOARD
> > +   select USB
> > +   imply CMD_DM
> > +   imply CMD_GPT
> > +   imply DISTRO_DEFAULTS
> 
> Suggest sorting these

As in sort all the selects alphabetically and sort all the implies
alphabetically seperately?

Does my use of impy here even make sense?

This whole Kconfig stuff is a bit alien to me and I must say that it
isn't obvious what "best-practice" is in this area...

> > +
> >  config ARCH_OWL
> > bool "Actions Semi OWL SoCs"
> > select DM
> > @@ -1932,6 +1952,8 @@ config ISW_ENTRY_ADDR
> >   image headers.
> >  endif
> >
> > +source "arch/arm/mach-apple/Kconfig"
> > +
> >  source "arch/arm/mach-aspeed/Kconfig"
> >
> >  source "arch/arm/mach-at91/Kconfig"
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index c68e598a67..44178c204b 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -51,6 +51,7 @@ PLATFORM_CPPFLAGS += $(arch-y) $(tune-y)
> >
> >  # Machine directory name.  This list is sorted alphanumerically
> >  # by CONFIG_* macro name.
> > +machine-$(CONFIG_ARCH_APPLE)   += apple
> >  machine-$(CONFIG_ARCH_ASPEED)  += aspeed
> >  machine-$(CONFIG_ARCH_AT91)+= at91
> >  machine-$(CONFIG_ARCH_BCM283X) += bcm283x
> > diff --git a/arch/arm/mach-apple/Kconfig b/arch/arm/mach-apple/Kconfig
> > new file mode 100644
> > index 00..66cab91b2a
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/Kconfig
> > @@ -0,0 +1,18 @@
> > +if ARCH_APPLE
> > +
> > +config SYS_TEXT_BASE
> > +   default 0x
> > +
> > +config SYS_CONFIG_NAME
> > +   default "apple"
> > +
> > +config SYS_SOC
> > +   default "m1"
> > +
> > +config SYS_MALLOC_LEN
> > +   default 0x400
> > +
> > +config SYS_MALLOC_F_LEN
> > +   default 0x4000
> > +
> > +endif
> > diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> > new file mode 100644
> > index 00..e74a8c9df1
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +obj-y += board.o
> > +obj-y += lowlevel_init.o
> > diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
> > new file mode 100644
> > index 00..0c8b35292e
> > --- /dev/null
> > +++ b/arch/arm/mach-apple/board.c
> > @@ -0,0 +1,158 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2021 Mark Kettenis 
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static struct mm_region apple_mem_map[] = {
> > +   {
> > +   /* I/O */
> > +   .virt = 0x2,
> > +   .phys = 0x2,
> > +   .size = 8UL * SZ_1G,
> > +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > +PTE_BLOCK_NON_SHARE |
> > +PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > +   }, {
> > +   /* I/O */
> > +   .virt = 0x5,
> > +   .phys = 0x5,
> > +   .size = 2UL * 

Re: [PATCH 5/5] doc: board: apple: Add Apple M1 documentation

[Igor Opaniuk]

On Sat, Sep 18, 2021 at 4:56 PM Mark Kettenis  wrote:
>
> Provide preliminary instructions on how to get U-Boot to run on
> Apple Silicon Macs.
>
> Signed-off-by: Mark Kettenis 
> ---
>  doc/board/apple/index.rst |  9 +++
>  doc/board/apple/m1.rst| 56 +++
>  doc/board/index.rst   |  1 +
>  3 files changed, 66 insertions(+)
>  create mode 100644 doc/board/apple/index.rst
>  create mode 100644 doc/board/apple/m1.rst
>
> diff --git a/doc/board/apple/index.rst b/doc/board/apple/index.rst
> new file mode 100644
> index 00..8446847818
> --- /dev/null
> +++ b/doc/board/apple/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Apple
> +=
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   m1
> diff --git a/doc/board/apple/m1.rst b/doc/board/apple/m1.rst
> new file mode 100644
> index 00..2f2d940a4c
> --- /dev/null
> +++ b/doc/board/apple/m1.rst
> @@ -0,0 +1,56 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +U-Boot for Apple Silicon Macs
> +=
> +
> +Allows Apple Silicon Macs to boot U-Boot via the m1n1 bootloader
> +developed by the Asahi Linux project.  At this point the machines with
> +the following SoCs work:
> +
> + - Apple M1 SoC
> +
> +On these SoCs the following hardware is supported:
> +
> + - S5L serial port
> + - Framebuffer
> + - USB 3.1 Type-C ports
> +
> +Device trees are currently provided for the M1 Mac mini (2020, J274)
> +and M1 MacBook Pro 13" (2020, J293).  The M1 MacBook Air (2020) is
> +expected to work with the J293 device tree.  The M1 iMac (2021) may
> +work with the J274 device tree.
> +
> +Building U-Boot
> +---
> +
> +.. code-block:: bash
> +
> +$ export CROSS_COMPILE=aarch64-none-elf-
> +$ make apple_m1_defconfig
> +$ make
> +
> +This will build ``u-boot-nodtb.bin`` as well as devices trees for some
> +of the supported machines.  These device trees can be found in the
> +``arch/arm/dts`` subdirectory of your build.
> +
> +Image creation
> +--
> +
> +In order to run U-Boot on an Apple Silicon Mac, U-Boot has to be used
> +as a payload for the m1n1 bootloader.  Instructions for building m1n1
> +can be found here:
> +
> +https://github.com/AsahiLinux/docs/wiki/SW%3Am1n1
> +
> +.. code-block:: bash
> +
> +$ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho
> +
> +Image installation
> +--
> +
> +Instructions on how to install U-Boot on your Mac can be found at:
> +
> +https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
> +
> +Just replace ``m1n1.macho`` with ``u-boot.macho`` in the instructions.
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 33087074fa..0add55b5d3 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -10,6 +10,7 @@ Board-specific doc
> advantech/index
> AndesTech/index
> amlogic/index
> +   apple/index
> atmel/index
> congatec/index
> coreboot/index
> --
> 2.33.0
>

Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk

[PATCH v3 2/3] ARM: amlogic: add JetHub D1/H1 device support

[Vyacheslav Bocharov]

Add support for new home automation devices.

JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation controller 
with the following features:
- DIN Rail Mounting case
- Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 512Mb/1GB DDR3
- 8/16GB eMMC flash
- 1 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
Bluetooth 4.2.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- 2 x gpio LEDS
- GPIO user Button
- 1 x 1-Wire
- 2 x RS-485
- 4 x dry contact digital GPIO inputs
- 3 x relay GPIO outputs
- DC source with a voltage of 9 to 56 V / Passive POE

JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation controller 
with the following features:
- Square plastic case
- Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 1GB DDR3
- 8/16GB eMMC flash
- 2 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- MicroSD 2.x/3.x/4.x DS/HS cards.
- 1 x gpio LED
- ADC user Button
- DC source 5V microUSB with serial console

Patches from:
- JetHub H1
  https://lore.kernel.org/r/20210915085715.1134940-4-ad...@lexina.in
  https://git.kernel.org/amlogic/c/abfaae24ecf3e7f00508b60fa05e2b6789b8f607
- JetHub D1
  https://lore.kernel.org/r/20210915085715.1134940-5-ad...@lexina.in
  https://git.kernel.org/amlogic/c/8e279fb2903990cc6296ec56b3b80b2f854b6c79

Signed-off-by: Vyacheslav Bocharov 
Reviewed-by: Neil Armstrong 
---
 arch/arm/dts/Makefile |   2 +
 .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
 .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
 board/amlogic/jethub-j80/MAINTAINERS  |   9 +
 board/amlogic/jethub-j80/Makefile |   6 +
 board/amlogic/jethub-j80/jethub-j80.c |  68 
 configs/jethub_j100_defconfig |  55 +++
 configs/jethub_j80_defconfig  |  63 +++
 8 files changed, 805 insertions(+)
 create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
 create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
 create mode 100644 board/amlogic/jethub-j80/Makefile
 create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
 create mode 100644 configs/jethub_j100_defconfig
 create mode 100644 configs/jethub_j80_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f0160d2dc0..d1893a9812 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,10 +169,12 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxl-s905x-libretech-cc-v2.dtb \
meson-gxl-s905x-khadas-vim.dtb \
meson-gxl-s905d-libretech-pc.dtb \
+   meson-gxl-s905w-jethome-jethub-j80.dtb \
meson-gxm-khadas-vim2.dtb \
meson-gxm-s912-libretech-pc.dtb \
meson-gxm-wetek-core2.dtb \
meson-axg-s400.dtb \
+   meson-axg-jethome-jethub-j100.dtb \
meson-g12a-u200.dtb \
meson-g12a-sei510.dtb \
meson-g12b-gtking.dtb \
diff --git a/arch/arm/dts/meson-axg-jethome-jethub-j100.dts 
b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
new file mode 100644
index 00..5783732dc6
--- /dev/null
+++ b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
@@ -0,0 +1,361 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Vyacheslav Bocharov 
+ * Copyright (c) 2020 JetHome
+ * Author: Aleksandr Kazantsev 
+ * Author: Alexey Shevelkin 
+ * Author: Vyacheslav Bocharov 
+ */
+
+/dts-v1/;
+
+#include "meson-axg.dtsi"
+#include 
+#include 
+
+/ {
+   compatible = "jethome,jethub-j100", "amlogic,a113d", 
"amlogic,meson-axg";
+   model = "JetHome JetHub J100";
+   aliases {
+   serial0 = _AO;   /* Console */
+   serial1 = _AO_B; /* External UART (Wireless Module) */
+   ethernet0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   /* 1024MB RAM */
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+
+   reserved-memory {
+   linux,cma {
+   size = <0x0 0x40>;
+   };
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_3v3: regulator-vcc_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_3v3>;
+   regulator-always-on;
+   };
+
+   vcc_5v: regulator-vcc_5v {
+   compatible = "regulator-fixed";
+

[PATCH v3 3/3] ARM: amlogic: add JetHub D1/H1 docs

[Vyacheslav Bocharov]

Fix doc/board/amlogic/index.rst:
- Add S905W to S905X column.
- Add JetHub devices to the corresponding columns.
- Fix tabs to spaces for table alignment

Add doc/board/amlogic files:
- jethub-j100.rst
- jethub-j80.rst

Signed-off-by: Vyacheslav Bocharov 
Reviewed-by: Neil Armstrong 
---
 doc/board/amlogic/index.rst   | 128 +++---
 doc/board/amlogic/jethub-j100.rst | 108 +
 doc/board/amlogic/jethub-j80.rst  |  97 ++
 3 files changed, 270 insertions(+), 63 deletions(-)
 create mode 100644 doc/board/amlogic/jethub-j100.rst
 create mode 100644 doc/board/amlogic/jethub-j80.rst

diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
index 2913ab281a..c18f1b7e71 100644
--- a/doc/board/amlogic/index.rst
+++ b/doc/board/amlogic/index.rst
@@ -10,69 +10,69 @@ An up-do-date matrix is also available on: 
http://linux-meson.com
 
 This matrix concerns the actual source code version.
 
-+---+---+-+--+++-+--+
-|  | S905  | S905X   | S912 | 
A113X  | S905X2 | S922X   | S905X3   |
-|  |   | S805X   | S905D|  
  | S905D2 | A311D   | S905D3   |
-|  |   | |  |  
  | S905Y2 | |  |
-+===+===+=+==+++=+==+
-| Boards   | Odroid-C2 | P212| Khadas 
VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
-|  | Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
  | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
-|  | P200  | LibreTech-CC v1 | WeTek Core2  |  
  || GT-King/Pro | Odroid-C4|
-|  | P201  | LibreTech-AC v2 |  |  
  || GSKing-X| Odroid-HC4   |
-|   |   | |  | 
   || | BananaPi-M5  |
-+---+---+-+--+++-+--+
-| UART | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Pinctrl/GPIO | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Clock Control| **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| PWM  | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Reset Control| **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Infrared Decoder | No| No  | No   | 
No | No | No  | No   |
-+---+---+-+--+++-+--+
-| Ethernet | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Multi-core   | **Yes**   | **Yes** | **Yes**  | 
**Yes**| **Yes**| **Yes** | **Yes**  |
-+---+---+-+--+++-+--+
-| Fuse access  | **Yes**   | **Yes** |**Yes**   
|**Yes** |**Yes** |**Yes**  | **Yes**  |
-+---+---+-+--+++-+--+
-| SPI (FC) | **Yes**   | **Yes** | **Yes**  | 
**Yes**|**Yes**   

[PATCH v3 0/3] ARM: meson: add support for JetHub D1/H1

[Vyacheslav Bocharov]

Add support for new home automation devices manufactured by JetHome.
Patches prepared for use with the "ARM: meson: Sync Amlogic DT from Linux 5.14" 
patch series by Neil Armstrong

JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation controller 
with the following features:
- DIN Rail Mounting case
- Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 512Mb/1GB DDR3
- 8/16GB eMMC flash
- 1 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
Bluetooth 4.2.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- 2 x gpio LEDS
- GPIO user Button
- 1 x 1-Wire
- 2 x RS-485
- 4 x dry contact digital GPIO inputs
- 3 x relay GPIO outputs
- DC source with a voltage of 9 to 56 V / Passive POE

JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation controller 
with the following features:
- Square plastic case
- Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
- no video out
- 1GB DDR3
- 8/16GB eMMC flash
- 2 x USB 2.0
- 1 x 10/100Mbps ethernet
- WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
- TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
Zigbee 3.0 support.
- MicroSD 2.x/3.x/4.x DS/HS cards.
- 1 x gpio LED
- ADC user Button
- DC source 5V microUSB with serial console

Changes from v2:
- fix "Alignment should match open parenthesis" in 
board/amlogic/jethub-j80/jethub-j80.c
- add missing files to board/amlogic/jethub-j80/MAINTAINERS
- fix unexpected unindent in doc files

Changes from v1:
- fix BOOT_TARGET_DEVICES in jethub.h (patch 1/3)
- add lore URLs to description (patch 2/3)

Signed-off-by: Vyacheslav Bocharov 

Vyacheslav Bocharov (3):
  ARM: amlogic: add JetHub common config header
  ARM: amlogic: add JetHub D1/H1 device support
  ARM: amlogic: add JetHub D1/H1 docs

 arch/arm/dts/Makefile |   2 +
 .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
 .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
 board/amlogic/jethub-j80/MAINTAINERS  |   9 +
 board/amlogic/jethub-j80/Makefile |   6 +
 board/amlogic/jethub-j80/jethub-j80.c |  68 
 configs/jethub_j100_defconfig |  55 +++
 configs/jethub_j80_defconfig  |  63 +++
 doc/board/amlogic/index.rst   | 128 ---
 doc/board/amlogic/jethub-j100.rst | 108 ++
 doc/board/amlogic/jethub-j80.rst  |  97 +
 include/configs/jethub.h  |  40 ++
 12 files changed, 1115 insertions(+), 63 deletions(-)
 create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
 create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
 create mode 100644 board/amlogic/jethub-j80/Makefile
 create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
 create mode 100644 configs/jethub_j100_defconfig
 create mode 100644 configs/jethub_j80_defconfig
 create mode 100644 doc/board/amlogic/jethub-j100.rst
 create mode 100644 doc/board/amlogic/jethub-j80.rst
 create mode 100644 include/configs/jethub.h

-- 
2.30.2

[PATCH v3 1/3] ARM: amlogic: add JetHub common config header

[Vyacheslav Bocharov]

JetHub devices uses its own boot sequence with "rescue" button

Signed-off-by: Vyacheslav Bocharov 
---
 include/configs/jethub.h | 40 
 1 file changed, 40 insertions(+)
 create mode 100644 include/configs/jethub.h

diff --git a/include/configs/jethub.h b/include/configs/jethub.h
new file mode 100644
index 00..35f85095ac
--- /dev/null
+++ b/include/configs/jethub.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Configuration for JetHome devices
+ * Copyright (C) 2021 Vyacheslav Bocharov
+ * Author: Vyacheslav Bocharov 
+ */
+
+#ifndef __JETHUB_CONFIG_H
+#define __JETHUB_CONFIG_H
+
+#if defined(CONFIG_MESON_AXG)
+#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
+   "bootcmd_rescue=" \
+   "if gpio input 10; then " \
+   "run bootcmd_usb0;" \
+   "fi;\0"
+#else
+#define BOOTENV_DEV_RESCUE(devtypeu, devtypel, instance) \
+   "bootcmd_rescue=" \
+   "if test \"${userbutton}\" = \"true\"; then " \
+   "run bootcmd_mmc0; " \
+   "fi;\0"
+#endif
+
+#define BOOTENV_DEV_NAME_RESCUE(devtypeu, devtypel, instance) \
+   "rescue "
+
+#ifndef BOOT_TARGET_DEVICES
+#define BOOT_TARGET_DEVICES(func) \
+   func(RESCUE, rescue, na) \
+   func(MMC, mmc, 1) \
+   func(MMC, mmc, 0) \
+   BOOT_TARGET_DEVICES_USB(func) \
+   func(PXE, pxe, na) \
+   func(DHCP, dhcp, na)
+#endif
+
+#include 
+
+#endif /* __JETHUB_CONFIG_H */
-- 
2.30.2

Re: [PATCH 3/5] misc: Add Apple DART driver

[Mark Kettenis]

> From: Simon Glass 
> Date: Sun, 19 Sep 2021 21:16:00 -0600
> 
> Hi Mark,
> 
> On Sat, 18 Sept 2021 at 07:55, Mark Kettenis  wrote:
> >
> > The DART is an IOMMU that is used on Apple's M1 SoC.  This driver
> > supports the DART in bypass mode as well as in a mode where it
> > creates a 1:1 mapping of a subset of RAM as not all DARTs support
> > bypass mode.  The USB3 ports integrated on the SoC use a DART
> > that supports bypass mode.  The 1:1 mapping will be used in the
> > future to support other devices such as the PCIe host bridge
> > of the M1 SoC.
> >
> > Signed-off-by: Mark Kettenis 
> > ---
> >  drivers/misc/Kconfig  |   7 ++
> >  drivers/misc/Makefile |   1 +
> >  drivers/misc/apple_dart.c | 171 ++
> >  3 files changed, 179 insertions(+)
> >  create mode 100644 drivers/misc/apple_dart.c
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 997b713221..d70b060e74 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -38,6 +38,13 @@ config ALTERA_SYSID
> >   Select this to enable a sysid for Altera devices. Please find
> >   details on the "Embedded Peripherals IP User Guide" of Altera.
> >
> > +config APPLE_DART
> > +   bool "Apple DART support"
> > +   depends on MISC && ARCH_APPLE
> > +   default y
> > +   help
> > + Enable support for the DART on Apple SoCs.
> 
> Should have at least 3 lines. E.g. what does DART stand for, what does
> it do and what does the driver support?

Sure.  The DART is what we usually call an IOMMU.

> > +
> >  config ATSHA204A
> > bool "Support for Atmel ATSHA204A module"
> > depends on MISC
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index b64cd2a4de..f666cd392d 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -29,6 +29,7 @@ endif
> >  endif
> >  obj-$(CONFIG_ALI152X) += ali512x.o
> >  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
> > +obj-$(CONFIG_APPLE_DART) += apple_dart.o
> >  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
> >  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
> >  obj-$(CONFIG_DS4510)  += ds4510.o
> > diff --git a/drivers/misc/apple_dart.c b/drivers/misc/apple_dart.c
> > new file mode 100644
> > index 00..f619a624d0
> > --- /dev/null
> > +++ b/drivers/misc/apple_dart.c
> > @@ -0,0 +1,171 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2021 Mark Kettenis 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DART_PARAMS2   0x0004
> > +#define  DART_PARAMS2_BYPASS_SUPPORT   BIT(0)
> > +#define DART_TLB_OP0x0020
> > +#define  DART_TLB_OP_OPMASK(0xfff << 20)
> > +#define  DART_TLB_OP_FLUSH (0x001 << 20)
> > +#define  DART_TLB_OP_BUSY  BIT(2)
> > +#define DART_TLB_OP_SIDMASK0x0034
> > +#define DART_ERROR_STATUS  0x0040
> > +#define DART_TCR(sid)  (0x0100 + 4 * (sid))
> > +#define  DART_TCR_TRANSLATE_ENABLE BIT(7)
> > +#define  DART_TCR_BYPASS_DART  BIT(8)
> > +#define  DART_TCR_BYPASS_DAPF  BIT(12)
> > +#define DART_TTBR(sid, idx)(0x0200 + 16 * (sid) + 4 * (idx))
> > +#define  DART_TTBR_VALID   BIT(31)
> > +#define  DART_TTBR_SHIFT   12
> > +
> > +struct apple_dart_priv {
> 
> How about s/apple_dart/dart/ ?
> 
> It makes the code easier to read.

I think using apple_dart_ consistently as a prefix makes more sense.

> > +   struct clk_bulk clks;
> > +   void *base;
> > +};
> > +
> > +dma_addr_t apple_dart_bus_start;
> > +phys_addr_t apple_dart_phys_start;
> > +phys_size_t apple_dart_size = SZ_512M;
> 
> Try to avoid variables in drivers. Can these go in a priv struct?

Not really since the intent is that these variables specify a global
"window" that is mapped 1:1 into all the DARTs.

> > +
> > +static void apple_dart_flush_tlb(struct apple_dart_priv *priv)
> 
> comments on these functions
> 
> > +{
> > +   u32 status;
> > +
> > +   writel(0x, priv->base + DART_TLB_OP_SIDMASK);
> > +   writel(DART_TLB_OP_FLUSH, priv->base + DART_TLB_OP);
> > +
> > +   for (;;) {
> > +   status = readl(priv->base + DART_TLB_OP);
> > +   if ((status & DART_TLB_OP_OPMASK) == 0)
> > +   break;
> > +   if ((status & DART_TLB_OP_BUSY) == 0)
> > +   break;
> > +   }
> > +}
> > +
> > +static int apple_dart_clk_init(struct udevice *dev,
> > +  struct apple_dart_priv *priv)
> > +{
> > +   int ret;
> > +
> > +   ret = clk_get_bulk(dev, >clks);
> > +   if (ret == -ENOSYS || ret == -ENOENT)
> 
> Does -ENOSYS not indicate an error? If it doesn't, I think a comment
> would help here.

So we just learned that what we previously considered to be clocks are
really better modelled as power domains.  So this code will go away.

> > +   return 0;
> > +   if 

Please pull u-boot-marvell/next (watchdog related)

[Stefan Roese]

Hi Tom,

please pull the following watchdog related fix:


- wdt: dw: Fix passing NULL pointer to reset functions (Sean)


Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=114=results

Thanks,
Stefan

The following changes since commit 3f571228a5340e84123ea7330e2c9cdaea99e733:

  Merge tag 'dm-pull-18sep21' of 
https://source.denx.de/u-boot/custodians/u-boot-dm (2021-09-19 10:38:20 
-0400)


are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-marvell.git

for you to fetch changes up to b31077feca2276f0860706d1843f548baae68aee:

  wdt: dw: Fix passing NULL pointer to reset functions (2021-09-20 
07:39:29 +0200)



Sean Anderson (1):
  wdt: dw: Fix passing NULL pointer to reset functions

 drivers/watchdog/designware_wdt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

Re: [PATCH] wdt: dw: Fix passing NULL pointer to reset functions

[Stefan Roese]

On 11.09.21 21:11, Sean Anderson wrote:

reset_*_bulk expects a real pointer.

Fixes: 4f7abafe1c ("driver: watchdog: reset watchdog in designware_wdt_stop() 
function")
Signed-off-by: Sean Anderson 


Applied to u-boot-marvell/master

Thanks,
Stefan


---

  drivers/watchdog/designware_wdt.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
index afed81e6c6..cfec29bd15 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -22,7 +22,7 @@
  struct designware_wdt_priv {
void __iomem*base;
unsigned intclk_khz;
-   struct reset_ctl_bulk *resets;
+   struct reset_ctl_bulk resets;
  };
  
  /*

@@ -99,11 +99,11 @@ static int designware_wdt_stop(struct udevice *dev)
  if (CONFIG_IS_ENABLED(DM_RESET)) {
int ret;
  
-		ret = reset_assert_bulk(priv->resets);

+   ret = reset_assert_bulk(>resets);
if (ret)
return ret;
  
-		ret = reset_deassert_bulk(priv->resets);

+   ret = reset_deassert_bulk(>resets);
if (ret)
return ret;
}
@@ -156,11 +156,11 @@ static int designware_wdt_probe(struct udevice *dev)
  #endif
  
  	if (CONFIG_IS_ENABLED(DM_RESET)) {

-   ret = reset_get_bulk(dev, priv->resets);
+   ret = reset_get_bulk(dev, >resets);
if (ret)
goto err;
  
-		ret = reset_deassert_bulk(priv->resets);

+   ret = reset_deassert_bulk(>resets);
if (ret)
goto err;
}




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Re: Two jobs at once on denx-vulcan?

[Harald Seiler]

Hi,

On Sat, 2021-09-18 at 10:37 -0600, Simon Glass wrote:
> Hi,
> 
> Is there something screwy with this? It seems that denx-vulcan does
> two builds at once?
> 
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/323540

Hm, I did some changes to the vulcan runner which might have caused
this... But still, even if it is running multiple jobs in parallel, they
should still be isolated, so how does this lead to a build failure?

-- 
Harald

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62  Fax: +49-8142-66989-80   Email: h...@denx.de

Re: Rename of the u-boot-atmel custodian tree

[Anatolij Gustschin]

On Mon, 20 Sep 2021 06:46:01 +
eugen.hris...@microchip.com eugen.hris...@microchip.com wrote:
...
> Former u-boot-atmel tree is now u-boot-at91, available at :
> 
> https://source.denx.de/u-boot/custodians/u-boot-at91
> 
> Tom, do you know how can we update the U-boot denx wiki ?
> https://www.denx.de/wiki/U-Boot/Custodians

I've updated the git repo description in wiki.

--
Anatolij

Re: [PATCH v2 3/3] ARM: amlogic: add JetHub D1/H1 docs

[Neil Armstrong]

Hi,

On 19/09/2021 17:52, Vyacheslav Bocharov wrote:
> Fix doc/board/amlogic/index.rst:
> - Add S905W to S905X column.
> - Add JetHub devices to the corresponding columns.
> - Fix tabs to spaces for table alignment
> 
> Add doc/board/amlogic files:
> - jethub-j100.rst
> - jethub-j80.rst
> 
> Signed-off-by: Vyacheslav Bocharov 
> Reviewed-by: Neil Armstrong 
> ---
>  doc/board/amlogic/index.rst   | 128 +++---
>  doc/board/amlogic/jethub-j100.rst | 108 +
>  doc/board/amlogic/jethub-j80.rst  |  97 ++
>  3 files changed, 270 insertions(+), 63 deletions(-)
>  create mode 100644 doc/board/amlogic/jethub-j100.rst
>  create mode 100644 doc/board/amlogic/jethub-j80.rst
> 
> diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst
> index 2913ab281a..c18f1b7e71 100644
> --- a/doc/board/amlogic/index.rst
> +++ b/doc/board/amlogic/index.rst
> @@ -10,69 +10,69 @@ An up-do-date matrix is also available on: 
> http://linux-meson.com
>  
>  This matrix concerns the actual source code version.
>  
> -+---+---+-+--+++-+--+
> -|| S905  | S905X   | S912
>  | A113X  | S905X2 | S922X   | S905X3   |
> -||   | S805X   | S905D|  
>   | S905D2 | A311D   | S905D3   |
> -||   | |  |  
>   | S905Y2 | |  |
> -+===+===+=+==+++=+==+
> -| Boards | Odroid-C2 | P212| Khadas 
> VIM2  | S400   | U200   | Odroid-N2   | SEI610   |
> -|| Nanopi-K2 | Khadas-VIM  | Libretech-PC |  
>   | SEI510 | Khadas-VIM3 | Khadas-VIM3L |
> -|| P200  | LibreTech-CC v1 | WeTek Core2  |  
>   || GT-King/Pro | Odroid-C4|
> -|| P201  | LibreTech-AC v2 |  |  
>   || GSKing-X| Odroid-HC4   |
> -|   |   | |  
> ||| | BananaPi-M5  |
> -+---+---+-+--+++-+--+
> -| UART   | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Pinctrl/GPIO   | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Clock Control  | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| PWM| **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Reset Control  | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Infrared Decoder   | No| No  | No  
>  | No | No | No  | No   |
> -+---+---+-+--+++-+--+
> -| Ethernet   | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Multi-core | **Yes**   | **Yes** | **Yes** 
>  | **Yes**| **Yes**| **Yes** | **Yes**  |
> -+---+---+-+--+++-+--+
> -| Fuse access| **Yes**   | **Yes** |**Yes**  
>  |**Yes** |**Yes** |**Yes**  | 

Re: [PATCH v2 2/3] ARM: amlogic: add JetHub D1/H1 device support

[Neil Armstrong]

Hi,

On 19/09/2021 17:52, Vyacheslav Bocharov wrote:
> Add support for new home automation devices.

While applying I had a few warnings:

> 
> JetHome Jethub D1 (http://jethome.ru/jethub-d1) is a home automation 
> controller with the following features:
> - DIN Rail Mounting case
> - Amlogic A113X (ARM Cortex-A53) quad-core up to 1.5GHz
> - no video out
> - 512Mb/1GB DDR3
> - 8/16GB eMMC flash
> - 1 x USB 2.0
> - 1 x 10/100Mbps ethernet
> - WiFi / Bluetooth AMPAK AP6255 (Broadcom BCM43455) IEEE 802.11a/b/g/n/ac, 
> Bluetooth 4.2.
> - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
> Zigbee 3.0 support.
> - 2 x gpio LEDS
> - GPIO user Button
> - 1 x 1-Wire
> - 2 x RS-485
> - 4 x dry contact digital GPIO inputs
> - 3 x relay GPIO outputs
> - DC source with a voltage of 9 to 56 V / Passive POE
> 
> JetHome Jethub H1 (http://jethome.ru/jethub-h1) is a home automation 
> controller with the following features:
> - Square plastic case
> - Amlogic S905W (ARM Cortex-A53) quad-core up to 1.5GHz
> - no video out
> - 1GB DDR3
> - 8/16GB eMMC flash
> - 2 x USB 2.0
> - 1 x 10/100Mbps ethernet
> - WiFi / Bluetooth RTL8822CS IEEE 802.11a/b/g/n/ac, Bluetooth 5.0.
> - TI CC2538 + CC2592 Zigbee Wireless Module with up to 20dBm output power and 
> Zigbee 3.0 support.
> - MicroSD 2.x/3.x/4.x DS/HS cards.
> - 1 x gpio LED
> - ADC user Button
> - DC source 5V microUSB with serial console
> 
> Patches from:
> - JetHub H1
>   https://lore.kernel.org/r/20210915085715.1134940-4-ad...@lexina.in
>   https://git.kernel.org/amlogic/c/abfaae24ecf3e7f00508b60fa05e2b6789b8f607
> - JetHub D1
>   https://lore.kernel.org/r/20210915085715.1134940-5-ad...@lexina.in
>   https://git.kernel.org/amlogic/c/8e279fb2903990cc6296ec56b3b80b2f854b6c79
> 
> Signed-off-by: Vyacheslav Bocharov 
> Reviewed-by: Neil Armstrong 
> ---
>  arch/arm/dts/Makefile |   2 +
>  .../arm/dts/meson-axg-jethome-jethub-j100.dts | 361 ++
>  .../meson-gxl-s905w-jethome-jethub-j80.dts| 241 
>  board/amlogic/jethub-j80/MAINTAINERS  |   6 +
>  board/amlogic/jethub-j80/Makefile |   6 +
>  board/amlogic/jethub-j80/jethub-j80.c |  68 
>  configs/jethub_j100_defconfig |  55 +++
>  configs/jethub_j80_defconfig  |  63 +++
>  8 files changed, 802 insertions(+)
>  create mode 100644 arch/arm/dts/meson-axg-jethome-jethub-j100.dts
>  create mode 100644 arch/arm/dts/meson-gxl-s905w-jethome-jethub-j80.dts
>  create mode 100644 board/amlogic/jethub-j80/MAINTAINERS
>  create mode 100644 board/amlogic/jethub-j80/Makefile
>  create mode 100644 board/amlogic/jethub-j80/jethub-j80.c
>  create mode 100644 configs/jethub_j100_defconfig
>  create mode 100644 configs/jethub_j80_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f0160d2dc0..d1893a9812 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -169,10 +169,12 @@ dtb-$(CONFIG_ARCH_MESON) += \
>   meson-gxl-s905x-libretech-cc-v2.dtb \
>   meson-gxl-s905x-khadas-vim.dtb \
>   meson-gxl-s905d-libretech-pc.dtb \
> + meson-gxl-s905w-jethome-jethub-j80.dtb \
>   meson-gxm-khadas-vim2.dtb \
>   meson-gxm-s912-libretech-pc.dtb \
>   meson-gxm-wetek-core2.dtb \
>   meson-axg-s400.dtb \
> + meson-axg-jethome-jethub-j100.dtb \
>   meson-g12a-u200.dtb \
>   meson-g12a-sei510.dtb \
>   meson-g12b-gtking.dtb \
> diff --git a/arch/arm/dts/meson-axg-jethome-jethub-j100.dts 
> b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
> new file mode 100644
> index 00..5783732dc6
> --- /dev/null
> +++ b/arch/arm/dts/meson-axg-jethome-jethub-j100.dts
> @@ -0,0 +1,361 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Vyacheslav Bocharov 
> + * Copyright (c) 2020 JetHome
> + * Author: Aleksandr Kazantsev 
> + * Author: Alexey Shevelkin 
> + * Author: Vyacheslav Bocharov 
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-axg.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + compatible = "jethome,jethub-j100", "amlogic,a113d", 
> "amlogic,meson-axg";
> + model = "JetHome JetHub J100";
> + aliases {
> + serial0 = _AO;   /* Console */
> + serial1 = _AO_B; /* External UART (Wireless Module) */
> + ethernet0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + /* 1024MB RAM */
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x4000>;
> + };
> +
> + reserved-memory {
> + linux,cma {
> + size = <0x0 0x40>;
> + };
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_3v3: regulator-vcc_3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = 

Re: [PATCH] usb: xhci-dwc3: Add support for USB 3.1 controllers

[Bin Meng]

On Mon, Sep 20, 2021 at 6:44 AM Marek Vasut  wrote:
>
> On 9/19/21 10:40 AM, Bin Meng wrote:
> > Hi Marek,
> >
> > On Thu, Sep 16, 2021 at 10:08 PM Bin Meng  wrote:
> >>
> >> On Thu, Sep 16, 2021 at 10:00 PM Mark Kettenis  
> >> wrote:
> >>>
> >>> This adds support for the DWC_sub31 controllers such as those
> >>> found on Apple's M1 SoC.  This version of the controller
> >>> seems to work fine with the existing driver.
> >>>
> >>> Signed-off-by: Mark Kettenis 
> >>> ---
> >>>   drivers/usb/host/xhci-dwc3.c | 3 ++-
> >>>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>
> >> Reviewed-by: Bin Meng 
> >
> > I see this is assigned to me on patchwork. Would you like this to go
> > via the x86 tree?
>
> Since it's just one patch, I suspect Tom can just pick it directly.

Thanks, I have re-assigned it to Tom on patchwork.

Regards,
Bin