linux-kernel - RE: [PATCH v10 0/6] Introduced new Cadence USBSS DRD 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <BYAPR07MB470924FB97951364BD3AB5B3DDC40@BYAPR07MB4709.namprd07.prod.outlook.com>
Date:   Mon, 22 Jul 2019 12:11:40 +0000
From:   Pawel Laszczak <pawell@...ence.com>
To:     Pavel Machek <pavel@...x.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "felipe.balbi@...ux.intel.com" <felipe.balbi@...ux.intel.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "rogerq@...com" <rogerq@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jbergsagel@...com" <jbergsagel@...com>,
        "nsekhar@...com" <nsekhar@...com>, "nm@...com" <nm@...com>,
        Suresh Punnoose <sureshp@...ence.com>,
        Jayshri Dajiram Pawar <jpawar@...ence.com>,
        Rahul Kumar <kurahul@...ence.com>,
        Anil Joy Varughese <aniljoy@...ence.com>
Subject: RE: [PATCH v10 0/6] Introduced new Cadence USBSS DRD Driver.

>
>Hi!
>
>> > >> This patch introduce new Cadence USBSS DRD driver to linux kernel.
>> > >>
>> > >> The Cadence USBSS DRD Controller is a highly configurable IP Core which
>> > >> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
>> > >> Host Only (XHCI)configurations.
>> > >
>> > >I see you are using debugfs to select between DRD, peripheral-onlyh and XHCI...
>> > >
>> > >Is that good idea?
>> >
>> > Yes driver allows selecting dr_mode by debugfs. Controller also support such functionality
>> > so I don't understand why would it not be a good idea.
>> >
>> > I personally use this for testing but it can be used to limit controller functionality without
>> > recompiling kernel.
>>
>> debugfs is ONLY for debugging, never rely on it being enabled, or
>> mounted, on a system in order to have any normal operation happen.
>>
>> So for testing, yes, this is fine.  If this is going to be the normal
>> api/interface for how to control this driver, no, that is not acceptable
>> at all.
>
>It makes a lot of sense for end-user to toggle this... for example
>when he is lacking right cable for proper otg detection. As it is
>third driver offering this functionality, I believe we should stop
>treating it as debugging.
>

Exactly I use this for this purpose. Depending on my testing platform I have 
the adapter with Typ-c plugs or normal Type A plugs. In the second case, 
by means of this property I can force Device or Host mode from driver 
without changing adapter. 

Bu as I wrote I use it only for debugging purpose.  I believe  that device on 
the market should not work in this way. 

Cheers,
Pawel.