Oliver Hartkopp wrote: > 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 ...
OK, I see, if the sysfs file is in the device directory (not in /sys/class/can*) calling device_create_file(), I see little problems to get it accepted. Then it would simply be device specific. Would that be fine? Or do we need a common interface? For me it looks very device specific. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
