Dear Arnd Bergmann, On Tue, 12 Feb 2013 18:00:48 +0000, Arnd Bergmann wrote: > On Tuesday 12 February 2013, Thomas Petazzoni wrote: > > The pcim_*() functions are used by the libata-sff subsystem, and > > this subsystem is used for many SATA drivers on ARM platforms that > > do not necessarily have I/O ports. > > > > Signed-off-by: Thomas Petazzoni > > <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> Cc: Paul Gortmaker > > <paul.gortmaker@xxxxxxxxxxxxx> Cc: Jesse Barnes > > <jbarnes@xxxxxxxxxxxxxxxx> Cc: Yinghai Lu <yinghai@xxxxxxxxxx> > > Cc: linux-kernel@xxxxxxxxxxxxxxx > > Sorry, but this patch is still incorrect. I know, but the discussion was so huge on the first posting that it was basically impossible to draw a conclusion out of it. > Any driver that requires a > linear mapping of I/O ports to __iomem pointers must depend > CONFIG_HAS_IOPORT with the current definition of that symbol (as > mentioned before, we should really rename that to > CONFIG_HAS_IOPORT_MAP). Having these functions not defined is a > compile time check that is necessary to ensure that all drivers have > the correct annotation. I have the feeling that the problem is more complex than that. My understanding is that the pcim_iomap_regions() function used by drivers/ata/libata-sff.c can perfectly be used to map memory BARs, and not necessarily I/O BARs. Therefore, this driver can perfectly be used in an architecture where CONFIG_NO_IOPORT is selected. The thing is that pcim_iomap_regions() transparently allows to remap an I/O BAR is such a BAR is passed as argument, or a memory BAR if such a BAR is passed as argument. Therefore, I continue to believe that the pcim_*() functions are useful even if the platform doesn't have CONFIG_HAS_IOPORT. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
