From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Subject: Re: [PATCH lora-next 3/5] net: lora: sx130x: Add PicoCell serdev driver Date: Mon, 07 Jan 2019 13:11:15 +0100 Message-ID: <1546863075.3037.33.camel@suse.com> References: <20190104112131.14451-1-afaerber@suse.de> <20190104112131.14451-4-afaerber@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20190104112131.14451-4-afaerber@suse.de> Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: linux-serial@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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [lora-next,3/5] net: lora: sx130x: Add PicoCell serdev driver From: Oliver Neukum Message-Id: <1546863075.3037.33.camel@suse.com> Date: Mon, 07 Jan 2019 13:11:15 +0100 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 List-ID: T24gRnIsIDIwMTktMDEtMDQgYXQgMTI6MjEgKzAxMDAsIEFuZHJlYXMgRsOkcmJlciAgd3JvdGU6 Cj4gCj4gK3N0cnVjdCBwaWNvZ3dfZGV2aWNlIHsKPiArCXN0cnVjdCBzZXJkZXZfZGV2aWNlICpz ZXJkZXY7Cj4gKwo+ICsJdTggcnhfYnVmWzEwMjRdOwoKTm8sIHlvdSBjYW5ub3QgZG8gdGhhdC4g QUZBSUNUIHRoaXMgYnVmZmVyIGNhbiBiZSB1c2VkIGZvciBETUEuClRodXMgcHV0dGluZyBpdCBp bnRvIGFub3RoZXIgZGF0YSBzdHJ1Y3R1cmUgdmlvbGF0ZXMgdGhlIHJ1bGVzCm9mIERNQSBjb2hl cmVuY3kuIFlvdSBtdXN0IGFsbG9jYXRlIGl0IHNlcGFyYXRlbHkuCgo+ICtzdGF0aWMgaW50IHBp Y29nd19zZW5kX2NtZChzdHJ1Y3QgcGljb2d3X2RldmljZSAqcGljb2RldiwgY2hhciBjbWQsCj4g Kwl1OCBhZGRyLCBjb25zdCB2b2lkICpkYXRhLCB1MTYgZGF0YV9sZW4pCj4gK3sKPiArCXN0cnVj dCBzZXJkZXZfZGV2aWNlICpzZGV2ID0gcGljb2Rldi0+c2VyZGV2Owo+ICsJdTggYnVmWzRdOwo+ ICsJaW50IGksIHJldDsKPiArCj4gKwlidWZbMF0gPSBjbWQ7Cj4gKwlidWZbMV0gPSAoZGF0YV9s ZW4gPj4gOCkgJiAweGZmOwo+ICsJYnVmWzJdID0gKGRhdGFfbGVuID4+IDApICYgMHhmZjsKCldl IGhhdmUgbWFjcm9zIGZvciBjb252ZXJ0aW5nIGVuZGlhbm5lc3MgYW5kIHVuYWxpZ25lZCBhY2Nl c3MuCgo+ICsJYnVmWzNdID0gYWRkcjsKPiArCj4gKwlkZXZfZGJnKCZzZGV2LT5kZXYsICIlczog JWMgJTAyeCAlMDJ4ICUwMnhcbiIsIF9fZnVuY19fLCBidWZbMF0sCj4gKwkJKHVuc2lnbmVkIGlu dClidWZbMV0sICh1bnNpZ25lZCBpbnQpYnVmWzJdLCAodW5zaWduZWQgaW50KWJ1ZlszXSk7Cj4g Kwlmb3IgKGkgPSAwOyBpIDwgZGF0YV9sZW47IGkrKykgewo+ICsJCWRldl9kYmcoJnNkZXYtPmRl diwgIiVzOiBkYXRhICUwMnhcbiIsIF9fZnVuY19fLCAodW5zaWduZWQgaW50KSgoY29uc3QgdTgq KWRhdGEpW2ldKTsKPiArCX0KPiArCj4gKwlyZXQgPSBzZXJkZXZfZGV2aWNlX3dyaXRlX2J1Zihz ZGV2LCBidWYsIDQpOwo+ICsJaWYgKHJldCA8IDApCj4gKwkJcmV0dXJuIHJldDsKPiArCWlmIChy ZXQgIT0gNCkKPiArCQlyZXR1cm4gLUVJTzsKPiArCj4gKwlpZiAoZGF0YV9sZW4pIHsKPiArCQly ZXQgPSBzZXJkZXZfZGV2aWNlX3dyaXRlX2J1ZihzZGV2LCBkYXRhLCBkYXRhX2xlbik7Cj4gKwkJ aWYgKHJldCA8IDApCj4gKwkJCXJldHVybiByZXQ7Cj4gKwkJaWYgKHJldCAhPSBkYXRhX2xlbikK PiArCQkJcmV0dXJuIC1FSU87Cj4gKwl9Cj4gKwo+ICsJcmV0dXJuIDA7Cj4gK30KPiArCj4gK3N0 YXRpYyBpbnQgcGljb2d3X3JlY3ZfYW5zd2VyKHN0cnVjdCBwaWNvZ3dfZGV2aWNlICpwaWNvZGV2 LAo+ICsJY2hhciAqY21kLCBib29sICphY2ssIHZvaWQgKmJ1ZiwgaW50IGJ1Zl9sZW4sCj4gKwl1 bnNpZ25lZCBsb25nIHRpbWVvdXQpCj4gK3sKPiArCWludCBsZW47Cj4gKwo+ICsJdGltZW91dCA9 IHdhaXRfZm9yX2NvbXBsZXRpb25fdGltZW91dCgmcGljb2Rldi0+YW5zd2VyX2NvbXAsIHRpbWVv dXQpOwo+ICsJaWYgKCF0aW1lb3V0KQo+ICsJCXJldHVybiAtRVRJTUVET1VUOwoKQW5kPyBUaGUg SU8gaXMgc3RpbGwgc2NoZWR1bGVkLiBTaW1wbHkgZXJyb3Jpbmcgb3V0IGlzIHByb2JsZW1hdGlj LgpJZiB5b3Ugc2VlIGEgdGltZW91dCB5b3UgbmVlZCB0byBraWxsIHRoZSBzY2hlZHVsZWQgSU8u Cgo+ICtzdGF0aWMgaW50IHBpY29nd19oYW5kbGVfYW5zd2VyKHN0cnVjdCBwaWNvZ3dfZGV2aWNl ICpwaWNvZGV2KQo+ICt7Cj4gKwlzdHJ1Y3QgZGV2aWNlICpkZXYgPSAmcGljb2Rldi0+c2VyZGV2 LT5kZXY7Cj4gKwl1bnNpZ25lZCBpbnQgZGF0YV9sZW4gPSAoKHUxNilwaWNvZGV2LT5yeF9idWZb MV0gPDwgOCkgfCBwaWNvZGV2LT5yeF9idWZbMl07Cj4gKwlpbnQgY21kX2xlbiA9IDQgKyBkYXRh X2xlbjsKPiArCWludCBpLCByZXQ7Cj4gKwo+ICsJaWYgKHBpY29kZXYtPnJ4X2xlbiA8IDQpCj4g KwkJcmV0dXJuIDA7Cj4gKwo+ICsJaWYgKGNtZF9sZW4gPiBzaXplb2YocGljb2Rldi0+cnhfYnVm KSkgewo+ICsJCWRldl93YXJuKGRldiwgImFuc3dlciB0b28gbG9uZyAoJXUpXG4iLCBkYXRhX2xl bik7Cj4gKwkJcmV0dXJuIDA7Cj4gKwl9Cj4gKwo+ICsJaWYgKHBpY29kZXYtPnJ4X2xlbiA8IGNt ZF9sZW4pIHsKPiArCQlkZXZfZGJnKGRldiwgImdvdCAldSwgbmVlZCAldSBieXRlc1xuIiwgcGlj b2Rldi0+cnhfbGVuLCBjbWRfbGVuKTsKPiArCQlyZXR1cm4gMDsKPiArCX0KPiArCj4gKwlkZXZf ZGJnKGRldiwgIkFuc3dlciAlYyA9JXUgJXMgKCV1KVxuIiwgcGljb2Rldi0+cnhfYnVmWzBdLAo+ ICsJCSh1bnNpZ25lZCBpbnQpcGljb2Rldi0+cnhfYnVmWzNdLAo+ICsJCShwaWNvZGV2LT5yeF9i dWZbM10gPT0gMSkgPyAiT0siIDogIkswIiwKPiArCQlkYXRhX2xlbik7Cj4gKwlmb3IgKGkgPSAw OyBpIDwgZGF0YV9sZW47IGkrKykgewo+ICsJCS8vZGV2X2RiZyhkZXYsICIlczogJTAyeFxuIiwg X19mdW5jX18sICh1bnNpZ25lZCBpbnQpcGljb2Rldi0+cnhfYnVmWzQgKyBpXSk7Cj4gKwl9Cj4g Kwo+ICsJY29tcGxldGUoJnBpY29kZXYtPmFuc3dlcl9jb21wKTsKPiArCXJldCA9IHdhaXRfZm9y X2NvbXBsZXRpb25faW50ZXJydXB0aWJsZV90aW1lb3V0KCZwaWNvZGV2LT5hbnN3ZXJfcmVhZF9j b21wLCBIWiAvIDIpOwoKUHJvYmxlbWF0aWMuIFlvdSBoYXZlIG5vIGlkZWEgd2hlbiB0aGF0IGNv bXBsZXRlKCkgd2lsbCBoYXZlIGFuIGVmZmVjdC4KWW91IGFyZSBvcGVyYXRpbmcgd2l0aCBhbiB1 bmRlZmluZWQgdGltZW91dCBoZXJlLiBUaGVvcmV0aWNhbGx5IGl0CmNvdWxkIGJlIG5lZ2F0aXZl LgoKCVJlZ2FyZHMKCQlPbGl2ZXIK