Sebastian Haas wrote:
> Wolfgang Grandegger schrieb:
>> Matthias Fuchs wrote:
>>> Hi,
>>>
>>> I am wondering what is the best way to provide
>>> some product information for a CAN interface device (hardware version, 
>>> serialno, firmware version)? My favour way is to generate some files
>>> in sysfs as it is typically (but limited) done for USB devices.
>>>
>>> Would /sys/class/net/can*/version be suitable?
>> I just understood from Oliver, that your are speaking about device
>> specific properties (and not common one). Then just use
>> device_create_file(), which will create entries in /sys/devices/...
>> (the symbolic link /sys/class/net/can*/device).
> We are talking about common properties (e.g. manufacturer, serial
> number, ...) and specific properties (e.g. enable +5V output).
> 
> Imagine a GUI application which displays all available CAN channels. How
> does the user differ between 2 or 3 connected devices or just think
> about the 4 channel CPC-PCI board. How does the user know which can*
> device is which channel?

This could be done using the device renaming mechanism.
 
> In our proprietary products we have a similiar situation as in Socket
> CAN. In Socket CAN you have abstract can* network interface to access
> the actual physical channel. In our library CPC-LIB you have CHAN*,
> these logical channels (CHAN*) must be configured using device
> information (e.g. CHAN00 is CPC-PCI board #1, channel #2, CHAN02 is
> CPC-USB with serial #1923).
> 
> If the candev system would provide a common to get this information, a
> GUI display or even a terminal application can display additional
> information about each channel, so the user can decide which channel he
> wants to actually use.

Then it would make sense to add this to the device properties you can
get via the CAN netlink interface. Most likely you are interested in
other parameters like CAN statistics or bit-timinig as well. That's not
a big deal. They would then show up here:


$ ip -details -statistics link show can0
    2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen 10
      link/can
      can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 100
      bitrate 125000 sample_point 0.875
      tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
      sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
      clock 8000000
      board cpc-pci channel 2 serial# 123456 

Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to