Re: [PATCH 2/2] PCI: rcar: Fix missing MACCTLR register setting in initialize sequence

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

 



Hello Shimoda-san,

On Fri, Nov 01, 2019 at 06:39:03AM +0000, Yoshihiro Shimoda wrote:
> Hello again,
> 
> > From: Yoshihiro Shimoda, Sent: Friday, November 1, 2019 2:08 PM
> <snip>
> > Hello Eugeniu-san,
> > 
> > > From: Eugeniu Rosca, Sent: Thursday, October 31, 2019 1:35 AM
> > <snip>
> > > > diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> > > > index 40d8c54..d470ab8 100644
> > > > --- a/drivers/pci/controller/pcie-rcar.c
> > > > +++ b/drivers/pci/controller/pcie-rcar.c
> > > > @@ -91,6 +91,7 @@
> > > >  #define  LINK_SPEED_2_5GTS	(1 << 16)
> > > >  #define  LINK_SPEED_5_0GTS	(2 << 16)
> > > >  #define MACCTLR			0x011058
> > > > +#define  MACCTLR_INIT_VAL	0x80ff0000
> > >
> > > Actually, I do believe there is an inconsistency in the manual,
> > > since the following statements pretty much contradict one another:
> > >
> > > 1. (as quoted by Shimoda-san from "Initial Setting of PCI Express")
> > >    > Be sure to write the initial value (= H'80FF 0000) to MACCTLR
> > >    > before enabling PCIETCTLR.CFINIT.
> > > 2. Description of SPCHG bit in "54.2.98 MAC Control Register (MACCTLR)"
> > >    > Only writing 1 is valid and writing 0 is invalid.
> > >
> > > The last "invalid" sounds like "bad things can happen" aka "expect
> > > undefined behaviors" when SPCHG is written "0".
> > 
> > I asked the hardware team about the "invalid" in the SPCHG bit and then
> > this "invalid" means "ignored", not "prohibited". So, even if we write
> > the SPCHG to 0, no bad things/undefined behaviors happen.
> > 
> > > While leaving the decision on the patch inclusion to the maintainers, I
> > > hope, in the long run, Renesas can resolve the documentation conflict
> > > with the HW team and the tech writers.
> > 
> > So, I don't think the documentation conflict exists about the MACCTLR register.
> > But, what do you think?
> 
> JFYI, I have submitted v2 patch series which was described about the SPCHG:
> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=196557

Thanks for clarifying the exact meaning of the "invalid" wording in the
description of the SPCHG bit so promptly and for stressing that in v2.
Greatly appreciated from our side.

-- 
Best Regards,
Eugeniu



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux