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 8611EC00528 for ; Mon, 31 Jul 2023 20:09:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230225AbjGaUJf (ORCPT ); Mon, 31 Jul 2023 16:09:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230239AbjGaUJe (ORCPT ); Mon, 31 Jul 2023 16:09:34 -0400 Received: from mgamail.intel.com (unknown [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 663ED1BCE; Mon, 31 Jul 2023 13:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690834169; x=1722370169; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=cuZ/s3KbQrL5FJUAvN0dudzHyrghoYL3rl94jhaDl/g=; b=ftHOvTCa8RPwzUspzwci+n0epOo/8hGt7/SAOCY3B1yycdtVZ9zH1ATu LtqB0usvz+YwmD45bUW7/XBvKQqOuAirwnwS8Dk1RRo7dHhIxTBvvYuFD aweXproy1LamJYF01ifVVppgGmjGaE9ZclLw+xX206WH1xeONGVYGIBeG uodfbJrXjpGqIA6YDtn4neJvdlVKp2SZ4gduzpZUwwy0zhKiwld9OBkr+ oBkBx0aegCbruFn8+t0q8EJ//lu+KBaMptV6iF8y1shp+tdWIrATbd0aH eGjHvS8/r4Z3UkD5Bc4a25xEY4IwG4oIote1SSi7G6CCDRpU+CVd8RWzD A==; X-IronPort-AV: E=McAfee;i="6600,9927,10788"; a="354039273" X-IronPort-AV: E=Sophos;i="6.01,245,1684825200"; d="scan'208";a="354039273" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jul 2023 13:09:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10788"; a="852167161" X-IronPort-AV: E=Sophos;i="6.01,245,1684825200"; d="scan'208";a="852167161" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga004.jf.intel.com with ESMTP; 31 Jul 2023 13:09:26 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qQZCm-004BwP-23; Mon, 31 Jul 2023 23:09:24 +0300 Date: Mon, 31 Jul 2023 23:09:24 +0300 From: Andy Shevchenko To: Jarkko Nikula Cc: Mario Limonciello , Wolfram Sang , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Mika Westerberg , Jan Dabros , Andi Shyti Subject: Re: [PATCH v1 4/9] i2c: designware: Propagate firmware node Message-ID: References: <20230725143023.86325-1-andriy.shevchenko@linux.intel.com> <20230725143023.86325-5-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 Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org On Fri, Jul 28, 2023 at 03:25:58PM +0300, Jarkko Nikula wrote: > On 7/25/23 17:30, Andy Shevchenko wrote: > > Propagate firmware node by using a specific API call, i.e. device_set_node(). ... > > + device_set_node(&dev->adapter.dev, dev_fwnode(dev->dev)); > > Would this be better to put in the same place where ACPI_COMPANION_SET() is > removed like below? I'd keep this static inline function in the header file > as simple as possible. All extra code might invite adding even more. We come again to the duplication and prone to deviation code, I wouldn't like to go this way. The idea of this call is to unify and avoid mistakes, like updating only in ACPI or DT (or any new one if happens in the future) case and leaving the second one unconsidered. That said, I would rather drop this patch until i2c core will take this once for all (may be never in the reasonable future :-). -- With Best Regards, Andy Shevchenko