[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ymj8LWUgk6X/Alze@kuha.fi.intel.com>
Date: Wed, 27 Apr 2022 11:17:49 +0300
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Benson Leung <bleung@...gle.com>,
Prashant Malani <pmalani@...omium.org>,
Jameson Thies <jthies@...gle.com>,
"Regupathy, Rajaram" <rajaram.regupathy@...el.com>,
Guenter Roeck <linux@...ck-us.net>,
Won Chung <wonchung@...gle.com>, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] usb: typec: Separate USB Power Delivery from USB
Type-C
On Wed, Apr 27, 2022 at 09:30:30AM +0200, Greg Kroah-Hartman wrote:
> > > "struct pd" is just about the shortest structure name I've seen in the
> > > kernel so far. How about using some more letters? :)
> >
> > Okay, I'll make it usbpd.
>
> How about some more vowels: "struct usb_power_delivery" please. This
> isn't the 1980's :)
"struct usb_power_delivery" is fine, but I would still really really
want to use "struct usbpd_capabilities" instead of
"struct usb_power_delivery_capabilities" - it's just too long.
Is that okay?
> > > > +
> > > > +int pd_init(void);
> > > > +void pd_exit(void);
> > >
> > > The kobject question above goes to the code as well. You are creating a
> > > bunch of raw kobjects still, why? This should all fit into the driver
> > > model and kobjects shouldn't be needed. Are you trying to nest too deep
> > > in the attributes? If so, kobjects will not work as userspace tools
> > > will not realize they are there and are attributes at all.
> >
> > They are not raw kobjects, they are all devices now. That header just
> > needs to be fixed.
>
> You have loads of kobject attributes in the .c file. Either I read it
> wrong, or you are doing something wrong, as that should never be the
> case for a driver or device.
Hmm, I'm probable still doing something wrong...
thanks,
--
heikki
Powered by blists - more mailing lists