Received-SPF: pass (google.com: domain of linux-kernel+bounces-150537-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 18 Apr 2024 13:03:46 -0400
From: Parker Newman <parker@finest.io>
To: Ilpo =?UTF-8?B?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby
 <jirislaby@kernel.org>, LKML <linux-kernel@vger.kernel.org>, linux-serial
 <linux-serial@vger.kernel.org>, Parker Newman <pnewman@connecttech.com>
Subject: Re: [PATCH v4 6/7] serial: exar: add CTI specific setup code
Message-ID: <20240418130346.12530fdb@SWDEV2.connecttech.local>
In-Reply-To: <8c91f3a5-e124-aa28-06bb-2e6a699d4998@linux.intel.com>
References: <cover.1713382717.git.pnewman@connecttech.com>
	<ae4a66e7342b686cb8d4b15317585dfb37222cf4.1713382717.git.pnewman@connecttech.com>
	<f2353b8c-2079-b895-2707-f6be83161288@linux.intel.com>
	<20240418102153.554d56ba@SWDEV2.connecttech.local>
	<8c91f3a5-e124-aa28-06bb-2e6a699d4998@linux.intel.com>
Organization: Connect Tech Inc.
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:tjcr0Ahnnec=;gteE6YzDXl5uqbwyvx7UohYmLNk
 JsbPXtz/URu0wLgqY5eY+LN+E5LVOZNbq4rISUy/1f9w52wkUFyw4XmciPZyGj73LWVYo3Yt0
 IugX/J5neCpHVdCdcbdDSH9RJO2AgpXEm0+eGp30+mO0rfYWlG6+Q+7K7kGpvzT2ioiSgA99x
 C8ZHUejanlT3niJaT24Ms7lQtPcMwvfkJT+oASBPanNfnont1eTDXpP7iNey9VJi/4XEbUMeS
 UZXVFibNIhLP7Xx5yObi5/FtvtciW4V63GjYgWAxAlnnXKu85qgcr7AN+hOUHKS34A0PzA98x
 A/f/85XSU9MrzWtn6ZJxtYkTkhRjNvUb68UxYcryI8Nqd1cRCLQE2YkmXUSm0c0b+Qbak1Tpv
 226eav7rndECgztJmVbiHbYCNMjxz+1wBNE0DJ935YTyV5ee4VhM7yn898uLpxpQ30O5sXNH2
 8HaYzPtJEChmUaFcPw9DzHx1Gg2rnG5zG/e1yiqDxYZGgWp5FAZc9H0BIz4gooGOKFNrLEVKr
 56pLD5g1tw67Tmcys/Vv+p1rUirz3xDIHryfPXPh1N039dlzWwYFbvO+g5Q2ELg208AipGAkB
 7qmkA6fDwCUZQ8lOXJNTF+7NtbqTT2O3yP15UPQ29seB7iEpAmac8Qg6nX8ICutDHC8jtOLX/
 5gQL6Kui1mrrXIFR3aucrm33BBllLFXtazd5Zx+eFq/UfQRTAeAhnT0rQQ9ca8Dnvi9Oy3wJv
 X8dL0sgQcdYW3KoEfpYaWVDGEoNbEN2+v4UbQx8yf+5hPkz965+g/U=

On Thu, 18 Apr 2024 19:29:44 +0300 (EEST)
Ilpo J=C3=A4rvinen <ilpo.jarvinen@linux.intel.com> wrote:

> On Thu, 18 Apr 2024, Parker Newman wrote:
> > On Thu, 18 Apr 2024 16:20:15 +0300 (EEST)
> > Ilpo J=C3=A4rvinen <ilpo.jarvinen@linux.intel.com> wrote:
> >  =20
> > > On Wed, 17 Apr 2024, Parker Newman wrote: =20
> > > > From: Parker Newman <pnewman@connecttech.com>
> > > >=20
> > > > This is a large patch but is only additions. All changes and remova=
ls
> > > > are made in previous patches in this series.
> > > >=20
> > > > - Add CTI board_init and port setup functions for each UART type
> > > > - Add CTI_EXAR_DEVICE() and CTI_PCI_DEVICE() macros
> > > > - Add support for reading a word from the Exar EEPROM.
> > > > - Add support for configuring and setting a single MPIO
> > > > - Add various helper functions for CTI boards.
> > > > - Add osc_freq to struct exar8250
> > > >=20
> > > > Signed-off-by: Parker Newman <pnewman@connecttech.com> =20
>=20
> > > > @@ -192,11 +252,201 @@ struct exar8250_board {
> > > >=20
> > > >  struct exar8250 {
> > > >  	unsigned int		nr;
> > > > +	unsigned int		osc_freq;
> > > >  	struct exar8250_board	*board;
> > > >  	void __iomem		*virt;
> > > >  	int			line[];
> > > >  };
> > > >=20
> > > > +static inline void exar_write_reg(struct exar8250 *priv,
> > > > +				unsigned int reg, u8 value)
> > > > +{
> > > > +	writeb(value, priv->virt + reg);
> > > > +}
> > > > +
> > > > +static inline u8 exar_read_reg(struct exar8250 *priv, unsigned int=
 reg)
> > > > +{
> > > > +	return readb(priv->virt + reg);
> > > > +}   =20
> > >=20
> > > I tried to understand what is going on with this priv->virt in 8250_e=
xar=20
> > > in general and why it exists but I failed. It seems to BAR0 is mapped=
=20
> > > there but also serial8250_pci_setup_port() does map the same BAR and=
=20
> > > sets it up into the usual place in membase.
> > >  =20
> >=20
> > Exar PCI/PCIe UARTs have global configuration registers from 0x80-0x9B.
> > These registers are for reading the EEPROM, configuring the MPIO, etc.
> > As these registers are only at 0x80, and not port specific, the driver =
maps
> > BAR0 to priv->virt for accessing them.  =20
>=20
> Okay, thanks for explaining. The naming & lack of comments wasn't exactly=
=20
> making it easy to follow this bit (this is not your fault in anyway but=20
> a pre-existing problem in the driver's code).
>=20
> I've a follow up question now that it's confirmed they're different,=20
> see below...
>=20
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_8XMODE), 0x00);
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_FCTR), UART_FCTR_EXAR_TR=
GD);
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_TXTRG), 128);
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_RXTRG), 128);   =20
> > >=20
> > > Unnecessary parenthesis. =20
>=20
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_8XMODE), 0x00);
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_FCTR), UART_FCTR_EXAR_TR=
GD);
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_TXTRG), 32);
> > > > +	exar_write_reg(priv, (offset + UART_EXAR_RXTRG), 32);   =20
> > >=20
> > > Unnecessary parenthesis.
> > >  =20
> >=20
> > I will fix these in my cleanup patches.  =20
>=20
> Based on the wording in your response, I'm not sure you got this right. I=
t=20
> is code you're adding in this patch so the parenthesis should be removed=
=20
> from this change so they never appear in the commit history.
>=20

