From: Menna Mahmoud <eng.mennamahmoud.mm@gmail.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: gregkh@linuxfoundation.org, outreachy@lists.linux.dev,
johan@kernel.org, elder@kernel.org, linux-kernel@vger.kernel.org,
linux-staging@lists.linux.dev
Subject: Re: [PATCH] staging: greybus: use inline function for macros
Date: Mon, 20 Mar 2023 00:00:46 +0200 [thread overview]
Message-ID: <649afe06-e069-e046-21ec-0d86243a4bfa@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2303192225590.2867@hadrien>
On ١٩/٣/٢٠٢٣ ٢٣:٢٦, Julia Lawall wrote:
>
> On Sun, 19 Mar 2023, Menna Mahmoud wrote:
>
>> On ١٩/٣/٢٠٢٣ ٢٢:٥٥, Julia Lawall wrote:
>>> On Sun, 19 Mar 2023, Menna Mahmoud wrote:
>>>
>>>> On ١٩/٣/٢٠٢٣ ٢٢:٢١, Julia Lawall wrote:
>>>>> On Sun, 19 Mar 2023, Menna Mahmoud wrote:
>>>>>
>>>>>> Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
>>>>>> static inline functions.
>>>>>>
>>>>>> it is not great to have macro that use `container_of` macro,
>>>>>> because from looking at the definition one cannot tell what type
>>>>>> it applies to.
>>>>>>
>>>>>> One can get the same benefit from an efficiency point of view
>>>>>> by making an inline function.
>>>>>>
>>>>>> Suggested-by: Julia Lawall <julia.lawall@inria.fr>
>>>>>> Signed-off-by: Menna Mahmoud <eng.mennamahmoud.mm@gmail.com>
>>>>>> ---
>>>>>> 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 1de510499480..42c4e3fe307c 100644
>>>>>> --- a/drivers/staging/greybus/gbphy.h
>>>>>> +++ b/drivers/staging/greybus/gbphy.h
>>>>>> @@ -16,7 +16,10 @@ struct gbphy_device {
>>>>>> struct device dev;
>>>>>> };
>>>>>>
>>>>> You have made the patch against your previous patch that added a newline
>>>>> here. It should be against Greg's tree.
>>>>>
>>>>> julia
>>>> you mean I should remove this newline, right?
>>> You should apply your change to the state of Greg's tree, not the state
>>> after your patch.
>>>
>>> Assuming that you have committed both the patch adding the new line and
>>> the patch changing the macro to a function, and have made no other
>>> changes, you can do git rebase -i HEAD~2 and the put a d at the beginning
>>> of the line related to the patch adding the newline.
>>
>> you mean drop this patch "staging: greybus: remove unnecessary blank line"?
> No, the one that removes the blank line looks fine.
>
> At some point, you added a blank line below the two structure definitions.
> That blank line is not in Greg's tree, so you shoulsn't send a patch that
> assumes that it is there.
I'm sorry I mean this patch "staging: greybus: add blank line after
struct", Julia I understood the issue
but I am confused about how to fix it, should I drop the patch that
added the newline? then what should I do?
and version that I have submitted, should I do anything about it as you
said it is wrong solution?
Menna
> julia
>
>> Menna
>>
>>
>>> If you have made
>>> more changes, you can adapt the HEAD~ part accordingly.
>>>
>>> julia
>>>
>>>
>>>> Menna
>>>>
>>>>>> -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
>>>>>> +static inline struct gbphy_device *to_gbphy_dev(const struct device
>>>>>> *d)
>>>>>> +{
>>>>>> + return container_of(d, struct gbphy_device, dev);
>>>>>> +}
>>>>>>
>>>>>> static inline void *gb_gbphy_get_data(struct gbphy_device *gdev)
>>>>>> {
>>>>>> @@ -45,7 +48,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
>>>>>> *d)
>>>>>> +{
>>>>>> + return container_of(d, struct gbphy_driver, driver);
>>>>>> +}
>>>>>>
>>>>>> int gb_gbphy_register_driver(struct gbphy_driver *driver,
>>>>>> struct module *owner, const char
>>>>>> *mod_name);
>>>>>> --
>>>>>> 2.34.1
>>>>>>
>>>>>>
> >
next prev parent reply other threads:[~2023-03-19 22:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-19 20:13 [PATCH] staging: greybus: use inline function for macros Menna Mahmoud
2023-03-19 20:21 ` Julia Lawall
2023-03-19 20:42 ` Menna Mahmoud
2023-03-19 20:55 ` Julia Lawall
2023-03-19 21:07 ` Menna Mahmoud
2023-03-19 21:26 ` Julia Lawall
2023-03-19 22:00 ` Menna Mahmoud [this message]
2023-03-19 22:06 ` Julia Lawall
2023-03-19 22:17 ` Menna Mahmoud
2023-03-20 6:00 ` Julia Lawall
2023-03-20 10:14 ` Menna Mahmoud
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=649afe06-e069-e046-21ec-0d86243a4bfa@gmail.com \
--to=eng.mennamahmoud.mm@gmail.com \
--cc=elder@kernel.org \
--cc=gregkh@linuxfoundation.org \
--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.