All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Sean Young" <sean@mess.org>,
	linux-media@vger.kernel.org, linux-pwm@vger.kernel.org,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	"Jean Delvare" <jdelvare@suse.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Support Opensource" <support.opensource@diasemi.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Pavel Machek" <pavel@ucw.cz>, "Lee Jones" <lee@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Mark Gross" <markgross@kernel.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Daniel Thompson" <daniel.thompson@linaro.org>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-hwmon@vger.kernel.org, linux-input@vger.kernel.org,
	linux-leds@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
Date: Sat, 21 Oct 2023 11:08:22 +0200	[thread overview]
Message-ID: <01a505ac-320f-3819-a58d-2b82c1bf2a86@redhat.com> (raw)
In-Reply-To: <20231019105118.64gdzzixwqrztjir@pengutronix.de>

Hi Uwe,

On 10/19/23 12:51, Uwe Kleine-König wrote:
> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>> Hi Sean,
>>
>> On 10/17/23 11:17, Sean Young wrote:
>>> Some drivers require sleeping, for example if the pwm device is connected
>>> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
>>> with the generated IR signal when sleeping occurs.
>>>
>>> This patch makes it possible to use pwm when the driver does not sleep,
>>> by introducing the pwm_can_sleep() function.
>>>
>>> Signed-off-by: Sean Young <sean@mess.org>
>>
>> I have no objection to this patch by itself, but it seems a bit
>> of unnecessary churn to change all current callers of pwm_apply_state()
>> to a new API.
> 
> The idea is to improve the semantic of the function name, see
> https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rlymzz@pengutronix.de
> for more context.

Hmm, so the argument here is that the GPIO API has this, but GPIOs
generally speaking can be set atomically, so there not being able
to set it atomically is special.

OTOH we have many many many other kernel functions which may sleep
and we don't all postfix them with _can_sleep.

And for PWM controllers pwm_apply_state is IMHO sorta expected to
sleep. Many of these are attached over I2C so things will sleep,
others have a handshake to wait for the current dutycycle to
end before you can apply a second change on top of an earlier
change during the current dutycycle which often also involves
sleeping.

So the natural/expeected thing for pwm_apply_state() is to sleep
and thus it does not need a postfix for this IMHO.

> I think it's very subjective if you consider this
> churn or not.

I consider it churn because I don't think adding a postfix
for what is the default/expected behavior is a good idea
(with GPIOs not sleeping is the expected behavior).

I agree that this is very subjective and very much goes
into the territory of bikeshedding. So please consider
the above my 2 cents on this and lets leave it at that.

> While it's nice to have every caller converted in a single
> step, I'd go for
> 
> 	#define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state)
> 
> , keep that macro for a while and convert all users step by step. This
> way we don't needlessly break oot code and the changes to convert to the
> new API can go via their usual trees without time pressure.

I don't think there are enough users of pwm_apply_state() to warrant
such an exercise.

So if people want to move ahead with the _can_sleep postfix addition
(still not a fan) here is my acked-by for the drivers/platform/x86
changes, for merging this through the PWM tree in a single commit:

Acked-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans



WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "Sean Young" <sean@mess.org>,
	linux-media@vger.kernel.org, linux-pwm@vger.kernel.org,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	"Jean Delvare" <jdelvare@suse.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Support Opensource" <support.opensource@diasemi.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Pavel Machek" <pavel@ucw.cz>, "Lee Jones" <lee@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Mark Gross" <markgross@kernel.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Daniel Thompson" <daniel.thompson@linaro.org>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Helge Deller" <deller@gmx.de>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-hwmon@vger.kernel.org, linux-input@vger.kernel.org,
	linux-leds@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
Date: Sat, 21 Oct 2023 11:08:22 +0200	[thread overview]
Message-ID: <01a505ac-320f-3819-a58d-2b82c1bf2a86@redhat.com> (raw)
In-Reply-To: <20231019105118.64gdzzixwqrztjir@pengutronix.de>

Hi Uwe,

On 10/19/23 12:51, Uwe Kleine-König wrote:
> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>> Hi Sean,
>>
>> On 10/17/23 11:17, Sean Young wrote:
>>> Some drivers require sleeping, for example if the pwm device is connected
>>> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
>>> with the generated IR signal when sleeping occurs.
>>>
>>> This patch makes it possible to use pwm when the driver does not sleep,
>>> by introducing the pwm_can_sleep() function.
>>>
>>> Signed-off-by: Sean Young <sean@mess.org>
>>
>> I have no objection to this patch by itself, but it seems a bit
>> of unnecessary churn to change all current callers of pwm_apply_state()
>> to a new API.
> 
> The idea is to improve the semantic of the function name, see
> https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rlymzz@pengutronix.de
> for more context.

Hmm, so the argument here is that the GPIO API has this, but GPIOs
generally speaking can be set atomically, so there not being able
to set it atomically is special.

OTOH we have many many many other kernel functions which may sleep
and we don't all postfix them with _can_sleep.

And for PWM controllers pwm_apply_state is IMHO sorta expected to
sleep. Many of these are attached over I2C so things will sleep,
others have a handshake to wait for the current dutycycle to
end before you can apply a second change on top of an earlier
change during the current dutycycle which often also involves
sleeping.

So the natural/expeected thing for pwm_apply_state() is to sleep
and thus it does not need a postfix for this IMHO.

> I think it's very subjective if you consider this
> churn or not.

I consider it churn because I don't think adding a postfix
for what is the default/expected behavior is a good idea
(with GPIOs not sleeping is the expected behavior).

I agree that this is very subjective and very much goes
into the territory of bikeshedding. So please consider
the above my 2 cents on this and lets leave it at that.

> While it's nice to have every caller converted in a single
> step, I'd go for
> 
> 	#define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state)
> 
> , keep that macro for a while and convert all users step by step. This
> way we don't needlessly break oot code and the changes to convert to the
> new API can go via their usual trees without time pressure.

I don't think there are enough users of pwm_apply_state() to warrant
such an exercise.

So if people want to move ahead with the _can_sleep postfix addition
(still not a fan) here is my acked-by for the drivers/platform/x86
changes, for merging this through the PWM tree in a single commit:

Acked-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans



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

WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-fbdev@vger.kernel.org, "Sean Young" <sean@mess.org>,
	linux-doc@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Pavel Machek" <pavel@ucw.cz>,
	linux-leds@vger.kernel.org,
	"Daniel Thompson" <daniel.thompson@linaro.org>,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Helge Deller" <deller@gmx.de>, "Lee Jones" <lee@kernel.org>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	linux-input@vger.kernel.org,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	linux-media@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-pwm@vger.kernel.org, "Jean Delvare" <jdelvare@suse.com>,
	intel-gfx@lists.freedesktop.org,
	"Mark Gross" <markgross@kernel.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-hwmon@vger.kernel.org,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Support Opensource" <support.opensource@diasemi.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>
