Received: by 2002:a05:7412:b112:b0:f9:3106:f1c0 with SMTP id az18csp130742rdb; Mon, 18 Dec 2023 01:03:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IF+83OToT5bOaDh91xxUMUef7Y1IrBxezr6Y2u2C8AqEXUYU3ETFRSWjAhrX68VQ669ie5g X-Received: by 2002:a05:6e02:1e08:b0:35f:535a:9c68 with SMTP id g8-20020a056e021e0800b0035f535a9c68mr21094407ila.85.1702890239378; Mon, 18 Dec 2023 01:03:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702890239; cv=none; d=google.com; s=arc-20160816; b=Dx1zLFau/LYG5RawW3eu0Un8NQ5udIdqDsP8azL4akQHQiVtjq9/5gh4ngBMinKyMh v+rHc05a2c/iQ8mpoeWgTIGehMNRXnBOm/wLpxEFxTD+z5k18acRvHDhEx3bxjXtcqvz bIpqpENvNLwj9HpmnO4cJkEcMKJw7Vm+3pfKr4uXMlXB1NHWMqvv8xsr+9Z8OVh+0tQM DJw7iz9glnC2emR0B56Vvnd0qKhGc49s8EtkLEiM6HC+SDH5eDY4kHRmJIGB48LmNqEx WUvL8KpAiYGIbhKhhwYIKSQ5fyld7robVpZAre0lfh2epEkK42/fAnWCNO4DcP9qPeZv ZSlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=iVBLZWsgioFfVWIWFYWHEdljzEsQVzpnvURPB02y+Sc=; fh=WxFGxY2cNnb5TOzdbVcDUYfOHsHoe85SkRl7ILRXLZM=; b=baqLGTr9Vhn75oUz0IrUS7ZNnFcWXzpPmPsqm56DfvcLoqfa8YAEaar4yOsQtMqQNF coOsXR7qFzpXfI2rIrz/N4/OVEg/e2hc2ed7o4sblChNjqATffGYyLgbeSxGDgU8bY5N n3CWMt/LWTuYaJJ4PmWlhLnoR4OvH7NsTMyKAq/gMOuddzmNNE+pfoRphndqQGHHB1/7 PnbS7jzX8sUVSTcMDHcs0AGoBCNEXDonZFACQ3Z0Bxf0ngCCnFbwHfMJAJZY1q4Lgr/3 sMQEtTAPeZt8pJ8a/NtAo1JTroUPjeRwRcyKF9uj6nexHZa3TvWxFF15OYKqyXeBuuCD vQUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mess.org header.s=2020 header.b=jehA85YU; spf=pass (google.com: domain of linux-kernel+bounces-3205-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-3205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mess.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id m7-20020a635807000000b005c665c81b7bsi17121238pgb.36.2023.12.18.01.03.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 01:03:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-3205-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@mess.org header.s=2020 header.b=jehA85YU; spf=pass (google.com: domain of linux-kernel+bounces-3205-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-3205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mess.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 0A4D82833AD for ; Mon, 18 Dec 2023 09:03:59 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A0BEA11CA6; Mon, 18 Dec 2023 09:03:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mess.org header.i=@mess.org header.b="jehA85YU" X-Original-To: linux-kernel@vger.kernel.org Received: from gofer.mess.org (gofer.mess.org [88.97.38.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 74C70111AA; Mon, 18 Dec 2023 09:03:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mess.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mess.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mess.org; s=2020; t=1702890208; bh=gXF4zwPtrzbsMvzl/OG/KlHSiLQN4XqG8q1rytTusLw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jehA85YU9WcbUoRVBvQQxScipzxMzPY/w9KZfL8dL0jEdc4grQY/dzJ9r6pzDBhaP T/u++SErVxB09yqNG+QldWap8LSCGZCbualEWsuuFpGrn/6e6Nea+N2aJi5T5iX04o 6htm44WrCVg4cICcuuXCx6Y8i4TiC5JpAcjrLAX4FpYCnji60vittpFlXz6JgV5Owr kkK3gCWFlr3Ehyt/KTrJ/0f5kfEueBriNTjLCv+RPD05UcMxHoINLL+dPfPVQjyWzs BY9O6chbSue2t/O7PcPPwvZO4JQuFy7wI0aL8QFnDNyCS6fHfJO3Bd4JvMXIENXXY2 PNjmIQVMKUruQ== Received: by gofer.mess.org (Postfix, from userid 1000) id A984110029E; Mon, 18 Dec 2023 09:03:28 +0000 (GMT) Date: Mon, 18 Dec 2023 09:03:28 +0000 From: Sean Young To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: linux-media@vger.kernel.org, linux-pwm@vger.kernel.org, Ivaylo Dimitrov , Thierry Reding , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 4/6] pwm: Make it possible to apply PWM changes in atomic context Message-ID: References: <57f48330eb606356e86be17f85253f0e3d6ab104.1702369869.git.sean@mess.org> <20231212114812.afzgjiunzc6druov@pengutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231212114812.afzgjiunzc6druov@pengutronix.de> Hello Uwe, On Tue, Dec 12, 2023 at 12:48:12PM +0100, Uwe Kleine-K?nig wrote: > On Tue, Dec 12, 2023 at 08:34:03AM +0000, Sean Young wrote: > > +/** > > + * pwm_apply_might_sleep() - atomically apply a new state to a PWM device > > + * Cannot be used in atomic context. > > + * @pwm: PWM device > > + * @state: new state to apply > > + */ > > +int pwm_apply_might_sleep(struct pwm_device *pwm, const struct pwm_state *state) > > +{ > > + int err; > > + > > + /* > > + * Some lowlevel driver's implementations of .apply() make use of > > + * mutexes, also with some drivers only returning when the new > > + * configuration is active calling pwm_apply_might_sleep() from atomic context > > + * is a bad idea. So make it explicit that calling this function might > > + * sleep. > > + */ > > + might_sleep(); > > + > > + if (IS_ENABLED(CONFIG_PWM_DEBUG) && pwm->chip->atomic) { > > + /* > > + * Catch any drivers that have been marked as atomic but > > + * that will sleep anyway. > > + */ > > + non_block_start(); > > + err = pwm_apply_unchecked(pwm, state); > > + non_block_end(); > > + } else { > > + err = pwm_apply_unchecked(pwm, state); > > + } > > + > > /* > > * only do this after pwm->state was applied as some > > * implementations of .get_state depend on this > > */ > > - pwm_apply_debug(pwm, state); > > + if (!err) > > + pwm_apply_debug(pwm, state); > > It's easier to keep that in pwm_apply_unchecked(), isn't it? Then > pwm_apply_atomic() also benefits from the checks. Good point. > I'm not so happy with the function name of pwm_apply_unchecked(), but I > don't have a good suggestion either. Probably I'd have chosen > __pam_apply(), but that's probably subjective. That is more consistent, fixed in v9. Sean