| Message ID | 1363338730-14581-9-git-send-email-balbi@ti.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 03/15/2013 03:12 AM, Felipe Balbi wrote: > PHY layer no longer returns NULL, we must > switch from IS_ERR_OR_NULL() to IS_ERR(). This change will definitely conflict with some Tegra EHCI/USB-PHY changes that Venu plans to submit very soon, for 3.10. This is relevant since we'd previously discussed you ack'ing Venu's patches, and my applying them to the Tegra tree, due to dependencies between the Tegra device tree files and his USB changes. To resolve this, we can do the following: 1) I will create a tiny topic branch containing just the Tegra DT changes that must happen before the USB driver changes. This can be based on v3.9-rc1 or similar, and be entirely self-contained. 2) You can merge that topic branch into your USB tree, so that the changes are present there. 3) I will merge that topic branch into the Tegra tree. (2) and (3) are both needed so that the exact same commit ID is present in each of our branches. It's needed in yours as a pre-cursor to Venu's changes. It's needed in Tegra's because I still hope to activate usage of the C pre-processor on the Tegra DT files, and that needs to build on top of the same DT change of Venu's that you also need. 4) Once you've done that, you can take Venu's USB patches through your USB tree rather than my applying them to the Tegra tree. This will allow you to resolve any conflicts between your changes and Venu's changes entirely within your branch simply by applying the patches one after the other. Nice and simple, and just like any other USB change. However, this goes against your statement that you "don't accept pull requests". Perhaps you can make an exception for this case? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Fri, Mar 15, 2013 at 03:12:08PM -0600, Stephen Warren wrote: > On 03/15/2013 03:12 AM, Felipe Balbi wrote: > > PHY layer no longer returns NULL, we must > > switch from IS_ERR_OR_NULL() to IS_ERR(). > > This change will definitely conflict with some Tegra EHCI/USB-PHY > changes that Venu plans to submit very soon, for 3.10. This is relevant but this is such a small change that, even if it conflicts, resolution will be trivial. > since we'd previously discussed you ack'ing Venu's patches, and my > applying them to the Tegra tree, due to dependencies between the Tegra > device tree files and his USB changes. > > To resolve this, we can do the following: > > 1) I will create a tiny topic branch containing just the Tegra DT > changes that must happen before the USB driver changes. This can be > based on v3.9-rc1 or similar, and be entirely self-contained. > > 2) You can merge that topic branch into your USB tree, so that the > changes are present there. > > 3) I will merge that topic branch into the Tegra tree. > > (2) and (3) are both needed so that the exact same commit ID is present > in each of our branches. It's needed in yours as a pre-cursor to Venu's > changes. It's needed in Tegra's because I still hope to activate usage > of the C pre-processor on the Tegra DT files, and that needs to build on > top of the same DT change of Venu's that you also need. > > 4) Once you've done that, you can take Venu's USB patches through your > USB tree rather than my applying them to the Tegra tree. This will allow > you to resolve any conflicts between your changes and Venu's changes > entirely within your branch simply by applying the patches one after the > other. Nice and simple, and just like any other USB change. > > However, this goes against your statement that you "don't accept pull > requests". Perhaps you can make an exception for this case? Greg won't like seeing merges from my pull request and I kinda agree with him. We can sort out the conflicts later. Greg ?
On 03/18/2013 02:02 AM, Felipe Balbi wrote: > Hi, > > On Fri, Mar 15, 2013 at 03:12:08PM -0600, Stephen Warren wrote: >> On 03/15/2013 03:12 AM, Felipe Balbi wrote: >>> PHY layer no longer returns NULL, we must switch from >>> IS_ERR_OR_NULL() to IS_ERR(). >> >> This change will definitely conflict with some Tegra >> EHCI/USB-PHY changes that Venu plans to submit very soon, for >> 3.10. This is relevant > > but this is such a small change that, even if it conflicts, > resolution will be trivial. Well, Venu's changes re-organize exactly the code you're modifying. Wouldn't it be simpler to simply take all the Tegra USB patches through the PHY tree and avoid any conflicts at all? >> since we'd previously discussed you ack'ing Venu's patches, and >> my applying them to the Tegra tree, due to dependencies between >> the Tegra device tree files and his USB changes. >> >> To resolve this, we can do the following: >> >> 1) I will create a tiny topic branch containing just the Tegra >> DT changes that must happen before the USB driver changes. This >> can be based on v3.9-rc1 or similar, and be entirely >> self-contained. >> >> 2) You can merge that topic branch into your USB tree, so that >> the changes are present there. >> >> 3) I will merge that topic branch into the Tegra tree. >> >> (2) and (3) are both needed so that the exact same commit ID is >> present in each of our branches. It's needed in yours as a >> pre-cursor to Venu's changes. It's needed in Tegra's because I >> still hope to activate usage of the C pre-processor on the Tegra >> DT files, and that needs to build on top of the same DT change of >> Venu's that you also need. >> >> 4) Once you've done that, you can take Venu's USB patches through >> your USB tree rather than my applying them to the Tegra tree. >> This will allow you to resolve any conflicts between your changes >> and Venu's changes entirely within your branch simply by applying >> the patches one after the other. Nice and simple, and just like >> any other USB change. >> >> However, this goes against your statement that you "don't accept >> pull requests". Perhaps you can make an exception for this case? > > Greg won't like seeing merges from my pull request and I kinda > agree with him. We can sort out the conflicts later. That seems odd. There are plenty of cases of merges in other trees. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 18, 2013 at 10:02:45AM +0200, Felipe Balbi wrote: > Hi, > > On Fri, Mar 15, 2013 at 03:12:08PM -0600, Stephen Warren wrote: > > On 03/15/2013 03:12 AM, Felipe Balbi wrote: > > > PHY layer no longer returns NULL, we must > > > switch from IS_ERR_OR_NULL() to IS_ERR(). > > > > This change will definitely conflict with some Tegra EHCI/USB-PHY > > changes that Venu plans to submit very soon, for 3.10. This is relevant > > but this is such a small change that, even if it conflicts, resolution > will be trivial. > > > since we'd previously discussed you ack'ing Venu's patches, and my > > applying them to the Tegra tree, due to dependencies between the Tegra > > device tree files and his USB changes. > > > > To resolve this, we can do the following: > > > > 1) I will create a tiny topic branch containing just the Tegra DT > > changes that must happen before the USB driver changes. This can be > > based on v3.9-rc1 or similar, and be entirely self-contained. > > > > 2) You can merge that topic branch into your USB tree, so that the > > changes are present there. > > > > 3) I will merge that topic branch into the Tegra tree. > > > > (2) and (3) are both needed so that the exact same commit ID is present > > in each of our branches. It's needed in yours as a pre-cursor to Venu's > > changes. It's needed in Tegra's because I still hope to activate usage > > of the C pre-processor on the Tegra DT files, and that needs to build on > > top of the same DT change of Venu's that you also need. > > > > 4) Once you've done that, you can take Venu's USB patches through your > > USB tree rather than my applying them to the Tegra tree. This will allow > > you to resolve any conflicts between your changes and Venu's changes > > entirely within your branch simply by applying the patches one after the > > other. Nice and simple, and just like any other USB change. > > > > However, this goes against your statement that you "don't accept pull > > requests". Perhaps you can make an exception for this case? > > Greg won't like seeing merges from my pull request and I kinda agree > with him. We can sort out the conflicts later. > > Greg ? Ick, what a mess. If you need to take patches for the Tegra stuff this way, I guess it can work out. I'll defer to you as to how you want to handle it. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 18, 2013 at 09:25:34AM -0600, Stephen Warren wrote: > On 03/18/2013 02:02 AM, Felipe Balbi wrote: > > Hi, > > > > On Fri, Mar 15, 2013 at 03:12:08PM -0600, Stephen Warren wrote: > >> On 03/15/2013 03:12 AM, Felipe Balbi wrote: > >>> PHY layer no longer returns NULL, we must switch from > >>> IS_ERR_OR_NULL() to IS_ERR(). > >> > >> This change will definitely conflict with some Tegra > >> EHCI/USB-PHY changes that Venu plans to submit very soon, for > >> 3.10. This is relevant > > > > but this is such a small change that, even if it conflicts, > > resolution will be trivial. > > Well, Venu's changes re-organize exactly the code you're modifying. > Wouldn't it be simpler to simply take all the Tegra USB patches > through the PHY tree and avoid any conflicts at all? alright, I will take all patches, so please create a very small immutable branch which I can merge then I'll take all other patches. Let's just try to avoid this sort of situation whenever possible. cheers
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c index fafbc81..1d2488c 100644 --- a/drivers/usb/host/ehci-tegra.c +++ b/drivers/usb/host/ehci-tegra.c @@ -768,14 +768,12 @@ static int tegra_ehci_probe(struct platform_device *pdev) goto fail; } -#if IS_ENABLED(CONFIG_USB_PHY) if (pdata->operating_mode == TEGRA_USB_OTG) { tegra->transceiver = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2); - if (!IS_ERR_OR_NULL(tegra->transceiver)) + if (!IS_ERR(tegra->transceiver)) otg_set_host(tegra->transceiver->otg, &hcd->self); } -#endif err = usb_add_hcd(hcd, irq, IRQF_SHARED); if (err) { @@ -794,10 +792,8 @@ static int tegra_ehci_probe(struct platform_device *pdev) return err; fail: -#if IS_ENABLED(CONFIG_USB_PHY) - if (!IS_ERR_OR_NULL(tegra->transceiver)) + if (!IS_ERR(tegra->transceiver)) otg_set_host(tegra->transceiver->otg, NULL); -#endif usb_phy_shutdown(hcd->phy); fail_io: clk_disable_unprepare(tegra->clk); @@ -815,10 +811,8 @@ static int tegra_ehci_remove(struct platform_device *pdev) pm_runtime_disable(&pdev->dev); pm_runtime_put_noidle(&pdev->dev); -#if IS_ENABLED(CONFIG_USB_PHY) - if (!IS_ERR_OR_NULL(tegra->transceiver)) + if (!IS_ERR(tegra->transceiver)) otg_set_host(tegra->transceiver->otg, NULL); -#endif usb_phy_shutdown(hcd->phy); usb_remove_hcd(hcd);
PHY layer no longer returns NULL, we must switch from IS_ERR_OR_NULL() to IS_ERR(). Signed-off-by: Felipe Balbi <balbi@ti.com> --- drivers/usb/host/ehci-tegra.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-)