Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp965039rwb; Tue, 27 Sep 2022 06:53:01 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5M3Th04QQI7DAyh2ekpGJ8HNt1JdtTwqQdtIzb6+w61NffrRvDsLYcfGap0wl34oKBBfMo X-Received: by 2002:a17:906:ee81:b0:77e:829a:76e9 with SMTP id wt1-20020a170906ee8100b0077e829a76e9mr23590666ejb.207.1664286781085; Tue, 27 Sep 2022 06:53:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664286781; cv=none; d=google.com; s=arc-20160816; b=iY+j0BZz6X/fqO7qWpQw4hNUB4ah+bpx4XcslLSBX46EFkboEXaV7vaEuVyvGvbhDh oXgMjzBStQIpUZFF/fxv0EnPkdgBDkR+O4dc3e3EA4R3Kzp8Sdsc6EMkr0M7tIJe+BVu b6aMxwEny3t7e5SFJXsWjglIKEC9tJ82sSnJMhWa0jUmXijJLgAx4HEO5qw4t9a3xOiB SaaIuC7oHxVjDTF9K9CbdgAw/ZfOto5ioq71xFc/fjlmGNV/g8Aes0FTHGneywGWSoB9 FCSe68hy2xPbsWLmHTXnmB7g/V2L4t1CG7C1Xn2cy+vAj47ia6SyP7/Ik4OW4mKyGKYe 8a/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=ELWISdX/9sBvFeydvloaIktg59EFBOWavlNHB984OXE=; b=xS853ZFUnxSSMKVHRlpdpHJnJZKJg2u2yChgv5ebbQiP4g+mwOkgX28D8QT7/Bev49 NGxHqyzzjDvU32FvyGpurMgsF+r8ZPhOnYWJEzsEIKqotL/19UmXspXJWjqRtsqbBnFc 24cxZl5AVDHLr+EHb0ipd0IJEcfxDxDbolYiPZLrtCU2QremAPulujBtm6ujpKFkfe7v OBgq0NSKFR/UYTE4Zi8JEaFzFLkWUS/JcHrSSWn1djKgzG40pTdthhpfOMV1sEQxCmyf flKKvm6f5aPmufPhmIPz6VgSwZsWixISPVK5oWqj26b9TAD/Y/ofqIeZOJyjB7RgIumT 95PA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QjkNRJ9J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nb34-20020a1709071ca200b00783112d1790si1774850ejc.255.2022.09.27.06.52.35; Tue, 27 Sep 2022 06:53:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=QjkNRJ9J; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229631AbiI0MUU (ORCPT + 99 others); Tue, 27 Sep 2022 08:20:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232310AbiI0MTv (ORCPT ); Tue, 27 Sep 2022 08:19:51 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FB0812FF07; Tue, 27 Sep 2022 05:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664281126; x=1695817126; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=OFIxxBkiaCDaU7hdmWCgva7sjv3x1WGTNlqGM1oQtNQ=; b=QjkNRJ9JABpK5KuGM6vW13ifDgF1zvv2NkXQaswwpopi4XOrqXvNEW0a zpn3E9p4vm/ehX8quUW0x0BcZv29fvHaAW/CgJ7m0T7qXQe0amKRrEDAS EzB9PNHcvJpz0v5O31ewC6zMNtvXzKqa8GeDCBYoV0lCNy6b/2IZB1DBT Id0ypUSxa2I1GHDoKY+PdTwG9seHh2aJKRcz1VEVKBPDv0rkhfFI2ij6M HzvJcvXyiqAF0KmEO1wuXT7fF/4llRwNNO0kHo3UcyfJOgYiuwzhcscEj KvJSp43ftV8CWZlWWf9OWIxVC5CY0jzHRUjgnkJrYa+TZkir+NeUE9ezV A==; X-IronPort-AV: E=McAfee;i="6500,9779,10482"; a="302782109" X-IronPort-AV: E=Sophos;i="5.93,349,1654585200"; d="scan'208";a="302782109" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2022 05:18:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10482"; a="599160114" X-IronPort-AV: E=Sophos;i="5.93,349,1654585200"; d="scan'208";a="599160114" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga006.jf.intel.com with ESMTP; 27 Sep 2022 05:18:06 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1od9XD-008RHv-1p; Tue, 27 Sep 2022 15:17:59 +0300 Date: Tue, 27 Sep 2022 15:17:59 +0300 From: Andy Shevchenko To: Rob Herring , Andrzej Hajda Cc: Olof Johansson , Greg Kroah-Hartman , Saravana Kannan , "Rafael J. Wysocki" , Laurentiu Tudor , Jiri Slaby , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Joel Stanley , Andrew Jeffery , Nicolas Saenz Julienne , Broadcom internal kernel review list , Florian Fainelli , Ray Jui , Scott Branden , Al Cooper , Paul Cercueil , Vladimir Zapolskiy , Matthias Brugger , Thierry Reding , Jonathan Hunter , Kunihiko Hayashi , Masami Hiramatsu , Tobias Klauser , Russell King , Vineet Gupta , Richard Genoud , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Alexander Shiyan , Baruch Siach , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Karol Gugala , Mateusz Holenko , Gabriel Somlo , Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Taichi Sugaya , Takao Orito , Liviu Dudau , Sudeep Holla , Lorenzo Pieralisi , Andy Gross , Bjorn Andersson , Pali Rohar , Andreas Farber , Manivannan Sadhasivam , Krzysztof Kozlowski , Alim Akhtar , Laxman Dewangan , Palmer Dabbelt , Paul Walmsley , Orson Zhai , Baolin Wang , Chunyan Zhang , Patrice Chotard , Maxime Coquelin , Alexandre Torgue , "David S. Miller" , Hammer Hsieh , Peter Korsgaard , Timur Tabi , Michal Simek , sascha hauer , peng fan , kevin hilman , ulf hansson , len brown , pavel machek , joerg roedel , will deacon , andrew lunn , heiner kallweit , eric dumazet , jakub kicinski , paolo abeni , linus walleij , hideaki yoshifuji , david ahern , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, iommu@lists.linux-foundation.org, netdev@vger.kernel.org, linux-gpio@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-rpi-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-actions@lists.infradead.org, linux-unisoc@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, sparclinux@vger.kernel.org Subject: Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set Message-ID: References: <20220701012647.2007122-1-saravanak@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 26, 2022 at 01:25:05PM -0500, Rob Herring wrote: > On Mon, Sep 19, 2022 at 5:56 PM Olof Johansson wrote: > > > > On Mon, Sep 19, 2022 at 1:44 AM Greg Kroah-Hartman > > wrote: > > > > > > On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote: > > > > On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman > > > > wrote: > > > > > > > > > > On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote: > > > > > > These patches are on top of driver-core-next. > > > > > > > > > > > > Even if stdout-path isn't set in DT, this patch should take console > > > > > > probe times back to how they were before the deferred_probe_timeout > > > > > > clean up series[1]. > > > > > > > > > > Now dropped from my queue due to lack of a response to other reviewer's > > > > > questions. > > > > > > > > What happened to this patch? I have a 10 second timeout on console > > > > probe on my SiFive Unmatched, and I don't see this flag being set for > > > > the serial driver. In fact, I don't see it anywhere in-tree. I can't > > > > seem to locate another patchset from Saravana around this though, so > > > > I'm not sure where to look for a missing piece for the sifive serial > > > > driver. > > > > > > > > This is the second boot time regression (this one not fatal, unlike > > > > the Layerscape PCIe one) from the fw_devlink patchset. > > > > > > > > Greg, can you revert the whole set for 6.0, please? It's obviously > > > > nowhere near tested enough to go in and I expect we'll see a bunch of > > > > -stable fixups due to this if we let it remain in. > > > > > > What exactly is "the whole set"? I have the default option fix queued > > > up and will send that to Linus later this week (am traveling back from > > > Plumbers still), but have not heard any problems about any other issues > > > at all other than your report. > > > > I stand corrected in this case, the issue on the Hifive Unmatched was > > a regression due to a PWM clock change -- I just sent a patch for that > > (serial driver fix). > > > > So it seems like as long as the fw_devlink.strict=1 patch is reverted, > > things are back to a working state here. > > > > I still struggle with how the fw_devlink patchset is expected to work > > though, since DT is expected to describe the hardware configuration, > > and it has no knowledge of whether there are drivers that will be > > bound to any referenced supplier devnodes. It's not going to work well > > to assume that they will always be bound, and to add 10 second > > timeouts for those cases isn't a good solution. Seems like the number > > of special cases will keep adding up. > > Since the introduction of deferred probe, the kernel has always > assumed if there is a device described, then there is or will be a > driver for it. The result is you can't use new DTs (if they add > providers) with older kernels. > > We've ended up with a timeout because no one has come up with a better > way to handle it. What the kernel needs is userspace saying "I'm done > loading modules", but it's debatable whether that's a good solution > too. In my opinion the deferred probe is a big hack and that is the root cause of the issues we have here and there. It has to be redesigned to be mathematically robust. It was an attempt by Andrzej Hajda to solve this [1]. [1]: https://events19.linuxfoundation.org/wp-content/uploads/2017/12/Deferred-Problem-Issues-With-Complex-Dependencies-Between-Devices-in-Linux-Kernel-Andrzej-Hajda-Samsung.pdf -- With Best Regards, Andy Shevchenko