From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBF1233F582 for ; Thu, 30 Jul 2026 12:14:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785413659; cv=none; b=HciwAKChOs+pw/QDVhVP9KaX1gwo2Gvd9RxVDvztBjLfNUCUIQGGaTOsWCgT4X3/1attauv+b0wbQUfIiLKhzarB8hVdO2+QCNVhYk6+kg2btmNT3HDcpbp41hW1JVgwtkPfIqgDJ6bUAPRbzhwYtpzLM2LrzFmd5rPHjdAW8pE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785413659; c=relaxed/simple; bh=BJ+cWhYC6dqD6hTCTqd1x42LkssBMGfB2WTF8cxtnfQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pxnDownrSqEk6Qb3C97aQbBcNl8eFBPkOSh9Dbaoj/7304nQiNpwHyVc7W8ZZx7lMdCUtSumfcrVu+pvb7beoF0L+NvKyLiCMFH8edlcLoGPlDy0n/UYcdANeaOKx3t9f2MaBwQyiLdrdNGE5nyOFxG9z+OcoutjxQbzxQL42NQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QpWYFZti; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QpWYFZti" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D7FB1F000E9; Thu, 30 Jul 2026 12:14:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785413657; bh=ymHKN/BJa2+0pQ3DOlaBBtFOqaY7h/grwRM8s4BKdwc=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=QpWYFZtiv7xvBiD8yhhxjDR2I2Pxtdoj+NdAO8DyGiiTwd4gadDiR6vxblENSgQfX uFyV8YPD4UFbBzs9ONRhUpq5rNQVbgT/Dism5miL278jpJrPywtD856VCMMhPTn19g AK41e+OIieKxQsCeMpzobggMAUCCe2HEFu1MyAx5Eq0bSUizDgBYHiiR32/pMNkqCu 6Ev5KnnDPgr8KUS+AGhS767CbP9EHAZxhAB9qlB0gG4QRR3KWK7g8jpIWzNLRTE6/X B5xvZbremozqKo3xssG6J4qhtATPnModw+eXSJ21hsjYV9K+0NEs5RMWOCPI4phGl1 /3Se2nMv/k9qg== Message-ID: <59156118-27b2-453d-81b9-86a3d411a855@kernel.org> Date: Thu, 30 Jul 2026 14:14:13 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] soc: fsl: qe: properly scan GPIO nodes at startup To: Krzysztof Kozlowski Cc: linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski , Herve Codina , Paul Louvel References: <04dc047f8958a78a920f0a88ca3bd8bf70c56187.1785333986.git.chleroy@kernel.org> <223afb76-9f6f-48a1-a5c5-beb1a641916c@kernel.org> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 30/07/2026 à 14:05, Krzysztof Kozlowski a écrit : > On 30/07/2026 14:01, Christophe Leroy (CS GROUP) wrote: >> >> >> Le 30/07/2026 à 13:14, Krzysztof Kozlowski a écrit : >>> On 29/07/2026 16:10, Christophe Leroy (CS GROUP) wrote: >>>> Before commit 156460811def ("soc: fsl: qe: Change GPIO driver to a >>>> proper platform driver") qe_add_gpiochips() was walking the device >>>> tree to find all nodes with compatible "fsl,mpc8323-qe-pario-bank". >>>> >>>> After that commit the discovery is handled by the platform core, >>>> therefore it is necessary to call of_platform_default_populate() on >>>> the par_io node. >>>> >>>> Fixes: 156460811def ("soc: fsl: qe: Change GPIO driver to a proper platform driver") >>>> Signed-off-by: Christophe Leroy (CS GROUP) >>>> --- >>>> drivers/soc/fsl/qe/qe_io.c | 15 +++++++++++++++ >>>> 1 file changed, 15 insertions(+) >>>> >>>> diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c >>>> index a5e2d0e5ab51..02ca556c8db0 100644 >>>> --- a/drivers/soc/fsl/qe/qe_io.c >>>> +++ b/drivers/soc/fsl/qe/qe_io.c >>>> @@ -15,6 +15,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #include >>>> #include >>>> @@ -184,3 +185,17 @@ int par_io_of_config(struct device_node *np) >>>> return 0; >>>> } >>>> EXPORT_SYMBOL(par_io_of_config); >>>> + >>>> +static int __init par_io_populate(void) >>>> +{ >>>> + struct device_node *np = of_find_node_by_name(NULL, "par_io"); >>> >>> No, node name must not be ABI. Especially wrong node name. >> >> What's wrong with the node name ? > > 1. It causes W=2 warnings (which we might move to W=1 at some point) > 2. It is not generic and DT spec asks for generic node names, although > maybe this part of code follows more of ePAPR than DT. But ePAPR v1.1 > also was asking for generic node names. > >> >> Regardless, I messed it up, I wanted to use type but copy/pasted >> of_find_node_by_name(NULL, "par_io") from quirk_mpc8360e_qe_enet10() in >> arch/powerpc/platforms/83xx/km83xx.c instead. >> >> Is it OK to use of_find_node_by_type(NULL, "par_io") instead ? > > Well, depends. Is it a documented ABI? In Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe/par_io.txt: Required properties: - device_type : should be "par_io". - reg : offset to the register set and its length. - num-ports : number of Parallel I/O ports Example: par_io@1400 { reg = <1400 100>; #address-cells = <1>; #size-cells = <0>; device_type = "par_io"; num-ports = <7>; ucc_pin@1 { ...... }; Is it OK ? Thanks, Christophe