Re: [RFC] new board VoCore2

2019-12-15 Thread Stefan Roese

Hi Mauro,

On 15.12.19 11:20, Mauro Condarelli wrote:

I am trying to extend support to a new board "VoCore2" whose specs can
be found here: https://vocore.io/v2.html


Nice. Thanks for working on this.


Port is concerning the "ultimate" board which has all connectors in
place for SD, USB and Ethernet.
This board comes with a paleolithic (1.3.0) version of u-boot and I'm
trying to upgrade to a recent one
also because I need to implement "automatic upgrade" (possibly using
RAUC, but that is another story).

Port is working and able to boot Linuz, but it is not ready for
inclusion for several reasons
and I would like to have expert advice on how to tackle shortcomings, as
advised by stefanro on IRC:

6:49:14 AM - stefanro: mcon: Please submit the patches directly to the
list, with me (and other MIPS / MT7628/88 experts - Daniel etc) on Cc.
If you feel the patches are not ready for integration, then you can
mark them as "RFC" in the subject.


Problematic areas I see (side from possible code style issues) are:
1) I added support for a new SPI NOR Flash and that should, probably, be
a separate patch.


Yes, please.


2) I added support for SPI NOR partitioning and I'm unsure if that
should be in the "board definition".
3) SPI NOR partitioning is actually duplicated in ENV var (mtdparts) and
in Device Tree; I didn't find how to read it directly from DT.


When you pass the MTD partitioning via kernel cmdline "mtdparts=...",
which can be generated by U-Boot, then there is no need for the DT
partitioning.


4) Board also has SD, handled via MTK_SD driver, but I've been unable to
make it work.


Then I suggest to exclude it for now.


5) Current binary is rather big and I would like to shrink it a bit, if
possible.

Any hint/criticism/advice would be VERY welcome.


The most important comment I have is, please post the patch inline, so that
we can easily comment on it. Please also take a look at this page for hints
about patch submission:

http://www.denx.de/wiki/view/U-Boot/Patches

Thanks,
Stefan


[PATCH v3 3/3] configs: ls1012afwry: Enable usb network cards support

2019-12-15 Thread Yinbo Zhu
Enable RTL8152, AX88179 and AX8817X USB network cards support
for ls1012afwry

Signed-off-by: Yinbo Zhu 
---
Change in v3:
Update the commit information

 configs/ls1012afrwy_tfa_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/ls1012afrwy_tfa_defconfig 
b/configs/ls1012afrwy_tfa_defconfig
index 354c521ea4..12fb8740e7 100644
--- a/configs/ls1012afrwy_tfa_defconfig
+++ b/configs/ls1012afrwy_tfa_defconfig
@@ -55,4 +55,8 @@ CONFIG_FSL_QSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_XHCI_DWC3=y
-- 
2.17.1



[PATCH v3 1/3] configs: ls1046afwry: Enable usb network cards support

2019-12-15 Thread Yinbo Zhu
Enable RTL8152, AX88179 and AX8817X USB network cards support
for ls1046afrwy

Signed-off-by: Yinbo Zhu 
---
Change in v3:
Update the commit information

 configs/ls1046afrwy_tfa_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/ls1046afrwy_tfa_defconfig 
b/configs/ls1046afrwy_tfa_defconfig
index 4137eda995..49240b051d 100644
--- a/configs/ls1046afrwy_tfa_defconfig
+++ b/configs/ls1046afrwy_tfa_defconfig
@@ -56,5 +56,9 @@ CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-- 
2.17.1



[PATCH v3 2/3] configs: ls1088ardb: Enable usb network cards support

2019-12-15 Thread Yinbo Zhu
Enable RTL8152, AX88179 and AX8817X USB network cards support
for ls1088ardb

Signed-off-by: Yinbo Zhu 
---
Change in v3:
Update the commit information

 configs/ls1088ardb_tfa_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index e071f1a3c9..b7e28ce586 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -72,4 +72,8 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_GADGET=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
-- 
2.17.1



Re: [PATCH v2 1/4] serial: ns16550: Support run-time configuration

2019-12-15 Thread Bin Meng
Hi Simon,

On Wed, Dec 11, 2019 at 3:35 AM Park, Aiden  wrote:
>
> Hi Simon,
>
> > -Original Message-
> > From: U-Boot  On Behalf Of Simon Glass
> > Sent: Monday, December 9, 2019 8:59 AM
> > To: U-Boot Mailing List 
> > Cc: Stefan Roese ; Angelo Dureghello 
> > Subject: [PATCH v2 1/4] serial: ns16550: Support run-time configuration
> >
> > At present this driver uses an assortment of CONFIG options to control how
> > it accesses the hardware. This is painful for platforms that are supposed 
> > to be
> > controlled by a device tree or a previous-stage bootloader.
> >
> > Add a new CONFIG option to enable fully dynamic configuration. This
> > controls register spacing, size, offset and endianness.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - runtime -> run-time
> > - Enable run-time config for slimbootloader too
> > - Improve Kconfig help based on Bin's comments
> > - Use ns16550 in patch subject
> >
> >  drivers/serial/Kconfig   | 21 +++
> >  drivers/serial/ns16550.c | 57 ++
> > --
> >  include/ns16550.h| 13 +
> >  3 files changed, 83 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index
> > ece7d87d4c..472a9f0929 100644
> > --- a/drivers/serial/Kconfig
> > +++ b/drivers/serial/Kconfig
> > @@ -598,6 +598,27 @@ config SYS_NS16550
> > be used. It can be a constant or a function to get clock, eg,
> > get_serial_clock().
> >
> > +config NS16550_DYNAMIC
> > + bool "Allow NS16550 to be configured at runtime"
> > + default y if SYS_COREBOOT || SYS_SLIMBOOTLOADER
> > + help
> > +   Enable this option to allow device-tree control of the driver.
> > +
> > +   Normally this driver is controlled by the following options:
> > +
> > +   CONFIG_SYS_NS16550_PORT_MAPPED - indicates that port I/O is
> > used for
> > +  access. If not enabled, then the UART is memory-mapped.
> > +   CONFIG_SYS_NS16550_MEM32 - if memory-mapped, indicates that
> > 32-bit
> > +  access should be used (instead of 8-bit)
> > +   CONFIG_SYS_NS16550_REG_SIZE - indicates register width and also
> > +  endianness. If positive, big-endian access is used. If negative,
> > +  little-endian is used.
> > +
> > +   It is not a good practice for a driver to be statically configured,
> > +   since it prevents the same driver being used for different types of
> > +   UARTs in a system. This option avoids this problem at the cost of a
> > +   slightly increased code size.
> > +
> >  config INTEL_MID_SERIAL
> >   bool "Intel MID platform UART support"
> >   depends on DM_SERIAL && OF_CONTROL
> > diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index
> > 754b6e9921..96c4471efd 100644
> > --- a/drivers/serial/ns16550.c
> > +++ b/drivers/serial/ns16550.c
> > @@ -92,19 +92,57 @@ static inline int serial_in_shift(void *addr, int shift)
> > #define CONFIG_SYS_NS16550_CLK  0  #endif
> >
> > +static void serial_out_dynamic(struct ns16550_platdata *plat, u8 *addr,
> > +int value)
> > +{
> > + if (plat->flags & NS16550_FLAG_BE) {
> > + if (plat->reg_width == 1)
> > + writeb(value, addr + (1 << plat->reg_shift) - 1);
> > + else if (plat->flags & NS16550_FLAG_IO)
> > + out_be32(addr, value);
> > + else
> > + writel(value, addr);
> > + } else {
> > + if (plat->reg_width == 1)
> > + writeb(value, addr);
> > + else if (plat->flags & NS16550_FLAG_IO)
> > + out_le32(addr, value);
> > + else
> > + writel(value, addr);
> > + }
> > +}
> IO needs to use outb(). It breaks QEMU 0x3f8 IO (reg_width = 1, flags=IO).
> I have verified 0x3f8 IO on QEMU and MMIO32 on APL with below code.
> if (plat->flags & NS16550_FLAG_IO) {
> outb(value, addr);
> } else {
> if (plat->flags & NS16550_FLAG_BE) {
> if (plat->reg_width == 1)
> writeb(value, addr + (1 << plat->reg_shift) - 
> 1);
> else
> out_be32(addr, value);
> } else {
> if (plat->reg_width == 1)
> writeb(value, addr);
> else
> out_le32(addr, value);
> }
> }
>

Would you post a v3 that fixes the issue that Aiden pointed out?

Regards,
Bin


Re: [PATCH] cmd/eeprom.c: prepend 0x to hex numbers in output message format

2019-12-15 Thread Heiko Schocher

Hello Rasmus,

Am 11.12.2019 um 12:18 schrieb Rasmus Villemoes:

From: "Klaus H. Sorensen" 

If the numbers do not happen to contain any digits from [a-f], it's
not clear that they are base 16.

Signed-off-by: Klaus H. Sorensen 
Signed-off-by: Rasmus Villemoes 
---
  cmd/eeprom.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Thanks!

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


