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 AA5DCC004D4 for ; Wed, 18 Jan 2023 08:19:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230087AbjARITM (ORCPT ); Wed, 18 Jan 2023 03:19:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229862AbjARIRm (ORCPT ); Wed, 18 Jan 2023 03:17:42 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA5776D6BE; Tue, 17 Jan 2023 23:46:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674028022; x=1705564022; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+QFXAEE/I1e+ZlCichsm9XHIaVDx4dSZnoWCivSwEaY=; b=PtHr7507Cc91CPZHgkRPNwLBmP/s/8zGjZyu3XiMRtg+ZPwEa46OR8tv QYyKnAnZwtc8EfLh/gop36PJERFsIx+VhTt0ouBZPiZTpNC9UzH52KAgE W4eYDTNReQfmzHYhd6pBDZQUANIJtYwBfOoIk42Jy9JAro9aDlFACP2Qs WNbfxN0romXGMPRP08pnS2fTKS8fJl2yGh3hi59cCeuwnNhKpjqRyAAoe qhTX2V3p4FY7nMrnM+O3AO55hfEQSmce7QaBeFuf/tLGqzWwx+zI2y/4j /JJPQr2EinN2B1Ps6Ttsd/Ph72CD5/QsiYzQ40Np/sfL1DhEoIWgMw0tP g==; X-IronPort-AV: E=McAfee;i="6500,9779,10593"; a="322611688" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="322611688" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2023 23:46:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10593"; a="728085837" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="728085837" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga004.fm.intel.com with ESMTP; 17 Jan 2023 23:46:17 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pI39C-00Azu7-2C; Wed, 18 Jan 2023 09:46:14 +0200 Date: Wed, 18 Jan 2023 09:46:14 +0200 From: Andy Shevchenko To: Marijn Suijten Cc: Jonathan Cameron , Nuno =?iso-8859-1?Q?S=E1?= , linux-arm-msm@vger.kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Gross , Bjorn Andersson , Konrad Dybcio , Jonathan Cameron , Lars-Peter Clausen Subject: Re: [PATCH v1 1/1] iio: adc: qcom-spmi-adc5: Fix the channel name Message-ID: References: <20230117093944.72271-1-andriy.shevchenko@linux.intel.com> <20230117231204.fpvxryjscosg57a6@SoMainline.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230117231204.fpvxryjscosg57a6@SoMainline.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 18, 2023 at 12:12:04AM +0100, Marijn Suijten wrote: > On 2023-01-17 11:39:44, Andy Shevchenko wrote: > > The node name can contain an address part which is not used by > > the driver. Cut it out before assigning the channel name. > > This explanation doesn't cut it. It's not that the driver "doesn't use" Driver doesn't use it still. There is no contradiction, but I agree that below part is good to have in the commit message. > the address part, it is that this string is propagated into the > userspace label, sysfs /filenames/ *and breaking ABI*. So I will add it into v2 in case the fix works (see below). ... > > - const char *name = fwnode_get_name(fwnode), *channel_name; > > + const char *name, *channel_name; > > I don't think this'll compile as name is still a pointer to const data, > while you're assigning (a '\0' char) to it below. Right, it's always hard for me to compile things for ARM on x86 :-) Thanks for catching this up! But does this fix the issue after compilation fix? -- With Best Regards, Andy Shevchenko