Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2565842ybt; Mon, 22 Jun 2020 01:23:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9oYBQftJhqtpHq7JAHWQ8YuJIw62v5gotXLuvHq+tpiJjSczjNbct6XXgihEqYfKe6qxr X-Received: by 2002:a17:907:94c4:: with SMTP id dn4mr14095362ejc.150.1592814194153; Mon, 22 Jun 2020 01:23:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592814194; cv=none; d=google.com; s=arc-20160816; b=Fuwm/jq3dNLdKADmrmdy1kObefREzRz/eZZ4sSKDBvaKafGZmz/suHSx9iLeI0h8HM s47I0RNFbZGYCggAhHPe/y9ngXWqkI7jOzkIZpJn+yw5zUy62xnGYtqwhSrfUbBB7NUp FNtkNi3w5CH6tGdUSC8WqALZMe8v5EcCSVi7TENokWcLp9Xz220TtwjE7f6OPFhBsGMu 14RRVDyiuCtRyDQfyTXJKse0nDqypLjRnGVM98lXB32TTt2rXtzKlZs0Us576UigPX03 3oLLK0JKX5ixWAayAgaA+g5fGeBlxWobHLbnLLL8eYcz/2ERpyKyz7tBjoBNhsMHp43r dy/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=6yo6sOkfQGmg4hEFNO2X/+erjdLtZn5U0ZyDD1LeOo4=; b=oMasO4owbb1uW3x57vwrbUCmqkvt5AyR5xjE+m4UXbsAIdBT4dotP/gl6XhsjBPOTj zT6Hf6//fu7jzQPEUMTWzWeMzPsnU1PxhdcskYwXn96DQeOI6WqE8GkizhjK9TWCV9Ub hB9yzugyir36s4T6TlniCUuKa4H1O0HhYAbiELlLt32RgGj+640tcpAUd+lSbKsxzgWl HDHJ8H7Em8O3EfVuihJoxv2nxPBXWKDzatrtJ8P1NEW3oPHsDy0Q+A2KParEmuwrQ+zW oWlin6okct2KWgq9fSzLpSM0lSVx4Fs3w8pADSOx/PtYE0KkFOpnJ0rKl1rzU6UJofJu C6UQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s15si8746844ejz.132.2020.06.22.01.22.51; Mon, 22 Jun 2020 01:23:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726827AbgFVIS1 (ORCPT + 99 others); Mon, 22 Jun 2020 04:18:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726196AbgFVIS0 (ORCPT ); Mon, 22 Jun 2020 04:18:26 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADD7DC061794 for ; Mon, 22 Jun 2020 01:18:25 -0700 (PDT) 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.92) (envelope-from ) id 1jnHel-0004I1-8V; Mon, 22 Jun 2020 10:18:19 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1jnHeU-0003pu-F0; Mon, 22 Jun 2020 10:18:02 +0200 Date: Mon, 22 Jun 2020 10:18:02 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Jonathan =?utf-8?Q?Neusch=C3=A4fer?= Cc: linux-kernel@vger.kernel.org, Alexandre Belloni , Heiko Stuebner , linux-pwm@vger.kernel.org, Linus Walleij , Thierry Reding , Fabio Estevam , linux-rtc@vger.kernel.org, Mauro Carvalho Chehab , Sam Ravnborg , Andreas Kemnade , NXP Linux Team , devicetree@vger.kernel.org, Stephan Gerhold , allen , Sascha Hauer , Lubomir Rintel , Rob Herring , Lee Jones , linux-arm-kernel@lists.infradead.org, Alessandro Zummo , Mark Brown , Pengutronix Kernel Team , Heiko Stuebner , Josua Mayer , Shawn Guo , "David S. Miller" Subject: Re: [RFC PATCH 06/10] pwm: ntxec: Add driver for PWM function in Netronix EC Message-ID: <20200622081802.pv4xmb7vn4te5r5t@taurus.defre.kleine-koenig.org> References: <20200620224222.1312520-1-j.neuschaefer@gmx.net> <20200620224222.1312520-5-j.neuschaefer@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7tfyuhyp2zipmowo" Content-Disposition: inline In-Reply-To: <20200620224222.1312520-5-j.neuschaefer@gmx.net> 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 --7tfyuhyp2zipmowo Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Sun, Jun 21, 2020 at 12:42:17AM +0200, Jonathan Neusch=E4fer wrote: > The Netronix EC provides a PWM output, which is used for the backlight s/,// > on ebook readers. This patches adds a driver for the PWM output. on *some* ebook readers > +#define NTXEC_UNK_A 0xa1 > +#define NTXEC_UNK_B 0xa2 > +#define NTXEC_ENABLE 0xa3 > +#define NTXEC_PERIOD_LOW 0xa4 > +#define NTXEC_PERIOD_HIGH 0xa5 > +#define NTXEC_DUTY_LOW 0xa6 > +#define NTXEC_DUTY_HIGH 0xa7 > + > +/* > + * The time base used in the EC is 8MHz, or 125ns. Period and duty cycle= are > + * measured in this unit. > + */ > +static int ntxec_pwm_config(struct pwm_chip *chip, struct pwm_device *pw= m_dev, > + int duty_ns, int period_ns) > +{ > + struct ntxec_pwm *pwm =3D pwmchip_to_pwm(chip); > + uint64_t duty =3D duty_ns; > + uint64_t period =3D period_ns; As you cannot use values bigger than 8191999 anyhow, I wonder why you use a 64 bit type here. > + int res =3D 0; > + > + do_div(period, 125); Please use a define instead of plain 125. > + if (period > 0xffff) { > + dev_warn(pwm->dev, > + "Period is not representable in 16 bits: %llu\n", period); > + return -ERANGE; > + } > + > + do_div(duty, 125); > + if (duty > 0xffff) { > + dev_warn(pwm->dev, "Duty cycle is not representable in 16 bits: %llu\n= ", > + duty); > + return -ERANGE; > + } This check isn't necessary as the pwm core ensures that duty <=3D period. > + res |=3D ntxec_write8(pwm->ec, NTXEC_PERIOD_HIGH, period >> 8); > + res |=3D ntxec_write8(pwm->ec, NTXEC_PERIOD_LOW, period); > + res |=3D ntxec_write8(pwm->ec, NTXEC_DUTY_HIGH, duty >> 8); > + res |=3D ntxec_write8(pwm->ec, NTXEC_DUTY_LOW, duty); Does this complete the currently running period? Can it happen that a new period starts between the first and the last write and so a mixed period can be seen at the output? > + > + return (res < 0) ? -EIO : 0; > +} > + > +static int ntxec_pwm_enable(struct pwm_chip *chip, > + struct pwm_device *pwm_dev) > +{ > + struct ntxec_pwm *pwm =3D pwmchip_to_pwm(chip); > + > + return ntxec_write8(pwm->ec, NTXEC_ENABLE, 1); > +} > + > +static void ntxec_pwm_disable(struct pwm_chip *chip, > + struct pwm_device *pwm_dev) > +{ > + struct ntxec_pwm *pwm =3D pwmchip_to_pwm(chip); > + > + ntxec_write8(pwm->ec, NTXEC_ENABLE, 0); > +} > + > +static struct pwm_ops ntxec_pwm_ops =3D { > + .config =3D ntxec_pwm_config, > + .enable =3D ntxec_pwm_enable, > + .disable =3D ntxec_pwm_disable, > + .owner =3D THIS_MODULE, Please don't align the =3D, just a single space before them is fine. More important: Please implement .apply() (and .get_state()) instead of the old API. Also please enable PWM_DEBUG which might save us a review iteration. > +}; > + > +static int ntxec_pwm_probe(struct platform_device *pdev) > +{ > + struct ntxec *ec =3D dev_get_drvdata(pdev->dev.parent); > + struct ntxec_pwm *pwm; > + struct pwm_chip *chip; > + int res; > + > + pwm =3D devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL); > + if (!pwm) > + return -ENOMEM; > + > + pwm->ec =3D ec; > + pwm->dev =3D &pdev->dev; > + > + chip =3D &pwm->chip; > + chip->dev =3D &pdev->dev; > + chip->ops =3D &ntxec_pwm_ops; > + chip->base =3D -1; > + chip->npwm =3D 1; > + > + res =3D pwmchip_add(chip); > + if (res < 0) > + return res; > + > + platform_set_drvdata(pdev, pwm); > + > + res |=3D ntxec_write8(pwm->ec, NTXEC_ENABLE, 0); > + res |=3D ntxec_write8(pwm->ec, NTXEC_UNK_A, 0xff); > + res |=3D ntxec_write8(pwm->ec, NTXEC_UNK_B, 0xff); > + > + return (res < 0) ? -EIO : 0; This is broken for several reasons: - You're not supposed to modify the output in .probe - if ntxec_write8 results in an error you keep the pwm registered. - From the moment on pwmchip_add returns the callbacks can be called. The calls to ntxec_write8 probably interfere here. Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --7tfyuhyp2zipmowo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl7waTcACgkQwfwUeK3K 7Alz9gf8C+9A/FPfdyoWF4DcZ7zjNKarHze44XtL4sUIkJfLYl9xqKr+/YjB9EYr 6Z/sukeRDw5Gn0DZo0kgntYx5TcLztsQxB7TFVhO6cj25+uzwnJwumN4DQxJlOqY u30aZH1IyFoG2PTDKyCnOrxrWGnK2VsUqV5t5g8RgIUIJysGaMtUgiwvyggtXvKv jMLcjm5QBnrsU56rkZYJGiXtcz+L6lGF7rd1cXWPR3nfgXngWPEBe/NjnqChsfsy VRF8nb6G46xF7c58IARrMRiH43wLcHLhtKvIStC17t5on0FbfuL3jFMT1wylV+E5 lZ9Y/VFroSxQX6EARBDDa2E/J38PSg== =eoxM -----END PGP SIGNATURE----- --7tfyuhyp2zipmowo--