[PATCH] efi_selftest: Update .gitignore

2019-12-15 Thread Sughosh Ganu
Add the following file to .gitignore
 efi_miniapp_file_image_exception.h

Signed-off-by: Sughosh Ganu 
---
 lib/efi_selftest/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/efi_selftest/.gitignore b/lib/efi_selftest/.gitignore
index 293a17b..9cac367 100644
--- a/lib/efi_selftest/.gitignore
+++ b/lib/efi_selftest/.gitignore
@@ -1,3 +1,4 @@
+efi_miniapp_file_image_exception.h
 efi_miniapp_file_image_exit.h
 efi_miniapp_file_image_return.h
 *.efi
-- 
2.7.4



[PATCH v2 1/3] configs: ls1046afwry: Enable usb network card

2019-12-15 Thread Yinbo Zhu
enable ls1046afwry usb network card r8152_eth AX88179 and AX8817X driver

Signed-off-by: Yinbo Zhu 
---
Change in v2:
update the commit information

 configs/ls1046afrwy_tfa_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/ls1046afrwy_tfa_defconfig 
b/configs/ls1046afrwy_tfa_defconfig
index 4137eda995..49240b051d 100644
--- a/configs/ls1046afrwy_tfa_defconfig
+++ b/configs/ls1046afrwy_tfa_defconfig
@@ -56,5 +56,9 @@ CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-- 
2.17.1



[PATCH v2 3/3] configs: ls1012afwry: Enable usb network card

2019-12-15 Thread Yinbo Zhu
enable ls1012afwry usb network card r8152_eth AX88179 and AX8817X driver

Signed-off-by: Yinbo Zhu 
---
Change in v2:
update the commit information

 configs/ls1012afrwy_tfa_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/ls1012afrwy_tfa_defconfig 
b/configs/ls1012afrwy_tfa_defconfig
index 354c521ea4..12fb8740e7 100644
--- a/configs/ls1012afrwy_tfa_defconfig
+++ b/configs/ls1012afrwy_tfa_defconfig
@@ -55,4 +55,8 @@ CONFIG_FSL_QSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_XHCI_DWC3=y
-- 
2.17.1



[PATCH v2 2/3] configs: ls1088ardb: Enable usb network card

2019-12-15 Thread Yinbo Zhu
enable ls1088ardb usb network card r8152_eth AX88179 and AX8817X driver

Signed-off-by: Yinbo Zhu 
---
Change in v2:
update the commit information

 configs/ls1088ardb_tfa_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index e071f1a3c9..b7e28ce586 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -72,4 +72,8 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_GADGET=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
-- 
2.17.1



RE: [PATCH v1 3/3] enable ls1046afwry usb network card

2019-12-15 Thread Priyanka Jain



>-Original Message-
>From: U-Boot  On Behalf Of Yinbo Zhu
>Sent: Friday, December 13, 2019 11:54 AM
>To: Sudhanshu Gupta ; Harninder Rai
>; Rajesh Bhagat ; open
>list 
>Cc: Peter Chen ; Xiaobo Xie ;
>Jiafei Pan ; Ran Wang ; Yinbo
>Zhu ; Jun Li 
>Subject: [PATCH v1 3/3] enable ls1046afwry usb network card
>
>enable ls1046afwry usb network card r8152_eth AX88179 and AX8817X driver
>
Wrong platform mentioned in subject and description.
>Signed-off-by: Yinbo Zhu 
>---
> configs/ls1012afrwy_tfa_defconfig | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/configs/ls1012afrwy_tfa_defconfig
>b/configs/ls1012afrwy_tfa_defconfig
>index 65ed34e..5ae7ae9 100644
>--- a/configs/ls1012afrwy_tfa_defconfig
>+++ b/configs/ls1012afrwy_tfa_defconfig
>@@ -52,4 +52,8 @@ CONFIG_FSL_QSPI=y
> CONFIG_USB=y
> CONFIG_DM_USB=y
> CONFIG_USB_XHCI_HCD=y
>+CONFIG_USB_ETHER_ASIX=y
>+CONFIG_USB_ETHER_ASIX88179=y
>+CONFIG_USB_HOST_ETHER=y
>+CONFIG_USB_ETHER_RTL8152=y
> CONFIG_USB_XHCI_DWC3=y
>--
>2.7.4
priyanka


RE: [PATCH v1 1/3] enable ls1046afwry usb network card

2019-12-15 Thread Priyanka Jain



>-Original Message-
>From: U-Boot  On Behalf Of Yinbo Zhu
>Sent: Friday, December 13, 2019 11:54 AM
>To: Sudhanshu Gupta ; Harninder Rai
>; Rajesh Bhagat ; open
>list 
>Cc: Peter Chen ; Xiaobo Xie ;
>Jiafei Pan ; Ran Wang ; Yinbo
>Zhu ; Jun Li 
>Subject: [PATCH v1 1/3] enable ls1046afwry usb network card
Please add domain area in subject. Something like:
Configs: ls1046afrwy_tfa_defconfig: Enable usb network card
>enable ls1046afwry usb network card r8152_eth AX88179 and AX8817X driver
>
>Signed-off-by: Yinbo Zhu 
>---
> configs/ls1046afrwy_tfa_defconfig | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/configs/ls1046afrwy_tfa_defconfig
>b/configs/ls1046afrwy_tfa_defconfig
>index 1d27408..550e521 100644
>--- a/configs/ls1046afrwy_tfa_defconfig
>+++ b/configs/ls1046afrwy_tfa_defconfig
>@@ -52,5 +52,9 @@ CONFIG_DM_SPI=y
> CONFIG_FSL_QSPI=y
> CONFIG_USB=y
> CONFIG_DM_USB=y
>+CONFIG_USB_ETHER_ASIX=y
>+CONFIG_USB_ETHER_ASIX88179=y
>+CONFIG_USB_HOST_ETHER=y
>+CONFIG_USB_ETHER_RTL8152=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
>--
>2.7.4
-priyanka


Re: [PATCH v1] T1024RDB: USB: Add a 10808 us delay in usb_scan_port

2019-12-15 Thread Bin Meng
+Marek,

On Mon, Dec 16, 2019 at 11:13 AM Yinbo Zhu  wrote:
>
> T1024RDB usb controller doesn't detect usb device at first usb start
> Add a delay that is greater than 10808 us can fix that issue, which
> delay if is less than 10808 us, issue is probabilistic occurrence
>
> => usb start
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB EHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> scanning bus 1 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> => usb stop
> stopping USB..
> => usb start
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB EHCI 1.00
> scanning bus 0 for devices... 2 USB Device(s) found
> scanning bus 1 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
> =>
>
> Signed-off-by: Yinbo Zhu 
> ---
>  common/usb_hub.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/common/usb_hub.c b/common/usb_hub.c
> index 33aaeb8e44..6dd06696b2 100644
> --- a/common/usb_hub.c
> +++ b/common/usb_hub.c
> @@ -486,6 +486,9 @@ static int usb_scan_port(struct usb_device_scan *usb_scan)
> return 0;
> }
>
> +#ifdef CONFIG_TARGET_T1024RDB
> +   udelay(10808);
> +#endif

This looks like a workaround. Is this a silicon errata?

> if (portchange & USB_PORT_STAT_C_RESET) {
> debug("port %d reset change\n", i + 1);
> usb_clear_port_feature(dev, i + 1, USB_PORT_FEAT_C_RESET);
> --

Regards,
Bin


[PATCH v1] T1024RDB: USB: Add a 10808 us delay in usb_scan_port

2019-12-15 Thread Yinbo Zhu
T1024RDB usb controller doesn't detect usb device at first usb start
Add a delay that is greater than 10808 us can fix that issue, which
delay if is less than 10808 us, issue is probabilistic occurrence

=> usb start
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
=> usb stop
stopping USB..
=> usb start
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
=>

Signed-off-by: Yinbo Zhu 
---
 common/usb_hub.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index 33aaeb8e44..6dd06696b2 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -486,6 +486,9 @@ static int usb_scan_port(struct usb_device_scan *usb_scan)
return 0;
}
 
