> >> Use a meaningful name for the reference clocks so that it indicates the function.
> >>
> >> CC: Lee Jones <lee.jones@xxxxxxxxxx>
> >> CC: Samuel Ortiz <sameo@xxxxxxxxxxxxxxx>
> >> Signed-off-by: Roger Quadros <rogerq@xxxxxx>
> >> ---
> >> drivers/mfd/omap-usb-host.c | 12 ++++++------
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> >> index 865c276..651e249 100644
> >> --- a/drivers/mfd/omap-usb-host.c
> >> +++ b/drivers/mfd/omap-usb-host.c
> >> @@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device *pdev)
> >> goto err_mem;
> >> }
> >>
> >> - omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
> >> + omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
> >> if (IS_ERR(omap->xclk60mhsp1_ck)) {
> >> ret = PTR_ERR(omap->xclk60mhsp1_ck);
> >> - dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
> >> + dev_err(dev, "refclk_60m_ext_p1 failed error:%d\n", ret);
> >> goto err_mem;
> >> }
> >
> > Will anything break if I were to apply the MFD patches seperately?
> >
>
> Nothing will break for OMAP3, but OMAP4 USB host will break (e.g. Panda board).
> OMAP5 USB host was never working so it doesn't matter there.
>
> To make sure nothing breaks, we need at least these 2 patches to go in together with mfd changes.
>
> [PATCH v8 08/14] ARM: dts: omap4: Update omap-usb-host node
> [PATCH v8 09/14] ARM: dts: omap5: Update omap-usb-host node
>
> Any suggestions about how we can proceed?
Yes, unfortunately you have to squash each of the patches into one
patch. Applying a patch which breaks a build, then applying another one
immediately after which subsequently fixes the break is not an acceptable
way of working I'm afraid. What would happen if we were to fall into
the middle of the two patches when bisecting?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
