linux-kernel - Re: [PATCH v14 3/5] tee: add OP-TEE driver

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, 25 Jan 2017 12:03:37 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Jens Wiklander <jens.wiklander@...aro.org>,
        Olof Johansson <olof@...om.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Wei Xu <xuwei5@...ilicon.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        Al Viro <viro@...iv.linux.org.uk>, valentin.manea@...wei.com,
        jean-michel.delorme@...com, emmanuel.michel@...com,
        javier@...igon.com,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        Mark Rutland <mark.rutland@....com>,
        Michal Simek <michal.simek@...inx.com>,
        Rob Herring <robh+dt@...nel.org>,
        Will Deacon <will.deacon@....com>, Nishanth Menon <nm@...com>,
        "Andrew F . Davis" <afd@...com>, Mark Brown <broonie@...nel.org>,
        scott.branden@...adcom.com
Subject: Re: [PATCH v14 3/5] tee: add OP-TEE driver

On Wed, Jan 25, 2017 at 11:02 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Wed, Jan 25, 2017 at 10:47:45AM +0100, Jens Wiklander wrote:
>> On Tue, Jan 24, 2017 at 01:53:30PM +0100, Jens Wiklander wrote:
>> >
>> > /sys/class/tee/ sounds good, I'll use that. It's more or less what we
>> > also have today.
>>
>> I'm sorry, it seems a struct device has to be used in order to put stuff
>> under /sys/class/tee/. Or am I missing something?
>
> Nope, that is correct.

But that's a different device: this device represents the "class" of
device for the
user space interface, nothing wrong with that. However, we don't need both
the class device and a platform device that is made up by the optee driver
for a firmware feature to represent the same entity that we have the
class device
for.

     Arnd