>Понедельник, 28 января 2019, 13:43 +03:00 от Andreas Henriksson <andreas@xxxxxxxx>: ... >[...] >>> According to my personal testing I can make the probing reliable just by >>> raising MCP251X_OST_DELAY_MS [1] to 30ms which seems to be the sweet >>> spot for me. (25ms isn't enough, while 40ms as suggested in last comment >>> in the raspberrypi issue doesn't seem to be needed either.) >[...] >> Re-examining the code, I do not see obvious errors. However, the problem >> is probably the implementation of the mdelay() for the ARM platform. > >(Can you please clue me in on the arm specific mdelay? I can't find any >arm-specific bits overriding the default mdelay define[1], and >with MCP251X_OST_DELAY_MS set to 5 that should be directly equivalent >to 'udelay(5000);' as MAX_UDELAY_MS is also 5. Right?) That's right. In our case, you need to look at the udelay() definition for the ARM. See arch/arm/include/asm/delay.h >> Can you do the test by replacing the lines mdelay(MCP251X_OST_DELAY_MS) >> by udelay(2000)? Yes, exactly 2000. > >I've tested this now but no improvement. The interfaces comes up >on every other "rmmod mcp251x; sleep 1 ; modprobe mcp251x" just like >with plain 4.20.0. Attaching patch of my changes just to verify The changes looks good. >(I noticed in >https://www.kernel.org/doc/Documentation/timers/timers-howto.txt >that mdelay is discuraged in favour of msleep, but I'm not sure I >really understood what the correct approach is after reading that doc.) Ok, lets try to use usleep_range(500, 2000). Can you test this? ---
