Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Date:   Thu, 15 Nov 2018 16:00:32 +0100
From:   Stefan Agner <stefan@agner.ch>
To:     Trent Piepho <tpiepho@impinj.com>
Cc:     jingoohan1@gmail.com, l.stach@pengutronix.de,
        gustavo.pimentel@synopsys.com, linux-kernel@vger.kernel.org,
        linux-pci@vger.kernel.org, bhelgaas@google.com
Subject: Re: [PATCH] PCI: dwc: Limit config space size for i.MX6
In-Reply-To: <1542224641.30311.478.camel@impinj.com>
References: <20181019111350.6170-1-stefan@agner.ch>
 <40d0c27d612534033d146497029b1922@agner.ch>
 <1542224641.30311.478.camel@impinj.com>
Message-ID: <b06c24705caddf2f1e97237fd6aa3523@agner.ch>
User-Agent: Roundcube Webmail/1.3.7
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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