Bin Liu <b-liu@xxxxxx> writes: > Hi Felipe, > > On 09/24/2015 03:37 AM, Hans de Goede wrote: >> Hi, >> >> On 23-09-15 22:59, Bin Liu wrote: >>> Hi, >>> >>> On 09/23/2015 02:53 PM, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 23-09-15 19:10, Bin Liu wrote: >>>>> Hi, >>>>> >>>>> On 09/22/2015 04:18 PM, Felipe Balbi wrote: >>>>>> On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 09/22/2015 09:40 AM, Felipe Balbi wrote: >>>>>>>> On Mon, Sep 21, 2015 at 10:50:56AM -0500, Bin Liu wrote: >>>>>>>>> Some USB phy drivers have different handling for the controller in >>>>>>>>> each >>>>>>>>> dr_mode. But the phy driver does not have visibility to the >>>>>>>>> dr_mode of >>>>>>>>> the controller. >>>>>>>>> >>>>>>>>> This adds an api to return the dr_mode of the controller which >>>>>>>>> associates the given phy node. >>>>>>>>> >>>>>>>>> Signed-off-by: Bin Liu <b-liu@xxxxxx> >>>>>>>> >>>>>>>> >>>>>>>> doesn't apply anymore. Probably because of Heikki's series which I >>>>>>>> just >>>>>>>> added to testing/next. >>>>>>>> >>>>>>>> Please rebase there. >>>>>>>> >>>>>>> I have to rewrite my patch. Before Heikki's patch >>>>>>> of_usb_get_dr_mode() takes >>>>>>> parameter 'struct *device_node', but now usb_get_dr_mode() takes >>>>>>> parameter >>>>>>> 'struct *device'. The logic in my patch iterates over of nodes, I am >>>>>>> not >>>>>>> sure how to get the 'struct *device' from a of node yet... >>>>>> >>>>>> okay. >>>>>> >>>>> There is no way to get the 'struct *device' to the controller in the >>>>> phy driver, because the controller device might not be registered yet >>>>> by the time the phy probe is called. >>>>> >>>>> So I have to put back the implementation of the removed >>>>> of_usb_get_dr_mode() into this new of_usb_get_dr_mode_by_phy() >>>>> function. Please let me know if this is acceptable then I will send >>>>> the v5. >>>> >>>> Sounds to me like it is better to revert the API change / removal of >>>> of_usb_get_dr_mode() >>>> as a separate patch and then stick with your v4 patch. >>> >>> +1 >> >> If you agree, then the best way to do this is probably to send a patch >> series with the actual revert + your v4 patch. Probably best to call >> that series v5. > > Since Heikki's patch is only in your testing/next branch, do you want to > just drop that patch and take my v4 patch, or you want me to send the > revert patch? I'm not sure that's the way we want to go. Heikki's patch is doing a cleanup which is necessary for the USB layer to be able to use device properties instead of relying exclusively on DT or PCI. Device properties is the unification of the two. Heikki, any comments -- balbi
Attachment:
signature.asc
Description: PGP signature
