Received: by 10.192.165.148 with SMTP id m20csp540135imm; Wed, 25 Apr 2018 03:58:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx49Ka8Z61qLxw7b6FL1rI3vpZkhDUoFGn8eaisx5BLZeG1cUrvqQa274HQ7Pjtnt69+GyRiY X-Received: by 10.99.177.5 with SMTP id r5mr22617572pgf.186.1524653892620; Wed, 25 Apr 2018 03:58:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524653892; cv=none; d=google.com; s=arc-20160816; b=sHFycBiBrAL90pHYjYFw5em3jLXvfmVrNd63RCddWtRksMmo7PUiRoxdD/vpsQp+mA s/1c7tl2rcZIELIEALWlDLUvEEbtALYT3XIm70OQEGw3GsCEHncYPCZMD7iYGGPx86VF lM4yU+IZkoZwVHt4vzBrw76pVGfRDOXv05fElnnw1GRWEQbkYtIAMJb1ni/KnZZLk+0V PrvN3E1PE6CNXsftyRLdUE6MsP+hUM84NMq1KL9Lq8yhDdnpCORnHOT/iOBkLiHtc7kQ OmMBAHRoB+iQfrvhLKdbgf/6kuz/E5dNeLk93SFSwttoHh/U7CZOLl6ZQ3UooEG33oCB Wxww== 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:arc-authentication-results; bh=zlCddK7os+6KSxbIfngmcdQmuahIiBlJFp/sOxTScXs=; b=sxgGsCndvesog4/a462mLe+RRUHlE4h2oQUr/pQUrOnPl3fQOOXQtGYbl/dWppmezI 0G3PhI9Q0K0gjUmhmpMxgaz19eaa3LWJ1xVRy8zFZshEWMj+wnRDpJmCoVGhqWysNtWE Fg15WgV/vLX70VwatR9lDUAKnCM2IMHzUuLTydq3+NQ0GyyUif8aA0TOkptNlth9mcMr 35CenaUBUXsLQeuuSS30Rjdy/+n0zk7TaxnvdFC0jhGeUfNBFbY3jF0SGUoCs2fYPUoE FMFYlBncr9dDLeMgLLeJA8pyOJV/yEe3H+mG/g9Q7h+6Ly4rlo84vJC1K7fBSIsObEmo lDew== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=CTix02Uq; 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 bg11-v6si16197731plb.171.2018.04.25.03.57.58; Wed, 25 Apr 2018 03:58:12 -0700 (PDT) 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=CTix02Uq; 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 S1754300AbeDYK5B (ORCPT + 99 others); Wed, 25 Apr 2018 06:57:01 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:40186 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753514AbeDYK4z (ORCPT ); Wed, 25 Apr 2018 06:56:55 -0400 Received: by mail-lf0-f65.google.com with SMTP id j16-v6so7553692lfb.7; Wed, 25 Apr 2018 03:56:55 -0700 (PDT) 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=zlCddK7os+6KSxbIfngmcdQmuahIiBlJFp/sOxTScXs=; b=CTix02UqrhXeZEV7QDgFZeu52Ha9+hbpthlce9SK6C56TSBJ39/k4qabl4Xg8nuuvo qJIlkOxNXwXr1cjDNZrUDOJyyqD+FwsV1aPxTqHQ/dHx9NF7OPY2RbebwdZRoCyM84Hy F50AM5iWUixRNl96sqpuABTfT5ou77uz+Az9jaI4mlduaKUtl5WQhe15nBkPtMB1Pe/e smtMj2vlsF3H1cVrtyRB35LORHOlWojbI+ACCtUr26xX2BHXkqTgRCiioMyyd/eKb8vN Udfj40GLKJwewWbNh7yF3CIPnGqSUV7K6rNQrpoVBagIVwDbLy9i6SVAsnNaVOC4//4q loMA== 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=zlCddK7os+6KSxbIfngmcdQmuahIiBlJFp/sOxTScXs=; b=NGT1136VQGutDcrIXmUlzGPop5pTPquidAw4gDbmYGkdRW47oT+Op4GQWZGA7sKSdG a5h1z2DzQP0gCSGNz34WNTAwSB53ldRf9KMy/WmMhzaU42z4H3c+Q4DxnyNLqes6w3R+ rkpBlmQu9KDBYF3wSf8hH28291ICdL12BFEFTNOZtUMlx/SFx/Ua23AUyI3sJXBlNjiX 4EQH4ukKi1L7zBuguSOngbVReeaMGo8PqU6TntklGWuA/T5fGTZ92NEdbXBEVJs6rs83 SZFrPbZCtleHOtdZEwFr/PH8RRwkJxd8y9v7sov6ZWoL4Qh3I5jNRmZhzhpgjjx9UBdg 8Esg== X-Gm-Message-State: ALQs6tBp6n9ItKJey7WzSqI6sVaqGPDOkd/6SDF1wGsSTZ7EO/fz3a3m BcTVDH53jBFl7I/I2BqF3nU= X-Received: by 2002:a19:f106:: with SMTP id p6-v6mr1800169lfh.118.1524653814182; Wed, 25 Apr 2018 03:56:54 -0700 (PDT) Received: from xi.terra (c-8bb2e655.07-184-6d6c6d4.cust.bredbandsbolaget.se. [85.230.178.139]) by smtp.gmail.com with ESMTPSA id e6-v6sm3841873lfg.59.2018.04.25.03.56.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Apr 2018 03:56:53 -0700 (PDT) Received: from johan by xi.terra with local (Exim 4.90_1) (envelope-from ) id 1fBI6P-000055-8N; Wed, 25 Apr 2018 12:56:45 +0200 Date: Wed, 25 Apr 2018 12:56:45 +0200 From: Johan Hovold To: Greg Kroah-Hartman Cc: Johan Hovold , Rob Herring , Mark Rutland , Andreas Kemnade , Arnd Bergmann , "H . Nikolaus Schaller" , Pavel Machek , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH 1/7] gnss: add GNSS receiver subsystem Message-ID: <20180425105645.GP4615@localhost> References: <20180424163458.11947-1-johan@kernel.org> <20180424163458.11947-2-johan@kernel.org> <20180425085649.GB13295@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180425085649.GB13295@kroah.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 25, 2018 at 10:56:49AM +0200, Greg Kroah-Hartman wrote: > On Tue, Apr 24, 2018 at 06:34:52PM +0200, Johan Hovold wrote: > > +#define GNSS_MINORS 16 > > Why only 16? Just have to start somewhere? Yeah, a mostly arbitrarily picked number. I figured only developers would have an interest in having even that many GNSS receivers in one system. But it can be raised, now or later. > > +static int gnss_open(struct inode *inode, struct file *file) > > +{ > > + struct gnss_device *gdev; > > + int ret = 0; > > + > > + gdev = container_of(inode->i_cdev, struct gnss_device, cdev); > > + > > + get_device(&gdev->dev); > > + > > + nonseekable_open(inode, file); > > + file->private_data = gdev; > > + > > + down_write(&gdev->rwsem); > > Just curious, why a rwsem? They can be slower than a normal semaphore, > is this really a contentious lock? I use the rwsem to deal with hotplugging; the underlying device can go away at any time and the core makes sure that no further calls into the corresponding driver is made once all currently executing callbacks return. > > + if (gdev->disconnected) { > > + ret = -ENODEV; > > + goto unlock; > > + } > > + > > + if (gdev->count++ == 0) { > > + ret = gdev->ops->open(gdev); > > + if (ret) > > + gdev->count--; > > Why do we care about the opens here? Do you only want the "child > driver" to have open called once, like a tty driver? Does it matter? Exactly, core deals with the open counts so that the individual gnss drivers need not. Serdev, for example, blows up if you try to open the same device twice. > Again, just curious. > > > + } > > +unlock: > > + up_write(&gdev->rwsem); > > + > > + if (ret) > > + goto err_put_device; > > + > > + return 0; > > + > > +err_put_device: > > + put_device(&gdev->dev); > > + > > + return ret; > > Those last 9 lines can be rewritten as just: > > if (!ret) > put_device(&gdev->dev); > > return ret; Yeah, I usually prefer having an explicit return 0 in the success path and clearly separate the error paths even if it adds few extra lines. This case could become an exception though. > > +static ssize_t gnss_write(struct file *file, const char __user *buf, > > + size_t count, loff_t *pos) > > +{ > > + struct gnss_device *gdev = file->private_data; > > + size_t written = 0; > > + int ret; > > + > > + dev_dbg(&gdev->dev, "%s - count = %zu\n", __func__, count); > > Nit, some of these initial dev_dbg() calls might be able to be removed, > as ftrace should handle the tracing code now, right? Right. The were probably mostly useful to me during development, and can be added back later if it turns out they have any further value. > > +static const struct file_operations gnss_fops = { > > + .owner = THIS_MODULE, > > + .open = gnss_open, > > + .release = gnss_release, > > + .read = gnss_read, > > + .write = gnss_write, > > + .poll = gnss_poll, > > + .llseek = no_llseek, > > +}; > > +struct gnss_device *gnss_allocate_device(struct device *parent) > > +{ > > + struct gnss_device *gdev; > > + struct device *dev; > > + int id; > > + int ret; > > + > > + gdev = kzalloc(sizeof(*gdev), GFP_KERNEL); > > + if (!gdev) > > + return NULL; > > + > > + id = ida_simple_get(&gnss_minors, 0, GNSS_MINORS, GFP_KERNEL); > > + if (id < 0) { > > + kfree(gdev); > > + return ERR_PTR(id); > > + } > > + > > + gdev->id = id; > > + > > + dev = &gdev->dev; > > + device_initialize(dev); > > + dev->devt = gnss_first + id; > > + dev->class = gnss_class; > > + dev->parent = parent; > > + dev->release = gnss_device_release; > > + dev_set_drvdata(dev, gdev); > > + dev_set_name(dev, "gnss%d", id); > > + > > + init_rwsem(&gdev->rwsem); > > + mutex_init(&gdev->read_mutex); > > + mutex_init(&gdev->write_mutex); > > + init_waitqueue_head(&gdev->read_queue); > > + > > + ret = kfifo_alloc(&gdev->read_fifo, GNSS_READ_FIFO_SIZE, GFP_KERNEL); > > + if (ret) > > + goto err_put_device; > > + > > + gdev->write_buf = kzalloc(GNSS_WRITE_BUF_SIZE, GFP_KERNEL); > > + if (!gdev->write_buf) > > + goto err_put_device; > > + > > + cdev_init(&gdev->cdev, &gnss_fops); > > + gdev->cdev.owner = THIS_MODULE; > > This protects this module from being unloaded, but how do you pass on > the module reference counts to the "child" gnss driver? Am I just > missing that logic here somewhere? Due to the hotplug support mentioned above, I do not need to pin the "child" gnss driver modules. Their devices can go away at any time, be it due to hotplugging, driver unbind through sysfs, or module unload. > Anyway, minor things, this looks really clean, nice job. Thanks again! Johan