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(-)
Remove unnecessary blank line before struct as reported by checkpatch:
" CHECK: Please don't use multiple blank lines "
Signed-off-by: Menna Mahmoud eng.mennamahmoud.mm@gmail.com --- 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];
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 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 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);
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
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 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
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, 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:
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: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
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
Remove unnecessary blank line before struct as reported by checkpatch:
" CHECK: Please don't use multiple blank lines "
Signed-off-by: Menna Mahmoud eng.mennamahmoud.mm@gmail.com --- 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;
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
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 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 ٢١/٣/٢٠٢٣ ١٨:٢٦, 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 eitherbe 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 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 ٢١/٣/٢٠٢٣ ١٨:٣٩, 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 eitherbe 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
-
Greg KH -
Julia Lawall -
Menna Mahmoud -
Uwe Kleine-König