From: zajec5@gmail.com (Rafał Miłecki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts
Date: Mon, 31 Oct 2016 23:16:20 +0100 [thread overview]
Message-ID: <CACna6ryMbF8kVUYOfhre4qtZp5haa2Shijcv40AXsjL_jZL=JQ@mail.gmail.com> (raw)
In-Reply-To: <3847db9f-a8e1-b7fe-c2fa-19ea893bae5f@broadcom.com>
On 31 October 2016 at 23:05, Scott Branden <scott.branden@broadcom.com> wrote:
> On 16-10-31 02:56 PM, Florian Fainelli wrote:
>> - 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.
This was already suggested by Arnd:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-April/422873.html
and Ray was checking some internal datasheets, but I'm afraid he never
found info on checking if error was caused by PCIe controller.
Maybe we could think about some BCM5301X API (extra symbol exported by
arch code) for starting ignoring aborts and stopping that. We could
ignore aborts during scanning only but honestly it sounds like a bit
hacky solution to me.
>> 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.
So for it seems like the best solution to me, but I'm open for changes
if someone points another that is clean & better one.
--
Rafa?
next prev parent reply other threads:[~2016-10-31 22:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-29 11:12 [PATCH] ARM: BCM5301X: Add back handler ignoring external imprecise aborts Rafał Miłecki
2016-10-31 18:08 ` Scott Branden
2016-10-31 20:59 ` Hauke Mehrtens
2016-10-31 21:01 ` Florian Fainelli
2016-10-31 21:46 ` Scott Branden
2016-10-31 21:56 ` Florian Fainelli
2016-10-31 22:04 ` Rafał Miłecki
2016-10-31 22:05 ` Scott Branden
2016-10-31 22:16 ` Rafał Miłecki [this message]
2016-10-31 22:28 ` Ray Jui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACna6ryMbF8kVUYOfhre4qtZp5haa2Shijcv40AXsjL_jZL=JQ@mail.gmail.com' \
--to=zajec5@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).