On 14.11.2018 20:44, Trent Piepho wrote: > On Wed, 2018-11-14 at 16:49 +0100, Stefan Agner wrote: >> On 19.10.2018 13:13, Stefan Agner wrote: >> > Reading the full 4k config space through sysfs leads to an >> > external abort. Testing on a platform showed that the upper >> > limit is 512. Limit config space to 512. >> >> Any comment on this patch? >> >> Since other devices use similar quirks, I guess the fix can't be far >> off? >> >> Maybe restricting to the PCI device ID used in i.MX 6 only is too >> restrictive, but I guess better restrictive for now? > > To trigger this bug I should read the sysfs "config" file for the PCI > bridge device? > > Tested on imx7, no problems. > > # hexdump -C > /sys/devices/platform/soc/30800000.aips-bus/33800000.pcie/pci0000:00/0000:00:00.0/config > > > [stuff] > 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > > 00000400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > |................| > * > > 00000700 76 00 63 01 ff ff ff ff 04 00 00 07 00 f0 f0 1b > |v.c.............| > [more stuff] > > The bridge on imx7d is 16c3:abcd, same as patch I believe. I do have a > pci-e device connected, unlike the original bug. Maybe that is > related? Or maybe this problem is fixed in imx7d? The i.MX 7D seems to have a different register set... I don't think it is related to whether a PCIe device is connected or not. The fact that i.MX 7D has the same device id and does not suffer the problem actually shows that the approach this patch takes is not ideal... Will send a patch limiting register access on a per driver/compatible string level. -- Stefan > >> > >> > #define PCI_VENDOR_ID_SYNOPSYS 0x16c3 >> > +#define PCI_DEVICE_ID_SYNOPSYS_IMX6 0xabcd >> > >> > #define PCI_VENDOR_ID_VITESSE 0x1725 >> > #define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174
