Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 10 Nov 2020 07:01:33 +0900
From:   Stafford Horne <shorne@gmail.com>
To:     Mateusz Holenko <mholenko@antmicro.com>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jslaby@suse.com>, devicetree@vger.kernel.org,
        linux-serial@vger.kernel.org, Karol Gugala <kgugala@antmicro.com>,
        Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        "Paul E. McKenney" <paulmck@linux.ibm.com>,
        Filip Kokosinski <fkokosinski@antmicro.com>,
        Pawel Czarnecki <pczarnecki@internships.antmicro.com>,
        Joel Stanley <joel@jms.id.au>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Maxime Ripard <mripard@kernel.org>,
        Shawn Guo <shawnguo@kernel.org>,
        Heiko Stuebner <heiko@sntech.de>,
        Sam Ravnborg <sam@ravnborg.org>,
        Icenowy Zheng <icenowy@aosc.io>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        linux-kernel@vger.kernel.org,
        "Gabriel L. Somlo" <gsomlo@gmail.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v12 0/5] LiteX SoC controller and LiteUART serial driver
Message-ID: <20201109220133.GA961977@lianli.shorne-pla.net>
References: <20201013164454.2002023-0-mholenko@antmicro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201013164454.2002023-0-mholenko@antmicro.com>
Precedence: bulk

On Tue, Oct 13, 2020 at 04:45:09PM +0200, Mateusz Holenko wrote:
> This patchset introduces support for LiteX SoC Controller
> and LiteUART - serial device from LiteX SoC builder
> (https://github.com/enjoy-digital/litex).
> 
> In the following patchset I will add
> a new mor1kx-based (OpenRISC) platform that
> uses this device.
> 
> Later I plan to extend this platform by
> adding support for more devices from LiteX suite.
> 
> Changes in v12:
>     - fixed descriptions in yaml files
>     - simplified probe implementations
>     - introduced litex_{read,write}{8,16,32,64}() fast accessors
>     - added formal documentation of litex_get_reg()/litex_set_reg()
>     - fixed possible memory leaks
>     - removed spin locks from CSR accessors
> 
> Changes in v11:
>     - added Reviewed-by tag
>     - reformatted some comments
>     - switched to WARN instead of BUG on CSR validation fail
> 
> Changes in v10:
>     - added casting to avoid sparse warnings in the SoC Controller's driver
> 
> Changes in v9:
>     - fixed the `reg` node notation in the DT example
>     - added exporting of the `litex_set_reg`/`litex_get_reg` symbols
> 
> Changes in v8:
>     - fixed help messages in LiteUART's KConfig
>     - removed dependency between LiteUART and LiteX SoC drivers
>     - removed `litex_check_accessors()` helper function
>     - added crashing (BUG) on the failed LiteX CSR access test
> 
> Changes in v7:
>     - added missing include directive in UART's driver
> 
> Changes in v6:
>     - changed accessors in SoC Controller's driver
>     - reworked UART driver
> 
> Changes in v5:
>     - added Reviewed-by tag
>     - removed custom accessors from SoC Controller's driver
>     - fixed error checking in SoC Controller's driver
> 
> Changes in v4:
>     - fixed copyright headers
>     - fixed SoC Controller's yaml 
>     - simplified SoC Controller's driver
> 
> Changes in v3:
>     - added Acked-by and Reviewed-by tags
>     - introduced LiteX SoC Controller driver
>     - removed endianness detection (handled now by LiteX SoC Controller driver)
>     - modified litex.h header
>     - DTS aliases for LiteUART made optional
>     - renamed SERIAL_LITEUART_NR_PORTS to SERIAL_LITEUART_MAX_PORTS
>     - changed PORT_LITEUART from 122 to 123
> 
> Changes in v2:
>     - binding description rewritten to a yaml schema file
>     - added litex.h header with common register access functions
> 
> Filip Kokosinski (3):
>   dt-bindings: vendor: add vendor prefix for LiteX
>   dt-bindings: serial: document LiteUART bindings
>   drivers/tty/serial: add LiteUART driver
> 
> Pawel Czarnecki (2):
>   dt-bindings: soc: document LiteX SoC Controller bindings
>   drivers/soc/litex: add LiteX SoC Controller driver
> 
>  .../bindings/serial/litex,liteuart.yaml       |  38 ++
>  .../soc/litex/litex,soc-controller.yaml       |  39 ++
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  MAINTAINERS                                   |   9 +
>  drivers/soc/Kconfig                           |   1 +
>  drivers/soc/Makefile                          |   1 +
>  drivers/soc/litex/Kconfig                     |  19 +
>  drivers/soc/litex/Makefile                    |   3 +
>  drivers/soc/litex/litex_soc_ctrl.c            | 176 ++++++++
>  drivers/tty/serial/Kconfig                    |  32 ++
>  drivers/tty/serial/Makefile                   |   1 +
>  drivers/tty/serial/liteuart.c                 | 404 ++++++++++++++++++
>  include/linux/litex.h                         | 103 +++++
>  13 files changed, 831 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml
>  create mode 100644 Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
>  create mode 100644 drivers/soc/litex/Kconfig
>  create mode 100644 drivers/soc/litex/Makefile
>  create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
>  create mode 100644 drivers/tty/serial/liteuart.c
>  create mode 100644 include/linux/litex.h
(CCing Linus)

Hello,

As it looks like we have all required signoffs and no issues with the latest v12
series I have queued this in the OpenRISC 5.11 queue (where we are one of the
first users in our platform).

I am CCing Linus in case he has any concerns with these merging through the
OpenRISC queue.

In the LiteX ecosystem RISC-V and lm32 (lattice micro 32 soft core) FPGA SoC's
are also used which take advantage of these drivers.  There will be more to come
in the future, probably the next being LiteETH (ethernet).

-Stafford