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. Thanks, Guenter > > 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. > > Well, if platform data has a default, I suppose we ought to use it. > > > 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 > > I would say that the ought to be a driver for type C which controls > alternate modes and roles. > > Regards > Oliver > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
