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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEFC8C77B60 for ; Thu, 23 Mar 2023 15:00:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231935AbjCWPAe (ORCPT ); Thu, 23 Mar 2023 11:00:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231923AbjCWPA2 (ORCPT ); Thu, 23 Mar 2023 11:00:28 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69D851912A; Thu, 23 Mar 2023 08:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679583626; x=1711119626; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=p1yP5VaKxRh8aNw09SSnNje/p5ZzINNB14cTYNhYeLc=; b=SNloEObLSCun2Eo6EjENRT8JmSgWjzzslSc8LKjEFgnUNGkJQGgv2ceb Ipu5besLcZUG3NS+SlnxS+oNjGqi8IACvBRYqJXKdzqN9RtXBxnCOBSed GCI8kea4OpwDk3yxgacjJeMWW4oHKGIdx99zi67GMshtHL6UT7/xyx1a+ PJ00Jq5KUhw4hLb9w2YGvPQSTLcM2N/b/rHoq8f9TY1B+3/ftX/QNCcEH PjVn+3kLd4uKTXjvJuanmWNI+2W2Ob1K6CMcHRvCHDZypFxHNRm5IdCWo NTh1rppr3MOltBXKMOM+ieZkCwRZwIsiwQt4tT1PdXYwx4hJq2kd5LAcJ A==; X-IronPort-AV: E=McAfee;i="6600,9927,10658"; a="323372199" X-IronPort-AV: E=Sophos;i="5.98,285,1673942400"; d="scan'208";a="323372199" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Mar 2023 08:00:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10658"; a="746739875" X-IronPort-AV: E=Sophos;i="5.98,285,1673942400"; d="scan'208";a="746739875" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga008.fm.intel.com with ESMTP; 23 Mar 2023 08:00:11 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pfMQC-007Y3R-2S; Thu, 23 Mar 2023 17:00:08 +0200 Date: Thu, 23 Mar 2023 17:00:08 +0200 From: Andy Shevchenko To: "Russell King (Oracle)" Cc: Andrew Lunn , Heiner Kallweit , Daniel Scally , "David S. Miller" , Eric Dumazet , Florian Fainelli , Greg Kroah-Hartman , Heikki Krogerus , Jakub Kicinski , linux-acpi@vger.kernel.org, netdev@vger.kernel.org, Paolo Abeni , "Rafael J. Wysocki" , Sakari Ailus , Vladimir Oltean Subject: Re: [PATCH RFC net-next 3/7] net: dsa: use fwnode_get_phy_mode() to get phy interface mode Message-ID: References: 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 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Mar 23, 2023 at 02:49:01PM +0000, Russell King (Oracle) wrote: > On Thu, Mar 23, 2023 at 04:38:29PM +0200, Andy Shevchenko wrote: > > On Thu, Mar 23, 2023 at 02:31:04PM +0000, Russell King (Oracle) wrote: > > > On Thu, Mar 23, 2023 at 04:03:05PM +0200, Andy Shevchenko wrote: > > > > On Wed, Mar 22, 2023 at 12:00:06PM +0000, Russell King (Oracle) wrote: ... > > > > > + struct fwnode_handle *fwnode; > > > > > > > > > + fwnode = of_fwnode_handle(dp->dn); > > > > > > > > const struct fwnode_handle *fwnode = of_fwnode_handle(dp->dn); > > > > > > > > ? > > > > > > Why const? > > > > Do you modify its content on the fly? > > Do you want to litter code with casts to get rid of the const? > > > For fwnode as a basic object type we want to reduce the scope of the possible > > modifications. If you don't modify and APIs you call do not require non-const > > object, use const for fwnode. > > Let's start here. We pass this fwnode to fwnode_get_phy_mode(): > > include/linux/property.h:int fwnode_get_phy_mode(struct fwnode_handle *fwnode); > > Does fwnode_get_phy_mode() alter the contents of the fwnode? Probably > not, but it doesn't take a const pointer. Therefore, to declare my > fwnode as const, I'd need to cast the const-ness away before calling > this. So, fix the fwnode_get_phy_mode(). Is it a problem? > Then there's phylink_create(). Same problem. So, fix that. Is it a problem? > So NAK to this const - until such time that we have a concerted effort > to making functions we call which do not modify the "fwnode" argument > constify that argument. Otherwise it's just rediculously crazy to > declare a variable const only to then litter the code with casts to get > rid of it at every call site. > > Please do a bit of research before making suggestions. Thanks. So, MAK to your patch. You can fix that, and you know that. P.S. Please, move that phy thingy away from property.h, it doesn't belong there. -- With Best Regards, Andy Shevchenko