Re: Notifying Id/HNP status to HCD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 08, 2010 at 10:43:07AM -0400, Alan Stern wrote:
> On Wed, 8 Sep 2010, Pavan Kondeti wrote:
> 
> > I am glad that you asked this question.
> 
> It is an interesting problem.  I'm not familiar with your hardware.  Do 
> the same device registers get used to control both the host controller 
> and the device controller?  If that's so then it really is not possible 
> for both of them to exist at the same time.
> 
Yes. The same set of registers are used to control both host controller and
the device controller. Interrupt line is also the same.

> > The reason for removing HCD upon id float is to guard against
> > 1. sysfs/debugfs entries exposed by USB core/ehci
> > 2. auto suspend (runtime suspend) and system suspend
> 
> If the host controller registers can be accessed without interfering
> with the operation of the device controller then there's no reason to
> guard against these things.
> 

As the registers are common, this gaurding is necessary.

> > I have started manipulating HW_ACCESSIBLE flag initially and faced some
> > problems. This was on 2.6.29 kernel. So I have decided to use usb_add_hcd and
> > usb_remove_hcd upon Id state change. But this is causing problems in meeting
> > HNP timings. When HNP is started, host is suspended by clearing HW_ACCESSIBLE
> > flag, disabling autosuspend, and changing it usb state to NOT_ATTACHED.
> 
> You should change the state to NOT_ATTACHED first.  I hope you do this 
> by calling usb_set_device_state().
> 

udev->state is directly changed to NOT_ATTACHED. The reason, I have not used
this API is that it blocks till the children device is disconnected (i.e class
driver's unbind is called). Is this API have an async version?

> > I really want to avoid calling usb_add_hcd() and usb_remove_hcd() and use the
> > same set of operations for both Id state change and HNP.
> 
> If there isn't enough time then you don't have much choice.  However 
> those steps you take aren't enough to prevent intrusion before you get 
> around to calling usb_remove_hcd().
> 

According to OTG 2.0 spec, B-device should observe A-device connect signal
with in 155ms (min time) after A-device suspended the bus. usb_remove_hcd
blocks till the B-device and root hub are completely disconnected (class
drivers unbind).

ehci_irq observes the PCD interrupt and B-device disconnection is carried out
in hub thread context. Before hub thread observes, this device disconnection,
root hub device state and HW_ACCESSIBLE flag is cleared and gadget driver is
activated. Yeah. Its all looks like hacky and racy. But could not find a
better method to meet HNP timings.

> 
> >  How can we avoid autosuspend/system suspend and intrusion from
> > sysfs/debugfs without calling usb_remove_hcd?
> 
> The only way would be to have the HCD check whether or not the hardware
> is in host mode before allowing it to do anything.  On the whole,
> unregistering the host controller seems safer if it cannot operate
> without interfering with the device controller.
> 
I agree. I am trying to submit the basic OTG driver (host/device role based on
Id pin state) first. So I will stick to usb_add_hcd() and usb_remove_hcd().
> 
> --
> 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

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux