From patchwork Fri Aug 8 16:34:51 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawel Moll X-Patchwork-Id: 4697201 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 243E0C0338 for ; Fri, 8 Aug 2014 16:37:15 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 480CD20179 for ; Fri, 8 Aug 2014 16:37:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 59B9520160 for ; Fri, 8 Aug 2014 16:37:13 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XFn8a-0006xe-HD; Fri, 08 Aug 2014 16:35:28 +0000 Received: from fw-tnat.austin.arm.com ([217.140.110.23] helo=collaborate-mta1.arm.com) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XFn8Y-00060u-1F for linux-arm-kernel@lists.infradead.org; Fri, 08 Aug 2014 16:35:26 +0000 Received: from [10.2.201.42] (hornet.cambridge.arm.com [10.2.201.42]) by collaborate-mta1.arm.com (Postfix) with ESMTP id E100513F91D; Fri, 8 Aug 2014 11:34:50 -0500 (CDT) Message-ID: <1407515691.31897.26.camel@hornet> Subject: Re: [PATCH 2/5] char: tile-srom: Remove reference to platform_bus From: Pawel Moll To: Chris Metcalf Date: Fri, 08 Aug 2014 17:34:51 +0100 In-Reply-To: <53E139C8.9000502@tilera.com> References: <1406298233-27876-1-git-send-email-pawel.moll@arm.com> <1406298233-27876-2-git-send-email-pawel.moll@arm.com> <53DAA605.2030500@tilera.com> <1406913678.22529.46.camel@hornet> <53E139C8.9000502@tilera.com> X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140808_093526_200191_5A13BEC9 X-CRM114-Status: GOOD ( 25.08 ) X-Spam-Score: -0.7 (/) Cc: "paul@pwsan.com" , Arnd Bergmann , Stephen Warren , Greg Kroah-Hartman , Peter De Schrijver , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , "arm@kernel.org" , Catalin Marinas , Olof Johansson , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, 2014-08-05 at 21:08 +0100, Chris Metcalf wrote: > >> In addition, we also have user binaries > >> in the wild that know to look for /sys/devices/platform/srom/ paths, > >> so I'm pretty reluctant to change this path without good reason. > > So what is the srom class for then if not for device discovery? And why > > do they look for them in the first place? To get relevant character > > device's data, if I understand it right? > > > > Maybe you could just register a simple "proper" platform device for all > > the sroms and then hang the class devices from it? I can type some code > > doing this if it sound reasonably? > > I'm not sure exactly what you mean by device discovery here. > The > subdirectories under /sys/devices/platform/srom/ correspond to partitions > in the SPI-ROM, which are software constructs created by the Tilera hypervisor. > By default we have three, where the first holds boot data that the chip > can use to boot out of hardware, and the other two are smaller partitions > for boot- and user-specific data. We use the /sys files primarily to get the > page size and sector size for the sroms, and also export other interesting > information like the total size of the particular srom device. > > Thank you for volunteering to write a bit of code; if that's the best > way to clarify this for us, fantastic, or else pointing us at existing > good practices or documentation would be great too. I was thinking about something like the following (warning, untested) 8<------------------------------------------- From c53f0a2492d6cd38d1f82d57916a6528b071e8a8 Mon Sep 17 00:00:00 2001 From: Pawel Moll Date: Fri, 8 Aug 2014 16:32:58 +0100 Subject: [PATCH] char: tile-srom: Add real platform bus parent Add a real platform bus device as a parent for the srom class devices, to prevent non-platform devices hanging from the bus root. Signed-off-by: Pawel Moll --- drivers/char/tile-srom.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/char/tile-srom.c b/drivers/char/tile-srom.c index bd37747..7fb0fd5 100644 --- a/drivers/char/tile-srom.c +++ b/drivers/char/tile-srom.c @@ -76,6 +76,7 @@ MODULE_LICENSE("GPL"); static int srom_devs; /* Number of SROM partitions */ static struct cdev srom_cdev; +static struct platform_device *srom_parent; static struct class *srom_class; static struct srom_dev *srom_devices; @@ -350,7 +351,7 @@ static int srom_setup_minor(struct srom_dev *srom, int index) SROM_PAGE_SIZE_OFF, sizeof(srom->page_size)) < 0) return -EIO; - dev = device_create(srom_class, &platform_bus, + dev = device_create(srom_class, srom_parent, MKDEV(srom_major, index), srom, "%d", index); return PTR_ERR_OR_ZERO(dev); } @@ -415,6 +416,13 @@ static int srom_init(void) if (result < 0) goto fail_chrdev; + /* Create a parent device */ + srom_parent = platform_device_register_simple("srom", -1, NULL, 0); + if (IS_ERR(srom_parent)) { + result = PTR_ERR(srom_parent); + goto fail_pdev; + } + /* Create a sysfs class. */ srom_class = class_create(THIS_MODULE, "srom"); if (IS_ERR(srom_class)) { @@ -438,6 +446,8 @@ fail_class: device_destroy(srom_class, MKDEV(srom_major, i)); class_destroy(srom_class); fail_cdev: + platform_device_unregister(srom_parent); +fail_pdev: cdev_del(&srom_cdev); fail_chrdev: unregister_chrdev_region(dev, srom_devs); @@ -454,6 +464,7 @@ static void srom_cleanup(void) device_destroy(srom_class, MKDEV(srom_major, i)); class_destroy(srom_class); cdev_del(&srom_cdev); + platform_device_unregister(srom_parent); unregister_chrdev_region(MKDEV(srom_major, 0), srom_devs); kfree(srom_devices); }