All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Verdun, Jean-Marie" <verdun@hpe.com>
Cc: "minyard@acm.org" <minyard@acm.org>,
	"Hawkins, Nick" <nick.hawkins@hpe.com>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Amit Kucheria" <amitk@kernel.org>,
	"Zhang Rui" <rui.zhang@intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Russell King" <linux@armlinux.org.uk>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Olof Johansson" <olof@lixom.net>,
	"soc@kernel.org" <soc@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Stanislav Jakubek" <stano.jakubek@gmail.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Hao Fang" <fanghao11@huawei.com>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Anshuman Khandual" <anshuman.khandual@arm.com>,
	"Wang Kefeng" <wangkefeng.wang@huawei.com>,
	"Lukas Bulwahn" <lukas.bulwahn@gmail.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"openipmi-developer@lists.sourceforge.net"
	<openipmi-developer@lists.sourceforge.net>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] HPE BMC GXP SUPPORT
Date: Wed, 2 Feb 2022 22:21:25 +0100	[thread overview]
Message-ID: <CAK8P3a3itj=nshdRCoFQQh5fg-RsEaqj1PdBxfeN2-TzqmoPpQ@mail.gmail.com> (raw)
In-Reply-To: <3E9905F2-1576-4826-ADC2-85796DE0F4DB@hpe.com>

On Wed, Feb 2, 2022 at 7:14 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
>
> > This is far too big for a single patch.  It needs to be broken into
> > functional chunks that can be reviewed individually.  Each driver and
> > each device tree change along with it's accompanying code need to be
> > done in individual patches.  The way it is it can't be reviewed in any
> > sane manner.
>
> > -corey
>
> Thanks for your feedback. We are getting a little bit lost here, as our plan was to submit initial
>
> - bindings
> - dts for SoC and 1 board
> - initial platform init code
>
> Then drivers code avoiding to send many dts updates which might complexify the
> review. We wanted to send all drivers code to relevant reviewers by tomorrow.
>
> So, what you are asking ( do not worry I am not trying to negotiate, I just want
> to avoid English misunderstandings as I am French) is to send per driver
>
> - binding
> - dts update
> - driver code
>
> For each driver through different submission (with each of them containing the
> 3 associated parts) ?
>
> What shall be the initial one in our case as we are introducing a platform ?
> An empty dts infrastructure and then we make it grow one step at a time ?

Ideally, what I prefer to see is a series of patches for all "essential" drivers
and the platform code that includes:

- one patch for each new binding
- one patch for each new driver
- one patch that hooks up arch/arm/mach-hpe/, MAINTAINERS
  and any other changes to arch/arm/ other than dts
- one patch that adds the initial .dts and .dtsi files, with all the
  devices added that have a valid binding, no need to split this
  up any further

This should include everything you need to boot into an initramfs
shell, typically cpu, serial, timer, clk, pinctrl,  gpio, irqchip. We will
merge these as a git branch in the soc tree.

In parallel, you can work with subsystem maintainers for the
"non-essential" drivers to review any other driver and binding,
e.g. drm/kms, network, i2c, pci, usb, etc. The patches for
the corresponding .dts additions also go through the soc tree,
but to make things simpler, you can send those in for a later
release.

          Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Verdun, Jean-Marie" <verdun@hpe.com>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	"Wang Kefeng" <wangkefeng.wang@huawei.com>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	"Amit Kucheria" <amitk@kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Stanislav Jakubek" <stano.jakubek@gmail.com>,
	"Hao Fang" <fanghao11@huawei.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Russell King" <linux@armlinux.org.uk>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"openipmi-developer@lists.sourceforge.net"
	<openipmi-developer@lists.sourceforge.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Zhang Rui" <rui.zhang@intel.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	"minyard@acm.org" <minyard@acm.org>,
	"Anshuman Khandual" <anshuman.khandual@arm.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"soc@kernel.org" <soc@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Hawkins, Nick" <nick.hawkins@hpe.com>,
	"Lukas Bulwahn" <lukas.bulwahn@gmail.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] HPE BMC GXP SUPPORT
Date: Wed, 2 Feb 2022 22:21:25 +0100	[thread overview]
Message-ID: <CAK8P3a3itj=nshdRCoFQQh5fg-RsEaqj1PdBxfeN2-TzqmoPpQ@mail.gmail.com> (raw)
In-Reply-To: <3E9905F2-1576-4826-ADC2-85796DE0F4DB@hpe.com>

