Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9607081imu; Wed, 5 Dec 2018 07:30:46 -0800 (PST) X-Google-Smtp-Source: AFSGD/VZMXV59tkBoHeKNODn2qOflLSVR9rgq65zkzoYSYYL+rURuE+IF9MnbEDRh6jkbm7VJbBN X-Received: by 2002:a63:d818:: with SMTP id b24mr20406992pgh.174.1544023845959; Wed, 05 Dec 2018 07:30:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544023845; cv=none; d=google.com; s=arc-20160816; b=V01BoikJU/iqz3LSNP8UC+CXHBFmSqLado4mI2glNX4mf7sXXDgSx8uRLi69nqBKqs IUF3H3o7KP3Q5SGSaqnUDtbvr6iweImoiIjFJ8B7No0lG7HAJNdPx8wsqF3WEL9vnrbR 0Ae8GkDC2xjPOOU31QiePAQeoL2chQWFUISeIGzjUWWeBo62DPvg+4AhQQbvZ21piZEc qpz4T7HTRmMXzsi8BZu5Dz5JhOOb4mnYIipv4Sh5byRbbLbUxT0ceG2uqsSpx2553CLM A76rE/Co13IXWn74yXMpb6j70of4Ce/Uj4MHkWDKDATT73zSK8C5LdKOjYZLWvKBB2Jd zY4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=hqh55ZpQu4kLll1eIkjGjqKf2zcc+i/G0xCQhidr/ds=; b=ToZ1VNU7SAB9Nf3WQRL+2T+lojtPmyYflMUsm5kCumNsnKj3fRa8crLFLj3OcWD1ZZ h7/SNgQ5J18gUDOQ8XSVn5CLEDJhAacxXhKBXgRrTQtOZ6CVBQWu4N7A8xbl/Q+ZYHcQ 27x1dcvwBm2ftRDkZwElK0o4qaTvQPPQcvQN0KtCozEPyOOuHj4Hispk72Aw5VrDPSlr nPZ7Cilc7BhJ3rXGv4mXPiML6TNreVHXFf7MXGUj4L0FmgdPalClziPoOVRQU9vhLxDL 2DG7cJ9IL6M9sXpi/RwS6KJTVQZFPuGn1ua6bIuhEwUYbPT5FjFsV9XRaGjs8ENUyVB5 czQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=GYk6jDYI; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9si19875114plc.40.2018.12.05.07.30.30; Wed, 05 Dec 2018 07:30:45 -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=fail header.i=@gmail.com header.s=20161025 header.b=GYk6jDYI; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727780AbeLEP3x (ORCPT + 99 others); Wed, 5 Dec 2018 10:29:53 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:35358 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727182AbeLEP3x (ORCPT ); Wed, 5 Dec 2018 10:29:53 -0500 Received: by mail-lj1-f196.google.com with SMTP id x85-v6so18724360ljb.2; Wed, 05 Dec 2018 07:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hqh55ZpQu4kLll1eIkjGjqKf2zcc+i/G0xCQhidr/ds=; b=GYk6jDYIR5x4a9/kbzOoQ5CecVYCvkBn0dJef6SlDqJJTeLa4lG7KKjFJJHd7sKh/E mEvnNBDhTPDSlIA58INT5LA34qsSV8LDBwMzW3aNYwJyytwF2qbCJmwhLs3f560vv4d4 plDY1IN3glo7IrfcGnW5WXWMpe3P9FigmGDSY2Avm8XstVInz56yYotsIwwAlNekniYc 7RJfPUF7LrSnGZ680fxkvQ+gOXLRhlq3PnGCXz/K3m9jMJ0/H6PY2UlP9fB4U+52bcoS VCqlkZjD63RoSU+uZBugBR5F/jOJtGDFDgT9MRjs+gninJGW+UD/f1j1pS91Ix1GZYyb rA5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=hqh55ZpQu4kLll1eIkjGjqKf2zcc+i/G0xCQhidr/ds=; b=HynR1cinX0suhiuGfAL3AGt6U8A+3Ku3rrCmMJuGcvRRi1ypDXgMpcjpUEX7dI8vcE HWdw9urY1s58r7+x+a7a0jMMXh2kqYXGTcurTLmUALgNJpoHiou5YeodUR8Ms5oP7CxC 1IY7lFBjer7P3wCHkNTzhjaiNtJp52VFs0CZseUuvFfjw45N7yjrfpw3QBM+Lp67T33m zZHkZNPyPLLHxfrSjIvEQ1hjZ/G+KgmBxr2eTqyXuJaZy5fZmBCJPew1UpQRF3D7SBQ2 brdAZIOaZPbttswDgety07bzE86dqfOVjvUIg8sDY0Zqc4BSK49mSMBtizcutJRGvnKp 8fmA== X-Gm-Message-State: AA+aEWZas/DCNZhqELcVkJ+weYlawtnTa8/WGO8ZOf/8FPWkduKrhbXl QCm3XhT+N09B/RCVAPnappQDGVao X-Received: by 2002:a2e:7317:: with SMTP id o23-v6mr17461684ljc.67.1544023790300; Wed, 05 Dec 2018 07:29:50 -0800 (PST) Received: from xi.terra (c-74bee655.07-184-6d6c6d4.bbcust.telenor.se. [85.230.190.116]) by smtp.gmail.com with ESMTPSA id p19-v6sm3882085ljb.47.2018.12.05.07.29.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 07:29:49 -0800 (PST) Received: from johan by xi.terra with local (Exim 4.91) (envelope-from ) id 1gUZ7Y-0004A7-2c; Wed, 05 Dec 2018 16:29:52 +0100 Date: Wed, 5 Dec 2018 16:29:52 +0100 From: Johan Hovold To: Lars Poeschel Cc: Johan Hovold , devicetree@vger.kernel.org, Samuel Ortiz , open list , "open list:NFC SUBSYSTEM" Subject: Re: [PATCH v4 4/6] nfc: pn533: add UART phy driver Message-ID: <20181205152952.GK15689@localhost> References: <20181101100216.613-1-poeschel@lemonage.de> <20181101100216.613-4-poeschel@lemonage.de> <20181114153517.GB19900@localhost> <20181203142622.GA8057@lem-wkst-02.lemonage> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181203142622.GA8057@lem-wkst-02.lemonage> User-Agent: Mutt/1.11.1 (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 03, 2018 at 03:26:22PM +0100, Lars Poeschel wrote: > On Wed, Nov 14, 2018 at 04:35:17PM +0100, Johan Hovold wrote: > > On Thu, Nov 01, 2018 at 11:02:12AM +0100, Lars Poeschel wrote: > > > This adds the UART phy interface for the pn533 driver. > > > The pn533 driver can be used through UART interface this way. > > > It is implemented as a serdev device. > > > > > > Signed-off-by: Lars Poeschel > > > > Please make sure to include reviewers on CC. > > It's hard to do all things right, about how to correctly email patches, > patch sets and follow ups and send what to whom. > I am still learning. Sorry about that. No problem, I fully understand that. > > > + err = serdev_device_open(serdev); > > > + if (err) { > > > + dev_err(&serdev->dev, "Unable to open device\n"); > > > + goto err_skb; > > > + } > > > + > > > + err = serdev_device_set_baudrate(serdev, 115200); > > > + if (err != 115200) { > > > + err = -EINVAL; > > > + goto err_serdev; > > > + } > > > + > > > + serdev_device_set_flow_control(serdev, false); > > > + pn532->send_wakeup = PN532_SEND_WAKEUP; > > > + timer_setup(&pn532->cmd_timeout, pn532_cmd_timeout, 0); > > > + priv = pn533_register_device(PN533_DEVICE_PN532, > > > + PN533_NO_TYPE_B_PROTOCOLS, > > > + PN533_PROTO_REQ_ACK_RESP, > > > + pn532, &uart_phy_ops, NULL, > > > + &pn532->serdev->dev, > > > + &serdev->dev); > > > + if (IS_ERR(priv)) { > > > + err = PTR_ERR(priv); > > > + goto err_serdev; > > > + } > > > + > > > + pn532->priv = priv; > > > + err = pn533_finalize_setup(pn532->priv); > > > + if (err) > > > + goto err_unregister; > > > + > > > + serdev_device_close(serdev); > > > > This looks broken; what if the NFC interface is brought up before this > > point? You'd get a double open, which is likely to crash things, but > > even if you survive that, the port would not be closed despite the > > interface being up. > > I understand the problem and would like to solve it with a mutex. I will > not have time to work on that until next year. Please be patient. I will > send a new patchset. I'm in no hurry here. :) But I still think doing that setup before registering the device might be preferred if it's possible as you wouldn't need a mutex then. > > Can't you finalise your setup before registering the interface? > > Well, propably I can do that. But I did it the way the other drivers > (usb and i2c) are already doing and reusing the code of the pn533 core > driver. Since their probe works very similar to mine, I suspect them to > have the same problems. Quite possibly. > I can rewrite the probe for my driver, but not for the other two. I can > not test them. > Would you prefer that I rewrite my own _register_device and > _finalize_setup functions, not using the ones from the core driver ? If you add common paths that you can test using your driver I think it should be fine to convert the others unless it ends up being really complicated. Perhaps the authors of those driver can help out with testing too. > Thank you for your very valuable feedback. You're welcome. Johan