This patchset includes change happened in greybus driver in three
different files two of them patch one and three related to
checkpatch issue and in second patch convert two
`container_of` macros into inline functions.
Menna Mahmoud (3):
staging: greybus: remove unnecessary blank line
staging: greybus: use inline function for macros
staging: greybus: remove unnecessary blank line
drivers/staging/greybus/gbphy.h | 10 ++++++++--
drivers/staging/greybus/greybus_authentication.h | 1 -
drivers/staging/greybus/pwm.c | 1 -
3 files changed, 8 insertions(+), 4 deletions(-)
--
2.34.1
Remove unnecessary blank line before struct as reported
by checkpatch:
" CHECK: Please don't use multiple blank lines "
Signed-off-by: Menna Mahmoud <[email protected]>
---
drivers/staging/greybus/greybus_authentication.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/greybus/greybus_authentication.h b/drivers/staging/greybus/greybus_authentication.h
index 7edc7295b7ab..48b4a9794d3c 100644
--- a/drivers/staging/greybus/greybus_authentication.h
+++ b/drivers/staging/greybus/greybus_authentication.h
@@ -41,7 +41,6 @@
#define CAP_AUTH_RESULT_CR_NO_KEY 0x03
#define CAP_AUTH_RESULT_CR_SIG_FAIL 0x04
-
/* IOCTL support */
struct cap_ioc_get_endpoint_uid {
__u8 uid[8];
--
2.34.1
Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
static inline function.
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 <[email protected]>
Signed-off-by: Menna Mahmoud <[email protected]>
---
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..03a977056637 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 *d)
+{
+ return container_of(d, struct gbphy_device, dev);
+}
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 *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
Remove unnecessary blank line before struct as reported
by checkpatch:
" CHECK: Please don't use multiple blank lines "
Signed-off-by: Menna Mahmoud <[email protected]>
---
drivers/staging/greybus/pwm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/greybus/pwm.c b/drivers/staging/greybus/pwm.c
index 3fda172239d2..26d39e08c3b6 100644
--- a/drivers/staging/greybus/pwm.c
+++ b/drivers/staging/greybus/pwm.c
@@ -24,7 +24,6 @@ struct gb_pwm_chip {
#define pwm_chip_to_gb_pwm_chip(chip) \
container_of(chip, struct gb_pwm_chip, chip)
-
static int gb_pwm_count_operation(struct gb_pwm_chip *pwmc)
{
struct gb_pwm_count_response response;
--
2.34.1
On Tue, 21 Mar 2023, Menna Mahmoud wrote:
> This patchset includes change happened in greybus driver in three
> different files two of them patch one and three related to
> checkpatch issue and in second patch convert two
> `container_of` macros into inline functions.
>
> Menna Mahmoud (3):
> staging: greybus: remove unnecessary blank line
> staging: greybus: use inline function for macros
> staging: greybus: remove unnecessary blank line
Different patches should have different subject lines. You need to either
be more specific about the file affected or merge the two patches with the
same subject into one.
julia
>
> drivers/staging/greybus/gbphy.h | 10 ++++++++--
> drivers/staging/greybus/greybus_authentication.h | 1 -
> drivers/staging/greybus/pwm.c | 1 -
> 3 files changed, 8 insertions(+), 4 deletions(-)
>
> --
> 2.34.1
>
>
>
Hello,
just some nitpicks:
On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
> Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> static inline function.
>
> it is not great to have macro that use `container_of` macro,
s/it/It/; s/macro/macros/; s/use/use the/;
> because from looking at the definition one cannot tell what type
> it applies to.
> [...]
> -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
drivers/staging/greybus/gbphy.c always passes a variable named
"dev" to this macro. So I'd call the parameter "dev", too, instead of
"d". This is also a more typical name for variables of that type.
> +{
> + return container_of(d, struct gbphy_device, dev);
> +}
> [...]
> };
> -#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);
> +}
With a similar reasoning (and also to not have "d"s that are either
device or device_driver) I'd recommend "drv" here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Tue, 21 Mar 2023, Uwe Kleine-K?nig wrote:
> Hello,
>
> just some nitpicks:
>
> On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
> > Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> > static inline function.
> >
> > it is not great to have macro that use `container_of` macro,
>
> s/it/It/; s/macro/macros/; s/use/use the/;
>
> > because from looking at the definition one cannot tell what type
> > it applies to.
> > [...]
> > -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> > +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
>
> drivers/staging/greybus/gbphy.c always passes a variable named
> "dev" to this macro. So I'd call the parameter "dev", too, instead of
> "d". This is also a more typical name for variables of that type.
I argued against that. Because then there are two uses of dev
in the argument of container_of, and they refer to completely different
things. It's true that by the way container_of works, it's fine, but it
may be misleading.
julia
>
> > +{
> > + return container_of(d, struct gbphy_device, dev);
> > +}
> > [...]
> > };
> > -#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);
> > +}
>
> With a similar reasoning (and also to not have "d"s that are either
> device or device_driver) I'd recommend "drv" here.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | https://www.pengutronix.de/ |
>
On ٢١/٣/٢٠٢٣ ١٣:٤٦, Julia Lawall wrote:
>
> On Tue, 21 Mar 2023, Menna Mahmoud wrote:
>
>> This patchset includes change happened in greybus driver in three
>> different files two of them patch one and three related to
>> checkpatch issue and in second patch convert two
>> `container_of` macros into inline functions.
>>
>> Menna Mahmoud (3):
>> staging: greybus: remove unnecessary blank line
>> staging: greybus: use inline function for macros
>> staging: greybus: remove unnecessary blank line
> Different patches should have different subject lines.
But I have already the same edit in both file, so should I re-write the
subject for one of them?
> You need to either
> be more specific about the file affected or merge the two patches with the
> same subject into one.
each patch related to different file. So, Can I to merge two commits for
different files but have the same edit in one patch?
but in this case no need to create patchset for all changes in `greybus`
driver, right?
If okay with that, should I versioning the patches to resend them again,
or should add "RESEND" subject prefix?
please tell me the best way to resend these patches, appreciate your help.
Menna
>
> julia
>
>> drivers/staging/greybus/gbphy.h | 10 ++++++++--
>> drivers/staging/greybus/greybus_authentication.h | 1 -
>> drivers/staging/greybus/pwm.c | 1 -
>> 3 files changed, 8 insertions(+), 4 deletions(-)
>>
>> --
>> 2.34.1
>>
>>
>>
On ٢١/٣/٢٠٢٣ ١٧:٤٧, Uwe Kleine-König wrote:
> Hello,
>
> just some nitpicks:
>
> On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
>> Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
>> static inline function.
>>
>> it is not great to have macro that use `container_of` macro,
> s/it/It/; s/macro/macros/; s/use/use the/;
Okay, I will fix it.
>
>> because from looking at the definition one cannot tell what type
>> it applies to.
>> [...]
>> -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
>> +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
> drivers/staging/greybus/gbphy.c always passes a variable named
> "dev" to this macro. So I'd call the parameter "dev", too, instead of
> "d". This is also a more typical name for variables of that type.
>
>> +{
>> + return container_of(d, struct gbphy_device, dev);
>> +}
>> [...]
>> };
>> -#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);
>> +}
> With a similar reasoning (and also to not have "d"s that are either
> device or device_driver) I'd recommend "drv" here.
please check this with Julia, because she said they should different.
Thanks,
Menna
>
> Best regards
> Uwe
>
On Tue, Mar 21, 2023 at 06:22:44PM +0200, Menna Mahmoud wrote:
>
> On ٢١/٣/٢٠٢٣ ١٣:٤٦, Julia Lawall wrote:
> >
> > On Tue, 21 Mar 2023, Menna Mahmoud wrote:
> >
> > > This patchset includes change happened in greybus driver in three
> > > different files two of them patch one and three related to
> > > checkpatch issue and in second patch convert two
> > > `container_of` macros into inline functions.
> > >
> > > Menna Mahmoud (3):
> > > staging: greybus: remove unnecessary blank line
> > > staging: greybus: use inline function for macros
> > > staging: greybus: remove unnecessary blank line
> > Different patches should have different subject lines.
> But I have already the same edit in both file, so should I re-write the
> subject for one of them?
> > You need to either
> > be more specific about the file affected or merge the two patches with the
> > same subject into one.
>
> each patch related to different file. So, Can I to merge two commits for
> different files but have the same edit in one patch?
Yes, or make 2 different patches with 2 different subject lines as they
are obviously doing different things.
> but in this case no need to create patchset for all changes in `greybus`
> driver, right?
>
> If okay with that, should I versioning the patches to resend them again, or
> should add "RESEND" subject prefix?
>
> please tell me the best way to resend these patches, appreciate your help.
What would you want to see if you had to review and apply loads of
patches like this?
(hint, it's not a resend, but a new version...)
thanks,
greg k-h
On Tue, Mar 21, 2023 at 04:59:49PM +0100, Julia Lawall wrote:
>
>
> On Tue, 21 Mar 2023, Uwe Kleine-K?nig wrote:
>
> > Hello,
> >
> > just some nitpicks:
> >
> > On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
> > > Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> > > static inline function.
> > >
> > > it is not great to have macro that use `container_of` macro,
> >
> > s/it/It/; s/macro/macros/; s/use/use the/;
> >
> > > because from looking at the definition one cannot tell what type
> > > it applies to.
> > > [...]
> > > -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> > > +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
> >
> > drivers/staging/greybus/gbphy.c always passes a variable named
> > "dev" to this macro. So I'd call the parameter "dev", too, instead of
> > "d". This is also a more typical name for variables of that type.
>
> I argued against that. Because then there are two uses of dev
> in the argument of container_of, and they refer to completely different
> things. It's true that by the way container_of works, it's fine, but it
> may be misleading.
Hmm, that seems to be subjective, but I have less problems with that
than with using "d" for a struct device (or a struct device_driver).
I'd even go so far as to consider it nice if they are identical.
Maybe that's because having the first and third argument identical is
quite common:
$ git grep -P 'container_of\((?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*\g{ident}\s*\)' | wc -l
5940
which is >44% of all the usages
$ git grep -P 'container_of\((?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*(?&ident)\s*\)' | wc -l
13362
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Tue, 21 Mar 2023, Uwe Kleine-K?nig wrote:
> On Tue, Mar 21, 2023 at 04:59:49PM +0100, Julia Lawall wrote:
> >
> >
> > On Tue, 21 Mar 2023, Uwe Kleine-K?nig wrote:
> >
> > > Hello,
> > >
> > > just some nitpicks:
> > >
> > > On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
> > > > Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> > > > static inline function.
> > > >
> > > > it is not great to have macro that use `container_of` macro,
> > >
> > > s/it/It/; s/macro/macros/; s/use/use the/;
> > >
> > > > because from looking at the definition one cannot tell what type
> > > > it applies to.
> > > > [...]
> > > > -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> > > > +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
> > >
> > > drivers/staging/greybus/gbphy.c always passes a variable named
> > > "dev" to this macro. So I'd call the parameter "dev", too, instead of
> > > "d". This is also a more typical name for variables of that type.
> >
> > I argued against that. Because then there are two uses of dev
> > in the argument of container_of, and they refer to completely different
> > things. It's true that by the way container_of works, it's fine, but it
> > may be misleading.
>
> Hmm, that seems to be subjective, but I have less problems with that
> than with using "d" for a struct device (or a struct device_driver).
> I'd even go so far as to consider it nice if they are identical.
>
> Maybe that's because having the first and third argument identical is
> quite common:
>
> $ git grep -P 'container_of\((?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*\g{ident}\s*\)' | wc -l
> 5940
>
> which is >44% of all the usages
>
> $ git grep -P 'container_of\((?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*(?&ident)\s*\)' | wc -l
> 13362
OK, if people like that, then why not. But it's dangerous if the call to
container_of is in a macro, rather than in a function.
julia
On Tue, 21 Mar 2023, Menna Mahmoud wrote:
>
> On ٢١/٣/٢٠٢٣ ١٣:٤٦, Julia Lawall wrote:
> >
> > On Tue, 21 Mar 2023, Menna Mahmoud wrote:
> >
> > > This patchset includes change happened in greybus driver in three
> > > different files two of them patch one and three related to
> > > checkpatch issue and in second patch convert two
> > > `container_of` macros into inline functions.
> > >
> > > Menna Mahmoud (3):
> > > staging: greybus: remove unnecessary blank line
> > > staging: greybus: use inline function for macros
> > > staging: greybus: remove unnecessary blank line
> > Different patches should have different subject lines.
> But I have already the same edit in both file, so should I re-write the
> subject for one of them?
> > You need to either
> > be more specific about the file affected or merge the two patches with the
> > same subject into one.
>
> each patch related to different file. So, Can I to merge two commits for
> different files but have the same edit in one patch?
They are both for greybus, which is what you advertise in the subject
line. And the sense of the changes is the same, and the changes are quite
simple. So I think you could just put them in one patch. If you find
other occurrences of the problem in greybus you could make one patch that
fixes all of them.
> but in this case no need to create patchset for all changes in `greybus`
> driver, right?
A patchset is needed if the changes affect the same file, because there
might be complications if the patches are applied in the wrong order.
>
> If okay with that, should I versioning the patches to resend them again, or
> should add "RESEND" subject prefix?
RESEND would be if you send exactly the same thing, because some time has
passed and you are worried that the patch has been lost. Now that you
have put these in a series, it is perhaps best to leave them in a series
and increase the version number, to avoid confusion on the part of people
reading the patches.
julia
> please tell me the best way to resend these patches, appreciate your help.
>
>
> Menna
>
>
> >
> > julia
> >
> > > drivers/staging/greybus/gbphy.h | 10 ++++++++--
> > > drivers/staging/greybus/greybus_authentication.h | 1 -
> > > drivers/staging/greybus/pwm.c | 1 -
> > > 3 files changed, 8 insertions(+), 4 deletions(-)
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > >
>
On Tue, Mar 21, 2023 at 06:25:29PM +0200, Menna Mahmoud wrote:
>
> On ٢١/٣/٢٠٢٣ ١٧:٤٧, Uwe Kleine-König wrote:
> > Hello,
> >
> > just some nitpicks:
> >
> > On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
> > > Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> > > static inline function.
> > >
> > > it is not great to have macro that use `container_of` macro,
> > s/it/It/; s/macro/macros/; s/use/use the/;
> Okay, I will fix it.
> >
> > > because from looking at the definition one cannot tell what type
> > > it applies to.
> > > [...]
> > > -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> > > +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
> > drivers/staging/greybus/gbphy.c always passes a variable named
> > "dev" to this macro. So I'd call the parameter "dev", too, instead of
> > "d". This is also a more typical name for variables of that type.
> >
> > > +{
> > > + return container_of(d, struct gbphy_device, dev);
> > > +}
> > > [...]
> > > };
> > > -#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);
> > > +}
> > With a similar reasoning (and also to not have "d"s that are either
> > device or device_driver) I'd recommend "drv" here.
>
>
> please check this with Julia, because she said they should different.
At least use "_dev" instead of "d" which seems to be a common idiom,
too:
$ git grep -P 'container_of\(_(?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*\g{ident}\s*\)' | wc -l
570
("drv" should be fine, because the third argument is "driver" there.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Tue, Mar 21, 2023 at 05:35:54PM +0100, Julia Lawall wrote:
>
>
> On Tue, 21 Mar 2023, Uwe Kleine-K?nig wrote:
>
> > On Tue, Mar 21, 2023 at 04:59:49PM +0100, Julia Lawall wrote:
> > >
> > >
> > > On Tue, 21 Mar 2023, Uwe Kleine-K?nig wrote:
> > >
> > > > Hello,
> > > >
> > > > just some nitpicks:
> > > >
> > > > On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
> > > > > Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
> > > > > static inline function.
> > > > >
> > > > > it is not great to have macro that use `container_of` macro,
> > > >
> > > > s/it/It/; s/macro/macros/; s/use/use the/;
> > > >
> > > > > because from looking at the definition one cannot tell what type
> > > > > it applies to.
> > > > > [...]
> > > > > -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
> > > > > +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
> > > >
> > > > drivers/staging/greybus/gbphy.c always passes a variable named
> > > > "dev" to this macro. So I'd call the parameter "dev", too, instead of
> > > > "d". This is also a more typical name for variables of that type.
> > >
> > > I argued against that. Because then there are two uses of dev
> > > in the argument of container_of, and they refer to completely different
> > > things. It's true that by the way container_of works, it's fine, but it
> > > may be misleading.
> >
> > Hmm, that seems to be subjective, but I have less problems with that
> > than with using "d" for a struct device (or a struct device_driver).
> > I'd even go so far as to consider it nice if they are identical.
> >
> > Maybe that's because having the first and third argument identical is
> > quite common:
> >
> > $ git grep -P 'container_of\((?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*\g{ident}\s*\)' | wc -l
> > 5940
> >
> > which is >44% of all the usages
> >
> > $ git grep -P 'container_of\((?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*(?&ident)\s*\)' | wc -l
> > 13362
>
> OK, if people like that, then why not. But it's dangerous if the call to
> container_of is in a macro, rather than in a function.
It's not "dangerous" at all, as the macro will enforce type-safety, you
can't get it wrong when using it.
Ideally this is best as a macro as it's just doing pointer math, worst
case, the compiler turns a function like this into a real function and
you have a call/subtract/return for every time you make this call.
So this conversion to functions feels odd to me, as you potentially are
making all of this worse overall.
Wait until people realize that when we eventually turn these into
container_of_const() you HAVE to go back to using it as a macro instead
of in a function call wrapper like this...
thanks,
greg k-h
On ٢١/٣/٢٠٢٣ ١٨:٤٢, Uwe Kleine-König wrote:
> On Tue, Mar 21, 2023 at 06:25:29PM +0200, Menna Mahmoud wrote:
>> On ٢١/٣/٢٠٢٣ ١٧:٤٧, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> just some nitpicks:
>>>
>>> On Tue, Mar 21, 2023 at 01:04:33AM +0200, Menna Mahmoud wrote:
>>>> Convert `to_gbphy_dev` and `to_gbphy_driver` macros into a
>>>> static inline function.
>>>>
>>>> it is not great to have macro that use `container_of` macro,
>>> s/it/It/; s/macro/macros/; s/use/use the/;
>> Okay, I will fix it.
>>>> because from looking at the definition one cannot tell what type
>>>> it applies to.
>>>> [...]
>>>> -#define to_gbphy_dev(d) container_of(d, struct gbphy_device, dev)
>>>> +static inline struct gbphy_device *to_gbphy_dev(const struct device *d)
>>> drivers/staging/greybus/gbphy.c always passes a variable named
>>> "dev" to this macro. So I'd call the parameter "dev", too, instead of
>>> "d". This is also a more typical name for variables of that type.
>>>
>>>> +{
>>>> + return container_of(d, struct gbphy_device, dev);
>>>> +}
>>>> [...]
>>>> };
>>>> -#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);
>>>> +}
>>> With a similar reasoning (and also to not have "d"s that are either
>>> device or device_driver) I'd recommend "drv" here.
>>
>> please check this with Julia, because she said they should different.
> At least use "_dev" instead of "d" which seems to be a common idiom,
> too:
>
> $ git grep -P 'container_of\(_(?<ident>[A-Za-z_0-9-]*)\s*,[^,]*,\s*\g{ident}\s*\)' | wc -l
> 570
>
> ("drv" should be fine, because the third argument is "driver" there.)
Okay, I will do that.
Thanks,
Menna
>
> Best regards
> Uwe
>
On ٢١/٣/٢٠٢٣ ١٨:٢٦, Greg KH wrote:
> On Tue, Mar 21, 2023 at 06:22:44PM +0200, Menna Mahmoud wrote:
>> On ٢١/٣/٢٠٢٣ ١٣:٤٦, Julia Lawall wrote:
>>> On Tue, 21 Mar 2023, Menna Mahmoud wrote:
>>>
>>>> This patchset includes change happened in greybus driver in three
>>>> different files two of them patch one and three related to
>>>> checkpatch issue and in second patch convert two
>>>> `container_of` macros into inline functions.
>>>>
>>>> Menna Mahmoud (3):
>>>> staging: greybus: remove unnecessary blank line
>>>> staging: greybus: use inline function for macros
>>>> staging: greybus: remove unnecessary blank line
>>> Different patches should have different subject lines.
>> But I have already the same edit in both file, so should I re-write the
>> subject for one of them?
>>> You need to either
>>> be more specific about the file affected or merge the two patches with the
>>> same subject into one.
>> each patch related to different file. So, Can I to merge two commits for
>> different files but have the same edit in one patch?
> Yes, or make 2 different patches with 2 different subject lines as they
> are obviously doing different things.
okay, I will fix it.
>
>> but in this case no need to create patchset for all changes in `greybus`
>> driver, right?
>>
>> If okay with that, should I versioning the patches to resend them again, or
>> should add "RESEND" subject prefix?
>>
>> please tell me the best way to resend these patches, appreciate your help.
> What would you want to see if you had to review and apply loads of
> patches like this?
sure add version number will be easy to review.
> (hint, it's not a resend, but a new version...)
>
> thanks,
>
> greg k-h
Thanks,
Menna
On ٢١/٣/٢٠٢٣ ١٨:٣٩, Julia Lawall wrote:
>
> On Tue, 21 Mar 2023, Menna Mahmoud wrote:
>
>> On ٢١/٣/٢٠٢٣ ١٣:٤٦, Julia Lawall wrote:
>>> On Tue, 21 Mar 2023, Menna Mahmoud wrote:
>>>
>>>> This patchset includes change happened in greybus driver in three
>>>> different files two of them patch one and three related to
>>>> checkpatch issue and in second patch convert two
>>>> `container_of` macros into inline functions.
>>>>
>>>> Menna Mahmoud (3):
>>>> staging: greybus: remove unnecessary blank line
>>>> staging: greybus: use inline function for macros
>>>> staging: greybus: remove unnecessary blank line
>>> Different patches should have different subject lines.
>> But I have already the same edit in both file, so should I re-write the
>> subject for one of them?
>>> You need to either
>>> be more specific about the file affected or merge the two patches with the
>>> same subject into one.
>> each patch related to different file. So, Can I to merge two commits for
>> different files but have the same edit in one patch?
> They are both for greybus, which is what you advertise in the subject
> line. And the sense of the changes is the same, and the changes are quite
> simple. So I think you could just put them in one patch. If you find
> other occurrences of the problem in greybus you could make one patch that
> fixes all of them.
>
>> but in this case no need to create patchset for all changes in `greybus`
>> driver, right?
> A patchset is needed if the changes affect the same file, because there
> might be complications if the patches are applied in the wrong order.
>
>> If okay with that, should I versioning the patches to resend them again, or
>> should add "RESEND" subject prefix?
> RESEND would be if you send exactly the same thing, because some time has
> passed and you are worried that the patch has been lost. Now that you
> have put these in a series, it is perhaps best to leave them in a series
> and increase the version number, to avoid confusion on the part of people
> reading the patches.
>
> julia
understood, thanks Julia.
Menna
>
>> please tell me the best way to resend these patches, appreciate your help.
>>
>>
>> Menna
>>
>>
>>> julia
>>>
>>>> drivers/staging/greybus/gbphy.h | 10 ++++++++--
>>>> drivers/staging/greybus/greybus_authentication.h | 1 -
>>>> drivers/staging/greybus/pwm.c | 1 -
>>>> 3 files changed, 8 insertions(+), 4 deletions(-)
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>>
>>>>
> >