On Wed, Feb 2, 2022 at 7:14 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
>
> > This is far too big for a single patch.  It needs to be broken into
> > functional chunks that can be reviewed individually.  Each driver and
> > each device tree change along with it's accompanying code need to be
> > done in individual patches.  The way it is it can't be reviewed in any
> > sane manner.
>
> > -corey
>
> Thanks for your feedback. We are getting a little bit lost here, as our plan was to submit initial
>
> - bindings
> - dts for SoC and 1 board
> - initial platform init code
>
> Then drivers code avoiding to send many dts updates which might complexify the
> review. We wanted to send all drivers code to relevant reviewers by tomorrow.
>
> So, what you are asking ( do not worry I am not trying to negotiate, I just want
> to avoid English misunderstandings as I am French) is to send per driver
>
> - binding
> - dts update
> - driver code
>
> For each driver through different submission (with each of them containing the
> 3 associated parts) ?
>
> What shall be the initial one in our case as we are introducing a platform ?
> An empty dts infrastructure and then we make it grow one step at a time ?

Ideally, what I prefer to see is a series of patches for all "essential" drivers
and the platform code that includes:

- one patch for each new binding
- one patch for each new driver
- one patch that hooks up arch/arm/mach-hpe/, MAINTAINERS
  and any other changes to arch/arm/ other than dts
- one patch that adds the initial .dts and .dtsi files, with all the
  devices added that have a valid binding, no need to split this
  up any further

This should include everything you need to boot into an initramfs
shell, typically cpu, serial, timer, clk, pinctrl,  gpio, irqchip. We will
merge these as a git branch in the soc tree.

In parallel, you can work with subsystem maintainers for the
"non-essential" drivers to review any other driver and binding,
e.g. drm/kms, network, i2c, pci, usb, etc. The patches for
the corresponding .dts additions also go through the soc tree,
but to make things simpler, you can send those in for a later
release.

          Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Verdun, Jean-Marie" <verdun@hpe.com>
Cc: "minyard@acm.org" <minyard@acm.org>,
	"Hawkins, Nick" <nick.hawkins@hpe.com>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@canonical.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Amit Kucheria" <amitk@kernel.org>,
	"Zhang Rui" <rui.zhang@intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Russell King" <linux@armlinux.org.uk>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Olof Johansson" <olof@lixom.net>,
	"soc@kernel.org" <soc@kernel.org>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Stanislav Jakubek" <stano.jakubek@gmail.com>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Hao Fang" <fanghao11@huawei.com>,
	"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Anshuman Khandual" <anshuman.khandual@arm.com>,
	"Wang Kefeng" <wangkefeng.wang@huawei.com>,
	"Lukas Bulwahn" <lukas.bulwahn@gmail.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"openipmi-developer@lists.sourceforge.net"
	<openipmi-developer@lists.sourceforge.net>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] HPE BMC GXP SUPPORT
Date: Wed, 2 Feb 2022 22:21:25 +0100	[thread overview]
Message-ID: <CAK8P3a3itj=nshdRCoFQQh5fg-RsEaqj1PdBxfeN2-TzqmoPpQ@mail.gmail.com> (raw)
In-Reply-To: <3E9905F2-1576-4826-ADC2-85796DE0F4DB@hpe.com>

On Wed, Feb 2, 2022 at 7:14 PM Verdun, Jean-Marie <verdun@hpe.com> wrote:
>
> > This is far too big for a single patch.  It needs to be broken into
> > functional chunks that can be reviewed individually.  Each driver and
> > each device tree change along with it's accompanying code need to be
> > done in individual patches.  The way it is it can't be reviewed in any
> > sane manner.
>
> > -corey
>
> Thanks for your feedback. We are getting a little bit lost here, as our plan was to submit initial
>
> - bindings
> - dts for SoC and 1 board
> - initial platform init code
>
> Then drivers code avoiding to send many dts updates which might complexify the
> review. We wanted to send all drivers code to relevant reviewers by tomorrow.
>
> So, what you are asking ( do not worry I am not trying to negotiate, I just want
> to avoid English misunderstandings as I am French) is to send per driver
>
> - binding
> - dts update
> - driver code
>
> For each driver through different submission (with each of them containing the
> 3 associated parts) ?
>
> What shall be the initial one in our case as we are introducing a platform ?
> An empty dts infrastructure and then we make it grow one step at a time ?

Ideally, what I prefer to see is a series of patches for all "essential" drivers
and the platform code that includes:

- one patch for each new binding
- one patch for each new driver
- one patch that hooks up arch/arm/mach-hpe/, MAINTAINERS
  and any other changes to arch/arm/ other than dts
