linux-kernel - Re: [PATCH] drm/bridge: tc358767: Expose test mode functionality via debugfs

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] [day] [month] [year] [list]

Date:   Wed, 28 Aug 2019 08:48:04 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...com>
To:     Andrey Smirnov <andrew.smirnov@...il.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
CC:     <dri-devel@...ts.freedesktop.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Cory Tusar <cory.tusar@....aero>,
        Chris Healy <cphealy@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/bridge: tc358767: Expose test mode functionality via
 debugfs

On 28/08/2019 01:51, Andrey Smirnov wrote:

>> The whole point of a
>> driver is to avoid needing detailed knowledge of the device's internals
>> in userspace.
>>
> 
> You won't avoid needing detailed knowledge of the device's internals
> if you don't have a priori knowledge in the form of a agreed upon/well
> known abstraction you are exposing from the driver. There is no such
> abstraction in this case. Whether you present "tstctl" that takes a
> magic value or "red", "green", "blue" and "pattern" taking numbers and
> special strings, as a user, you still would have to go read the driver
> code in order to figure out how that stuff works.
> 
> Given how this is an obscure _debug_ feature for a niche part, I think
> exposing raw register and leaving a comment in the driver source code
> explaining how it works is reasonably user-friendly (for all 10 - 15
> unique users that this feature would ever have).
> 
> To avoid any further back and forth of this subject, how about the
> following. If this is up to me, then I'd like to move forward to v2
> with the interface as is. If you feel strongly about this and insist
> on your vision of the interface, please let me know what it looks like
> (e.g. is what I described above good enough) and I'll rework v2 to
> have that.

I agree, I don't see a point in adding a pile of code to make a device 
specific debug feature to hide the device internals. If someone is going 
to use this feature, most likely he either has the datasheet or he has 
been asked by someone with the datasheet to try the feature.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki