lkml.org 
[lkml]   [2012]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2012-03-20 15:53    [W:0.943 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site