public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Neil Greatorex <neil@fatboyfat.co.uk>,
	linux-arm-kernel@lists.infradead.org,
	Matthew Minter <matthew_minter@xyratex.com>,
	linux-kernel@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>
Subject: Re: [PATCH v2] bus: mvebu-mbus: Avoid setting an undefined window size
Date: Wed, 9 Apr 2014 09:53:50 +0200	[thread overview]
Message-ID: <20140409095350.47029549@skate> (raw)
In-Reply-To: <20140409074752.GF16465@1wt.eu>

Dear Willy Tarreau,

On Wed, 9 Apr 2014 09:47:52 +0200, Willy Tarreau wrote:

> > Yes, the panic is expected: Jason's patch is not *fixing* anything,
> > it's just telling you *why* it's going to panic.
> 
> I just thought that the EINVAL would prevent one from registering
> the device, which would be more useful (if at all possible).

Unfortunately, I don't think that's possible: the function that sets up
the MBus window is called by the emulated bridge code, i.e when the
Linux PCI core thinks it is doing a write to a bridge register. And I
don't think there is a way of "refusing" the write to let the Linux
PCI core know that it was not possible to set up the bridge BAR as it
was requested.

Maybe this is something that Jason can confirm/infirm. I remember
having a quick look at the core Linux PCI core to see if it was
somehow checking whether the bridge BAR has been properly configured,
but I think I concluded it was not the case, and it was just assuming
that write the memory base/limit in the bridge registers was
sufficient. 

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2014-04-09  7:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-08 23:44 [PATCH v2] bus: mvebu-mbus: Avoid setting an undefined window size Jason Gunthorpe
2014-04-09  6:11 ` Willy Tarreau
2014-04-09  7:12   ` Thomas Petazzoni
2014-04-09  7:47     ` Willy Tarreau
2014-04-09  7:53       ` Thomas Petazzoni [this message]
2014-04-09  7:56         ` Willy Tarreau
2014-04-09 16:30         ` Jason Gunthorpe
2014-04-09 16:20   ` Jason Gunthorpe
2014-04-10  6:35     ` Willy Tarreau
2014-04-10  6:53     ` Thomas Petazzoni
2014-04-10 11:59       ` Jason Cooper

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=20140409095350.47029549@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew_minter@xyratex.com \
    --cc=neil@fatboyfat.co.uk \
    --cc=w@1wt.eu \
    /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