Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1948554rwb; Fri, 11 Nov 2022 02:53:43 -0800 (PST) X-Google-Smtp-Source: AA0mqf4x1jb0+9WLfElZ0nA0MHpkcFb0JX0GzCAiqbrJ1nSrZhuxdl7ceVtIMPBkUtz8rsDAsx7t X-Received: by 2002:a17:903:26d2:b0:186:9ecf:94f3 with SMTP id jg18-20020a17090326d200b001869ecf94f3mr1994032plb.105.1668164023752; Fri, 11 Nov 2022 02:53:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668164023; cv=none; d=google.com; s=arc-20160816; b=mMcsteSqhaH0ImkBCRAp6hvCHqs5HiYgH2fxCUZ3Qe/UaS0n4v/xkicXByf1xt57qJ 8VXLEX/GlUgi0ho3a9O1r3U28cKcHgSfPITIcND98Anpphc9qgyb2DkWQbzNHF0LX1s2 vf1fkqt6VMhzewmYZzslUxnUtZLCbcgVWfgSt2QMglYkHAyoaOn2OKv37CU2DhekMreM Ug2AczvbtIwvCoL0ot1Hl43cXsoA7Lr7OZMRabc3AiS2oTDk6/aaQzGoJ9FbqRRjpUZA +lABvIX5mKuw2ZFpp8Dz21/nLxqeFKE0JOYjzR7ooV1FybBL8lmOFOj3J10GiMwIs5Uo pl5Q== 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=AdGBjGSpfpiCr6uZr/DVn1+Yj7Sypc0ObDDcsbamL2c=; b=SoDlLX0WWlen3rTYBQE7fhycQ7R9blzK5awRVJi3MF0NS2GGu+WcEDrYuIlcR3ZwYa m1pz/3oHn/xAZYy8QFLTo6hjx/KSxMNPPgl5Lg9cHlFc2BE7OMjFozNAMHc1cE6rvjBf lcW+cPzK/0kAhmOYMQGyrGmZOLXW132M/1RWE0qS65tAPrGPxFegdHRA+tdGbS4j5w2p 3dwpnOLibTvG0TmhEyGWOVeu2pmb0odAMkT3r4HuL6Lj3lwAR9mdljda1rDRCl9Kc6YR ZifXHSgocd0wz2cbVhvS/s0oNCezc1tYYilqoKAvXWkSrr9diQciVkuVZH7Vthya43th 0KnA== 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 g1-20020a056a000b8100b0056cf9ed8f10si2280962pfj.329.2022.11.11.02.53.32; Fri, 11 Nov 2022 02:53:43 -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 S232341AbiKKKjq convert rfc822-to-8bit (ORCPT + 93 others); Fri, 11 Nov 2022 05:39:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233868AbiKKKjk (ORCPT ); Fri, 11 Nov 2022 05:39:40 -0500 Received: from smtp.220.in.ua (smtp.220.in.ua [89.184.67.205]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EC521654CC; Fri, 11 Nov 2022 02:39:39 -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 AA8051A25F73; Fri, 11 Nov 2022 12:39:37 +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: Fri, 11 Nov 2022 12:39:22 +0200 Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org, Pavel Machek , "weiyongjun (A)" Content-Transfer-Encoding: 8BIT Message-Id: 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> <6D18A607-EC63-495F-BA2D-78E0DB056D3C@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 Hello Wang, > 11 лист. 2022 р. о 11:21 wangyufen написав(ла): > > > 在 2022/11/9 18:43, Oleh Kravchenko 写道: >> >> >>> 9 лист. 2022 р. о 12:25 wangyufen написав(ла): >>> >>> >>> 在 2022/11/9 17:39, Oleh Kravchenko 写道: >>> >>>>> -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? > > Fix the &priv->lock used after destroy, for details, please see patch #0 > LKML: Wang Yufen: [PATCH 00/13] leds: Fix devm vs. non-devm ordering It doesn’t make any sense for me. You saying that remove() called before devm_* allocation if it true then set_brightness_delayed() will crash the system in anyway. LED device has a parent SPI device; LED device can’t exist without SPI device. So deallocation order should be next: 1. LED device devm_*() 2. SPI device remove()