All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Wolfram Sang <wsa@kernel.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Sean Young <sean@mess.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Gross <markgross@kernel.org>, Vinod Koul <vkoul@kernel.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Sanyog Kale <sanyog.r.kale@intel.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Ming Lei <ming.lei@redhat.com>, Jilin Yuan <yuanjilin@cdjrlc.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ira Weiny <ira.weiny@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Won Chung <wonchung@google.com>,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-block@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-i3c@lists.infradead.org,
	linux-input@vger.kernel.org, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-usb@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH 3/5] driver core: make struct device_type.uevent() take a const *
Date: Wed, 23 Nov 2022 14:59:00 +0100	[thread overview]
Message-ID: <97be39ed-3cea-d55a-caa6-c2652baef399@gmail.com> (raw)
In-Reply-To: <Y34hgIW8p1RlQTBB@smile.fi.intel.com>

On 11/23/22 14:34, Andy Shevchenko wrote:
> On Wed, Nov 23, 2022 at 02:14:31PM +0100, Maximilian Luz wrote:
>> On 11/23/22 13:25, Greg Kroah-Hartman wrote:
>>> The uevent() callback in struct device_type should not be modifying the
>>> device that is passed into it, so mark it as a const * and propagate the
>>> function signature changes out into all relevant subsystems that use
>>> this callback.
> 
> [...]
> 
>>> -static inline struct ssam_device *to_ssam_device(struct device *d)
>>> +static inline struct ssam_device *to_ssam_device(const struct device *d)
>>>    {
>>>    	return container_of(d, struct ssam_device, dev);
>>>    }
>>
>> I am slightly conflicted about this change as that now more or less
>> implicitly drops the const. So I'm wondering if it wouldn't be better to
>> either create a function specifically for const pointers or to just
>> open-code it in the instance above.
>>
>> I guess we could also convert this to a macro. Then at least there
>> wouldn't be an explicit and potentially misleading const-conversion
>> indicated in the function signature.
> 
> This is an intermediate step as far as I know since moving container_of to
> recognize const is a bit noisy right now. I guess you can find a discussion
> on the topic between Greg and Sakari.

Thanks! I assume you are referring to the following?

	https://lore.kernel.org/lkml/4218173bd72b4f1899d4c41a8e251f0d@AcuMS.aculab.com/T/

As far as I can tell this is only a warning in documentation, not
compile time (which would probably be impossible?).

As I've said I'd be fine with converting the function to a macro (and
preferably adding a similar warning like the one proposed in that
thread). The point that irks me up is just that, as proposed, the
function signature would now advertise a conversion that should never be
happening.

Having two separate functions would create a compile-time guarantee, so
I'd prefer that, but I can understand if that might be considered too
noisy in code. Or if there is a push to make container_of() emit a
compile-time warning I'd also be perfectly happy with converting it to a
macro now as that'd alleviate the need for functions in the future.

Regards,
Max


WARNING: multiple messages have this Message-ID (diff)
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Wolfram Sang <wsa@kernel.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Sean Young <sean@mess.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Mark Gross <markgross@kernel.org>, Vinod Koul <vkoul@kernel.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Sanyog Kale <sanyog.r.kale@intel.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Ming Lei <ming.lei@redhat.com>, Jilin Yuan <yuanjilin@cdjrlc.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ira Weiny <ira.weiny@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Won Chung <wonchung@google.com>,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	linux-acpi@vger.kernel.org, linux-block@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-i3c@lists.infradead.org,
	linux-input@vger.kernel.org, linux-media@vger.kernel.org,
	linux-serial@vger.kernel.org, linux-usb@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH 3/5] driver core: make struct device_type.uevent() take a const *
Date: Wed, 23 Nov 2022 14:59:00 +0100	[thread overview]
Message-ID: <97be39ed-3cea-d55a-caa6-c2652baef399@gmail.com> (raw)
In-Reply-To: <Y34hgIW8p1RlQTBB@smile.fi.intel.com>

On 11/23/22 14:34, Andy Shevchenko wrote:
> On Wed, Nov 23, 2022 at 02:14:31PM +0100, Maximilian Luz wrote:
>> On 11/23/22 13:25, Greg Kroah-Hartman wrote:
>>> The uevent() callback in struct device_type should not be modifying the
>>> device that is passed into it, so mark it as a const * and propagate the
>>> function signature changes out into all relevant subsystems that use
>>> this callback.
> 
> [...]
> 
>>> -static inline struct ssam_device *to_ssam_device(struct device *d)
>>> +static inline struct ssam_device *to_ssam_device(const struct device *d)
>>>    {
>>>    	return container_of(d, struct ssam_device, dev);
>>>    }
>>
>> I am slightly conflicted about this change as that now more or less
>> implicitly drops the const. So I'm wondering if it wouldn't be better to
>> either create a function specifically for const pointers or to just
>> open-code it in the instance above.
>>
>> I guess we could also convert this to a macro. Then at least there
>> wouldn't be an explicit and potentially misleading const-conversion
>> indicated in the function signature.
> 
> This is an intermediate step as far as I know since moving container_of to
> recognize const is a bit noisy right now. I guess you can find a discussion
> on the topic between Greg and Sakari.

Thanks! I assume you are referring to the following?

	https://lore.kernel.org/lkml/4218173bd72b4f1899d4c41a8e251f0d@AcuMS.aculab.com/T/

As far as I can tell this is only a warning in documentation, not
compile time (which would probably be impossible?).

As I've said I'd be fine with converting the function to a macro (and
preferably adding a similar warning like the one proposed in that
thread). The point that irks me up is just that, as proposed, the
function signature would now advertise a conversion that should never be
happening.

Having two separate functions would create a compile-time guarantee, so
I'd prefer that, but I can understand if that might be considered too
noisy in code. Or if there is a push to make container_of() emit a
compile-time warning I'd also be perfectly happy with converting it to a
macro now as that'd alleviate the need for functions in the future.

Regards,
Max


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

WARNING: multiple messages have this Message-ID (diff)
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sean Young <sean@mess.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	alsa-devel@alsa-project.org, platform-driver-x86@vger.kernel.org,
	linux-i2c@vger.kernel.org,
	Andreas Noever <andreas.noever@gmail.com>,
	linux-i3c@lists.infradead.org,
	linux1394-devel@lists.sourceforge.net,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-acpi@vger.kernel.org, Frank Rowand <frowand.list@gmail.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	"Matthew Wilcox \(Oracle\)" <willy@infradead.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Alan Stern <stern@rowland.harvard.edu>,
	linux-serial@vger.kernel.org, linux-input@vger.kernel.org,
	Won Chung <wonchung@google.com>, Len Brown <lenb@kernel.org>,
	devicetree@vger.kernel.org, Chaitanya Kulkarni <kch@nvidia.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Ming Lei <ming.lei@redhat.com>, Mark Gross <markgross@kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Jilin Yuan <yuanjilin@cdjrlc.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-kernel@vger.kernel.org, Wolfram Sang <wsa@kernel.org>,
	Vinod Koul <vkoul@kernel.org>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	Sanyog Kale <sanyog.r.kale@intel.com>,
	linux-media@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH 3/5] driver core: make struct device_type.uevent() take a const *
Date: Wed, 23 Nov 2022 14:59:00 +0100	[thread overview]
Message-ID: <97be39ed-3cea-d55a-caa6-c2652baef399@gmail.com> (raw)
In-Reply-To: <Y34hgIW8p1RlQTBB@smile.fi.intel.com>

On 11/23/22 14:34, Andy Shevchenko wrote:
> On Wed, Nov 23, 2022 at 02:14:31PM +0100, Maximilian Luz wrote:
>> On 11/23/22 13:25, Greg Kroah-Hartman wrote:
>>> The uevent() callback in struct device_type should not be modifying the
>>> device that is passed into it, so mark it as a const * and propagate the
>>> function signature changes out into all relevant subsystems that use
>>> this callback.
> 
> [...]
> 
>>> -static inline struct ssam_device *to_ssam_device(struct device *d)
>>> +static inline struct ssam_device *to_ssam_device(const struct device *d)
>>>    {
>>>    	return container_of(d, struct ssam_device, dev);
>>>    }
>>
>> I am slightly conflicted about this change as that now more or less
>> implicitly drops the const. So I'm wondering if it wouldn't be better to
>> either create a function specifically for const pointers or to just
>> open-code it in the instance above.
>>
>> I guess we could also convert this to a macro. Then at least there
>> wouldn't be an explicit and potentially misleading const-conversion
>> indicated in the function signature.
> 
> This is an intermediate step as far as I know since moving container_of to
> recognize const is a bit noisy right now. I guess you can find a discussion
> on the topic between Greg and Sakari.

Thanks! I assume you are referring to the following?

	https://lore.kernel.org/lkml/4218173bd72b4f1899d4c41a8e251f0d@AcuMS.aculab.com/T/

As far as I can tell this is only a warning in documentation, not
compile time (which would probably be impossible?).

As I've said I'd be fine with converting the function to a macro (and
preferably adding a similar warning like the one proposed in that
thread). The point that irks me up is just that, as proposed, the
function signature would now advertise a conversion that should never be
happening.

Having two separate functions would create a compile-time guarantee, so
I'd prefer that, but I can understand if that might be considered too
noisy in code. Or if there is a push to make container_of() emit a
compile-time warning I'd also be perfectly happy with converting it to a
macro now as that'd alleviate the need for functions in the future.

Regards,
Max


  reply	other threads:[~2022-11-23 14:04 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-23 12:25 [PATCH 1/5] driver core: make struct class.dev_uevent() take a const * Greg Kroah-Hartman
2022-11-23 12:25 ` [PATCH 2/5] driver core: make struct class.devnode() " Greg Kroah-Hartman
2022-11-23 12:25   ` Greg Kroah-Hartman
2022-11-23 12:25   ` Greg Kroah-Hartman
2022-11-23 12:25   ` Greg Kroah-Hartman
2022-11-25 11:55   ` Mauro Carvalho Chehab
2022-11-25 11:55     ` Mauro Carvalho Chehab
2022-11-25 11:55     ` Mauro Carvalho Chehab
2022-11-25 12:40     ` Sumit Semwal
2022-11-25 12:40       ` Sumit Semwal
2022-11-25 12:40       ` Sumit Semwal
2022-11-23 12:25 ` [PATCH 3/5] driver core: make struct device_type.uevent() " Greg Kroah-Hartman
2022-11-23 12:25   ` Greg Kroah-Hartman
2022-11-23 12:25   ` Greg Kroah-Hartman
2022-11-23 12:38   ` Rafael J. Wysocki
2022-11-23 12:38     ` Rafael J. Wysocki
2022-11-23 12:38     ` Rafael J. Wysocki
2023-01-11  9:51     ` Greg Kroah-Hartman
2023-01-11  9:51       ` Greg Kroah-Hartman
2023-01-11  9:51       ` Greg Kroah-Hartman
2022-11-23 13:14   ` Maximilian Luz
2022-11-23 13:14     ` Maximilian Luz
2022-11-23 13:14     ` Maximilian Luz
2022-11-23 13:34     ` Andy Shevchenko
2022-11-23 13:34       ` Andy Shevchenko
2022-11-23 13:34       ` Andy Shevchenko
2022-11-23 13:59       ` Maximilian Luz [this message]
2022-11-23 13:59         ` Maximilian Luz
2022-11-23 13:59         ` Maximilian Luz
2022-11-23 14:52         ` Matthew Wilcox
2022-11-23 14:52           ` Matthew Wilcox
2022-11-23 14:52           ` Matthew Wilcox
2022-11-23 15:14           ` Maximilian Luz
2022-11-23 15:14             ` Maximilian Luz
2022-11-23 15:14             ` Maximilian Luz
2022-11-23 15:37           ` Greg Kroah-Hartman
2022-11-23 15:37             ` Greg Kroah-Hartman
2022-11-23 15:37             ` Greg Kroah-Hartman
2022-11-23 15:48             ` Maximilian Luz
2022-11-23 15:48               ` Maximilian Luz
2022-11-23 15:48               ` Maximilian Luz
2022-11-23 15:52               ` Greg Kroah-Hartman
2022-11-23 15:52                 ` Greg Kroah-Hartman
2022-11-23 15:52                 ` Greg Kroah-Hartman
2022-11-23 16:25             ` Jason Gunthorpe
2022-11-23 16:25               ` Jason Gunthorpe
2022-11-23 16:25               ` Jason Gunthorpe
2022-11-23 17:01               ` Greg Kroah-Hartman
2022-11-23 17:01                 ` Greg Kroah-Hartman
2022-11-23 17:01                 ` Greg Kroah-Hartman
2022-11-23 17:29                 ` Jason Gunthorpe
2022-11-23 17:29                   ` Jason Gunthorpe
2022-11-23 17:29                   ` Jason Gunthorpe
2022-11-23 17:49                   ` Matthew Wilcox
2022-11-23 17:49                     ` Matthew Wilcox
2022-11-23 17:49                     ` Matthew Wilcox
2022-11-23 17:55                     ` Jason Gunthorpe
2022-11-23 17:55                       ` Jason Gunthorpe
2022-11-23 17:55                       ` Jason Gunthorpe
2022-11-23 18:00                       ` Matthew Wilcox
2022-11-23 18:00                         ` Matthew Wilcox
2022-11-23 18:00                         ` Matthew Wilcox
2022-12-01 18:43                         ` Greg Kroah-Hartman
2022-12-01 18:43                           ` Greg Kroah-Hartman
2022-12-01 18:43                           ` Greg Kroah-Hartman
2022-11-23 18:10                     ` Greg Kroah-Hartman
2022-11-23 18:10                       ` Greg Kroah-Hartman
2022-11-23 18:10                       ` Greg Kroah-Hartman
2022-11-23 18:25                       ` Jason Gunthorpe
2022-11-23 18:25                         ` Jason Gunthorpe
2022-11-23 18:25                         ` Jason Gunthorpe
2022-11-23 19:06                         ` Greg Kroah-Hartman
2022-11-23 19:06                           ` Greg Kroah-Hartman
2022-11-23 19:06                           ` Greg Kroah-Hartman
2022-11-23 23:24                           ` Barnabás Pőcze
2022-11-23 23:24                             ` Barnabás Pőcze
2022-11-23 23:24                             ` Barnabás Pőcze
2022-11-23 13:56   ` Mika Westerberg
2022-11-23 13:56     ` Mika Westerberg
2022-11-23 13:56     ` Mika Westerberg
2023-01-11  9:52     ` Greg Kroah-Hartman
2023-01-11  9:52       ` Greg Kroah-Hartman
2023-01-11  9:52       ` Greg Kroah-Hartman
2022-11-25 11:56   ` Mauro Carvalho Chehab
2022-11-25 11:56     ` Mauro Carvalho Chehab
2022-11-25 11:56     ` Mauro Carvalho Chehab
2023-01-11  9:52     ` Greg Kroah-Hartman
2023-01-11  9:52       ` Greg Kroah-Hartman
2023-01-11  9:52       ` Greg Kroah-Hartman
2022-11-23 12:25 ` [PATCH 4/5] driver core: make struct device_type.devnode() " Greg Kroah-Hartman
2022-11-23 19:23   ` Dan Williams
2023-01-11  9:46     ` Greg Kroah-Hartman
2022-11-23 12:25 ` [PATCH 5/5] driver core: device_get_devnode() should " Greg Kroah-Hartman
2022-11-23 12:39   ` Rafael J. Wysocki
2022-11-23 13:36   ` Andy Shevchenko
2023-01-11  9:47     ` Greg Kroah-Hartman
2022-11-23 12:38 ` [PATCH 1/5] driver core: make struct class.dev_uevent() " Rafael J. Wysocki
2022-11-24 15:03 ` Sebastian Reichel
2022-11-25 11:54 ` Mauro Carvalho Chehab
2022-11-25 23:51 ` Bart Van Assche
2022-11-27 13:45   ` Greg Kroah-Hartman
2022-11-28  2:38     ` Bart Van Assche
2022-11-28 17:25       ` Greg Kroah-Hartman

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=97be39ed-3cea-d55a-caa6-c2652baef399@gmail.com \
    --to=luzmaximilian@gmail.com \
    --cc=YehezkelShB@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andreas.noever@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=ira.weiny@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=jirislaby@kernel.org \
    --cc=kch@nvidia.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=markgross@kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mchehab@kernel.org \
    --cc=michael.jamet@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=ming.lei@redhat.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=sean@mess.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=vkoul@kernel.org \
    --cc=willy@infradead.org \
    --cc=wonchung@google.com \
    --cc=wsa@kernel.org \
    --cc=yuanjilin@cdjrlc.com \
    --cc=yung-chuan.liao@linux.intel.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.