On Thu, 18 Apr 2024 19:29:44 +0300 (EEST) Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote: > On Thu, 18 Apr 2024, Parker Newman wrote: > > On Thu, 18 Apr 2024 16:20:15 +0300 (EEST) > > Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote: > > > > > On Wed, 17 Apr 2024, Parker Newman wrote: > > > > From: Parker Newman <pnewman@xxxxxxxxxxxxxxx> > > > > > > > > This is a large patch but is only additions. All changes and removals > > > > are made in previous patches in this series. > > > > > > > > - 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 > > > > > > > > Signed-off-by: Parker Newman <pnewman@xxxxxxxxxxxxxxx> > > > > > @@ -192,11 +252,201 @@ struct exar8250_board { > > > > > > > > struct exar8250 { > > > > unsigned int nr; > > > > + unsigned int osc_freq; > > > > struct exar8250_board *board; > > > > void __iomem *virt; > > > > int line[]; > > > > }; > > > > > > > > +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); > > > > +} > > > > > > I tried to understand what is going on with this priv->virt in 8250_exar > > > in general and why it exists but I failed. It seems to BAR0 is mapped > > > there but also serial8250_pci_setup_port() does map the same BAR and > > > sets it up into the usual place in membase. > > > > > > > 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. > > Okay, thanks for explaining. The naming & lack of comments wasn't exactly > making it easy to follow this bit (this is not your fault in anyway but > a pre-existing problem in the driver's code). > > I've a follow up question now that it's confirmed they're different, > see below... > > > > > + exar_write_reg(priv, (offset + UART_EXAR_8XMODE), 0x00); > > > > + exar_write_reg(priv, (offset + UART_EXAR_FCTR), UART_FCTR_EXAR_TRGD); > > > > + exar_write_reg(priv, (offset + UART_EXAR_TXTRG), 128); > > > > + exar_write_reg(priv, (offset + UART_EXAR_RXTRG), 128); > > > > > > Unnecessary parenthesis. > > > > > + exar_write_reg(priv, (offset + UART_EXAR_8XMODE), 0x00); > > > > + exar_write_reg(priv, (offset + UART_EXAR_FCTR), UART_FCTR_EXAR_TRGD); > > > > + exar_write_reg(priv, (offset + UART_EXAR_TXTRG), 32); > > > > + exar_write_reg(priv, (offset + UART_EXAR_RXTRG), 32); > > > > > > Unnecessary parenthesis. > > > > > > > I will fix these in my cleanup patches. > > Based on the wording in your response, I'm not sure you got this right. It > is code you're adding in this patch so the parenthesis should be removed > from this change so they never appear in the commit history. > 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 misunderstood. I already sent these fixes in a new mini-series. > > > I recommend you add a helper for this as it is repeated twice. Are the > > > values 32 and 128 literal or do they have some specific meaning? If the > > > latter case, they should be using named defines (this likely applies to > > > the existing trigger code in the driver too). > > > > > > > > > > They are the FIFO trigger levels so they are literally 128 and 32. > > Okay, no problem then if its 128 characters and 32 characters. > > > These 4 writes come from Exar's out-of-tree driver and are in > > pci_xr17v35x_setup() and some other vendor specific functions. > > > > I am not sure why/if these are needed. > > ...So the follow-up question. I see the existing code in > pci_fastcom335_setup() and pci_xr17v35x_setup() writes into membase > based address but your code uses exar_write_reg() which is priv->virt > based. Is this difference intentional? > 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 = port->port.membase; writeb(0x00, p + UART_EXAR_8XMODE);