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 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 A5E21C433B4 for ; Tue, 20 Apr 2021 09:47:00 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 92BB961107 for ; Tue, 20 Apr 2021 09:46:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92BB961107 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FPf3Q0JFKz30D8 for ; Tue, 20 Apr 2021 19:46:58 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=217.72.192.73; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FPdBD70sFz2xdP for ; Tue, 20 Apr 2021 19:07:47 +1000 (AEST) Received: from mail-ej1-f45.google.com ([209.85.218.45]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1Mgf8s-1m07Ln0vNc-00h2Y6 for ; Tue, 20 Apr 2021 11:07:43 +0200 Received: by mail-ej1-f45.google.com with SMTP id g5so50435503ejx.0 for ; Tue, 20 Apr 2021 02:07:43 -0700 (PDT) X-Gm-Message-State: AOAM5331UhYVOeHQmNcza8kb7h5UovdmAhvX/sDD0ld7VPkRHIjifiN1 9xv4CAXlC2QxfNOYctbskrWU2QqkrTmJx0U1kHU= X-Google-Smtp-Source: ABdhPJwSiNwlZ27l6d0oeVOJMjBIBpaEf6fV+Kr02yQOCGa6DdHdokE+eIs4+TiyDD+ybgS8jO4hGYikHl0QAhmuRDs= X-Received: by 2002:adf:db4f:: with SMTP id f15mr19571156wrj.99.1618909652608; Tue, 20 Apr 2021 02:07:32 -0700 (PDT) MIME-Version: 1.0 References: <20210419042722.27554-1-alice.guo@oss.nxp.com> <20210419042722.27554-4-alice.guo@oss.nxp.com>

In-Reply-To: From: Arnd Bergmann Date: Tue, 20 Apr 2021 11:07:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match To: Dominique MARTINET Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:WCMPNj3wUQNO6aWbyFkNRQthZSGLva8YFhQT854krwZWkw/IIha 2b6yH8JULhXqu3iprxSpFmllduQ+DZu3+fLFrAJFOwE4XHS3vmkYLWEpjOSjgnHuoJHfDWB uDN6s982HOo3IZssgv+Ay925e+Hzf46DC9fnEwhDJBs85h/uFJ2vZUA5EhzueU6i2ViYTjf VL5G9iADWzSnakrIFGlxQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:0c/HvcBEmUE=:nP/d61a8TH3mmcr8jy/4T1 ti0um83ttVVrMm0fOfwHeiRkpoB1++7RzhWloh/NkoBBEpgAJ50yPqKsL/dVCrWIxQxqpJJAO RrvYFKFvaw5NZMWCSEqEVx/lNjUWsyDGJ9GxeIDUeXwDI0ZlTYfZMlyKOCbwcMOQcVV2N6FTN WVem8VooKqTTHTpdDWfYx5OWNYIGilwD8T3mGxr+WjHzLIZ9JeijgevX95Nc8MKGaYI94QDiB 4XqPpDN7VSkrep8bxCSLmG0/A+CSeWWDW35O4OKceh5Q2UPwzZZnh1yGA+VB9WtFZ9kXYFPMO 1nT/hfubh7QPXbLGHADreXycoy25snFnrsvIFLA6i9Z/nKxkc6O6iwx7KW2fjLLEg8ZoZHfwt CZ8HdyMWpJlXAM7TI1cLQftO8DNWBK72bCCO6dAWuMv//JxbkZ/rzQA+QYboJg216kR3v7L5Y Ttv6uZZdjJxoGLq0LtjXbUKmQFKMuNZ06D9INxav9KkgybRJDXBXgO3pgtmc5JeIhgYj0yBAl xZfPd/7NxR8vToFRdmenaStSfb4V9XZ94nOYsbPWIhyXSqwEevIOfSopzzi7SixOvzCQMBQzc gmusxpI9AvGmis4JG/KoFCtoFd9xSu6QfUbcZDxYwybqah0ugV5q1yuaCLf0YR2vgOWU8Xf7Q OlN0= X-Mailman-Approved-At: Tue, 20 Apr 2021 19:46:37 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , aymen.sghaier@nxp.com, Geert Uytterhoeven , Rafael Wysocki , David Airlie , Michael Turquette , dri-devel , Linux Kernel Mailing List , Andrzej Hajda , Networking , linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com, linux-clk , Linux-Renesas , Wim Van Sebroeck , Herbert Xu , =?UTF-8?Q?Horia_Geant=C4=83?= , Kevin Hilman , Joerg Roedel , Neil Armstrong , linux-staging@lists.linux.dev, "open list:IOMMU DRIVERS" , Kishon , Tony Lindgren , linux-omap , Geert Uytterhoeven , Jakub Kicinski , Linus Walleij , Guenter Roeck , Linux Media Mailing List , LINUXWATCHDOG , Will Deacon , Linux PM list , linuxppc-dev , Eduardo Valentin , "open list:GPIO SUBSYSTEM" , "moderated list:ARM/Mediatek SoC..." , Santosh Shilimkar , Matthias Brugger , "open list:ARM/Amlogic Meson SoC support" , Mauro Carvalho Chehab , Linux ARM , "Alice Guo \(OSS\)" , Felipe Balbi , tomba@kernel.org, Stephen Boyd , gregkh , Alan Stern , USB list , linux-mmc , Adrian Hunter , Robert Foss , Leo Li , Tony Prisk , Vinod Koul , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Daniel Vetter , Keerthy , dmaengine@vger.kernel.org, Roy Pledge , jyri.sarha@iki.fi, David Miller Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET wrote: > Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200: > > For built-in drivers, load order depends on the initcall level and > > link order (how things are lined listed in the Makefile hierarchy). > > > > For loadable modules, this is up to user space in the end. > > > > Which of the drivers in this scenario are loadable modules? > > All the drivers involved in my case are built-in (nvmem, soc and final > soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is > not identified properly). Ok, in that case you may have a chance to just adapt the initcall levels. This is somewhat fragile if someone else already relies on a particular order, but it's an easy one-line change to change a driver e.g. from module_init() or device_initcall() to arch_initcall(). > I frankly don't like the idea of moving nvmem/ above soc/ in > drivers/Makefile as a "solution" to this (especially as there is one > that seems to care about what soc they run on...), so I'll have a look > at links first, hopefully that will work out. Right, that would be way more fragile. I think the main problem in this case is the caam driver that really should not look into the particular SoC type or even machine compatible string. This is something we can do as a last resort for compatibility with busted devicetree files, but it appears that this driver does it as the primary method for identifying different hardware revisions. I would suggest fixing the binding so that each SoC that includes one of these devices has a soc specific compatible string associated with the device that the driver can use as the primary way of identifying the device. We probably need to keep the old logic around for old dtb files, but there can at least be a comment next to that table that discourages people from adding more entries there. Arnd