From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Sun, 15 Nov 2015 20:35:53 +0100 Subject: [U-Boot] [PATCH v2 18/26] dm: usb: Remove inactive children after a bus scan In-Reply-To: References: <1447051688-24936-1-git-send-email-sjg@chromium.org> <1447051688-24936-19-git-send-email-sjg@chromium.org> <564057DC.1000809@redhat.com> <564374A4.5080009@gmail.com> <56449D69.2020904@redhat.com> Message-ID: <5648DE99.5060504@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 11/13/2015 10:58 PM, Simon Glass wrote: > Hi Hans, >>>> Talking about usb-stop, there is still one (BIG!) problem after >>>> this patch set when building usb-support with DM_DEVICE_REMOVE >>>> not set. This means that the controllers dma engines will not >>>> be stopped when booting the actual OS and they will still be >>>> accessing parts of the main memory while the actual OS is >>>> booting, which is BAD. So I suggest adding something like >>>> this to all host drivers which use dma in this way: >>>> >>>> #if defined CONFIG_DM_USB && !defined CONFIG_DM_DEVICE_REMOVE >>>> #error The EHCI driver cannot be used without CONFIG_DM_DEVICE_REMOVE >>>> otherwise DMA stays active while booting the OS >>>> #endif >>> >>> >>> Sounds good. I am not suggesting that we encourage people to build USB >>> with out DM_DEVICE_REMOVE. I just want to make sure that we don't >>> create unnecessary dependencies such that DM_DEVICE_REMOVE becomes >>> impossible to use. >>> >>> We have a note in the Kconfig for that, but I agree we need to make it >>> more explicit. With the #if approach it makes the pitfall much more >>> obvious. >> >> >> Ack, so we need to have patches for this for at least ohci, ehci, xhci >> and I guess also uhci ? Who is going to write these patches ? > > I suppose I could do that. I would like to make sure that any USB fish > hooks are removed, and that is part of the solution. > > I'd really like to resolve this and move things forward. If you still > have have strong objections please let me know. There are no objections from my side to move forward with your current solution. > We did discuss this at > the time and I was clear that I did not want to keep the solution as > it was - I merged it because it fixed a bug, as you pointed out at the > time. Ack. Regards, Hans