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
--
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
