Re: SPI CAN device enumeration / network device naming

Re: SPI CAN device enumeration / network device naming

[Patrick Menschel]

Hi,

I'm adding the devicetree mailing list to CC as they are the experts.

Normally you should get your numbering to work with aliases but I'm not
sure if it is used the same way in overlays.

aliases {
         can0 = &can0;
         can1 = &can1;
         can2 = &can2;
         can3 = &can3;
         };


Btw nice that my kicad contributions come to work by itself.
https://github.com/KiCad/kicad-symbols/pull/201
I was routing my own board but unpredictably holidays were over ;-)

Regards,
Patrick


> 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@xor.wtf> 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

Re: SPI CAN device enumeration / network device naming

[Rob Herring]

On Wed, Sep 12, 2018 at 11:11 AM Patrick Menschel <menschel.p@posteo.de> wrote:
>
> Hi,
>
> I'm adding the devicetree mailing list to CC as they are the experts.
>
> Normally you should get your numbering to work with aliases but I'm not
> sure if it is used the same way in overlays.
>
> aliases {
>          can0 = &can0;
>          can1 = &can1;
>          can2 = &can2;
>          can3 = &can3;
>          };

Yes, some platforms do this for built-in CAN controllers. I'm not sure
if this can really work for overlays though. You might get away with
it because the base dt doesn't have any can aliases, but what if it
did? Or what happens when you plugin a USB to CAN device (assuming
such a thing exists)?

I'd suggest using "label" properties if there's a human identifiable
connector/port and then support something like /dev/can/by-label/<some
label name>. udev would create symlinks for each /sys/class/can/
device. That's how other classes of devices work. I guess if it is
like ethernet though, that's a bit different, but still solved without
fixed numbering.

> Btw nice that my kicad contributions come to work by itself.
> https://github.com/KiCad/kicad-symbols/pull/201
> I was routing my own board but unpredictably holidays were over ;-)
>
> Regards,
> Patrick
>
>
> > 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"

The main problem with this is it is very much platform specific.

This problem is solved for other devices and not by fixed indexes. No
one expects eth0, eth1, etc. anymore.

Rob