From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D8F32153C1 for ; Fri, 24 Oct 2025 16:03:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761321831; cv=none; b=rW6IC9WphaY5Y/2e/tvy7BOpu8vr2D8ccv4ymofQHq+7DUof2WzEd7tnACQqcIiwKZZpsIVKM9jhOpWrJvZGK01X7YpqtzksxlCF2Q2ipAEP5CpaXC/IQK0xdsZ6Q63n0l9+r+9aAishh18O3NRAEcYamTAhgRFMpfdS7O6P7b8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761321831; c=relaxed/simple; bh=4rQ06hcRDPh06TcIr4Hhsm2kdiwKuNYxumRXFNrUjJA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=joe6FQClezer77/ddQFVWihMr9QQf/SK2UBSonJanoe4W7c54VzfgaZ/r+06DMFgGEjvftc9lHNukK8Oo3VKd8+Xt1ysUQQEYGWu8gltBUtF+pitsouX3Lzo+QWNSDXqSk2dIIkkwPK4LhErwYuPrNb+VCFyM1GakzJhUT59BAw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=D2uYRx1h; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="D2uYRx1h" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761321829; x=1792857829; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=4rQ06hcRDPh06TcIr4Hhsm2kdiwKuNYxumRXFNrUjJA=; b=D2uYRx1hfDysVVfPIVU9Ny2dvhk7A44UUJsD4sG6HaNhqZEPPhcEspHQ gMqI87RRh6N9kXYlq5eanAs55luYOaZDCzw0lNEkTJ/DyrRPviEIHXtbW iz7RnxQJjj1mRzl5WPmdZhiat6goRfv/6DKK6sAdvVUaWBMomjgJXA9iM Fl1C+8Wj+u+J32J4DfuMyFIK7zRfDIeiUClWVHRt7E4fe0DUciH6buxsQ 2pOFrw6nkL6+7GK57Y0pAY70LufdHoiMOS2DF0DkHOFyA5u2bz5pn01y3 M0OUCozi2rC3aqM9vhs2FoudenkUv4+k4GsXK7wwU7wLhCVWrcEZp1M00 A==; X-CSE-ConnectionGUID: sHJuIaEpSnKGaNThlHAtxw== X-CSE-MsgGUID: 78prEfOxRdGBJr/Uq3Lgag== X-IronPort-AV: E=McAfee;i="6800,10657,11586"; a="73794039" X-IronPort-AV: E=Sophos;i="6.19,252,1754982000"; d="scan'208";a="73794039" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2025 09:03:48 -0700 X-CSE-ConnectionGUID: oM1QeLgRR2izo7nsOkSYWQ== X-CSE-MsgGUID: nRGZyRpfSYK4S0x3HQThpw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,252,1754982000"; d="scan'208";a="215117928" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO ashevche-desk.local) ([10.245.245.147]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2025 09:03:45 -0700 Received: from andy by ashevche-desk.local with local (Exim 4.98.2) (envelope-from ) id 1vCKGT-00000002Cpo-42le; Fri, 24 Oct 2025 19:03:41 +0300 Date: Fri, 24 Oct 2025 19:03:41 +0300 From: Andy Shevchenko To: Frank Li Cc: Alexandre Belloni , Miquel Raynal , Jonathan Cameron , David Lechner , Nuno =?iso-8859-1?Q?S=E1?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev, linux-iio@vger.kernel.org, joshua.yeong@starfivetech.com, devicetree@vger.kernel.org Subject: Re: [PATCH v6 1/5] i3c: Add HDR API support Message-ID: References: <20251014-i3c_ddr-v6-0-3afe49773107@nxp.com> <20251014-i3c_ddr-v6-1-3afe49773107@nxp.com> Precedence: bulk X-Mailing-List: imx@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Fri, Oct 24, 2025 at 10:03:22AM -0400, Frank Li wrote: > On Fri, Oct 24, 2025 at 09:13:27AM +0300, Andy Shevchenko wrote: > > On Thu, Oct 23, 2025 at 07:53:15PM -0400, Frank Li wrote: > > > On Thu, Oct 23, 2025 at 09:22:55PM +0300, Andy Shevchenko wrote: > > > > On Thu, Oct 23, 2025 at 11:18:37AM -0400, Frank Li wrote: > > > > > On Thu, Oct 23, 2025 at 11:23:39AM +0300, Andy Shevchenko wrote: > > > > > > On Tue, Oct 14, 2025 at 12:40:00PM -0400, Frank Li wrote: ... > > > > > > > +/* keep back compatible */ > > > > > > > +#define i3c_priv_xfer i3c_xfer > > > > > > > > > > > > How many of the current users do this? Can't we just rename treewide? > > > > > > > > > > git grep -r priv_xfer drivers/ > > > > > > > > `git grep -lw ...` is a better approach :-) > > > > > > > > > drivers/base/regmap/regmap-i3c.c: struct i3c_priv_xfer xfers[] = { > > > > > drivers/base/regmap/regmap-i3c.c: return i3c_device_do_priv_xfers(i3c, xfers, 1); > > > > > drivers/base/regmap/regmap-i3c.c: struct i3c_priv_xfer xfers[2]; > > > > > drivers/base/regmap/regmap-i3c.c: return i3c_device_do_priv_xfers(i3c, xfers, 2); > > > > > drivers/hwmon/lm75.c: struct i3c_priv_xfer xfers[] = { > > > > > drivers/hwmon/lm75.c: ret = i3c_device_do_priv_xfers(i3cdev, xfers, 2); > > > > > drivers/hwmon/lm75.c: struct i3c_priv_xfer xfers[] = { > > > > > drivers/hwmon/lm75.c: return i3c_device_do_priv_xfers(i3cdev, xfers, 1); > > > > > drivers/i3c/device.c:int i3c_device_do_xfers(struct i3c_device *dev, struct i3c_priv_xfer *xfers, > > > > > drivers/i3c/master.c: if (!ops->priv_xfers && !ops->i3c_xfers) > > > > > drivers/i3c/master.c: if (!master->ops->priv_xfers) > > > > > drivers/i3c/master.c: return master->ops->priv_xfers(dev, xfers, nxfers); > > > > > drivers/i3c/master/dw-i3c-master.c:static int dw_i3c_master_priv_xfers(struct i3c_dev_desc *dev, > > > > > drivers/i3c/master/dw-i3c-master.c: struct i3c_priv_xfer *i3c_xfers, > > > > > drivers/i3c/master/dw-i3c-master.c: .priv_xfers = dw_i3c_master_priv_xfers, > > > > > drivers/i3c/master/i3c-master-cdns.c:static int cdns_i3c_master_priv_xfers(struct i3c_dev_desc *dev, > > > > > drivers/i3c/master/i3c-master-cdns.c: struct i3c_priv_xfer *xfers, > > > > > drivers/i3c/master/i3c-master-cdns.c: .priv_xfers = cdns_i3c_master_priv_xfers, > > > > > drivers/i3c/master/mipi-i3c-hci/core.c:static int i3c_hci_priv_xfers(struct i3c_dev_desc *dev, > > > > > drivers/i3c/master/mipi-i3c-hci/core.c: struct i3c_priv_xfer *i3c_xfers, > > > > > drivers/i3c/master/mipi-i3c-hci/core.c: .priv_xfers = i3c_hci_priv_xfers, > > > > > drivers/i3c/master/renesas-i3c.c:static int renesas_i3c_priv_xfers(struct i3c_dev_desc *dev, struct i3c_priv_xfer *i3c_xfers, > > > > > drivers/i3c/master/renesas-i3c.c: .priv_xfers = renesas_i3c_priv_xfers, > > > > > drivers/i3c/master/svc-i3c-master.c: struct i3c_priv_xfer *xfer; > > > > > drivers/i3c/master/svc-i3c-master.c: * at svc_i3c_master_priv_xfers(). > > > > > drivers/i3c/master/svc-i3c-master.c:static int svc_i3c_master_i3c_xfers(struct i3c_dev_desc *dev, struct i3c_priv_xfer *xfers, > > > > > drivers/net/mctp/mctp-i3c.c: struct i3c_priv_xfer xfer = { .rnw = 1, .len = mi->mrl }; > > > > > drivers/net/mctp/mctp-i3c.c: rc = i3c_device_do_priv_xfers(mi->i3c, &xfer, 1); > > > > > drivers/net/mctp/mctp-i3c.c: struct i3c_priv_xfer xfer = { .rnw = false }; > > > > > drivers/net/mctp/mctp-i3c.c: rc = i3c_device_do_priv_xfers(mi->i3c, &xfer, 1); > > > > > > > > > > After this patch merged, I can clean up it at difference subsytem. After > > > > > all cleanup done, we can safely remove this define. > > > > > > > > I counted 9. I think it's not a big deal to convert all of them at once without > > > > leaving an intermediate state. But this is a call for the I³C subsystem maintaiiner. > > > > > > There also are other cleanup works. The key point is that everyone agree my > > > HDR solution. Cleanup these is not big deal. I am not sure how to avoid > > > build broken at difference subsystem. > > > > > > After this patch merge, cleanup will be easier and safer. > > > > Then leave that renaming to the cleanup series. No need to use a define, just > > use the old function name. > > Using old function name for HDR will be very strange and conflict with > spec's name convention. > > The term 'private' transfer in i3c spec is specific for SDR transfer. It > is neccessary steps to complete whole naming switches. Right, but this out of scope OR a prerequisite to this series. My point that these two shouldn't be mixed and one left half-baked. -- With Best Regards, Andy Shevchenko