* [PATCH] staging: greybus: use inline function for macros @ 2023-03-19 20:13 Menna Mahmoud 2023-03-19 20:21 ` Julia Lawall 0 siblings, 1 reply; 11+ messages in thread From: Menna Mahmoud @ 2023-03-19 20:13 UTC (permalink / raw) To: gregkh Cc: outreachy, johan, elder, linux-kernel, linux-staging, eng.mennamahmoud.mm, Julia Lawall 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; }; -#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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 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 0 siblings, 1 reply; 11+ messages in thread From: Julia Lawall @ 2023-03-19 20:21 UTC (permalink / raw) To: Menna Mahmoud Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging, Julia Lawall 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 > -#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 > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 20:21 ` Julia Lawall @ 2023-03-19 20:42 ` Menna Mahmoud 2023-03-19 20:55 ` Julia Lawall 0 siblings, 1 reply; 11+ messages in thread From: Menna Mahmoud @ 2023-03-19 20:42 UTC (permalink / raw) To: Julia Lawall; +Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging 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? 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 >> >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 20:42 ` Menna Mahmoud @ 2023-03-19 20:55 ` Julia Lawall 2023-03-19 21:07 ` Menna Mahmoud 0 siblings, 1 reply; 11+ messages in thread From: Julia Lawall @ 2023-03-19 20:55 UTC (permalink / raw) To: Menna Mahmoud Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging [-- Attachment #1: Type: text/plain, Size: 2579 bytes --] 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. 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 > > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 20:55 ` Julia Lawall @ 2023-03-19 21:07 ` Menna Mahmoud 2023-03-19 21:26 ` Julia Lawall 0 siblings, 1 reply; 11+ messages in thread From: Menna Mahmoud @ 2023-03-19 21:07 UTC (permalink / raw) To: Julia Lawall; +Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging 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"? 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 >>>> >>>> > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 21:07 ` Menna Mahmoud @ 2023-03-19 21:26 ` Julia Lawall 2023-03-19 22:00 ` Menna Mahmoud 0 siblings, 1 reply; 11+ messages in thread From: Julia Lawall @ 2023-03-19 21:26 UTC (permalink / raw) To: Menna Mahmoud Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging [-- Attachment #1: Type: text/plain, Size: 3353 bytes --] 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. 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 > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 21:26 ` Julia Lawall @ 2023-03-19 22:00 ` Menna Mahmoud 2023-03-19 22:06 ` Julia Lawall 0 siblings, 1 reply; 11+ messages in thread From: Menna Mahmoud @ 2023-03-19 22:00 UTC (permalink / raw) To: Julia Lawall; +Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging 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 >>>>>> >>>>>> > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 22:00 ` Menna Mahmoud @ 2023-03-19 22:06 ` Julia Lawall 2023-03-19 22:17 ` Menna Mahmoud 0 siblings, 1 reply; 11+ messages in thread From: Julia Lawall @ 2023-03-19 22:06 UTC (permalink / raw) To: Menna Mahmoud Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging [-- Attachment #1: Type: text/plain, Size: 4660 bytes --] On Mon, 20 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: > > > > > > > > > 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? If the git rebase solution is not clear to you, then another simple solution is just to clone Greg's tree again somewhere else, and make your changes. > and version that I have submitted, should I do anything about it as you said > it is wrong solution? My concern was the blank line after each of the structure definitions, which is not in Greg's tree, so he can't apply the patch. Other than that, if the code compiles it is at least going in the right direction. Please fix the newlines issue, and then send the patch again. julia > > > 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 > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 22:06 ` Julia Lawall @ 2023-03-19 22:17 ` Menna Mahmoud 2023-03-20 6:00 ` Julia Lawall 0 siblings, 1 reply; 11+ messages in thread From: Menna Mahmoud @ 2023-03-19 22:17 UTC (permalink / raw) To: Julia Lawall; +Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging On ٢٠/٣/٢٠٢٣ ٠٠:٠٦, Julia Lawall wrote: > > On Mon, 20 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: >>>>> >>>>>> 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? > If the git rebase solution is not clear to you, then another simple > solution is just to clone Greg's tree again somewhere else, and make your > changes. > >> and version that I have submitted, should I do anything about it as you said >> it is wrong solution? > My concern was the blank line after each of the structure definitions, > which is not in Greg's tree, so he can't apply the patch. Other than > that, if the code compiles it is at least going in the right direction. > > Please fix the newlines issue, and then send the patch again. > > julia Okay I will fix it, but will send it as a new patch not v3, right? Menna > >> >> 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 >>>>>>>> >>>>>>>> > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-19 22:17 ` Menna Mahmoud @ 2023-03-20 6:00 ` Julia Lawall 2023-03-20 10:14 ` Menna Mahmoud 0 siblings, 1 reply; 11+ messages in thread From: Julia Lawall @ 2023-03-20 6:00 UTC (permalink / raw) To: Menna Mahmoud Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging > > > and version that I have submitted, should I do anything about it as you > > > said > > > it is wrong solution? > > My concern was the blank line after each of the structure definitions, > > which is not in Greg's tree, so he can't apply the patch. Other than > > that, if the code compiles it is at least going in the right direction. > > > > Please fix the newlines issue, and then send the patch again. > > > > julia > > > Okay I will fix it, but will send it as a new patch not v3, right? Why as a new patch? The change is the same as in v2, and sending v3 makes it clear that v2 should be ignored. julia ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] staging: greybus: use inline function for macros 2023-03-20 6:00 ` Julia Lawall @ 2023-03-20 10:14 ` Menna Mahmoud 0 siblings, 0 replies; 11+ messages in thread From: Menna Mahmoud @ 2023-03-20 10:14 UTC (permalink / raw) To: Julia Lawall; +Cc: gregkh, outreachy, johan, elder, linux-kernel, linux-staging On ٢٠/٣/٢٠٢٣ ٠٨:٠٠, Julia Lawall wrote: >>>> and version that I have submitted, should I do anything about it as you >>>> said >>>> it is wrong solution? >>> My concern was the blank line after each of the structure definitions, >>> which is not in Greg's tree, so he can't apply the patch. Other than >>> that, if the code compiles it is at least going in the right direction. >>> >>> Please fix the newlines issue, and then send the patch again. >>> >>> julia >> >> Okay I will fix it, but will send it as a new patch not v3, right? > Why as a new patch? The change is the same as in v2, and sending v3 makes > it clear that v2 should be ignored. > > julia Okay, thanks. Menna ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-03-20 10:14 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox