Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp2345731iob; Fri, 6 May 2022 00:02:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuZIGjoyNMsNaSitYayF8lliOOgfAS4Ol8+PQ8NSm2KgzXoQ4qmBlDqn2Q6CR3Bbp5EHab X-Received: by 2002:a17:90a:ee84:b0:1d9:27f3:eeeb with SMTP id i4-20020a17090aee8400b001d927f3eeebmr10906018pjz.66.1651820531858; Fri, 06 May 2022 00:02:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651820531; cv=none; d=google.com; s=arc-20160816; b=Tmn+Q5YxgxugIPZxxmBio/NMgaf2fOLh0w0z5hOcIfuG7sSpaGQ5vPEbt3t4Nizk/t /t+L2Tb2URDMy6acqgNDbI4ZCXbTB4aTUOdgVeoXOUlzG3U5T2Ux6mdeGLrYFYriilj5 RB7dzWXe5GHHS2k1tLCVuDH979ZZmtVwZ6L71/wkYo5jb/IXk1Zb02nG5M7HoIKsC3/Y TxgATF+17Q3vj9KbGpinAHyYf4ziJs/h4+P8Q0EqVf6OVYLBxudYue4MJKeYCO/DHQLj 8QJulql6Ove5LTS780ekDNE1JQYFkOV8+uj9HiIZc6EKHuxFxTAXY7XlJ8wna2uooT76 EgrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=KJp9JyoWPqwUbh0KWB3wxu5W5C3T1ha8Qd2x9Ch3LEk=; b=BCsFViTcoI2WM5mO+hJwODXYTJOnAksAqs1beNKv9SaXF8+dE79Gbta5/GoSmDmcm5 zvbU8TJFJzU7nKvkMwXBXzcoXe1jEQUgg+vDhXYrlY1VS8qbIl3ah+6gOyh/jk8U8i3O JqrAXa6ulD2tJ4znpuDfFjAyNtkv9SJucQVurimq0II8wL/INDWzqaBPsQIryoNKJ4C2 F/uO2SYXXviXxXdGaa9fsrgR038B0c22VBI614cXUaSe2dovtXM3rd+x1e5WmkmWDo8+ aBEPDloOOXsRTxeS4fu218HPGuyakDNUrbW52XScl0oSg/npqQU6iXcMovoaC8Y6cMcG wuMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=dHgtXRnp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 7-20020a630907000000b003c600669407si3877575pgj.138.2022.05.06.00.01.56; Fri, 06 May 2022 00:02:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=dHgtXRnp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350033AbiEDM4i (ORCPT + 99 others); Wed, 4 May 2022 08:56:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236375AbiEDM4f (ORCPT ); Wed, 4 May 2022 08:56:35 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D9DF2AE12; Wed, 4 May 2022 05:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651668779; x=1683204779; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=TAR0OSTmgPalp1GT6kqlq85T8vW4wKavBhWP3MJ2K2A=; b=dHgtXRnpPjjVlbRuYsjwUesITQQlcyEAnpWwSqK8E3QnR3mvzJAk3x94 Hu9ol/3/ksX4ORH3dx2tVizgJRR0+gz8k9VyzFP6adFTdT1874uzhCCgL 53vkHKHmzs182tA6TySkrYpLdZubHRjf2xAKlqVuHhKUfiznQLBI0p3bL JDOPsS/V9HQqtff/dd6WG2GAYw7LUiTRlIsMTZkesDf5ELsNhunkvacAQ ECQ32eEAIs892VDOTYhsDJ6WQ3GEzNERyp1SuQgTXHuaBZveF0/YDEiil IJWEZ0ENBVozZ3mkQphKUS0r8IIOwTRbrwRo64fW2SnagoJs9alYZNg/a A==; X-IronPort-AV: E=McAfee;i="6400,9594,10336"; a="292946346" X-IronPort-AV: E=Sophos;i="5.91,198,1647327600"; d="scan'208";a="292946346" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2022 05:52:58 -0700 X-IronPort-AV: E=Sophos;i="5.91,198,1647327600"; d="scan'208";a="734387769" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2022 05:52:52 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1nmEUq-00Bssm-FU; Wed, 04 May 2022 15:52:48 +0300 Date: Wed, 4 May 2022 15:52:48 +0300 From: Andy Shevchenko To: Lee Jones Cc: Wolfram Sang , Jean Delvare , Heiner Kallweit , Hans de Goede , Linus Walleij , Tan Jui Nee , Kate Hsuan , Jonathan Yong , linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-i2c@vger.kernel.org, linux-gpio@vger.kernel.org, platform-driver-x86@vger.kernel.org, Borislav Petkov , Mauro Carvalho Chehab , Tony Luck , James Morse , Robert Richter , Jean Delvare , Peter Tyser , Mika Westerberg , Andy Shevchenko , Mark Gross , Henning Schild Subject: Re: [PATCH v4 5/8] mfd: lpc_ich: Add support for pinctrl in non-ACPI system Message-ID: References: <20220131151346.45792-1-andriy.shevchenko@linux.intel.com> <20220131151346.45792-6-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 15, 2022 at 05:29:51PM +0000, Lee Jones wrote: > On Tue, 15 Feb 2022, Andy Shevchenko wrote: > > On Tue, Feb 15, 2022 at 04:54:00PM +0000, Lee Jones wrote: > > > On Mon, 31 Jan 2022, Andy Shevchenko wrote: > > Thank you for the review, my answers below. ... > > > > +static struct resource apl_gpio_resources[APL_GPIO_NR_DEVICES][2] = { > > > > + [APL_GPIO_NORTH] = { > > > > + DEFINE_RES_MEM(APL_GPIO_NORTH_OFFSET, 0x1000), > > > > > > Are these 0x1000's being over-written in lpc_ich_init_pinctrl()? > > > > > > If so, why pre-initialise? > > > > You mean to pre-initialize the offsets, but leave the length to be added > > in the function? It can be done, but it feels inconsistent, since we would > > have offsets and lengths in different places for the same thingy. That said, > > I prefer current way for the sake of consistency. > > Don't you over-write this entry entirely? > > for (i = 0; i < ARRAY_SIZE(apl_gpio_devices); i++) { > struct resource *mem = &apl_gpio_resources[i][0]; > > /* Fill MEM resource */ > mem->start += base.start; > mem->end += base.start; > mem->flags = base.flags; > } > > Oh wait, you're just adding the base value to the offsets. > > In which case that comment is also confusing! I have realised that in current form it has a bug (*), so I re-do a bit the way that comment stays and the actual actions will be to *fill* the resource. *) unbinding and binding back will bring us to the completely wrong resources. -- With Best Regards, Andy Shevchenko