All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Sealey <matt@genesi-usa.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org, "René Bürgel" <r.buergel@unicontrol.de>
Subject: Re: [PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
Date: Mon, 03 Nov 2008 15:57:09 -0600	[thread overview]
Message-ID: <490F73B5.6010004@genesi-usa.com> (raw)
In-Reply-To: <fa686aa40811031255w3d9a065dgb0eb7ad4b26c9651@mail.gmail.com>



Grant Likely wrote:
> On Mon, Nov 3, 2008 at 12:32 PM, René Bürgel <r.buergel@unicontrol.de> wrote:
>> Hi
>>
>> This patch is a workaround for bug #364 found in the MPC52xx processor.
>> The errata document can be found under
>> http://www.freescale.com/files/32bit/doc/errata/MPC5200E.pdf?fpsp=1&WT_TYPE=Errata&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
>>
> 
> This is an MPC5200 errata.  It doesn't exist on the MPC5200B.  The
> bugfix code should be enabled at runtime only if running on the
> original MPC5200.  You can use the value of the compatible property to
> determine whether or not to enable it.

I would hope not since the Efika uses mpc5200-psc and mpc5200-serial
as it's compatible properties (this is from before mpc5200-psc-uart
was defined), which would enable this bugfix across the board.

Until we have a decent update for the device tree here (it's starting
to cause some real trouble lately when people update stuff like this
and want to compare) the best way to check for the MPC5200 or MPC5200B
is to look at the PVR - you don't need the device tree for this, at
all.

Sometime this week I am going to go through the 5200b device tree in
the kernel source and make sure efika.forth follows it as best as I
can, and then make a release.. that won't fix anything for people who
don't run the script, however.

 > Optionally you can further
> reduce impact by checking if CONFIG_PPC_MPC5200_BUGFIX is defined.

I would much prefer this.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

  reply	other threads:[~2008-11-03 21:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-03 19:32 [PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state) René Bürgel
2008-11-03 20:55 ` Grant Likely
2008-11-03 21:57   ` Matt Sealey [this message]
2008-11-03 22:15     ` Wolfram Sang
2008-11-03 22:55       ` Grant Likely
2008-11-04 18:18       ` Matt Sealey
2008-11-04 10:43   ` [PATCH V2] " René Bürgel
2008-11-04 11:15     ` Wolfram Sang
2008-11-04 14:13       ` René Bürgel
2008-11-04 19:40       ` [PATCH V3] " René Bürgel
2008-11-04 21:21         ` Wolfram Sang
2008-11-06  8:11           ` [PATCH V4] " René Bürgel
2008-11-06  8:11             ` René Bürgel
2008-11-14 19:09             ` Grant Likely
2008-11-14 19:09               ` Grant Likely
2008-11-04 18:23     ` [PATCH V2] " Matt Sealey
2008-11-06 17:01       ` René Bürgel
2008-11-06 22:41         ` Matt Sealey

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=490F73B5.6010004@genesi-usa.com \
    --to=matt@genesi-usa.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=r.buergel@unicontrol.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.