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;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6
Mime-Version: 1.0
Message-Id: <eeeaf258-8f2b-436a-aba0-b32dc90b359f@app.fastmail.com>
In-Reply-To: <2ba483e9-267f-2159-1ea8-75a2618fcdf9@linux.intel.com>
References: <20230508025936.36776-1-ychuang570808@gmail.com>
 <20230508025936.36776-11-ychuang570808@gmail.com>
 <2ba483e9-267f-2159-1ea8-75a2618fcdf9@linux.intel.com>
Date:   Tue, 09 May 2023 14:14:00 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
        "Jacky Huang" <ychuang570808@gmail.com>
Cc:     "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
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, May 9, 2023, at 12:17, Ilpo J=C3=A4rvinen 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=20
> 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.

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.

>
>> +/* 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=20
> 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 =3D {
>> +	.owner        =3D THIS_MODULE,
>> +	.driver_name  =3D "serial",
>> +	.dev_name     =3D "ttyS",
>> +	.major        =3D TTY_MAJOR,
>> +	.minor        =3D 64,
>> +	.cons         =3D MA35D1SERIAL_CONSOLE,
>> +	.nr           =3D UART_NR,
>> +};
>
> This doesn't seem necessary, 8250 core will have the uart_driver for y=
ou
> and most of the console stuff too. You just need to setup a few things=20
> correctly (see the setup functions in 8250_early for ideas/examples).
>...
>> +
>> +	ret =3D uart_add_one_port(&ma35d1serial_reg, &up->port);
>
> For 8250, you should be using serial8250_register_8250_port(). See the=20
> 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