Re: RFC: extending struct pci_ops to include HW specific read and write functions

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

 



Hi Greg,

Thanks for your feedback. Please see my comments below:

> Ick.  I'm pretty sure this came up a few years ago and was shot down
> then.  Have you checked the archives?
> 

I just searched the 'linux-pci' archives for "struct pci_ops" on both
'gmane.org' and 'spinics.net' but I couldn't find any proposal to extend
"struct pci_ops". Should I also look elsewhere (i.e. linux-kernel
archives)?

> > +
> > + return (ops->hw_readl)?(ops->hw_readl(__hw_mem_pci(hw->regs + reg))):
> > + (readl(hw->regs + reg));
> 
> Doesn't this imply that you should just be changing your arch's readl()
> function to handle this type of thing properly?  Do you really want to
> add this type of logic to _EVERY_ device driver out there (hint, no.)

The thing is 'readl()' applies to all devices as 'pci_ops->hw_readl()'
is PCIe controller specific. So, I can't simply change 'readl()' without
impacting other drivers or even portions of the same driver PCIe device
that may need to access other non PCIe HW specific registers.

Using the 'pci_ops->hw_readl()' would _only_ be required for device
drivers that interact with PCIe controllers that cannot map PCI memory
to CPU memory space. That's the PXA168's case where the standard
'readl()' can not access the endpoint. All reads and writes need go
through specialized functions that abstract the 4 step process to access
to the PIO channels. I see no need update all existing drivers to
support HW specific reads and writes. This could happen over time as the
need arises.


> I think you can do this today with the arch-specific hooks provided to
> you, have you looked into that?
> 

The arch specific hooks are generic to the arch. The problem here is
that we have specific way for accessing a PCIe controller. It is
entirely conceivable that we could see other design implementations that
follow the same paradigm in other architectures in the near future.
Adding these extensions to "struct pci_ops" would make them generic
across all architectures.

Also, "struct pci_ops" seems like a natural home for these HW specific
functions along with the other two read() and write() functions used for
PCI HW specific configuration. I did search for other options but this
was the one that had the _least_ impact.

Thoughts?

Jason


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux