Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 9 May 2023 15:25:41 +0300 (EEST)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     Arnd Bergmann <arnd@arndb.de>
cc:     Jacky Huang <ychuang570808@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        krzysztof.kozlowski+dt@linaro.org, Lee Jones <lee@kernel.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Tomer Maimon <tmaimon77@gmail.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, devicetree@vger.kernel.org,
        linux-clk@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        linux-arm-kernel@lists.infradead.org,
        linux-serial <linux-serial@vger.kernel.org>, schung@nuvoton.com,
        mjchen@nuvoton.com, Jacky Huang <ychuang3@nuvoton.com>
Subject: Re: [PATCH v10 10/10] tty: serial: Add Nuvoton ma35d1 serial driver
 support
In-Reply-To: <eeeaf258-8f2b-436a-aba0-b32dc90b359f@app.fastmail.com>
Message-ID: <b9573562-d4d7-3535-fb4d-f2bc694f2a4@linux.intel.com>
References: <20230508025936.36776-1-ychuang570808@gmail.com> <20230508025936.36776-11-ychuang570808@gmail.com> <2ba483e9-267f-2159-1ea8-75a2618fcdf9@linux.intel.com> <eeeaf258-8f2b-436a-aba0-b32dc90b359f@app.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-1414178471-1683634754=:2036"
Content-ID: <9bb37169-6cc8-9ecf-9c75-4d17151c32d@linux.intel.com>
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1414178471-1683634754=:2036
Content-Type: text/plain; CHARSET=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Content-ID: <ba1258be-c4c9-856b-c814-9cd42d1740c8@linux.intel.com>

On Tue, 9 May 2023, Arnd Bergmann wrote:

> On Tue, May 9, 2023, at 12:17, Ilpo J?rvinen wrote:
> > On Mon, 8 May 2023, Jacky Huang wrote:
> >> +
> >> +#define UART_NR			17
> >> +
> >> +#define UART_REG_RBR		0x00
> >> +#define UART_REG_THR		0x00
> >> +#define UART_REG_IER		0x04
> >> +#define UART_REG_FCR		0x08
> >> +#define UART_REG_LCR		0x0C
> >> +#define UART_REG_MCR		0x10
> >
> > These duplicate include/uapi/linux/serial_reg.h ones, use the std ones 
> > directly.
> >
> > Setup regshift too and use it in serial_in.
> 
> I think this came up in previous reviews, but it turned out that
> only the first six registers are compatible, while the later
> ones are all different, and it's not 8250 compatible.

So use the normal name for compatible ones and HW specific names for the 
others?

It might not be compatible in everything but surely 8250 influence is 
visible here and there.

> It might be helpful to rename the registers to something
> with a prefix other than UART_REG_*, to avoid the confusion
> and possible namespace clash.

That is what I also suggested for the rest of the registers.

-- 
 i.

> >> +/* UART_REG_IER - Interrupt Enable Register */
> >> +#define IER_RDA_IEN		BIT(0)  /* RBR Available Interrupt Enable */
> >> +#define IER_THRE_IEN		BIT(1)  /* THR Empty Interrupt Enable */
> >> +#define IER_RLS_IEN		BIT(2)  /* RX Line Status Interrupt Enable */
> >
> > These look same as UART_IER bits, use the std ones.
> ...
> > Are these same as UART_FCR_CLEAR_* functionality wise? If they're use std 
> > ones.
> 
> Again, I'd think we're better off having a distinct naming for
> them than trying to share the definitions with 8250.
> 
> >> +static struct uart_driver ma35d1serial_reg = {
> >> +	.owner        = THIS_MODULE,
> >> +	.driver_name  = "serial",
> >> +	.dev_name     = "ttyS",
> >> +	.major        = TTY_MAJOR,
> >> +	.minor        = 64,
> >> +	.cons         = MA35D1SERIAL_CONSOLE,
> >> +	.nr           = UART_NR,
> >> +};
> >
> > This doesn't seem necessary, 8250 core will have the uart_driver for you
> > and most of the console stuff too. You just need to setup a few things 
> > correctly (see the setup functions in 8250_early for ideas/examples).
> >...
> >> +
> >> +	ret = uart_add_one_port(&ma35d1serial_reg, &up->port);
> >
> > For 8250, you should be using serial8250_register_8250_port(). See the 
> > other drivers how to setup the console functions.
> 
> Consequently, this should also be kept separate from the serial8250
> driver, I don't see a way to fit the nuvoton code into the existing
> driver without making the resulting driver worse for everyone.
> 
> There is one thing that absolutely needs to be changed though:
> the driver_name/dev_name/major/minor fields all clash with the
> 8250 driver, so you cannot have a kernel that has both drivers
> built-in. All of these should change to get out of the way of the
> existing drivers.
> 
>         Arnd
> 
--8323329-1414178471-1683634754=:2036--