+#ifdef CONFIG_TARGET_T1024RDB
+   udelay(10808);
+#endif
if (portchange & USB_PORT_STAT_C_RESET) {
debug("port %d reset change\n", i + 1);
usb_clear_port_feature(dev, i + 1, USB_PORT_FEAT_C_RESET);
-- 
2.17.1



回复: [PATCH v3] arm: add acpi support for the arm

2019-12-15 Thread Steven Hao
This problem seems like lay aside.


发件人: Bin Meng 
发送时间: 2019年11月27日 14:04
收件人: Simon Glass 
抄送: Heinrich Schuchardt ; Steven Hao 
; liu...@phytium.com.cn ; 
ag...@csgraf.de ; ja...@amarulasolutions.com 
; marek.va...@gmail.com ; 
s...@denx.de ; patrice.chot...@st.com ; 
a...@ti.com ; horatiu.vul...@microchip.com 
; narmstr...@baylibre.com 
; ryder@mediatek.com ; 
igor.opan...@gmail.com ; patrick.delau...@st.com 
; eugen.hris...@microchip.com 
; judge.pack...@gmail.com 
; yamada.masah...@socionext.com 
; swar...@nvidia.com ; 
michal.si...@xilinx.com ; u-boot@lists.denx.de 
; Andy Shevchenko 
主题: Re: [PATCH v3] arm: add acpi support for the arm

Hi Simon,

On Wed, Nov 27, 2019 at 11:42 AM Simon Glass  wrote:
>
> Hi Heinrich,
>
> On Mon, 25 Nov 2019 at 18:12, Heinrich Schuchardt  wrote:
> >
> > On 11/26/19 12:40 AM, Simon Glass wrote:
> > > Hi,
> > >
> > > On Mon, 25 Nov 2019 at 15:57, Heinrich Schuchardt  
> > > wrote:
> > >>
> > >> On 11/25/19 3:42 AM, Steven Hao wrote:> 获取 Outlook for iOS
> > >> 
> > >>> 
> > >>> *发件人:* Bin Meng 
> > >>> *发送时间:* Monday, November 25, 2019 10:13:40 AM
> > >>> *收件人:* Steven Hao 
> > >>> *抄送:* xypron.g...@gmx.de ; liu...@phytium.com.cn
> > >>> ; ag...@csgraf.de ;
> > >>> ja...@amarulasolutions.com ;
> > >>> marek.va...@gmail.com ; s...@denx.de 
> > >>> ;
> > >>> patrice.chot...@st.com ; a...@ti.com
> > >>> ; horatiu.vul...@microchip.com
> > >>> ; narmstr...@baylibre.com
> > >>> ; ryder@mediatek.com
> > >>> ; igor.opan...@gmail.com
> > >>> ; patrick.delau...@st.com
> > >>> ; eugen.hris...@microchip.com
> > >>> ; s...@chromium.org ;
> > >>> judge.pack...@gmail.com ;
> > >>> yamada.masah...@socionext.com ;
> > >>> swar...@nvidia.com ; michal.si...@xilinx.com
> > >>> ; u-boot@lists.denx.de ;
> > >>> Andy Shevchenko 
> > >>> *主题:* Re: [PATCH v3] arm: add acpi support for the arm
> > >>> Hi Steven,
> > >>>
> > >>> On Mon, Nov 25, 2019 at 10:09 AM Steven Hao 
> > >>> wrote:
> > 
> >  Dear Bin:
> > 
> >  Firstly:
> >  I know that acpi about x86 is existing. And it is usefull for x86
> > >> platfporm. If it  is used to arm platform,some modification may have to
> > >> do. For example,facs table is useless for arm.
> > 
> >  In adition,The acpi table is writed statically and then modified
> > >> dynamically in my patch. It is a new method.
> > 
> >  I want to consult that whether my method is helpful or not.
> > 
> >  Secondly:
> >  If i want to reuse the x86-acpi. I will overwrite the
> > >> write_acpi_tables function. But the definition about acpi strcuture is
> > >> placed in arch/x86/include/asm directory. It can not be used to arm
> > >> plateform. If the acpi library need to surport for all platform,i  think
> > >> it should move to /include directory.
> > 
> > >>>
> > >>> Yes, we all are aware that modifications are needed to the existing
> > >>> x86 ACPI support to support ARM. We don't want to create 2 ACP
> > >>> implementation in U-Boot.
> > >>>
> > >>> Regards,
> > >>> Bin> Dear Bin:
> > >>>
> > >>> I have a suggetion that the acpi specification definition such as all
> > >>> acpi table structure definition  should be place in /include directory.
> > >>> and write_acpi_tables function can be placed in platform directory.
> > >>>Creating acpi table mothod  can be diffrent between x86 and arm.
> > >>>
> > >>> Thank you
> > >>> Steven Hao
> > >>>
> > >>
> > >> Currently we are using CPU specific C files generating ACPI tables, e.g.
> > >> arch/x86/cpu/tangier/acpi.c.
> > >>
> > >> I would prefer if we would generate the ACPI tables and definition
> > >> blocks completely from text files instead of using C code. This would
> > >> avoid any architecture specific code.
> > >
> > > I am finding with Apollo Lake that this isn't possible - we need to
> > > insert run-time information into the tables set up with .asl files.
> >
> > For device trees we generate the binary form with a compiler. Then we
> > patch the device tree with runtime information in image_setup_libfdt().
> >
> > Couldn't we go a similar way for ACPI?
>
> Yes that's my goal, except that some tables are generated wholesale
> from code (equivalent to entire nodes in DT).
>
> I had a bit of a look at how this is done in coreboot. It is pretty
> hard to follow as there are weak functions and the code jumps back and
> forth between generic code and SoC-specific code. But every device has
> ACPI operation and I think that makes sense.
>
> My current idea is to add a new optional acpi_ops struct pointer into
> each struct driver, to handle the ACPI table generation and other
> things needed by ACPI. Then devices that want to do ACPI things can do
> so. Then we need a new drivers/core/acpi.c file to handle things.
>

Yes, this approach makes sense to me, for dynamic ACPI table generation.

Regards,
Bin


[PATCH] ARM: dts: xilinx: Fix I2C and SPI bus warnings

2019-12-15 Thread Florian Klink
Ported over from https://patchwork.kernel.org/patch/10599941/

Signed-off-by: Florian Klink 
---
 arch/arm/dts/zynq-zc702.dts   | 12 ++--
 arch/arm/dts/zynq-zc770-xm010.dts |  2 +-
 arch/arm/dts/zynq-zc770-xm013.dts |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index d10695740f..b043d341d6 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -181,17 +181,17 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <7>;
-   hwmon@52 {
+   hwmon@34 {
compatible = "ti,ucd9248";
-   reg = <52>;
+   reg = <0x34>;
};
-   hwmon@53 {
+   hwmon@35 {
compatible = "ti,ucd9248";
-   reg = <53>;
+   reg = <0x35>;
};
-   hwmon@54 {
+   hwmon@36 {
compatible = "ti,ucd9248";
-   reg = <54>;
+   reg = <0x36>;
};
};
};
diff --git a/arch/arm/dts/zynq-zc770-xm010.dts 
b/arch/arm/dts/zynq-zc770-xm010.dts
index e1f34653ec..c547d7921d 100644
--- a/arch/arm/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/dts/zynq-zc770-xm010.dts
@@ -72,7 +72,7 @@
status = "okay";
num-cs = <4>;
is-decoded-cs = <0>;
-   flash@0 {
+   flash@1 {
compatible = "sst25wf080", "jedec,spi-nor";
reg = <1>;
spi-max-frequency = <100>;
diff --git a/arch/arm/dts/zynq-zc770-xm013.dts 
b/arch/arm/dts/zynq-zc770-xm013.dts
index 05a49982cc..bdf0c2f956 100644
--- a/arch/arm/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/dts/zynq-zc770-xm013.dts
@@ -67,7 +67,7 @@
status = "okay";
num-cs = <4>;
is-decoded-cs = <0>;
-   eeprom: eeprom@0 {
+   eeprom: eeprom@2 {
at25,byte-len = <8192>;
at25,addr-mode = <2>;
at25,page-size = <32>;
-- 
2.24.1



[PATCH] env: another attempt at fixing SPL build failures

2019-12-15 Thread Rasmus Villemoes
I'm also seeing the build failure that commit

7d4776545b env: solve compilation error in SPL

tried to fix, namely that the reference to env_flags_validate from
env_htab cannot be satisfied when flags.o is not built in. However,
that commit got reverted by

d90fc9c3de Revert "env: solve compilation error in SPL"

Necessary, but not sufficient conditions to see this are

CONFIG_SPL=y (obviously)
CONFIG_SPL_ENV_SUPPORT=n (so flags.o does not get compiled)
CONFIG_SPL_LIBCOMMON_SUPPORT=y (so env/built-in.o is part of the SPL link)

Now, these are satisfied for e.g. imx6q_logic_defconfig. But that
builds just fine, and spl/u-boot-spl.map lists .data.env_htab among
the discarded (garbage collected) sections. Yet, on our
mpc8309-derived board, we do see the build failure, so perhaps the
linker works a bit differently on ppc than on ARM, or there's yet some
other configuration option needed to observe the break.

This is another attempt at solving it, which also cleans up
env/Makefile a bit: Introduce a def_bool y symbol CONFIG_ENV_SUPPORT
which complements CONFIG_(SPL/TPL)_SUPPORT. Then use
CONFIG_$(SPL_TPL_)ENV_SUPPORT to decide whether to include the five
basic env/*.o files. For attr.o, flags.o and callback.o, this
shouldn't change anything. Also, common.o and env.o still get
unconditionally built for U-boot proper. But for TPL/SPL, those two
are only included if CONFIG_(SPL/TPL)_SUPPORT is set.

Having that symbol should also allow simplifying conditionals such as

#if !defined(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(ENV_SUPPORT)

found in drivers/reset/reset-socfpga.c to just
CONFIG_IS_ENABLED(ENV_SUPPORT).

Signed-off-by: Rasmus Villemoes 
---
 env/Kconfig  |  3 +++
 env/Makefile | 13 +
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/env/Kconfig b/env/Kconfig
index ed12609f6a..4661082f0e 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -1,5 +1,8 @@
 menu "Environment"
 
+config ENV_SUPPORT
+   def_bool y
+
 config ENV_IS_NOWHERE
bool "Environment is not stored"
default y if !ENV_IS_IN_EEPROM && !ENV_IS_IN_EXT4 && \
diff --git a/env/Makefile b/env/Makefile
index 90144d6caf..e2a165b8f1 100644
--- a/env/Makefile
+++ b/env/Makefile
@@ -3,12 +3,13 @@
 # (C) Copyright 2004-2006
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 
-obj-y += common.o env.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += common.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += env.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o
 
 ifndef CONFIG_SPL_BUILD
-obj-y += attr.o
-obj-y += callback.o
-obj-y += flags.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
 extra-$(CONFIG_ENV_IS_EMBEDDED) += embedded.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += embedded.o
@@ -19,10 +20,6 @@ obj-$(CONFIG_ENV_IS_IN_ONENAND) += onenand.o
 obj-$(CONFIG_ENV_IS_IN_SATA) += sata.o
 obj-$(CONFIG_ENV_IS_IN_REMOTE) += remote.o
 obj-$(CONFIG_ENV_IS_IN_UBI) += ubi.o
-else
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o
 endif
 
 obj-$(CONFIG_$(SPL_TPL_)ENV_IS_NOWHERE) += nowhere.o
-- 
2.23.0



[PATCH 3/3] net: add driver for NXP SJA1105 DSA L2 switch

2019-12-15 Thread Vladimir Oltean
The SJA1105 driver is largely reused from Linux. Its programming model
is that it is blank out of reset, and it waits for a static
configuration stream over SPI, which contains all runtime parameters (it
has no notion of "default values").

Keeping a binary array for the configuration stream would have meant
that aspects such as the CPU port and the MAC speeds could have not been
configured easily, and would have been static and board-dependent.
Live-patching the binary array means recalculating the static config
table CRCs, which is not a fun process.

So we create an abstraction over the static config tables, using the
packing API, same as in Linux. The tables are kept as C structures, and
the binary configuration stream is constructed on-the-go, with CRC and
all.

All static config tables instantiated in this driver are mandatory.
The hardware reference manual can be found at:
https://www.nxp.com/docs/en/user-guide/UM10944.pdf

For tagging, a simplified version of dsa_8021q from Linux is used. The
VLAN EtherType is the same (0xdadb) but since we don't want switching in
U-Boot, there is no reason to have a TX VLAN and an RX VLAN for each
port. We just need the RX VLANs to act as the unique pvid of each
front-panel port, to decode the switch port number. The RX VLAN is used
for both RX and TX.

The device tree bindings are the same as in Linux, sans the custom
sja1105,role-mac and sja1105,role-phy which are not implemented yet
since I saw no immediate need for them.

Signed-off-by: Vladimir Oltean 
---
 drivers/net/Kconfig   |   17 +
 drivers/net/Makefile  |1 +
 drivers/net/sja1105.c | 2309 +
 3 files changed, 2327 insertions(+)
 create mode 100644 drivers/net/sja1105.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ff14e79453f2..7da091e6300d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -381,6 +381,23 @@ config RTL8169
  This driver supports Realtek 8169 series gigabit ethernet family of
  PCI/PCIe chipsets/adapters.
 
+config SJA1105
+   bool "NXP SJA1105 Ethernet switch family driver"
+   depends on DM_DSA && DM_SPI
+   select BITREVERSE
+   select PACKING
+   help
+ This is the driver for the NXP SJA1105 automotive Ethernet switch
+ family. These are 5-port devices and are managed over an SPI
+ interface. Probing is handled based on OF bindings. The driver
+ supports the following revisions:
+   - SJA1105E (Gen. 1, No TT-Ethernet)
+   - SJA1105T (Gen. 1, TT-Ethernet)
+   - SJA1105P (Gen. 2, No SGMII, No TT-Ethernet)
+   - SJA1105Q (Gen. 2, No SGMII, TT-Ethernet)
+   - SJA1105R (Gen. 2, SGMII, No TT-Ethernet)
+   - SJA1105S (Gen. 2, SGMII, TT-Ethernet)
+
 config SMC911X
bool "SMSC LAN911x and LAN921x controller driver"
 
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 8be49f63352b..67204ef3f481 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_DNET) += dnet.o
 obj-$(CONFIG_E1000) += e1000.o
 obj-$(CONFIG_E1000_SPI) += e1000_spi.o
 obj-$(CONFIG_EEPRO100) += eepro100.o
+obj-$(CONFIG_SJA1105) += sja1105.o
 obj-$(CONFIG_SUN4I_EMAC) += sunxi_emac.o
 obj-$(CONFIG_SUN8I_EMAC) += sun8i_emac.o
 obj-$(CONFIG_EP93XX) += ep93xx_eth.o
diff --git a/drivers/net/sja1105.c b/drivers/net/sja1105.c
new file mode 100644
index ..8e64845dcc06
--- /dev/null
+++ b/drivers/net/sja1105.c
@@ -0,0 +1,2309 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright 2016-2018, NXP Semiconductors
+ * Copyright 2018, Sensor-Technik Wiedemann GmbH
+ * Copyright 2018-2019, Vladimir Oltean 
+ *
+ * Ported from Linux (drivers/net/dsa/sja1105/).
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ETHER_CRC32_POLY   0x04C11DB7
+#define ETH_P_SJA1105  0xdadb
+#define SJA1105_NUM_PORTS  5
+#define SJA1105_NUM_TC 8
+#define SJA1105ET_FDB_BIN_SIZE 4
+#define SJA1105_SIZE_CGU_CMD   4
+#define SJA1105_SIZE_RESET_CMD 4
+#define SJA1105_SIZE_SPI_MSG_HEADER4
+#define SJA1105_SIZE_SPI_MSG_MAXLEN(64 * 4)
+#define SJA1105_SIZE_DEVICE_ID 4
+#define SJA1105_SIZE_TABLE_HEADER  12
+#define SJA1105_SIZE_L2_POLICING_ENTRY 8
+#define SJA1105_SIZE_VLAN_LOOKUP_ENTRY 8
+#define SJA1105_SIZE_L2_FORWARDING_ENTRY   8
+#define SJA1105_SIZE_L2_FORWARDING_PARAMS_ENTRY12
+#define SJA1105_SIZE_XMII_PARAMS_ENTRY 4
+#define SJA1105ET_SIZE_MAC_CONFIG_ENTRY28
+#define SJA1105ET_SIZE_L2_LOOKUP_PARAMS_ENTRY  4
+#define SJA1105ET_SIZE_GENERAL_PARAMS_ENTRY40
+#define 

[PATCH 2/3] include: import if_vlan.h from Linux

2019-12-15 Thread Vladimir Oltean
This is needed for the VLAN header structure.

Signed-off-by: Vladimir Oltean 
---
 include/linux/if_vlan.h | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 include/linux/if_vlan.h

diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
new file mode 100644
index ..cbc82f4cc217
--- /dev/null
+++ b/include/linux/if_vlan.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * VLANAn implementation of 802.1Q VLAN tagging.
+ *
+ * Authors:Ben Greear 
+ */
+#ifndef _LINUX_IF_VLAN_H_
+#define _LINUX_IF_VLAN_H_
+
+/**
+ * struct vlan_ethhdr - vlan ethernet header (ethhdr + vlan_hdr)
+ * @h_dest: destination ethernet address
+ * @h_source: source ethernet address
+ * @h_vlan_proto: ethernet protocol
+ * @h_vlan_TCI: priority and VLAN ID
+ * @h_vlan_encapsulated_proto: packet type ID or len
+ */
+struct vlan_ethhdr {
+   unsigned char   h_dest[ETH_ALEN];
+   unsigned char   h_source[ETH_ALEN];
+   __be16  h_vlan_proto;
+   __be16  h_vlan_TCI;
+   __be16  h_vlan_encapsulated_proto;
+};
+
+#endif /* !(_LINUX_IF_VLAN_H_) */
-- 
2.17.1



[PATCH 0/3] DM DSA driver for NXP SJA1105 Ethernet switch

2019-12-15 Thread Vladimir Oltean
This is a driver for the SJA1105 automotive L2 switch. It uses the
DSA uclass proposed by Alex Marginean (but not yet merged) here [0].
This is convenient because with this framework, the switch acts as a
4-port Ethernet multiplexer capable of TFTP, but does not do switching,
which is not unnecessary in the bootloader, and which would also cause
issues in complex networks that rely on STP to block loops.

[0]: https://patchwork.ozlabs.org/patch/1203754/

Vladimir Oltean (3):
  lib: import packing API from Linux
  include: import if_vlan.h from Linux
  net: add driver for NXP SJA1105 DSA L2 switch

 drivers/net/Kconfig |   17 +
 drivers/net/Makefile|1 +
 drivers/net/sja1105.c   | 2309 +++
 include/linux/if_vlan.h |   26 +
 include/linux/packing.h |   49 +
 lib/Kconfig |   17 +
 lib/Makefile|1 +
 lib/packing.c   |  208 
 8 files changed, 2628 insertions(+)
 create mode 100644 drivers/net/sja1105.c
 create mode 100644 include/linux/if_vlan.h
 create mode 100644 include/linux/packing.h
 create mode 100644 lib/packing.c

-- 
2.17.1



[PATCH 1/3] lib: import packing API from Linux

2019-12-15 Thread Vladimir Oltean
This is needed to support the sja1105 DSA driver.

Signed-off-by: Vladimir Oltean 
---
 include/linux/packing.h |  49 ++
 lib/Kconfig |  17 
 lib/Makefile|   1 +
 lib/packing.c   | 208 
 4 files changed, 275 insertions(+)
 create mode 100644 include/linux/packing.h
 create mode 100644 lib/packing.c

diff --git a/include/linux/packing.h b/include/linux/packing.h
new file mode 100644
index ..54667735cc67
--- /dev/null
+++ b/include/linux/packing.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright (c) 2016-2018, NXP Semiconductors
+ * Copyright (c) 2018-2019, Vladimir Oltean 
+ */
+#ifndef _LINUX_PACKING_H
+#define _LINUX_PACKING_H
+
+#include 
+#include 
+
+#define QUIRK_MSB_ON_THE_RIGHT BIT(0)
+#define QUIRK_LITTLE_ENDIANBIT(1)
+#define QUIRK_LSW32_IS_FIRST   BIT(2)
+
+enum packing_op {
+   PACK,
+   UNPACK,
+};
+
+/**
+ * packing - Convert numbers (currently u64) between a packed and an unpacked
+ *  format. Unpacked means laid out in memory in the CPU's native
+ *  understanding of integers, while packed means anything else that
+ *  requires translation.
+ *
+ * @pbuf: Pointer to a buffer holding the packed value.
+ * @uval: Pointer to an u64 holding the unpacked value.
+ * @startbit: The index (in logical notation, compensated for quirks) where
+ *   the packed value starts within pbuf. Must be larger than, or
+ *   equal to, endbit.
+ * @endbit: The index (in logical notation, compensated for quirks) where
+ * the packed value ends within pbuf. Must be smaller than, or equal
+ * to, startbit.
+ * @op: If PACK, then uval will be treated as const pointer and copied (packed)
+ * into pbuf, between startbit and endbit.
+ * If UNPACK, then pbuf will be treated as const pointer and the logical
+ * value between startbit and endbit will be copied (unpacked) to uval.
+ * @quirks: A bit mask of QUIRK_LITTLE_ENDIAN, QUIRK_LSW32_IS_FIRST and
+ * QUIRK_MSB_ON_THE_RIGHT.
+ *
+ * Return: 0 on success, EINVAL or ERANGE if called incorrectly. Assuming
+ *correct usage, return code may be discarded.
+ *If op is PACK, pbuf is modified.
+ *If op is UNPACK, uval is modified.
+ */
+int packing(void *pbuf, u64 *uval, int startbit, int endbit, size_t pbuflen,
+   enum packing_op op, u8 quirks);
+
+#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index 965cf7bc039c..a828b80a40d3 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -33,6 +33,23 @@ config HAVE_PRIVATE_LIBGCC
 config LIB_UUID
bool
 
+config PACKING
+   bool "Generic bitfield packing and unpacking"
+   default n
+   help
+ This option provides the packing() helper function, which permits
+ converting bitfields between a CPU-usable representation and a
+ memory representation that can have any combination of these quirks:
+   - Is little endian (bytes are reversed within a 32-bit group)
+   - The least-significant 32-bit word comes first (within a 64-bit
+ group)
+   - The most significant bit of a byte is at its right (bit 0 of a
+ register description is numerically 2^7).
+ Drivers may use these helpers to match the bit indices as described
+ in the data sheets of the peripherals they are in control of.
+
+ When in doubt, say N.
+
 config PRINTF
bool
default y
diff --git a/lib/Makefile b/lib/Makefile
index 1fb650cd90d1..4f99bd47c21e 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -104,6 +104,7 @@ obj-y += hexdump.o
 obj-$(CONFIG_TRACE) += trace.o
 obj-$(CONFIG_LIB_UUID) += uuid.o
 obj-$(CONFIG_LIB_RAND) += rand.o
+obj-$(CONFIG_PACKING) += packing.o
 obj-y += panic.o
 
 ifeq ($(CONFIG_$(SPL_TPL_)BUILD),y)
diff --git a/lib/packing.c b/lib/packing.c
new file mode 100644
index ..93af114ee1fe
--- /dev/null
+++ b/lib/packing.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
+/* Copyright (c) 2016-2018, NXP Semiconductors
+ * Copyright (c) 2018-2019, Vladimir Oltean 
+ */
+#include 
+#include 
+#include 
+#include 
+
+static int get_le_offset(int offset)
+{
+   int closest_multiple_of_4;
+
+   closest_multiple_of_4 = (offset / 4) * 4;
+   offset -= closest_multiple_of_4;
+   return closest_multiple_of_4 + (3 - offset);
+}
+
+static int get_reverse_lsw32_offset(int offset, size_t len)
+{
+   int closest_multiple_of_4;
+   int word_index;
+
+   word_index = offset / 4;
+   closest_multiple_of_4 = word_index * 4;
+   offset -= closest_multiple_of_4;
+   word_index = (len / 4) - word_index - 1;
+   return word_index * 4 + offset;
+}
+
+static u64 bit_reverse(u64 val, unsigned int width)
+{
+   u64 new_val = 0;
+   unsigned int bit;
+   unsigned int i;
+
+   for (i = 0; i < width; i++) {
+   bit = (val & (1 << i)) 

Re: [GIT PULL] For socfpga-next

2019-12-15 Thread Marek Vasut
On 12/15/19 4:27 PM, Marek Vasut wrote:
> On 12/13/19 10:49 AM, Tan, Ley Foon wrote:
>> Hi Marek
>>
>> Please pull the following update for socfpga-next.
>>
>> Thanks.
>>
>> Regards
>> Ley Foon
>>
>> The following changes since commit f412fa8c2b82eba609c0f4494bad0da38606aa77:
>>
>>   configs: socfpga: fix building Stratix10 and Agilex (2019-12-13 01:58:15 
>> +0100)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/lftan/u-boot.git for-marek-next
>>
>> for you to fetch changes up to 9063341301cc9400c7673d369249b0ae8514a07d:
>>
>>   ddr: socfpga: Enable ARM64 Non-Secure SDRAM ECC Access (2019-12-13 
>> 17:25:37 +0800)
>>
>> 
>> Thor Thayer (2):
>>   arm: socfpga: stratix10: Enable SMMU access
>>   ddr: socfpga: Enable ARM64 Non-Secure SDRAM ECC Access
> 
> For some reason, this doesn't apply to socfpga/next . I rebased next on
> u-boot/master and pushed it, can you update the PR ? Thanks

Please ignore what I just said, I took the wrong pull URL. Applied to
next, thanks.


Re: [GIT PULL] For socfpga-next

2019-12-15 Thread Marek Vasut
On 12/13/19 10:49 AM, Tan, Ley Foon wrote:
> Hi Marek
> 
> Please pull the following update for socfpga-next.
> 
> Thanks.
> 
> Regards
> Ley Foon
> 
> The following changes since commit f412fa8c2b82eba609c0f4494bad0da38606aa77:
> 
>   configs: socfpga: fix building Stratix10 and Agilex (2019-12-13 01:58:15 
> +0100)
> 
> are available in the Git repository at:
> 
>   https://github.com/lftan/u-boot.git for-marek-next
> 
> for you to fetch changes up to 9063341301cc9400c7673d369249b0ae8514a07d:
> 
>   ddr: socfpga: Enable ARM64 Non-Secure SDRAM ECC Access (2019-12-13 17:25:37 
> +0800)
> 
> 
> Thor Thayer (2):
>   arm: socfpga: stratix10: Enable SMMU access
>   ddr: socfpga: Enable ARM64 Non-Secure SDRAM ECC Access

For some reason, this doesn't apply to socfpga/next . I rebased next on
u-boot/master and pushed it, can you update the PR ? Thanks


Re: [PATCH] clk: uclass: clk_get_by_name() must not be available if CONFIG_OF_PLATDATA is enabled

2019-12-15 Thread Giulio Benetti

Hi Lukasz,

On 12/15/19 2:50 PM, Lukasz Majewski wrote:

Hi Giulio,


On 12/13/19 11:09 AM, Lukasz Majewski wrote:

On Fri, 13 Dec 2019 00:02:25 +0100
Giulio Benetti  wrote:
   

Hi Lukasz,

On 12/12/19 11:53 PM, Giulio Benetti wrote:

clk_get_by_name() requires clk_get_by_id() that is not available
if CONFIG_OF_PLATDATA is defined, so move clk_get_by_name() into
#else condition of #if CONFIG_IS_ENABLED(OF_PLATDATA).

Signed-off-by: Giulio Benetti



I've already successfully executed a complete Travis with master
and this patch applied:
https://travis-ci.org/giuliobenetti/u-boot-imxrt/builds/624256888


Is this a preparatory patch for some other work? Or is it just a
standalone fix?


This is a standalone fix.


As we are really close to final U-Boot release - I'm more keen to add
this patch to u-boot-clk -next repository.

Do you mind ?


No problem at all, we'll see it "next"!

Best regards

--
Giulio Benetti
Benetti Engineering sas



Best regards





Best regards,

Lukasz Majewski

--

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





[RFC] new board VoCore2

2019-12-15 Thread Mauro Condarelli
I am trying to extend support to a new board "VoCore2" whose specs can
be found here: https://vocore.io/v2.html
Port is concerning the "ultimate" board which has all connectors in
place for SD, USB and Ethernet.
This board comes with a paleolithic (1.3.0) version of u-boot and I'm
trying to upgrade to a recent one
also because I need to implement "automatic upgrade" (possibly using
RAUC, but that is another story).

Port is working and able to boot Linuz, but it is not ready for
inclusion for several reasons
and I would like to have expert advice on how to tackle shortcomings, as
advised by stefanro on IRC:
> 6:49:14 AM - stefanro: mcon: Please submit the patches directly to the
> list, with me (and other MIPS / MT7628/88 experts - Daniel etc) on Cc.
> If you feel the patches are not ready for integration, then you can
> mark them as "RFC" in the subject.

Problematic areas I see (side from possible code style issues) are:
1) I added support for a new SPI NOR Flash and that should, probably, be
a separate patch.
2) I added support for SPI NOR partitioning and I'm unsure if that
should be in the "board definition".
3) SPI NOR partitioning is actually duplicated in ENV var (mtdparts) and
in Device Tree; I didn't find how to read it directly from DT.
4) Board also has SD, handled via MTK_SD driver, but I've been unable to
make it work.
5) Current binary is rather big and I would like to shrink it a bit, if
possible.

Any hint/criticism/advice would be VERY welcome.
Thanks in Advance
Mauro Condarelli
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index c9d75596f2..234bdfbaa9 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
 dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
+dtb-$(CONFIG_BOARD_VOCORE2) += vocore2.dtb
 dtb-$(CONFIG_TARGET_JZ4780_CI20) += ci20.dtb
 dtb-$(CONFIG_SOC_LUTON) += luton_pcb090.dtb luton_pcb091.dtb
 dtb-$(CONFIG_SOC_OCELOT) += ocelot_pcb120.dtb ocelot_pcb123.dtb
diff --git a/arch/mips/dts/vocore2.dts b/arch/mips/dts/vocore2.dts
new file mode 100644
index 00..826309965d
--- /dev/null
+++ b/arch/mips/dts/vocore2.dts
@@ -0,0 +1,84 @@
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+	compatible = "vocore,vocore2", "ralink,mt7628a-soc";
+	model = "VoCore2";
+
+	aliases {
+		serial0 = 
+		spi0 = 
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x0800>;
+	};
+
+	chosen {
+		bootargs = "console=ttyS2,115200 root=/dev/mtdblock4 rootfstype=squashfs USE=SD";
+		stdout-path = 
+	};
+};
+
+ {
+	state_default: pin_state {
+		p0led {
+			groups = "p0led_a";
+			function = "led";
+		};
+	};
+};
+
+ {
+	status = "okay";
+};
+
+ {
+	status = "okay";
+	nor0: m25p80@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "m25p80";
+		spi-max-frequency = <1000>;
+		reg = <0x0>;
+		m25p,chunked-io = <32>;
+
+		partition@0 {
+			label = "u-boot";
+			reg = <0x0 0x5>;
+		};
+		partition@5 {
+			label = "kernel";
+			reg = <0x5 0x2b>;
+		};
+		partition@30 {
+			label = "filesystem";
+			reg = <0x30 0xcfe000>;
+		};
+		partition@ffe000 {
+			label = "env";
+			reg = <0xffe000 0x001000>;
+		};
+		eeprom: partition@fff000 {
+			label = "factory";
+			reg = <0xfff000 0x001000>;
+		};
+	};
+};
+
+ {
+	pinctrl-names = "default";
+	pinctrl-0 = <_iot_mode>;
+	mediatek,poll-link-phy = <0>;
+};
+/*
+ {
+	status = "okay";
+	mediatek,mtd-eeprom = < 0x>;
+};
+*/
+ {
+	status = "okay";
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index c8dcf19c0d..5ea260232f 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -43,6 +43,14 @@ config BOARD_LINKIT_SMART_7688
 	  ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
 	  a MT7688 (PCIe).
 
+config BOARD_VOCORE2
+	bool "VoCore2"
+	depends on SOC_MT7628
+	select SUPPORTS_BOOT_RAM
+	help
+	  Vonger VoCore2 board has a MT7628 SoC with 128 MiB of RAM
+	  and 16 MiB of flash (SPI).
+
 endchoice
 
 choice
@@ -134,5 +142,6 @@ config SUPPORTS_BOOT_RAM
 
 source "board/gardena/smart-gateway-mt7688/Kconfig"
 source "board/seeed/linkit-smart-7688/Kconfig"
+source "board/vonger/vocore2/Kconfig"
 
 endmenu
diff --git a/board/vonger/vocore2/Kconfig b/board/vonger/vocore2/Kconfig
new file mode 100644
index 00..4067973e70
--- /dev/null
+++ b/board/vonger/vocore2/Kconfig
@@ -0,0 +1,11 @@
+if BOARD_VOCORE2
+config SYS_BOARD
+	default "vocore2"
+
+config SYS_VENDOR
+	default "vonger"
+
+config SYS_CONFIG_NAME
+	default "vocore2"
+
+endif
diff --git a/board/vonger/vocore2/Makefile b/board/vonger/vocore2/Makefile
new file mode 100644
index 00..4b162318c2
--- /dev/null
+++ b/board/vonger/vocore2/Makefile
@@ -0,0 +1,2 @@
+
+obj-y := board.o
diff --git a/board/vonger/vocore2/board.c b/board/vonger/vocore2/board.c
new file 

Re: [PATCH v3 4/6] drivers: net: add Felix DSA switch driver

2019-12-15 Thread Vladimir Oltean
On Sun, 15 Dec 2019 at 14:53, Vladimir Oltean  wrote:
>
> Hi Alex,
>
> On Tue, 3 Dec 2019 at 18:18, Alex Marginean  
> wrote:
> > +static int felix_port_enable(struct udevice *dev, int port,
> > +struct phy_device *phy)
> > +{
> > +   struct felix_priv *priv = dev_get_priv(dev);
> > +   void *base = priv->regs_base;
> > +
> > +   out_le32(base + FELIX_GMII_MAC_ENA_CFG(port),
> > +FELIX_GMII_MAX_ENA_CFG_TX | FELIX_GMII_MAX_ENA_CFG_RX);
> > +
> > +   out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),
> > +FELIX_QSYS_SYSTEM_SW_PORT_ENA |
> > +FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
> > +FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
> > +
> > +   if (phy)
> > +   phy_startup(phy);
> > +   return 0;
> > +}
> > +
> > +static void felix_port_disable(struct udevice *dev, int port,
> > +  struct phy_device *phy)
> > +{
> > +   struct felix_priv *priv = dev_get_priv(dev);
> > +   void *base = priv->regs_base;
> > +
> > +   out_le32(base + FELIX_GMII_MAC_ENA_CFG(port), 0);
> > +
> > +   out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),
> > +FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
> > +FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
> > +
> > +   /*
> > +* we don't call phy_shutdown here to avoind waiting next time we 
> > use
> > +* the port, but the downside is that remote side will think we're
> > +* actively processing traffic although we are not.
> > +*/
> > +}
> > --
> > 2.17.1
> >
>
> What is the correct general procedure here, is it to call phy_startup
> so late (felix_port_enable)? I'm trying to take this driver as an
> example for sja1105, which has RGMII so PCS and no autonomous in-band
> AN like felix does. On this switch, it is too late to do phy_startup
> now. Instead, I would need to look at phy->speed which should have
> been settled by now, and reprogram my MAC with it.
> My question is: don't you think phy_startup() and phy_shutdown()
> belong in the DSA uclass code?
>

