All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brad Larson <blarson@amd.com>
To: <andy.shevchenko@gmail.com>
Cc: <adrian.hunter@intel.com>, <alcooperx@gmail.com>, <arnd@arndb.de>,
	<blarson@amd.com>, <brendan.higgins@linux.dev>,
	<briannorris@chromium.org>, <brijeshkumar.singh@amd.com>,
	<broonie@kernel.org>, <catalin.marinas@arm.com>,
	<davidgow@google.com>, <devicetree@vger.kernel.org>,
	<fancer.lancer@gmail.com>, <gerg@linux-m68k.org>,
	<gsomlo@gmail.com>, <krzk@kernel.org>,
	<krzysztof.kozlowski+dt@linaro.org>, <lee.jones@linaro.org>,
	<lee@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-mmc@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <p.yadav@ti.com>,
	<p.zabel@pengutronix.de>, <piotrs@cadence.com>,
	<rdunlap@infradead.org>, <robh+dt@kernel.org>,
	<samuel@sholland.org>, <skhan@linuxfoundation.org>,
	<suravee.suthikulpanit@amd.com>, <thomas.lendacky@amd.com>,
	<tonyhuang.sunplus@gmail.com>, <ulf.hansson@linaro.org>,
	<vaishnav.a@ti.com>, <will@kernel.org>,
	<yamada.masahiro@socionext.com>
Subject: Re: [PATCH v12 15/15] soc: amd: Add support for AMD Pensando SoC Controller
Date: Fri, 31 Mar 2023 15:26:41 -0700	[thread overview]
Message-ID: <20230331222641.38009-1-blarson@amd.com> (raw)
In-Reply-To: <CAHp75VcbDBUf2cH_6rRqn5RCGSEOWqE85Yn3gDhYiJPhGf1S=Q@mail.gmail.com>

Hi Andy,

Thanks for the review.

On Thu, Mar 23, 2023 at 13:06 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Thu, Mar 23, 2023 at 2:11 AM Brad Larson <blarson@amd.com> wrote:
>>
>> The Pensando SoC controller is a SPI connected companion device
>> that is present in all Pensando SoC board designs.  The essential
>> board management registers are accessed on chip select 0 with
>> board mgmt IO support accessed using additional chip selects.
>
> ...
>
>> +config AMD_PENSANDO_CTRL
>> +       tristate "AMD Pensando SoC Controller"
>> +       depends on SPI_MASTER=y
>> +       depends on (ARCH_PENSANDO && OF) || COMPILE_TEST
>> +       default y if ARCH_PENSANDO
>
>       default ARCH_PENSANDO

Changed to default ARCH_PENSANDO

>> +       select REGMAP_SPI
>> +       select MFD_SYSCON
>
> ...
>
>> +/*
>> + * AMD Pensando SoC Controller
>> + *
>> + * Userspace interface and reset driver support for SPI connected Pensando SoC
>> + * controller device.  This device is present in all Pensando SoC designs and
>> + * contains board control/status regsiters and management IO support.
>
> registers ?

Fixed the typo

> ...
>
>> +#include <linux/cdev.h>
>> +#include <linux/delay.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/fs.h>
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>
> Seems semi-random. Are you sure you use this and not missing mod_devicetable.h?

Added mod_devicetable.h.
Removed delay.h, fs.h and of_device.h

>> +#include <linux/reset-controller.h>
>> +#include <linux/spi/spi.h>
>
>...
>
>> +struct penctrl_device {
>> +       struct spi_device *spi_dev;
>> +       struct reset_controller_dev rcdev;
>
> Perhaps swapping these two might provide a better code generation.

Its a 96 byte struct with pointer followed by the reset controller.
The spi_device variable is accessed frequently and rcdev during
boot and ideally never again so if rcdev is mostly missing from
cache that is fine.  Likely the address of spi_dev is also in 
cache given it is periodically accessed.

> ...
>
>> +       struct spi_transfer t[2] = { 0 };
>
> 0 is not needed.

Dropped the 0.

> ...
>
>> +       if (_IOC_DIR(cmd) & _IOC_READ)
>> +               ret = !access_ok((void __user *)arg, _IOC_SIZE(cmd));
>> +       else if (_IOC_DIR(cmd) & _IOC_WRITE)
>> +               ret = !access_ok((void __user *)arg, _IOC_SIZE(cmd));
>
>
> Maybe you should create a temporary variable as
>
>    void __user *in = ... arg;

Yes, created temp variable.

>
>> +       if (ret)
>> +               return -EFAULT;
>
> ...
>
>> +       /* Verify and prepare spi message */
>
> SPI