- one patch that adds the initial .dts and .dtsi files, with all the
  devices added that have a valid binding, no need to split this
  up any further

This should include everything you need to boot into an initramfs
shell, typically cpu, serial, timer, clk, pinctrl,  gpio, irqchip. We will
merge these as a git branch in the soc tree.

In parallel, you can work with subsystem maintainers for the
"non-essential" drivers to review any other driver and binding,
e.g. drm/kms, network, i2c, pci, usb, etc. The patches for
the corresponding .dts additions also go through the soc tree,
but to make things simpler, you can send those in for a later
release.

          Arnd

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2022-02-02 21:21 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-02 16:52 [PATCH] HPE BMC GXP SUPPORT nick.hawkins
2022-02-02 16:52 ` nick.hawkins
2022-02-02 16:52 ` nick.hawkins
2022-02-02 17:56 ` Corey Minyard
2022-02-02 17:56   ` Corey Minyard
2022-02-02 17:56   ` Corey Minyard
2022-02-02 18:14   ` Verdun, Jean-Marie
2022-02-02 18:14     ` Verdun, Jean-Marie
2022-02-02 18:14     ` Verdun, Jean-Marie
2022-02-02 21:21     ` Arnd Bergmann [this message]
2022-02-02 21:21       ` Arnd Bergmann
2022-02-02 21:21       ` Arnd Bergmann
2022-02-02 22:10     ` [Openipmi-developer] " Corey Minyard
2022-02-02 22:10       ` Corey Minyard
2022-02-02 22:10       ` Corey Minyard
2022-02-02 18:14 ` Sam Ravnborg
2022-02-02 18:14   ` Sam Ravnborg
2022-02-02 18:14   ` Sam Ravnborg
2022-02-03  1:10 ` Andrew Lunn
2022-02-03  1:10   ` Andrew Lunn
2022-02-03  1:10   ` Andrew Lunn
2022-02-03  7:41 ` Krzysztof Kozlowski
2022-02-03  7:41   ` Krzysztof Kozlowski
2022-02-03  7:41   ` Krzysztof Kozlowski
2022-02-03 14:29 ` Rob Herring
2022-02-03 14:29   ` Rob Herring
2022-02-03 14:29   ` Rob Herring
2022-02-03 14:55   ` Krzysztof Kozlowski
2022-02-03 14:55     ` Krzysztof Kozlowski
2022-02-03 14:55     ` Krzysztof Kozlowski
2022-02-03 17:07     ` Verdun, Jean-Marie
2022-02-03 17:07       ` Verdun, Jean-Marie
2022-02-03 17:07       ` Verdun, Jean-Marie
2022-02-04  8:52       ` Krzysztof Kozlowski
2022-02-04  8:52         ` Krzysztof Kozlowski
2022-02-04  8:52         ` Krzysztof Kozlowski
2022-02-04 12:05 ` Russell King (Oracle)
2022-02-04 12:05   ` Russell King (Oracle)
2022-02-04 12:05   ` Russell King (Oracle)
2022-02-04 12:18   ` Joe Perches
2022-02-04 12:18     ` Joe Perches
2022-02-04 12:18     ` Joe Perches
2022-02-04 12:31     ` Russell King (Oracle)
2022-02-04 12:31       ` Russell King (Oracle)
2022-02-04 12:31       ` Russell King (Oracle)
2022-02-04 14:01       ` Joe Perches
2022-02-04 14:01         ` Joe Perches
2022-02-04 14:01         ` Joe Perches
2022-02-04 13:32   ` Andrew Lunn
2022-02-04 13:32     ` Andrew Lunn
2022-02-04 13:32     ` Andrew Lunn

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='CAK8P3a3itj=nshdRCoFQQh5fg-RsEaqj1PdBxfeN2-TzqmoPpQ@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=airlied@linux.ie \
    --cc=amitk@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fanghao11@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=kuba@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@roeck-us.net \
    --cc=lukas.bulwahn@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=maz@kernel.org \
    --cc=minyard@acm.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=nick.hawkins@hpe.com \
    --cc=olof@lixom.net \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=rafael@kernel.org \
    --cc=richard@nod.at \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robh+dt@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=sam@ravnborg.org \
    --cc=shawnguo@kernel.org \
    --cc=soc@kernel.org \
    --cc=stano.jakubek@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=verdun@hpe.com \
    --cc=vigneshr@ti.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=wim@linux-watchdog.org \
    /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.