hi Mathias, thanks for reviewing these, 2015-02-18 16:47 GMT+08:00 Mathias Nyman <mathias.nyman@xxxxxxxxx>: > Hi > > This looks correct, but if you are still going to make a new series fixing > Felipe's comments then the following tiny nitpicks could be fixed as well. > > Otherwise > > Acked-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> > > Felipe, Do you want to take this series through your tree? > > On 17.02.2015 07:41, Sneeker Yeh wrote: >> >> +static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num) > > Either add a function description explaining something like "Late clearing of connect status. > Some quirky hardware will suspend the controller when CSC bit is cleared and leave URBs unhandled" > > Or change the function name to something like xhci_late_csc_clear_quirk() or xhci_deferred_csc_clear_quirk() > > Maybe the name should be changed anyways. > The "try to" makes it look like some non-blocking version of a csc clear function. hm...thanks...it totally make sense, i'd like to use xhci_deferred_csc_clear_quirk(), and will take it to my next patches. > >> +{ >> + int max_ports; >> + struct xhci_hcd *xhci = hcd_to_xhci(hcd); >> + __le32 __iomem **port_array; >> + u32 status; >> + >> + /* print debug info */ > > Remove this comment okay, i see. > >> + if (hcd->speed == HCD_USB3) { >> + max_ports = xhci->num_usb3_ports; >> + port_array = xhci->usb3_ports; >> + } else { >> + max_ports = xhci->num_usb2_ports; >> + port_array = xhci->usb2_ports; >> + } >> + >> + if (dev_port_num > max_ports) { >> + xhci_err(xhci, "%s() port number invalid", __func__); >> + return; >> + } >> + status = readl(port_array[dev_port_num - 1]); >> + >> + /* write 1 to clear */ > > Not really a helpful comment either, either remove or change to something like > "clearing the connect status bit will now immediately suspend these quirky controllers" okay, i got it , thanks. Much appreciate, Sneeker > > -Mathias -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html