Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3755728rwb; Fri, 30 Sep 2022 07:58:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6ZjSdUk/iU+rG2KrkI1tgcGgHsQ2sNYQxt5uxOKvz4TFFq/MVIdn4UN3QsjCC71rxEL5l0 X-Received: by 2002:a17:906:58c9:b0:782:83c:7aad with SMTP id e9-20020a17090658c900b00782083c7aadmr6664465ejs.608.1664549900535; Fri, 30 Sep 2022 07:58:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664549900; cv=none; d=google.com; s=arc-20160816; b=MEucsoDbHsr5I4+umfkSY7kwp1eel1W/8Q1E9hmzmRH2992qBl7WymwQxPZicfpOhe s8JRDhGN2qE1Ptksvt8n+NSkJeZW9OE0CAJ3W3IO9IV+sfNuH3yAnOsHQEFPNie89FC/ GPIPhlOUCr2sBD7Sc3A9WTOAjb4Yz/G4OvDnMMvOHZg0ETlmJRipgcVeRJbe0IoN59BM le9Wg0augIjYYVy0Jgz36iI1xNrsAQPtrn5gxDlVzQb4LmBC9YaYo92/mxNSDmmtNuYA EJ1A4+jnqFDvxLkZ+Dty0IaTuntD+e06xkpluf45KeBtkaCW9GQM02Bh40MIe8CxQf62 JO9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=U91awyFBtQ5MC9NqxvSXjeOW7So9kd/ePCrnvp0Lha8=; b=CoH+CG/tEnZq9PSGQH7EofDtwN61MlWjHvDrWNHv+aGjICiNvNEIpOGBfyl33efusr ecdL5Y5Pq96KlYfAAYVT8vER2l0pMTJIGAthL+oj1R89nviqA3toGwlkDBBUwoP76B7v Gzd3Hi3XOHf7UPW94Btl6QqEqodfHxSn6kzFUVxZsxBvWYiIasrtRYDQz0ymeLVng5qf 0WGg6Z6V++o+voF6hMn89+jPowzv0j0fXB1wZlSRotd+HWoNDwO43ac5EdiRpcMBoE4V dHjeNm3TO+f8vZVeSRGeF/vMOEPHLrX7ax5OY/7glMMFvLhSm9CZKxchZyGezPVj5k4/ XqMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ahCe/e+E"; 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 j11-20020a05640211cb00b00446dc8f5e44si2493584edw.243.2022.09.30.07.57.55; Fri, 30 Sep 2022 07:58:20 -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="ahCe/e+E"; 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 S231881AbiI3ObM (ORCPT + 99 others); Fri, 30 Sep 2022 10:31:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231177AbiI3ObH (ORCPT ); Fri, 30 Sep 2022 10:31:07 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF5F01117F; Fri, 30 Sep 2022 07:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664548259; x=1696084259; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=j26v+IkUVM1DJvy8r/Kyk/ns4U7hnATbQsuziy7CbQw=; b=ahCe/e+E7nUf6WJnv6966rr4mcaG0MDeFCRA01ukZiaVP1JZWgckt6od rKgdFepihJsOD72MZSKTAil7cqYGdoWJKxzQpDqzXZxZyHoRzqydPUk8P Kv+UvCt/Vt0EyF5SWfto6HI1r8gTTbb9p43UOh4C46kqTSCJgtG9tBfOt cTNHLtNEGan75/mw5OOQ2LDXW+s7Eac9ZiBMYvbJtEJ5IZvLZDVHrxeNx 9LgN5rPhiMYoX12+CKGsi1W+swAGjLsH46DvsfCEHH2a5oKYcX1bFck+A wXAFSJH0YWJgxhH+YlyaYI7/euuJconauNbpnNHK8s+MXFTwDFeTybe+r Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10486"; a="366252407" X-IronPort-AV: E=Sophos;i="5.93,358,1654585200"; d="scan'208";a="366252407" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2022 07:30:58 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10486"; a="867828260" X-IronPort-AV: E=Sophos;i="5.93,358,1654585200"; d="scan'208";a="867828260" Received: from punajuuri.fi.intel.com (HELO paasikivi.fi.intel.com) ([10.237.72.43]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2022 07:30:55 -0700 Received: from paasikivi.fi.intel.com (localhost [127.0.0.1]) by paasikivi.fi.intel.com (Postfix) with SMTP id 436E82021B; Fri, 30 Sep 2022 17:30:53 +0300 (EEST) Date: Fri, 30 Sep 2022 14:30:53 +0000 From: Sakari Ailus To: Greg Kroah-Hartman Cc: Andy Shevchenko , Heikki Krogerus , Bjorn Andersson , Prashant Malani , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Daniel Scally , "Rafael J. Wysocki" Subject: Re: [PATCH v2 1/5] device property: Keep dev_fwnode() and dev_fwnode_const() separate Message-ID: References: <20220928105746.51208-1-andriy.shevchenko@linux.intel.com> <20220928105746.51208-2-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE 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 Hi Greg, On Wed, Sep 28, 2022 at 01:05:20PM +0200, Greg Kroah-Hartman wrote: > On Wed, Sep 28, 2022 at 01:57:42PM +0300, Andy Shevchenko wrote: > > It's not fully correct to take a const parameter pointer to a struct > > and return a non-const pointer to a member of that struct. > > > > Instead, introduce a const version of the dev_fwnode() API which takes > > and returns const pointers and use it where it's applicable. > > > > Suggested-by: Sakari Ailus > > Fixes: aade55c86033 ("device property: Add const qualifier to device_get_match_data() parameter") > > Signed-off-by: Andy Shevchenko > > Acked-by: Heikki Krogerus > > Reviewed-by: Sakari Ailus > > --- > > drivers/base/property.c | 11 +++++++++-- > > include/linux/property.h | 3 ++- > > 2 files changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/base/property.c b/drivers/base/property.c > > index 4d6278a84868..699f1b115e0a 100644 > > --- a/drivers/base/property.c > > +++ b/drivers/base/property.c > > @@ -17,13 +17,20 @@ > > #include > > #include > > > > -struct fwnode_handle *dev_fwnode(const struct device *dev) > > +struct fwnode_handle *dev_fwnode(struct device *dev) > > { > > return IS_ENABLED(CONFIG_OF) && dev->of_node ? > > of_fwnode_handle(dev->of_node) : dev->fwnode; > > } > > EXPORT_SYMBOL_GPL(dev_fwnode); > > > > +const struct fwnode_handle *dev_fwnode_const(const struct device *dev) > > +{ > > + return IS_ENABLED(CONFIG_OF) && dev->of_node ? > > + of_fwnode_handle(dev->of_node) : dev->fwnode; > > +} > > +EXPORT_SYMBOL_GPL(dev_fwnode_const); > > Ick, no, this is a mess. > > Either always return a const pointer, or don't. Ideally always return a > const pointer, so all we really need is: > > const struct fwnode_handle *dev_fwnode(const struct device *dev); > > right? > > Yes, it will take some unwinding backwards to get there, but please do > that instead of having 2 different functions where the parameter type is > part of the function name. This isn't the 1980's... The problem with this approach is that sometimes non-const fwnode_handles are needed. On OF, for instance, anything that has something to do with refcounting requires this. Software nodes as well. One option which I suggested earlier was to turn dev_fwnode() into a macro and use C11 _Generic() to check whether the device is const or not. Being able to turn struct device pointers const is certainly not worth violating constness properties. -- Regards, Sakari Ailus