From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 B0B1533F8A2 for ; Wed, 1 Apr 2026 03:20:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775013605; cv=none; b=WDwnTPKAeUstKVw14wFs2JhSkwusdk/gAE5hwB2Pts8XBUr53yfuGT2bKeMHN6KcCPbjfe1Vs3o4d8ex87DqrnbsUTrOyH56DQVQoYmxG2pi7mdktu3ZNWX9pWOtn6GwoItShVoRd5Qlwnh/wUCN3e+kYabiuLfeDMevcSLlSiU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775013605; c=relaxed/simple; bh=HGiDfapAhtuXluq1IFgXS0Dok2/LIuXf/4U3bjhLJbs=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=PQ/houCIsXxxEL+NrZDx2n74wdUJ03x95K5WwmotSFOqBPlgETFJ2iqiwmL3ywNLdyAX05jwX6HjnWk6AIfTCwFWtaPJG1AmwLyBwjOT5EJtpVAWoNMvvNc3igoQyQPZOSM8gW7g491vvfR90b+zKRFuc+fT8FmwkflWDu2vmdc= 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=dcsSRuPv; arc=none smtp.client-ip=209.85.214.175 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="dcsSRuPv" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2b2589c26e3so22517685ad.1 for ; Tue, 31 Mar 2026 20:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775013604; x=1775618404; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:references :in-reply-to:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=17IIdQbaWiCM4KvJxXBpWnaDw4MMr/Naj3oOivwpD20=; b=dcsSRuPvjY65nQyJCb6/BtA7MeVL4c9tdBHmy/gnrAYET+MYPGu3Zyy+9JlZU91lsC TpGmPVDo3aQPPv3oeN63K2wxQTYPg/AywrYtsOMnX4/1uY+XkibOM61ADpkpbk8foyPi 1W+chCDwd+vzoBKKlYncVTAEiGfX8L5iW2Ekf3E63oz9x2VZYXz6NCxU0+gAG1wvmfsS ScWqw8awMefrzCKWF5yZCuxY5oJNYoozQrO6/oc/EINws4Iz8257xTuCYh3YlhykvNHf ZgWYZnOf2HdQ7lxrymsvv3hjujXBfP7/K0ncLTyPPof6RU/Pr967Re8l4x7M/ZVjF3ox LDrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775013604; x=1775618404; h=content-transfer-encoding:mime-version:message-id:references :in-reply-to:user-agent:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=17IIdQbaWiCM4KvJxXBpWnaDw4MMr/Naj3oOivwpD20=; b=OV7STJiOgr+xXtdGmx7KpWI9fLDqapq7iwU5fpe0ibsgyFnPgWix2nRQOkU+/vMjDO 9MCO0Nx6XIDaKJL+sHjojkZrc6qvyAtspMfKqhPC5cdA9UwWA61w8t9ddx70aClu0IsI JdC6xwojTE9gqK7Di/bcDkehiqMj/KsGzmY1b0oYKBjWbtS/+qpOGEjHu3sV+jvDMJzc EIDyipQUE9OD81tbzCzN7ZqaPF32cMlSf8eLDRXGF1X0cBkX4A0OqQnxo1ma0sKffnuV twBqj8rcedSPh56Za5K3MURsq7H1MCeyRN1fF7J7InXDLgrw/twWQ32dy972a6PL6VWV PQeQ== X-Forwarded-Encrypted: i=1; AJvYcCUD4nTI+7xHoBBHSheAk4XLapvVnjwpQwQUt0sZcKmg7vqznNFebUzsVOQxL2alLcAQmscYbdesn9iRWhc=@vger.kernel.org X-Gm-Message-State: AOJu0YzR2Ql5WSHc5IQx6GBG3DS9l00tge/Akps7YX1SYCYpDeyl/Em1 DIOTLu3ToL8enKRlOTE0CbH5vfj+kUMUhojnSflm98mqtUDrln6wSwZc X-Gm-Gg: ATEYQzyppv9DnRP8xGq1fzpfv9UdnMR8cYFI08KX6K1DNIkKzDMZ38xfuBMqBJkbZwi 5i6Y0UE39i0C3HGs4G5csBznSsNWtu08wm2x1akgXmCw8KyiMLY0S+/+PkCOJ6+p0QffNmenVj4 wu8eHS4jkpdXMz2D0J5PUYOU9cBOQysK6LlOuhx/rIp+kFEhplfb70eG3PPb+hprnUv/4RzEsz0 ckOrby9Oj3qkvMbAD/VIxXRiP8ZavacwnFT5gsM8c8WMFy4tQiGQ3bw0aLFd6sYtKlVuD/+Bx9g mlysH/F6ZkEL6QkuQdrqWvpfBFrpEQdAAGymCgJiz3/osoOB98mVFPjNXFa7XCu5mvLm//xQlFn g5PFpj5Z5SsMm/pT2x2cFxhYdNqusVDV/lmSwgtDhhq9L7te93QxKKuuuZ31EiJviwJUyqUgytb uee9KXBMMX/4nvk4mL6BV3e+3C9woZ2hp18x6326kr2IMuIg== X-Received: by 2002:a17:903:1b6d:b0:2b0:bebb:1081 with SMTP id d9443c01a7336-2b269cffdfamr15228455ad.28.1775013603888; Tue, 31 Mar 2026 20:20:03 -0700 (PDT) Received: from ehlo.thunderbird.net ([2401:4900:c01b:b139:b0d:529c:e26d:b48d]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b24ddc0afbsm128280835ad.64.2026.03.31.20.20.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Mar 2026 20:20:03 -0700 (PDT) Date: Wed, 01 Apr 2026 08:49:58 +0530 From: Sanjay Chitroda To: Andy Shevchenko CC: jic23@kernel.org, dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org, kees@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v4_3/4=5D_iio=3A_ssp=5Fsensors=3A_s?= =?US-ASCII?Q?sp=5Fspi=3A_use_guard=28=29_to_release_mutexes?= User-Agent: Thunderbird for Android In-Reply-To: References: <20260326081815.925373-1-sanjayembedded@gmail.com> <20260326081815.925373-4-sanjayembedded@gmail.com> <4017E54C-B25B-41AC-B4E1-F28576C2D64C@gmail.com> Message-ID: <9403348A-7EC9-45E5-B4AF-9ED29CA7B634@gmail.com> 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=utf-8 Content-Transfer-Encoding: quoted-printable On 30 March 2026 9:47:52=E2=80=AFpm IST, Sanjay Chitroda wrote: > > >On 29 March 2026 5:14:38=E2=80=AFpm IST, Andy Shevchenko wrote: >>On Sat, Mar 28, 2026 at 12:24:11PM +0530, Sanjay Chitroda wrote: >>> On 26 March 2026 2:52:06=E2=80=AFpm IST, Andy Shevchenko wrote: >>> >On Thu, Mar 26, 2026 at 01:48:14PM +0530, Sanjay Chitroda wrote: >> >>> >> Replace explicit mutex_lock() and mutex_unlock() with the guard() m= acro >>> >> for cleaner and safer mutex handling=2E >>> > >>> >NAK=2E Please, be very careful when do such changes=2E >> >>=2E=2E=2E >> >>> >> - mutex_unlock(&data->comm_lock); >>> >> - >>> > >>> >Pzzz! See what you are doing here=2E=2E=2E >>>=20 >>> Thank Andy for pointing this out =E2=80=94 you=E2=80=99re right, using= "guard(mutex)" here >>> unintentionally extends the lifetime of "comm_lock" and can hold it ac= ross >>> the completion wait, which is not safe=2E >>>=20 >>> I=E2=80=99ve reworked the change to keep the original locking semantic= s intact: >>>=20 >>> - "comm_lock" is still explicitly unlocked before "wait_for_completion= _timeout()" >>> - No sleeping paths are executed while holding "comm_lock" >>> - Introduced small helpers to simplify the flow: >>> - "ssp_send_and_enqueue()" for SPI write + pending list add >>> - "ssp_dequeue_msg()" for safe removal from the pending list >>>=20 >>> Updated flow looks like this: >> >>If you are going to mix mutex_lock() with guard()(), it's even more NAKi= sh >>solution (id est worse than no change)=2E >> > >Thanks =E2=80=94 agreed on not mixing "mutex_lock()"/"mutex_unlock()" wit= h "guard()"=2E > >This patch is intended as a cleanup to switch to "guard()", not to change= locking semantics=2E > >I=E2=80=99ll rework this so that it=E2=80=99s a consistent conversion: > >- convert it fully to "guard()" without changing the lock scope (e=2Eg=2E= , by restructuring the critical section appropriately or limiting scope wit= h {} )=2E > >Will update the patch accordingly=2E > Following up on my previous reply =E2=80=94 after reconsidering, I=E2=80= =99ll drop the guard-based conversion to keep the locking style consistent = with the existing code=2E Instead, I=E2=80=99ll keep the explicit mutex usage and, if needed, simpli= fy the repeated pending_list handling via small helper functions without ch= anging any locking semantics=2E I=E2=80=99ll send a revised version accordingly=2E > >>> This keeps the synchronization boundary unchanged while reducing dupli= cation >>> around pending list handling=2E I=E2=80=99ve also limited "guard()" us= age to short, >>> local critical sections only=2E >>>=20 >>> Please let me know if you=E2=80=99d prefer keeping the list operations= inline instead >>> of helpers=2E >>