Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp867052imj; Fri, 15 Feb 2019 08:06:28 -0800 (PST) X-Google-Smtp-Source: AHgI3IZX8i2lxSRovLe9EZMsGRlW8T/vulvTak5TE6ZeejZTRrYKxS0tRyQbUBs3lLsLQ13er+JM X-Received: by 2002:a63:1ce:: with SMTP id 197mr6022459pgb.47.1550246788082; Fri, 15 Feb 2019 08:06:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550246788; cv=none; d=google.com; s=arc-20160816; b=lT6f24zgrPXOPJZ8VJ9nD48db23e48MokP5IaeUIYXDvkKxHIxid5DVzWqGppCeCYP Ay1VdbcglgdewTIka/y9aXKvxAss0/LehgFfLfwo5pHqOLYBSw5Ycc14ut69docA2aou WozfPWYpnz9/lOGjldlRkVY5ob4gp3X5ovtRxIop8Y+B2qfwzSpWe51w/ZthJIn2lKZu 0Qll/fir6Ybh742O05anLqt8J+Xl2/XKQWEsBF1T/ujk7fFJ25atljTlVbdpBvcXRkdB vnoKwSxSUwUC3RKvJN0m/5bw8dNWFjk9UkkaQctPAuQJ8D39ID+sYGn8fJeogH3yt6I8 3vrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=TJlEKjBn308zEaJtyLaAfGAb4zqaSPbAsNxstsAHUPo=; b=AI4uqWkyrTSXC1TCDe2OSezilTuTC7aukBdLEYxE2Ne/tHIvHiphrfAcIZ1Yl1xvsz zI1vvqdYapTcYqlLVyP2R46BaI/pwgEckpCGaqWPamx4StoZ5avkoNKeka9qSVdJIWSg dfb/ZEQIMmPj1Fj7t3sLnVOV4xerjOlL7KAGSSV+yEJGIqg51+9vjq5905eJy7hGjj/R d93tUHMdNBACZpN4hy8zX9bsfNXHs5p8S41AFtCgugqa8M+kRkYkeCLi+4sMOMOprsHb gKWHSCbJBF5eLun9b81E1dNrQRW8luW0zgsJnca1IeoG9H2hDdak+WNqPij6FbT4ENKX hYFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e3si5761047pfe.203.2019.02.15.08.06.10; Fri, 15 Feb 2019 08:06:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388366AbfBOKXC (ORCPT + 99 others); Fri, 15 Feb 2019 05:23:02 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:44483 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388071AbfBOKXB (ORCPT ); Fri, 15 Feb 2019 05:23:01 -0500 Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1guadu-0006rX-9h; Fri, 15 Feb 2019 11:22:50 +0100 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1guads-0006Oy-2E; Fri, 15 Feb 2019 11:22:48 +0100 Date: Fri, 15 Feb 2019 11:22:48 +0100 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Claudiu.Beznea@microchip.com Cc: fabrice.gasnier@st.com, thierry.reding@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, alexandre.torgue@st.com, tduszyns@gmail.com, linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org, mcoquelin.stm32@gmail.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 3/3] pwm: core: add consumer device link Message-ID: <20190215102248.i2mggrw74lgs2owq@pengutronix.de> References: <1550055012-23348-1-git-send-email-fabrice.gasnier@st.com> <1550055012-23348-4-git-send-email-fabrice.gasnier@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 15, 2019 at 09:23:48AM +0000, Claudiu.Beznea@microchip.com wrote: > > > On 13.02.2019 12:50, Fabrice Gasnier wrote: > > Add a device link between the PWM consumer and the PWM provider. This > > enforces the PWM user to get suspended before the PWM provider. It > > allows proper synchronization of suspend/resume sequences: the PWM user > > is responsible for properly stopping PWM, before the provider gets > > suspended: see [1]. Add the device link in: > > - of_pwm_get() > > - pwm_get() > > - devm_ variants > > as it requires a reference to the device for the PWM consumer. > > > > [1] https://lkml.org/lkml/2019/2/5/770 > > > > Suggested-by: Thierry Reding > > Signed-off-by: Fabrice Gasnier > > --- > > Changes in v3: > > - add struct device to of_get_pwm() arguments to handle device link from > > there. > > --- > > drivers/pwm/core.c | 14 +++++++++++--- > > include/linux/pwm.h | 6 ++++-- > > 2 files changed, 15 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c > > index 1581f6a..8cb5d4bc 100644 > > --- a/drivers/pwm/core.c > > +++ b/drivers/pwm/core.c > > @@ -638,6 +638,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct device_node *np) > > > > /** > > * of_pwm_get() - request a PWM via the PWM framework > > + * @dev: device for PWM consumer > > * @np: device node to get the PWM from > > * @con_id: consumer name > > * > > @@ -655,7 +656,8 @@ static struct pwm_chip *of_node_to_pwmchip(struct device_node *np) > > * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded > > * error code on failure. > > */ > > -struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id) > > +struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np, > > + const char *con_id) > > { > > struct pwm_device *pwm = NULL; > > struct of_phandle_args args; > > @@ -689,6 +691,9 @@ struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id) > > if (IS_ERR(pwm)) > > goto put; > > > > + if (!device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER)) > > + pr_debug("%s(): device link not added\n", __func__); > > + > > Just asking... will this mechanism also be working for PWMs requested via > sysfs? At a first look it seems not. No, but I would not expect a problem because AFAIU userspace is suspended before kernel devices. However as userspace might not notice the suspend it probably fails to stop the pwm and so will likely prevent the suspend. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |