Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1410009 > unrolled thread

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-05-31 11:00 +0200
    Re: [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-05-31 14:10 +0200
      Re: [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-05-31 14:50 +0200
        Re: [RFC PATCHv2] usb: USB Type-C Connector Class Guenter Roeck <linux@roeck-us.net> - 2016-05-31 19:30 +0200
          Re: [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus <heikki.krogerus@linux.intel.com> - 2016-06-01 10:30 +0200
            Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-06-01 10:40 +0200
            Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-06-01 11:10 +0200
              Re: [RFC PATCHv2] usb: USB Type-C Connector Class Guenter Roeck <linux@roeck-us.net> - 2016-06-01 15:40 +0200
                Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-06-02 08:30 +0200
                  Re: [RFC PATCHv2] usb: USB Type-C Connector Class Guenter Roeck <linux@roeck-us.net> - 2016-06-02 08:40 +0200
                    Re: [RFC PATCHv2] usb: USB Type-C Connector Class Oliver Neukum <oneukum@suse.com> - 2016-06-02 09:50 +0200

#1410009 — Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> Hi Oliver,
> 
> On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > Hi guys,
> > > 
> > > I'm attaching a diff instead of full v3. I'm not yet adding attributes
> > > for the reset and cable_reset. I still don't understand what is the
> > > case where the userspace would need to be able to tricker reset? Why
> > > isn't it enough for the userspace to be able to enter/exit modes?
> > > Oliver! Can you please comment?
> > 
> > 1. Because we need error handling.
> >    Devices crash. Cables will crash. We will get out of sync.
> >    You never put yourself in a place where you cannot handle an
> >    IO error.
> > 2. Because it is in the spec. We do not second guess the spec.
> >    We implement it.
> 
> Error conditions and crashes are the responsibility of the USB PD
> stack, not userspace. In those cases the stack can not wait for a

Those are not exclusive conditions.

> command from the userspace. So for example if a timer like
> NoResponseTimer times out, the stack an its state machines will have
> to take care of the reset quite independently.

Yes. But somebody needs to handle high level errors.

> If you get out of sync with an alternate mode, you reset that specific
> alternate mode by exiting and re-entering it, and you do not reset the
> entire PD connection, port, partner or cable.

That would be the first step. If that doesn't work you will at that
point either give up or use the next largest hammer.
In principle you could do that in kernel space, but that implies
that the kernel can detect all failures. That is unlikely.

> The resets from userspace would be purely unsolicited. What would the
> cases where we would need to tricker a reset like that?
> 
> I want to be careful with exposing reset to userspace. Reset in USB PD
> is not just an IO related thing. When you tricker a reset with USB PD,
> even if it's a soft reset, it may lead into hard reset, which may
> potentially lead into sudden voltage and current drop, which may lead
> into the entire system crashing. We really need to understand the
> cases where it would be necessary to tricker a reset from userspace.
> Right now I don't see any.

User space can call reboot. Actually that does not help.
Reset is an operation that is intended for error handling.
If all else fails, we will need to use it.
Its bad consequences apply whether you trigger this from kernel or
user space. In fact, an operation that may potentially crash the system
should involve user space.

[..]
> > > We also need to decide how the alternate modes a port support are
> > > exposed to the userspace. Do we just assume the port drivers will
> > > create them as devices under the port device itself, just like
> > > alternate modes of partners and cable plugs are exposed under the
> > > partners and cable plugs? That works for me, but again, the class does
> > > not have any effect on that, and it will be just a guideline. Maybe
> > > we can add some kind of helpers and force the port drivers to use
> > > them.
> > 
> > What are the alternatives?
> 
> Can we make a group for them under the port device somehow? Like the
> supported_alternate_modes I proposed. I guess it's not possible to add
> devices to a specific group in sysfs. And would it even be useful.

Please explain. It is not clear to me what you are proposing here.

	Regards
		Oliver

[toc] | [next] | [standalone]

#1410234

On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote:
> On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> > Hi Oliver,
> > 
> > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > > Hi guys,
> > > > 
> > > > I'm attaching a diff instead of full v3. I'm not yet adding attributes
> > > > for the reset and cable_reset. I still don't understand what is the
> > > > case where the userspace would need to be able to tricker reset? Why
> > > > isn't it enough for the userspace to be able to enter/exit modes?
> > > > Oliver! Can you please comment?
> > > 
> > > 1. Because we need error handling.
> > >    Devices crash. Cables will crash. We will get out of sync.
> > >    You never put yourself in a place where you cannot handle an
> > >    IO error.
> > > 2. Because it is in the spec. We do not second guess the spec.
> > >    We implement it.
> > 
> > Error conditions and crashes are the responsibility of the USB PD
> > stack, not userspace. In those cases the stack can not wait for a
> 
> Those are not exclusive conditions.
> 
> > command from the userspace. So for example if a timer like
> > NoResponseTimer times out, the stack an its state machines will have
> > to take care of the reset quite independently.
> 
> Yes. But somebody needs to handle high level errors.
> 
> > If you get out of sync with an alternate mode, you reset that specific
> > alternate mode by exiting and re-entering it, and you do not reset the
> > entire PD connection, port, partner or cable.
> 
> That would be the first step. If that doesn't work you will at that
> point either give up or use the next largest hammer.
> In principle you could do that in kernel space, but that implies
> that the kernel can detect all failures. That is unlikely.

Any PD communication failures the kernel has to be able to detect, so
I guess you mean failures with the alternate modes themselves, right?

In that case, surely exiting the mode is enough to "reset" it? When it
is re-entered, it has to be completely re-configured in any case. I
don't see how resetting the whole port or cable would guarantee that a
mode would become any more functional in case of failures? It will
however make also the other active modes to de-activate even if they
are functioning fine.

> > The resets from userspace would be purely unsolicited. What would the
> > cases where we would need to tricker a reset like that?
> > 
> > I want to be careful with exposing reset to userspace. Reset in USB PD
> > is not just an IO related thing. When you tricker a reset with USB PD,
> > even if it's a soft reset, it may lead into hard reset, which may
> > potentially lead into sudden voltage and current drop, which may lead
> > into the entire system crashing. We really need to understand the
> > cases where it would be necessary to tricker a reset from userspace.
> > Right now I don't see any.
> 
> User space can call reboot. Actually that does not help.
> Reset is an operation that is intended for error handling.
> If all else fails, we will need to use it.
> Its bad consequences apply whether you trigger this from kernel or
> user space. In fact, an operation that may potentially crash the system
> should involve user space.
> 
> > > > We also need to decide how the alternate modes a port support are
> > > > exposed to the userspace. Do we just assume the port drivers will
> > > > create them as devices under the port device itself, just like
> > > > alternate modes of partners and cable plugs are exposed under the
> > > > partners and cable plugs? That works for me, but again, the class does
> > > > not have any effect on that, and it will be just a guideline. Maybe
> > > > we can add some kind of helpers and force the port drivers to use
> > > > them.
> > > 
> > > What are the alternatives?
> > 
> > Can we make a group for them under the port device somehow? Like the
> > supported_alternate_modes I proposed. I guess it's not possible to add
> > devices to a specific group in sysfs. And would it even be useful.
> 
> Please explain. It is not clear to me what you are proposing here.

So is it possible to have a folder in sysfs for the alternate modes
a port supports?

So instead of:

        /sysfs/class/type-c/usbc0/svid:xxx1/
        /sysfs/class/type-c/usbc0/svid:xxx2/
        /sysfs/class/type-c/usbc0/svid:xxx3/
        ...

We would have something like:

        /sysfs/class/type-c/usbc0/supported_alternate_modes/svid:xxx1/
        /sysfs/class/type-c/usbc0/supported_alternate_modes/svid:xxx2/
        /sysfs/class/type-c/usbc0/supported_alternate_modes/svid:xxx3/
        ...


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1410266

On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote:
> On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote:
> > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> > > Hi Oliver,
> > > 
> > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > > > Hi guys,
> > > > > 
> > > > > I'm attaching a diff instead of full v3. I'm not yet adding attributes
> > > > > for the reset and cable_reset. I still don't understand what is the
> > > > > case where the userspace would need to be able to tricker reset? Why
> > > > > isn't it enough for the userspace to be able to enter/exit modes?
> > > > > Oliver! Can you please comment?
> > > > 
> > > > 1. Because we need error handling.
> > > >    Devices crash. Cables will crash. We will get out of sync.
> > > >    You never put yourself in a place where you cannot handle an
> > > >    IO error.
> > > > 2. Because it is in the spec. We do not second guess the spec.
> > > >    We implement it.
> > > 
> > > Error conditions and crashes are the responsibility of the USB PD
> > > stack, not userspace. In those cases the stack can not wait for a
> > 
> > Those are not exclusive conditions.
> > 
> > > command from the userspace. So for example if a timer like
> > > NoResponseTimer times out, the stack an its state machines will have
> > > to take care of the reset quite independently.
> > 
> > Yes. But somebody needs to handle high level errors.
> > 
> > > If you get out of sync with an alternate mode, you reset that specific
> > > alternate mode by exiting and re-entering it, and you do not reset the
> > > entire PD connection, port, partner or cable.
> > 
> > That would be the first step. If that doesn't work you will at that
> > point either give up or use the next largest hammer.
> > In principle you could do that in kernel space, but that implies
> > that the kernel can detect all failures. That is unlikely.
> 
> Any PD communication failures the kernel has to be able to detect, so
> I guess you mean failures with the alternate modes themselves, right?
> 
> In that case, surely exiting the mode is enough to "reset" it? When it
> is re-entered, it has to be completely re-configured in any case. I
> don't see how resetting the whole port or cable would guarantee that a
> mode would become any more functional in case of failures? It will
> however make also the other active modes to de-activate even if they
> are functioning fine.

Forget about it, I'll just add the reset attributes. I'm still not
clear about their usefulness, but instead they will just create a small
risk, but I can live with that.


Cheers,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1410469

On Tue, May 31, 2016 at 03:43:56PM +0300, Heikki Krogerus wrote:
> On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote:
> > On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote:
> > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> > > > Hi Oliver,
> > > > 
> > > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > > > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > I'm attaching a diff instead of full v3. I'm not yet adding attributes
> > > > > > for the reset and cable_reset. I still don't understand what is the
> > > > > > case where the userspace would need to be able to tricker reset? Why
> > > > > > isn't it enough for the userspace to be able to enter/exit modes?
> > > > > > Oliver! Can you please comment?
> > > > > 
> > > > > 1. Because we need error handling.
> > > > >    Devices crash. Cables will crash. We will get out of sync.
> > > > >    You never put yourself in a place where you cannot handle an
> > > > >    IO error.
> > > > > 2. Because it is in the spec. We do not second guess the spec.
> > > > >    We implement it.
> > > > 
> > > > Error conditions and crashes are the responsibility of the USB PD
> > > > stack, not userspace. In those cases the stack can not wait for a
> > > 
> > > Those are not exclusive conditions.
> > > 
> > > > command from the userspace. So for example if a timer like
> > > > NoResponseTimer times out, the stack an its state machines will have
> > > > to take care of the reset quite independently.
> > > 
> > > Yes. But somebody needs to handle high level errors.
> > > 
> > > > If you get out of sync with an alternate mode, you reset that specific
> > > > alternate mode by exiting and re-entering it, and you do not reset the
> > > > entire PD connection, port, partner or cable.
> > > 
> > > That would be the first step. If that doesn't work you will at that
> > > point either give up or use the next largest hammer.
> > > In principle you could do that in kernel space, but that implies
> > > that the kernel can detect all failures. That is unlikely.
> > 
> > Any PD communication failures the kernel has to be able to detect, so
> > I guess you mean failures with the alternate modes themselves, right?
> > 
> > In that case, surely exiting the mode is enough to "reset" it? When it
> > is re-entered, it has to be completely re-configured in any case. I
> > don't see how resetting the whole port or cable would guarantee that a
> > mode would become any more functional in case of failures? It will
> > however make also the other active modes to de-activate even if they
> > are functioning fine.
> 
> Forget about it, I'll just add the reset attributes. I'm still not
> clear about their usefulness, but instead they will just create a small
> risk, but I can live with that.
> 

Given my experience over the last few weeks, I think the added risk
may not just be small, and I think the added benefit is questionable.
Reset handling is not well implemented in all devices, and manually
triggered resets in an unexpected state may make the situation worse.

Can you make it optional ? I may choose not to support it to avoid
the risk.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]

#1410934

On Tue, May 31, 2016 at 10:20:34AM -0700, Guenter Roeck wrote:
> On Tue, May 31, 2016 at 03:43:56PM +0300, Heikki Krogerus wrote:
> > On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote:
> > > On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote:
> > > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> > > > > Hi Oliver,
> > > > > 
> > > > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > > > > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > > > > > Hi guys,
> > > > > > > 
> > > > > > > I'm attaching a diff instead of full v3. I'm not yet adding attributes
> > > > > > > for the reset and cable_reset. I still don't understand what is the
> > > > > > > case where the userspace would need to be able to tricker reset? Why
> > > > > > > isn't it enough for the userspace to be able to enter/exit modes?
> > > > > > > Oliver! Can you please comment?
> > > > > > 
> > > > > > 1. Because we need error handling.
> > > > > >    Devices crash. Cables will crash. We will get out of sync.
> > > > > >    You never put yourself in a place where you cannot handle an
> > > > > >    IO error.
> > > > > > 2. Because it is in the spec. We do not second guess the spec.
> > > > > >    We implement it.
> > > > > 
> > > > > Error conditions and crashes are the responsibility of the USB PD
> > > > > stack, not userspace. In those cases the stack can not wait for a
> > > > 
> > > > Those are not exclusive conditions.
> > > > 
> > > > > command from the userspace. So for example if a timer like
> > > > > NoResponseTimer times out, the stack an its state machines will have
> > > > > to take care of the reset quite independently.
> > > > 
> > > > Yes. But somebody needs to handle high level errors.
> > > > 
> > > > > If you get out of sync with an alternate mode, you reset that specific
> > > > > alternate mode by exiting and re-entering it, and you do not reset the
> > > > > entire PD connection, port, partner or cable.
> > > > 
> > > > That would be the first step. If that doesn't work you will at that
> > > > point either give up or use the next largest hammer.
> > > > In principle you could do that in kernel space, but that implies
> > > > that the kernel can detect all failures. That is unlikely.
> > > 
> > > Any PD communication failures the kernel has to be able to detect, so
> > > I guess you mean failures with the alternate modes themselves, right?
> > > 
> > > In that case, surely exiting the mode is enough to "reset" it? When it
> > > is re-entered, it has to be completely re-configured in any case. I
> > > don't see how resetting the whole port or cable would guarantee that a
> > > mode would become any more functional in case of failures? It will
> > > however make also the other active modes to de-activate even if they
> > > are functioning fine.
> > 
> > Forget about it, I'll just add the reset attributes. I'm still not
> > clear about their usefulness, but instead they will just create a small
> > risk, but I can live with that.
> > 
> 
> Given my experience over the last few weeks, I think the added risk
> may not just be small, and I think the added benefit is questionable.
> Reset handling is not well implemented in all devices, and manually
> triggered resets in an unexpected state may make the situation worse.
> 
> Can you make it optional ? I may choose not to support it to avoid
> the risk.

Maybe I gave up on this too hastily... I changing my mind about this,
I'm not going to add them. Having them optional is not enough. It
changes nothing when they are implemented. I think there is a change
that we would actually end up having to remove the attributes, which
would be really bad.

I think we can still add them later if they are still seen as
necessity later on, tough I seriously doubt it. It would not be
ideal, but adding an attribute should not really break anything,
right? Removing would.


Thanks,

-- 
heikki

[toc] | [prev] | [next] | [standalone]

#1410952

On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote:
> On Tue, May 31, 2016 at 10:20:34AM -0700, Guenter Roeck wrote:
> > On Tue, May 31, 2016 at 03:43:56PM +0300, Heikki Krogerus wrote:
> > > On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote:
> > > > On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote:
> > > > > On Tue, 2016-05-31 at 11:31 +0300, Heikki Krogerus wrote:
> > > > > > Hi Oliver,
> > > > > > 
> > > > > > On Mon, May 30, 2016 at 03:59:27PM +0200, Oliver Neukum wrote:
> > > > > > > On Mon, 2016-05-30 at 16:19 +0300, Heikki Krogerus wrote:
> > > > > > > > Hi guys,
> > > > > > > > 
> > > > > > > > I'm attaching a diff instead of full v3. I'm not yet adding attributes
> > > > > > > > for the reset and cable_reset. I still don't understand what is the
> > > > > > > > case where the userspace would need to be able to tricker reset? Why
> > > > > > > > isn't it enough for the userspace to be able to enter/exit modes?
> > > > > > > > Oliver! Can you please comment?
> > > > > > > 
> > > > > > > 1. Because we need error handling.
> > > > > > >    Devices crash. Cables will crash. We will get out of sync.
> > > > > > >    You never put yourself in a place where you cannot handle an
> > > > > > >    IO error.
> > > > > > > 2. Because it is in the spec. We do not second guess the spec.
> > > > > > >    We implement it.
> > > > > > 
> > > > > > Error conditions and crashes are the responsibility of the USB PD
> > > > > > stack, not userspace. In those cases the stack can not wait for a
> > > > > 
> > > > > Those are not exclusive conditions.
> > > > > 
> > > > > > command from the userspace. So for example if a timer like
> > > > > > NoResponseTimer times out, the stack an its state machines will have
> > > > > > to take care of the reset quite independently.
> > > > > 
> > > > > Yes. But somebody needs to handle high level errors.
> > > > > 
> > > > > > If you get out of sync with an alternate mode, you reset that specific
> > > > > > alternate mode by exiting and re-entering it, and you do not reset the
> > > > > > entire PD connection, port, partner or cable.
> > > > > 
> > > > > That would be the first step. If that doesn't work you will at that
> > > > > point either give up or use the next largest hammer.
> > > > > In principle you could do that in kernel space, but that implies
> > > > > that the kernel can detect all failures. That is unlikely.
> > > > 
> > > > Any PD communication failures the kernel has to be able to detect, so
> > > > I guess you mean failures with the alternate modes themselves, right?
> > > > 
> > > > In that case, surely exiting the mode is enough to "reset" it? When it
> > > > is re-entered, it has to be completely re-configured in any case. I
> > > > don't see how resetting the whole port or cable would guarantee that a
> > > > mode would become any more functional in case of failures? It will
> > > > however make also the other active modes to de-activate even if they
> > > > are functioning fine.
> > > 
> > > Forget about it, I'll just add the reset attributes. I'm still not
> > > clear about their usefulness, but instead they will just create a small
> > > risk, but I can live with that.
> > > 
> > 
> > Given my experience over the last few weeks, I think the added risk
> > may not just be small, and I think the added benefit is questionable.
> > Reset handling is not well implemented in all devices, and manually
> > triggered resets in an unexpected state may make the situation worse.
> > 
> > Can you make it optional ? I may choose not to support it to avoid
> > the risk.
> 
> Maybe I gave up on this too hastily... I changing my mind about this,
> I'm not going to add them. Having them optional is not enough. It
> changes nothing when they are implemented. I think there is a change
> that we would actually end up having to remove the attributes, which
> would be really bad.
> 
> I think we can still add them later if they are still seen as
> necessity later on, tough I seriously doubt it. It would not be
> ideal, but adding an attribute should not really break anything,
> right? Removing would.

That is true. So let's leave it out for now. I still think sane
error handling will require it eventually, but that will be in the
future.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1411008

On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote:
> I think we can still add them later if they are still seen as
> necessity later on, tough I seriously doubt it. It would not be
> ideal, but adding an attribute should not really break anything,
> right? Removing would.

However, how do we learn that the other side has triggered a reset?

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1411228

On 06/01/2016 02:04 AM, Oliver Neukum wrote:
> On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote:
>> I think we can still add them later if they are still seen as
>> necessity later on, tough I seriously doubt it. It would not be
>> ideal, but adding an attribute should not really break anything,
>> right? Removing would.
>
> However, how do we learn that the other side has triggered a reset?
>

USB PD specification, section 6.8.2.2 (Modal Operation and Hard Reset):

A Hard Reset shall cause all Active Modes to be exited by both Port Partners
and any Cable Plugs (see Section 6.4.4.3.4).

Section 6.4.4.3.4 (Enter Mode Command):

The following events shall also cause the Port Partners and Cable Plug(s) to exit all Active Modes:
- A PD Hard Reset
- The Port Partners or Cable Plug(s) are Detached
- A Cable Reset (only exits the Cable Plug’s Active Modes)

The class code would not explicitly learn about the reset,
but it would be informed about the exited modes.

Guenter

[toc] | [prev] | [next] | [standalone]

#1411882

On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
> The class code would not explicitly learn about the reset,
> but it would be informed about the exited modes.

That has drawbacks

- it doesn't tell you what caused the mode to be left (if you
  UFP, it may be the regular command)
- it is a race against your own command
- it does not work if you are in basic USB mode

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1411891

On 06/01/2016 11:24 PM, Oliver Neukum wrote:
> On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
>> The class code would not explicitly learn about the reset,
>> but it would be informed about the exited modes.
>
> That has drawbacks
>

Playing devils advocate a bit here

> - it doesn't tell you what caused the mode to be left (if you
>    UFP, it may be the regular command)

Does it matter ?

> - it is a race against your own command

It is my understanding that races have to be resolved by the drivers,
since the typec code does not do any locking. This is quite similar
to handling, say, a request to change the vconn source or to change
the power role. Am I missing something ?

> - it does not work if you are in basic USB mode
>
Would alternate modes be active in that case ?

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]

#1411957

On Wed, 2016-06-01 at 23:37 -0700, Guenter Roeck wrote:
> On 06/01/2016 11:24 PM, Oliver Neukum wrote:
> > On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
> >> The class code would not explicitly learn about the reset,
> >> but it would be informed about the exited modes.
> >
> > That has drawbacks
> >
> 
> Playing devils advocate a bit here
> 
> > - it doesn't tell you what caused the mode to be left (if you
> >    UFP, it may be the regular command)
> 
> Does it matter ?

Potentially yes. Should you restore the last state when the mode
is reentered? If it caused the other side to reset, probably not.

> > - it is a race against your own command
> 
> It is my understanding that races have to be resolved by the drivers,
> since the typec code does not do any locking. This is quite similar
> to handling, say, a request to change the vconn source or to change
> the power role. Am I missing something ?

Yes. There is a fundamental race between Exit Mode and reset if you
only report leaving a mode. Drivers can do nothing to prevent it
unless reporting resets by themselves.

> > - it does not work if you are in basic USB mode
> >
> Would alternate modes be active in that case ?

No and that is the point. A reset happens, presumably because the
other side saw an error condition and we just blindly continue
because no Alternate Mode was left and our user space remains
uninformed.

	Regards
		Oliver

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web