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 40F82C4332F for ; Wed, 14 Dec 2022 23:09:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229689AbiLNXJE (ORCPT ); Wed, 14 Dec 2022 18:09:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229551AbiLNXJD (ORCPT ); Wed, 14 Dec 2022 18:09:03 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CC5F442C6 for ; Wed, 14 Dec 2022 15:09:02 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id js9so8602496pjb.2 for ; Wed, 14 Dec 2022 15:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3ehVNxRAk8vtcQmEsS2DeBEXBsGDUIlgGFYWQTXu6Hk=; b=XGNT1V8bB+E+b7ARt7dy88tch1s1aCC7J585miYX8QJAQHTQDryfRyy/yUbZe84R3Z QJ7OhpwNdCrA01EPKWFvknWSPw+t9xl6+DApoaVCcW9P6hnZtW89BYPZAJ42P547x/26 meb60w9D91tfFRNBLiL1qGf8wirGUo1fIfqMeHLIpjqP9c1zUtguR4FFW4p6uewrkK86 xKAydwss7Ktfjm8lJXjr8VmFLpKBGTgpQ5ZyG54z3vn2vPZMkDHePBP9fauHDYHKsmcP HmzlCquXfd7JZcmZ5jRnUHrATM998CH2pypijXpvXMtUOZSQ9JXbvaIr0ZWopAfdXi6o tkpg== 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:message-id :reply-to; bh=3ehVNxRAk8vtcQmEsS2DeBEXBsGDUIlgGFYWQTXu6Hk=; b=NxPtyXZvlbn/DrCDR6p9Bm+acUXVesT/3pT5zHM08XNg/sukYjsG8TKyVJLciaZ/BG dcmMACthSfE8qsh0lDLhMnHwoA0egUDuundCLHrnXV9kzks+h1vXzO0pcdmyiFvCv+Oq pHnpi4aj0Bak8x4NCP8OiYLO1fJb2gG5/fD11DEiM3WTmUkbBlfd3bnWDCVhuoEiLONW +IUUdNzsyVS5c89ctuKOErFLiOKTHdz1xAJ3unBRjrjRkKb+ur8F2lLyiebcCu6xCXBo 9mqQYz3pXfukdNacq3Wb4g7hrm+Xr+2CXKbvIn1TQQm5OasaSi9p7C/WVHqwzdxU5hOl zfdw== X-Gm-Message-State: ANoB5pmwC0iMD1ubNHQ6hFOcgwPT34U+JZ280zy2hlJIIrsf1FkQB7D1 r1fILW5EV8kVLvtM7prTEo7ZErvYRd/AYepFd03Hwg== X-Google-Smtp-Source: AA0mqf4F3DDjCXcDZNjOHDv7HOXv55ZrwJY8PAYxDaDIKWp/7EopgFHllqtnyYZqC/Y9dH5TVaBIAEWv4YV5P1wITi4= X-Received: by 2002:a17:902:eac5:b0:189:f06e:fd93 with SMTP id p5-20020a170902eac500b00189f06efd93mr11179976pld.37.1671059341322; Wed, 14 Dec 2022 15:09:01 -0800 (PST) MIME-Version: 1.0 References: <20221128054820.1771-1-clin@suse.com> <20221128054820.1771-3-clin@suse.com> In-Reply-To: From: Saravana Kannan Date: Wed, 14 Dec 2022 15:08:25 -0800 Message-ID: Subject: Re: [PATCH v2 2/2] pinctrl: add NXP S32 SoC family support To: Linus Walleij Cc: Chester Lin , Fabio Estevam , Dong Aisheng , Shawn Guo , Jacky Bai , Pengutronix Kernel Team , s32@nxp.com, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Larisa Grigore , Ghennadi Procopciuc , Andrei Stefanescu , Radu Pirea , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Matthias Brugger , Matthew Nunez , Phu Luu An , Stefan-Gabriel Mirea Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Dec 9, 2022 at 3:26 AM Linus Walleij wrote: > > On Fri, Dec 9, 2022 at 5:39 AM Chester Lin wrote: > > > > Hi Linus and Fabio, > > > > Thanks for your time to review this patch! > > > > On Thu, Dec 08, 2022 at 10:37:36PM +0100, Linus Walleij wrote: > > > On Thu, Dec 8, 2022 at 12:04 AM Fabio Estevam wrote: > > > > > > > In other imx8m pinctrl drivers we pass: > > > (...) > > > > > +module_platform_driver(s32g_pinctrl_driver); > > > > > > > > And we also register it in arch_initcall() level. > > > > > > Do you really need that though? This driver certainly does not. > > > > > > I was under the impression that recent changes to the probe-order > > > logic has made most explicit arch_ etc initcall orderings surplus. > > > > > > > Could bool/tristate options in the Kconfig be the key point? > > > > Based on current design I prefer to build the s32g2 pinctrl driver as built-in > > rather than a loadable module. IIUC, when the driver is not built as module > > then the initcall ordering should still matter. > > It is true that if you compile something into a module then all initicalls > are the same: they are called when the module is loaded. > > But the remaining initcalls used to be assigned to core, arch, subsystem > etc in order for resources (such as clocks, regulators or pins) to be > available before the drivers that need them get probed. > > However there was first deferred probe to partially solve the problem > and recently a large and refined series that use the dependencies in > the device tree to resolve probe order. > > Saravana Kannan has been working tirelessly at this, issueing > git log --oneline --author="Saravana Kannan" > you will see the scope of this work. > Thanks Linus. For a system using DT, fw_devlink's goal is to make module load ordering or driver registration ordering irrelevant to proper functioning of the kernel/drivers. It should automatically figure out the dependencies and have the devices probe in the right order. It's already true for at least 80% of the cases for a system using DT. There are some known issues I'm either working on or have on my To do list. So, if you see a case where fw_devlink is not handling it correctly, please let me know. -Saravana