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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 16, 2022 at 05:40:31AM +0000, Tharunkumar.Pasumarthi@xxxxxxxxxxxxx wrote:
> > From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > Sent: Thursday, December 15, 2022 11:13 PM

...

> > > +     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);

Makes sense.

...

> > > +     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)?

Why is it not mandatory?

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux