Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3477339imu; Mon, 7 Jan 2019 04:12:49 -0800 (PST) X-Google-Smtp-Source: ALg8bN63b5Ak3KQCIJxQ792tGRm7mns3BpLB9tXYQEY70WPxw8Yb3seim0zEK9raCwYzMjlXseQ+ X-Received: by 2002:a17:902:8541:: with SMTP id d1mr62061375plo.205.1546863169165; Mon, 07 Jan 2019 04:12:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546863169; cv=none; d=google.com; s=arc-20160816; b=ZaKMVW6184e8pwlA/6oeU+eidmmdeTzuNVJ/cdGfj/+PONtk0RGE9mNjz7m/awarCT T8aM+aUs5r8vR0ejzKOAU5S2ocOTy09+fuBCOGPr9Uf7ZT/5YIuYwoeQdsMCpMmw/CiO 6jeM3AFWq/MgawNk/8Z0qNgiqYJXlNGOWGI/d5uW9tJWohxctgl+eC/l8zM+zrsacE9L VA4iu4Faamr1pWIN41drkhYIPF7Gh6f2g0hI3478xwNX30CpGyGTjE1gvBuSXC0Dbo63 No4tGv1qSSJLRxomy4RWTO6CxI3ZpMb9OIE6OiOb9rhRr8Uds42eMqOBdEIL6cq7YomA DBxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=bgATrNcdkkbPe9n1bORWgh8Jq1Dlse5ZFCcIAi+M814=; b=vmaGtL1F6/s/5F7xe5hs9gth7UQXN8gxSuMSBPu+2hMhlLwNLZs1fq/4wAzMcz5J8K 1viMcIEzBJrY2fQvtj84cvx8ioIRNVg5ugE0SjRdrGWesJ77Cz8XAzHXNHITQYnecS/o LXseomt7zj83ZqMTZnvi7D+hr5UF+XTC0OIY8H+cx0BJ4L0Q6aGScBf4qIzbwaget1xd AIG6DqzqT/leUSrr3EihaO3daZ/qfagBNq8Tod1ZqGgWNMxcxxXHrxvnaRI6ffZiVFfT bLbMe9XhsW3z2zwGOcycQkeYDs6b5IOVH9/2PEZg7B07dBtWSUbOVyvunlHxbjate+Vl KMmg== 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 q26si61181623pgk.162.2019.01.07.04.12.34; Mon, 07 Jan 2019 04:12:49 -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 S1726987AbfAGMLU (ORCPT + 99 others); Mon, 7 Jan 2019 07:11:20 -0500 Received: from mx2.suse.de ([195.135.220.15]:54148 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726873AbfAGMLT (ORCPT ); Mon, 7 Jan 2019 07:11:19 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DF719AF5D; Mon, 7 Jan 2019 12:11:17 +0000 (UTC) Message-ID: <1546863075.3037.33.camel@suse.com> Subject: Re: [PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver From: Oliver Neukum To: Andreas =?ISO-8859-1?Q?F=E4rber?= , linux-lpwan@lists.infradead.org, linux-serial@vger.kernel.org Cc: "David S. Miller" , Johan Hovold , Rob Herring , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, netdev@vger.kernel.org Date: Mon, 07 Jan 2019 13:11:15 +0100 In-Reply-To: <20190104112131.14451-4-afaerber@suse.de> References: <20190104112131.14451-1-afaerber@suse.de> <20190104112131.14451-4-afaerber@suse.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fr, 2019-01-04 at 12:21 +0100, Andreas Färber wrote: > > +struct picogw_device { > + struct serdev_device *serdev; > + > + u8 rx_buf[1024]; No, you cannot do that. AFAICT this buffer can be used for DMA. Thus putting it into another data structure violates the rules of DMA coherency. You must allocate it separately. > +static int picogw_send_cmd(struct picogw_device *picodev, char cmd, > + u8 addr, const void *data, u16 data_len) > +{ > + struct serdev_device *sdev = picodev->serdev; > + u8 buf[4]; > + int i, ret; > + > + buf[0] = cmd; > + buf[1] = (data_len >> 8) & 0xff; > + buf[2] = (data_len >> 0) & 0xff; We have macros for converting endianness and unaligned access. > + buf[3] = addr; > + > + dev_dbg(&sdev->dev, "%s: %c %02x %02x %02x\n", __func__, buf[0], > + (unsigned int)buf[1], (unsigned int)buf[2], (unsigned int)buf[3]); > + for (i = 0; i < data_len; i++) { > + dev_dbg(&sdev->dev, "%s: data %02x\n", __func__, (unsigned int)((const u8*)data)[i]); > + } > + > + ret = serdev_device_write_buf(sdev, buf, 4); > + if (ret < 0) > + return ret; > + if (ret != 4) > + return -EIO; > + > + if (data_len) { > + ret = serdev_device_write_buf(sdev, data, data_len); > + if (ret < 0) > + return ret; > + if (ret != data_len) > + return -EIO; > + } > + > + return 0; > +} > + > +static int picogw_recv_answer(struct picogw_device *picodev, > + char *cmd, bool *ack, void *buf, int buf_len, > + unsigned long timeout) > +{ > + int len; > + > + timeout = wait_for_completion_timeout(&picodev->answer_comp, timeout); > + if (!timeout) > + return -ETIMEDOUT; And? The IO is still scheduled. Simply erroring out is problematic. If you see a timeout you need to kill the scheduled IO. > +static int picogw_handle_answer(struct picogw_device *picodev) > +{ > + struct device *dev = &picodev->serdev->dev; > + unsigned int data_len = ((u16)picodev->rx_buf[1] << 8) | picodev->rx_buf[2]; > + int cmd_len = 4 + data_len; > + int i, ret; > + > + if (picodev->rx_len < 4) > + return 0; > + > + if (cmd_len > sizeof(picodev->rx_buf)) { > + dev_warn(dev, "answer too long (%u)\n", data_len); > + return 0; > + } > + > + if (picodev->rx_len < cmd_len) { > + dev_dbg(dev, "got %u, need %u bytes\n", picodev->rx_len, cmd_len); > + return 0; > + } > + > + dev_dbg(dev, "Answer %c =%u %s (%u)\n", picodev->rx_buf[0], > + (unsigned int)picodev->rx_buf[3], > + (picodev->rx_buf[3] == 1) ? "OK" : "K0", > + data_len); > + for (i = 0; i < data_len; i++) { > + //dev_dbg(dev, "%s: %02x\n", __func__, (unsigned int)picodev->rx_buf[4 + i]); > + } > + > + complete(&picodev->answer_comp); > + ret = wait_for_completion_interruptible_timeout(&picodev->answer_read_comp, HZ / 2); Problematic. You have no idea when that complete() will have an effect. You are operating with an undefined timeout here. Theoretically it could be negative. Regards Oliver