All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Menna Mahmoud <eng.mennamahmoud.mm@gmail.com>
Cc: outreachy@lists.linux.dev, johan@kernel.org, elder@kernel.org,
	linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev,
	Julia Lawall <julia.lawall@inria.fr>
Subject: Re: [PATCH v2] staging: greybus: use inline function for macros
Date: Wed, 22 Mar 2023 10:13:37 +0100	[thread overview]
Message-ID: <ZBrGwZK5YA+hMVM4@kroah.com> (raw)
In-Reply-To: <20230321183456.10385-1-eng.mennamahmoud.mm@gmail.com>

On Tue, Mar 21, 2023 at 08:34:56PM +0200, Menna Mahmoud wrote:
> Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> static inline function.
> 
> It is not great to have macros that use the `container_of` macro,
> because from looking at the definition one cannot tell what type
> it applies to.

Note, the compiler will tell you if you get this wrong, so this really
is not an issue.

The container_of() macro is "special" in that it is very type safe and
is very commonly used just as a #define to make it simpler and the
compiler can just do the pointer math automatically without ever needing
a function call to be involved.

> One can get the same benefit from an efficiency point of view
> by making an inline function.

It's actually more efficient to be a macro, so this isn't correct.

But all of this is really moot, and I would normally just take this
patch, but it's not correct:

> 
> Suggested-by: Julia Lawall <julia.lawall@inria.fr>
> Signed-off-by: Menna Mahmoud <eng.mennamahmoud.mm@gmail.com>
> ---
> changes in v2:
> 	-send patch as a single patch.
> 	-edit the name of struct object.
> 	-edit commit message.
> ---
>  drivers/staging/greybus/gbphy.h | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/greybus/gbphy.h b/drivers/staging/greybus/gbphy.h
> index d4a225b76338..e7ba232bada1 100644
> --- a/drivers/staging/greybus/gbphy.h
> +++ b/drivers/staging/greybus/gbphy.h
> @@ -15,7 +15,10 @@ struct gbphy_device {
>  	struct list_head list;
>  	struct device dev;
>  };
> -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> +static inline struct gbphy_device *to_gbphy_dev(const struct device *_dev)
> +{
> +	return container_of(_dev, struct gbphy_device, dev);
> +}

You need a newline right before your new function to properly set it
off.


>  
>  static inline void *gb_gbphy_get_data(struct gbphy_device *gdev)
>  {
> @@ -43,7 +46,10 @@ struct gbphy_driver {
>  
>  	struct device_driver driver;
>  };
> -#define to_gbphy_driver(d) container_of(d, struct gbphy_driver, driver)
> +static inline struct gbphy_driver *to_gbphy_driver(struct device_driver *drv)
> +{
> +	return container_of(drv, struct gbphy_driver, driver);
> +}

I'm going to be a stickler here, and say this really should be using the
new container_of_const() macro instead, and with that, you can NOT turn
it into an inline function at all due to the fun use of Generic in that
macro.

So I wouldn't recommend changing this macro at this time at all, sorry.

thanks,

greg k-h

  parent reply	other threads:[~2023-03-22  9:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 18:34 [PATCH v2] staging: greybus: use inline function for macros Menna Mahmoud
2023-03-21 18:50 ` Alex Elder
2023-03-21 20:43   ` Julia Lawall
2023-03-21 21:09     ` Alex Elder
2023-03-21 21:29       ` Julia Lawall
2023-03-21 22:42         ` Alex Elder
2023-03-22 10:00           ` Julia Lawall
2023-03-22 12:39             ` Alex Elder
2023-03-23  4:58             ` Greg KH
2023-03-23  5:05               ` Deepak R Varma
2023-03-23  5:22                 ` Greg KH
2023-03-23 19:46                   ` Deepak R Varma
2023-03-23  9:52               ` Julia Lawall
2023-03-25  8:49                 ` Greg KH
2023-03-25  9:28                   ` Julia Lawall
2023-03-22  9:13 ` Greg KH [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-03-19 20:49 Menna Mahmoud
2023-03-19 20:56 ` Julia Lawall

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=ZBrGwZK5YA+hMVM4@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=elder@kernel.org \
    --cc=eng.mennamahmoud.mm@gmail.com \
    --cc=johan@kernel.org \
    --cc=julia.lawall@inria.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=outreachy@lists.linux.dev \
    /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.