Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3449382imu; Mon, 14 Jan 2019 03:15:36 -0800 (PST) X-Google-Smtp-Source: ALg8bN4C7eoNVwa0xyAHZxxrWyl43oPEYssbHk/9VewoNg0eewdnfY0jQlrDRY1l86YbEjxJsyrL X-Received: by 2002:a17:902:b20e:: with SMTP id t14mr25053975plr.128.1547464536884; Mon, 14 Jan 2019 03:15:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547464536; cv=none; d=google.com; s=arc-20160816; b=fQcDLE3KBTXzWcnSu2gnf6xxrcRNp8v9+EuQGbx3Jlr0f1rDd6ROJPz7YhDza+pNBx ROyXK4DWJDoDREQXLuwfbotVnDuG7TIvsEiG+GV4hT8knFg9v2TjNTOcvkNeYzUzHrG0 rou7j6PASFn9Bo0Ssa05SSeJu5P7uqxS4egabc+JBCOeXjq1EswDrbrPUFg9Ay8QN490 gXwc/B8xHGbGBrN3dduNlowLcNdaKrkRIrGRk0vTP7EmbuwTtx9PJsceghF8gdJshsI+ NBYt8GY9DdZz1lnwqxGQzVxsWrat3QUnVIiO3XDedvtKP2Iv0G273MUubB0ylCqQFP55 R3Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=svBCDBq8bWr+JrQJ41SKoxjOcMNQ6G0zJyH5TfvUZqU=; b=fdNzM6o4n8p3Bv36GDgqkD7tBfP83e5R3lnK1o3aPhKnkpFIGGX+Xauc/KRJlYY8CR BO0cV2CdmnE+nANxvtFC0QwizU1ksxvED/avk0+8wUiCUVmXNenWbgmWegvVDJrityS7 p5ZzwEyPMphCU6q2tJOIEUsRN3GqJUIXyYoln4QRlKi6pm7b31aca/bqaT/x+ZXJrbzd 8hpuULBMsftlKKAKSxobFQgwWzvHxizmD4/khd23+35UnkJi1MCAS9oM6oZFdLW3kFpy IA6Jhp5obEheRix1unB1U26lxT2LvtHP0DzKJ7lkcF7FFCSFwPUjmh80Q1rjLbHq6ya2 PRgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@jms.id.au header.s=google header.b=I4IWMPD1; 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 z18si7319pgk.367.2019.01.14.03.15.20; Mon, 14 Jan 2019 03:15:36 -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=@jms.id.au header.s=google header.b=I4IWMPD1; 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 S1726625AbfANLN1 (ORCPT + 99 others); Mon, 14 Jan 2019 06:13:27 -0500 Received: from mail-qt1-f175.google.com ([209.85.160.175]:33641 "EHLO mail-qt1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726526AbfANLN1 (ORCPT ); Mon, 14 Jan 2019 06:13:27 -0500 Received: by mail-qt1-f175.google.com with SMTP id l11so26056797qtp.0 for ; Mon, 14 Jan 2019 03:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=svBCDBq8bWr+JrQJ41SKoxjOcMNQ6G0zJyH5TfvUZqU=; b=I4IWMPD1UgIPQ60krEIXBmSSpQbIOL/hoYd704xzRq8Y5l3Y1B7CFABR3La3dEAh8N p4q+jEw6zxuYxl70NGCUNcyNpWhklR1JEZSrrGPUKY23YGXTb5yC5ZixT7vKFnNJhX2K NrE4sIzAy8Z41IER6MRmJfg6M33wf9rB96wTw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=svBCDBq8bWr+JrQJ41SKoxjOcMNQ6G0zJyH5TfvUZqU=; b=E8RBGgo8ur7JQmSUo7wGD2VWM5LUSLnCv/DnhweXUYzC/8Y/Qywxl/L4YtfrN2Mt6k AXJFJ7mFuYdmSHyyjQzmWe5ZxGIa9vEIVOV1jjiDFSKSL2f0Rf2hWIeXR9XB8g3PPjU6 PVxealZOR0uD7ldO3KLbQzHNYadkI1ryKJAOjt7Wl5ZzsjaUjmP1oBzBeaQObk6rARa8 lRAEg6gagmyGfZwtQmCN5yU0Y3OAitNT+MM3slLQV1TURtOk8vdTcLN6cqot+wfxa7mw cG4pmbIP+m8bkz7RddMsuEThtLltLnWLYAmDHEeVUa+b3fT+GcCkcrg8FE6LGC26hPfq dFhg== X-Gm-Message-State: AJcUukc7vrfQgD5O6aYvg6QzdF8LQ8T4oo3M4VQtGzVdTCBngcMTGcfz kzhnfDk5KUBrmVTuIWMJtI0LasWBhx3ISjfRB9E= X-Received: by 2002:ac8:3065:: with SMTP id g34mr23873498qte.136.1547464405416; Mon, 14 Jan 2019 03:13:25 -0800 (PST) MIME-Version: 1.0 References: <20190107214136.5256-1-jae.hyun.yoo@linux.intel.com> <20190107214136.5256-4-jae.hyun.yoo@linux.intel.com> In-Reply-To: <20190107214136.5256-4-jae.hyun.yoo@linux.intel.com> From: Joel Stanley Date: Mon, 14 Jan 2019 21:43:13 +1030 Message-ID: Subject: Re: [PATCH v10 03/12] peci: Add support for PECI bus driver core To: Jae Hyun Yoo Cc: Greg Kroah-Hartman , Arnd Bergmann , Linux Kernel Mailing List , OpenBMC Maillist , Viresh Kumar , Andy Shevchenko , Benjamin Herrenschmidt , Fengguang Wu , Jason M Biils , Julia Cartwright , Haiyue Wang , James Feist , Vernon Mauery Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Jae, On Tue, 8 Jan 2019 at 08:11, Jae Hyun Yoo wrote: > > This commit adds driver implementation for PECI bus core into linux > driver framework. I would like to help you get this merged next release cycle, as we are now carrying it in OpenBMC. I suggest we ask Greg to queue it up if there are no objections after you've addressed my questions. > +static u8 peci_aw_fcs(u8 *data, int len) I was wondering what aw_fcs meant. I notice that later on you describe it as an Assure Write Frame Check Sequence byte. You could add a comment next to this function :) Instead of casing to u8 every time you call this, you could have this take a struct peci_xfer_msg * and cast when calling crc8. > +{ > + return crc8(peci_crc8_table, data, (size_t)len, 0); > +} > + > +static int __peci_xfer(struct peci_adapter *adapter, struct peci_xfer_msg *msg, > + bool do_retry, bool has_aw_fcs) > +{ > + ktime_t start, end; > + s64 elapsed_ms; > + int rc = 0; > + > + /** These are for kerneldoc, and the comments aren't kerneldoc. Replace them with /* instead. > + * For some commands, the PECI originator may need to retry a command if > + * the processor PECI client responds with a 0x8x completion code. In > + * each instance, the processor PECI client may have started the > + * operation but not completed it yet. When the 'retry' bit is set, the > + * PECI client will ignore a new request if it exactly matches a > + * previous valid request. > + */ > + > + if (do_retry) > + start = ktime_get(); > + > + do { > + rc = adapter->xfer(adapter, msg); > + > + if (!do_retry || rc) > + break; > + > + if (msg->rx_buf[0] == DEV_PECI_CC_SUCCESS) > + break; > + > + /* Retry is needed when completion code is 0x8x */ > + if ((msg->rx_buf[0] & DEV_PECI_CC_RETRY_CHECK_MASK) != > + DEV_PECI_CC_NEED_RETRY) { > + rc = -EIO; > + break; > + } > + > + /* Set the retry bit to indicate a retry attempt */ > + msg->tx_buf[1] |= DEV_PECI_RETRY_BIT; > + > + /* Recalculate the AW FCS if it has one */ > + if (has_aw_fcs) > + msg->tx_buf[msg->tx_len - 1] = 0x80 ^ Can we guarantee that msg->tx_len will be set to non-zero whenever has_aw_fcs? I suggest checking before doing the assignment in case a new caller is added and they make a mistake. > +static int peci_ioctl_get_dib(struct peci_adapter *adapter, void *vmsg) > +{ > + struct peci_get_dib_msg *umsg = vmsg; > + struct peci_xfer_msg msg; > + int rc; > + > + msg.addr = umsg->addr; > + msg.tx_len = GET_DIB_WR_LEN; > + msg.rx_len = GET_DIB_RD_LEN; > + msg.tx_buf[0] = GET_DIB_PECI_CMD; > + > + rc = peci_xfer(adapter, &msg); Most of tx_buf is going to be uninitialised. I assume a well behaving adapter->xfer will check this and only send the correct number of bytes, but it might pay to zero out struct peci_xfer_msg in all of these functions? > + if (rc) > + return rc; > + > + umsg->dib = le64_to_cpup((__le64 *)msg.rx_buf); > + > + return 0; > +} > + > +#if IS_ENABLED(CONFIG_OF) > +static struct peci_client *peci_of_register_device(struct peci_adapter *adapter, > + struct device_node *node) > +{ > + struct peci_board_info info = {}; > + struct peci_client *result; > + const __be32 *addr_be; > + int len; > + > + dev_dbg(&adapter->dev, "register %pOF\n", node); > + > + if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) { I don't understand why you're doing this. Won't this always be peci, as your binding requires? > + dev_err(&adapter->dev, "modalias failure on %pOF\n", node); > + return ERR_PTR(-EINVAL); > + } > + > + addr_be = of_get_property(node, "reg", &len); > + if (!addr_be || len < sizeof(*addr_be)) { The second check looks suspicious. You could fix it to check the expected length (4), or use of_property_read_u32. > + dev_err(&adapter->dev, "invalid reg on %pOF\n", node); > + return ERR_PTR(-EINVAL); > + } > + > + info.addr = be32_to_cpup(addr_be); > + info.of_node = of_node_get(node); > + > + result = peci_new_device(adapter, &info); > + if (!result) Should you do an of_node_put here? > + result = ERR_PTR(-EINVAL); > + > + of_node_put(node); Why do you release the reference here? > + return result; > +} > +