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 A2BF2C4332F for ; Wed, 14 Dec 2022 23:10:33 +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=0vgd2OeGv/3pYxlqbnlyET3OX/5dZgve8GQ5Vr1kmC0=; b=yhbFYEu02QHGxK qXXDBfi91ZaDDsa6kpXA0sd/97jkHQwy9O4fzvQYpyt+Un5HlbdS4CHdwPY1Mt2n230U0iZwJdv1E XYwKXg5FxAm/p74suFN+rSTS2cWl1t7GcNrn2W38gUJlnf/UgeLOg+TNfRUWME5f28PEh3E2WTVlT Mq57I5PwtvC2qVdz1d0/iWH+738PBfFAmDIX4RUut4ea++xexoB7VoeOZKlKNI2HETpPdWeu/r92w DHcGsr7P7StKtNH/2/vrovpkdn3WEZXlf99/DV5Extx0hylu/kMkl7FgMWDykHjkpihUohqlsitPg 563H/rnGdswcXXqSAgwg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5as7-0046LC-BD; Wed, 14 Dec 2022 23:09:07 +0000 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p5as4-0046Hr-HW for linux-arm-kernel@lists.infradead.org; Wed, 14 Dec 2022 23:09:05 +0000 Received: by mail-pj1-x1032.google.com with SMTP id q17-20020a17090aa01100b002194cba32e9so899537pjp.1 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=tV3VApPft9h0mD88RNmbjgj8wij/l4b9jIHp23ErgCsDVszrzE42WgkfGJaHBuE71T KETcHtTgTKQjoGxhYfyAgWnpn+PqwvDKErfJM7Wf82PjdvYmrEH9BaLVH/BqHg5XAJSe 8WY0JmTApdKY+ghZKXTpSFdkCdlHQDuPcK3b5Ne36y6JhEzhqocFH0GXhAk8SS+lARtf SxpcCCeszI1zKdWM/DAVc/k4FoUvFhKxYPZqxlFSAYUy6pR9qNPvNcCYozdGe+ODd0NV njn0l+ZoLGy96h0Bzye+QzzAfkLFn+lWLUGr+1uO5TpiOalWQNtw01skPKXubNmH7hHR fydQ== X-Gm-Message-State: ANoB5pm12V6NlTFqfzL1WnOJ8xEGOGAgleC1/mGB4oQQRRl5dSRX0jcp zoLxJNig/SQELY5cL9lB0EBBhZZbZ8whJqkBfN1+Aw== 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221214_150904_604636_C435308E X-CRM114-Status: GOOD ( 30.14 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel