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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B185FECAAD5 for ; Mon, 12 Sep 2022 17:24:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230052AbiILRYA (ORCPT ); Mon, 12 Sep 2022 13:24:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229909AbiILRX5 (ORCPT ); Mon, 12 Sep 2022 13:23:57 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84A5B3F328 for ; Mon, 12 Sep 2022 10:23:56 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id a41so1993199edf.4 for ; Mon, 12 Sep 2022 10:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=uW3AM/UZ8qCMKh2ox+FP5lC7oxltagZaytrj/l/iJk0=; b=EIJIney81duJTq4k/HKTJsz7r/F/XGIzapuP7y35cKvvcSBmQ5C6Z8PlcYag4mWbCv gNu7V71PNXcB/Lmxdp8rESySJMW0m/D8lEV6rUJhlh2kRfEoTyQelCU1wM/VyBvLV6Vt QBTxsska86glADjhjc03qVyNpoVlXtWsZ9HOSJoHoVCOl1rmzUunW9PI+2ki/HBz1a3D DVyvREcWu4LeDaTaPcqYj9/4A1wlQicNiaYL+VH5qliA3IIc/AR2EkL26Kyjf8GWXMdR g9eg2EjjdJ4mPYvGEzlhJF+WfmZYyfUmZNKwpNmly6e8B6gUVT9QKUyRe3Td81HqAqXZ VxmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=uW3AM/UZ8qCMKh2ox+FP5lC7oxltagZaytrj/l/iJk0=; b=71oVrSPcki72P3i44MsClCAPkQVtOCjV2Lp0oynm4frI5Kxxoq9DoD90yCQJpIKU5J wZM6funDja541nJ2BJmzVwX7cLg7pW5DkVlqJ2ZbeKAE9CDjKJdz4NxXQtcGViSfOCet fvKSI1FZTeH66kJnoxIeffNTsG/FlXgNp7Gw4/0kiHQ0aBwsfSpIEsswJ6nwJ8ffkfg2 4VlD4PZi0JycEGAw6h4phuQ6rsI8tH1DjAq+yyaeMMm4wlNuoX6I48Xxkl/6yazEiSzi mXR4uuPa3SLNpT+eOYdMdXMWsHzJvszNkpi+g+OSrztiDBre47r77P8773Y5Ifqc5ZW6 6Wvw== X-Gm-Message-State: ACgBeo2EuLFcEHXHCRHQMhlbtl59eFH5CDfBFvqQvPsc4abuj0xrJaAy uJkgGP/SWZXfa6BcNef1dejFjuzGgNXoj2Yq0EaCm5m4IwI= X-Google-Smtp-Source: AA6agR5ae8kTiyd2Jqu3e3JcOa0dYa2dK3GIvhXWxHODvtgvuDSGpqsDP3DEM4FERBLv4IPO1jmr5JnUr6JvmsADYu0= X-Received: by 2002:aa7:cb92:0:b0:443:98d6:20da with SMTP id r18-20020aa7cb92000000b0044398d620damr22772932edt.399.1663003435009; Mon, 12 Sep 2022 10:23:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olof Johansson Date: Mon, 12 Sep 2022 10:23:42 -0700 Message-ID: Subject: Re: [GIT PULL] Driver core changes for 6.0-rc1 To: Greg KH Cc: Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Stephen Rothwell , Saravana Kannan , Linux ARM Mailing List , Shawn Guo , Li Yang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Aug 3, 2022 at 7:16 AM Greg KH wrote: > Saravana Kannan (11): > PM: domains: Delete usage of driver_deferred_probe_check_state() > pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state() > net: mdio: Delete usage of driver_deferred_probe_check_state() > driver core: Add wait_for_init_devices_probe helper function > net: ipconfig: Relax fw_devlink if we need to mount a network rootfs > Revert "driver core: Set default deferred_probe_timeout back to 0." > driver core: Set fw_devlink.strict=1 by default > iommu/of: Delete usage of driver_deferred_probe_check_state() > driver core: Delete driver_deferred_probe_check_state() > driver core: fw_devlink: Allow firmware to mark devices as best effort > of: base: Avoid console probe delay when fw_devlink.strict=1 The last patch in this list regresses my HoneyComb LX2K (ironically the machine I do maintainer work on). It stops PCIe from probing, but without a single message indicating why. The reason seems to be that the iommu-maps property doesn't get patched up by my (older) u-boot, and thus isn't a valid reference. System works fine without IOMMU, which is how I've ran it for a couple of years. It's also extremely hard to diagnose out of the box because there are *no error messages*. And there were no warnings leading up to this strict enforcement. This "feature" seems to have been done backwards. The checks should have been running (and not skipped due to the "optional" flag), but also not causing errors, just warnings. That would have given users a chance to know that this is something that needs to be fixed. And when you flip the switch, at least report what failed so that people don't need to spend a whole night bisecting kernels, please. Greg, mind reverting just the last one? If I hit this, I presume others would too. -Olof 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AE67EECAAD5 for ; Mon, 12 Sep 2022 17:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EYOMavUuJBxJ4ViysEr63vE4Wo8GweiR6/qMyCxoGc4=; b=mh6nDpA/qeLQcW z+BJgckLY8ZRLC44RKtedJQ7jV9wC/metH49afb0NeYoEO/9OaVehW4Ra2gGBjVAN/xdqhk2ZyRgC VEE/e87xBAoGCyrYvnKyHKGTAqUjUxxHDONnvFdR70g8YGIOY5igHQylNUDSqZIfGZ9qJ6g4ry2R7 B1V6axJMWlICDZDtvO2Mp7bZ2CIdNorbznxqeIh/IquwIbu8zUGD/D04sCdQ1INHuabAYlHWH8kB6 VLZvvQJahdYphr2zduQyqPurq8Er2AIIqhChrT2DeYyTblikfTg7F3kYdSxseLq5L6SiKqBGVD0Dj 7neK3cBDr16dLbZCal9w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXnAG-00Bzk2-Ai; Mon, 12 Sep 2022 17:24:08 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXnAC-00Bzgx-Aa for linux-arm-kernel@lists.infradead.org; Mon, 12 Sep 2022 17:24:05 +0000 Received: by mail-ed1-x52c.google.com with SMTP id z21so13855438edi.1 for ; Mon, 12 Sep 2022 10:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=uW3AM/UZ8qCMKh2ox+FP5lC7oxltagZaytrj/l/iJk0=; b=EIJIney81duJTq4k/HKTJsz7r/F/XGIzapuP7y35cKvvcSBmQ5C6Z8PlcYag4mWbCv gNu7V71PNXcB/Lmxdp8rESySJMW0m/D8lEV6rUJhlh2kRfEoTyQelCU1wM/VyBvLV6Vt QBTxsska86glADjhjc03qVyNpoVlXtWsZ9HOSJoHoVCOl1rmzUunW9PI+2ki/HBz1a3D DVyvREcWu4LeDaTaPcqYj9/4A1wlQicNiaYL+VH5qliA3IIc/AR2EkL26Kyjf8GWXMdR g9eg2EjjdJ4mPYvGEzlhJF+WfmZYyfUmZNKwpNmly6e8B6gUVT9QKUyRe3Td81HqAqXZ VxmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=uW3AM/UZ8qCMKh2ox+FP5lC7oxltagZaytrj/l/iJk0=; b=yL0pU5liwYKgRNEF3OpnmYyeDs2eHOhwG2zBI7aNuWh7fIlip06jR/atbX09CX1bh0 sXgFHbBa/3YDjPnG0IK6/HksTnAQFn6W3e4cR6Exu3VkGfOyP9YYl4tsJUE6Ly1VXvL6 bgIKqx9VbrZ3yts1+HQcAf/kcrOaLXki7neIi7o1zQek2/VO27UOhFkBmrGtNiLR8E7w hvBV9DEmGNIDW/9A5W8Kbx15zJX7cHlpq7DDqN+M3lgyPRpG/qA90NVCZnlCeH1smJU/ JCwnszrOhGZ88+MGHGad2QEYWFjgsk8+/V1F5rKSxIVyoHfYd3mV4v9OAqaJTQsp23xg 1GtQ== X-Gm-Message-State: ACgBeo2V8GGjwcRTS/Iy1s1M0sEQTDE/F+dCu7aZBGJxM9GfvQesKKHT kimbtAqRJQt2HA5GFPaZU1eYHI2uqkHCn/5/rf5r8A== X-Google-Smtp-Source: AA6agR5ae8kTiyd2Jqu3e3JcOa0dYa2dK3GIvhXWxHODvtgvuDSGpqsDP3DEM4FERBLv4IPO1jmr5JnUr6JvmsADYu0= X-Received: by 2002:aa7:cb92:0:b0:443:98d6:20da with SMTP id r18-20020aa7cb92000000b0044398d620damr22772932edt.399.1663003435009; Mon, 12 Sep 2022 10:23:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Olof Johansson Date: Mon, 12 Sep 2022 10:23:42 -0700 Message-ID: Subject: Re: [GIT PULL] Driver core changes for 6.0-rc1 To: Greg KH Cc: Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Stephen Rothwell , Saravana Kannan , Linux ARM Mailing List , Shawn Guo , Li Yang X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220912_102404_527530_6D7B81C4 X-CRM114-Status: GOOD ( 14.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Wed, Aug 3, 2022 at 7:16 AM Greg KH wrote: > Saravana Kannan (11): > PM: domains: Delete usage of driver_deferred_probe_check_state() > pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state() > net: mdio: Delete usage of driver_deferred_probe_check_state() > driver core: Add wait_for_init_devices_probe helper function > net: ipconfig: Relax fw_devlink if we need to mount a network rootfs > Revert "driver core: Set default deferred_probe_timeout back to 0." > driver core: Set fw_devlink.strict=1 by default > iommu/of: Delete usage of driver_deferred_probe_check_state() > driver core: Delete driver_deferred_probe_check_state() > driver core: fw_devlink: Allow firmware to mark devices as best effort > of: base: Avoid console probe delay when fw_devlink.strict=1 The last patch in this list regresses my HoneyComb LX2K (ironically the machine I do maintainer work on). It stops PCIe from probing, but without a single message indicating why. The reason seems to be that the iommu-maps property doesn't get patched up by my (older) u-boot, and thus isn't a valid reference. System works fine without IOMMU, which is how I've ran it for a couple of years. It's also extremely hard to diagnose out of the box because there are *no error messages*. And there were no warnings leading up to this strict enforcement. This "feature" seems to have been done backwards. The checks should have been running (and not skipped due to the "optional" flag), but also not causing errors, just warnings. That would have given users a chance to know that this is something that needs to be fixed. And when you flip the switch, at least report what failed so that people don't need to spend a whole night bisecting kernels, please. Greg, mind reverting just the last one? If I hit this, I presume others would too. -Olof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel