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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 47B58C6FD19 for ; Mon, 13 Mar 2023 16:53:35 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 38E2C85D3C; Mon, 13 Mar 2023 17:53:31 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="nyJCDDrr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1A71485D34; Mon, 13 Mar 2023 17:53:28 +0100 (CET) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 0D6E885D64 for ; Mon, 13 Mar 2023 17:53:23 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jbx6244@gmail.com Received: by mail-ed1-x529.google.com with SMTP id x3so51301124edb.10 for ; Mon, 13 Mar 2023 09:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678726402; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vo/G6vEqBKd/PHrK0k14TkkZsmRUyuOSjkR9i1+7TIw=; b=nyJCDDrrpb6V4ukQzr/WEcbzlNa+2vnLVKSQOEX7IaDLBtnSTg5mhXh/5LKVedksI/ sxTP2IksIPcqsV3/enRY3xb87Q49ptFJxpG0fVusth+8mxVF6Z2GY0Z8futoPGvnCC3j UGIytuzI9AtTGKPXwaWDTFS0N59QOP5BjUSPUQLlMRxVTJyhFUJ9GQpzNiE1xOjqu2il eeTWcdTulQ6kTSvOPUt+MhKYCbmxwAFQpdUvjaYLmARO2cjFjTsYvJ7EgcVJkY67tovo V0uGD6pRcUTpKu+pOxFeyW9Pm6rAA8/7U4s/mPGNxx4tHZ70xmhiIjBfaUJwZDwKIiJR kyXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678726402; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vo/G6vEqBKd/PHrK0k14TkkZsmRUyuOSjkR9i1+7TIw=; b=NP+YMLpKIrxJ1VuPQ1we2lXbTT+yXW4K8/gDwNuLk48XGg3D27plpjaEopATSVZUHe PleXel+w8TP/ITCUb+k5DHFNpPM2cFxJoSEJ7hueS38FsWy2/SA9dTA5nFxNnNGQpla9 SDWI0bQSpFEeUKT3drQir6n8dhRyGwNHntW4R+7fJwGiLA/kJk3pqKojYFRstI74r7F2 0X24FsXShPKN8PgDtHz2G+EX1ZEw0sJUDHEMyasLgr6dGU00Dg6H5y20kxx72h66HRpi ltODDVWpP5EAmK8TR5mR7QznwqurG/AAKmx65Cb8ZTZ+OI0/PWmI0HQgRZyc3G+AOISm 1kQA== X-Gm-Message-State: AO0yUKWdcya8RS1wQAQCdSBH4fibYxQGMLbPQV8t5Ff/EU0yo93jFu/C 7l2k/A0BNaN6/rvRB5yRLgU= X-Google-Smtp-Source: AK7set8JI2A+2L3lNZ1/Mo1jq841o2xRMaaj85/M7B55IiPkOHKhvhLFi1RDW/8WmyD2cnvrRVtnSw== X-Received: by 2002:a17:906:384a:b0:8f0:143d:ee28 with SMTP id w10-20020a170906384a00b008f0143dee28mr34058568ejc.16.1678726402452; Mon, 13 Mar 2023 09:53:22 -0700 (PDT) Received: from [192.168.2.2] (81-204-249-205.fixed.kpn.net. [81.204.249.205]) by smtp.gmail.com with ESMTPSA id y3-20020a170906914300b0092178941cb6sm32578ejw.39.2023.03.13.09.53.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Mar 2023 09:53:21 -0700 (PDT) Message-ID: Date: Mon, 13 Mar 2023 17:53:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v8 13/24] rockchip: rk3288: syscon_rk3288: store syscon platdata in regmap To: John Keeping Cc: dario.binacchi@amarulasolutions.com, michael@amarulasolutions.com, sjg@chromium.org, philipp.tomsich@vrull.eu, kever.yang@rock-chips.com, u-boot@lists.denx.de, yifeng.zhao@rock-chips.com References: <6e68b95b-bf55-647d-df5e-cbbce20257f0@gmail.com> Content-Language: en-US From: Johan Jonker In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On 3/13/23 14:26, John Keeping wrote: > On Mon, Mar 13, 2023 at 01:30:57AM +0100, Johan Jonker wrote: >> The Rockchip SoC rk3288 has 2 types of device trees floating around. >> A 64bit reg size when synced from Linux and a 32bit for U-boot. >> A pre-probe function in the syscon class driver assumes only 32bit. >> For other odd reg structures the regmap must be defined in the individual >> syscon driver. Store rk3288 platdata in a regmap before pre-probe >> during bind. >> >> Signed-off-by: Johan Jonker >> --- > > What is special about the rk3288 syscon that means the driver needs this > handling? Isn't this a general problem for DTs with 64-bit addresses on > 32-bit systems that could be solved in syscon-uclass.c? The dtd structure is only know to the driver with the SoC orientated compatible string. I see guessing the "reg" size more as a legacy that we keep using for existing drivers and should be deprecated. > > I suspect it's difficult to handle the general case since #memory-cells > may be difference for difference syscons so a global constant doesn't > work, but the approach in this patch seems incredibly verbose for You are right here, but other then rk3288 I don't see that happen for other 32bit Rockchip SoCs. It's more verbose, because struct syscon_uc_info is not there yet in the bind fase. (ie. calloc) > something that is likely to be needed for many platforms. > > Could we use driver flags with something like: > > .flags = of_platdata_reg_size(struct rockchip_rk3288_noc_plat), Driver flags might solve only the "reg" size part, but not the ARRAY_SIZE and the unknown "reg" property location part. > > and this untested macro: > > #define of_platdata_reg_size(s) \ > ((sizeof(((struct rockchip_rk3288_noc_plat *) 0)->reg) == 64) ? \ > DM_FLAGS_PLATDATA_REG_64BIT : 0) This would create a parallel data flow of a "size flag and ARRAY_SIZE variable + data" in a structure to the syscon class driver that also must be stored somewhere, while we could do the thing correct in the regmap structure right away. Johan