Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Tue, Dec 13, 2016 at 2:34 PM, Hans Verkuil wrote: > Try again, this time with Krzysztof's new email address... > > > On 13/12/16 13:20, Hans Verkuil wrote: >> >> Hi Krzysztof, >> >> This still seems to be broken with the latest 4.9 kernel, right? >> >> Has there been any progress on this? Do you have an updated patch series >> for me to use? Hi, I think it is not fixed. Still. I left this work to others. AFAIK, Peter Chen is working on a new generic approach: https://lwn.net/Articles/703556/ On top of his patchset, Odroid would need some DTS code as well (and maybe something in usb3503). However I do not plan to work on this anymore as I do not have Odroid U3 anymore. Marek and Bartlomiej from Samsung Poland are in CC-list so maybe they would like to continue the work? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
Try again, this time with Krzysztof's new email address... On 13/12/16 13:20, Hans Verkuil wrote: Hi Krzysztof, This still seems to be broken with the latest 4.9 kernel, right? Has there been any progress on this? Do you have an updated patch series for me to use? Regards, Hans On 05/05/16 14:34, Krzysztof Kozlowski wrote: Hi, This is a different, second try to fix usb3503+lan on Odroid U3 board if it was initialized by bootloader (e.g. for TFTP boot). First version: http://www.spinics.net/lists/linux-usb/msg140042.html Problem === When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset is required, e.g. by suspend to RAM. The actual TFTP boot does not have to happen. Just "usb start" from U-Boot is sufficient. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
Hi Krzysztof, This still seems to be broken with the latest 4.9 kernel, right? Has there been any progress on this? Do you have an updated patch series for me to use? Regards, Hans On 05/05/16 14:34, Krzysztof Kozlowski wrote: Hi, This is a different, second try to fix usb3503+lan on Odroid U3 board if it was initialized by bootloader (e.g. for TFTP boot). First version: http://www.spinics.net/lists/linux-usb/msg140042.html Problem === When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset is required, e.g. by suspend to RAM. The actual TFTP boot does not have to happen. Just "usb start" from U-Boot is sufficient. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On 05/31/2016 02:58 AM, Peter Chen wrote: > On Sat, May 28, 2016 at 11:36:13AM +0800, Peter Chen wrote: >> All, how we move on for this? >> >> 1. Using a generic driver to manage both mmc and USB (and further >> subsystem), USB and further subsystem do not use pwrseq node in dts. >> 2. USB creates the similar driver under drivers/usb for its own use. >> >> Which one do you prefer, thanks. >> > > Hi Krzysztof Kozlowski, > > I think option 1 may be better according to Rob and Ulf's comment. Hi, I like the option #1 as well. The generic driver should rely and parse existing bindings like 'reset-gpios'. Still additional property (e.g. "do-the-power-sequence") seems needed as we do not want to play with all reset-gpios in DTB. > Would you like going on your patch set? You can work on generic pwrseq > driver, I will do USB stuffs based on generic pwrseq driver? Great, that sounds good! I'll start the work. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Sat, May 28, 2016 at 11:36:13AM +0800, Peter Chen wrote: > On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote: > > + Arnd > > > > [...] > > > > >> >> Solution > > >> >> > > >> >> This is very similar to the MMC pwrseq behavior so the idea is to: > > >> >> 1. Move MMC pwrseq drivers to generic place, > > >> > > > >> > You can do that, but I'm going to NAK any use of pwrseq bindings > > >> > outside > > >> > of MMC. I think it is the wrong way to do things. The DT should > > >> > describe > > >> > > >> Huh, I didn't know that was your view of the mmc pwrseq bindings. Why > > >> didn't you NAK them before? > > > > > > Unfortunately, either I missed it or it was a time I couldn't spend much > > > time on reviews. > > > > Okay, I guess it's common issue among maintainers. The problem with DT > > is that it gets really hard to be fixed up later. :-) > > > > > > > >> > the devices. If they happen to be "simple" then the core can walk the > > >> > tree and do any setup. For example, look for "reset-gpios" and toggle > > >> > that GPIO. There is no need for a special node. > > >> > > > >> >> 2. Extend the pwrseq-simple with regulator toggling, > > >> >> 3. Add support to USB hub and port core for pwrseq, > > >> > > > >> > We discussed this for USB already[1] and is why we defined how to add > > >> > USB child devices. The idea is not to add pwrseq to that. > > >> > > >> I am not familiar with the USB discussion. > > >> > > >> Still, let me give you some more background to the mmc pwrseq. The > > >> idea from the mmc pwrseq bindings comes from the power-domain DT > > >> bindings, as I thought these things were a bit related. > > >> In both cases they are not directly a property of the device, but more > > >> describing a HW dependency to allow the device to work. > > > > > > I could see this as a board level power domain. However the difference > > > is we are not generally exposing internal SOC details the same way as > > > board level components. Perhaps we could extend power domains to board > > > level, but that is not what was done here. > > > > > >> One could probably use a child node instead of a phandle, but that > > >> wasn't chosen back then. Of course you are the DT expert, but could > > >> you perhaps tell me why a child node is better for cases like this? > > > > > > If there is a control path hierarchy, then we try to model that in DT > > > with child nodes. In cases of SDIO and USB, there is a clear hierarchy. > > > Ignoring the discovery ordering problem, we already have defined ways to > > > describe GPIO connections, regulators, etc. to devices. Describing those > > > things separately from the device to solve a particular issue that is > > > really a kernel limitation is what I don't like. > > > > Okay, I see. > > > > To move forward in trying to make mmc pwrseq a generic pwrseq, could > > we perhaps allow both cases? > > > > In the mmc case, there are already deployed bindings so we need to > > cope with these by using the phandle option, but for USB etc we could > > force the child node option. > > As long as we agree that we keep using a compatible string for the > > child node as well, both options should be able to co-exist and we > > should probably be able to managed them both from a common pwrseq > > driver framework. > > > > Although, I do remember from an older conversations around some of > > mine submission for the mmc pwrseq code, that some people (maybe > > Arnd?) wasn't keen on adding a new framework for this. Perhaps that > > has changed? > > > > All, how we move on for this? > > 1. Using a generic driver to manage both mmc and USB (and further > subsystem), USB and further subsystem do not use pwrseq node in dts. > 2. USB creates the similar driver under drivers/usb for its own use. > > Which one do you prefer, thanks. > Hi Krzysztof Kozlowski, I think option 1 may be better according to Rob and Ulf's comment. Would you like going on your patch set? You can work on generic pwrseq driver, I will do USB stuffs based on generic pwrseq driver? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote: > + Arnd > > [...] > > >> >> Solution > >> >> > >> >> This is very similar to the MMC pwrseq behavior so the idea is to: > >> >> 1. Move MMC pwrseq drivers to generic place, > >> > > >> > You can do that, but I'm going to NAK any use of pwrseq bindings outside > >> > of MMC. I think it is the wrong way to do things. The DT should describe > >> > >> Huh, I didn't know that was your view of the mmc pwrseq bindings. Why > >> didn't you NAK them before? > > > > Unfortunately, either I missed it or it was a time I couldn't spend much > > time on reviews. > > Okay, I guess it's common issue among maintainers. The problem with DT > is that it gets really hard to be fixed up later. :-) > > > > >> > the devices. If they happen to be "simple" then the core can walk the > >> > tree and do any setup. For example, look for "reset-gpios" and toggle > >> > that GPIO. There is no need for a special node. > >> > > >> >> 2. Extend the pwrseq-simple with regulator toggling, > >> >> 3. Add support to USB hub and port core for pwrseq, > >> > > >> > We discussed this for USB already[1] and is why we defined how to add > >> > USB child devices. The idea is not to add pwrseq to that. > >> > >> I am not familiar with the USB discussion. > >> > >> Still, let me give you some more background to the mmc pwrseq. The > >> idea from the mmc pwrseq bindings comes from the power-domain DT > >> bindings, as I thought these things were a bit related. > >> In both cases they are not directly a property of the device, but more > >> describing a HW dependency to allow the device to work. > > > > I could see this as a board level power domain. However the difference > > is we are not generally exposing internal SOC details the same way as > > board level components. Perhaps we could extend power domains to board > > level, but that is not what was done here. > > > >> One could probably use a child node instead of a phandle, but that > >> wasn't chosen back then. Of course you are the DT expert, but could > >> you perhaps tell me why a child node is better for cases like this? > > > > If there is a control path hierarchy, then we try to model that in DT > > with child nodes. In cases of SDIO and USB, there is a clear hierarchy. > > Ignoring the discovery ordering problem, we already have defined ways to > > describe GPIO connections, regulators, etc. to devices. Describing those > > things separately from the device to solve a particular issue that is > > really a kernel limitation is what I don't like. > > Okay, I see. > > To move forward in trying to make mmc pwrseq a generic pwrseq, could > we perhaps allow both cases? > > In the mmc case, there are already deployed bindings so we need to > cope with these by using the phandle option, but for USB etc we could > force the child node option. > As long as we agree that we keep using a compatible string for the > child node as well, both options should be able to co-exist and we > should probably be able to managed them both from a common pwrseq > driver framework. > > Although, I do remember from an older conversations around some of > mine submission for the mmc pwrseq code, that some people (maybe > Arnd?) wasn't keen on adding a new framework for this. Perhaps that > has changed? > All, how we move on for this? 1. Using a generic driver to manage both mmc and USB (and further subsystem), USB and further subsystem do not use pwrseq node in dts. 2. USB creates the similar driver under drivers/usb for its own use. Which one do you prefer, thanks. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
+ Arnd [...] >> >> Solution >> >> >> >> This is very similar to the MMC pwrseq behavior so the idea is to: >> >> 1. Move MMC pwrseq drivers to generic place, >> > >> > You can do that, but I'm going to NAK any use of pwrseq bindings outside >> > of MMC. I think it is the wrong way to do things. The DT should describe >> >> Huh, I didn't know that was your view of the mmc pwrseq bindings. Why >> didn't you NAK them before? > > Unfortunately, either I missed it or it was a time I couldn't spend much > time on reviews. Okay, I guess it's common issue among maintainers. The problem with DT is that it gets really hard to be fixed up later. :-) > >> > the devices. If they happen to be "simple" then the core can walk the >> > tree and do any setup. For example, look for "reset-gpios" and toggle >> > that GPIO. There is no need for a special node. >> > >> >> 2. Extend the pwrseq-simple with regulator toggling, >> >> 3. Add support to USB hub and port core for pwrseq, >> > >> > We discussed this for USB already[1] and is why we defined how to add >> > USB child devices. The idea is not to add pwrseq to that. >> >> I am not familiar with the USB discussion. >> >> Still, let me give you some more background to the mmc pwrseq. The >> idea from the mmc pwrseq bindings comes from the power-domain DT >> bindings, as I thought these things were a bit related. >> In both cases they are not directly a property of the device, but more >> describing a HW dependency to allow the device to work. > > I could see this as a board level power domain. However the difference > is we are not generally exposing internal SOC details the same way as > board level components. Perhaps we could extend power domains to board > level, but that is not what was done here. > >> One could probably use a child node instead of a phandle, but that >> wasn't chosen back then. Of course you are the DT expert, but could >> you perhaps tell me why a child node is better for cases like this? > > If there is a control path hierarchy, then we try to model that in DT > with child nodes. In cases of SDIO and USB, there is a clear hierarchy. > Ignoring the discovery ordering problem, we already have defined ways to > describe GPIO connections, regulators, etc. to devices. Describing those > things separately from the device to solve a particular issue that is > really a kernel limitation is what I don't like. Okay, I see. To move forward in trying to make mmc pwrseq a generic pwrseq, could we perhaps allow both cases? In the mmc case, there are already deployed bindings so we need to cope with these by using the phandle option, but for USB etc we could force the child node option. As long as we agree that we keep using a compatible string for the child node as well, both options should be able to co-exist and we should probably be able to managed them both from a common pwrseq driver framework. Although, I do remember from an older conversations around some of mine submission for the mmc pwrseq code, that some people (maybe Arnd?) wasn't keen on adding a new framework for this. Perhaps that has changed? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Mon, May 09, 2016 at 09:46:40AM +0200, Ulf Hansson wrote: > On 6 May 2016 at 00:42, Rob Herring wrote: > > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > >> Hi, > >> > >> This is a different, second try to fix usb3503+lan on Odroid U3 board > >> if it was initialized by bootloader (e.g. for TFTP boot). > >> > >> First version: > >> http://www.spinics.net/lists/linux-usb/msg140042.html > >> > >> > >> Problem > >> === > >> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), > >> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset > >> is required, e.g. by suspend to RAM. The actual TFTP boot does > >> not have to happen. Just "usb start" from U-Boot is sufficient. > >> > >> From the schematics, the regulator is a supply only to LAN, however > >> without toggling it off/on, the usb3503 hub won appear neither. > >> > >> > >> Solution > >> > >> This is very similar to the MMC pwrseq behavior so the idea is to: > >> 1. Move MMC pwrseq drivers to generic place, > > > > You can do that, but I'm going to NAK any use of pwrseq bindings outside > > of MMC. I think it is the wrong way to do things. The DT should describe > > Huh, I didn't know that was your view of the mmc pwrseq bindings. Why > didn't you NAK them before? Unfortunately, either I missed it or it was a time I couldn't spend much time on reviews. > > the devices. If they happen to be "simple" then the core can walk the > > tree and do any setup. For example, look for "reset-gpios" and toggle > > that GPIO. There is no need for a special node. > > > >> 2. Extend the pwrseq-simple with regulator toggling, > >> 3. Add support to USB hub and port core for pwrseq, > > > > We discussed this for USB already[1] and is why we defined how to add > > USB child devices. The idea is not to add pwrseq to that. > > I am not familiar with the USB discussion. > > Still, let me give you some more background to the mmc pwrseq. The > idea from the mmc pwrseq bindings comes from the power-domain DT > bindings, as I thought these things were a bit related. > In both cases they are not directly a property of the device, but more > describing a HW dependency to allow the device to work. I could see this as a board level power domain. However the difference is we are not generally exposing internal SOC details the same way as board level components. Perhaps we could extend power domains to board level, but that is not what was done here. > One could probably use a child node instead of a phandle, but that > wasn't chosen back then. Of course you are the DT expert, but could > you perhaps tell me why a child node is better for cases like this? If there is a control path hierarchy, then we try to model that in DT with child nodes. In cases of SDIO and USB, there is a clear hierarchy. Ignoring the discovery ordering problem, we already have defined ways to describe GPIO connections, regulators, etc. to devices. Describing those things separately from the device to solve a particular issue that is really a kernel limitation is what I don't like. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On 6 May 2016 at 00:42, Rob Herring wrote: > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >> Hi, >> >> This is a different, second try to fix usb3503+lan on Odroid U3 board >> if it was initialized by bootloader (e.g. for TFTP boot). >> >> First version: >> http://www.spinics.net/lists/linux-usb/msg140042.html >> >> >> Problem >> === >> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), >> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset >> is required, e.g. by suspend to RAM. The actual TFTP boot does >> not have to happen. Just "usb start" from U-Boot is sufficient. >> >> From the schematics, the regulator is a supply only to LAN, however >> without toggling it off/on, the usb3503 hub won appear neither. >> >> >> Solution >> >> This is very similar to the MMC pwrseq behavior so the idea is to: >> 1. Move MMC pwrseq drivers to generic place, > > You can do that, but I'm going to NAK any use of pwrseq bindings outside > of MMC. I think it is the wrong way to do things. The DT should describe Huh, I didn't know that was your view of the mmc pwrseq bindings. Why didn't you NAK them before? > the devices. If they happen to be "simple" then the core can walk the > tree and do any setup. For example, look for "reset-gpios" and toggle > that GPIO. There is no need for a special node. > >> 2. Extend the pwrseq-simple with regulator toggling, >> 3. Add support to USB hub and port core for pwrseq, > > We discussed this for USB already[1] and is why we defined how to add > USB child devices. The idea is not to add pwrseq to that. I am not familiar with the USB discussion. Still, let me give you some more background to the mmc pwrseq. The idea from the mmc pwrseq bindings comes from the power-domain DT bindings, as I thought these things were a bit related. In both cases they are not directly a property of the device, but more describing a HW dependency to allow the device to work. One could probably use a child node instead of a phandle, but that wasn't chosen back then. Of course you are the DT expert, but could you perhaps tell me why a child node is better for cases like this? > > Rob > > [1] http://www.spinics.net/lists/linux-usb/msg134082.html Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Fri, May 6, 2016 at 1:10 AM, Krzysztof Kozlowski wrote: > On 05/06/2016 12:42 AM, Rob Herring wrote: >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >>> Hi, >>> >>> This is a different, second try to fix usb3503+lan on Odroid U3 board >>> if it was initialized by bootloader (e.g. for TFTP boot). >>> >>> First version: >>> http://www.spinics.net/lists/linux-usb/msg140042.html >>> >>> >>> Problem >>> === >>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), >>> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset >>> is required, e.g. by suspend to RAM. The actual TFTP boot does >>> not have to happen. Just "usb start" from U-Boot is sufficient. >>> >>> From the schematics, the regulator is a supply only to LAN, however >>> without toggling it off/on, the usb3503 hub won appear neither. >>> >>> >>> Solution >>> >>> This is very similar to the MMC pwrseq behavior so the idea is to: >>> 1. Move MMC pwrseq drivers to generic place, >> >> You can do that, but I'm going to NAK any use of pwrseq bindings outside >> of MMC. I think it is the wrong way to do things. The DT should describe >> the devices. If they happen to be "simple" then the core can walk the >> tree and do any setup. For example, look for "reset-gpios" and toggle >> that GPIO. There is no need for a special node. > > Okay, I got it, no node for pwrseq but parse device properties. In case > of reset-gpios it seems quite obvious but also actively used: > $ git grep reset-gpios arch/arm/boot/dts | wc -l > 142 > > Definitely pwrseq shouldn't add itself to all of these devices. > > My questions would be then: > 1. An additional pwrseq compatible for device is acceptable? Perhaps. The issue is whether common or driver specific code handles this may change over time. In other words, it is purely a kernel decision. It could move in either direction. It may be better to just have a whitelist of devices (though it would need to be board specific somehow). > 2. How would you name the regulator? We shouldn't toggle off/on every > regulator but probably only some specific ones. I'd argue the generic case is just enable all the ones defined. If you only need to deal with some of them or need a specific sequence, then it is not generic. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Fri, May 06, 2016 at 08:12:24AM +0200, Krzysztof Kozlowski wrote: > On 05/06/2016 07:44 AM, Peter Chen wrote: > > On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: > >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > >>> Hi, > >>> > >>> This is a different, second try to fix usb3503+lan on Odroid U3 board > >>> if it was initialized by bootloader (e.g. for TFTP boot). > >>> > >>> First version: > >>> http://www.spinics.net/lists/linux-usb/msg140042.html > >>> > >>> > >>> Problem > >>> === > >>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), > >>> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset > >>> is required, e.g. by suspend to RAM. The actual TFTP boot does > >>> not have to happen. Just "usb start" from U-Boot is sufficient. > >>> > >>> From the schematics, the regulator is a supply only to LAN, however > >>> without toggling it off/on, the usb3503 hub won appear neither. > >>> > >>> > >>> Solution > >>> > >>> This is very similar to the MMC pwrseq behavior so the idea is to: > >>> 1. Move MMC pwrseq drivers to generic place, > >> > >> You can do that, but I'm going to NAK any use of pwrseq bindings outside > >> of MMC. I think it is the wrong way to do things. The DT should describe > >> the devices. If they happen to be "simple" then the core can walk the > >> tree and do any setup. For example, look for "reset-gpios" and toggle > >> that GPIO. There is no need for a special node. > >> > > > > Oh, I am doing the same thing like this patch set doing. > > Shame on me that I did not use Google before starting the work. I could > just extend your patchset. I think we can combine our efforts. > Sure :) -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On 05/06/2016 07:44 AM, Peter Chen wrote: > On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >>> Hi, >>> >>> This is a different, second try to fix usb3503+lan on Odroid U3 board >>> if it was initialized by bootloader (e.g. for TFTP boot). >>> >>> First version: >>> http://www.spinics.net/lists/linux-usb/msg140042.html >>> >>> >>> Problem >>> === >>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), >>> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset >>> is required, e.g. by suspend to RAM. The actual TFTP boot does >>> not have to happen. Just "usb start" from U-Boot is sufficient. >>> >>> From the schematics, the regulator is a supply only to LAN, however >>> without toggling it off/on, the usb3503 hub won appear neither. >>> >>> >>> Solution >>> >>> This is very similar to the MMC pwrseq behavior so the idea is to: >>> 1. Move MMC pwrseq drivers to generic place, >> >> You can do that, but I'm going to NAK any use of pwrseq bindings outside >> of MMC. I think it is the wrong way to do things. The DT should describe >> the devices. If they happen to be "simple" then the core can walk the >> tree and do any setup. For example, look for "reset-gpios" and toggle >> that GPIO. There is no need for a special node. >> > > Oh, I am doing the same thing like this patch set doing. Shame on me that I did not use Google before starting the work. I could just extend your patchset. I think we can combine our efforts. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On 05/06/2016 12:42 AM, Rob Herring wrote: > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >> Hi, >> >> This is a different, second try to fix usb3503+lan on Odroid U3 board >> if it was initialized by bootloader (e.g. for TFTP boot). >> >> First version: >> http://www.spinics.net/lists/linux-usb/msg140042.html >> >> >> Problem >> === >> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), >> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset >> is required, e.g. by suspend to RAM. The actual TFTP boot does >> not have to happen. Just "usb start" from U-Boot is sufficient. >> >> From the schematics, the regulator is a supply only to LAN, however >> without toggling it off/on, the usb3503 hub won appear neither. >> >> >> Solution >> >> This is very similar to the MMC pwrseq behavior so the idea is to: >> 1. Move MMC pwrseq drivers to generic place, > > You can do that, but I'm going to NAK any use of pwrseq bindings outside > of MMC. I think it is the wrong way to do things. The DT should describe > the devices. If they happen to be "simple" then the core can walk the > tree and do any setup. For example, look for "reset-gpios" and toggle > that GPIO. There is no need for a special node. Okay, I got it, no node for pwrseq but parse device properties. In case of reset-gpios it seems quite obvious but also actively used: $ git grep reset-gpios arch/arm/boot/dts | wc -l 142 Definitely pwrseq shouldn't add itself to all of these devices. My questions would be then: 1. An additional pwrseq compatible for device is acceptable? 2. How would you name the regulator? We shouldn't toggle off/on every regulator but probably only some specific ones. > >> 2. Extend the pwrseq-simple with regulator toggling, >> 3. Add support to USB hub and port core for pwrseq, > > We discussed this for USB already[1] and is why we defined how to add > USB child devices. The idea is not to add pwrseq to that. Yes, I left it for next iteration because it would require much more changes in USB core. As for now, these bindings are useless for USB devices which are not yet enumerated (because power sequence has to be done on them). Making use of these bindings would be a next step... Just let me do it one step a time. Best regards, Krzysztof > > Rob > > [1] http://www.spinics.net/lists/linux-usb/msg134082.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > > Hi, > > > > This is a different, second try to fix usb3503+lan on Odroid U3 board > > if it was initialized by bootloader (e.g. for TFTP boot). > > > > First version: > > http://www.spinics.net/lists/linux-usb/msg140042.html > > > > > > Problem > > === > > When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), > > the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset > > is required, e.g. by suspend to RAM. The actual TFTP boot does > > not have to happen. Just "usb start" from U-Boot is sufficient. > > > > From the schematics, the regulator is a supply only to LAN, however > > without toggling it off/on, the usb3503 hub won appear neither. > > > > > > Solution > > > > This is very similar to the MMC pwrseq behavior so the idea is to: > > 1. Move MMC pwrseq drivers to generic place, > > You can do that, but I'm going to NAK any use of pwrseq bindings outside > of MMC. I think it is the wrong way to do things. The DT should describe > the devices. If they happen to be "simple" then the core can walk the > tree and do any setup. For example, look for "reset-gpios" and toggle > that GPIO. There is no need for a special node. > Oh, I am doing the same thing like this patch set doing. Then, how can we let things be generic like you mention at [1] if without common pwrseq driver/library? The properties like "reset-gpios" under USB child node seems can only be handled by USB driver. > > 2. Extend the pwrseq-simple with regulator toggling, > > 3. Add support to USB hub and port core for pwrseq, > > We discussed this for USB already[1] and is why we defined how to add > USB child devices. The idea is not to add pwrseq to that. > > Rob > > [1] http://www.spinics.net/lists/linux-usb/msg134082.html [1] http://www.spinics.net/lists/linux-usb/msg137312.html -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: > Hi, > > This is a different, second try to fix usb3503+lan on Odroid U3 board > if it was initialized by bootloader (e.g. for TFTP boot). > > First version: > http://www.spinics.net/lists/linux-usb/msg140042.html > > > Problem > === > When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP), > the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset > is required, e.g. by suspend to RAM. The actual TFTP boot does > not have to happen. Just "usb start" from U-Boot is sufficient. > > From the schematics, the regulator is a supply only to LAN, however > without toggling it off/on, the usb3503 hub won appear neither. > > > Solution > > This is very similar to the MMC pwrseq behavior so the idea is to: > 1. Move MMC pwrseq drivers to generic place, You can do that, but I'm going to NAK any use of pwrseq bindings outside of MMC. I think it is the wrong way to do things. The DT should describe the devices. If they happen to be "simple" then the core can walk the tree and do any setup. For example, look for "reset-gpios" and toggle that GPIO. There is no need for a special node. > 2. Extend the pwrseq-simple with regulator toggling, > 3. Add support to USB hub and port core for pwrseq, We discussed this for USB already[1] and is why we defined how to add USB child devices. The idea is not to add pwrseq to that. Rob [1] http://www.spinics.net/lists/linux-usb/msg134082.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
Hi,
This is a different, second try to fix usb3503+lan on Odroid U3 board
if it was initialized by bootloader (e.g. for TFTP boot).
First version:
http://www.spinics.net/lists/linux-usb/msg140042.html
Problem
===
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
is required, e.g. by suspend to RAM. The actual TFTP boot does
not have to happen. Just "usb start" from U-Boot is sufficient.
>From the schematics, the regulator is a supply only to LAN, however
without toggling it off/on, the usb3503 hub won appear neither.
Solution
This is very similar to the MMC pwrseq behavior so the idea is to:
1. Move MMC pwrseq drivers to generic place,
2. Extend the pwrseq-simple with regulator toggling,
3. Add support to USB hub and port core for pwrseq,
4. Toggle the regulator when needed.
Issues
==
I am not familiar with USB subsystem, so please kindly guide me
where USB related code should be placed.
In the code there are still some issues to solve (FIXME/TODO notes).
If the approach is okay, I will improve the patchset. However at this
point - IT WORKS, which is nice. :)
Best regards,
Krzysztof
Krzysztof Kozlowski (13):
usb: misc: usb3503: Clean up on driver unbind
power/mmc: Move pwrseq drivers to power/pwrseq
MAINTAINERS: Retain Ulf Hansson as the same maintainer of pwrseq
power: pwrseq: Enable COMPILE_TEST for drivers
power: pwrseq: Remove mmc prefix from mmc_pwrseq
power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
power: pwrseq: simple: Add support for toggling regulator
usb: hub: Handle deferred probe
power: pwrseq: Add support for USB hubs with external power
usb: hub: Power sequence the ports on activation
usb: port: Parse pwrseq phandle from Device Tree
ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on
Odroid U3
.../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 +
MAINTAINERS| 8 +++
arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 7 ++
drivers/mmc/Kconfig| 2 -
drivers/mmc/core/Makefile | 3 -
drivers/mmc/core/core.c| 8 +--
drivers/mmc/core/host.c| 2 +-
drivers/mmc/core/pwrseq.h | 52 --
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/{mmc/core => power/pwrseq}/Kconfig | 21 --
drivers/power/pwrseq/Makefile | 3 +
drivers/{mmc/core => power/pwrseq}/pwrseq.c| 80 +-
drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c | 15 ++--
drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 73
drivers/usb/core/hub.c | 17 -
drivers/usb/core/hub.h | 3 +
drivers/usb/core/port.c| 15
drivers/usb/misc/usb3503.c | 28
include/linux/mmc/host.h | 4 +-
include/linux/pwrseq.h | 60
22 files changed, 294 insertions(+), 113 deletions(-)
delete mode 100644 drivers/mmc/core/pwrseq.h
rename drivers/{mmc/core => power/pwrseq}/Kconfig (65%)
create mode 100644 drivers/power/pwrseq/Makefile
rename drivers/{mmc/core => power/pwrseq}/pwrseq.c (50%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (89%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (64%)
create mode 100644 include/linux/pwrseq.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