My bad, phy_startup() is synchronous and waits for PHY AN to complete.
So this is fine.

> Thanks,
> -Vladimir


Re: [PATCH] clk: uclass: clk_get_by_name() must not be available if CONFIG_OF_PLATDATA is enabled

2019-12-15 Thread Lukasz Majewski
Hi Giulio,

> On 12/13/19 11:09 AM, Lukasz Majewski wrote:
> > On Fri, 13 Dec 2019 00:02:25 +0100
> > Giulio Benetti  wrote:
> >   
> >> Hi Lukasz,
> >>
> >> On 12/12/19 11:53 PM, Giulio Benetti wrote:  
> >>> clk_get_by_name() requires clk_get_by_id() that is not available
> >>> if CONFIG_OF_PLATDATA is defined, so move clk_get_by_name() into
> >>> #else condition of #if CONFIG_IS_ENABLED(OF_PLATDATA).
> >>>
> >>> Signed-off-by: Giulio Benetti
> >>>   
> >>
> >> I've already successfully executed a complete Travis with master
> >> and this patch applied:
> >> https://travis-ci.org/giuliobenetti/u-boot-imxrt/builds/624256888  
> > 
> > Is this a preparatory patch for some other work? Or is it just a
> > standalone fix?  
> 
> This is a standalone fix.

