Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp328603rwb; Wed, 9 Nov 2022 03:07:53 -0800 (PST) X-Google-Smtp-Source: AMsMyM4WeF/YTSKpVf0+vFbDAm75euuBABPl3ZaQjkPBRpr3mWjCfqegvRJ/3P7MQOQvjH0DdSGC X-Received: by 2002:a17:90a:e20d:b0:212:ec76:6fc6 with SMTP id a13-20020a17090ae20d00b00212ec766fc6mr62723875pjz.0.1667992073562; Wed, 09 Nov 2022 03:07:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667992073; cv=none; d=google.com; s=arc-20160816; b=tBsACWDsWkhsacLLLeY7Q44NbGVYVurtArwUSsBBnWU15YAOP3VWXbeNRmxw+v6LYm 2N5gkNhybBM1jP6V8mhr1HDLV+HgXFZ+sgbS7igDzz89++Q3J2503tM+LpqlJNQV0IQ7 L9NEaT73vZTKMZ/kmmEgX/1ajmpNxyrVFUl2gKUfl1Me9Z2Dsr9+jYJTfF4nJHFdj/HS en48Z6zAIjR4nDcjFiu+ofy2WQElcdwRT5+/PnE3ouPWIjb4NHJLN/hFMgQsjb3QUQpr riCNJwuXqO8B/UK/8QrRnplgJXv+g+M5778EE+Gn3iyBLcILFTHMnZAuDUKEFojz6Hmy 8dPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=F8B3a/elXI0w+Ba1/Q+kYiCim61DbT+cS53M+JisgzM=; b=ntegHerWV0NOAOV8K+0846HGoTZkxb6XRsiQQJsj5S+FmprUKiT54byN3lzz+LiGEh mRq/zhETIsldZ1LFLd3AltY9cVBnOUzES2G/PePv6ai2qJF3jcaUgoTlWx/BPLEDvC2d NCt51hRoxQYhQvZN24CrwvwOoQLQDnUYtme64h4qmjabmzIrDWC1LcoPEMaJltmSu7ZA RuUF5pEYsZQEdOsRXbk+czeWK9NToXwPpdqbjHyfr8xQ84PdSOQSit86frhDG3SextxS kwD7DVMBnTp6cWCYjmMxa4tUcAokpxgHDMmd6Ur8DdyeMsoNMFaQgNl/gWdLhNyLxe3R QJ5w== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pg18-20020a17090b1e1200b00213e74d1e78si1313138pjb.78.2022.11.09.03.07.41; Wed, 09 Nov 2022 03:07:53 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231157AbiKIKoG convert rfc822-to-8bit (ORCPT + 93 others); Wed, 9 Nov 2022 05:44:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231272AbiKIKns (ORCPT ); Wed, 9 Nov 2022 05:43:48 -0500 Received: from smtp.220.in.ua (smtp.220.in.ua [89.184.67.205]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EB7AF2BF1; Wed, 9 Nov 2022 02:43:30 -0800 (PST) Received: from smtpclient.apple (unknown [95.67.115.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.220.in.ua (Postfix) with ESMTPSA id 2DC4B1A21FD2; Wed, 9 Nov 2022 12:43:29 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: [PATCH 02/13] leds: el15203000: Fix devm vs. non-devm ordering From: Oleh Kravchenko In-Reply-To: Date: Wed, 9 Nov 2022 12:43:13 +0200 Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org, Pavel Machek Content-Transfer-Encoding: 8BIT Message-Id: <6D18A607-EC63-495F-BA2D-78E0DB056D3C@kaa.org.ua> References: <1667983694-15040-1-git-send-email-wangyufen@huawei.com> <1667983694-15040-3-git-send-email-wangyufen@huawei.com> <5D15416B-1866-4031-9958-7CD763C0BD6E@kaa.org.ua> To: wangyufen X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS 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 > 9 лист. 2022 р. о 12:25 wangyufen написав(ла): > > > 在 2022/11/9 17:39, Oleh Kravchenko 写道: >> Hello all! >> >>> 9 лист. 2022 р. о 10:48 Wang Yufen написав(ла): >>> >>> return el15203000_probe_dt(priv); >>> } >>> >>> -static void el15203000_remove(struct spi_device *spi) >> Is remove() callback from struct spi_driver deprecated? > > It is not that remove() callback is deprecated, > it's that after wrapping mutex_destroy() call with devm_add_action_or_reset(), > remove() callback is unnecessary here. When remove() is called, the memory allocated by devm_*() is valid. So what you try to fix here? > >> >>> -{ >>> - struct el15203000 *priv = spi_get_drvdata(spi); >>> - >>> - mutex_destroy(&priv->lock); >>> -} >>> >>> static const struct of_device_id el15203000_dt_ids[] = { >>> { .compatible = "crane,el15203000", }, >>> @@ -331,7 +336,6 @@ static void el15203000_remove(struct spi_device *spi) >>> >>> static struct spi_driver el15203000_driver = { >>> .probe = el15203000_probe, >>> - .remove = el15203000_remove, >>> .driver = { >>> .name = KBUILD_MODNAME, >>> .of_match_table = el15203000_dt_ids, >>> -- >>> 1.8.3.1 >>> >>