On Thu, Nov 05, 2009 at 06:18:05PM +0100, Oliver Hartkopp wrote:
> Kurt Van Dijck wrote:
>
> >>>>> Maybe after all this discussion and after coming back to sysfs the idea
> >>>>> behind
> >>>>> a driver generated unique canhwid has become clearer.
> >>>>>
> >>>>> IMO we could define a common specification, how the canhwid has to be
> >>>>> built by
> >>>>> the driver, e.g.
> >>>> yes, and this does not forbit anyone to create other sysfs entries for
> >>>> special cases :-)
> >>>>> <drvname>#<vendor>#<product>#<serialnumber>#<ioport>#<channel>#
> > From these, only serialnumber & channel are new values. The others (if
> > they would be available) can be found in the device subdirectory.
> (..)
> > I can, however, imagine very usefull things with a 'channel' (which is
> > per-CAN chip) and a serial (which is per-device), although not every
> > device has such properties.
> > A good udev config (we use a udev replacement, written in house just for
> > faster boots) should be able to do anything you like when these
> > (2) are seperate sysfs properties.
>
> No problems with that.
>
> So your suggestion in two sentences would be:
>
> 1. Put the modalias stuff AS-IS in /sys/class/net/can0/device/modalias
right, but this is not the driver's job, it's the bus's job.
> 2. Put the CAN interface differencing stuff in /sys/class/net/can0/canhwid
>
> Right?
>
> This would make udev happy to load & handle the correct driver and
> additionally would allow to identify separate CAN interfaces embedded in this
> 'device' due to the serialnumber/channel/ioport in the driver generated
> canhwid.
ack.
>
> Do you know if this can be handled sufficiently by udev scripts to configure
> e.g. bitrates? I'm not that familiar with udev scripting.
Yep, you can access sysfs properties to match udev rules. Here, it
becomes important to only have 1 value per sysfs file, as Wolfgang
already mentioned.
To be honest, we developed our own (not yet open source) udev
replacement, to speed up boot time. I therefore don't know the exact
syntax anymore.
Still in udev:
Once a rule matched, you can attach any command you like to the uevent.
be carefull with this, udev per default tries to run these commands
serialized with other events, so your command must return within a
reasonable time. I used to apply the 'atd' scheduler for it to schedule
work.
'ip link set .... ${DEV}' is a command as any other in this regard.
For this rule-matching, the 'device' symlink comes extremely handy,
as you're not limited to the netdevice, you can access the parent
'physical' device's properties too, like ioport, irq, manufacturer,
product when the bus exports these.
I'm not how to use udev's driver symlink support.
I did not write udev rules for CAN chips, I mainly did for personal
camera, printer, ..., usb disk, ... to run commands when they appeared.
In the next example, I'll demonstrate an example with my softing card.
1 addition I'll need to make (never had any problem with 1 card), is a
bus-num per CAN chip property.
So, if you'd like to configure a bitrate when the device comes up,
then the udev rule must be something like this. (I'm not sure on $name)
SUBSYSTEM=="net", DRIVERS=="softing_cs", ATTR{bus_num}=="1",
ATTR{device/prod_id1}=="SOFTING GmbH", RUN+="ip link set $name ..."
Mind the device/* attributes, they're not added by my driver, they come
from the pcmcia subsystem.
Therefore, The only 2 properties I see usefull here are a serial number
per device, and a 'bus number within the card' per chip.
Hope this clarifies some things
Kurt
>
> Regards,
> Oliver
>
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
