linux-kernel - Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 05 Jun 2013 22:36:45 +0100
From:	Nick Dyer <nick.dyer@...ev.co.uk>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Daniel Kurtz <djkurtz@...omium.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Alan.Bowens@...el.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, pmeerw@...erw.net,
	bleung@...omium.org, olofj@...omium.org
Subject: Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface
 via sysfs

Dmitry Torokhov wrote:
>> debugfs is a debug filesystem. This interface is useful for purposes which
>> are not debug.
> 
> What other purposes does it serve? I'd expect you need it during new
> board bringup.

Yes, during board bringup it's extremely useful. We have implemented
numerous open and closed source utilities that can use this interface.

Run-time examples would be adjusting noise suppression or touch suppression
parameters based on something going on in the app layer (eg having
different parameters during unlock screen), or tuning report rates based on
application requirements, ot to inspect debug data if the touch sensor is
faulty. You might say, well we should implement an kernel driver interface
for these requirements, but they will vary hugely between different
products. We are trying to keep the driver as generic as possible and push
product-specific complexity to user space. Hence exposing the register map
and implementing user-space libraries to deal with this kind of customisation.

>> I have to be pragmatic: I don't see debugfs enabled on most
>> shipping Android devices, and however much I tell them to enable debugfs
>> doesn't seem to hold much weight.
> 
> You do not need to have debugfs enabled on shipping kernels, just the
> ones you use for integration work.

I disagree. See above.

>> It's partly path dependence - it was implemented like this because regmap
>> wasn't in mainline at the point when I wrote it. Having a dependency on
>> regmap would now be a API break complicating support of customers using
>> older kernels than mainline. I would also have to update a bunch of
>> software and documentation and people to know about the two different APIs.
>> The existing implementation already appears in shipping devices, so it is
>> well tested.
> 
> This was never a good argument for introducing an interface into the
> kernel.

Yes, I know. Just pointing out that making changes to this does result in a
significant cost.

>> I can look into porting on top of regmap. But it seems a pity to pepper
>> regmap with atmel_mxt_ts quirks just to save on three small functions in
>> the driver.
> 
> This is not about saving 3 functions but rather the fact that individual
> register access is desired by many parties and instead of each driver
> implementing it's own solution (via a char device, sysfs, debugfs, etc)
> we should try to standardize on common userspace interface.

I agree that a common interface is desirable. If regmap met the
requirements I would certainly use it instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/