* Re: broken FSL erratum handling for 8250 on MPC8xxx
2022-05-11 9:06 broken FSL erratum handling for 8250 on MPC8xxx Uwe Kleine-König
@ 2022-05-11 22:21 ` Paul Gortmaker
0 siblings, 0 replies; 2+ messages in thread
From: Paul Gortmaker @ 2022-05-11 22:21 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Alan Cox, NXP Linux Team, linux-serial, kernel
[broken FSL erratum handling for 8250 on MPC8xxx] On 11/05/2022 (Wed 11:06) Uwe Kleine-König wrote:
> Hello Paul, hello Alan, hello NXP,
>
> I have an MPC8313 here and the problem that a change introduced in 2011
> (i.e. 9deaa53ac7fa ("serial: add irq handler for Freescale 16550
> errata.")) results in a bug. (Will send a fix for that in a separate
> thread.)
Wow - that is going way back in time. I've since removed all the boards
from mainline that I had at the time -- git show v5.15-rc1~100^2~27
> The thing that bothers me is: The machine in question doesn't seem to
> have the behaviour described in the chip erratum document[1]. I'm using
> a MPC8313CVRAGDC, and even when I send a 10s long break, I only get a
> single interrupt and LSR doesn't get the BI bit set after the first
> event.
So, just to be clear - you've essentially "reverted" the 9deaa53ac7fa
workaround and are using the default 16550 code and things just work?
I've linked below a description of the original reproducer from 2008(!)
Without the workaround, you simply couldn't even use SysRQ over serial.
> (The erratum applies to MPC8313E, the MPC8313 doesn't have a dedicated
> errata document and reference manual. The latter states that it applies
> to MPC8313, too, the errata document doesn't. As the difference betweeen
> MPC8313 and MPC8313E is only an encryption engine I would expect that
> the UART of the MPC8313 shows the same behaviour as the MPC8313E?!)
From what I recall - your conclusion would be correct, but I think I
only had "E" series chips here in Canada? There might be enough crumbs
in e-mail to confirm, but really I agree - it shouldn't matter.
> Do you have some information which CPUs are actually affected, or is
> there a problem with my diagnosis that MPC8313CVRAGDC isn't affected?
If I recall correctly, the folks at (then) Freescale were the ones that
guided me on setting the scope of where the erratum should be applied.
If lore.kernel.org or other archives don't have the discussion, then I
might be able to find it in local backups, perhaps?
> @Paul: Do you still remember which machine you saw the problem on and
> which version of the erratum you had at the time?
So while I did have access to the Freescale reference platforms, I did
typically do most of my work on the WindRiver variants listed in the
commit 627e66f29aa2 mentioned above - sbc8349, sbc8548 and sbc8641d.
But fortunately lore has a better memory than me, and it says I tested
on 5 different boards - so I must have tested the above three plus a
couple Fsl reference platforms as well - going back to 2008:
https://lore.kernel.org/all/7d1d9c250807311843j58246eeco4411ad9e5deda78a@mail.gmail.com/
I don't think I ever had an 8313. The Yocto project chose mpc8315e-rdb
as one of their reference BSPs, so I had one of those available to me
back in the day but I don't recall explicitly testing SysRQ on it.
As for the errata "version" - there was none originally. As far as I
know, I discovered it, or at least was the first to publicly describe it
and propose a workaround. Then open discussions that lore should have
copies of -- shaped it into what finally went mainline years later.
Hope that helps. I won't go digging into decades old backups for now,
since IIRC the whole discussion was public, but if you can't find
something - let me know and I'll do what I can to help.
Paul.
--
>
> Best regards
> Uwe
>
> [1] General17 in https://www.nxp.com/docs/en/errata/MPC8313ECE.pdf
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 2+ messages in thread