On Monday 08 February 2016 16:51:19 Gabriele Paoloni wrote:

quoted

From: Arnd Bergmann [mailto:arnd at arndb.de]
On Monday 08 February 2016 16:06:54 Gabriele Paoloni wrote:

quoted

quoted

On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:

int

quoted

quoted

size,

quoted

+                         u32 *val)
+{
+   u32 reg;
+   u32 reg_val;
+   void *walker = &reg_val;
+
+   walker += (where & 0x3);
+   reg = where & ~0x3;
+   reg_val = readl(reg_base + reg);
+
+   if (size == 1)
+           *val = *(u8 __force *) walker;
+   else if (size == 2)
+           *val = *(u16 __force *) walker;
+   else if (size == 4)
+           *val = reg_val;
+   else
+           return PCIBIOS_BAD_REGISTER_NUMBER;
+
+   return PCIBIOS_SUCCESSFUL;
+}

Isn't this the same hack that Qualcomm are using?

As far as I can see Qualcomm defines its own config access
mechanism only for RC config read and also it seems they're
having problems with reporting the device class...

https://github.com/torvalds/linux/blob/master/drivers/pci/host/pcie-

qcom.c#L474

quoted

Our problem is that our HW can only perform 32b rd/wr accesses
So we can't use readw/readb/writew/writeb...

Sorry, my mistake, I meant Cavium not Qualcomm.
See https://lkml.org/lkml/2016/2/5/689 for the patches.

Well, looking at it Cavium seems quite different, 

On read they need to trigger the retrieval of the
config space info writing to the lower 32b of a 64b register,
then they need to read data back on the upper 64b of the
same register and adjust the content to remove the garbage...

We just use 32b accesses and adjust grab the appropriate
bytes depending on the read/write sizes...

Hmm, I must have misremembered that too then, let me try once more ;-)

The above appears to reimplement pci_generic_config_read32(). Can you
just use that instead?

	Arnd