* Re: regression(ti platforms): next-20140210 (ehci?) [not found] ` <52F8F77B.70605-l0cyMroinI0@public.gmane.org> @ 2014-02-10 17:50 ` Roger Quadros 2014-02-10 18:02 ` Nishanth Menon 2014-02-10 18:28 ` Kevin Hilman 0 siblings, 2 replies; 8+ messages in thread From: Roger Quadros @ 2014-02-10 17:50 UTC (permalink / raw) To: Nishanth Menon, linux-omap, linux-usb-u79uwXL29TY76Z2rM5mHXA, Balbi, Felipe Cc: linux-next-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org +devicetree On 02/10/2014 05:59 PM, Nishanth Menon wrote: > Hi, > > A quick note to report that I saw regression in today's next tag (logs > indicate around EHCI) boot on various TI platforms: > > Note: crane and sdp2430 are not expected to pass with > multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane > but USB is disabled there) > > next-20140210-multi_v7_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE > 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 > around ehci > > 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 > around ehci > > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT > 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK > around ehci > > 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM > 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 > around ehci > > 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ > around ehci I think the problem is that ehci-platform driver gets loaded instead of ehci-omap. In the DT node we have compatible ids for both. e.g. for omap4.dtsi usbhsehci: ehci@4a064c00 { compatible = "ti,ehci-omap", "usb-ehci"; reg = <0x4a064c00 0x400>; interrupt-parent = <&gic>; interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; }; Shouldn't ehci-omap driver be getting a higher priority than usb-ehci? A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms. cheers, -roger > > 12: sdp2430: Boot FAIL: expected (v6 platform) > 13: sdp3430: Boot FAIL: http://slexy.org/raw/s21cwW7PqH > around ehci > > 14: sdp4430: Boot PASS: http://slexy.org/raw/s2hL39Pyl9 > 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20UsDeuVB > TOTAL = 15 boards, Booted Boards = 7, No Boot boards = 8 > > next-20140207-multi_v7_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2yo795okf > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2TfAOi6XP > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21sKT3pFN > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21nCiNjAR > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21uEu69lC > 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s21SklkJs7 > 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s21aYZvPl7 > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot PASS: http://slexy.org/raw/s20soGBbYz > 10: ldp: Boot PASS: http://slexy.org/raw/s20lDIIwgN > 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2a5NWPUtE > 12: sdp2430: Boot FAIL: expected (v6 platform) > 13: sdp3430: Boot PASS: http://slexy.org/raw/s2osagMVWZ > 14: sdp4430: Boot PASS: http://slexy.org/raw/s2NxmpHFaW > 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2PMcXzAUP > TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 > > in comparison: > v3.14-rc2-multi_v7_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2NWCJQczI > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2566ZAl5d > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2msKg3ZQ9 > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2898HemYQ > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20ajDkVgM > 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s20YmD8SSG > 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2sXDV7x0T > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot PASS: http://slexy.org/raw/s21Zz8NJrj > 10: ldp: Boot PASS: http://slexy.org/raw/s21NANMvTx > 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s20NER4paD > 12: sdp2430: Boot FAIL: expected (v6 platform) > 13: sdp3430: Boot PASS: http://slexy.org/raw/s2WCHUl033 > 14: sdp4430: Boot PASS: http://slexy.org/raw/s21ySru6J1 > 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2kztuFoSu > TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: regression(ti platforms): next-20140210 (ehci?) 2014-02-10 17:50 ` regression(ti platforms): next-20140210 (ehci?) Roger Quadros @ 2014-02-10 18:02 ` Nishanth Menon 2014-02-10 18:16 ` Roger Quadros 2014-02-10 18:28 ` Kevin Hilman 1 sibling, 1 reply; 8+ messages in thread From: Nishanth Menon @ 2014-02-10 18:02 UTC (permalink / raw) To: Roger Quadros, linux-omap, linux-usb, Balbi, Felipe Cc: linux-next, devicetree@vger.kernel.org, tony@atomide.com On 02/10/2014 11:50 AM, Roger Quadros wrote: > +devicetree > [...] > In the DT node we have compatible ids for both. e.g. for omap4.dtsi > > usbhsehci: ehci@4a064c00 { > compatible = "ti,ehci-omap", "usb-ehci"; > reg = <0x4a064c00 0x400>; > interrupt-parent = <&gic>; > interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; > }; > > Shouldn't ehci-omap driver be getting a higher priority than usb-ehci? > > A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms. If the driver is not compatible with "usb-ehci", not sure why do we even state that in dts node? -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: regression(ti platforms): next-20140210 (ehci?) 2014-02-10 18:02 ` Nishanth Menon @ 2014-02-10 18:16 ` Roger Quadros 0 siblings, 0 replies; 8+ messages in thread From: Roger Quadros @ 2014-02-10 18:16 UTC (permalink / raw) To: Nishanth Menon, linux-omap, linux-usb, Balbi, Felipe Cc: linux-next, devicetree@vger.kernel.org, tony@atomide.com On 02/10/2014 08:02 PM, Nishanth Menon wrote: > On 02/10/2014 11:50 AM, Roger Quadros wrote: >> +devicetree >> > [...] >> In the DT node we have compatible ids for both. e.g. for omap4.dtsi >> >> usbhsehci: ehci@4a064c00 { >> compatible = "ti,ehci-omap", "usb-ehci"; >> reg = <0x4a064c00 0x400>; >> interrupt-parent = <&gic>; >> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; >> }; >> >> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci? >> >> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms. > > If the driver is not compatible with "usb-ehci", not sure why do we > even state that in dts node? > > I'm not sure either. Let's get rid of it. Patch to fix the reported issue. http://article.gmane.org/gmane.linux.drivers.devicetree/61204 cheers, -roger ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: regression(ti platforms): next-20140210 (ehci?) 2014-02-10 17:50 ` regression(ti platforms): next-20140210 (ehci?) Roger Quadros 2014-02-10 18:02 ` Nishanth Menon @ 2014-02-10 18:28 ` Kevin Hilman 2014-02-10 19:33 ` Nishanth Menon 1 sibling, 1 reply; 8+ messages in thread From: Kevin Hilman @ 2014-02-10 18:28 UTC (permalink / raw) To: Roger Quadros Cc: Nishanth Menon, linux-omap, linux-usb, Balbi, Felipe, linux-next, devicetree@vger.kernel.org, tony@atomide.com Roger Quadros <rogerq@ti.com> writes: > +devicetree > > On 02/10/2014 05:59 PM, Nishanth Menon wrote: >> Hi, >> >> A quick note to report that I saw regression in today's next tag (logs >> indicate around EHCI) boot on various TI platforms: >> >> Note: crane and sdp2430 are not expected to pass with >> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane >> but USB is disabled there) >> >> next-20140210-multi_v7_defconfig >> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 >> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE >> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 >> around ehci >> >> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 >> around ehci >> >> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT >> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK >> around ehci >> >> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 >> 8: crane: No Image built - Missing platform support?: >> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM >> 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 >> around ehci >> >> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ >> around ehci > > I think the problem is that ehci-platform driver gets loaded instead of ehci-omap. > > In the DT node we have compatible ids for both. e.g. for omap4.dtsi > > usbhsehci: ehci@4a064c00 { > compatible = "ti,ehci-omap", "usb-ehci"; > reg = <0x4a064c00 0x400>; > interrupt-parent = <&gic>; > interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; > }; > > Shouldn't ehci-omap driver be getting a higher priority than usb-ehci? > > A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms. I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes fixed the problem for me on 3530/overo, 3730/beagle-xM and 4460/panda-es. But I don't think that's the right fix. First we have to figure out why ehci-omap stopped getting loaded first. Kevin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: regression(ti platforms): next-20140210 (ehci?) 2014-02-10 18:28 ` Kevin Hilman @ 2014-02-10 19:33 ` Nishanth Menon 2014-02-11 1:07 ` Kevin Hilman 0 siblings, 1 reply; 8+ messages in thread From: Nishanth Menon @ 2014-02-10 19:33 UTC (permalink / raw) To: Kevin Hilman, Roger Quadros Cc: linux-omap, linux-usb, Balbi, Felipe, linux-next, devicetree@vger.kernel.org, tony@atomide.com On 02/10/2014 12:28 PM, Kevin Hilman wrote: > Roger Quadros <rogerq@ti.com> writes: > >> +devicetree >> >> On 02/10/2014 05:59 PM, Nishanth Menon wrote: >>> Hi, >>> >>> A quick note to report that I saw regression in today's next tag (logs >>> indicate around EHCI) boot on various TI platforms: >>> >>> Note: crane and sdp2430 are not expected to pass with >>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane >>> but USB is disabled there) >>> >>> next-20140210-multi_v7_defconfig >>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 >>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE >>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 >>> around ehci >>> >>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 >>> around ehci >>> >>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT >>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK >>> around ehci >>> >>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 >>> 8: crane: No Image built - Missing platform support?: >>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM >>> 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 >>> around ehci >>> >>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ >>> around ehci >> >> I think the problem is that ehci-platform driver gets loaded instead of ehci-omap. >> >> In the DT node we have compatible ids for both. e.g. for omap4.dtsi >> >> usbhsehci: ehci@4a064c00 { >> compatible = "ti,ehci-omap", "usb-ehci"; >> reg = <0x4a064c00 0x400>; >> interrupt-parent = <&gic>; >> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; >> }; >> >> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci? >> >> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms. > > I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes > fixed the problem for me on 3530/overo, 3730/beagle-xM and > 4460/panda-es. But I don't think that's the right fix. First we have > to figure out why ehci-omap stopped getting loaded first. Wont that depend on driver probe order? of_match_device is fairly simple compatible walk through without looking at other drivers which might also be compatible, but not yet probed? The issue started I think with the following patch getting merged: ehci-platform: Add support for clks and phy passed through devicetree some version of http://www.spinics.net/lists/linux-usb/msg101061.html introduced { .compatible = "usb-ehci", }, Now, in the build we have two drivers which dts claims compatibility with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c) for the platform. Thinking that way, in fact, the current compatibility even matches drivers/usb/host/ehci-ppc-of.c which obviously wont work either. -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: regression(ti platforms): next-20140210 (ehci?) 2014-02-10 19:33 ` Nishanth Menon @ 2014-02-11 1:07 ` Kevin Hilman 2014-02-11 13:27 ` Nishanth Menon [not found] ` <7h38jq8nk9.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org> 0 siblings, 2 replies; 8+ messages in thread From: Kevin Hilman @ 2014-02-11 1:07 UTC (permalink / raw) To: Nishanth Menon Cc: Roger Quadros, linux-omap, linux-usb, Balbi, Felipe, linux-next, devicetree@vger.kernel.org, tony@atomide.com Nishanth Menon <nm@ti.com> writes: > On 02/10/2014 12:28 PM, Kevin Hilman wrote: >> Roger Quadros <rogerq@ti.com> writes: >> >>> +devicetree >>> >>> On 02/10/2014 05:59 PM, Nishanth Menon wrote: >>>> Hi, >>>> >>>> A quick note to report that I saw regression in today's next tag (logs >>>> indicate around EHCI) boot on various TI platforms: >>>> >>>> Note: crane and sdp2430 are not expected to pass with >>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane >>>> but USB is disabled there) >>>> >>>> next-20140210-multi_v7_defconfig >>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 >>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE >>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 >>>> around ehci >>>> >>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 >>>> around ehci >>>> >>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT >>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK >>>> around ehci >>>> >>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 >>>> 8: crane: No Image built - Missing platform support?: >>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM >>>> 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 >>>> around ehci >>>> >>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ >>>> around ehci >>> >>> I think the problem is that ehci-platform driver gets loaded instead of ehci-omap. >>> >>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi >>> >>> usbhsehci: ehci@4a064c00 { >>> compatible = "ti,ehci-omap", "usb-ehci"; >>> reg = <0x4a064c00 0x400>; >>> interrupt-parent = <&gic>; >>> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; >>> }; >>> >>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci? >>> >>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms. >> >> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes >> fixed the problem for me on 3530/overo, 3730/beagle-xM and >> 4460/panda-es. But I don't think that's the right fix. First we have >> to figure out why ehci-omap stopped getting loaded first. > > Wont that depend on driver probe order? of_match_device is fairly > simple compatible walk through without looking at other drivers which > might also be compatible, but not yet probed? > > The issue started I think with the following patch getting merged: > ehci-platform: Add support for clks and phy passed through devicetree > some version of http://www.spinics.net/lists/linux-usb/msg101061.html > introduced { .compatible = "usb-ehci", }, This is what I was getting at: an understanding of what caused the failue in the first place. > Now, in the build we have two drivers which dts claims compatibility > with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c) > for the platform. Thinking that way, in fact, the current > compatibility even matches drivers/usb/host/ehci-ppc-of.c which > obviously wont work either. Right, so I agree that it makes sense to remove a compatible string where there is no compatability, but a couple other things should happen here. 1) changelog should describe why this compatible string is in the omap dtsi files in first place. 2) investigation into the patch that introduced this change to double check it's not introducing other breakage as well. Kevin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: regression(ti platforms): next-20140210 (ehci?) 2014-02-11 1:07 ` Kevin Hilman @ 2014-02-11 13:27 ` Nishanth Menon [not found] ` <7h38jq8nk9.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org> 1 sibling, 0 replies; 8+ messages in thread From: Nishanth Menon @ 2014-02-11 13:27 UTC (permalink / raw) To: Kevin Hilman Cc: Roger Quadros, linux-omap, linux-usb, Balbi, Felipe, linux-next, devicetree@vger.kernel.org, tony@atomide.com On 02/10/2014 07:07 PM, Kevin Hilman wrote: > Nishanth Menon <nm@ti.com> writes: > >> On 02/10/2014 12:28 PM, Kevin Hilman wrote: >>> Roger Quadros <rogerq@ti.com> writes: >>> >>>> +devicetree >>>> >>>> On 02/10/2014 05:59 PM, Nishanth Menon wrote: >>>>> Hi, >>>>> >>>>> A quick note to report that I saw regression in today's next tag (logs >>>>> indicate around EHCI) boot on various TI platforms: >>>>> >>>>> Note: crane and sdp2430 are not expected to pass with >>>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane >>>>> but USB is disabled there) >>>>> >>>>> next-20140210-multi_v7_defconfig >>>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94 >>>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE >>>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1 >>>>> around ehci >>>>> >>>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7 >>>>> around ehci >>>>> >>>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT >>>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK >>>>> around ehci >>>>> >>>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7 >>>>> 8: crane: No Image built - Missing platform support?: >>>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM >>>>> 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23 >>>>> around ehci >>>>> >>>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ >>>>> around ehci >>>> >>>> I think the problem is that ehci-platform driver gets loaded instead of ehci-omap. >>>> >>>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi >>>> >>>> usbhsehci: ehci@4a064c00 { >>>> compatible = "ti,ehci-omap", "usb-ehci"; >>>> reg = <0x4a064c00 0x400>; >>>> interrupt-parent = <&gic>; >>>> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>; >>>> }; >>>> >>>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci? >>>> >>>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms. >>> >>> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes >>> fixed the problem for me on 3530/overo, 3730/beagle-xM and >>> 4460/panda-es. But I don't think that's the right fix. First we have >>> to figure out why ehci-omap stopped getting loaded first. >> >> Wont that depend on driver probe order? of_match_device is fairly >> simple compatible walk through without looking at other drivers which >> might also be compatible, but not yet probed? >> >> The issue started I think with the following patch getting merged: >> ehci-platform: Add support for clks and phy passed through devicetree >> some version of http://www.spinics.net/lists/linux-usb/msg101061.html >> introduced { .compatible = "usb-ehci", }, > > This is what I was getting at: an understanding of what caused the > failue in the first place. > >> Now, in the build we have two drivers which dts claims compatibility >> with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c) >> for the platform. Thinking that way, in fact, the current >> compatibility even matches drivers/usb/host/ehci-ppc-of.c which >> obviously wont work either. > > Right, so I agree that it makes sense to remove a compatible string > where there is no compatability, but a couple other things should happen > here. > > 1) changelog should describe why this compatible string is in the omap > dtsi files in first place. > Agreed: I had commented the same on https://patchwork.kernel.org/patch/3621811/ > 2) investigation into the patch that introduced this change to double > check it's not introducing other breakage as well. discussion is now on the relevant patch generating the break: http://marc.info/?t=139178752000003&r=1&w=2 -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <7h38jq8nk9.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org>]
* Re: regression(ti platforms): next-20140210 (ehci?) [not found] ` <7h38jq8nk9.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org> @ 2014-02-11 15:21 ` Alan Stern 0 siblings, 0 replies; 8+ messages in thread From: Alan Stern @ 2014-02-11 15:21 UTC (permalink / raw) To: Kevin Hilman Cc: Nishanth Menon, Roger Quadros, linux-omap, linux-usb-u79uwXL29TY76Z2rM5mHXA, Balbi, Felipe, linux-next-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org On Mon, 10 Feb 2014, Kevin Hilman wrote: > > The issue started I think with the following patch getting merged: > > ehci-platform: Add support for clks and phy passed through devicetree > > some version of http://www.spinics.net/lists/linux-usb/msg101061.html > > introduced { .compatible = "usb-ehci", }, > > This is what I was getting at: an understanding of what caused the > failue in the first place. > > > Now, in the build we have two drivers which dts claims compatibility > > with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c) > > for the platform. Thinking that way, in fact, the current > > compatibility even matches drivers/usb/host/ehci-ppc-of.c which > > obviously wont work either. > > Right, so I agree that it makes sense to remove a compatible string > where there is no compatability, but a couple other things should happen > here. > > 1) changelog should describe why this compatible string is in the omap > dtsi files in first place. > > 2) investigation into the patch that introduced this change to double > check it's not introducing other breakage as well. Oddly enough, it was Roger who introduced this incorrect compatibility string in commit f17c89948dcd6 (ARM: dts: OMAP4: Add HS USB Host IP nodes). There is no explanation in the commit log of why the string is there. We better remove it from all the files where it doesn't belong. Of course, this won't help existing hardware. It will still be necessary to change the compatibility string used for the generic platform drivers. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-02-11 15:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <52F8F77B.70605@ti.com>
[not found] ` <52F8F77B.70605-l0cyMroinI0@public.gmane.org>
2014-02-10 17:50 ` regression(ti platforms): next-20140210 (ehci?) Roger Quadros
2014-02-10 18:02 ` Nishanth Menon
2014-02-10 18:16 ` Roger Quadros
2014-02-10 18:28 ` Kevin Hilman
2014-02-10 19:33 ` Nishanth Menon
2014-02-11 1:07 ` Kevin Hilman
2014-02-11 13:27 ` Nishanth Menon
[not found] ` <7h38jq8nk9.fsf-4poPxKt068f/PtFMR13I2A@public.gmane.org>
2014-02-11 15:21 ` Alan Stern
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).