Wolfgang Grandegger wrote: > 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. > > How would the product information be used in user space by an > application? Wouldn't a "dev_info" not be enough? > >> Would /sys/class/net/can*/version be suitable? > > I don't think so. We do device configuration via netlink.
Hi Wolfgang, additionally to 'classic' CAN netdev operations, e.g. the PEAK USB Adapters have at least these functionalities: - get the device specific serial number (a very common usecase) - set a device number (one byte) - get this device number And the PEAK PCCARD can be configured at runtime to enable a +5V output on Pin 1 of the Sub-D 9 to power a CAN phy adapter. These are only four cases i have in mind and i assume there are lot's more in the ESD, SOFTING and EMS hardware (to be hopefully complete with the product placement ;-) As you already suggested the firmware updates should use the firmware infrastructure provided by the Linux kernel. This could be done like this: 1. check if there is a firmware available in lib/firmware/... 2. check if that fw is different to the device fw 3. if yes, upload the fw to the device --- When using dev_info e.g. the serial number needs to be determined by 'greping' whatever in dmesg - i don't think this is suitable. Another point is the currently missing udev support: E.g. we created a tricky scripting solution to determine the PEAK USB device number from 'cat /proc/pcan' to set the appropriate bitrate and rename the hotplugged USB Adapter to a fix predefined netdevice name. Finally it turns out that providing a device specific identifier (e.g. a hardware serial number) is really needed as this scripting solution is not really a good and reusable approach. To get the Vendor information, Serial Number, etc. could be also a interesting information for GUI-based CAN applications to display. IMHO we 1. need to provide some information that can be used for udev (in sysfs!) 2. need to provide a netlink based interface for vendor specific functions like setting the +5V on Pin1, enabling features, etc ... But i don't know in detail what should be added to the sysfs or what can be re-used ... Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
