Thank you Chris! Unfortunately, using multiple DT overlays is not a good solution for me; I want the raspi bootloader to load the overlay from the hat's EEPROM, and afaik, there can be only one overlay per EEPROM. For now, I'm using a udev rules file: --- ACTION=="add", SUBSYSTEM=="net", DEVPATH=="/devices/platform/soc/*/spi0.0/net/can?", NAME="can0" ACTION=="add", SUBSYSTEM=="net", DEVPATH=="/devices/platform/soc/*/spi0.1/net/can?", NAME="can1" ACTION=="add", SUBSYSTEM=="net", DEVPATH=="/devices/platform/soc/*/spi1.0/net/can?", NAME="can2" ACTION=="add", SUBSYSTEM=="net", DEVPATH=="/devices/platform/soc/*/spi1.1/net/can?", NAME="can3" --- But that still requires installing that file in the linux image; If possible, I'd still prefer some way to achieve this in the device tree overlay. Greetings, Hubert Am 12.09.2018 um 00:23 schrieb Chris Sauer: > This is because these fragment names dont actually matter neither does > the order or the number you could change fragment@1 to fragment@4 and > you would get the same randomness. > You will need to split 4xMCP2517FD.dts into MCP2517FD-can0.dts > MCP2517FD-can1.dts MCP2517FD-can2.dts and MCP2517FD-can3.dts and > define your /boot/config.txt in the order you need it. > > dtoverlay=mcp2515-can0-overlay,oscillator=16000000,interrupt=Xx > dtoverlay=mcp2515-can1-overlay,oscillator=16000000,interrupt=Xx > dtoverlay=mcp2515-can2-overlay,oscillator=16000000,interrupt=Xx > dtoverlay=mcp2515-can3-overlay,oscillator=16000000,interrupt=Xx > > We ran though a similar issue on our dual can board. I am by no means > a device tree expert but /boot/config.txt does get processed in order > where as those DTS files get parsed by for_each_child_of_node() Which > does not guarantee init order. I believe there are some tricks you can > do but they aren't very clean or involve editing drivers/of/overlay.c > and thats a total pain. Sorry If someone gets this two or three times > I forgot to turn on plaintext only mode. > > On Tue, Sep 11, 2018 at 3:30 PM Hubert Denkmair <xor@xxxxxxx> wrote: >> >> Hi all, >> >> I'm currently building a open hardware Raspberry Pi HAT >> with four MCP2517FD SPI CAN controllers: >> https://github.com/Bytewerk/QuadCAN-FD/tree/v1 >> >> This seems to work with the device tree overlay from said >> repository and Martin Sperls latest MCP25xxFD patches \o/ >> >> Now, I have one problem and I'm not sure how to address this. >> I'm using a Raspberry Pi 3 Model B+ with current raspbian. >> >> Maybe 90% of all boots, I get the following in dmesg: >> --- >> [ 3.877118] mcp25xxfd: loading out-of-tree module taints kernel. >> [ 3.890743] mcp25xxfd spi0.0 can0: MCP2517 successfully initialized. >> [ 3.901189] mcp25xxfd spi0.1 can1: MCP2517 successfully initialized. >> [ 3.910035] mcp25xxfd spi1.1 can2: MCP2517 successfully initialized. >> [ 3.920515] mcp25xxfd spi1.0 can3: MCP2517 successfully initialized. >> --- >> >> But sometimes, the SPIs seem to get enumerated in different order: >> --- >> [ 3.720432] mcp25xxfd: loading out-of-tree module taints kernel. >> [ 3.733176] mcp25xxfd spi1.1 can0: MCP2517 successfully initialized. >> [ 3.741914] mcp25xxfd spi1.0 can1: MCP2517 successfully initialized. >> [ 3.750370] mcp25xxfd spi0.0 can2: MCP2517 successfully initialized. >> [ 3.758741] mcp25xxfd spi0.1 can3: MCP2517 successfully initialized. >> --- >> >> Also, I sometimes see the kernel taint message twice or even more. >> I expect this to be a concurrency problem with one CPI core enumerating >> one SPI bus, and another core enumerating the other? >> >> What's the best(tm) way to ensure consistent device naming in such a setup? >> Is there anything that could be done in device tree >> (so that I wouldn't have to touch the linux image itself)? >> >> Thanks, >> >> Hubert
