All of lore.kernel.org
 help / color / mirror / Atom feed
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: "corbet@lwn.net" <corbet@lwn.net>,
	"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
	"Lutomirski, Andy" <luto@kernel.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>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"jdelvare@suse.com" <jdelvare@suse.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"yazen.ghannam@amd.com" <yazen.ghannam@amd.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"joel@jms.id.au" <joel@jms.id.au>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"andriy.shevchenko@linux.intel.com" 
	<andriy.shevchenko@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"pierre-louis.bossart@linux.intel.com" 
	<pierre-louis.bossart@linux.intel.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
> > +};
> 


WARNING: multiple messages have this Message-ID (diff)
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
> > +};
> 


WARNING: multiple messages have this Message-ID (diff)
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: "corbet@lwn.net" <corbet@lwn.net>,
	"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
	"Lutomirski, Andy" <luto@kernel.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>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"jdelvare@suse.com" <jdelvare@suse.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"yazen.ghannam@amd.com" <yazen.ghannam@amd.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"joel@jms.id.au" <joel@jms.id.au>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.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
> > +};
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-16 21:20 UTC|newest]

Thread overview: 215+ 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 ` Iwona Winiarska
2021-07-12 22:04 ` Iwona Winiarska
2021-07-12 22:04 ` [PATCH 01/14] x86/cpu: Move intel-family to arch-independent headers Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-14 16:54   ` Williams, Dan J
2021-07-14 16:54     ` Williams, Dan J
2021-07-14 16:54     ` Williams, Dan J
2021-07-15 16:47     ` Winiarska, Iwona
2021-07-15 16:47       ` Winiarska, Iwona
2021-07-15 16:47       ` Winiarska, Iwona
2021-07-15 18:13       ` Dan Williams
2021-07-15 18:13         ` Dan Williams
2021-07-15 18:13         ` Dan Williams
2021-07-15 18:29         ` Luck, Tony
2021-07-15 18:29           ` Luck, Tony
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-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-14 16:58   ` Williams, Dan J
2021-07-14 16:58     ` Williams, Dan J
2021-07-14 16:58     ` Williams, Dan J
2021-07-15 16:51     ` Winiarska, Iwona
2021-07-15 16:51       ` Winiarska, Iwona
2021-07-15 16:51       ` Winiarska, Iwona
2021-07-15 16:58       ` Winiarska, Iwona
2021-07-15 16:58         ` 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   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04 ` [PATCH 04/14] dt-bindings: Add bindings for peci-aspeed Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-15 16:28   ` Rob Herring
2021-07-15 16:28     ` Rob Herring
2021-07-15 16:28     ` Rob Herring
2021-07-16 21:22     ` Winiarska, Iwona
2021-07-16 21:22       ` Winiarska, Iwona
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   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04 ` [PATCH 06/14] peci: Add core infrastructure Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-14 17:19   ` Williams, Dan J
2021-07-14 17:19     ` Williams, Dan J
2021-07-14 17:19     ` Williams, Dan J
2021-07-16 21:08     ` Winiarska, Iwona
2021-07-16 21:08       ` Winiarska, Iwona
2021-07-16 21:08       ` Winiarska, Iwona
2021-07-16 21:50       ` Dan Williams
2021-07-16 21:50         ` Dan Williams
2021-07-16 21:50         ` Dan Williams
2021-07-17  6:12         ` gregkh
2021-07-17  6:12           ` gregkh
2021-07-17  6:12           ` gregkh
2021-07-17 20:54           ` Dan Williams
2021-07-17 20:54             ` Dan Williams
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-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-13  5:02   ` Randy Dunlap
2021-07-13  5:02     ` Randy Dunlap
2021-07-13  5:02     ` Randy Dunlap
2021-07-15 16:42     ` Winiarska, Iwona
2021-07-15 16:42       ` Winiarska, Iwona
2021-07-15 16:42       ` Winiarska, Iwona
2021-07-14 17:39   ` Williams, Dan J
2021-07-14 17:39     ` Williams, Dan J
2021-07-14 17:39     ` Williams, Dan J
2021-07-16 21:17     ` Winiarska, Iwona
2021-07-16 21:17       ` Winiarska, Iwona
2021-07-16 21:17       ` Winiarska, Iwona
2021-07-27  8:49   ` Zev Weiss
2021-07-27  8:49     ` Zev Weiss
2021-07-27  8:49     ` Zev Weiss
2021-07-29 14:03     ` Winiarska, Iwona
2021-07-29 14:03       ` Winiarska, Iwona
2021-07-29 14:03       ` Winiarska, Iwona
2021-07-29 18:15       ` Zev Weiss
2021-07-29 18:15         ` Zev Weiss
2021-07-29 18:15         ` Zev Weiss
2021-07-12 22:04 ` [PATCH 08/14] peci: Add device detection Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-14 21:05   ` Williams, Dan J
2021-07-14 21:05     ` Williams, Dan J
2021-07-14 21:05     ` Williams, Dan J
2021-07-16 21:20     ` Winiarska, Iwona [this message]
2021-07-16 21:20       ` Winiarska, Iwona
2021-07-16 21:20       ` Winiarska, Iwona
2021-07-27 17:49   ` Zev Weiss
2021-07-27 17:49     ` Zev Weiss
2021-07-27 17:49     ` Zev Weiss
2021-07-29 18:55     ` Winiarska, Iwona
2021-07-29 18:55       ` Winiarska, Iwona
2021-07-29 18:55       ` Winiarska, Iwona
2021-07-29 20:50       ` Zev Weiss
2021-07-29 20:50         ` Zev Weiss
2021-07-29 20:50         ` Zev Weiss
2021-07-30 20:10         ` Winiarska, Iwona
2021-07-30 20:10           ` Winiarska, Iwona
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-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-27 20:10   ` Zev Weiss
2021-07-27 20:10     ` Zev Weiss
2021-07-27 20:10     ` Zev Weiss
2021-07-27 21:23     ` Guenter Roeck
2021-07-27 21:23       ` Guenter Roeck
2021-07-27 21:23       ` Guenter Roeck
2021-07-29 21:17     ` Winiarska, Iwona
2021-07-29 21:17       ` Winiarska, Iwona
2021-07-29 21:17       ` Winiarska, Iwona
2021-07-29 23:22       ` Zev Weiss
2021-07-29 23:22         ` Zev Weiss
2021-07-29 23:22         ` Zev Weiss
2021-07-30 20:13         ` Winiarska, Iwona
2021-07-30 20:13           ` Winiarska, Iwona
2021-07-30 20:13           ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 10/14] peci: Add peci-cpu driver Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-27 11:16   ` David Müller (ELSOFT AG)
2021-07-27 11:16     ` David Müller (ELSOFT AG)
2021-07-30 20:14     ` Winiarska, Iwona
2021-07-30 20:14       ` Winiarska, Iwona
2021-07-30 20:14       ` Winiarska, Iwona
2021-07-27 21:33   ` Zev Weiss
2021-07-27 21:33     ` Zev Weiss
2021-07-27 21:33     ` Zev Weiss
2021-07-30 21:21     ` Winiarska, Iwona
2021-07-30 21:21       ` Winiarska, Iwona
2021-07-30 21:21       ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 11/14] hwmon: peci: Add cputemp driver Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-15 17:45   ` Guenter Roeck
2021-07-15 17:45     ` Guenter Roeck
2021-07-15 17:45     ` Guenter Roeck
2021-07-19 20:12     ` Winiarska, Iwona
2021-07-19 20:12       ` Winiarska, Iwona
2021-07-19 20:12       ` Winiarska, Iwona
2021-07-19 20:35       ` Guenter Roeck
2021-07-19 20:35         ` Guenter Roeck
2021-07-19 20:35         ` Guenter Roeck
2021-07-27  7:06   ` Zev Weiss
2021-07-27  7:06     ` Zev Weiss
2021-07-27  7:06     ` Zev Weiss
2021-07-30 21:51     ` Winiarska, Iwona
2021-07-30 21:51       ` Winiarska, Iwona
2021-07-30 21:51       ` Winiarska, Iwona
2021-07-30 22:04       ` Guenter Roeck
2021-07-30 22:04         ` Guenter Roeck
2021-07-30 22:04         ` Guenter Roeck
2021-07-12 22:04 ` [PATCH 12/14] hwmon: peci: Add dimmtemp driver Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-15 17:56   ` Guenter Roeck
2021-07-15 17:56     ` Guenter Roeck
2021-07-15 17:56     ` Guenter Roeck
2021-07-19 20:31     ` Winiarska, Iwona
2021-07-19 20:31       ` Winiarska, Iwona
2021-07-19 20:31       ` Winiarska, Iwona
2021-07-19 20:36       ` Guenter Roeck
2021-07-19 20:36         ` Guenter Roeck
2021-07-19 20:36         ` Guenter Roeck
2021-07-26 22:08   ` Zev Weiss
2021-07-26 22:08     ` Zev Weiss
2021-07-26 22:08     ` Zev Weiss
2021-07-30 22:48     ` Winiarska, Iwona
2021-07-30 22:48       ` Winiarska, Iwona
2021-07-30 22:48       ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 13/14] docs: hwmon: Document PECI drivers Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-27 22:58   ` Zev Weiss
2021-07-27 22:58     ` Zev Weiss
2021-07-27 22:58     ` Zev Weiss
2021-07-28  0:49     ` Guenter Roeck
2021-07-28  0:49       ` Guenter Roeck
2021-07-28  0:49       ` Guenter Roeck
2021-08-02 11:39       ` Winiarska, Iwona
2021-08-02 11:39         ` Winiarska, Iwona
2021-08-02 11:39         ` Winiarska, Iwona
2021-08-02 11:37     ` Winiarska, Iwona
2021-08-02 11:37       ` Winiarska, Iwona
2021-08-02 11:37       ` Winiarska, Iwona
2021-08-04 17:52       ` Zev Weiss
2021-08-04 17:52         ` Zev Weiss
2021-08-04 17:52         ` Zev Weiss
2021-08-04 18:05         ` Guenter Roeck
2021-08-04 18:05           ` Guenter Roeck
2021-08-04 18:05           ` Guenter Roeck
2021-08-05 21:42           ` Winiarska, Iwona
2021-08-05 21:42             ` Winiarska, Iwona
2021-08-05 21:42             ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 14/14] docs: Add PECI documentation Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-12 22:04   ` Iwona Winiarska
2021-07-14 16:51 ` [PATCH 00/14] Introduce PECI subsystem Williams, Dan J
2021-07-14 16:51   ` Williams, Dan J
2021-07-14 16:51   ` Williams, Dan J
2021-07-15 17:33   ` Winiarska, Iwona
2021-07-15 17:33     ` Winiarska, Iwona
2021-07-15 17:33     ` Winiarska, Iwona
2021-07-15 19:34     ` Dan Williams
2021-07-15 19:34       ` Dan Williams
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=joel@jms.id.au \
    --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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.