From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
Date: Tue, 7 Apr 2015 16:13:54 +0200 [thread overview]
Message-ID: <201504071613.55018.marex@denx.de> (raw)
In-Reply-To: <BL2PR03MB1611C076E1E46FAEFD62885E0FD0@BL2PR03MB161.namprd03.prod.outlook.com>
On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote:
> > -----Original Message-----
> > From: Marek Vasut [mailto:marex at denx.de]
> > Sent: Tuesday, April 07, 2015 7:22 PM
> > To: Mehresh Ramneek-B31383
> > Cc: u-boot; sr at denx.de
> > Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
> >
> > On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote:
> >
> > [...]
> >
> > > > Hi,
> > > >
> > > > Is this similar hardware bug to the one which MX6 PCIe is suffering
> > > > ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY
> > > > from software, which means that if you start PCIe in U-Boot, you
> > > > cannot reliably use it in Linux. Furthermore, if you reset the MX6
> > > > via WDT, you cannot start PCIe reliably in Linux even if PCIe is not
> > > > used in U-Boot at all.
> > > >
> > > > Is this the same type of hardware screwup where the design team
> > > > didn't think reset was necessary?
> > >
> > > I have raised request for this feature in up-coming socs, and they
> > > have agreed to provide phy shut-down in future revs. However, this
> > > support is not available in current revs for which the code is sent.
> > > What do you suggest we should do for current socs?
> >
> > Hi,
> >
> > I don't know, but doesn't leaving the USB running cause trouble to Linux?
> > I think you should at least document the reasoning why the USB stop is
> > not implemented for this broken hardware.
>
> Hi Marek, it's not USB controller stop, it's Phy stop which is not
> supported. Controller stopping is supported.
OK, does it pose a problem for Linux ? If not, then please just document
it and let's stick with what there now.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2015-04-07 14:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BL2PR03MB161DE5448D4F4B4C8635AB6E06A0@BL2PR03MB161.namprd03.prod.outlook.com>
2014-12-18 11:16 ` [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/ Marek Vasut
2015-01-12 5:26 ` Ramneek Mehresh
2015-01-12 14:29 ` Marek Vasut
2015-04-06 8:58 ` Ramneek Mehresh
2015-04-06 15:11 ` Marek Vasut
2015-04-07 6:18 ` Ramneek Mehresh
2015-04-07 13:51 ` Marek Vasut
2015-04-07 14:05 ` Ramneek Mehresh
2015-04-07 14:13 ` Marek Vasut [this message]
2015-04-07 14:42 ` Ramneek Mehresh
2015-04-07 18:55 ` Marek Vasut
2015-04-07 14:52 ` Ramneek Mehresh
2015-04-07 18:55 ` Marek Vasut
2015-04-07 6:39 ` Paul Kocialkowski
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=201504071613.55018.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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.