Re: [PATCHv12 2/3] usb: USB Type-C connector class

[Oliver Neukum <oneukum@suse.com>]

On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote:
> On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote:
> > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:

> The Type-C specification states (in 4.5.2.2.11):
> 
> "Note: if both Try.SRC and Try.SNK mechanisms are implemented, only one shall be
> enabled by the port at any given time. Deciding which of these two mechanisms
> is enabled is product design-specific."
> 
> I read into this:
> - The class code can not assume that either of those mechanisms are implemented.

Total agreement

> - "product-design specific" means that the product designer determines which of
>   the two mechanisms (if any) is enabled. While not explicitly stated, I would
>   assume this to be set either by hardware or via devicetree / ACPI, and not
>   from user space.

I read this as spec-speak for "not our problem"

> I don't mind to have user space control; all I am asking for is to have the
> means for lower level code (which is the most likely entity to know about
> product design) to be able to inform higher layers about its initial
> preferences. We have this now, so I am happy.

So am I.

> Personally I don't really care about a module parameter; as mentioned above,
> I would expect the preference, if it needs to be selectable, to be configured
> with devicetree or ACPI properties (or by a platform driver which sets a device
> property).

Well, as a distro for generic desktops and servers you will face an XHCI
on PCI and UCSI telling you that your ports can express preferences. Now
deal with it. And it must be said that such distros have over a decade
of experience in acting as a master. The slave capability is less well
developed. We'd like to be master. And if possible we'd like to avoid
a later switch of roles, so the choice should be easily made in initrd.

	Regards
		Oliver