Changed to SPI

>> +       size = _IOC_SIZE(cmd);
>> +       if ((size % sizeof(struct penctrl_spi_xfer)) != 0) {
>
> ' != 0' is redundant.

Fixed

>
>> +               ret = -EINVAL;
>> +               goto done;
>> +       }
>> +       num_msgs = size / sizeof(struct penctrl_spi_xfer);
>
>> +       if (num_msgs == 0) {
>> +               ret = -EINVAL;
>> +               goto done;
>> +       }
>
> Can be unified with a previous check as
>
> if (size == 0 || size % ...)

Yes, made this change.

>> +       msg = memdup_user((struct penctrl_spi_xfer __user *)arg, size);
>> +       if (!msg) {
>> +               ret = PTR_ERR(msg);
>> +               goto done;
>> +       }
>
>...
>
>> +       if (copy_from_user((void *)(uintptr_t)tx_buf,
>> +                          (void __user *)msg->tx_buf, msg->len)) {
>
> Why are all these castings here?

Yes, overkill, changed to:

        if (copy_from_user(tx_buf, (void __user *)msg->tx_buf, msg->len)) {

> ...
>
>> +       if (copy_to_user((void __user *)msg->rx_buf,
>> +                        (void *)(uintptr_t)rx_buf, msg->len))
>> +               ret = -EFAULT;
>
> Ditto.

Changed to:

        if (copy_to_user((void __user *)msg->rx_buf, rx_buf, msg->len))

> ...
>
>> +       struct spi_transfer t[2] = { 0 };
>
> 0 is redundant.

Dropped the 0.

> ...
>
>> +       struct spi_transfer t[1] = { 0 };
>
> Ditto.

Dropped the 0.

> Why is this an array?

Fixed, it's a single message and shouldn't be an array.

> ...
>
>> +       ret = spi_sync(spi_dev, &m);
>> +       return ret;
>
> return spi_sync(...);

Fixed.

> ...
>
>> +       np = spi_dev->dev.parent->of_node;
>> +       ret = of_property_read_u32(np, "num-cs", &num_cs);
>
> Why not simply device_property_read_u32()?

It can be and removed two lines with below result. Also changed the
variable spi_dev to spi which is the more common usage.

        ret = device_property_read_u32(spi->dev.parent, "num-cs", &num_cs);
        if (ret)
                return dev_err_probe(&spi->dev, ret,
                                     "number of chip-selects not defined\n");

> ...
>
>> +       cdev = cdev_alloc();
>> +       if (!cdev) {
>> +               dev_err(&spi_dev->dev, "allocation of cdev failed");
>> +               ret = -ENOMEM;
>
> ret = dev_err_probe(...);

Fixed.

>> +               goto cdev_failed;
>> +       }
>
> ...
>
>> +       ret = cdev_add(cdev, penctrl_devt, num_cs);
>> +       if (ret) {
>
>> +               dev_err(&spi_dev->dev, "register of cdev failed");
>
> dev_err_probe() ?

Fixed.

>> +               goto cdev_delete;
>> +       }
>
> ...
>
>> +       penctrl = kzalloc(sizeof(*penctrl), GFP_KERNEL);
>> +       if (!penctrl) {
>
>> +               ret = -ENOMEM;
>> +               dev_err(&spi_dev->dev, "allocate driver data failed");
>
> ret = dev_err_probe();
> But we do not print memory allocation failure messages.

Fixed this way

        penctrl = kzalloc(sizeof(*penctrl), GFP_KERNEL);
        if (!penctrl) {
                ret = -ENOMEM;
                goto free_cdev;
        }

> ...
>
>> +               if (IS_ERR(dev)) {
>> +                       ret = IS_ERR(dev);
>> +                       dev_err(&spi_dev->dev, "error creating device\n");
>
> ret = dev_err_probe();

Fixed.

> ...
>
> +       spi_set_drvdata(spi_dev, penctrl);
>
> Is it in use?

Not used and now dropped.

> ...
>
>> +       penctrl->rcdev.of_node = spi_dev->dev.of_node;
>
> device_set_node();

Added: device_set_node(&spi->dev, dev_fwnode(dev));

> ...
>
>> +       ret = reset_controller_register(&penctrl->rcdev);
>> +       if (ret)
>> +               return dev_err_probe(&spi_dev->dev, ret,
>> +                                    "failed to register reset controller\n");
>> +       return ret;
>
> return 0;

Yes, changed.

> ...
>
>> +       device_destroy(penctrl_class, penctrl_devt);
>
> Are you sure this is the correct API?

Yes, however a probe error could call up to 5 APIs to clean up which resulted
in this update:

destroy_device:
        for (cs = 0; cs < num_cs; cs++)
                device_destroy(penctrl_class, MKDEV(MAJOR(penctrl_devt), cs));
        kfree(penctrl);
free_cdev:
        cdev_del(cdev);
destroy_class:
        class_destroy(penctrl_class);
unregister_chrdev:
        unregister_chrdev(MAJOR(penctrl_devt), "penctrl");

        return ret;

> ...
>
>> +#include <linux/types.h>
>> +#include <linux/ioctl.h>
>
> Sorted?

Swapped these

Regards,
Brad

WARNING: multiple messages have this Message-ID (diff)
From: Brad Larson <blarson@amd.com>
To: <andy.shevchenko@gmail.com>
Cc: <adrian.hunter@intel.com>, <alcooperx@gmail.com>, <arnd@arndb.de>,
	<blarson@amd.com>, <brendan.higgins@linux.dev>,
	<briannorris@chromium.org>, <brijeshkumar.singh@amd.com>,
	<broonie@kernel.org>, <catalin.marinas@arm.com>,
	<davidgow@google.com>, <devicetree@vger.kernel.org>,
	<fancer.lancer@gmail.com>, <gerg@linux-m68k.org>,
	<gsomlo@gmail.com>, <krzk@kernel.org>,
	<krzysztof.kozlowski+dt@linaro.org>, <lee.jones@linaro.org>,
	<lee@kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-mmc@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <p.yadav@ti.com>,
	<p.zabel@pengutronix.de>, <piotrs@cadence.com>,
	<rdunlap@infradead.org>, <robh+dt@kernel.org>,
	<samuel@sholland.org>, <skhan@linuxfoundation.org>,
	<suravee.suthikulpanit@amd.com>, <thomas.lendacky@amd.com>,
	<tonyhuang.sunplus@gmail.com>, <ulf.hansson@linaro.org>,
	<vaishnav.a@ti.com>, <will@kernel.org>,
	<yamada.masahiro@socionext.com>
Subject: Re: [PATCH v12 15/15] soc: amd: Add support for AMD Pensando SoC Controller
Date: Fri, 31 Mar 2023 15:26:41 -0700	[thread overview]
Message-ID: <20230331222641.38009-1-blarson@amd.com> (raw)
In-Reply-To: <CAHp75VcbDBUf2cH_6rRqn5RCGSEOWqE85Yn3gDhYiJPhGf1S=Q@mail.gmail.com>

Hi Andy,

Thanks for the review.

On Thu, Mar 23, 2023 at 13:06 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Thu, Mar 23, 2023 at 2:11 AM Brad Larson <blarson@amd.com> wrote:
>>
>> The Pensando SoC controller is a SPI connected companion device
>> that is present in all Pensando SoC board designs.  The essential
>> board management registers are accessed on chip select 0 with
>> board mgmt IO support accessed using additional chip selects.
>
> ...
>
>> +config AMD_PENSANDO_CTRL
>> +       tristate "AMD Pensando SoC Controller"
>> +       depends on SPI_MASTER=y
>> +       depends on (ARCH_PENSANDO && OF) || COMPILE_TEST
>> +       default y if ARCH_PENSANDO
>
>       default ARCH_PENSANDO

Changed to default ARCH_PENSANDO

>> +       select REGMAP_SPI
>> +       select MFD_SYSCON
>
> ...
>
>> +/*
>> + * AMD Pensando SoC Controller
>> + *
>> + * Userspace interface and reset driver support for SPI connected Pensando SoC
>> + * controller device.  This device is present in all Pensando SoC designs and
>> + * contains board control/status regsiters and management IO support.
>
> registers ?

Fixed the typo

> ...
>
>> +#include <linux/cdev.h>
>> +#include <linux/delay.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/fs.h>
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>
> Seems semi-random. Are you sure you use this and not missing mod_devicetable.h?

Added mod_devicetable.h.
Removed delay.h, fs.h and of_device.h

>> +#include <linux/reset-controller.h>
>> +#include <linux/spi/spi.h>
>
>...
>
>> +struct penctrl_device {
>> +       struct spi_device *spi_dev;
>> +       struct reset_controller_dev rcdev;
>
> Perhaps swapping these two might provide a better code generation.

Its a 96 byte struct with pointer followed by the reset controller.
The spi_device variable is accessed frequently and rcdev during
boot and ideally never again so if rcdev is mostly missing from
cache that is fine.  Likely the address of spi_dev is also in 
cache given it is periodically accessed.

> ...
>
>> +       struct spi_transfer t[2] = { 0 };
>
> 0 is not needed.

Dropped the 0.

> ...
>
>> +       if (_IOC_DIR(cmd) & _IOC_READ)
>> +               ret = !access_ok((void __user *)arg, _IOC_SIZE(cmd));
>> +       else if (_IOC_DIR(cmd) & _IOC_WRITE)
>> +               ret = !access_ok((void __user *)arg, _IOC_SIZE(cmd));
>
>
> Maybe you should create a temporary variable as
>
>    void __user *in = ... arg;

Yes, created temp variable.

>
>> +       if (ret)
>> +               return -EFAULT;
>
> ...
>
>> +       /* Verify and prepare spi message */
>
> SPI

Changed to SPI

>> +       size = _IOC_SIZE(cmd);
>> +       if ((size % sizeof(struct penctrl_spi_xfer)) != 0) {
>
> ' != 0' is redundant.

Fixed

>
>> +               ret = -EINVAL;
>> +               goto done;
>> +       }
>> +       num_msgs = size / sizeof(struct penctrl_spi_xfer);
>
>> +       if (num_msgs == 0) {
>> +               ret = -EINVAL;
>> +               goto done;
>> +       }
>
> Can be unified with a previous check as
>
> if (size == 0 || size % ...)

Yes, made this change.

>> +       msg = memdup_user((struct penctrl_spi_xfer __user *)arg, size);
>> +       if (!msg) {
>> +               ret = PTR_ERR(msg);
>> +               goto done;
>> +       }
>
>...
>
>> +       if (copy_from_user((void *)(uintptr_t)tx_buf,
>> +                          (void __user *)msg->tx_buf, msg->len)) {
>
> Why are all these castings here?

Yes, overkill, changed to:

        if (copy_from_user(tx_buf, (void __user *)msg->tx_buf, msg->len)) {

> ...
>
>> +       if (copy_to_user((void __user *)msg->rx_buf,
>> +                        (void *)(uintptr_t)rx_buf, msg->len))
>> +               ret = -EFAULT;
>
> Ditto.

Changed to:

        if (copy_to_user((void __user *)msg->rx_buf, rx_buf, msg->len))

> ...
>
>> +       struct spi_transfer t[2] = { 0 };
>
> 0 is redundant.

Dropped the 0.

> ...
>
>> +       struct spi_transfer t[1] = { 0 };
>
> Ditto.

Dropped the 0.

> Why is this an array?

Fixed, it's a single message and shouldn't be an array.

> ...
>
>> +       ret = spi_sync(spi_dev, &m);
>> +       return ret;
>
> return spi_sync(...);

Fixed.

> ...
>
>> +       np = spi_dev->dev.parent->of_node;
>> +       ret = of_property_read_u32(np, "num-cs", &num_cs);
>
> Why not simply device_property_read_u32()?

It can be and removed two lines with below result. Also changed the
variable spi_dev to spi which is the more common usage.

        ret = device_property_read_u32(spi->dev.parent, "num-cs", &num_cs);
        if (ret)
                return dev_err_probe(&spi->dev, ret,
                                     "number of chip-selects not defined\n");

> ...
>
>> +       cdev = cdev_alloc();
>> +       if (!cdev) {
>> +               dev_err(&spi_dev->dev, "allocation of cdev failed");
>> +               ret = -ENOMEM;
>
> ret = dev_err_probe(...);

Fixed.

>> +               goto cdev_failed;
>> +       }
>
> ...
>
>> +       ret = cdev_add(cdev, penctrl_devt, num_cs);
>> +       if (ret) {
>
>> +               dev_err(&spi_dev->dev, "register of cdev failed");
>
> dev_err_probe() ?

Fixed.

>> +               goto cdev_delete;
>> +       }
>
> ...
>
>> +       penctrl = kzalloc(sizeof(*penctrl), GFP_KERNEL);
>> +       if (!penctrl) {
>
>> +               ret = -ENOMEM;
>> +               dev_err(&spi_dev->dev, "allocate driver data failed");
>
> ret = dev_err_probe();
> But we do not print memory allocation failure messages.

Fixed this way

        penctrl = kzalloc(sizeof(*penctrl), GFP_KERNEL);
        if (!penctrl) {
                ret = -ENOMEM;
                goto free_cdev;
        }

> ...
>
>> +               if (IS_ERR(dev)) {
>> +                       ret = IS_ERR(dev);
>> +                       dev_err(&spi_dev->dev, "error creating device\n");
>
> ret = dev_err_probe();

Fixed.

> ...
>
> +       spi_set_drvdata(spi_dev, penctrl);
>
> Is it in use?

Not used and now dropped.

> ...
>
>> +       penctrl->rcdev.of_node = spi_dev->dev.of_node;
>
> device_set_node();

Added: device_set_node(&spi->dev, dev_fwnode(dev));

> ...
>
>> +       ret = reset_controller_register(&penctrl->rcdev);
>> +       if (ret)
>> +               return dev_err_probe(&spi_dev->dev, ret,
>> +                                    "failed to register reset controller\n");
>> +       return ret;
>
> return 0;

Yes, changed.

> ...
>
>> +       device_destroy(penctrl_class, penctrl_devt);
>
> Are you sure this is the correct API?

Yes, however a probe error could call up to 5 APIs to clean up which resulted
in this update:

destroy_device:
        for (cs = 0; cs < num_cs; cs++)
                device_destroy(penctrl_class, MKDEV(MAJOR(penctrl_devt), cs));
        kfree(penctrl);
free_cdev:
        cdev_del(cdev);
destroy_class:
        class_destroy(penctrl_class);
unregister_chrdev:
        unregister_chrdev(MAJOR(penctrl_devt), "penctrl");

        return ret;

> ...
>
>> +#include <linux/types.h>
>> +#include <linux/ioctl.h>
>
> Sorted?

Swapped these

Regards,
Brad

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

  reply	other threads:[~2023-03-31 22:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23  0:06 [PATCH v12 00/15] Support AMD Pensando Elba SoC Brad Larson
2023-03-23  0:06 ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 01/15] dt-bindings: arm: add AMD Pensando boards Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 02/15] dt-bindings: mmc: cdns: Add AMD Pensando Elba SoC Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  6:36   ` Krzysztof Kozlowski
2023-03-23  6:36     ` Krzysztof Kozlowski
2023-03-23  0:06 ` [PATCH v12 03/15] dt-bindings: spi: cdns: Add compatible for " Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 04/15] dt-bindings: spi: dw: Add AMD Pensando Elba SoC SPI Controller Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 05/15] dt-bindings: soc: amd: amd,pensando-elba-ctrl: Add Pensando SoC Controller Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 06/15] MAINTAINERS: Add entry for AMD PENSANDO Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 07/15] arm64: Add config for AMD Pensando SoC platforms Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 08/15] arm64: dts: Add AMD Pensando Elba SoC support Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 09/15] spi: cadence-quadspi: Add compatible for AMD Pensando Elba SoC Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 10/15] spi: dw: Add support " Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 11/15] mmc: sdhci-cadence: Enable device specific override of writel() Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 12/15] mmc: sdhci-cadence: Support device specific init during probe Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  0:06 ` [PATCH v12 13/15] mmc: sdhci-cadence: Add AMD Pensando Elba SoC support Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23 10:42   ` Andy Shevchenko
2023-03-23 10:42     ` Andy Shevchenko
2023-03-23  0:06 ` [PATCH v12 14/15] mmc: sdhci-cadence: Support mmc hardware reset Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23  9:04   ` Philipp Zabel
2023-03-23  9:04     ` Philipp Zabel
2023-03-23  0:06 ` [PATCH v12 15/15] soc: amd: Add support for AMD Pensando SoC Controller Brad Larson
2023-03-23  0:06   ` Brad Larson
2023-03-23 11:06   ` Andy Shevchenko
2023-03-23 11:06     ` Andy Shevchenko
2023-03-31 22:26     ` Brad Larson [this message]
2023-03-31 22:26       ` Brad Larson

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=20230331222641.38009-1-blarson@amd.com \
    --to=blarson@amd.com \
    --cc=adrian.hunter@intel.com \
    --cc=alcooperx@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=brendan.higgins@linux.dev \
    --cc=briannorris@chromium.org \
    --cc=brijeshkumar.singh@amd.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=davidgow@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=gerg@linux-m68k.org \
    --cc=gsomlo@gmail.com \
    --cc=krzk@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee.jones@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=p.yadav@ti.com \
    --cc=p.zabel@pengutronix.de \
    --cc=piotrs@cadence.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=samuel@sholland.org \
    --cc=skhan@linuxfoundation.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=thomas.lendacky@amd.com \
    --cc=tonyhuang.sunplus@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vaishnav.a@ti.com \
    --cc=will@kernel.org \
    --cc=yamada.masahiro@socionext.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.