From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78B733ED5C5 for ; Fri, 14 Aug 2026 08:58:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786697898; cv=none; b=QwrzUyzrm9KlvpbkhFr4/eUq7GnyM2l9swYxpzHDCxqkyzSe8bSiYivMz5PV6gSN7dZic0yaWCDF/JJ7BkLI77t7Ynd28nIGp9GiGPokjDQexQw8rYsSwgUwHuebPOT2rI0jB1Px1gCjrOUQLd/NsceA7J8/a71rSwDj+hHZzno= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786697898; c=relaxed/simple; bh=+xAo7DKr8KYN09cQolTEwlHpwoWQgrI8LMbIPJfHU88=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=Sx/Cgrdls6lc1JkNGFkBuea/WvHP5fnVyzJxxiAR59T3VMqxiHnPBoF3d7G5mLxN4OV2OWe5xKbN6r7TdsW0oTq0dGyUy5GltKwu8k89t7l6HMKEXnXn8HTmjevgPlEjU4lwl4f3NeURxTUuGijZDQXjytXckNrPAmeeKxAZISc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QFSAJGzF; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QFSAJGzF" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4954dff6536so6460945e9.0 for ; Fri, 14 Aug 2026 01:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786697895; x=1787302695; darn=vger.kernel.org; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=P1U17HFehyxVTvnmYZONr+ZpAC1JSagDXgrDixqbumk=; b=QFSAJGzFEic43BCmL8jAUD1QhXdRyn/Yk9e53a+QAe0kpIeMaGWlPTW6JLBhhh1lM0 n0K5+Js/M6rb5erHreu58bD1mYhHAHKthiLEzKJYRuKppKLbBSco9lVZSPbZgTZcLuHg goAMfpB2+Y3hMlILA0KaXBhFymCoNj0gug/zgrYSJimAkJJfKwCamrpflTNHyswjiv9+ JkBbOidxK0YG632BaCkoG29x2qklW3aMCZqzwZeLExKpSyIoDHfUmFD4PNpr9jqdxayY lDBXFXSLBqKoPg+YKtEb+5yrreTIFK8510OujuohFjkj4LdWmiXpXhd3M/Uac2OarO3P izww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786697895; x=1787302695; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=P1U17HFehyxVTvnmYZONr+ZpAC1JSagDXgrDixqbumk=; b=MyTiKr3tUwgfV0G3fe/qPLlT4Yu7qvpxcX4TS9f5cP6PrYFG6MBfKL65Y4M+ocfOYX GNVQAqXeEBiwZbJBGdiyQe3LVwgQoIqU0vU5dHV3rPkZW5uuSoy7QNR7mukDltk91JD5 mE0edvGcCCo9FM/1V0rSYbSsI+cUZjwrCnZYQQJOycHbkEqb+N8UeY59zr+6Z64QxE/K ATrsJ1HSKgYIN2D0ivPQlpTGGJ+IUn9pjYL4g3+ARxajVLiSGywPNnJXwzpZInlVDo2w LCHmBg/1UwSneJgGRrs3FL873CWlaju0xB2CoYES79k3yGQdRpmE8ErBdmVFGKULDV+x gYTQ== X-Forwarded-Encrypted: i=1; AHgh+RqQTEMfYkViDsHACRoGEdjQ000vqdrnRpXNT2LW0ablzt4b+INx0BFq4uJWAOtTqK7EBIrZB7k4Nt8L5EQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yy6AinTbfy6WeF11Ip1NR6lAcTnfuj+A5+86UPHMPevtNj8IQt/ 8Rcg935HNzF1EKz5yHGpuUjjNrICSJlgN9t+k5JmTiNQOTvgEGO+WWjF X-Gm-Gg: AR+sD10IuuM4dqO0PrPrY8v4/MonAvHkibDATn49F8BH9cv3mVTlZ2gsSCbEhOfTP8C N0GTiGBsBjnC6pxfwKSEPFItS3N20cbXweo8mxrflq5bHO/Wdi43peKh1uIzvh3ZbjQvU1Enk/v cYZiwqhPy8CXTebdRIcDoR61sogHzMSraWgRFpLtqWiJXii3l+YAQYPNsK7oJst/kkiYZ4Xndh8 J+kGN/fZlEa81SzHYOiI2FI4Q0Y5Yoa8VZwtTVblHc67ycqcdNWP5NjH9eshZP1yfO+aYSkh0yo c2xgIsZpCAhmQqalOL7KZA1N41HZTn0TrRk6rMtVjmqmeiPikOrG066A9dLhG0ZKo67YmGwba1w StJs4uc7ND6uEWjW4//HYhzuU6joKmioL9eGv//u/rS4128wRQU6DHXzNl/UFjTHbx2DVGPtebr g5DoY40V4ym2VGShndqrocQcuhkXSC7dMw1t/rYWOtGXtktWpJYyBa3QOf1txx5O72BOaCH9VSh Hi3O37z6i0QOA== X-Received: by 2002:a05:600c:8714:b0:499:8704:242c with SMTP id 5b1f17b1804b1-499878ca13bmr68452965e9.0.1786697894555; Fri, 14 Aug 2026 01:58:14 -0700 (PDT) Received: from localhost ([2001:4bb8:16f:15e0:6cd4:2382:91e2:c6e4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49987b438cesm37139145e9.3.2026.08.14.01.58.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Aug 2026 01:58:13 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 14 Aug 2026 10:58:10 +0200 Message-Id: Subject: Re: [PATCH v6 2/4] iio: light: add support for veml6031x00 ALS series Cc: "Jonathan Cameron" , "Lars-Peter Clausen" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "David Lechner" , =?utf-8?q?Nuno_S=C3=A1?= , "Andy Shevchenko" , , , To: "Andy Shevchenko" , "Javier Carrasco" From: "Javier Carrasco" X-Mailer: aerc 0.21.0-143-g2f3a2e260c09 References: <20260812-veml6031x00-v6-0-7eef6e4ce290@gmail.com> <20260812-veml6031x00-v6-2-7eef6e4ce290@gmail.com> In-Reply-To: On Fri Aug 14, 2026 at 9:49 AM CEST, Andy Shevchenko wrote: > On Thu, Aug 13, 2026 at 11:46:32AM +0200, Javier Carrasco wrote: >> Hello Andy, thank you again for your thorough review. >> On Thu Aug 13, 2026 at 8:59 AM CEST, Andy Shevchenko wrote: >> > On Wed, Aug 12, 2026 at 10:27:41PM +0200, Javier Carrasco wrote: > > ... > >> >> + data->regmap =3D devm_regmap_init_i2c(i2c, &veml6031x00_regmap_conf= ig); >> >> + if (IS_ERR(data->regmap)) >> >> + return dev_err_probe(dev, PTR_ERR(data->regmap), >> >> + "Failed to set regmap\n"); >> > >> > Is debugfs access already enabled for regmap after this call? Perhaps = you want >> > mutex to be initialised before that? >> >> Could you please explain what you are trying to avoid? Even if the >> debugfs is already enabled for regmap at this point, what is the >> possible race condition? > > That's my question to you. If you think there is none, then we are all go= od. > Basically the Q is if that mutex (that is initialised later in the probe)= is > required for the device IO which might be possible immediately when regma= p > is registered. > >> The IIO device is still not registered at this >> point, and the registers are set to their right values in _hw_init() >> after the mutexes were initialized. Moving the mutex initialization a >> couple of lines towards the top is not an issue, but I would like to >> understand the reasoning behind. > > User may read (and depending on the driver case writing) the register map= . > Would it be a problem? > That is not a problem, as no assumptions about the original values are made. >> >> + ret =3D devm_mutex_init(dev, &data->scale_lock); >> >> + if (ret) >> >> + return ret; > > ... > >> >> +err_pm_put: >> >> + pm_runtime_put_noidle(dev); >> > >> > Hmm... This is usually a red flag to see a goto after devm_*() calls. >> >> Could you please elaborate on this? I am aware of the dangers of a goto >> after the cleanup attribute, but devm_*() calls work on a different >> scope, not local to the function. What could go wrong? This goto is just >> a way not to repeat pm_runtime_put_noidle(); return ret; and I am not >> strongly against repeating these two lines wherever there is a goto, but >> I am not sure what we are avoiding in this case. > > No, the goto here may (or may not) lead to the wrong ordering on the clea= nup > and/or error paths. It's usually recommended to avoid such a style even i= f > it works without races in that case. That's why when switching to managed > resources it's highly recommended to wrap everything to be managed (in ca= se > there is no native APIs available) and avoid any flow disruption (goto:s)= . In this case I can't see any issue with the goto. It only leads to a call to pm_runtime_put_noidle(), and after returning 'ret', the device-managed resources are released. If the goto is removed and a call to pm_runtime_put_noidle() is carried out in every error path, the result is exactly the same as there are no operations within the probe execution path that affect their behavior. I can imagine that it might be problematic in some special cases, but the use of devm_*() and goto jumps within a function is allowed and used in the official documentation [1], and in several upstream drivers in IIO [2][3] and other subsystems [4]. Of course, all those examples might be bad examples, but I could not find any reference discouraging the use of goto with devm_*(). [1] https://docs.kernel.org/driver-api/usb/writing_musb_glue_layer.html [2] drivers/iio/accel/kxcjk-1013.c [3] drivers/iio/pressure/hid-sensor-press.c [4] drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c Best regards, Javier