Hi Marek, Thanks for the feedback.
> Subject: Re: [PATCH] net: ravb: Fix NULL pointer access > > On 9/19/20 8:14 PM, Biju Das wrote: > > Hi, > > [...] > > >>>>> By looking at [1], only this driver is using writeext. > >>>>> [1]https://elixir.bootlin.com/u-boot/v2020.10-rc4/A/ident/writeext > >>>> > >>>> git grep indicates a couple more sites where the writeext is called. > >>>> But look into the KSZ9031 datasheet, that particular writeext call > >>>> seems to be setting up RGMII Clock Pad Skew (MMD Address 2, > >>>> Register 8), and I think there is a matching DT binding to set > >>>> those up too, rxc-skew-ps and txc- skew-ps I think. > >>> > >>> Thanks for the pointers. I checked the configs[2] which uses > >>> renesas ravb driver and found that we are defining only rxc-skew-ps in > all dts. > >>> > >>> since CONFIG DM_ETH is defined it is already picking the value > >> corresponding to "rxc-skew-ps". > >>> > >>> For txc-skew-ps anyway the value is default one. So we don't care. > >> > >> Are you sure (0xf << 5) | 0x19 is the same as the default value of > >> the clock pad skew register ? > > > > No. > > As per [1] & [2], the default values for this registers are 0xf > > So the combined value of the MMD 2-8 register is (0xf << 5) | (0xf << 0) , > right. > > > [1] > > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/net/phy/ > > micrel_ksz90x1.c#L105 [2] > > http://ww1.microchip.com/downloads/en/devicedoc/00002117f.pdf > > > > if we remove writephyext, by looking the code at [1], rxc-skew-ps will be > taken from the device tree[3] and "txc-skew-pc" will be the default > value(0xf). > > [3]https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/dts/ > > salvator-common.dtsi#L331 > > So you want to check whether each RCar3 DT contains a PHY node and that > PHY node has rxc-skew-ps and txc-skew-ps , which combined then results > into a register value (0xf << 5) | (0x19 << 0) . rxc-skew-ps set in DTS is 1500. 1 step is 60 ps, so 1500/60 = 25 which is 0x19 and this value will be overridden and stored in ofcfg->grp's val[0]. > > I will check this and let you know the results after checking on RCar board. > Unfortunately currently I don't have RCar board. > > It's enough to just check the DTs and verify that they set the matching > correct values of rxc-skew-ps/txc-skew-ps . I can test it on the real > hardware. Yes, that way we can make sure the mapping operation is correct for this phy. 1500 in dts after mapping operation should override ofcfg->grp's val[0] with 0x19. > If you want, you can add the txc-skew-ps into the Linux R-Car3 DTs too. We don't need to set txc-skew-ps in dts, since it is same as default value and is filled in ofcfg->grp's val[1]. We can avoid unnecessary mapping operations by not specifying in device tree, for default values. > btw unrelated, you seem to have rxc-skew-ps in your hihope-rzg2-ex.dtsi, > but I think you don't have KSZ9031 PHY, so maybe you want to remove it > form your DT too. OK. Thanks for reporting this. Will fix this in kernel as well as here. Cheers, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
