linux-kernel - Re: [RFC PATCHv2] usb: USB Type-C Connector Class

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: <57431704.3030703@roeck-us.net>
Date:	Mon, 23 May 2016 07:43:16 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	Andy Shevchenko <andy.shevchenko@...il.com>,
	Rajaram R <rajaram.officemail@...il.com>,
	Felipe Balbi <felipe.balbi@...ux.intel.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On 05/23/2016 06:58 AM, Oliver Neukum wrote:
> On Mon, 2016-05-23 at 06:27 -0700, Guenter Roeck wrote:
>>>> Good question. I originally added a sysfs attribute
>> 'preferred-mode' to
>>>> my code, but then concluded that this is supposed to be provided
>>>> by the platform and added it as platform data instead, with
>> (currently)
>>>> no means to report it to user space.
>>>
>>> Mode or role? I would say that the choice of alternate modes belongs
>> to
>>
>> s/preferred mode/preferred role/g
>
> Now I am confused. Are you saying that the choice of Alternate Mode does
> not belong into user space?
>

No; sorry for the confusion. The above was meant to apply to my use
of "preferred mode", not yours. I was trying to say that the choice of
preferred roles (which determines if Try.SRC or Try.SNK is enabled)
should belong primarily into the kernel, to be determined by the platform
(presumably via ACPI, devicetree data, or platform data). If it should
be possible to override it by user space is a different question. That
might be useful, at least for testing. If so, does such an override
belong into the class or into the PD driver ? Good question. I am fine
either way.

I don't really have a strong opinion about alternate mode selection. I would
think that there should be a kernel (platform) default, possibly determined
by the alternate mode itself, but I also think that it should be selectable
by user space. Question is if that should be done through the alternate mode
driver or through the class (example: alternate modes used for firmware
upgrades and other device specific functionality). I don't really have
an answer for that at this point. I'll probably have a better idea after
I implemented the alternate mode driver for Google devices.

Again, sorry for creating confusion between preferred role and preferred
(alternate) mode selection.

Thanks,
Guenter