All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: benh@kernel.crashing.org
Cc: Ayman El-Khashab <AymanE@tanisys.com>,
	Victor Gallardo <vgallardo@amcc.com>,
	linuxppc-dev@ozlabs.org
Subject: Re: Problems with PCI-E devices not being detected with switch
Date: Thu, 16 Oct 2008 10:48:45 +0200	[thread overview]
Message-ID: <200810161048.45937.sr@denx.de> (raw)
In-Reply-To: <1224145785.7654.4.camel@pasglop>

On Thursday 16 October 2008, Benjamin Herrenschmidt wrote:
> On Thu, 2008-10-16 at 10:03 +0200, Stefan Roese wrote:
> > Doing this unconditionally is not a good idea since we could have an old
> > (buggy) firmware which didn't configure the PCIe controller correctly.
> > But I really like your idea with the device-tree property to optionally
> > skip this re-configuration. Now we only need to find some "volunteer" to
> > do this job... ;)
>
> I don't have a problem adding support for testing that property and
> skipping most of the initial HW setup, basically treating the endpoint
> as pre-configured.
>
> What about using a value for "status" ?

No. "status" is already used to disable/skip the PCIe slot completely. For 
example on Canyonlands where PCIe#0 is multiplexed with the SATA port.

> Or an empty "configured" 
> property ? Ideally, it should have been the other way around, ie
> "unconfigured" for old/buggy stuff but I'm worried there may be existing
> out-of-tree device-trees without it :-)

Yeah. I could add this "configured" property to the current U-Boot version. 
Perhaps we should add some version information to it so that Linux could 
eventually decide to re-configure when the "configured" version is known to 
be buggy. What do you think?

Best regards,
Stefan

  reply	other threads:[~2008-10-16  8:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-15 15:47 Problems with PCI-E devices not being detected with switch Ayman El-Khashab
2008-10-16  5:20 ` Benjamin Herrenschmidt
2008-10-16  8:03   ` Stefan Roese
2008-10-16  8:29     ` Benjamin Herrenschmidt
2008-10-16  8:48       ` Stefan Roese [this message]
2008-10-16  8:58         ` Benjamin Herrenschmidt
2008-10-16 15:01   ` Ayman El-Khashab
2008-10-16 21:19     ` Benjamin Herrenschmidt
2008-10-17  0:10     ` Benjamin Herrenschmidt
2008-10-17  7:22       ` Stefan Roese
2008-10-17 14:54       ` Ayman El-Khashab
2008-10-17 21:05         ` Benjamin Herrenschmidt
2008-10-17 21:19         ` Benjamin Herrenschmidt
2008-10-20 21:03           ` Ayman El-Khashab
2008-10-20 21:57             ` Benjamin Herrenschmidt
2008-10-20 22:14               ` Ayman El-Khashab
2008-10-20 22:55                 ` Benjamin Herrenschmidt

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=200810161048.45937.sr@denx.de \
    --to=sr@denx.de \
    --cc=AymanE@tanisys.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=vgallardo@amcc.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.