>Пятница, 25 января 2019, 15:01 +03:00 от Andreas Henriksson <andreas@xxxxxxxx>: > >Hello, > >I have a board with a RPi CM3 and 4 mcp2515. The mcp2515 are on >"constant power" (vdd/reset not controlled by RPi/linux). >On a "cold-start" (power on) things come up as expected, but if I do a >soft reboot (sudo reboot) or do >rmmod mcp251x && modprobe mcp251x the drivers probe fails with ENODEV >every other time. >(I've also tested hooking up a GPIO to reset, describing vdd/xciever >regulator in devicetree so driver resets the mcp2515, but that did not >help at all.) > >Other people seem to have similar issues and multiple different >workarounds/hacks are discussed in >https://github.com/raspberrypi/linux/issues/2767 > >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.) > >This all seems related to this old commit[2] so I'm hoping the involved >people can please comment on this issue. Is raising the delay this much >acceptable? Is it just working around the symptom of another problem? > >commit ff06d611a31c4b687c7859e3c7516a38194d4d25 >"can: mcp251x: Improve mcp251x_hw_reset()" 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 do the test by replacing the lines mdelay(MCP251X_OST_DELAY_MS) by udelay(2000)? Yes, exactly 2000. ---
