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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BB37C43462 for ; Mon, 19 Apr 2021 09:34:13 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B691061245 for ; Mon, 19 Apr 2021 09:34:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B691061245 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atmark-techno.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 43D18402AF; Mon, 19 Apr 2021 09:34:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9qCPDLQoEGl; Mon, 19 Apr 2021 09:34:11 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp4.osuosl.org (Postfix) with ESMTP id 413C340397; Mon, 19 Apr 2021 09:34:06 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 10A9AC000F; Mon, 19 Apr 2021 09:34:06 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3C7A6C000B for ; Mon, 19 Apr 2021 09:34:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2B0C4835E0 for ; Mon, 19 Apr 2021 09:34:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK-zSmXRwmgu for ; Mon, 19 Apr 2021 09:33:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from gw.atmark-techno.com (gw.atmark-techno.com [13.115.124.170]) by smtp1.osuosl.org (Postfix) with ESMTP id B233583579 for ; Mon, 19 Apr 2021 09:33:59 +0000 (UTC) Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by gw.atmark-techno.com (Postfix) with ESMTPS id 0500F80491 for ; Mon, 19 Apr 2021 18:33:58 +0900 (JST) Received: by mail-pg1-f198.google.com with SMTP id r27-20020a63441b0000b02901e65403d377so5862694pga.14 for ; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f9v+Sm8mKFEbQyXi/sN2tJHr2LOa9v0CsJoz/H5l6cU=; b=FcOkAreAOATnZITm4i115FFhMGcpAcdctaxjAXOSfyJ1DzDwJNd09gEZwfaV6BObrL ffA0GnSbVMyXj3pCFQQxH+vZm/I/QQJrDiW3FhGmh2igzYN7+D/9ZuijuHwDuQWS6HOY DwzIj9rgJuD5hXjCjEj7LvX2YkRQ88t+ucjXGnIytCL57TshyalPPyiUq/MxqxwN++JX bgMxSTqJSA8ToQza8rSXizxQrANDUYjldtb0bxXxZSAJGSnH5m/Ngh9MVEW/V3Tk5J65 k1lj6BTVGxHwz4h7qXh50Mon9MHwZbZcmiWoGkcMVb5ZM0/wt9ZWbETrpJxTA/4GI4V8 R7wQ== X-Gm-Message-State: AOAM532SD29/vB+bOP2tIXoWoSQwLDOnqEdb2xXU3mlfRHvkd6ZIuunt Aah7e54kHLxQch1QOrObTfmHazJunYnoThtALZofOvP6IKJp8Pw+22Srr1NRZqV3Qgj3Fi6pY2s aU09miNWh5LEuk85B6Krl+eWrgcuTyIE1Vw== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208900pgw.31.1618824837070; Mon, 19 Apr 2021 02:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3BVfHB/Iu3InVzb+YLUkuY7/BfcYMlC0sOGsbJiks+G4SQp5aPsproxuobb7vRE8Qif9k+g== X-Received: by 2002:a63:1665:: with SMTP id 37mr11208853pgw.31.1618824836841; Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from pc-0115 (103.131.189.35.bc.googleusercontent.com. [35.189.131.103]) by smtp.gmail.com with ESMTPSA id x18sm10982637pjn.51.2021.04.19.02.33.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Apr 2021 02:33:56 -0700 (PDT) Received: from martinet by pc-0115 with local (Exim 4.94) (envelope-from ) id 1lYQHy-002k7D-3h; Mon, 19 Apr 2021 18:33:54 +0900 Date: Mon, 19 Apr 2021 18:33:44 +0900 From: Dominique MARTINET To: Geert Uytterhoeven Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Message-ID: References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: ulf.hansson@linaro.org, aymen.sghaier@nxp.com, geert+renesas@glider.be, rafael@kernel.org, airlied@linux.ie, mturquette@baylibre.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, a.hajda@samsung.com, netdev@vger.kernel.org, linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com, linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org, wim@linux-watchdog.org, herbert@gondor.apana.org.au, horia.geanta@nxp.com, khilman@baylibre.com, narmstrong@baylibre.com, linux-staging@lists.linux.dev, iommu@lists.linux-foundation.org, kishon@ti.com, tony@atomide.com, linux-omap@vger.kernel.org, stern@rowland.harvard.edu, kuba@kernel.org, linus.walleij@linaro.org, linux@roeck-us.net, linux-media@vger.kernel.org, linux-watchdog@vger.kernel.org, will@kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, edubezval@gmail.com, linux-gpio@vger.kernel.org, linux-mediatek@lists.infradead.org, ssantosh@kernel.org, matthias.bgg@gmail.com, linux-amlogic@lists.infradead.org, mchehab@kernel.org, linux-arm-kernel@lists.infradead.org, "Alice Guo \(OSS\)" , balbi@kernel.org, tomba@kernel.org, sboyd@kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org, adrian.hunter@intel.com, robert.foss@linaro.org, leoyang.li@nxp.com, linux@prisktech.co.nz, vkoul@kernel.org, Arnd Bergmann , linux-crypto@vger.kernel.org, daniel@ffwll.ch, j-keerthy@ti.com, dmaengine@vger.kernel.org, Roy.Pledge@nxp.com, jyri.sarha@iki.fi, davem@davemloft.net X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > This is going to need quite some more work to be acceptable, in my > > opinion, but I think it should be possible. > > In general, this is very hard to do, IMHO. Some drivers may be used on > multiple platforms, some of them registering an SoC device, some of > them not registering an SoC device. So there is no way to know the > difference between "SoC device not registered, intentionally", and > "SoC device not yet registered". Hm, good point, I was probably a bit too optimistic if there are devices which don't register any soc yet have drivers which want one; I don't see how to make the difference indeed... And that does mean we can't just defer all the time. > soc_device_match() should only be used as a last resort, to identify > systems that cannot be identified otherwise. Typically this is used for > quirks, which should only be enabled on a very specific subset of > systems. IMHO such systems should make sure soc_device_match() > is available early, by registering their SoC device early. I definitely agree there, my suggestion to defer was only because I know of no other way to influence the ordering of drivers loading reliably and gave up on soc being init'd early. In this particular case the problem is that since 7d981405d0fd ("soc: imx8m: change to use platform driver") the soc probe tries to use the nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet. So soc loading gets pushed back to the end of the list because it gets defered and other drivers relying on soc_device_match get confused because they wrongly think a device doesn't match a quirk when it actually does. If there is a way to ensure the nvmem driver gets loaded before the soc, that would also solve the problem nicely, and avoid the need to mess with all the ~50 drivers which use it. Is there a way to control in what order drivers get loaded? Something in the dtb perhaps? Thanks, -- Dominique _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu