[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2UnhZf5/HkY6vwm@kroah.com>
Date: Fri, 4 Nov 2022 15:53:57 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
davem@...emloft.net, linux-can@...r.kernel.org,
kernel@...gutronix.de
Subject: Re: [PATCH net-next 0/14] pull-request: can-next 2022-10-31
On Fri, Nov 04, 2022 at 02:08:57PM +0100, Marc Kleine-Budde wrote:
> On 01.11.2022 06:06:13, Greg Kroah-Hartman wrote:
> > Also, the line:
> >
> > + .attrs = (struct attribute **)peak_usb_sysfs_attrs,
> >
> > Is odd, there should never be a need to cast anything like this if you
> > are doing things properly.
>
> After marking the struct attribute not as const, we can remove the cast:
>
> | --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> | +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> | @@ -64,14 +64,14 @@ static ssize_t user_devid_show(struct device *dev, struct device_attribute *attr
> | }
> | static DEVICE_ATTR_RO(user_devid);
> |
> | -static const struct attribute *peak_usb_sysfs_attrs[] = {
> | +static struct attribute *peak_usb_sysfs_attrs[] = {
Ah. Yeah, I would love to make this a const pointer, but people do some
pretty crazy dynamic stuff with attribute groups at times, so that it
will not always work.
I have a long series of patches I'm working on that add more const
markings to the kobject and then the driver core apis, I'll add this
type of thing to the idea list as what to work on next.
thanks,
greg k-h
Powered by blists - more mailing lists