Hi Lorenzo, > From: Lorenzo Pieralisi, Sent: Monday, November 11, 2019 11:43 PM > > Never ever add stable@xxxxxxxxxxxxxxx in the CC list of the email > header. You should add the tag in the commit log as you did but > never CC stable when sending the patch email. Thank you for the pointed it out. I had added stable@xxxxxxxxxxxxxxx in such cases, but I understood it. I will drop stable@xxxxxxxxxxxxxxx. > On Tue, Nov 05, 2019 at 07:51:29PM +0900, Yoshihiro Shimoda wrote: > > According to the R-Car Gen2/3 manual, "Be sure to write the initial > > value (= H'80FF 0000) to MACCTLR before enabling PCIETCTLR.CFINIT". > > To avoid unexpected behaviors, this patch fixes it. Note that > > the SPCHG bit of MACCTLR register description said "Only writing 1 > > is valid and writing 0 is invalid" but this "invalid" means > > "ignored", not "prohibited". So, any documentation conflict doesn't > > exist about writing the MACCTLR register. > > I am sorry but I don't understand what you mean, if either you or > any rcar maintainer can help me rewrite this log I will merge this > patch then, appreciated. I'm sorry. I think I should not drop a sentence "because the bit 0 is set to 1 on reset" which has the reverted patch from this version. Also, the note seems to be difficult to understand. So, I'll rewrite this log like below. Is it acceptable? --- According to the R-Car Gen2/3 manual, "Be sure to write the initial value (= H'80FF 0000) to MACCTLR before enabling PCIETCTLR.CFINIT" because the bit 0 of MACCTLR is set to 1 on reset. To avoid unexpected behaviors, this patch fixes it. Note that the SPCHG bit (bit 24) of MACCTLR register description said "Only writing 1 is valid and writing 0 is invalid", but this "invalid" means "ignored", not "prohibited". So, even if the driver writes the SPCHG to 0, there is no problem. --- Best regards, Yoshihiro Shimoda
