Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
Hi,
Le jeudi 18 décembre 2014 à 12:16 +0100, Marek Vasut a écrit :
On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
Hi Marex,
Following u-boot patch is pending for your review for some time. Please let
me know if you have any concerns. fsl/usb: Add USB XHCI support:
http://patchwork.ozlabs.org/patch/373593/
I missed the patch completely, sorry. Next time, please keep me on CC when
submitting the patches, that helps a lot.
As for the board_usb_init, you can drop the inline and the __board_usb_init()
and do:
__weak int board_usb_init(int index, enum usb_init_type init)
{
return 0;
}
The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down
the controller, which I don't see happening. Why?
By the way, this is already defined in common/usb.c, so it's probably
not worth duplicating it. On the other hand, it means that *HCI support
would be broken (it applies to all other drivers usb board_usb_init)
when not using CMD_USB, which I'm not sure is a good thing.
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
-Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Monday, April 06, 2015 8:42 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Monday, April 06, 2015 at 10:58:30 AM, Ramneek Mehresh wrote: [...] The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down the controller, which I don't see happening. Why? I could not locate any such requirement in IP documentation. Have contacted local IP/PHY team for the same. Waiting for response from them This is needed, so you don't start Linux with a running USB controller. xhci controller is already stopped in usb_stop-usb_lowlevel_stop-xhci_reset(). I could see CMD_RUN bit getting reset in this function before the controller is reset. So, from your previously stated requirement, controller is halted when Linux is started. Other people are shutting down PHY as part of xhci_core_exit(), not the controller!! We would not like to re-start and re-configure PHY inside Linux, and take phy initialization inside bootloader. I got word from hw team that they do not support phy shutting down from sw. hence, we do not have any sequence for current socs to shut down phy from sw. if required, I'll put forward a request to provide this control in future socs. Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
-Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:22 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote: [...] Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Hi, I don't know, but doesn't leaving the USB running cause trouble to Linux? I think you should at least document the reasoning why the USB stop is not implemented for this broken hardware. Hi Marek, it's not USB controller stop, it's Phy stop which is not supported. Controller stopping is supported. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote: -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:22 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote: [...] Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Hi, I don't know, but doesn't leaving the USB running cause trouble to Linux? I think you should at least document the reasoning why the USB stop is not implemented for this broken hardware. Hi Marek, it's not USB controller stop, it's Phy stop which is not supported. Controller stopping is supported. OK, does it pose a problem for Linux ? If not, then please just document it and let's stick with what there now. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
-Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:44 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote: -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:22 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote: [...] Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Hi, I don't know, but doesn't leaving the USB running cause trouble to Linux? I think you should at least document the reasoning why the USB stop is not implemented for this broken hardware. Hi Marek, it's not USB controller stop, it's Phy stop which is not supported. Controller stopping is supported. OK, does it pose a problem for Linux ? If not, then please just document it and let's stick with what there now. No, it won't create issue in Linux because Linux usb driver resets the controller (which in turn resets the phy). Please suggest what's the best place to document this. Shall I document this inside some u-boot doc file? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote: [...] Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Hi, I don't know, but doesn't leaving the USB running cause trouble to Linux? I think you should at least document the reasoning why the USB stop is not implemented for this broken hardware. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
-Original Message- From: Mehresh Ramneek-B31383 Sent: Tuesday, April 07, 2015 8:12 PM To: 'Marek Vasut' Cc: u-boot; s...@denx.de Subject: RE: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:44 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote: -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:22 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote: [...] Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Hi, I don't know, but doesn't leaving the USB running cause trouble to Linux? I think you should at least document the reasoning why the USB stop is not implemented for this broken hardware. Hi Marek, it's not USB controller stop, it's Phy stop which is not supported. Controller stopping is supported. OK, does it pose a problem for Linux ? If not, then please just document it and let's stick with what there now. No, it won't create issue in Linux because Linux usb driver resets the controller (which in turn resets the phy). Please suggest what's the best place to document this. Shall I document this inside some u-boot doc file? I can document this inside xhci_stop() part of fsl driver. In addition, this will also be documented in FSL USB driver documentation. Please tell if this is ok. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Tuesday, April 07, 2015 at 04:42:36 PM, Ramneek Mehresh wrote: -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:44 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote: -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:22 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote: [...] Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Hi, I don't know, but doesn't leaving the USB running cause trouble to Linux? I think you should at least document the reasoning why the USB stop is not implemented for this broken hardware. Hi Marek, it's not USB controller stop, it's Phy stop which is not supported. Controller stopping is supported. OK, does it pose a problem for Linux ? If not, then please just document it and let's stick with what there now. No, it won't create issue in Linux because Linux usb driver resets the controller (which in turn resets the phy). Please suggest what's the best place to document this. Shall I document this inside some u-boot doc file? A comment in the driver source would be fine. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Tuesday, April 07, 2015 at 04:52:09 PM, Ramneek Mehresh wrote: -Original Message- From: Mehresh Ramneek-B31383 Sent: Tuesday, April 07, 2015 8:12 PM To: 'Marek Vasut' Cc: u-boot; s...@denx.de Subject: RE: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:44 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 04:05:31 PM, Ramneek Mehresh wrote: -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Tuesday, April 07, 2015 7:22 PM To: Mehresh Ramneek-B31383 Cc: u-boot; s...@denx.de Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/ On Tuesday, April 07, 2015 at 08:18:03 AM, Ramneek Mehresh wrote: [...] Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? I have raised request for this feature in up-coming socs, and they have agreed to provide phy shut-down in future revs. However, this support is not available in current revs for which the code is sent. What do you suggest we should do for current socs? Hi, I don't know, but doesn't leaving the USB running cause trouble to Linux? I think you should at least document the reasoning why the USB stop is not implemented for this broken hardware. Hi Marek, it's not USB controller stop, it's Phy stop which is not supported. Controller stopping is supported. OK, does it pose a problem for Linux ? If not, then please just document it and let's stick with what there now. No, it won't create issue in Linux because Linux usb driver resets the controller (which in turn resets the phy). Please suggest what's the best place to document this. Shall I document this inside some u-boot doc file? I can document this inside xhci_stop() part of fsl driver. In addition, this will also be documented in FSL USB driver documentation. Please tell if this is ok. Yes, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
-Original Message-
From: Marek Vasut [mailto:ma...@denx.de]
Sent: Monday, January 12, 2015 8:00 PM
To: Mehresh Ramneek-B31383
Cc: u-boot
Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Monday, January 12, 2015 at 06:26:24 AM, Ramneek Mehresh wrote:
-Original Message-
From: Marek Vasut [mailto:ma...@denx.de]
Sent: Thursday, December 18, 2014 4:46 PM
To: u-boot
Cc: Mehresh Ramneek-B31383
Subject: Re: Regarding patch:
http://patchwork.ozlabs.org/patch/373593/
On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh
wrote:
Hi Marex,
Following u-boot patch is pending for your review for some time.
Please let me know if you have any concerns. fsl/usb: Add USB XHCI
support:
http://patchwork.ozlabs.org/patch/373593/
I missed the patch completely, sorry. Next time, please keep me on
CC when submitting the patches, that helps a lot.
As for the board_usb_init, you can drop the inline and the
__board_usb_init() and do:
__weak int board_usb_init(int index, enum usb_init_type init) {
return 0;
}
Will do
The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must
shut down the controller, which I don't see happening. Why?
I could not locate any such requirement in IP documentation. Have
contacted local IP/PHY team for the same. Waiting for response from
them
This is needed, so you don't start Linux with a running USB controller.
xhci controller is already stopped in
usb_stop-usb_lowlevel_stop-xhci_reset().
I could see CMD_RUN bit getting reset in this function before the controller is
reset.
So, from your previously stated requirement, controller is halted when Linux is
started.
Other people are shutting down PHY as part of xhci_core_exit(), not the
controller!!
We would not like to re-start and re-configure PHY inside Linux, and take phy
initialization
inside bootloader. I got word from hw team that they do not support phy
shutting down from sw. hence, we do not have any sequence for current socs to
shut down phy from sw. if required, I'll put forward a request to provide
this control in future socs.
Thanks!
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Monday, April 06, 2015 at 10:58:30 AM, Ramneek Mehresh wrote: [...] The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down the controller, which I don't see happening. Why? I could not locate any such requirement in IP documentation. Have contacted local IP/PHY team for the same. Waiting for response from them This is needed, so you don't start Linux with a running USB controller. xhci controller is already stopped in usb_stop-usb_lowlevel_stop-xhci_reset(). I could see CMD_RUN bit getting reset in this function before the controller is reset. So, from your previously stated requirement, controller is halted when Linux is started. Other people are shutting down PHY as part of xhci_core_exit(), not the controller!! We would not like to re-start and re-configure PHY inside Linux, and take phy initialization inside bootloader. I got word from hw team that they do not support phy shutting down from sw. hence, we do not have any sequence for current socs to shut down phy from sw. if required, I'll put forward a request to provide this control in future socs. Hi, Is this similar hardware bug to the one which MX6 PCIe is suffering ? On MX6, the bug is that you cannot reset the PCIe and PCIe PHY from software, which means that if you start PCIe in U-Boot, you cannot reliably use it in Linux. Furthermore, if you reset the MX6 via WDT, you cannot start PCIe reliably in Linux even if PCIe is not used in U-Boot at all. Is this the same type of hardware screwup where the design team didn't think reset was necessary? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Monday, January 12, 2015 at 06:26:24 AM, Ramneek Mehresh wrote:
-Original Message-
From: Marek Vasut [mailto:ma...@denx.de]
Sent: Thursday, December 18, 2014 4:46 PM
To: u-boot
Cc: Mehresh Ramneek-B31383
Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
Hi Marex,
Following u-boot patch is pending for your review for some time.
Please let me know if you have any concerns. fsl/usb: Add USB XHCI
support:
http://patchwork.ozlabs.org/patch/373593/
I missed the patch completely, sorry. Next time, please keep me on CC
when submitting the patches, that helps a lot.
As for the board_usb_init, you can drop the inline and the
__board_usb_init() and do:
__weak int board_usb_init(int index, enum usb_init_type init) {
return 0;
}
Will do
The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut
down the controller, which I don't see happening. Why?
I could not locate any such requirement in IP documentation. Have contacted
local IP/PHY team for the same. Waiting for response from them
This is needed, so you don't start Linux with a running USB controller.
Thanks!
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
-Original Message-
From: Marek Vasut [mailto:ma...@denx.de]
Sent: Thursday, December 18, 2014 4:46 PM
To: u-boot
Cc: Mehresh Ramneek-B31383
Subject: Re: Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
Hi Marex,
Following u-boot patch is pending for your review for some time.
Please let me know if you have any concerns. fsl/usb: Add USB XHCI
support:
http://patchwork.ozlabs.org/patch/373593/
I missed the patch completely, sorry. Next time, please keep me on CC when
submitting the patches, that helps a lot.
As for the board_usb_init, you can drop the inline and the
__board_usb_init() and do:
__weak int board_usb_init(int index, enum usb_init_type init) {
return 0;
}
Will do
The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down
the controller, which I don't see happening. Why?
I could not locate any such requirement in IP documentation. Have contacted
local
IP/PHY team for the same. Waiting for response from them
- Ramneek
Thanks!
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote:
Hi Marex,
Following u-boot patch is pending for your review for some time. Please let
me know if you have any concerns. fsl/usb: Add USB XHCI support:
http://patchwork.ozlabs.org/patch/373593/
I missed the patch completely, sorry. Next time, please keep me on CC when
submitting the patches, that helps a lot.
As for the board_usb_init, you can drop the inline and the __board_usb_init()
and do:
__weak int board_usb_init(int index, enum usb_init_type init)
{
return 0;
}
The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down
the controller, which I don't see happening. Why?
Thanks!
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
