Messages in this thread | | | From | <> | Subject | RE: [PATCH v9 tty-next 2/4] serial: 8250_pci1xxxx: Add driver for quad-uart support | Date | Fri, 16 Dec 2022 05:40:31 +0000 |
| |
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Sent: Thursday, December 15, 2022 11:13 PM > To: Kumaravel Thiagarajan - I21417 > <Kumaravel.Thiagarajan@microchip.com> > <Tharunkumar.Pasumarthi@microchip.com> > 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
| |