As we are really close to final U-Boot release - I'm more keen to add
this patch to u-boot-clk -next repository.

Do you mind ?

> 
> Best regards




Best regards,

Lukasz Majewski

--

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


pgpZ2fUs3lZbi.pgp
Description: OpenPGP digital signature


Please pull u-boot-x86/next to next branch

2019-12-15 Thread Bin Meng
Hi Tom,

This PR includes the following changes for u-boot/next branch.

- Various x86 common codes updated for TPL/SPL
- I2C designware driver updated for PCI
- ICH SPI driver updated to support Apollo Lake
- Add Intel FSP2 base support
- Intel Apollo Lake platform specific drivers support
- Add a new board Google Chromebook Coral

The following changes since commit 553cb06887825314e74a9bdac337467c77d1db88:

  Merge tag 'dm-next-13dec19' of
https://gitlab.denx.de/u-boot/custodians/u-boot-dm into next
(2019-12-12 08:18:59 -0500)

are available in the git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-x86 next

for you to fetch changes up to a1d6dc3f84071f05574044f337dbdca70fae495d:

  x86: Add chromebook_coral (2019-12-15 11:44:30 +0800)


Simon Glass (100):
  binman: Add a library to access binman entries
  dm: gpio: Allow control of GPIO uclass in SPL
  dm: core: Fix offset_to_ofnode() with invalid offset
  dm: pci: Allow delaying auto-config until after relocation
  dm: pci: Move pci_get_devfn() into a common file
  net: Move the checksum functions to lib/
  i2c: designware: Tidy up PCI support
  i2c: designware: Avoid using static data
  i2c: designware: Support use in SPL
  x86: spi: Add helper functions for Intel Fast SPI
  fdt: Show the preprocessed .dts file on error
  dm: pinctrl: Allow enabling full pinctrl in SPL/TPL
  board_r: Move early-timer init later
  x86: timer: use a timer base of 0
  x86: timer: Reduce timer code size in TPL on Intel CPUs
  x86: Drop unnecessary cpu code for TPL
  x86: Drop unnecessary interrupt code for TPL
  x86: power: Add an ACPI PMC uclass
  x86: sandbox: Add a PMC emulator and test
  pci: Add support for p2sb uclass
  sandbox: Disable mmio by default in tests
  sandbox: Add PCI driver and test for p2sb
  x86: Move UCLASS_IRQ into a separate file
  sandbox: Add a test for IRQ
  x86: Define the SPL image start
  x86: Reduce mrccache record alignment size
  x86: Correct mrccache find_next_mrc_cache() calculation
  x86: Adjust mrccache_get_region() to use livetree
  x86: Adjust mrccache_get_region() to support get_mmap()
  x86: Add a new global_data member for the cache record
  x86: Tidy up error handling in mrccache_save()
  x86: Update mrccache to support multiple caches
  x86: Add mrccache support for a 'variable' cache
  x86: Don't export mrccache_update()
  x86: Move fsp_prepare_mrc_cache() to fsp1 directory
  x86: Set the DRAM banks to reflect real location
  x86: Set up the MTRR for SDRAM
  x86: Don't imply libfdt or SPI flash in TPL
  x86: Allow removal of standard PCH drivers
  x86: Allow interrupt to happen once
  x86: fsp: Make graphics support common to FSP1/2
  x86: fsp: Correct wrong header inlude in fsp_support.c
  x86: fsp: Add FSP2 base support
  x86: fsp: Set up an MTRR for the graphics frame buffer
  x86: fsp: Add a new arch_fsp_init_r() hook
  x86: fsp: Allow remembering the location of FSP-S
  x86: fsp: Make the notify API call common
  x86: Don't include the BIOS emulator in TPL
  x86: Add an option to include a FIT
  x86: Add support for newer CAR schemes
  x86: Disable microcode section for FSP2
  x86: Update the fsp command for FSP2
  x86: Update .dtsi file for FSP2
  x86: Add an option to control the position of U-Boot
  x86: Add an option to control the position of SPL
  x86: Add an fdtmap and image-header
  x86: Don't repeat microcode in U-Boot if not needed
  x86: Separate out U-Boot and device tree in ROM image
  x86: Make MSR_PKG_POWER_SKU common
  spi: Correct operations check in dm_spi_xfer()
  x86: spi: Don't enable SPI_FLASH_BAR by default
  spi: ich: Move init function just above probe()
  spi: ich: Move the protection/lockdown code into a function
  spi: ich: Convert to livetree
  spi: ich: Fix header order
  spi: ich: Various small tidy-ups
  spi: ich: Add mmio_base to struct ich_spi_platdata
  dm: doc: Add a note about of-platdata and header files
  spi: ich: Correct max-size bug in ich_spi_adjust_size()
  spi: ich: Support of-platdata for fast-spi
  spi: ich: Support hardware sequencing
  spi: ich: Add support for get_mmap() method
  spi: ich: Add TPL support
  spi: ich: Add Apollo Lake support
  mtd: spi: Export spi_flash_std_probe()
  x86: Enable pinctrl in SPL and TPL
  x86: Add low-power subsystem (lpss) support
  x86: Add a generic Intel pinctrl driver
  x86: Add a generic Intel GPIO driver
  x86: Move qemu CPU fixup function into its own file
  x86: apl: Add basic IO addresses
  x86: apl: Add PMC driver
  x86: apl: Add UART driver
  x86: apl: Add pinctrl driver
  i2c: designware: Add Apollo Lake support
   

