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: <20160524110431.GC26874@kuha.fi.intel.com>
Date:	Tue, 24 May 2016 14:04:31 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Oliver Neukum <oneukum@...e.com>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	Andy Shevchenko <andy.shevchenko@...il.com>,
	Rajaram R <rajaram.officemail@...il.com>,
	Felipe Balbi <felipe.balbi@...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 Tue, May 24, 2016 at 12:18:38PM +0200, Oliver Neukum wrote:
> On Tue, 2016-05-24 at 13:08 +0300, Heikki Krogerus wrote:
> > Hi Guenter,
> > 
> > On Mon, May 23, 2016 at 09:52:12AM -0700, Guenter Roeck wrote:
> > > On Mon, May 23, 2016 at 05:55:04PM +0200, Oliver Neukum wrote:
> > > > On Mon, 2016-05-23 at 07:43 -0700, Guenter Roeck wrote:
> > > > > On 05/23/2016 06:58 AM, Oliver Neukum wrote:
> > > > 
> > > > > > 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
> > > > 
> > > > Why on earth? That is most clearly a policy decision.
> > > > 
> > > 
> > > The question is not that much if it is policy (it is), but if the policy
> > > should be driven by the platform or by user space. I think there needs
> > > to be at least a default driven by the platform. As already mentioned,
> > > I am ok with a means to override this platform default from user space.
> > > But if user space doesn't say, there still needs to be a default.
> > 
> > I don't completely agree with that. The platform should not, and
> > actually in most cases with ACPI AFAIK, will not provide any
> > "preferences" to the OS about anything. The platform should only
> > provide the OS the physical capabilities and nothing else. So if for
> > example the platform is capable of acting as only source with a Type-C
> > port, that is what it needs to tell to the OS so possibly the PHY can
> > be programmed accordingly, etc.
> 
> May I suggest that the point is moot as long as we agree that user space
> needs to be able to set a policy? The OS cannot ignore the port before
> user space tells it what to do. So a default will be needed.
> 
> The OS must act conservatively, which means it cannot deactivate
> hardware. So if a port can do DRP, that must be the default.

So exactly my point.

> I would go so far that I would suggest that we add a module parameter
> for Try.SRC and Try.SNK to avoid trouble during boot.

I would be fine with that, but apparently module parameters are so 90s
:(

> > So IMO, just like with any decision related to what the system will
> > ultimately be used for, decision about the preferred role really
> > belongs to the userspace.
> 
> Yes, but ought the APIs for role, mode and PD be separate or not.
> Sorry to sound like a broken record, but you need to provide some
> higher level planning here.

I was kinda hoping that we could formulate the plan together in this
thread.


Thanks,

-- 
heikki