All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Maximilian Luz <luzmaximilian@gmail.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 15:34:56 +0200	[thread overview]
Message-ID: <Y34hgIW8p1RlQTBB@smile.fi.intel.com> (raw)
In-Reply-To: <711d5275-7e80-c00d-0cdc-0f3d52175361@gmail.com>

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.

-- 
With Best Regards,
Andy Shevchenko



WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Maximilian Luz <luzmaximilian@gmail.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 15:34:56 +0200	[thread overview]
Message-ID: <Y34hgIW8p1RlQTBB@smile.fi.intel.com> (raw)
In-Reply-To: <711d5275-7e80-c00d-0cdc-0f3d52175361@gmail.com>

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.

-- 
With Best Regards,
Andy Shevchenko



-- 
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: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Maximilian Luz <luzmaximilian@gmail.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 15:34:56 +0200	[thread overview]
Message-ID: <Y34hgIW8p1RlQTBB@smile.fi.intel.com> (raw)
In-Reply-To: <711d5275-7e80-c00d-0cdc-0f3d52175361@gmail.com>

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.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-11-23 13:46 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 [this message]
2022-11-23 13:34       ` Andy Shevchenko
2022-11-23 13:34       ` Andy Shevchenko
2022-11-23 13:59       ` Maximilian Luz
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=Y34hgIW8p1RlQTBB@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=YehezkelShB@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andreas.noever@gmail.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=luzmaximilian@gmail.com \
    --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.