Messages in this thread | | | Subject | Re: [PATCHv14 2/3] usb: USB Type-C connector class | From | Guenter Roeck <> | Date | Tue, 10 Jan 2017 05:50:04 -0800 |
| |
On 01/10/2017 12:54 AM, Heikki Krogerus wrote: > Hi Guenter, > > On Mon, Jan 09, 2017 at 08:59:32AM -0800, Guenter Roeck wrote: >>> +/** >>> + * typec_register_partner - Register a USB Type-C Partner >>> + * @port: The USB Type-C Port the partner is connected to >>> + * @desc: Description of the partner >>> + * >>> + * Registers a device for USB Type-C Partner described in @desc. >>> + * >>> + * Returns handle to the partner on success or NULL on failure. >>> + */ >>> +struct typec_partner *typec_register_partner(struct typec_port *port, >>> + struct typec_partner_desc *desc) >>> +{ >> >> With the changes to hide the actual partner structure, this looks at first >> glance like a minor API change, but it is substantial. >> >> Reason is that the vdo as required by typec_partner_desc is provided by a VDM >> command reply, which is completely orthogonal to the PD registration process. >> So far I was able to set the vdo later, after registering the connection, >> and after (and if) the vdo was received. > > If the identity vdo value is updated after the creation of the device, > then the user space needs to be notified separately. > >> Since the partner may not even respond to the DISCOVER_IDENT message, or not >> support PD at all, this means that I would have to disconnect partner >> registration from the PD protocol itself and tie it to the VDO message >> exchange, with appropriate timeouts to register anyway even if the identity >> was not received after some period of time or if the partner does not support >> PD. >> >> This in turn means that I'll have to re-implement and possibly re-architect >> a substantial amount of code. > > We don't need to protect the structures like this, we can change this > back. But how about we introduce driver callback function for updating > the value instead, which would also notify the uses space? >
That would work.
Thanks, Guenter
| |