Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp270662rwe; Fri, 26 Aug 2022 04:55:04 -0700 (PDT) X-Google-Smtp-Source: AA6agR7Sa5ZvFBhOg+E5E7arC+9nlAEzpyrZnU52wF0Z+GMr+QbY4ntpJKUk0hRnPcxLemqnrO/T X-Received: by 2002:a17:90b:1e0c:b0:1f5:4e52:4866 with SMTP id pg12-20020a17090b1e0c00b001f54e524866mr4101214pjb.230.1661514904332; Fri, 26 Aug 2022 04:55:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661514904; cv=none; d=google.com; s=arc-20160816; b=aN/Isg6FIkDlddg39mq6f9/EG+aattRyVCC3bwRPGdUcSNR0snMV/oLue/goYD4x18 AqRemR/9p6kAoqoRSP4OFngS99wO4YuVUtktG6uWgxf8nobSAdbJwoR+uqL5UbfIvN85 iK3tdtRDVj9UsqxXkLk0dsIxoqSR2tXuT09pBzLiLHvu82faGbex8yP07POxnptMK9zs 7KPfR8TbbjF/Pe03FpXskny82NUhUD9QzLmAyMpSFimLau+WyUvs4vlVjI40fYtolk6d qKdsVHGrPHUCxg9jMVxDWuFLbPA8nC6T8o3eY2G9oX6jOIkT4xfVtkLES9+OU546Ebjw IEvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=P9AsG7gThmUES9KSpQbh1/yQIt+a2Ly6k49idujfHCM=; b=nj3hdpMmAsmXmUr+rUievmcepy2D9rYpRIrhGG+9zChXCkoshaILrJtBrRkxO3KVKa s0fB0sKqtZPiU+WJHc6wrvkg5doBtFxPoKYuuLZORg5zXwZw0sJn33HKd4O3HllHM/RT a962fGnYwCPvb2de5zkDlG6H4aN+LcfVkRV/yEzjhRqHBaJG2y1MlvkzCzFs4gu/0bdl 6rLG1A/++6kB0gP2meSeyuMhOd+c4td47CoiIJ/ccou8su4QD0HiZdvfMtmWe169TWSU kRAA3FbEZZunG1VnbJFv9ny6fHRZogX+pKJqVY3cyhXYA2BuwWbEZbe3Lj/k/GSWxmiL SRnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@axis.com header.s=axis-central1 header.b=Az3mPGng; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=axis.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p1-20020a639501000000b004114723aa79si1700629pgd.819.2022.08.26.04.54.47; Fri, 26 Aug 2022 04:55:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@axis.com header.s=axis-central1 header.b=Az3mPGng; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=axis.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245256AbiHZLiq (ORCPT + 99 others); Fri, 26 Aug 2022 07:38:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229917AbiHZLio (ORCPT ); Fri, 26 Aug 2022 07:38:44 -0400 Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 320A5DB7E2; Fri, 26 Aug 2022 04:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1661513922; x=1693049922; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=P9AsG7gThmUES9KSpQbh1/yQIt+a2Ly6k49idujfHCM=; b=Az3mPGnggbKs/VBeSChAq+3SFUCiIgtREdgp2tQ90hj65Tvi8+P9BLA1 AlPUM44pHRBlXUa+d2UToIGlyi3BOTGQhm8WNj6ATwNd9PtiIF465xzPM XsCN3wOzsbeMQzw/NXCQRoMukNw1cq+4MwdrD/nMZMr/QVSwIwUfr65+T HH9hLJGj0zLgrAkZJFoKhJtljrgPiw3U3M77Ac3V3gRPs13nhZK7YGXLv l96evXNcYOkYSxQHuBeBCj72yNEysvbxE4EvZ4un6XzKrLYBKl0aVwaVq nUyhs4d0iT04lfBYzbjdKIH6QOUFupeKxZkvvXu1IH4roCePzcHujyNrx w==; Date: Fri, 26 Aug 2022 13:38:39 +0200 From: Vincent Whitchurch To: Andy Shevchenko CC: Jonathan Cameron , kernel , Lars-Peter Clausen , Axel Jonsson , linux-iio , Linux Kernel Mailing List Subject: Re: [PATCH 1/2] iio: adc: mcp320x: use device managed functions Message-ID: References: <20220824104002.2749075-1-vincent.whitchurch@axis.com> <20220824104002.2749075-2-vincent.whitchurch@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 25, 2022 at 10:01:58PM +0200, Andy Shevchenko wrote: > On Wed, Aug 24, 2022 at 1:46 PM Vincent Whitchurch > wrote: > > > > Use devm_* functions in probe to remove some code and to make it easier > > to add further calls to the probe function. > > ... > > > + mutex_init(&adc->lock); > > > + return devm_iio_device_register(&spi->dev, indio_dev); > > Do you still need to destroy the mutex? If so, you may not call devm_ > variant of iio_device_register() or you have to wrap mutex_destroy() > accordingly. mutex_destroy() is only used to ensure that mutex debugging catches further use of the mutex. Isn't it rather overkill to add specific cleanup to do only that, especially in this case when it's anyway going to get freed immediately afterwards? The vast majority of IIO drivers don't call mutex_destroy() (256 calls to mutex_init() in HEAD vs 12 to mutex_destroy()).