Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interfacevia sysfs

[Mark Brown]

On Thu, Jun 06, 2013 at 11:31:57AM +0100, Nick Dyer wrote:

> Having to define every parameter in each object (there are thousands) in
> the kernel driver would be impractically technically, since it would result
> in a huge, and constantly updating API, which would be always out-of-date,
> and impossible to support.

> Also, I'm afraid it would also be impractical legally, since it would
> breach the NDA terms that Atmel require on these parameter definitions.

If that's a big problem just put the data table in a section of the
firmware (or a separate file that gets requested as a firmware).  Or
have the firmware be able to enumerate itself when asked.

> >> product-specific complexity to user space. Hence exposing the register map
> >> and implementing user-space libraries to deal with this kind of customisation.

> > This sounds like a bad design decision for Linux, it's just asking for
> > fragility if userspace can go randomly poking round the entire register
> > map of the device with nothing coordinating with the driver code.

> It works very well in practice. This same abstraction is used across
> maXTouch products on many platforms to provide tool support. I agree that
> its use should be restricted to system programs.

It works well so long as people use the supplied binaries in the way
that's been proscribed.  As soon as people start upgrading kernels,
customising things out of your expected flow (because they can or
they're on a tight deadline) things will get more fragile.  This sort of
stuff is really common, the approaches I'm describing are fairly
standard solutions.

Attachment: signature.asc
Description: Digital signature