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 <rafal@xxxxxxxxxx>
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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
