Hi Kishon, On Fri, Feb 1, 2013 at 10:51 AM, kishon <kishon@xxxxxx> wrote: > Hi, > > > On Thursday 31 January 2013 09:08 PM, Felipe Balbi wrote: >> >> On Thu, Jan 31, 2013 at 09:00:37PM +0530, Vivek Gautam wrote: >>> >>> Hi Felipe, >>> >>> >>> On Thu, Jan 31, 2013 at 8:55 PM, Felipe Balbi <balbi@xxxxxx> wrote: >>>> >>>> Hi, >>>> >>>> On Thu, Jan 31, 2013 at 08:53:27PM +0530, Vivek Gautam wrote: >>>>>>> >>>>>>> Moreover, SoCs having multiple dwc3 controllers will have multiple >>>>>>> PHYs, which eventually be added using usb_add_phy_dev(), and not >>>>>>> using usb_add_phy(). So each dwc3 controller won't be able to >>>>>>> get PHYs by simply calling devm_usb_get_phy() also. >>>>>> >>>>>> >>>>>> No. We have added usb_get_phy_dev() for that purpose in the case of >>>>>> non-dt. >>>>>> I think, instead you can have a patch to use devm_usb_get_phy_dev() >>>>>> here and >>>>>> in exynos platform specific code use usb_bind_phy() to bind the phy >>>>>> and >>>>>> controller till you change it to dt. >>>>>> >>>>> >>>>> We have dt support for dwc3-exynos, in such case we should go ahead >>>>> with >>>>> of_platform_populate(), right ? >>>>> But if when i use of_platform_populate() i will not be able to set >>>>> dma_mask to dwc3->dev. :-( > > > You can do something like this > > static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32); > > static int dwc3_exynos_set_dmamask(struct device *dev, void *c) > { > dev->dma_mask = &dwc3_exynos_dma_mask; > > return 0; > } > > And in your probe after of_platform_populate, you can add > > device_for_each_child(&pdev->dev, NULL, dwc3_exynos_set_dmamask); > > Here pdev is the platform device of dwc3-exynos. By this way all the > children of dwc3-exynos will have dma_mask set to the required value. > Nice idea, thanks :-) hmm.. so i can patch this now, and get things working ;-) > I'm not sure if there is any other better way to achieve the same (without > patching of.c ;-)) > -- Thanks & Regards Vivek -- 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