Greg has already merged this series into his testing branch. I assumed any
changes would need to be made in a separate patch series? Sorry if I=20
misunderstood. I already sent these fixes in a new mini-series.=20

> > > I recommend you add a helper for this as it is repeated twice. Are th=
e=20
> > > values 32 and 128 literal or do they have some specific meaning? If t=
he=20
> > > latter case, they should be using named defines (this likely applies =
to=20
> > > the existing trigger code in the driver too).
> > >=20
> > >  =20
> >=20
> > They are the FIFO trigger levels so they are literally 128 and 32.  =20
>=20
> Okay, no problem then if its 128 characters and 32 characters.
>=20
> > These 4 writes come from Exar's out-of-tree driver and are in=20
> > pci_xr17v35x_setup() and some other vendor specific functions.=20
> >=20
> > I am not sure why/if these are needed.  =20
>=20
> ...So the follow-up question. I see the existing code in=20
> pci_fastcom335_setup() and pci_xr17v35x_setup() writes into membase=20
> based address but your code uses exar_write_reg() which is priv->virt=20
> based. Is this difference intentional?
>=20

Both methods are effectively the same thing. I used exar_write_reg() to be
consistent with my other code and it is a bit cleaner than:

	u8 __iomem *p;

	p =3D port->port.membase;

	writeb(0x00, p + UART_EXAR_8XMODE);