RE: [PATCH v9 tty-next 2/4] serial: 8250_pci1xxxx: Add driver for quad-uart support

From: Tharunkumar.Pasumarthi
Date: Fri Dec 16 2022 - 00:40:47 EST


> From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> Sent: Thursday, December 15, 2022 11:13 PM
> To: Kumaravel Thiagarajan - I21417
> <Kumaravel.Thiagarajan@xxxxxxxxxxxxx>
> <Tharunkumar.Pasumarthi@xxxxxxxxxxxxx>
> Subject: Re: [PATCH v9 tty-next 2/4] serial: 8250_pci1xxxx: Add driver for
> quad-uart support
>
> > + ret = serial8250_pci_setup_port(pdev, port, 0, port_idx * 256,
> > + 0);
>
> Actually isn't 0x100 better (show that there is an offset rather than a value of
> an register)?

Okay, I will so something like this,
#define PORT_OFFSET 0x100
ret = serial8250_pci_setup_port(pdev, port, 0, PORT_OFFSET * port_idx, 0);

> > + num_vectors = pci_alloc_irq_vectors(pdev, 1, max_vec_reqd,
> PCI_IRQ_ALL_TYPES);
> > + if (num_vectors < 0) {
>
> > + pci_iounmap(pdev, priv->membase);
>
> Here is inconsistency on how you interpret pci_*() calls when
> pcim_enable_device() has been used. I.e. for IRQ you don't deallocate
> resources explicitly (yes, it's done automatically anyway), but you explicitly
> call pci_iounmap(). Choose a single approach for all of them.

AFAIK call to pci_iounmap cannot be avoided since pci_ioremap_bar is not 'managed' API.
You suggest calling pci_free_irq_vectors (even though it is not mandatory)?

Thanks,
Tharun Kumar P