Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755594AbdLUVFt (ORCPT ); Thu, 21 Dec 2017 16:05:49 -0500 Received: from mail-by2nam01on0133.outbound.protection.outlook.com ([104.47.34.133]:11232 "EHLO NAM01-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753469AbdLUVFp (ORCPT ); Thu, 21 Dec 2017 16:05:45 -0500 From: Trent Piepho To: "kyle.roeschley@ni.com" , "broonie@kernel.org" CC: "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "geert@linux-m68k.org" Subject: Re: [PATCH] spi: Add a sysfs interface to instantiate devices Thread-Topic: [PATCH] spi: Add a sysfs interface to instantiate devices Thread-Index: AQHTepa/bd9DaJGU50O8hIUqRuj0KKNOSb4A Date: Thu, 21 Dec 2017 21:05:43 +0000 Message-ID: <1513890342.26695.4.camel@impinj.com> References: <20171221200309.17967-1-kyle.roeschley@ni.com> In-Reply-To: <20171221200309.17967-1-kyle.roeschley@ni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tpiepho@impinj.com; x-originating-ip: [216.243.31.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DM5PR06MB2809;6:EDsWdin7soFVK4xrenQRK3tmCz5oG99aA/lk3gjwlZfSr68hUbiJdNmZyswjDjooEn/MMEuw126I9D5/bvXzSvibgtQ4B6rBW4e7lfZiHJ0kNc+dCuZcQceKfROC8KjUAgUAXekgo7QlIR5R16KB5eYOaYuApsJXDn9Jh6hChTXwAZC/Y48DamNYilE4SEZWjevUPX1od9cC+2CydI1vUaZFMc+ZS6hL14j6yKFDKsBrFeg5sho3ZF4QO4R3+QsNyHX0dlKp6B3Q5JdPkGB2HnQvs37j3SsD6ALYFghAu7anSK1MWCxrkjPeZNk4hLCZvdbsUIpR61rzNF4X7CslIK3l1Sm0AGr1q6AQ7YPy2R4=;5:ebyP73ItDHIhU0ln4IE2y/ruLTHqFYREKoc52fe7ZSE82Qn8hZI7j0BTGU0IJL7HJQrpQkMkIXLokEu3nkFjxy3nCpAMGuvUmKWj+a8577cqnxgKvQ9b5vbPv0oNH0Kud+zfHlx+cv/ICTmo7/6M2Wi8NtCLgqgzoOf1vgsqjm0=;24:Vjn7tmkysKz9yuTUXCCdI/fcKGm69Amjx609RZOzkvSCPadQPzj0fM+OKnuLGtEtAqnL2j6ca4FaNsmnZpQdCOf6GEUlvmSdbB2uzyG4ptM=;7:UnSwejadQIgrQWStEwXxJ7taY4iAKmoEdFE/LG820I/PrCPFJmTuHgaoUpdrPlospiWaV2VWvUbRKNe5xO1R1acXzxQOVn+I3/sgGSlatMvOy7A8Pg8W2KsGqW99ot2jGI0459pzx3YiYziTWsY75ZJDrxVFWoxUSlZS62AMpPf7Q/Djpc7cx/AuHXrYCo1jFqwBaQGBrrvzTdPhHTORvEmUMjyLZPMqJ7CpAUoiw0YN8CIOE/NfiJUGxUx2YM0J x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5dd98e9d-b19f-45e5-a1f1-08d548b69948 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008031)(2017052603307)(7153060);SRVR:DM5PR06MB2809; x-ms-traffictypediagnostic: DM5PR06MB2809: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(145744241990776); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231023)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011);SRVR:DM5PR06MB2809;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:DM5PR06MB2809; x-forefront-prvs: 0528942FD8 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(39380400002)(39850400004)(396003)(346002)(366004)(376002)(24454002)(199004)(189003)(377424004)(110136005)(2900100001)(54906003)(3280700002)(36756003)(2501003)(6436002)(5890100001)(77096006)(6512007)(5660300001)(97736004)(4001150100001)(6486002)(99286004)(316002)(103116003)(6116002)(68736007)(76176011)(66066001)(3846002)(229853002)(86362001)(6246003)(14454004)(3660700001)(305945005)(105586002)(2906002)(4326008)(53936002)(478600001)(8676002)(81166006)(7736002)(59450400001)(25786009)(81156014)(8936002)(2950100002)(106356001)(102836004)(6506007);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR06MB2809;H:DM5PR06MB2812.namprd06.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <69D5B49F2A1B254687383E390C43DBBF@namprd06.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: impinj.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5dd98e9d-b19f-45e5-a1f1-08d548b69948 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2017 21:05:43.4308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6de70f0f-7357-4529-a415-d8cbb7e93e5e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2809 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id vBLL5tVT022696 Content-Length: 5876 Lines: 168 On Thu, 2017-12-21 at 14:03 -0600, Kyle Roeschley wrote: > Add a sysfs interface to instantiate and delete SPI devices using the > spidev driver. This can be used when developing a driver on a > self-soldered board which doesn't yet have proper SPI device declaration > at the platform level, and presumably for various debugging situations. > > Inspired by 99cd8e25875a ("i2c: Add a sysfs interface to instantiate > devices"). The i2c interface allows one to specify the type of device to create. Why must this interface be linked to spidev and only capable of creating spidev devices? > > Signed-off-by: Kyle Roeschley > --- > Documentation/spi/spi-summary | 14 ++++++++ > drivers/spi/spi.c | 78 +++++++++++++++++++++++++++++++++++++++++++ > include/linux/spi/spi.h | 3 ++ > 3 files changed, 95 insertions(+) > > diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary > index 1721c1b570c3..51d9747c4426 100644 > --- a/Documentation/spi/spi-summary > +++ b/Documentation/spi/spi-summary > @@ -339,6 +339,20 @@ up the spi bus master, and will likely need spi_new_device() to provide the > board info based on the board that was hotplugged. Of course, you'd later > call at least spi_unregister_device() when that board is removed. > > +Alternatively, a sysfs interface was added to let the user create devices which > +using the spidev driver. This interface is made of 2 attribute files which are > +created in every SPI master directory: new_device and delete_device. Both files > +are write only and you must write the decimal SPI chip select number to them in > +order to properly instantiate or delete a SPI device. As no two devices can be > +attached to the same master with the same chip select line, the chip select > +number is sufficient to uniquely identify the device to be deleted. > + > +Example: > +# echo 1 > /sys/class/spi_master/spi0/new_device > + > +In general, this interface should only be used when in-kernel device > +declaration can't be done. > + > When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those > configurations will also be dynamic. Fortunately, such devices all support > basic device identification probes, so they should hotplug normally. > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > index b33a727a0158..648ccdf359f9 100644 > --- a/drivers/spi/spi.c > +++ b/drivers/spi/spi.c > @@ -242,8 +242,85 @@ static const struct attribute_group spi_controller_statistics_group = { > .attrs = spi_controller_statistics_attrs, > }; > > +static ssize_t > +new_device_store(struct device *dev, struct device_attribute *attr, > + const char *buf, size_t count) > +{ > + struct spi_controller *ctlr = container_of(dev, struct spi_controller, > + dev); > + struct spi_device *spi; > + struct spi_board_info bi = { > + .modalias = "spidev", > + .max_speed_hz = ctlr->max_speed_hz, > + }; > + > + if (kstrtou16(buf, 0, &bi.chip_select) < 0) > + return -EINVAL; > + > + spi = spi_new_device(ctlr, &bi); > + if (!spi) { > + dev_err(dev, "can't create new device\n"); > + return -ENXIO; I2C returns -EINVAL > + } > + > + mutex_lock(&ctlr->bus_lock_mutex); > + list_add_tail(&spi->userspace_device, &ctlr->userspace_devices); > + mutex_unlock(&ctlr->bus_lock_mutex); > + > + dev_info(dev, "created spidev device %s\n", dev_name(&spi->dev)); > + > + return count; > +} > +static DEVICE_ATTR_WO(new_device); > + > +static ssize_t > +delete_device_store(struct device *dev, struct device_attribute *attr, > + const char *buf, size_t count) > +{ > + struct spi_controller *ctlr = container_of(dev, struct spi_controller, > + dev); > + struct spi_device *spi, *next; > + int ret = -ENXIO; > + u16 cs; > + > + if (kstrtou16(buf, 0, &cs) < 0) > + return -EINVAL; > + > + mutex_lock(&ctlr->bus_lock_mutex); > + list_for_each_entry_safe(spi, next, &ctlr->userspace_devices, > + userspace_device) { > + if (spi->chip_select != cs) > + continue; > + > + dev_info(dev, "deleting spidev device %s\n", > + dev_name(&spi->dev)); > + list_del(&spi->userspace_device); > + spi_unregister_device(spi); > + ret = count; > + break; > + } > + mutex_unlock(&ctlr->bus_lock_mutex); > + > + if (ret == -ENXIO) > + dev_err(dev, "can't find spidev device %u in list\n", cs); > + > + return ret; > +} > +static DEVICE_ATTR_WO(delete_device); > + > +static struct attribute *spi_controller_userspace_attrs[] = { > + &dev_attr_new_device.attr, > + &dev_attr_delete_device.attr, > + NULL, > +}; > + > +static const struct attribute_group spi_controller_userspace_group = { > + .attrs = spi_controller_userspace_attrs, > +}; > + > static const struct attribute_group *spi_master_groups[] = { > &spi_controller_statistics_group, > + &spi_controller_userspace_group, > NULL, > }; > > @@ -2129,6 +2206,7 @@ int spi_register_controller(struct spi_controller *ctlr) > return id; > ctlr->bus_num = id; > } > + INIT_LIST_HEAD(&ctlr->userspace_devices); > INIT_LIST_HEAD(&ctlr->queue); > spin_lock_init(&ctlr->queue_lock); > spin_lock_init(&ctlr->bus_lock_spinlock); > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h > index bc6bb325d1bf..f7255745326d 100644 > --- a/include/linux/spi/spi.h > +++ b/include/linux/spi/spi.h > @@ -172,6 +172,8 @@ struct spi_device { > /* the statistics */ > struct spi_statistics statistics; > > + struct list_head userspace_device; > + > /* > * likely need more hooks for more protocol options affecting how > * the controller talks to each chip, like: > @@ -410,6 +412,7 @@ struct spi_controller { > struct device dev; > > struct list_head list; > + struct list_head userspace_devices; > > /* other than negative (== assign one dynamically), bus_num is fully > * board-specific. usually that simplifies to being SOC-specific.