Re: [PATCH v3 1/6] net: introduce DSA class for Ethernet switches

2019-12-15 Thread Vladimir Oltean
On Tue, 3 Dec 2019 at 17:32, Alex Marginean  wrote:
> +/**
> + * This function deals with additional devices around the switch as these 
> should
> + * have been bound to drivers by now.
> + * TODO: pick up references to other switch devices here, if we're cascaded.
> + */
> +static int dm_dsa_pre_probe(struct udevice *dev)
> +{
> +   struct dsa_perdev_platdata *platdata = dev_get_platdata(dev);
> +   int i;
> +
> +   if (!platdata)
> +   return -EINVAL;
> +
> +   if (ofnode_valid(platdata->master_node))
> +   uclass_find_device_by_ofnode(UCLASS_ETH, 
> platdata->master_node,
> +>master_dev);
> +
> +   for (i = 0; i < platdata->num_ports; i++) {
> +   struct dsa_port_platdata *port = >port[i];
> +
> +   if (port->dev) {
> +   port->dev->priv = port;
> +   port->phy = dm_eth_phy_connect(port->dev);

Fixed-link interfaces don't work with DM_MDIO. That is somewhat
natural as there is no MDIO bus for a fixed-link. However the legacy
phy_connect function can be made rather easily to work with
fixed-link, since it has the necessary code for dealing with it
already. I am not, however, sure how it ever worked in the absence of
an MDIO bus.

commit 1b7e23cc7e6d0dc3fe7ae9c55390b40717ff3c3a
Author: Vladimir Oltean 
Date:   Sat Dec 14 23:25:40 2019 +0200

phy: make phy_connect_fixed work with a null mdio bus

It is utterly pointless to require an MDIO bus pointer for a fixed PHY
device. The fixed.c implementation does not require it, only
phy_device_create. Fix that.

Signed-off-by: Vladimir Oltean 

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 80a7664e4978..8ea5c9005291 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -658,7 +658,7 @@ static struct phy_device *phy_device_create(struct
mii_dev *bus, int addr,
dev = malloc(sizeof(*dev));
if (!dev) {
printf("Failed to allocate PHY device for %s:%d\n",
-  bus->name, addr);
+  bus ? bus->name : "(null bus)", addr);
return NULL;
}

@@ -686,7 +686,7 @@ static struct phy_device *phy_device_create(struct
mii_dev *bus, int addr,
return NULL;
}

-   if (addr >= 0 && addr < PHY_MAX_ADDR)
+   if (addr >= 0 && addr < PHY_MAX_ADDR && phy_id != PHY_FIXED_ID)
bus->phymap[addr] = dev;

return dev;

With the patch above in place, fixed-link can also be made to work
with some logic similar to what can be seen below:

if (ofnode_valid(ofnode_find_subnode(port->dev->node, "fixed-link")))
port->phy = phy_connect(NULL, 0, port->dev, phy_mode); //
phy_mode needs to be pre-parsed somewhere else as well
else
port->phy = dm_eth_phy_connect(port->dev);

How would you see fixed-link interfaces being treated? My question so
far is in the context of front-panel ports but I am interested in your
view of the CPU port situation as well.

> +   }
> +   }
> +
> +   return 0;
> +}

