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 Best regards, Yoshihiro Shimoda
