From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 78C4232470E; Wed, 1 Jul 2026 11:12:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782904334; cv=none; b=QyAMPs86gK3qZYWEjV2oZ05zYs/uUTilMmrCKrrmXq6j6Hdqy7bcKYi76kS6emV+MIkYL8NpbysO4tLM09gHM+bb6GJKZRlmOiCW8HzeM+Wse9X62xzq98A6o1RFuK3IU9tyNtfg8xQtJAvW1F/+6CIWuybtK5mxbLT21TveMKg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782904334; c=relaxed/simple; bh=2tCAa5egD6m2BQ0H4jq7urovVKQ5/sWa/ZCUDCRIOW0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=enremP1CNqhpBBvvNyXt51QmAWfTELwCr3qHN5SmIZZ6KEMAaBADEfiVAhN3K8lQ60DNEOXdYgXDMbnImmH5KCzcKU6bDuoqIAhj5b1/d10usjLdydK3l7cF77F73r6rkCHSdDUVsks0F81egA5QHkHO4o+Kzu+uj4r/ibO9MsQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=CAPeMb1h; arc=none smtp.client-ip=198.175.65.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="CAPeMb1h" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782904333; x=1814440333; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=2tCAa5egD6m2BQ0H4jq7urovVKQ5/sWa/ZCUDCRIOW0=; b=CAPeMb1hitOD2RCj5nPTZAwrE3FKr2GtP1gf6kBSkWfoiRyHFtEx71wK wDSqOrQiM10gz8g8GC847lzxl2Z+Y5aI9U/qdnU/TSiSjb9qoBlxXRpIB zUWyy4K3mBaStuVmgyEI2MiMqCjsJuePDoNami/3H4PTmeh6gQATliR4p 6kI+trSAQ2V6giNSr4IA9n8ae2+UadhPzjeorVB7DMJsvRqsugp4NpcYi ZSc/ZuHzZE+64fP8d2MkNNR7Cw0+Qb3bYqATy3U+8FTQYmT+bCKm2Tjza hsjJkTqRsSIOS4fJGF/kr5VvK1Ht8FHgDEZvWn1KNKdoFVwBG44qdCj8J A==; X-CSE-ConnectionGUID: orOa2vviQCGGfF3BuUxr0Q== X-CSE-MsgGUID: fcLHt2KBRJSuX4+e3zUUzA== X-IronPort-AV: E=McAfee;i="6800,10657,11833"; a="83721272" X-IronPort-AV: E=Sophos;i="6.25,141,1779174000"; d="scan'208";a="83721272" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2026 04:12:12 -0700 X-CSE-ConnectionGUID: HclpZFOuQk+O8i5FfAH5GA== X-CSE-MsgGUID: 2vsG1rcEQuGncX4nmPTU2Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,141,1779174000"; d="scan'208";a="257441229" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO kekkonen.fi.intel.com) ([10.245.244.62]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2026 04:12:08 -0700 Received: from kekkonen.localdomain (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with SMTP id 784DB121796; Wed, 01 Jul 2026 14:12:09 +0300 (EEST) Date: Wed, 1 Jul 2026 14:12:09 +0300 Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo From: Sakari Ailus To: Hans de Goede Cc: Tarang Raval , Kate Hsuan , Mauro Carvalho Chehab , Hans Verkuil , Serin Yeh , Damjan Georgievski , Kieran Bingham , computman , "linux-media@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Daniel Scally , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , "platform-driver-x86@vger.kernel.org" Subject: Re: [PATCH v6 3/4] platform: int3472: discrete: con_id vana for Sony IMX471 as power enable Message-ID: References: <20260629074026.35490-1-hpa@redhat.com> <20260629074026.35490-4-hpa@redhat.com> <49257d09-a2fd-4a9d-9479-4d2b5e0fb8a6@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Hans, On Wed, Jul 01, 2026 at 01:01:58PM +0200, Hans de Goede wrote: > Hi, > > On 1-Jul-26 08:19, Tarang Raval wrote: > > Hi Hans, > > > >> On 30-Jun-26 09:32, Tarang Raval wrote: > >>> Hi Kate, > >>> > >>>> Update the con_id for the Sony IMX471 sensor to "vana" to serve as the > >>>> power enable. Additionally, the HID values SONY471A and TBE20A0, both > >>>> associated with the IMX471 image sensor, have been identified on Lenovo > >>>> laptops. > >>>> > >>>> Signed-off-by: Kate Hsuan > >>> > >>> Thanks, looks good. > >>> > >>> Reviewed-by: Tarang Raval > >> > >> Hmm, the imx471 driver is still pending upstream: > >> > >> https://lore.kernel.org/linux-media/20260629074026.35490-5-hpa@redhat.com/ > >> > >> As part of this series. > >> > >> Please just use the standardized "avdd" in that driver instead > >> of "vana" (which also seems to refer to the analog supply vdd, > >> which is what avdd stands for). > >> > >> Then this whole patch is unnecessary and can be dropped from > >> this series. > > > > The regulator name "vana" comes directly from the Sony IMX471 sensor > > datasheet, which typically refers to the analog supply voltage. Using the > > datasheet name helps keep the driver consistent with the hardware > > documentation and makes it easier to cross-reference. > > > > as per my understanding, the more standardized way is to use the regulator > > name as per the sensor datasheet. Therefore, I respectfully disagree with > > your suggestion. > > As shown by the need for this patch on x86 at least because there > is no devicetree it greatly helps if all Linux sensor drivers use > standardized names for their regulators rather then using the exact name > from the datasheet which often is not very consistent. > > And "avdd" is the name we've standardized on for this, so lets use that: > > hans@shalem:~/projects/linux$ grep -l '"vana"' drivers/media/i2c/*.c | wc -l > 4 > hans@shalem:~/projects/linux$ grep -l '"avdd"' drivers/media/i2c/*.c | wc -l > 36 > > The alternative is needing to add more and more quirks as different > sensors are used, which is not great. I do agree that having a constant name for the regulators would be beneficial for the int3472 driver. Still, if, and presumably, when that sensor gets DT support, the bindings will use the regulator name from the datasheet. Let's just use the datasheet name now and add the few lines needed to the int3472 driver and avoid the churn in the future. There's a limited number of sensor drivers that need this after all. I'd be more concerned of what's going on in tps68470_board_data.c for instance. -- Kind regards, Sakari Ailus