On 28 July 2020 09:31:52 GMT+02:00, "Stéphane Grosjean" <s.grosjean@xxxxxxxxxxxxxxx> wrote: >Thx for your answer Kurt! Even if properties are channel related, this >could be a solution... > >But... creating a (new) channel tree under /devices looks weird, >doesn't it? /sys/class/net/.... are symlinks to /sys/devices/..., not weird IMO >And why it should be "easier" to add attributes there rather than under >each /sys/class/net/can? Equally easy to add, much simpler to use in udev without race conditions. > >-- Stéphane > > >De : Kurt Van Dijck <dev.kurt@xxxxxxxxxxxxxxxxxxxxxx> >Envoyé : vendredi 24 juillet 2020 11:45 >À : Stéphane Grosjean <s.grosjean@xxxxxxxxxxxxxxx> >Cc : Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx>; linux-can@xxxxxxxxxxxxxxx ><linux-can@xxxxxxxxxxxxxxx> >Objet : Re: About sysfs usage by socket-can drivers > >> We've several pending requests regarding: >> - changing the default clock value, >> - reading the bus load value, >> - using a flashed device id. to better control the can interface >number, >> - identifying the (USB) channel >> - ... > >I tend to look in the (in your case) usb device, and add properties >there. >After all, those are device-related properties, not? > >You could reach them via /sys/class/net/canX/device/... > >If you add them before the netdev is registered, you can use them in >udev rules without race conditions. > >Kurt > >-- >PEAK-System Technik GmbH >Sitz der Gesellschaft Darmstadt - HRB 9183 >Geschaeftsfuehrung: Alexander Gach / Uwe Wilhelm >Unsere Datenschutzerklaerung mit wichtigen Hinweisen >zur Behandlung personenbezogener Daten finden Sie unter >www.peak-system.com/Datenschutz.483.0.html Sent from a small mobile device
