From patchwork Wed Mar 3 23:27:50 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Cameron X-Patchwork-Id: 46879 Return-Path: <3efCOSwUJCUQpoi89igs.gi.0qxzi-rot03muumrkmxu0vy.ius@groups.bounces.google.com> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from mail-vw0-f56.google.com (mail-vw0-f56.google.com [209.85.212.56]) by ozlabs.org (Postfix) with ESMTP id 40429B7CCD for ; Thu, 4 Mar 2010 10:27:55 +1100 (EST) Received: by vws18 with SMTP id 18sf515402vws.11 for ; Wed, 03 Mar 2010 15:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:x-cam-antivirus:x-cam-spamdetails :x-cam-scannerinfo:received:received:received:date:from:to:cc :subject:message-id:in-reply-to:references:x-mailer:mime-version :sender:x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :x-thread-url:x-message-url:list-subscribe:list-unsubscribe :content-type; bh=G9bGQ6rC8Z6JH5mJ76gg+Ne9Ofenp+jxe/RcYromzLA=; b=v4/m2Mg2A0YsGPxWEnCi1qQzGr+NAtWuPaCI4n2uXVmPR8I8FLf38hYhitcWaBrmiw CFzrqByIYmrRxr2oRukCpumF9UePKHTLF+haTZ14AtPnUVuf+7tzb4tCKeQ76oeuYaLL yS7rIuq/4Ghaz+msEHauIlwQtVuCzXQD+DNxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:x-cam-antivirus:x-cam-spamdetails :x-cam-scannerinfo:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:sender :x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :x-thread-url:x-message-url:list-subscribe:list-unsubscribe :content-type; b=bNXtTjxElw1ZV/mKaVPbSeWDGyOGC5E6LZ83CnoyAhS4Fi6/7fjIUb3YNUlm/OK0dB 6S3pvS8v/blysJEPFQH31XXeZAixEuwh1aS0Y9aAa9JTcumGlMxP+6hw/LOp7/cF8IQ2 hqEcH/TNbfP+XqLkHZhmN06OVlnzAJH9C52MU= Received: by 10.220.123.215 with SMTP id q23mr165305vcr.59.1267658873505; Wed, 03 Mar 2010 15:27:53 -0800 (PST) X-BeenThere: rtc-linux@googlegroups.com Received: by 10.220.87.136 with SMTP id w8ls271842vcl.0.p; Wed, 03 Mar 2010 15:27:52 -0800 (PST) Received: by 10.220.66.101 with SMTP id m37mr737054vci.3.1267658872100; Wed, 03 Mar 2010 15:27:52 -0800 (PST) Received: by 10.220.66.101 with SMTP id m37mr737053vci.3.1267658871970; Wed, 03 Mar 2010 15:27:51 -0800 (PST) Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by gmr-mx.google.com with ESMTP id 40si5687669vws.2.2010.03.03.15.27.51; Wed, 03 Mar 2010 15:27:51 -0800 (PST) Received-SPF: pass (google.com: domain of jic23@hermes.cam.ac.uk designates 131.111.8.137 as permitted sender) client-ip=131.111.8.137; X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53368) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:jic23) id 1Nmxyo-0005yr-PX (Exim 4.70) (return-path ); Wed, 03 Mar 2010 23:27:50 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:jic23) id 1Nmxyo-0006xN-T0 (Exim 4.67) (return-path ); Wed, 03 Mar 2010 23:27:50 +0000 Received: from [86.136.144.105] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.2); 03 Mar 2010 23:27:50 +0000 Date: 03 Mar 2010 23:27:50 +0000 From: "J.I. Cameron" To: Alessandro Zummo Cc: rtc-linux@googlegroups.com, Robert Jarzmik , Richard Purdie , Ben Dooks Subject: Re: [rtc-linux] Re: rtc-pxa: why are irq's only requested in the open call()? Message-ID: In-Reply-To: <20100303150813.3512a98e@linux.lan.towertech.it> References: <4B8D501B.9010607@cam.ac.uk> <4B8E6C0C.7000101@cam.ac.uk> <20100303150813.3512a98e@linux.lan.towertech.it> X-Mailer: Prayer v1.3.2 Mime-Version: 1.0 Sender: rtc-linux@googlegroups.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jic23@hermes.cam.ac.uk designates 131.111.8.137 as permitted sender) smtp.mail=jic23@hermes.cam.ac.uk X-Original-Sender: jonathan.cameron@gmail.com Reply-To: rtc-linux@googlegroups.com Precedence: list Mailing-list: list rtc-linux@googlegroups.com; contact rtc-linux+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: X-Thread-Url: http://groups.google.com/group/rtc-linux/t/e6e12052fabfc2b7 X-Message-Url: http://groups.google.com/group/rtc-linux/msg/e7b402e58bba5aa4 List-Subscribe: , List-Unsubscribe: , On Mar 3 2010, Alessandro Zummo wrote: >On Wed, 03 Mar 2010 14:02:52 +0000 >Jonathan Cameron wrote: > >> to ensure that opening inside the kernel has the same effect as >> opening the file or just call the open op directly in rtc_class_open. >> The only driver doing anything other than interrupt requesting in here >> is rtc-m41t80 and I am far from sure what that is doing? > > we might amend rtc_class_open to handle this issue. > patches will be appreciated ;) Hi Alessandro. I am a little confused as to why the code that runs on rtc_class_open is rtc_task *task) if (task == NULL || task->func == NULL) return -EINVAL; - /* Cannot register while the char dev is in use */ - if (test_and_set_bit_lock(RTC_DEV_BUSY, &rtc->flags)) - return -EBUSY; - spin_lock_irq(&rtc->irq_task_lock); if (rtc->irq_task == NULL) { rtc->irq_task = task; @@ -447,8 +464,6 @@ int rtc_irq_register(struct rtc_device *rtc, struct rtc_task *task) } spin_unlock_irq(&rtc->irq_task_lock); - clear_bit_unlock(RTC_DEV_BUSY, &rtc->flags); - return retval; } EXPORT_SYMBOL_GPL(rtc_irq_register); different to that that runs on device open. For in kernel calls, the device is only exclusively taken when adding changing the interrupt. Thus it would I think be possible for multiple user run this function, whilst they all think they have exclusive control. Do we not want to ensure single access to the device whether in kernel or via the userspace interface? To do this I would propose moving if (test_and_set_bit_lock(RTC_DEV_BUSY, &rtc->flags)) return -EBUSY; etc into the rtc_class_open and also to add a call to ops->open here. Clearly we would also need the corresponding clear_bit_lock and ops->release calls in rtc_class_close. Assuming there is no reason that I'm missing behind the inherent differences in kernel and out of kernel, the only complexity I know of is that a lot of drivers define an ops->release. The following certainly seem to work fine with rtc-pxa. Not sure what my webmail will do with the patch... Thanks, Jonathan [PATCH] rtc: Make in kernel interface behave similarly to character device. Signed-off-by: Jonathan Cameron --- drivers/rtc/interface.c | 29 ++++++++++++++++++++++------- 1 files changed, 22 insertions(+), 7 deletions(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index a0c8162..553ca4a 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -406,6 +406,7 @@ struct rtc_device *rtc_class_open(char *name) { struct device *dev; struct rtc_device *rtc = NULL; + int err; dev = class_find_device(rtc_class, NULL, name, __rtc_match); if (dev) @@ -415,15 +416,35 @@ struct rtc_device *rtc_class_open(char *name) if (!try_module_get(rtc->owner)) { put_device(dev); rtc = NULL; + goto exit; + } + /* Cannot use while the char dev is in use */ + if (test_and_set_bit_lock(RTC_DEV_BUSY, &rtc->flags)) { + put_device(dev); + rtc = NULL; + goto exit; + } + err = rtc->ops->open ? rtc->ops->open(rtc->dev.parent) : 0; + if (err != 0) { + clear_bit_unlock(RTC_DEV_BUSY, &rtc->flags); + put_device(dev); + rtc = NULL; + goto exit; } + spin_lock_irq(&rtc->irq_lock); + rtc->irq_data = 0; + spin_unlock_irq(&rtc->irq_lock); } - +exit: return rtc; } EXPORT_SYMBOL_GPL(rtc_class_open); void rtc_class_close(struct rtc_device *rtc) { + if (rtc->ops->release) + rtc->ops->release(rtc->dev.parent); + clear_bit_unlock(RTC_DEV_BUSY, &rtc->flags); module_put(rtc->owner); put_device(&rtc->dev); } @@ -436,10 +457,6 @@ int rtc_irq_register(struct rtc_device *rtc, struct