Daniel Kurtz wrote: > Userspace can write a 24-bit value (encoded as a 6 character hex string) > to the 'object' sysfs entry to modify a single byte of the object table. > The hex string encodes a 3 bytes, in the following format: > TTFFVV > > Where: > TT = object type > FF = object offset > VV = byte value > > The object table is modified in device ram, which means the change is > volatile, and will be overwritten on the next device reset. To make > changes permanent, the new settings should be persisted in the device's > Non-Voltatile Memory using the updatenv sysfs entry. > > Also, since the device driver initializes itself by reading some values > from the object table, the entire driver may need to be unloaded and > reloaded after writing the values for the driver to stay in sync. Whether > this is required depends on exactly which values were updated. > > Signed-off-by: Daniel Kurtz <djkurtz@xxxxxxxxxxxx> NAK. I have several concerns about this: 1) The object sysfs entry doesn't follow the sysfs guidelines, this is abusing it further. 2) Object type can be larger than 1 byte in the future. 3) Your interface restricts you to doing 1 byte writes. What about larger block sizes? In short, I think exposing the entire register space as a binary attribute (the same way that regmap does) is a preferable solution to this requirement, and we already have user space tools which use it. cheers -- Nick Dyer Software Engineer, ITDev Ltd Hardware and Software Development Consultancy Website: http://www.itdev.co.uk -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
