From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (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 46C8F32E72F for ; Sat, 11 Apr 2026 11:41:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775907695; cv=none; b=jXk/Fi+qnoeM3Ojc5EwtQlVLXGv7gADfRlqL+qV94TIscM9JkU+3y0vqhS4o14ljo0nrlb25wZ8JNQZ3XFBDEhRlPWOqVbJrbc48lr/AWYzcE3a7+3lzYCSqRgsAa1dtoHPbKU4lNFj9hSkZsQoh4KvqxZNoBhMgN7kaSHJWlEM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775907695; c=relaxed/simple; bh=W1nOInobauqhWR55LUyEwXQV2pJv56J3u5fSBwMoa7E=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=LOAJtPTneUuIrNkejiUM6d4O08uiY0SMrcOcfQP6024IB30N6tjQvhGeJQMnnG+VI2Cwsj3QCB4aE2Lsk1hjqvVIsafITJULvCRN2/F84MZWgxfhH323IyrrSig1VUq8nzdYRzRvGxhkTcYuoDy+BYruPfT2DMgT7Y3B4EQ+1pE= 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=dnBTamRl; arc=none smtp.client-ip=209.85.216.43 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="dnBTamRl" Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-35da1af3e10so2979201a91.3 for ; Sat, 11 Apr 2026 04:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775907693; x=1776512493; 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=Qj/YA69tK8OayNqIO/aiIJnQgpjfgWaqvEfEq2cuNao=; b=dnBTamRl3xyaFkizCovn/JUcFxB6QIu5y11vc2NR+9sa4GAYzQMqAFROSDyiyi7Kke x5yIDmSQc5CK2ptbKJS9bUpHadtdxaqv/FacJoUMgRHwI/32JKIRiQYA2E6CAmerLFIt hbciccw+d1rgvdW+udCvPuZFqjAn1pr8X3nga5opHLadcfupO1OT9IIHcmTUUXPT9nmc w7NLVA5uTtLKR0+MRihTF3f/LOvQdKkjhP7Kyeda+AQaWPhkWC8BQOaY8pLXiVHyXuXS t0mMrJVxNSJl5wXMXb4R8YVEk/sGMIM8s9fnD8G7jVabjC0r792y27GfSd0PDCC6PrT8 KQSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775907693; x=1776512493; 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=Qj/YA69tK8OayNqIO/aiIJnQgpjfgWaqvEfEq2cuNao=; b=j6VIwzVFCz811d02MeyfqrtRstwV5Fh1t35xb4+Z9gyYAlZVJRfGbGG192fv3l8itx T1RQBogMKGOMneeuGcY335nt4dCNcBTZpsnt3jBZLFQS2m39jsOfWY2jZjaXnXxlAwPL s0sQaRyVzCFQv12xorJnyP8L/Wb4q7/pbfRT9s6U8g8hS9nEY1FZOkN9YoW3DVij39bH jrfz16qIlx67E64pl7p9bdNm1LF2PTkiLGoJEGFjj8UoLNmo2W2STqNDljFboaxrSb1M Oqhm709dEVqQQ6rp0V2ndlDFK4TWDq6QQqv5qytNyXZe0EAvMtBFn3ZdiYxGXqxsTf4o e0qw== X-Forwarded-Encrypted: i=1; AJvYcCW7uM8lk2N5ZwN5nPbYp+RVCek0byJ9ituhpOCgjvqqksWd+s0tQYOsJ9/BVwDZtNx/7a02pTWsNYl9OsM=@vger.kernel.org X-Gm-Message-State: AOJu0YxqJDvGf9FxU1kFUJuswoP2wxbHevS4kPLBPxm8wbTvad8y2GK0 EQl/dnIPgNGUvSNShLMAzsfUewslugmEEM++lEMk8hPdSt3dXrIOz+eS X-Gm-Gg: AeBDieufJ9cdBPLPnCCkRZwuvlJtoEYcu2hRIeHbRFCZDenvz/WLyfklbyDHJwdrHKp mP9yYaVAVDOnkCE64br7Lz7ItvrN7ziod7lxnw/IYnN0UqrDLnhU338epsmt7f97ID87LoxXzbS f1+VSCWBdQfL/mbEUbr2cMZrmuQUwpkN5O1/N9CY3ktperfsQFaDN2JHruYGqiBCDwx82yJrx2L T6icnLgs9L4vP9nqh3BVQts9DBc9KSZDPuvIJIT2NB7papOg96sv4iyl/R6SWDfXcMWkgHH1NmS TgpYv/Cd7QlYG3JBWYhSRIOl0gK+YlJTJ6GiQ5CoytRJuY94tvKyaamMovX7ySDPBLlaO79ahcA foLLaY3iOaemfga+mJll1wZ+r1A4+iyVsGqbGT8nC4H1DAkl/kcWywLO4pmu9HsRJ2/WzsXGDmk l4nJ6yiEcEWaqz/ze+fJY8d23j9/QH6UKhLpgF3Ug= X-Received: by 2002:a17:90b:5285:b0:35d:95eb:879a with SMTP id 98e67ed59e1d1-35e4282be05mr7062476a91.13.1775907693519; Sat, 11 Apr 2026 04:41:33 -0700 (PDT) Received: from ehlo.thunderbird.net ([2401:4900:1955:aff9:1:0:8c78:2328]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-35e4133743bsm6347786a91.15.2026.04.11.04.41.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2026 04:41:33 -0700 (PDT) Date: Sat, 11 Apr 2026 17:05:47 +0530 From: Sanjay Chitroda To: David Lechner , jic23@kernel.org, nuno.sa@analog.com, andy@kernel.org CC: kees@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v5_4/5=5D_iio=3A_ssp=5Fsensors=3A_us?= =?US-ASCII?Q?e_devm_APIs_for_mutex_and_IRQ_resources?= User-Agent: Thunderbird for Android In-Reply-To: References: <20260406080852.2727453-1-sanjayembedded@gmail.com> <20260406080852.2727453-5-sanjayembedded@gmail.com> Message-ID: <438F2B61-7F4D-4488-82D0-E1EE23FBF766@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 6 April 2026 9:44:33=E2=80=AFpm IST, David Lechner wrote: >On 4/6/26 3:08 AM, Sanjay Chitroda wrote: >> From: Sanjay Chitroda >>=20 >> Convert mutex initialization and IRQ registration to use devm-managed >> helpers, tying their lifetime to the device=2E >>=20 >> This removes the need for explicit cleanup in the error and remove >> paths, as the resources are automatically released on probe failure >> or device unbind=2E >>=20 >> Signed-off-by: Sanjay Chitroda >> --- >> drivers/iio/common/ssp_sensors/ssp_dev=2Ec | 36 +++++++++++-----------= -- >> 1 file changed, 17 insertions(+), 19 deletions(-) >>=20 >> diff --git a/drivers/iio/common/ssp_sensors/ssp_dev=2Ec b/drivers/iio/c= ommon/ssp_sensors/ssp_dev=2Ec >> index da09c9f3ceb6=2E=2Ef4fc869fc770 100644 >> --- a/drivers/iio/common/ssp_sensors/ssp_dev=2Ec >> +++ b/drivers/iio/common/ssp_sensors/ssp_dev=2Ec >> @@ -510,7 +510,11 @@ static int ssp_probe(struct spi_device *spi) >> data->spi =3D spi; >> spi_set_drvdata(spi, data); >> =20 >> - mutex_init(&data->comm_lock); >> + ret =3D devm_mutex_init(&spi->dev, &data->comm_lock); >> + if (ret < 0) { >> + dev_err(&spi->dev, "Failed to init comm_lock mutex\n"); >> + goto err_setup_spi; >> + } >> =20 >> for (i =3D 0; i < SSP_SENSOR_MAX; ++i) { >> data->delay_buf[i] =3D SSP_DEFAULT_POLLING_DELAY; >> @@ -523,7 +527,11 @@ static int ssp_probe(struct spi_device *spi) >> =20 >> data->time_syncing =3D true; >> =20 >> - mutex_init(&data->pending_lock); >> + ret =3D devm_mutex_init(&spi->dev, &data->pending_lock); >> + if (ret < 0) { >> + dev_err(&spi->dev, "Failed to init pending_lock mutex\n"); >> + goto err_setup_spi; >> + } >> INIT_LIST_HEAD(&data->pending_list); >> =20 >> atomic_set(&data->enable_refcount, 0); >> @@ -533,13 +541,13 @@ static int ssp_probe(struct spi_device *spi) >> =20 >> timer_setup(&data->wdt_timer, ssp_wdt_timer_func, 0); >> =20 >> - ret =3D request_threaded_irq(data->spi->irq, NULL, >> - ssp_irq_thread_fn, >> - IRQF_TRIGGER_FALLING | IRQF_ONESHOT, >> - "SSP_Int", data); >> + ret =3D devm_request_threaded_irq(&spi->dev, data->spi->irq, NULL, >> + ssp_irq_thread_fn, >> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT, >> + "SSP_Int", data); >> if (ret < 0) { >> dev_err(&spi->dev, "Irq request fail\n"); >> - goto err_setup_irq; >> + goto err_setup_spi; >> } >> =20 >> /* Let's start with enabled one so irq balance could be ok */ >> @@ -553,21 +561,16 @@ static int ssp_probe(struct spi_device *spi) >> ret =3D ssp_initialize_mcu(data); >> if (ret < 0) { >> dev_err(&spi->dev, "Initialize_mcu failed\n"); >> - goto err_read_reg; >> + goto err_setup_spi; >> } >> } else { >> dev_err(&spi->dev, "Firmware version not supported\n"); >> ret =3D -EPERM; >> - goto err_read_reg; >> + goto err_setup_spi; >> } >> =20 >> return 0; >> =20 >> -err_read_reg: >> - free_irq(data->spi->irq, data); >> -err_setup_irq: >> - mutex_destroy(&data->pending_lock); >> - mutex_destroy(&data->comm_lock); >> err_setup_spi: >> mfd_remove_devices(&spi->dev); >> =20 >> @@ -589,14 +592,9 @@ static void ssp_remove(struct spi_device *spi) >> =20 >> ssp_clean_pending_list(data); >> =20 >> - free_irq(data->spi->irq, data); > >Do we need to replace this with an irq_disable() so make sure >no more timers/work is scheduled after we delete them below? > >If it is safe the way it is, add an explanation to the commit >message=2E > >Alternative would be to use devm_add_action_or_reset() to >handle all of the other cleanup functions in the correct order >still and get rid of the remove function entirely=2E Hi David, Thank you for the input and feedback=2E Understood, will check and accordingly plan to update commit message or ha= ve devm_add_action_or_reset()=2E In my opinion usage of devm API to drop remove() would be better one=2E > >> - >> timer_delete_sync(&data->wdt_timer); >> cancel_work_sync(&data->work_wdt); >> =20 >> - mutex_destroy(&data->comm_lock); >> - mutex_destroy(&data->pending_lock); >> - >> mfd_remove_devices(&spi->dev); >> } >> =20 Also, I observed that in remove() path, there is duplicate of following wi= th ssp_disable_wdt_timer(): static void ssp_remove(struct spi_device *spi) { =2E=2E=2E ssp_disable_wdt_timer(data); =2E=2E=2E=2E timer_delete_sync(&data->wdt_timer); cancel_work_sync(&data->work_wdt); =2E=2E=2E } static void ssp_disable_wdt_timer(data)(struct spi_device *spi) { timer_delete_sync(&data->wdt_timer); cancel_work_sync(&data->work_wdt); } At first glance looks redundant, do we require both ? >