From mboxrd@z Thu Jan 1 00:00:00 1970 From: scott.branden@broadcom.com (Scott Branden) Date: Mon, 31 Oct 2016 15:05:35 -0700 Subject: [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts In-Reply-To: <18db27c7-1055-ff3c-0b0b-eeeaf5f3f5e0@gmail.com> References: <20161029111229.26875-1-zajec5@gmail.com> <6e252703-0010-83ae-fa14-57352add007a@hauke-m.de> <18db27c7-1055-ff3c-0b0b-eeeaf5f3f5e0@gmail.com> Message-ID: <3847db9f-a8e1-b7fe-c2fa-19ea893bae5f@broadcom.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 16-10-31 02:56 PM, Florian Fainelli wrote: > On 10/31/2016 02:46 PM, Scott Branden wrote: >> >> >> On 16-10-31 02:01 PM, Florian Fainelli wrote: >>> On 10/31/2016 01:59 PM, Hauke Mehrtens wrote: >>>> >>>> >>>> On 10/31/2016 07:08 PM, Scott Branden wrote: >>>>> Hi Rafal, >>>>> >>>>> >>>>> On 16-10-29 04:12 AM, Rafa? Mi?ecki wrote: >>>>>> From: Rafa? Mi?ecki >>>>>> >>>>>> Since early BCM5301X days we got abort handler that was removed by >>>>>> commit 937b12306ea79 ("ARM: BCM5301X: remove workaround imprecise >>>>>> abort >>>>>> fault handler"). It assumed we need to deal only with pending aborts >>>>>> left by the bootloader. Unfortunately this isn't true for BCM5301X. >>>>>> >>>>>> When probing PCI config space (device enumeration) it is expected to >>>>>> have master aborts on the PCI bus. Most bridges don't forward (or they >>>>>> allow disabling it) these errors onto the AXI/AMBA bus but not the >>>>>> Northstar (BCM5301X) one. >>>>> Should we only add this workaround code if CONFIG_PCI is on then? >>>> >>>> I think all the supported northstar devices have a PCIe controller. We >>>> could add such a CONFIG_PCI check, but I do not see a big advantage. >>> >>> Actually, I do see a couple disadvantages if we gate this with >>> CONFIG_PCI: if this problem shows up irrespective of your kernel >>> configuration, you want the error handler to clear it, not rely on >>> CONFIG_PCI to be enabled for the error to go away and also, without an >>> additional ifdef, additional compiler coverage. >>> >> A problem with reintroducing this change is that all imprecise data >> aborts are ignored, not just PCI. So if you don't actually use PCI in >> your system and want to debug other aborts you are unable to. I don't >> know if we care about such situation. > > Considering that any abort is pretty much fatal, the options are: > > - update the freaking bootloader to a version where there are no such > aborts generated, not an option on consumer devices, unclear which > version (if any) fixes that > > - fixups the aborts externally, via a boot wrapper, which is going to > take some time to develop, causes additional burden on the distributors > to provide instructions/build images on how to do it I think the abort is already fixed in the kernel now on boot so option 1 and 2 were not needed - and abort handler was removed as detailed by Rafal in the commit. Only outstanding issue is now this new PCI enumeration issue. > > - fixups the aborts in the kernel, irrespective of where they come from, > simple and easy > > - fixups the aborts in the kernel, look where they come from, by using > some bit of magic, looking at PCIe registers and whatnot (provided that > is even possible), not too hard, but can take a while, and is error prone Option 4 sounds like the proper solution - check the range the abort is due to the PCI device enumeration and only ignore those aborts. > > I can certainly advocate that option 3 is the one that gives a working > device, and this is what matters from a distribution perspective like > LEDE/OpenWrt. > Since I don't use BCM5301x option 3 is fine by me.