From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3DF47C433EF for ; Sat, 20 Nov 2021 11:11:20 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3EC59834AC; Sat, 20 Nov 2021 12:11:17 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 738A6834CB; Sat, 20 Nov 2021 12:11:15 +0100 (CET) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9DED7834AA for ; Sat, 20 Nov 2021 12:11:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id e858cd34; Sat, 20 Nov 2021 12:11:10 +0100 (CET) Date: Sat, 20 Nov 2021 12:11:10 +0100 (CET) From: Mark Kettenis To: Ilias Apalodimas Cc: trini@konsulko.com, xypron.glpk@gmx.de, u-boot@lists.denx.de, sjg@chromium.org In-Reply-To: (message from Ilias Apalodimas on Sat, 20 Nov 2021 10:20:23 +0200) Subject: Re: [PATCH] efi: Call bootm_disable_interrupts earlier in efi_exit_boot_services References: <20211119213304.2824837-1-trini@konsulko.com> <20211119220951.GL24579@bill-the-cat> Message-ID: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.37 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean > From: Ilias Apalodimas > Date: Sat, 20 Nov 2021 10:20:23 +0200 > > On Sat, 20 Nov 2021 at 00:09, Tom Rini wrote: > > > > On Fri, Nov 19, 2021 at 10:52:27PM +0100, Heinrich Schuchardt wrote: > > > > > > > > > Am 19. November 2021 22:33:04 MEZ schrieb Tom Rini : > > > >If we look at the path that bootm/booti take when preparing to boot the > > > >OS, we see that as part of (or prior to calling do_bootm_states, > > > >explicitly) the process, bootm_disable_interrupts() is called prior to > > > >announce_and_cleanup() which is where udc_disconnect() / > > > >board_quiesce_devices() / dm_remove_devices_flags() are called from. In > > > >the EFI path, these are called afterwards. In efi_exit_boot_services() > > > >however we have been calling bootm_disable_interrupts() after the above > > > >functions, as part of ensuring that we disable interrupts as required > > > >by the spec. However, bootm_disable_interrupts() is also where we go > > > >and call usb_stop(). While this has been fine before, on the TI J721E > > > >platform this leads us to an exception. This exception seems likely to > > > >be the case that we're trying to stop devices that we have already > > > >disabled clocks for. The most direct way to handle this particular > > > > > > This patch may hide an error on your board but obviously does not address the real problem. > > I don't think it 'hides' it. I think it's the other way around, this > board exposes the problem. In any case I think disabling irq's etc > make sense to run before we disable devices completely. > > > > > > > If dependencies in the shut down sequence should exist, we need to consider them in the driver model. > > Yes agree 100% here. > > > > > > > What is your plan to analyze the problem? > > > > I'm not sure there is a different problem to solve here. It's unsafe to > > call the "shut everything down" function, which is what usb_stop() is, > > after having shut everything down. We may be able to stop calling > > usb_stop() as any sort of shutdown should already have happened via > > driver model, which is what we see now. > > Linux has CONFIG_EFI_DISABLE_PCI_DMA to deal with similar problems on > PCI devices. Basically it disables busmastering until linux properly > configures the SMMU. I think disabling the devices before handing > over to the OS (when possible) is a good policy. In any case I think > this patch is reasonable since it at lest makes EFI and bootm/i behave > similarly. I'll go have a look on bootm/i and cleanup the whole thing > at some point. Have to be careful here. Some OSes may assume (implicitly or explicitly) that the "firmware" has initialized the hardware to a point where it can be used. This is especially important for serial ports in order to have a debugging channel available in the OS as early as possible. But it is also good for things like USB PHYs and PCIe root complexes. If you tear those down completely (by doing a full reset and/or disabling associated clocks) you risk breaking OSes. This happened to OpenBSD on the Raspberry Pi 4 because earlier this year a change was committed that resets the PCIe root complex. And I think this has been responsible for some of the USB issues with Rockchip platforms as well. But yes, quiescing DMA masters is necessary, and disabling interrupts is probably a good idea as well.