Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3449478rwb; Tue, 16 Aug 2022 03:19:31 -0700 (PDT) X-Google-Smtp-Source: AA6agR4LwucBHPRYQmUyOzgWh5LsUAjDZdyVNJuSitKCKxHbztlT1NT+9yXkBcCKjwXh+txsesH+ X-Received: by 2002:a05:6a00:1f8b:b0:52d:5b9e:3ecf with SMTP id bg11-20020a056a001f8b00b0052d5b9e3ecfmr20383686pfb.48.1660645171681; Tue, 16 Aug 2022 03:19:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660645171; cv=none; d=google.com; s=arc-20160816; b=srG0L5IvhYGIg4NbtxOH7yfvBpJ45EidBNPEZzOo9kQrhGkZuQbMF1r0cN8nncWO6T laukpFfyAY0TlvC2P745mm86d8XETGlUovUsq57V1EJE+wLAJUpr0fi8zx6OfXNdNeNC afA2RF+YdKXZHBYjq4JXFfm7pwVB5J6ylByqGBtiz4zae7MsvxnYz5MT86nGDP0FeYqp P4iFkLci+9y6L8qszT69X3yaKSVej5yEVSn0Gs8SA6P1a2gNwmRUzckEdsyBRLxZmLNI nvDZf8KkBJq4SyeQRhGz8fmrT6a5wsmGLYRybsy57kUI9rMqABccyaWv6r4YAvp/cYdq Z9jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=M8+zN5n51GohpbStdjKXmJWXHgqhXr7wmE0QoYJl1Tg=; b=qJ2Wdcg2dy+oSzlG/N7P3y5kmabBfy5shlu2n+fAGS0CdZ/ttDZQDeiU3DgZTWVJrN ZOZtYfC/u+HKPumiN6uZXLMr0gvWIDguC5jFungx2ulRmh2PPqqlzqVhvdZ16BHw2Ki8 wezQX28MEzq20PmtBjeIs4eVC8/FjiG5TjzvxM9zW/QUT5wbCa2/YUU9A+X7bcaaPlDH Y1CiJzwUXcbOj0E8CCl/zF0r96D+aJvIld5TqzrutYrJN44iyaWxzjBHp5Ep5tkLNlfG WPnU3Cj/gzDFRA9se1tAWzQZOGKOIbgnlYTHdkKDh1GUwTUG7uTd3MqtO5PNZAwKYsZ+ fFCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=qLuGJVyd; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e17-20020a17090301d100b001712e1efa90si15352686plh.22.2022.08.16.03.19.19; Tue, 16 Aug 2022 03:19:31 -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 header.i=@gmail.com header.s=20210112 header.b=qLuGJVyd; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234252AbiHPKIy (ORCPT + 99 others); Tue, 16 Aug 2022 06:08:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234262AbiHPKID (ORCPT ); Tue, 16 Aug 2022 06:08:03 -0400 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CB1E356F4; Tue, 16 Aug 2022 01:42:58 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id b2so7628325qkh.12; Tue, 16 Aug 2022 01:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=M8+zN5n51GohpbStdjKXmJWXHgqhXr7wmE0QoYJl1Tg=; b=qLuGJVydbZapmuhh/ri/mPvYA5bm4nMtIaG76TKtA3Mvo/gBhkJK17beJcQl4lBkM0 iPBdZSSrCNgcezsRIABTJwp7UtgOhSIzqLsuYw6uKZIdWj2+EzGX4Ynvo2pcygJ3ES0H rNv2bDiwY+8yFgEBX8y3Q+RZ0w+7z61uHWS67T1C+ZdmOf9xIz3+Ss494E0LnAKj62KJ uuV7tjhnSgJ133uq7dK9dc8YkqzpGgSLl11+J0G8NNyLbKRknzb7wyR2X4f7YRD/3396 ChRcoJ8Z8tpfDVeQs7eHQAwLSDOEU4j8m9CRydpoEnGFQI0rjqmOED+9BOVCNq8moS5U UQgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=M8+zN5n51GohpbStdjKXmJWXHgqhXr7wmE0QoYJl1Tg=; b=Nepdhtws48v2xij5S/nWebWOJnxuWP4JOjF/2KqaCvOgfmk3TiLhtYBKBiom95hkNS gjU0XOwr5MW8JOxkNuPDG6BBnecPqoc09gvIePtGlb7iPAGaRs4Qo+5b28OYCPcgC+43 6Pty5tXDIzbhTHaXVTpEIitd1Qn2ZlJScZDw8ffK/aZUzgt22Xf+Z/o51x/oYWOVoAqF gndFTmrZnjwe7UmD2gFmx9lPVUwkOnsUldY6hrO2HaZOHoRcb5eVIxDxyuyTBIZ/xz/M uiDUCOmdl7judNDA1Pv8TNapNmlFTMwTYeev0jkQKrr4gRq7KWUX8Nhr7Hr/7OT2JfAW Pinw== X-Gm-Message-State: ACgBeo0uJw2fp/LLnGgtYGDsjU4qdXa/Lai1LTrrKIn0na9QclHQfC75 hAcLSuZIYCKtjqJHK9m8xBDMqPvqpvdgcDp7bds= X-Received: by 2002:ae9:e311:0:b0:6ba:e711:fb27 with SMTP id v17-20020ae9e311000000b006bae711fb27mr11131735qkf.320.1660639377250; Tue, 16 Aug 2022 01:42:57 -0700 (PDT) MIME-Version: 1.0 References: <166057828406.697572.228317501909350108.b4-ty@kernel.org> <20220815205857.308B1C433D6@smtp.kernel.org> In-Reply-To: From: Andy Shevchenko Date: Tue, 16 Aug 2022 11:42:20 +0300 Message-ID: Subject: Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable To: Laurent Pinchart Cc: Stephen Boyd , Mark Brown , Matti Vaittinen , Matti Vaittinen , dri-devel , Johan Hovold , Neil Armstrong , Lars-Peter Clausen , Kevin Hilman , Linux Kernel Mailing List , Daniel Vetter , linux-amlogic , Greg Kroah-Hartman , Linux Documentation List , Jonathan Cameron , Andy Shevchenko , Liam Girdwood , Michael Hennerich , Miaoqian Lin , linux-arm Mailing List , Alexandru Tachici , Jerome Brunet , Andrzej Hajda , Jonathan Corbet , Guenter Roeck , Jonas Karlman , Lorenzo Bianconi , Michael Turq uette , Jernej Skrabec , Martin Blumenstingl , Jean Delvare , Alexandru Ardelean , linux-hwmon@vger.kernel.org, linux-clk , =?UTF-8?B?TnVubyBTw6E=?= , Robert Foss , Aswath Govindraju , David Airlie , linux-iio Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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 Tue, Aug 16, 2022 at 8:37 AM Laurent Pinchart wrote: > On Mon, Aug 15, 2022 at 01:58:55PM -0700, Stephen Boyd wrote: > > Quoting Laurent Pinchart (2022-08-15 11:52:36) > > > On Mon, Aug 15, 2022 at 05:33:06PM +0100, Mark Brown wrote: ... > > > we'll run into trouble. Supplying active high input signals > > > to a device that is not powered can lead to latch-up, which tends to > > > only manifest after a statistically significant number of occurrences of > > > the condition, and can slowly damage the hardware over time. This is a > > > real concern as it will typically not be caught during early > > > development. I think we would still be better off with requiring drivers > > > to manually handle powering off the device until we provide a mechanism > > > that can do so safely in an automated way. > > > > Can you describe the error scenario further? I think it's driver author > > error that would lead to getting and enabling the regulator after > > getting and enabling a clk that drives out a clock signal on some pins > > that aren't powered yet. I'm not sure that's all that much easier to do > > with these sorts of devm APIs, but if it is then I'm concerned. > > You will very quickly see drivers doing this (either directly or > indirectly): > > probe() > { > devm_clk_get_enabled(); > devm_regulator_get_enable(); > } And how is it devm specific? If the author puts the same without devm the ordering would be wrong, correct? devm allows us to focus on ordering in a *single* place, which is a win. You seem to be proposing to make a high burden on a driver's author to focus on ordering in the *three* places. I disagree with that. Yet the driver author has to understand many issues with any tool they use. So the root cause of your whining is rather on the edge of documentation and education. (Yes, I have heard about issues with object lifetime in v4l2 subdevices regarding to devm, but it seems irrelevant to devm mechanism itself.) > Without a devres-based get+enable API drivers can get the resources they > need in any order, possibly moving some of those resource acquisition > operations to different functions, and then have a clear block of code > that enables the resources in the right order. These devres helpers give > a false sense of security to driver authors and they will end up > introducing problems, the same way that devm_kzalloc() makes it > outrageously easy to crash the kernel by disconnecting a device that is > in use. -- With Best Regards, Andy Shevchenko