From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJAw6-0003ec-7r for barebox@lists.infradead.org; Tue, 31 Mar 2020 07:03:47 +0000 References: <20200330143915.663705-1-ahmad@a3f.at> <20200330143915.663705-6-ahmad@a3f.at> <20200331054526.GF27288@pengutronix.de> <08a304f9-cfd3-706d-0c4e-7725c3f965f6@pengutronix.de> <20200331065529.GI27288@pengutronix.de> From: Ahmad Fatoum Message-ID: <293d97e3-6c83-2fa6-fe55-4cb3606b09a7@pengutronix.de> Date: Tue, 31 Mar 2020 09:03:44 +0200 MIME-Version: 1.0 In-Reply-To: <20200331065529.GI27288@pengutronix.de> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "barebox" Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: [PATCH 6/8] pinctrl: stm32: fix up st,package into stm32mp nodes To: Sascha Hauer Cc: barebox@lists.infradead.org, Ahmad Fatoum Hi, On 3/31/20 8:55 AM, Sascha Hauer wrote: > On Tue, Mar 31, 2020 at 07:50:32AM +0200, Ahmad Fatoum wrote: >> Hi, >> >> On 3/31/20 7:45 AM, Sascha Hauer wrote: >>> On Mon, Mar 30, 2020 at 04:39:13PM +0200, Ahmad Fatoum wrote: >>>> Since Linux v5.1, the pinctrl driver can use the st,package property >>>> if provided to validate whether the ball to be configured exists >>>> on the package. Have barebox supply this property. >>>> >>>> Signed-off-by: Ahmad Fatoum >>>> --- >>>> arch/arm/dts/stm32mp151.dtsi | 16 ++++++++ >>>> drivers/pinctrl/pinctrl-stm32.c | 67 +++++++++++++++++++++++++++++++++ >>>> 2 files changed, 83 insertions(+) >>>> >>>> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi >>>> index 8f8249dbc479..2a70a747e76e 100644 >>>> --- a/arch/arm/dts/stm32mp151.dtsi >>>> +++ b/arch/arm/dts/stm32mp151.dtsi >>>> @@ -37,4 +37,20 @@ >>>> >>>> &bsec { >>>> barebox,provide-mac-address = <ðernet0 0x39>; >>>> + >>>> + soc_package: soc-package@43 { >>>> + reg = <0x43 1>; >>>> + bits = <3 3>; >>>> + read-only; >>>> + }; >>>> +}; >>>> + >>>> +&pinctrl { >>>> + nvmem-cells = <&soc_package>; >>>> + nvmem-cell-names = "soc-package"; >>>> +}; >>>> + >>>> +&pinctrl_z { >>>> + nvmem-cells = <&soc_package>; >>>> + nvmem-cell-names = "soc-package"; >>>> }; >>> >>> Why this detour over device tree? We already have get_cpu_package() and >>> could use it here. >> >> The pinctrl driver should also be compatible to the STM32 MCUs, which don't >> have this property. I tried calling get_cpu_package at first, but the ifdefery >> needed to keep the driver independent on CONFIG_ARCH_STM32MP looked ugly. > > The fixup for the device tree nodes doesn't necessarily have to be in > the pinctrl driver, it could be somewhere where you know get_cpu_package > is present and valid. It's the most natural place though.. >> Making it a device property solves this nicely IMO. > > I might agree if there wasn't the nvmem binding involved. The bsec driver is a nvmem driver anyway. How else I am supposed to access nvmem devices? The current code in arch/arm/mach-stm32mp/init.c issues direct secure monitor calls to read the bsec OTP. I'd prefer to get rid of this and have everything go through the bsec driver. Cheers Ahmad > > Sascha > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox