Messages in this thread | | | Date | Tue, 20 Mar 2012 07:51:44 -0700 | From | Nick Dyer <> | Subject | Re: [PATCH 06/20] Input: atmel_mxt_ts - allow writing to object sysfs entry |
| |
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@chromium.org>
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
| |