Subject: Re: [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
Date: Sat, 21 Oct 2023 11:08:22 +0200	[thread overview]
Message-ID: <01a505ac-320f-3819-a58d-2b82c1bf2a86@redhat.com> (raw)
In-Reply-To: <20231019105118.64gdzzixwqrztjir@pengutronix.de>

Hi Uwe,

On 10/19/23 12:51, Uwe Kleine-König wrote:
> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>> Hi Sean,
>>
>> On 10/17/23 11:17, Sean Young wrote:
>>> Some drivers require sleeping, for example if the pwm device is connected
>>> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
>>> with the generated IR signal when sleeping occurs.
>>>
>>> This patch makes it possible to use pwm when the driver does not sleep,
>>> by introducing the pwm_can_sleep() function.
>>>
>>> Signed-off-by: Sean Young <sean@mess.org>
>>
>> I have no objection to this patch by itself, but it seems a bit
>> of unnecessary churn to change all current callers of pwm_apply_state()
>> to a new API.
> 
> The idea is to improve the semantic of the function name, see
> https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rlymzz@pengutronix.de
> for more context.

Hmm, so the argument here is that the GPIO API has this, but GPIOs
generally speaking can be set atomically, so there not being able
to set it atomically is special.

OTOH we have many many many other kernel functions which may sleep
and we don't all postfix them with _can_sleep.

And for PWM controllers pwm_apply_state is IMHO sorta expected to
sleep. Many of these are attached over I2C so things will sleep,
others have a handshake to wait for the current dutycycle to
end before you can apply a second change on top of an earlier
change during the current dutycycle which often also involves
sleeping.

So the natural/expeected thing for pwm_apply_state() is to sleep
and thus it does not need a postfix for this IMHO.

> I think it's very subjective if you consider this
> churn or not.

I consider it churn because I don't think adding a postfix
for what is the default/expected behavior is a good idea
(with GPIOs not sleeping is the expected behavior).

I agree that this is very subjective and very much goes
into the territory of bikeshedding. So please consider
the above my 2 cents on this and lets leave it at that.

> While it's nice to have every caller converted in a single
> step, I'd go for
> 
> 	#define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state)
> 
> , keep that macro for a while and convert all users step by step. This
> way we don't needlessly break oot code and the changes to convert to the
> new API can go via their usual trees without time pressure.

I don't think there are enough users of pwm_apply_state() to warrant
such an exercise.

So if people want to move ahead with the _can_sleep postfix addition
(still not a fan) here is my acked-by for the drivers/platform/x86
changes, for merging this through the PWM tree in a single commit:

Acked-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans



WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-fbdev@vger.kernel.org, "Sean Young" <sean@mess.org>,
	linux-doc@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, "Pavel Machek" <pavel@ucw.cz>,
	"David Airlie" <airlied@gmail.com>,
	linux-leds@vger.kernel.org,
	"Daniel Thompson" <daniel.thompson@linaro.org>,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Helge Deller" <deller@gmx.de>, "Lee Jones" <lee@kernel.org>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	linux-input@vger.kernel.org,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	linux-media@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-pwm@vger.kernel.org, "Jean Delvare" <jdelvare@suse.com>,
	intel-gfx@lists.freedesktop.org,
	"Mark Gross" <markgross@kernel.org>,
	"Mark Brown" <broonie@kernel.org>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-hwmon@vger.kernel.org,
	"Support Opensource" <support.opensource@diasemi.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
Date: Sat, 21 Oct 2023 11:08:22 +0200	[thread overview]
Message-ID: <01a505ac-320f-3819-a58d-2b82c1bf2a86@redhat.com> (raw)
In-Reply-To: <20231019105118.64gdzzixwqrztjir@pengutronix.de>

Hi Uwe,

On 10/19/23 12:51, Uwe Kleine-König wrote:
> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>> Hi Sean,
>>
>> On 10/17/23 11:17, Sean Young wrote:
>>> Some drivers require sleeping, for example if the pwm device is connected
>>> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
>>> with the generated IR signal when sleeping occurs.
>>>
>>> This patch makes it possible to use pwm when the driver does not sleep,
>>> by introducing the pwm_can_sleep() function.
>>>
>>> Signed-off-by: Sean Young <sean@mess.org>
>>
>> I have no objection to this patch by itself, but it seems a bit
>> of unnecessary churn to change all current callers of pwm_apply_state()
>> to a new API.
> 
> The idea is to improve the semantic of the function name, see
> https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rlymzz@pengutronix.de
> for more context.

Hmm, so the argument here is that the GPIO API has this, but GPIOs
generally speaking can be set atomically, so there not being able
to set it atomically is special.

OTOH we have many many many other kernel functions which may sleep
and we don't all postfix them with _can_sleep.

And for PWM controllers pwm_apply_state is IMHO sorta expected to
sleep. Many of these are attached over I2C so things will sleep,
others have a handshake to wait for the current dutycycle to
end before you can apply a second change on top of an earlier
change during the current dutycycle which often also involves
sleeping.

So the natural/expeected thing for pwm_apply_state() is to sleep
and thus it does not need a postfix for this IMHO.

> I think it's very subjective if you consider this
> churn or not.

I consider it churn because I don't think adding a postfix
for what is the default/expected behavior is a good idea
(with GPIOs not sleeping is the expected behavior).

I agree that this is very subjective and very much goes
into the territory of bikeshedding. So please consider
the above my 2 cents on this and lets leave it at that.

> While it's nice to have every caller converted in a single
> step, I'd go for
> 
> 	#define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state)
> 
> , keep that macro for a while and convert all users step by step. This
> way we don't needlessly break oot code and the changes to convert to the
> new API can go via their usual trees without time pressure.

I don't think there are enough users of pwm_apply_state() to warrant
such an exercise.

So if people want to move ahead with the _can_sleep postfix addition
(still not a fan) here is my acked-by for the drivers/platform/x86
changes, for merging this through the PWM tree in a single commit:

Acked-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans



  reply	other threads:[~2023-10-21  9:09 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-17  9:17 [PATCH v3 0/3] Improve pwm-ir-tx precision Sean Young
2023-10-17  9:17 ` [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context Sean Young
2023-10-17  9:17   ` [Intel-gfx] " Sean Young
2023-10-17  9:17   ` Sean Young
2023-10-17  9:17   ` Sean Young
2023-10-18 13:57   ` Hans de Goede
2023-10-18 13:57     ` Hans de Goede
2023-10-18 13:57     ` [Intel-gfx] " Hans de Goede
2023-10-18 13:57     ` Hans de Goede
2023-10-19 10:51     ` Uwe Kleine-König
2023-10-19 10:51       ` Uwe Kleine-König
2023-10-19 10:51       ` [Intel-gfx] " Uwe Kleine-König
2023-10-19 10:51       ` Uwe Kleine-König
2023-10-21  9:08       ` Hans de Goede [this message]
2023-10-21  9:08         ` [Intel-gfx] " Hans de Goede
2023-10-21  9:08         ` Hans de Goede
2023-10-21  9:08         ` Hans de Goede
2023-10-22 10:46         ` Sean Young
2023-10-22 10:46           ` [Intel-gfx] " Sean Young
2023-10-22 10:46           ` Sean Young
2023-10-22 10:46           ` Sean Young
2023-10-23 13:17           ` Hans de Goede
2023-10-23 13:17             ` [Intel-gfx] " Hans de Goede
2023-10-23 13:17             ` Hans de Goede
2023-10-23 13:17             ` Hans de Goede
2023-10-23 13:34           ` Daniel Thompson
2023-10-23 13:34             ` Daniel Thompson
2023-10-23 13:34             ` [Intel-gfx] " Daniel Thompson
2023-10-23 13:34             ` Daniel Thompson
2023-10-25  9:53             ` Sean Young
2023-10-25  9:53               ` [Intel-gfx] " Sean Young
2023-10-25  9:53               ` Sean Young
2023-10-25  9:53               ` Sean Young
2023-10-25 10:47               ` Uwe Kleine-König
2023-10-25 10:47                 ` [Intel-gfx] " Uwe Kleine-König
2023-10-25 10:47                 ` Uwe Kleine-König
2023-10-25 10:47                 ` Uwe Kleine-König
2023-10-21 23:55   ` kernel test robot
2023-10-23 10:47   ` Jani Nikula
2023-10-23 10:47     ` Jani Nikula
2023-10-23 10:47     ` [Intel-gfx] " Jani Nikula
2023-10-23 10:47     ` Jani Nikula
2023-10-17  9:17 ` [PATCH v3 2/3] pwm: bcm2835: allow pwm driver to be used " Sean Young
2023-10-17  9:17   ` Sean Young
2023-10-18 15:00   ` Stefan Wahren
2023-10-18 15:00     ` Stefan Wahren
2023-10-19 11:19     ` Sean Young
2023-10-19 11:19       ` Sean Young
2023-10-17  9:17 ` [PATCH v3 3/3] media: pwm-ir-tx: trigger edges from hrtimer interrupt context Sean Young

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=01a505ac-320f-3819-a58d-2b82c1bf2a86@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=airlied@gmail.com \
    --cc=broonie@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel.thompson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=deller@gmx.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=javierm@redhat.com \
    --cc=jdelvare@suse.com \
    --cc=jingoohan1@gmail.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=markgross@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sean@mess.org \
    --cc=support.opensource@diasemi.com \
    --cc=thierry.reding@gmail.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.