RE: [PATCH] Revert "MIPS: BCM47XX: Enable 74K Core ExternalSync for PCIe erratum"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I am very sorry for the problem caused by my patch.
And very sorry for too late to reply to the mail since I have just noticed this revert today...
(The mail was automatically saved into a folder to filter mails unintentionally...)
Also Thank you so much for your fix by reverting the patch.

> Tokunori - if this breaks your system then we'll need to look at
> applying the workaround more selectively.

  Thank you so much.
  Noted it.
  At this moment it is not broken on our system but if needed I will do it.

Regards,
Ikegami

> -----Original Message-----
> From: Paul Burton [mailto:paul.burton@xxxxxxxx]
> Sent: Saturday, July 28, 2018 2:13 AM
> To: Rafał Miłecki; IKEGAMI Tokunori
> Cc: James Hogan; Ralf Baechle; Michael Marley; PACKHAM Chris; Hauke
> Mehrtens; linux-mips@xxxxxxxxxxxxxx; Rafał Miłecki
> Subject: Re: [PATCH] Revert "MIPS: BCM47XX: Enable 74K Core ExternalSync
> for PCIe erratum"
> 
> Hi Rafał,
> 
> On Fri, Jul 27, 2018 at 01:13:39PM +0200, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal@xxxxxxxxxx>
> >
> > This reverts commit 2a027b47dba6b77ab8c8e47b589ae9bbc5ac6175.
> >
> > Enabling ExternalSync caused a regression for BCM4718A1 (used e.g. in
> > Netgear E3000 and ASUS RT-N16): it simply hangs during PCIe
> > initialization. It's likely that BCM4717A1 is also affected.
> >
> > I didn't notice that earlier as the only BCM47XX devices with PCIe I
> > own are:
> > 1) BCM4706 with 2 x 14e4:4331
> > 2) BCM4706 with 14e4:4360 and 14e4:4331
> > it appears that BCM4706 is unaffected.
> >
> > While BCM5300X-ES300-RDS.pdf seems to document that erratum and its
> > workarounds (according to quotes provided by Tokunori) it seems not even
> > Broadcom follows them.
> >
> > According to the provided info Broadcom should define CONF7_ES in their
> > SDK's mipsinc.h and implement workaround in the si_mips_init(). Checking
> > both didn't reveal such code. It *could* mean Broadcom also had some
> > problems with the given workaround.
> >
> > Reported-by: Michael Marley <michael@xxxxxxxxxxxxxxxxx>
> > Cc: Tokunori Ikegami <ikegami@xxxxxxxxxxxxxxxxxxxx>
> > Cc: Paul Burton <paul.burton@xxxxxxxx>
> > Cc: Hauke Mehrtens <hauke@xxxxxxxxxx>
> > Cc: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx
> > Cc: James Hogan <jhogan@xxxxxxxxxx>
> > Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx>
> > ---
> > This has been reported by Michael as OpenWrt bug at:
> > https://bugs.openwrt.org/index.php?do=details&task_id=1688
> > ---
> >  arch/mips/bcm47xx/setup.c        | 6 ------
> >  arch/mips/include/asm/mipsregs.h | 3 ---
> >  2 files changed, 9 deletions(-)
> 
> Thanks - I've applied this to mips-fixes, and will send to Linus before
> v4.18 final so this regression shouldn't appear in a stable kernel.
> 
> Tokunori - if this breaks your system then we'll need to look at
> applying the workaround more selectively.
> 
> Paul

[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux