[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4Tu9UUGGiEdFcVw@kroah.com>
Date: Mon, 28 Nov 2022 18:25:09 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Bart Van Assche <bvanassche@....org>
Cc: linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
Luis Chamberlain <mcgrof@...nel.org>,
Russ Weight <russell.h.weight@...el.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Jean Delvare <jdelvare@...e.com>,
Johan Hovold <johan@...nel.org>,
Jason Gunthorpe <jgg@...pe.ca>,
Leon Romanovsky <leon@...nel.org>,
Karsten Keil <isdn@...ux-pingi.de>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Keith Busch <kbusch@...nel.org>,
Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Sebastian Reichel <sre@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Johannes Berg <johannes@...solutions.net>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Raed Salem <raeds@...dia.com>,
Chen Zhongjin <chenzhongjin@...wei.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Avihai Horon <avihaih@...dia.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Alan Stern <stern@...land.harvard.edu>,
Colin Ian King <colin.i.king@...il.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Jakob Koschel <jakobkoschel@...il.com>,
Antoine Tenart <atenart@...nel.org>,
Frederic Weisbecker <frederic@...nel.org>,
Wang Yufen <wangyufen@...wei.com>, linux-block@...r.kernel.org,
linux-media@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-pm@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-usb@...r.kernel.org, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH 1/5] driver core: make struct class.dev_uevent() take a
const *
On Sun, Nov 27, 2022 at 06:38:39PM -0800, Bart Van Assche wrote:
> On 11/27/22 05:45, Greg Kroah-Hartman wrote:
> > On Fri, Nov 25, 2022 at 03:51:11PM -0800, Bart Van Assche wrote:
> > > On 11/23/22 04:25, Greg Kroah-Hartman wrote:
> > > > diff --git a/include/linux/mISDNif.h b/include/linux/mISDNif.h
> > > > index 7dd1f01ec4f9..7aab4a769736 100644
> > > > --- a/include/linux/mISDNif.h
> > > > +++ b/include/linux/mISDNif.h
> > > > @@ -586,7 +586,7 @@ extern struct mISDNclock *mISDN_register_clock(char *, int, clockctl_func_t *,
> > > > void *);
> > > > extern void mISDN_unregister_clock(struct mISDNclock *);
> > > > -static inline struct mISDNdevice *dev_to_mISDN(struct device *dev)
> > > > +static inline struct mISDNdevice *dev_to_mISDN(const struct device *dev)
> > > > {
> > > > if (dev)
> > > > return dev_get_drvdata(dev);
> > >
> > > Why does the dev_to_mISDN() function drop constness? I haven't found an
> > > explanation for this in the cover letter.
> >
> > I agree, this is going to be fixed up, see the thread starting here:
> > https://lore.kernel.org/r/Y34+V2bCDdqujBDk@kroah.com
> >
> > I'll work on making a const / non const version for these so that we
> > don't loose the marking.
> >
> > Oh wait, no, this function is fine, it's not modifying the device
> > structure at all, and only returning the pointer in the private data
> > stored in the device. There is no loss of const-ness here.
>
> Hi Greg,
>
> This is what I found in include/linux/mISDNif.h:
>
> struct mISDNdevice {
> struct mISDNchannel D;
> u_int id;
> u_int Dprotocols;
> u_int Bprotocols;
> u_int nrbchan;
> u_char channelmap[MISDN_CHMAP_SIZE];
> struct list_head bchannels;
> struct mISDNchannel *teimgr;
> struct device dev;
> };
>
> As one can see 'dev' is a member of struct mISDNdevice. I still think that
> dev_to_mISDN() drops constness. Did I perhaps overlook something?
I think you are missing that dev_to_mISDN() is doing something different
than most dev_to_FOO() functions do (i.e. there is no container_of()
call here at all):
static inline struct mISDNdevice *dev_to_mISDN(struct device *dev)
{
if (dev)
return dev_get_drvdata(dev);
else
return NULL;
}
See, no pointer mess or anything else here, all that happens is the
driver data pointer in struct device is returned.
If this was a "normal" dev_to_FOO() function, then yes, the const-ness
of the pointer would be called into question as the thread I linked to
discusses.
thanks,
greg k-h
Powered by blists - more mailing lists