Always use Reply-To-All so that your messages get sent to the mailing
list as well as to me.
Also, please avoid top-posting.
On Fri, 26 Oct 2012, Ankit wrote:
> Hi Alan,
>
> Sorry, earlier code was not proper.
>
> Below is a code (mark as Bold), which we have put in hub_activate(),
Sorry, I can't read this. It is whitespace damaged and in the wrong
format. Please follow the instructions in
Documentation/SubmittingPatches.
Alan Stern
> static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
> {
> ....
> ....
> for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
> struct usb_device *udev = hdev->children[port1-1];
> u16 portstatus, portchange;
>
> portstatus = portchange = 0;
> status = hub_port_status(hub, port1, &portstatus, &portchange);
> if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
> dev_dbg(hub->intfdev,
> "port %d: status %04x change %04x\n",
> port1, portstatus, portchange);
>
> /* After anything other than HUB_RESUME (i.e., initialization
> * or any sort of reset), every port should be disabled.
> * Unconnected ports should likewise be disabled (paranoia),
> * and so should ports for which we have no usb_device.
> */
> if ((portstatus & USB_PORT_STAT_ENABLE) && (
> type != HUB_RESUME ||
> !(portstatus & USB_PORT_STAT_CONNECTION) ||
> !udev ||
> udev->state == USB_STATE_NOTATTACHED)) {
> /*
> * USB3 protocol ports will automatically transition
> * to Enabled state when detect an USB3.0 device attach.
> * Do not disable USB3 protocol ports.
> */
> if (!hub_is_superspeed(hdev)) {
> clear_port_feature(hdev, port1,
> USB_PORT_FEAT_ENABLE);
> portstatus &= ~USB_PORT_STAT_ENABLE;
> } else {
> /* Pretend that power was lost for USB3 devs */
> portstatus &= ~USB_PORT_STAT_ENABLE;
> }
> }
>
> /* Clear status-change flags; we'll debounce later */
> if (portchange & USB_PORT_STAT_C_CONNECTION) {
> need_debounce_delay = true;
> clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_CONNECTION);
> }
> if (portchange & USB_PORT_STAT_C_ENABLE) {
> need_debounce_delay = true;
> clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_ENABLE);
> }
> if ((portchange & USB_PORT_STAT_C_BH_RESET) &&
> hub_is_superspeed(hub->hdev)) {
> need_debounce_delay = true;
> clear_port_feature(hub->hdev, port1,
> USB_PORT_FEAT_C_BH_PORT_RESET);
> }
> * if ( (portchange & USB_PORT_STAT_C_RESET)
> && hub_is_superspeed(hub->hdev)) {*
> * need_debounce_delay = true;*
> * clear_port_feature(hub->hdev, port1,*
> * USB_PORT_FEAT_C_RESET);*
> * }*
> *...*
> *....*
> }
>
> Please, let us know your inputs.
>
> Thanks & Regards,
> Ankit Patel
> Member Of Technical Staff-ASIC
> mob- +91 9099065690
> [email protected] | www.sibridgetech.com
>
>
>
>
> *An Innovative Solutions Provider*
>
> ASIC | FPGA | Design & Verification IPs | Embedded Solutions
>
>
>
> On Fri, Oct 26, 2012 at 11:03 AM, Ankit <[email protected]>wrote:
>
> > Hi Alan,
> >
> > Thanks for your response.
> >
> > We really thankful, if the patch gets submitted.
> >
> > As of now, we have put a condition as below in hub_activate(),
> >
> > for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
> > struct usb_device *udev = hdev->children[port1-1];
> > u16 portstatus, portchange;
> >
> > portstatus = portchange = 0;
> > status = hub_port_status(hub, port1, &portstatus, &portchange);
> >
> > if (portchange & USB_PORT_STAT_C_RESET){
> > dev_dbg(hub_dev, "reset change on port %d\n",i);
> > clear_port_feature(hdev, i, USB_PORT_FEAT_C_RESET);
> > }
> >
> >
> > One more thing, is it the same patch applied to the Compliance
> > Verification and Windows driver as well? If it will, then let us know
> > version number of Compliance Verification and Windows driver.
> >
> >
> > Regards,
> > Ankit Patel
> > Member Of Technical Staff-ASIC
> > mob- +91 9099065690
> > [email protected] | www.sibridgetech.com
> >
> >
> >
> >
> > *An Innovative Solutions Provider*
> >
> > ASIC | FPGA | Design & Verification IPs | Embedded Solutions
> >
> >
> >
> > On Thu, Oct 25, 2012 at 8:04 PM, Alan Stern
> > <[email protected]>wrote:
> >
> >> On Thu, 25 Oct 2012, Ankit wrote:
> >>
> >> > Hi Alan,
> >> >
> >> > Thanks for your response.
> >> >
> >> > Yes, there is a handling of PRC bit in xhci-hub.c
> >> >
> >> > Our query is, at the time of XHCI initialization (inserting xhci-hcd.ko
> >> and
> >> > no USB device is attached), is there PRC and CSC bits should be set?
> >> >
> >> > Our host controller sets PRC and CSC bits at the time of initialization,
> >> > even though no USB device is attached. At the time of initialization,
> >> > hub_probe() gets called and in-turn it calls hub_activate().
> >> hub_activate()
> >> > clears the CSC bit, but PRC bit does not get cleared (in linux 3.6.1).
> >> > hub_events() has functionality to clear the PRC bit, but initially
> >> there is
> >> > no events from HUB, so hub_events() may not clear the PRC bit. Due to
> >> this
> >> > behavior, when we try to insert a USB device, interrupt does not
> >> generate
> >> > (because, earlier, PRC bit was set and not cleared) and USB device does
> >> not
> >> > get enumerated.
> >> >
> >> > So, would you please tell us, what should be the behavior?
> >>
> >> I believe the hub driver needs to clear the USB_PORT_FEAT_C_RESET and
> >> USB_PORT_FEAT_C_OVERCURRENT features along with the other ones in
> >> hub_activate(). Would you like to submit a patch to do this?
> >>
> >> Alan Stern
> >>
> >>
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