Thanks,
-Vladimir


Re: [PATCH v3 4/6] drivers: net: add Felix DSA switch driver

2019-12-15 Thread Vladimir Oltean
On Sun, 15 Dec 2019 at 14:53, Vladimir Oltean  wrote:
>
> Hi Alex,
>
> On Tue, 3 Dec 2019 at 18:18, Alex Marginean  
> wrote:
> > +static int felix_port_enable(struct udevice *dev, int port,
> > +struct phy_device *phy)
> > +{
> > +   struct felix_priv *priv = dev_get_priv(dev);
> > +   void *base = priv->regs_base;
> > +
> > +   out_le32(base + FELIX_GMII_MAC_ENA_CFG(port),
> > +FELIX_GMII_MAX_ENA_CFG_TX | FELIX_GMII_MAX_ENA_CFG_RX);
> > +
> > +   out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),
> > +FELIX_QSYS_SYSTEM_SW_PORT_ENA |
> > +FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
> > +FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
> > +
> > +   if (phy)
> > +   phy_startup(phy);
> > +   return 0;
> > +}
> > +
> > +static void felix_port_disable(struct udevice *dev, int port,
> > +  struct phy_device *phy)
> > +{
> > +   struct felix_priv *priv = dev_get_priv(dev);
> > +   void *base = priv->regs_base;
> > +
> > +   out_le32(base + FELIX_GMII_MAC_ENA_CFG(port), 0);
> > +
> > +   out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),
> > +FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
> > +FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
> > +
> > +   /*
> > +* we don't call phy_shutdown here to avoind waiting next time we 
> > use
> > +* the port, but the downside is that remote side will think we're
> > +* actively processing traffic although we are not.
> > +*/
> > +}
> > --
> > 2.17.1
> >
>
> What is the correct general procedure here, is it to call phy_startup
> so late (felix_port_enable)? I'm trying to take this driver as an
> example for sja1105, which has RGMII so PCS and no autonomous in-band

RGMII, so no* PCS

> AN like felix does. On this switch, it is too late to do phy_startup
> now. Instead, I would need to look at phy->speed which should have
> been settled by now, and reprogram my MAC with it.
> My question is: don't you think phy_startup() and phy_shutdown()
> belong in the DSA uclass code?
>
> Thanks,
> -Vladimir


Re: [PATCH v3 4/6] drivers: net: add Felix DSA switch driver

2019-12-15 Thread Vladimir Oltean
Hi Alex,

On Tue, 3 Dec 2019 at 18:18, Alex Marginean  wrote:
> +static int felix_port_enable(struct udevice *dev, int port,
> +struct phy_device *phy)
> +{
> +   struct felix_priv *priv = dev_get_priv(dev);
> +   void *base = priv->regs_base;
> +
> +   out_le32(base + FELIX_GMII_MAC_ENA_CFG(port),
> +FELIX_GMII_MAX_ENA_CFG_TX | FELIX_GMII_MAX_ENA_CFG_RX);
> +
> +   out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),
> +FELIX_QSYS_SYSTEM_SW_PORT_ENA |
> +FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
> +FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
> +
> +   if (phy)
> +   phy_startup(phy);
> +   return 0;
> +}
> +
> +static void felix_port_disable(struct udevice *dev, int port,
> +  struct phy_device *phy)
> +{
> +   struct felix_priv *priv = dev_get_priv(dev);
> +   void *base = priv->regs_base;
> +
> +   out_le32(base + FELIX_GMII_MAC_ENA_CFG(port), 0);
> +
> +   out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),
> +FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
> +FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
> +
> +   /*
> +* we don't call phy_shutdown here to avoind waiting next time we use
> +* the port, but the downside is that remote side will think we're
> +* actively processing traffic although we are not.
> +*/
> +}
> --
> 2.17.1
>

What is the correct general procedure here, is it to call phy_startup
so late (felix_port_enable)? I'm trying to take this driver as an
example for sja1105, which has RGMII so PCS and no autonomous in-band
AN like felix does. On this switch, it is too late to do phy_startup
now. Instead, I would need to look at phy->speed which should have
been settled by now, and reprogram my MAC with it.
My question is: don't you think phy_startup() and phy_shutdown()
belong in the DSA uclass code?

Thanks,
-Vladimir


Re: [PATCH v3 1/6] net: introduce DSA class for Ethernet switches

2019-12-15 Thread Vladimir Oltean
Hi Alex,

On Tue, 3 Dec 2019 at 17:32, Alex Marginean  wrote:
>
> DSA stands for Distributed Switch Architecture and it covers switches that
> are connected to the CPU through an Ethernet link and generally use frame
> tags to pass information about the source/destination ports to/from CPU.
> Front panel ports are presented as regular ethernet devices in U-Boot and
> they are expected to support the typical networking commands.
> DSA switches may be cascaded, DSA class code does not currently support
> this.
>
> Signed-off-by: Alex Marginean 
> ---
>  drivers/net/Kconfig|  13 ++
>  include/dm/uclass-id.h |   1 +
>  include/net/dsa.h  | 141 
>  net/Makefile   |   1 +
>  net/dsa-uclass.c   | 369 +
>  5 files changed, 525 insertions(+)
>  create mode 100644 include/net/dsa.h
>  create mode 100644 net/dsa-uclass.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 4182897d89..a4157cb122 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -37,6 +37,19 @@ config DM_MDIO_MUX
>   This is currently implemented in net/mdio-mux-uclass.c
>   Look in include/miiphy.h for details.
>
> +config DM_DSA
> +   bool "Enable Driver Model for DSA switches"
> +   depends on DM_ETH && DM_MDIO
> +   help
> + Enable Driver Model for DSA switches
> +
> + Adds UCLASS_DSA class supporting switches that follow the 
> Distributed
> + Switch Architecture (DSA).  These switches rely on the presence of a
> + management switch port connected to an Ethernet controller capable 
> of
> + receiving frames from the switch.  This host Ethernet controller is
> + called "master" and "cpu" in DSA terminology.
> + This is currently implemented in net/dsa-uclass.c
> +
>  config MDIO_SANDBOX
> depends on DM_MDIO && SANDBOX
> default y
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 0c563d898b..8f37a91488 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -42,6 +42,7 @@ enum uclass_id {
> UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
> UCLASS_DSI_HOST,/* Display Serial Interface host */
> UCLASS_DMA, /* Direct Memory Access */
> +   UCLASS_DSA, /* Distributed (Ethernet) Switch Architecture 
> */
> UCLASS_EFI, /* EFI managed devices */
> UCLASS_ETH, /* Ethernet device */
> UCLASS_FIRMWARE,/* Firmware */
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> new file mode 100644
> index 00..2387419b9d
> --- /dev/null
> +++ b/include/net/dsa.h
> @@ -0,0 +1,141 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2019 NXP
> + */
> +
> +#ifndef __DSA_H__
> +#define __DSA_H__
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * DSA stands for Distributed Switch Architecture and it is infrastructure
> + * intended to support drivers for Switches that rely on an intermediary
> + * Ethernet device for I/O.  These switches may support cascading allowing
> + * them to be arranged as a tree.
> + * DSA is documented in detail in the Linux kernel documentation under
> + * Documentation/networking/dsa/dsa.txt
> + * The network layout of such a switch is shown below:
> + *
> + * |---
> + * | CPU network device (eth0)|
> + * 
> + * |  + * |  |
> + * |  |
> + * |tag added by CPU> |
> + * ||
> + * | Switch driver  |
> + * ||
> + * |||| ||
> + * |---|  |---|  |---|
> + * | sw0p0 |  | sw0p1 |  | sw0p2 |
> + * |---|  |---|  |---|
> + *
> + * In U-Boot the intent is to allow access to front panel ports (shown at the
> + * bottom of the picture) though the master Ethernet port (eth0 in the 
> picture).
> + * Front panel ports are presented as regular Ethernet devices in U-Boot and
> + * they are expected to support the typical networking commands.
> + * In general DSA switches require the use of tags, extra headers added both 
> by
> + * software on Tx and by the switch on Rx.  These tags carry at a minimum 
> port
> + * information and switch information for cascaded set-ups.
> + * In U-Boot these tags are inserted and parsed by the DSA switch driver, the
> + * class code helps with headroom/tailroom for the extra headers.
> + *
> + * TODO:
> + * - handle switch cascading, for now U-Boot only supports stand-alone 
> switches.
> + * - propagate the master Eth MAC address to switch ports, this is used in
> + * Linux to avoid using additional MAC addresses on master Eth.

Any idea how this would be done?
The DSA master