From: "Winiarska, Iwona" <iwona.winiarska@intel.com> To: "Williams, Dan J" <dan.j.williams@intel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org> Cc: "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>, "mchehab@kernel.org" <mchehab@kernel.org>, "corbet@lwn.net" <corbet@lwn.net>, "x86@kernel.org" <x86@kernel.org>, "pierre-louis.bossart@linux.intel.com" <pierre-louis.bossart@linux.intel.com>, "mingo@redhat.com" <mingo@redhat.com>, "linux@roeck-us.net" <linux@roeck-us.net>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "jdelvare@suse.com" <jdelvare@suse.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "bp@alien8.de" <bp@alien8.de>, "Lutomirski, Andy" <luto@kernel.org>, "tglx@linutronix.de" <tglx@linutronix.de>, "andriy.shevchenko@linux.intel.com" <andriy.shevchenko@linux.intel.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>, "Luck, Tony" <tony.luck@intel.com>, "andrew@aj.id.au" <andrew@aj.id.au>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "yazen.ghannam@amd.com" <yazen.ghannam@amd.com> Subject: Re: [PATCH 08/14] peci: Add device detection Date: Fri, 16 Jul 2021 21:20:08 +0000 [thread overview] Message-ID: <8b452cd32f297083228804f843bfea8ddb124dc0.camel@intel.com> (raw) In-Reply-To: <b8e5bfd209562d64c23631eea6425378c62a762b.camel@intel.com> On Wed, 2021-07-14 at 21:05 +0000, Williams, Dan J wrote: > On Tue, 2021-07-13 at 00:04 +0200, Iwona Winiarska wrote: > > Since PECI devices are discoverable, we can dynamically detect devices > > that are actually available in the system. > > > > This change complements the earlier implementation by rescanning PECI > > bus to detect available devices. For this purpose, it also introduces the > > minimal API for PECI requests. > > > > Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> > > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > > --- > > drivers/peci/Makefile | 2 +- > > drivers/peci/core.c | 13 ++++- > > drivers/peci/device.c | 111 ++++++++++++++++++++++++++++++++++++++++ > > drivers/peci/internal.h | 15 ++++++ > > drivers/peci/request.c | 74 +++++++++++++++++++++++++++ > > drivers/peci/sysfs.c | 34 ++++++++++++ > > 6 files changed, 246 insertions(+), 3 deletions(-) > > create mode 100644 drivers/peci/device.c > > create mode 100644 drivers/peci/request.c > > > > diff --git a/drivers/peci/Makefile b/drivers/peci/Makefile > > index 621a993e306a..917f689e147a 100644 > > --- a/drivers/peci/Makefile > > +++ b/drivers/peci/Makefile > > @@ -1,7 +1,7 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > > > # Core functionality > > -peci-y := core.o sysfs.o > > +peci-y := core.o request.o device.o sysfs.o > > obj-$(CONFIG_PECI) += peci.o > > > > # Hardware specific bus drivers > > diff --git a/drivers/peci/core.c b/drivers/peci/core.c > > index 0ad00110459d..ae7a9572cdf3 100644 > > --- a/drivers/peci/core.c > > +++ b/drivers/peci/core.c > > @@ -31,7 +31,15 @@ struct device_type peci_controller_type = { > > > > int peci_controller_scan_devices(struct peci_controller *controller) > > { > > - /* Just a stub, no support for actual devices yet */ > > + int ret; > > + u8 addr; > > + > > + for (addr = PECI_BASE_ADDR; addr < PECI_BASE_ADDR + PECI_DEVICE_NUM_MAX; addr++) { > > + ret = peci_device_create(controller, addr); > > + if (ret) > > + return ret; > > + } > > + > > This seems to be a behavior triggered at peci_controller_add and at the > request of userspace when touching the rescan attribute? A natural way > to handle this would be to have a driver for the peci_controller device > and have that driver issue scan at probe time. Otherwise, how does > userspace know when it is time to rescan the bus? > peci_controller_add() is expected to be called during probe() of controller driver (otherwise the driver isn't really a controller driver). > > return 0; > > } > > > > @@ -106,7 +114,8 @@ EXPORT_SYMBOL_NS_GPL(peci_controller_add, PECI); > > > > static int _unregister(struct device *dev, void *dummy) > > { > > - /* Just a stub, no support for actual devices yet */ > > + peci_device_destroy(to_peci_device(dev)); > > As mentioned previously, this could be delegated to devm to unregister > when the original driver that added the controller goes through - > > remove(). > Ack. > > + > > return 0; > > } > > > > diff --git a/drivers/peci/device.c b/drivers/peci/device.c > > new file mode 100644 > > index 000000000000..1124862211e2 > > --- /dev/null > > +++ b/drivers/peci/device.c > > @@ -0,0 +1,111 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +// Copyright (c) 2018-2021 Intel Corporation > > + > > +#include <linux/peci.h> > > +#include <linux/slab.h> > > + > > +#include "internal.h" > > + > > +static int peci_detect(struct peci_controller *controller, u8 addr) > > +{ > > + struct peci_request *req; > > + int ret; > > + > > + req = peci_request_alloc(NULL, 0, 0); > > + if (!req) > > + return -ENOMEM; > > + > > + mutex_lock(&controller->bus_lock); > > What is the underlying requirement to prevent 2 simultaneous ->xfer() > invocations? > It's PECI wire (physical layer) interface limitation. > > + ret = controller->xfer(controller, addr, req); > > + mutex_unlock(&controller->bus_lock); > > + > > + peci_request_free(req); > > + > > + return ret; > > +} > > + > > +static bool peci_addr_valid(u8 addr) > > +{ > > + return addr >= PECI_BASE_ADDR && addr < PECI_BASE_ADDR + PECI_DEVICE_NUM_MAX; > > +} > > + > > +static int peci_dev_exists(struct device *dev, void *data) > > +{ > > + struct peci_device *device = to_peci_device(dev); > > + u8 *addr = data; > > + > > + if (device->addr == *addr) > > + return -EBUSY; > > + > > + return 0; > > +} > > + > > +int peci_device_create(struct peci_controller *controller, u8 addr) > > +{ > > + struct peci_device *device; > > + int ret; > > + > > + if (WARN_ON(!peci_addr_valid(addr))) > > + return -EINVAL; > > + > > + /* Check if we have already detected this device before. */ > > + ret = device_for_each_child(&controller->dev, &addr, peci_dev_exists); > > + if (ret) > > + return 0; > > + > > + ret = peci_detect(controller, addr); > > + if (ret) { > > + /* > > + * Device not present or host state doesn't allow successful > > + * detection at this time. > > + */ > > + if (ret == -EIO || ret == -ETIMEDOUT) > > + return 0; > > + > > + return ret; > > + } > > + > > + device = kzalloc(sizeof(*device), GFP_KERNEL); > > + if (!device) > > + return -ENOMEM; > > + > > + device->controller = controller; > > + device->addr = addr; > > + device->dev.parent = &device->controller->dev; > > + device->dev.bus = &peci_bus_type; > > + device->dev.type = &peci_device_type; > > + > > + ret = dev_set_name(&device->dev, "%d-%02x", controller->id, device->addr); > > + if (ret) > > + goto err_free; > > + > > + ret = device_register(&device->dev); > > There is a recent movement away from device_register() to an alloc+add > pattern [1]. I.e. have device_initialize() and device_add() steps. With > that you can unify the error exit to be put_device(). > > [1]: https://lore.kernel.org/r/20210712134233.GA141137@ziepe.ca > It's just kfree in this case, but I agree. I'll modify this. > > + if (ret) > > + goto err_put; > > + > > + return 0; > > + > > +err_put: > > + put_device(&device->dev); > > +err_free: > > + kfree(device); > > + > > + return ret; > > +} > > + > > +void peci_device_destroy(struct peci_device *device) > > +{ > > + device_unregister(&device->dev); > > +} > > + > > +static void peci_device_release(struct device *dev) > > +{ > > + struct peci_device *device = to_peci_device(dev); > > + > > + kfree(device); > > +} > > + > > +struct device_type peci_device_type = { > > + .groups = peci_device_groups, > > + .release = peci_device_release, > > +}; > > diff --git a/drivers/peci/internal.h b/drivers/peci/internal.h > > index 80c61bcdfc6b..6b139adaf6b8 100644 > > --- a/drivers/peci/internal.h > > +++ b/drivers/peci/internal.h > > @@ -9,6 +9,21 @@ > > > > struct peci_controller; > > struct attribute_group; > > +struct peci_device; > > +struct peci_request; > > + > > +/* PECI CPU address range 0x30-0x37 */ > > +#define PECI_BASE_ADDR 0x30 > > +#define PECI_DEVICE_NUM_MAX 8 > > + > > +struct peci_request *peci_request_alloc(struct peci_device *device, u8 tx_len, u8 rx_len); > > +void peci_request_free(struct peci_request *req); > > + > > +extern struct device_type peci_device_type; > > +extern const struct attribute_group *peci_device_groups[]; > > + > > +int peci_device_create(struct peci_controller *controller, u8 addr); > > +void peci_device_destroy(struct peci_device *device); > > > > extern struct bus_type peci_bus_type; > > extern const struct attribute_group *peci_bus_groups[]; > > diff --git a/drivers/peci/request.c b/drivers/peci/request.c > > new file mode 100644 > > index 000000000000..78cee51dfae1 > > --- /dev/null > > +++ b/drivers/peci/request.c > > @@ -0,0 +1,74 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +// Copyright (c) 2021 Intel Corporation > > + > > +#include <linux/export.h> > > +#include <linux/peci.h> > > +#include <linux/slab.h> > > +#include <linux/types.h> > > + > > +#include "internal.h" > > + > > +/** > > + * peci_request_alloc() - allocate &struct peci_request with buffers with given lengths > > + * @device: PECI device to which request is going to be sent > > + * @tx_len: requested TX buffer length > > + * @rx_len: requested RX buffer length > > + * > > + * Return: A pointer to a newly allocated &struct peci_request on success or NULL otherwise. > > + */ > > +struct peci_request *peci_request_alloc(struct peci_device *device, u8 tx_len, u8 rx_len) > > +{ > > How big can these lengths be? PECI specification defines tx_len as a single byte, same thing for rx_len. Currently the largest we're using is 24 IIRC. > > > + struct peci_request *req; > > + u8 *tx_buf, *rx_buf; > > + > > + req = kzalloc(sizeof(*req), GFP_KERNEL); > > + if (!req) > > + return NULL; > > + > > + req->device = device; > > + > > + /* > > + * PECI controllers that we are using now don't support DMA, this > > + * should be converted to DMA API once support for controllers that do > > + * allow it is added to avoid an extra copy. > > + */ > > + if (tx_len) { > > + tx_buf = kzalloc(tx_len, GFP_KERNEL); > > + if (!tx_buf) > > + goto err_free_req; > > + > > + req->tx.buf = tx_buf; > > + req->tx.len = tx_len; > > + } > > + > > + if (rx_len) { > > + rx_buf = kzalloc(rx_len, GFP_KERNEL); > > + if (!rx_buf) > > + goto err_free_tx; > > + > > + req->rx.buf = rx_buf; > > + req->rx.len = rx_len; > > + } > > + > > + return req; > > + > > +err_free_tx: > > + kfree(req->tx.buf); > > +err_free_req: > > + kfree(req); > > + > > + return NULL; > > +} > > +EXPORT_SYMBOL_NS_GPL(peci_request_alloc, PECI); > > + > > +/** > > + * peci_request_free() - free peci_request > > + * @req: the PECI request to be freed > > + */ > > +void peci_request_free(struct peci_request *req) > > +{ > > + kfree(req->rx.buf); > > + kfree(req->tx.buf); > > + kfree(req); > > +} > > +EXPORT_SYMBOL_NS_GPL(peci_request_free, PECI); > > diff --git a/drivers/peci/sysfs.c b/drivers/peci/sysfs.c > > index 36c5e2a18a92..db9ef05776e3 100644 > > --- a/drivers/peci/sysfs.c > > +++ b/drivers/peci/sysfs.c > > @@ -1,6 +1,8 @@ > > // SPDX-License-Identifier: GPL-2.0-only > > // Copyright (c) 2021 Intel Corporation > > > > +#include <linux/device.h> > > +#include <linux/kernel.h> > > #include <linux/peci.h> > > > > #include "internal.h" > > @@ -46,3 +48,35 @@ const struct attribute_group *peci_bus_groups[] = { > > &peci_bus_group, > > NULL > > }; > > + > > +static ssize_t remove_store(struct device *dev, struct device_attribute *attr, > > + const char *buf, size_t count) > > +{ > > + struct peci_device *device = to_peci_device(dev); > > + bool res; > > + int ret; > > + > > + ret = kstrtobool(buf, &res); > > + if (ret) > > + return ret; > > + > > + if (res && device_remove_file_self(dev, attr)) > > + peci_device_destroy(device); > > + > > + return count; > > +} > > +static DEVICE_ATTR_IGNORE_LOCKDEP(remove, 0200, NULL, remove_store); > > Why does userspace need the ability to kick devices off the bus? > > Do you have an example userspace tool that is using these sysfs APIs? Symmetry with adding devices (in this case rescan) - it's also useful for development and testing (e.g. kick off extra devices to leave a single one). Moreover, it looks like common pattern in other subsystems. Thank you -Iwona > > > + > > +static struct attribute *peci_device_attrs[] = { > > + &dev_attr_remove.attr, > > + NULL > > +}; > > + > > +static const struct attribute_group peci_device_group = { > > + .attrs = peci_device_attrs, > > +}; > > + > > +const struct attribute_group *peci_device_groups[] = { > > + &peci_device_group, > > + NULL > > +}; >
next prev parent reply other threads:[~2021-07-16 21:21 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-12 22:04 [PATCH 00/14] Introduce PECI subsystem Iwona Winiarska 2021-07-12 22:04 ` [PATCH 01/14] x86/cpu: Move intel-family to arch-independent headers Iwona Winiarska 2021-07-14 16:54 ` Williams, Dan J 2021-07-15 16:47 ` Winiarska, Iwona 2021-07-15 18:13 ` Dan Williams 2021-07-15 18:29 ` Luck, Tony 2021-07-12 22:04 ` [PATCH 02/14] x86/cpu: Extract cpuid helpers to arch-independent Iwona Winiarska 2021-07-14 16:58 ` Williams, Dan J 2021-07-15 16:51 ` Winiarska, Iwona 2021-07-15 16:58 ` Winiarska, Iwona 2021-07-12 22:04 ` [PATCH 03/14] dt-bindings: Add generic bindings for PECI Iwona Winiarska 2021-07-12 22:04 ` [PATCH 04/14] dt-bindings: Add bindings for peci-aspeed Iwona Winiarska 2021-07-15 16:28 ` Rob Herring 2021-07-16 21:22 ` Winiarska, Iwona 2021-07-12 22:04 ` [PATCH 05/14] ARM: dts: aspeed: Add PECI controller nodes Iwona Winiarska 2021-07-12 22:04 ` [PATCH 06/14] peci: Add core infrastructure Iwona Winiarska 2021-07-14 17:19 ` Williams, Dan J 2021-07-16 21:08 ` Winiarska, Iwona 2021-07-16 21:50 ` Dan Williams 2021-07-17 6:12 ` gregkh 2021-07-17 20:54 ` Dan Williams 2021-07-12 22:04 ` [PATCH 07/14] peci: Add peci-aspeed controller driver Iwona Winiarska 2021-07-13 5:02 ` Randy Dunlap 2021-07-15 16:42 ` Winiarska, Iwona 2021-07-14 17:39 ` Williams, Dan J 2021-07-16 21:17 ` Winiarska, Iwona 2021-07-27 8:49 ` Zev Weiss 2021-07-29 14:03 ` Winiarska, Iwona 2021-07-29 18:15 ` Zev Weiss 2021-07-12 22:04 ` [PATCH 08/14] peci: Add device detection Iwona Winiarska 2021-07-14 21:05 ` Williams, Dan J 2021-07-16 21:20 ` Winiarska, Iwona [this message] 2021-07-27 17:49 ` Zev Weiss 2021-07-29 18:55 ` Winiarska, Iwona 2021-07-29 20:50 ` Zev Weiss 2021-07-30 20:10 ` Winiarska, Iwona 2021-07-12 22:04 ` [PATCH 09/14] peci: Add support for PECI device drivers Iwona Winiarska 2021-07-27 20:10 ` Zev Weiss 2021-07-27 21:23 ` Guenter Roeck 2021-07-29 21:17 ` Winiarska, Iwona 2021-07-29 23:22 ` Zev Weiss 2021-07-30 20:13 ` Winiarska, Iwona 2021-07-12 22:04 ` [PATCH 10/14] peci: Add peci-cpu driver Iwona Winiarska 2021-07-27 11:16 ` David Müller (ELSOFT AG) 2021-07-30 20:14 ` Winiarska, Iwona 2021-07-27 21:33 ` Zev Weiss 2021-07-30 21:21 ` Winiarska, Iwona 2021-07-12 22:04 ` [PATCH 11/14] hwmon: peci: Add cputemp driver Iwona Winiarska 2021-07-15 17:45 ` Guenter Roeck 2021-07-19 20:12 ` Winiarska, Iwona 2021-07-19 20:35 ` Guenter Roeck 2021-07-27 7:06 ` Zev Weiss 2021-07-30 21:51 ` Winiarska, Iwona 2021-07-30 22:04 ` Guenter Roeck 2021-07-12 22:04 ` [PATCH 12/14] hwmon: peci: Add dimmtemp driver Iwona Winiarska 2021-07-15 17:56 ` Guenter Roeck 2021-07-19 20:31 ` Winiarska, Iwona 2021-07-19 20:36 ` Guenter Roeck 2021-07-26 22:08 ` Zev Weiss 2021-07-30 22:48 ` Winiarska, Iwona 2021-07-12 22:04 ` [PATCH 13/14] docs: hwmon: Document PECI drivers Iwona Winiarska 2021-07-27 22:58 ` Zev Weiss 2021-07-28 0:49 ` Guenter Roeck 2021-08-02 11:39 ` Winiarska, Iwona 2021-08-02 11:37 ` Winiarska, Iwona 2021-08-04 17:52 ` Zev Weiss 2021-08-04 18:05 ` Guenter Roeck 2021-08-05 21:42 ` Winiarska, Iwona 2021-07-12 22:04 ` [PATCH 14/14] docs: Add PECI documentation Iwona Winiarska 2021-07-14 16:51 ` [PATCH 00/14] Introduce PECI subsystem Williams, Dan J 2021-07-15 17:33 ` Winiarska, Iwona 2021-07-15 19:34 ` Dan Williams
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8b452cd32f297083228804f843bfea8ddb124dc0.camel@intel.com \ --to=iwona.winiarska@intel.com \ --cc=andrew@aj.id.au \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bp@alien8.de \ --cc=corbet@lwn.net \ --cc=dan.j.williams@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=jae.hyun.yoo@linux.intel.com \ --cc=jdelvare@suse.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-aspeed@lists.ozlabs.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-hwmon@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@roeck-us.net \ --cc=luto@kernel.org \ --cc=mchehab@kernel.org \ --cc=mingo@redhat.com \ --cc=openbmc@lists.ozlabs.org \ --cc=pierre-louis.bossart@linux.intel.com \ --cc=robh+dt@kernel.org \ --cc=tglx@linutronix.de \ --cc=tony.luck@intel.com \ --cc=x86@kernel.org \ --cc=yazen.ghannam@amd.com \ --subject='Re: [PATCH 08/14] peci: Add device detection' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).