Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5929898imu; Tue, 13 Nov 2018 14:07:20 -0800 (PST) X-Google-Smtp-Source: AJdET5f3ntlEZWtM/EcaiszN++rMwas7HjklCsYF2UWUx6ivwKQzwv4dmtfczLcL9sKKC8EClZi6 X-Received: by 2002:a62:2803:: with SMTP id o3-v6mr7094512pfo.57.1542146840619; Tue, 13 Nov 2018 14:07:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542146840; cv=none; d=google.com; s=arc-20160816; b=igSDvpTOaKbBfLzjeDiFRIh2xzNz9QAUpKwO67o31VQ20Qqc66rvRMBjgKFdz70E7Q 5XmGGt7GG2a3WMk58EHv1E5haqL1RQEOwW+5oTnh9C7iuflbEVVUgBMHlnubhf/TYiJ+ eShNM1Vbln4aBVDpDXZLavNff7RhiAKPXKQjQnu9zCMTo3oRWAz6v3Iyfnsv1FOVthHr VsKKus36a/+47jx2O4WABe/L9yfP0vD3LwQ7VgDw4VLZZmi/oFPQOzom1k+wEMZUhYh1 6uK/ccKeSh4cySqU+Kp8ZOMMfYXP56tPNISsYeHNjgKfrYAezopog+Ni6gLyl4zykrzH ogFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=YFIEBqVv5UO4Gg7ttb4fv+yrCwf7OoZpjHpQf/T0jbs=; b=lMP9BNtlb5QHfQA/zKLELpgaAOR/v6yo9nCMeLUSnVUSOij/DYus3nmV/BOvnw0Xt8 vfGAA9mzqxMoUBGaeIZCHwwHOZB9HFK6DorYSaWi5Qc4wvXwirBeb0/F0sN+53+oDyth Y+9ReUTefGmIpCu4OQ5nNtsoH8w4OAGacI4tMMt7beMsKh5C263IMSCuWQCtY8TRCcys ZYRpG34m196ZSjl81nBdMW3uAdtWJOCF+AgEK5gZ93mK4spoLMjV88DsE+RFz77V7thQ +9CPgGcBR9Gu6hnl1wvJWaY8Vh3ZBQ5nSfMMlMnybEYjuQeqgNM+hsW5M/reXpySmW8Q atIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@laptop-org.20150623.gappssmtp.com header.s=20150623 header.b=Bw9+lctc; 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 w31-v6si22854337pla.347.2018.11.13.14.07.05; Tue, 13 Nov 2018 14:07:20 -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; dkim=pass header.i=@laptop-org.20150623.gappssmtp.com header.s=20150623 header.b=Bw9+lctc; 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 S1730896AbeKNIGt (ORCPT + 99 others); Wed, 14 Nov 2018 03:06:49 -0500 Received: from mail-pl1-f196.google.com ([209.85.214.196]:34119 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726408AbeKNIGt (ORCPT ); Wed, 14 Nov 2018 03:06:49 -0500 Received: by mail-pl1-f196.google.com with SMTP id f12-v6so6712508plo.1 for ; Tue, 13 Nov 2018 14:06:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=laptop-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:organization:user-agent; bh=YFIEBqVv5UO4Gg7ttb4fv+yrCwf7OoZpjHpQf/T0jbs=; b=Bw9+lctcbTOmWmsUY6nkEZ+uw8Q+WSFBuXgO4gL3Bw+F2XoADggdiMWlC1/OkMU7Ad k1K2sEdFk7I1n3OXyJrcEwo6zqiyp+WGqs9hp4wDXd3kL05ShB2Wu20fVlMT2BnbSS29 R/KfF5mgQ+TMPfprwU3jdgHPTHcxMOgZmHPXft5GjNyPelYFWLxP7VPdPghhIQY0vNOu Z3LHeDFiuRDLp4lnc6KuIdzpinLXGQAWgel78Bu5jrIibX6GxBn3NTCX4flplqo6zi1E BU+d01iakj3ezUGu36nMIUTR/Y5Nep7Pv0ODt7M8yOpZhgi6YdFHscCKS+5kQcKjjx6V Snug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:organization :user-agent; bh=YFIEBqVv5UO4Gg7ttb4fv+yrCwf7OoZpjHpQf/T0jbs=; b=r2eOfudYdBhf9uy090vHgG4N4u4z/UdvMaZL8MlOLIlIGy59L/im9SeiDqP7S6Ahxo 7dWxtpPJUHbl58IOHJXSuwa8R9z1jIN7FRpLOywPF+sb8ctAAPIH5rDffMxMw4sfcY0k amo+CUZQD8dyk8ozLt2SurodAiYNYBlp1Mm/T5k8bG5kU0DhACnfUNaOFBCixeYzOcgx KTODWJai85PCTbcLjvOC2+bMaWDO7DM5341Hx7AZLTDc6rDUjnpADQwOPpttShZmmx2m VtAW2RQZEBXH+qoQkqdRIbZADNpglpPrAuvi+yxMzQbRLWKwyS1IOHGHhd0T1Z7KaEPy HwMw== X-Gm-Message-State: AGRZ1gJn2R8Ls9vHT1GLWqQAkgqy/LplIZ1mpazM4fZgHmt6qo9HftUs 9Rs5CzD2R1+TUZ6Uno7guqMXHQ== X-Received: by 2002:a17:902:162:: with SMTP id 89-v6mr6858308plb.293.1542146797493; Tue, 13 Nov 2018 14:06:37 -0800 (PST) Received: from esk.lan (pa49-180-71-87.pa.nsw.optusnet.com.au. [49.180.71.87]) by smtp.gmail.com with ESMTPSA id b7-v6sm23695747pfg.56.2018.11.13.14.06.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Nov 2018 14:06:36 -0800 (PST) Received: from james by esk.lan with local (Exim 4.86_2) (envelope-from ) id 1gMgpL-0006md-9L; Wed, 14 Nov 2018 09:06:31 +1100 Date: Wed, 14 Nov 2018 09:06:31 +1100 From: James Cameron To: Lubomir Rintel Cc: Andy Shevchenko , Mark Brown , Geert Uytterhoeven , Darren Hart , Andy Shevchenko , Greg Kroah-Hartman , Sebastian Reichel , Rob Herring , Mark Rutland , Eric Miao , Haojian Zhuang , Daniel Mack , Robert Jarzmik , linux-spi , devicetree , Linux Kernel Mailing List , linux-arm Mailing List , Platform Driver , devel@driverdev.osuosl.org, Linux PM Subject: Re: [PATCH 06/15] Platform: OLPC: Add XO-1.75 EC driver Message-ID: <20181113220631.GB22127@us.netrek.org> References: <20181010172300.317643-1-lkundrak@v3.sk> <20181010172300.317643-7-lkundrak@v3.sk> <8881f5e48613c9d9d133e3964031fe2ab57f4801.camel@v3.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8881f5e48613c9d9d133e3964031fe2ab57f4801.camel@v3.sk> Organization: Netrek Vanilla Server Dictator User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 13, 2018 at 06:26:09PM +0100, Lubomir Rintel wrote: > Hi, > > first of all -- thanks for such a careful review. It is very helpful. > > Wherever I don't respond to you, I'm just following what you wrote. It > would perhaps be tiresome to respond to "Yes, will fix in next version" > to every single point. > > I'll be following up with a new version in a few days; I'm mostly done > with this one but I've not finished addressing the followup ones. > > On Fri, 2018-10-19 at 19:06 +0300, Andy Shevchenko wrote: > > On Wed, Oct 10, 2018 at 8:24 PM Lubomir Rintel > > wrote: > > > It's based off the driver from the OLPC kernel sources. Somewhat > > > modernized and cleaned up, for better or worse. > > > > > > Modified to plug into the olpc-ec driver infrastructure (so that > > > battery > > > interface and debugfs could be reused) and the SPI slave framework. > > > +#include > > > > asm/* goes after linux/* > > > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > > Easy to maintain when it's sorted. > > > > > + { 0 }, > > > > Terminators are better without trailing comma. > > > > > +#define EC_CMD_LEN 8 > > > +#define EC_MAX_RESP_LEN 16 > > > +#define LOG_BUF_SIZE 127 > > > > 127 sounds slightly strange. Is it by specification of protocol? > > Would > > it be better to define it 128 bytes / items? > > > > > +static int olpc_xo175_ec_is_valid_cmd(u8 cmd) > > > +{ > > > + const struct ec_cmd_t *p; > > > + > > > + for (p = olpc_xo175_ec_cmds; p->cmd; p++) { > > > + if (p->cmd == cmd) > > > + return p->bytes_returned; > > > + } > > > + > > > + return -1; > > > > -EINVAL ? > > > > > +} > > > +static void olpc_xo175_ec_complete(void *arg); > > > > Hmm... Can we avoid forward declaration? > > I don't think we can. > > > > + channel = priv->rx_buf[0]; > > > + byte = priv->rx_buf[1]; > > > > Maybe specific structures would fit better? > > > > Like > > > > struct olpc_ec_resp_hdr { > > u8 channel; > > u8 byte; > > ... > > } > > > > > + dev_warn(dev, "kbd/tpad not supported\n"); > > > > Please, spell it fully as touchpad and keyboard. > > > > > + pm_wakeup_event(priv->pwrbtn->dev.parent, > > > 1000); > > > > Magic number. > > > > > + /* For now, we just ignore the unknown > > > events. */ > > > > dev_dbg(dev, "Ignored unknown event %.2x\n", byte); > > > > ? > > > > > if (isprint(byte)) { > > > + priv->logbuf[priv->logbuf_len++] = byte; > > > + if (priv->logbuf_len == LOG_BUF_SIZE) > > > + olpc_xo175_ec_flush_logbuf(priv); > > > + } > > > > You may consider to take everything and run %pE when printing instead > > of %s. > > > > > +static int olpc_xo175_ec_cmd(u8 cmd, u8 *inbuf, size_t inlen, u8 > > > *resp, > > > + size_t resp_len, void > > > *ec_cb_arg) > > > +{ > > > + struct olpc_xo175_ec *priv = ec_cb_arg; > > > + struct device *dev = &priv->spi->dev; > > > + unsigned long flags; > > > + int nr_bytes; > > > + int ret = 0; > > > + > > > + dev_dbg(dev, "CMD %x, %d bytes expected\n", cmd, resp_len); > > > + > > > + if (inlen > 5) { > > > > Magic number. > > > > > + dev_err(dev, "command len %d too big!\n", > > > resp_len); > > > + return -EOVERFLOW; > > > + } > > > + WARN_ON(priv->suspended); > > > + if (priv->suspended) > > > > if (WARN_ON(...)) ? > > > > > + return -EBUSY; > > > + if (resp_len > nr_bytes) > > > + resp_len = nr_bytes; > > > > resp_len = min(resp_len, nr_bytes); > > > > > + priv->cmd[0] = cmd; > > > + priv->cmd[1] = inlen; > > > + priv->cmd[2] = 0; > > > > Perhaps specific struct header for this? > > > > > + memset(resp, 0, resp_len); > > > > Wouldn't be better to do this in where actual response has been > > filled? > > > > > + if (!wait_for_completion_timeout(&priv->cmd_done, > > > + msecs_to_jiffies(4000))) { > > > > Magic number. > > > > > + } > > > + /* Deal with the results. */ > > > > Somehow feels noisy / unneeded comment. > > > > > + if (priv->cmd_state == CMD_STATE_ERROR_RECEIVED) { > > > + /* EC-provided error is in the single response byte > > > */ > > > + dev_err(dev, "command 0x%x returned error 0x%x\n", > > > + cmd, priv- > > > >resp[0]); > > > > Indentation. > > > > > + ret = -EREMOTEIO; > > > + } else if (priv->resp_len != nr_bytes) { > > > + dev_err(dev, "command 0x%x returned %d bytes, > > > expected %d bytes\n", > > > + cmd, priv- > > > >resp_len, nr_bytes); > > > + ret = -ETIMEDOUT; > > > > In the message I see nothing about timeout. > > > > > + } else { > > > + } > > > +} > > > +static int olpc_xo175_ec_set_event_mask(unsigned int mask) > > > +{ > > > + unsigned char args[2]; > > > > u8 > > > > > + > > > + args[0] = mask & 0xff; > > > + args[1] = (mask >> 8) & 0xff; > > > > ...mask >> 0; > > ...mask >> 8; > > > > > + return olpc_ec_cmd(CMD_WRITE_EXT_SCI_MASK, args, 2, NULL, > > > 0); > > > +} > > > + > > > +static void olpc_xo175_ec_restart(enum reboot_mode mode, const > > > char *cmd) > > > +{ > > > + while (1) { > > > + olpc_ec_cmd(CMD_POWER_CYCLE, NULL, 0, NULL, 0); > > > + mdelay(1000); > > > + } > > > +} > > > + > > > +static void olpc_xo175_ec_power_off(void) > > > +{ > > > + while (1) { > > > + olpc_ec_cmd(CMD_POWER_OFF, NULL, 0, NULL, 0); > > > + mdelay(1000); > > > + } > > > +} > > > + > > > +#ifdef CONFIG_PM > > > +static int olpc_xo175_ec_suspend(struct device *dev) > > > > __maybe_unused instead of ugly #ifdef? > > > > > +{ > > > + struct platform_device *pdev = to_platform_device(dev); > > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev); > > > > dev_get_drvdata() or how is it called? > > > > > + unsigned char hintargs[5]; > > > > struct olpc_ec_hint_cmd { > > u8 ... > > u32 ... > > }; > > > > ? > > > > > + static unsigned int suspend_count; > > > > u32 I suppose. > > > > > + > > > + suspend_count++; > > > + dev_dbg(dev, "%s: suspend sync %08x\n", __func__, > > > suspend_count); > > > > __func__ can be issued if user asked for via Dynamic Debug interface. > > > > > + /* > > > + * First byte is 1 to indicate suspend, the rest is an > > > integer > > > + * counter. > > > + */ > > > + hintargs[0] = 1; > > > + memcpy(&hintargs[1], &suspend_count, 4); > > > + olpc_ec_cmd(CMD_SUSPEND_HINT, hintargs, 5, NULL, 0); > > > > What do you need this counter for? > > It doesn't seem to be actually used in the EC; the firmware just > includes it in its debug log. I'm not sure if all firmware versions > behave this way and I'd prefer to keep it. Some firmware versions rely on it, as the SOC_SLEEP line was unreliable where the board revision is B3 or earlier. (internal reference: Paul Fox Wed, 10 Oct 2012 09:39:44 -0400) Although population of B3 and earlier was low, prototypes were given out to many rather than destroyed. > > I'm adding a comment. > > > > > > + priv->suspended = true; > > > > Hmm... Who is the user of it? > > > > > + return 0; > > > +} > > > + > > > +static int olpc_xo175_ec_resume_noirq(struct device *dev) > > > +{ > > > + struct platform_device *pdev = to_platform_device(dev); > > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev); > > > + > > > + priv->suspended = false; > > > + > > > + return 0; > > > +} > > > + > > > +static int olpc_xo175_ec_resume(struct device *dev) > > > +{ > > > + struct platform_device *pdev = to_platform_device(dev); > > > + struct olpc_xo175_ec *priv = platform_get_drvdata(pdev); > > > + unsigned char x = 0; > > > > u8 > > > > > + priv->suspended = false; > > > > Isn't it redundant since noirq callback above? > > > > > + /* > > > + * The resume hint is only needed if no other commands are > > > + * being sent during resume. all it does is tell the EC > > > + * the SoC is definitely awake. > > > + */ > > > + olpc_ec_cmd(CMD_SUSPEND_HINT, &x, 1, NULL, 0); > > > + > > > + /* Enable all EC events while we're awake */ > > > + olpc_xo175_ec_set_event_mask(0xffff); > > > > #define EC_ALL_EVENTS GENMASK(15, 0) > > > > > +} > > > +#endif > > > +static struct platform_device *olpc_ec; > > > > I would rather see this at the top of file. > > > > > +static int olpc_xo175_ec_probe(struct spi_device *spi) > > > +{ > > > + if (olpc_ec) { > > > + dev_err(&spi->dev, "OLPC EC already > > > registered.\n"); > > > + return -EBUSY; > > > + } > > > > It's racy against parallel probe called. I don't think it would be a > > real issue, just let you know. > > > > > > > + /* Set up power button input device */ > > > + priv->pwrbtn = devm_input_allocate_device(&spi->dev); > > > + if (!priv->pwrbtn) > > > + return -ENOMEM; > > > + priv->pwrbtn->name = "Power Button"; > > > + priv->pwrbtn->dev.parent = &spi->dev; > > > + input_set_capability(priv->pwrbtn, EV_KEY, KEY_POWER); > > > + ret = input_register_device(priv->pwrbtn); > > > + if (ret) { > > > + dev_err(&spi->dev, "error registering input device: > > > %d\n", ret); > > > + return ret; > > > + } > > > > I would split out power button driver, but it's up to you. > > > > > > > + /* Enable all EC events while we're awake */ > > > + olpc_xo175_ec_set_event_mask(0xffff); > > > > See above about this magic. > > > > > +} > > > +#ifdef CONFIG_PM > > > + .suspend = olpc_xo175_ec_suspend, > > > + .resume_noirq = olpc_xo175_ec_resume_noirq, > > > + .resume = olpc_xo175_ec_resume, > > > +#endif > > > > SET_SYSTEM_SLEEP_PM_OPS() ? > > SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() ? > > > > > +static const struct of_device_id olpc_xo175_ec_of_match[] = { > > > + { .compatible = "olpc,xo1.75-ec" }, > > > + { }, > > > > No comma for terminators. > > > > > +}; > > Thanks, > Lubo > -- James Cameron http://quozl.netrek.org/