[PATCH] mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[PATCH] mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 16 Jan 2018 17:30:23 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/mfd/viperboard.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e6b3c70aeb22..e9f61262d583 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -59,10 +59,8 @@ static int vprbrd_probe(struct usb_interface *interface,
 
 	/* allocate memory for our device state and initialize it */
 	vb = kzalloc(sizeof(*vb), GFP_KERNEL);
-	if (vb == NULL) {
-		dev_err(&interface->dev, "Out of memory\n");
+	if (!vb)
 		return -ENOMEM;
-	}
 
 	mutex_init(&vb->lock);
 
-- 
2.15.1

[PATCH] mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 16 Jan 2018 17:30:23 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 drivers/mfd/viperboard.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
index e6b3c70aeb22..e9f61262d583 100644
--- a/drivers/mfd/viperboard.c
+++ b/drivers/mfd/viperboard.c
@@ -59,10 +59,8 @@ static int vprbrd_probe(struct usb_interface *interface,
 
 	/* allocate memory for our device state and initialize it */
 	vb = kzalloc(sizeof(*vb), GFP_KERNEL);
-	if (vb = NULL) {
-		dev_err(&interface->dev, "Out of memory\n");
+	if (!vb)
 		return -ENOMEM;
-	}
 
 	mutex_init(&vb->lock);
 
-- 
2.15.1

Re: [PATCH] mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[Lee Jones]

On Tue, 16 Jan 2018, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>

Markus,

Can you please fix-up all of the patches I've NACKed and collect them
up with all the other MFD patches you currently have on the list and
send them as a single set please?

Reviewing them one after another, is taking a lot of time and causing
my a great deal of pain.

I am marking all of your other MFD submissions as 'read and reviewed'
and will not be processing any more until the are all contained in a
single, threaded set.

Thank you!

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[Lee Jones]

On Tue, 16 Jan 2018, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>

Markus,

Can you please fix-up all of the patches I've NACKed and collect them
up with all the other MFD patches you currently have on the list and
send them as a single set please?

Reviewing them one after another, is taking a lot of time and causing
my a great deal of pain.

I am marking all of your other MFD submissions as 'read and reviewed'
and will not be processing any more until the are all contained in a
single, threaded set.

Thank you!

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[Lee Jones]

On Tue, 23 Jan 2018, Lee Jones wrote:

> On Tue, 16 Jan 2018, SF Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> 
> Markus,
> 
> Can you please fix-up all of the patches I've NACKed and collect them
> up with all the other MFD patches you currently have on the list and
> send them as a single set please?
> 
> Reviewing them one after another, is taking a lot of time and causing
> my a great deal of pain.
> 
> I am marking all of your other MFD submissions as 'read and reviewed'
> and will not be processing any more until the are all contained in a
> single, threaded set.
> 
> Thank you!

Also, could you change the subject lines, so they match that expected
by the subsystem.  You can check what that is by doing:

  `git log --oneline -- <subsystem>`

In MFD case it's:

  "mfd: <driver>: <Succinct headline starting with a capital letter>"

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[Lee Jones]

On Tue, 23 Jan 2018, Lee Jones wrote:

> On Tue, 16 Jan 2018, SF Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> 
> Markus,
> 
> Can you please fix-up all of the patches I've NACKed and collect them
> up with all the other MFD patches you currently have on the list and
> send them as a single set please?
> 
> Reviewing them one after another, is taking a lot of time and causing
> my a great deal of pain.
> 
> I am marking all of your other MFD submissions as 'read and reviewed'
> and will not be processing any more until the are all contained in a
> single, threaded set.
> 
> Thank you!

Also, could you change the subject lines, so they match that expected
by the subsystem.  You can check what that is by doing:

  `git log --oneline -- <subsystem>`

In MFD case it's:

  "mfd: <driver>: <Succinct headline starting with a capital letter>"

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[SF Markus Elfring]

>> Can you please fix-up all of the patches I've NACKed and collect them
>> up with all the other MFD patches you currently have on the list and
>> send them as a single set please?
>>
>> Reviewing them one after another, is taking a lot of time and causing
>> my a great deal of pain.

There will be review efforts needed as usual. They might be more noticeable
in this case just because I sent some update suggestions also for software
modules from the directory “drivers/mfd”.


>> I am marking all of your other MFD submissions as 'read and reviewed'
>> and will not be processing any more until the are all contained in a
>> single, threaded set.
>>
>> Thank you!
> 
> Also, could you change the subject lines, so they match that expected
> by the subsystem.

Do you request a resent for almost all changes from this patch series here?

Regards,
Markus

Re: mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[SF Markus Elfring]

>> Can you please fix-up all of the patches I've NACKed and collect them
>> up with all the other MFD patches you currently have on the list and
>> send them as a single set please?
>>
>> Reviewing them one after another, is taking a lot of time and causing
>> my a great deal of pain.

There will be review efforts needed as usual. They might be more noticeable
in this case just because I sent some update suggestions also for software
modules from the directory “drivers/mfd”.


>> I am marking all of your other MFD submissions as 'read and reviewed'
>> and will not be processing any more until the are all contained in a
>> single, threaded set.
>>
>> Thank you!
> 
> Also, could you change the subject lines, so they match that expected
> by the subsystem.

Do you request a resent for almost all changes from this patch series here?

Regards,
Markus

Re: mfd/viperboard: Delete an error message for a failed memory allocation in vprbrd_probe()

[Lee Jones]

On Tue, 23 Jan 2018, SF Markus Elfring wrote:

> >> Can you please fix-up all of the patches I've NACKed and collect them
> >> up with all the other MFD patches you currently have on the list and
> >> send them as a single set please?
> >>
> >> Reviewing them one after another, is taking a lot of time and causing
> >> my a great deal of pain.
> 
> There will be review efforts needed as usual. They might be more noticeable
> in this case just because I sent some update suggestions also for software
> modules from the directory “drivers/mfd”.

"It's not you, it's me!"

My preferred mailer (Mutt) re-orders replied-to mails by putting them
to the top of my Inbox.  At which point I have to re-navigate down to
the next patch to review.  This is fine for most submissions, but you
have fired ~30, mostly individual patches at me.  Most of which could
realistically be squashed into ~5 patches (if I was feeling mean).

The choice is yours though, either squash them into patches dealing
with the same type of fix-up or merely send all of the un-applied
patches again as a single set, so I can deal with them in a sane
manner.

> >> I am marking all of your other MFD submissions as 'read and reviewed'
> >> and will not be processing any more until the are all contained in a
> >> single, threaded set.
> >>
> >> Thank you!
> > 
> > Also, could you change the subject lines, so they match that expected
> > by the subsystem.
> 
> Do you request a resent for almost all changes from this patch series here?

I'm not sure I can decipher this.

I'd like you to do the following please:

  - Pull all un-applied MFD patches into a single branch based on Mainline
  - Add any Reviewed-by/Acked-by's you've received
  - Fix the subject lines on all of the patches 's///: /'
  - Resubmit as one single threaded patch-set

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: mfd: Patch management?

[SF Markus Elfring]

> My preferred mailer (Mutt) re-orders replied-to mails by putting them
> to the top of my Inbox.  At which point I have to re-navigate down to
> the next patch to review.

How much does this tool influence the amount of update suggestions
which you could handle easily and safely?


> This is fine for most submissions, but you have fired ~30,
> mostly individual patches at me.

This number could be appropriate. I tried to contribute hundreds
of change possibilities for various software components.


> I'd like you to do the following please:

It will take a while until you might get the next chance to take
another look at these subsequent patches.

Regards,
Markus

Re: mfd: Patch management?

[SF Markus Elfring]

> My preferred mailer (Mutt) re-orders replied-to mails by putting them
> to the top of my Inbox.  At which point I have to re-navigate down to
> the next patch to review.

How much does this tool influence the amount of update suggestions
which you could handle easily and safely?


> This is fine for most submissions, but you have fired ~30,
> mostly individual patches at me.

This number could be appropriate. I tried to contribute hundreds
of change possibilities for various software components.


> I'd like you to do the following please:

It will take a while until you might get the next chance to take
another look at these subsequent patches.

Regards,
Markus

Re: mfd: Patch management?

[Lee Jones]

On Tue, 23 Jan 2018, SF Markus Elfring wrote:

> > My preferred mailer (Mutt) re-orders replied-to mails by putting them
> > to the top of my Inbox.  At which point I have to re-navigate down to
> > the next patch to review.
> 
> How much does this tool influence the amount of update suggestions
> which you could handle easily and safely?

In the 5 years I've been doing this, this is the first time someone
has submitted in such a way as to cause an issue.

> > This is fine for most submissions, but you have fired ~30,
> > mostly individual patches at me.
> 
> This number could be appropriate. I tried to contribute hundreds
> of change possibilities for various software components.

Moving forward, my advice to you would be to collect grouped patches
on a number of topic branches, then send them out in batches, perhaps
every couple of weeks.

Sending ~30 patches individually, spaced over a few hours/days, is
actually not a good system.  It is in fact quite inappropriate and a
pain to manage.  I for one find many (to be fair, very trivial)
patches scatter-gunned throughout my inbox to be rather inconvenient.

What I should do really is ask you to take all similar (remove error
message, don't use sizeof(struct X), remove '== NULL') changes and
squash them into single patches.  However, I realise that you might
want the "upstream creds", so I won't do that -- but not at the
expense of my time/effort.

The two choices are to squash or to create a set.

> > I'd like you to do the following please:
> 
> It will take a while until you might get the next chance to take
> another look at these subsequent patches.

I'm not in a hurry.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: mfd: Patch management?

[Lee Jones]

On Tue, 23 Jan 2018, SF Markus Elfring wrote:

> > My preferred mailer (Mutt) re-orders replied-to mails by putting them
> > to the top of my Inbox.  At which point I have to re-navigate down to
> > the next patch to review.
> 
> How much does this tool influence the amount of update suggestions
> which you could handle easily and safely?

In the 5 years I've been doing this, this is the first time someone
has submitted in such a way as to cause an issue.

> > This is fine for most submissions, but you have fired ~30,
> > mostly individual patches at me.
> 
> This number could be appropriate. I tried to contribute hundreds
> of change possibilities for various software components.

Moving forward, my advice to you would be to collect grouped patches
on a number of topic branches, then send them out in batches, perhaps
every couple of weeks.

Sending ~30 patches individually, spaced over a few hours/days, is
actually not a good system.  It is in fact quite inappropriate and a
pain to manage.  I for one find many (to be fair, very trivial)
patches scatter-gunned throughout my inbox to be rather inconvenient.

What I should do really is ask you to take all similar (remove error
message, don't use sizeof(struct X), remove '= NULL') changes and
squash them into single patches.  However, I realise that you might
want the "upstream creds", so I won't do that -- but not at the
expense of my time/effort.

The two choices are to squash or to create a set.

> > I'd like you to do the following please:
> 
> It will take a while until you might get the next chance to take
> another look at these subsequent patches.

I'm not in a hurry.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mfd: Patch management?

[SF Markus Elfring]

> What I should do really is ask you to take all similar (remove error
> message, don't use sizeof(struct X), remove '== NULL') changes and
> squash them into single patches.

I would try such an approach more often if I would get also more
promising indications of corresponding change acceptance besides
other software development “surprises”.


> However, I realise that you might want the "upstream creds",
> so I won't do that

I find this view interesting somehow.


> -- but not at the expense of my time/effort.
> 
> The two choices are to squash or to create a set.

This information triggers recurring difficulties around differences
in the preferred patch granularity.

Regards,
Markus

Re: mfd: Patch management?

[SF Markus Elfring]

> What I should do really is ask you to take all similar (remove error
> message, don't use sizeof(struct X), remove '= NULL') changes and
> squash them into single patches.

I would try such an approach more often if I would get also more
promising indications of corresponding change acceptance besides
other software development “surprises”.


> However, I realise that you might want the "upstream creds",
> so I won't do that

I find this view interesting somehow.


> -- but not at the expense of my time/effort.
> 
> The two choices are to squash or to create a set.

This information triggers recurring difficulties around differences
in the preferred patch granularity.

Regards,
Markus

Re: mfd: Patch management?

[Lee Jones]

On Fri, 26 Jan 2018, SF Markus Elfring wrote:

Do not send private emails containing list related content.

<putting this conversation back on the list, where it belongs>

> > Moving forward, my advice to you would be to collect grouped patches
> > on a number of topic branches,
> 
> I am using development branches generally.

Great, so write patches and add them to your topic branches.  Then
send them out periodically, together, as a threaded set.

  See: `git send-email` -- grep for "--thread"

> > then send them out in batches, perhaps every couple of weeks.
> 
> I got other preferences for time ranges around patch distribution.

Not sure what this means.  I'm guessing you're saying that you are not
willing to collect your patches and you intend on sending them one at
a time, over time.

If I am understanding you correctly, then your patches will not be
reviewed.

> > Sending ~30 patches individually, spaced over a few hours/days,
> > is actually not a good system.
> 
> It happened that several update candidates were noticed by static
> source code analysis also in this software area.

Doesn't matter.  Collect them up and send them as a batch.

> > It is in fact quite inappropriate and a pain to manage.
> 
> It becomes more interesting when the patch numbers grow, doesn't it?

When contributors do not manage their submissions properly, it does
become more *annoying* and unmanageable, yes.

> > I for one find many (to be fair, very trivial) patches scatter-gunned
> > throughout my inbox to be rather inconvenient.
> 
> Are you looking for any better management tools?

No.

> Do you find any of the remaining change possibilities acceptable
> in principle?

I'm not going to review them until you re-submit them in an acceptable
manner, as requested.

> > The two choices are to squash or to create a set.
> 
> When will the adjustments which you could integrate already
> appear on the Linux next interface?
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/mfd/

When the merge-window closes.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: mfd: Patch management?

[Lee Jones]

On Fri, 26 Jan 2018, SF Markus Elfring wrote:

Do not send private emails containing list related content.

<putting this conversation back on the list, where it belongs>

> > Moving forward, my advice to you would be to collect grouped patches
> > on a number of topic branches,
> 
> I am using development branches generally.

Great, so write patches and add them to your topic branches.  Then
send them out periodically, together, as a threaded set.

  See: `git send-email` -- grep for "--thread"

> > then send them out in batches, perhaps every couple of weeks.
> 
> I got other preferences for time ranges around patch distribution.

Not sure what this means.  I'm guessing you're saying that you are not
willing to collect your patches and you intend on sending them one at
a time, over time.

If I am understanding you correctly, then your patches will not be
reviewed.

> > Sending ~30 patches individually, spaced over a few hours/days,
> > is actually not a good system.
> 
> It happened that several update candidates were noticed by static
> source code analysis also in this software area.

Doesn't matter.  Collect them up and send them as a batch.

> > It is in fact quite inappropriate and a pain to manage.
> 
> It becomes more interesting when the patch numbers grow, doesn't it?

When contributors do not manage their submissions properly, it does
become more *annoying* and unmanageable, yes.

> > I for one find many (to be fair, very trivial) patches scatter-gunned
> > throughout my inbox to be rather inconvenient.
> 
> Are you looking for any better management tools?

No.

> Do you find any of the remaining change possibilities acceptable
> in principle?

I'm not going to review them until you re-submit them in an acceptable
manner, as requested.

> > The two choices are to squash or to create a set.
> 
> When will the adjustments which you could integrate already
> appear on the Linux next interface?
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/mfd/

When the merge-window closes.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mfd: Patch management?

[Lee Jones]

On Fri, 26 Jan 2018, SF Markus Elfring wrote:

Any more private messages from now on will be ignored.

> >> I got other preferences for time ranges around patch distribution.
> > 
> > Not sure what this means.  I'm guessing you're saying that you are not
> > willing to collect your patches and you intend on sending them one at
> > a time, over time.
> 
> You interpreted my feedback in an unwanted direction.
> 
> I am just browsing through the Linux software landscape.
> Corresponding patches will evolve according to the varying sizes of
> affected directories.
> 
> 
> > If I am understanding you correctly, then your patches will not
> > be reviewed.
> 
> Another review will hopefully happen (under other circumstances).
> 
> 
> >> When will the adjustments which you could integrate already
> >> appear on the Linux next interface?
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/mfd/
> > 
> > When the merge-window closes.
> 
> I am curious if more positive feedback could evolve till then.
> I would appreciate if a potentially needed resend for my selection
> of update suggestions could become smaller (when reviewed steps
> could be already integrated for example).

I'm not entirely sure what you're trying to say, in any of your
responses.  Are you using Google Translate to convert between your
first language and English?

If you want to rebase your patches, to see what has been applied and
what hasn't, you can use the MFD repo and its next-next branch.

Repo:
  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git

Branch:
  for-mfd-next-next

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: mfd: Patch management?

[Lee Jones]

On Fri, 26 Jan 2018, SF Markus Elfring wrote:

Any more private messages from now on will be ignored.

> >> I got other preferences for time ranges around patch distribution.
> > 
> > Not sure what this means.  I'm guessing you're saying that you are not
> > willing to collect your patches and you intend on sending them one at
> > a time, over time.
> 
> You interpreted my feedback in an unwanted direction.
> 
> I am just browsing through the Linux software landscape.
> Corresponding patches will evolve according to the varying sizes of
> affected directories.
> 
> 
> > If I am understanding you correctly, then your patches will not
> > be reviewed.
> 
> Another review will hopefully happen (under other circumstances).
> 
> 
> >> When will the adjustments which you could integrate already
> >> appear on the Linux next interface?
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/mfd/
> > 
> > When the merge-window closes.
> 
> I am curious if more positive feedback could evolve till then.
> I would appreciate if a potentially needed resend for my selection
> of update suggestions could become smaller (when reviewed steps
> could be already integrated for example).

I'm not entirely sure what you're trying to say, in any of your
responses.  Are you using Google Translate to convert between your
first language and English?

If you want to rebase your patches, to see what has been applied and
what hasn't, you can use the MFD repo and its next-next branch.

Repo:
  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git

Branch:
  for-mfd-next-next

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mfd: Patch management?

[SF Markus Elfring]

>> I am curious if more positive feedback could evolve till then.
>> I would appreciate if a potentially needed resend for my selection
>> of update suggestions could become smaller (when reviewed steps
>> could be already integrated for example).
> 
> I'm not entirely sure what you're trying to say,
> in any of your responses.

I imagine that acceptance for these changes could be influenced
also by review comments from other contributors.


> Are you using Google Translate to convert between your
> first language and English?

No.


> If you want to rebase your patches, to see what has been applied and
> what hasn't, you can use the MFD repo and its next-next branch.

https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next-next

How are the chances that further update suggestions will be integrated
just because I sent them as small patch series in the threaded way?

Examples:
* tps65910: Adjustments for four function implementations
  https://lkml.org/lkml/2018/1/16/313

* abx500-core: Adjustments for eight function implementations
  https://lkml.org/lkml/2018/1/16/186


Regards,
Markus

Re: mfd: Patch management?

[SF Markus Elfring]

>> I am curious if more positive feedback could evolve till then.
>> I would appreciate if a potentially needed resend for my selection
>> of update suggestions could become smaller (when reviewed steps
>> could be already integrated for example).
> 
> I'm not entirely sure what you're trying to say,
> in any of your responses.

I imagine that acceptance for these changes could be influenced
also by review comments from other contributors.


> Are you using Google Translate to convert between your
> first language and English?

No.


> If you want to rebase your patches, to see what has been applied and
> what hasn't, you can use the MFD repo and its next-next branch.

https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next-next

How are the chances that further update suggestions will be integrated
just because I sent them as small patch series in the threaded way?

Examples:
* tps65910: Adjustments for four function implementations
  https://lkml.org/lkml/2018/1/16/313

* abx500-core: Adjustments for eight function implementations
  https://lkml.org/lkml/2018/1/16/186


Regards,
Markus

Re: mfd: Patch management?

[Lee Jones]

On Fri, 26 Jan 2018, SF Markus Elfring wrote:

> >> I am curious if more positive feedback could evolve till then.
> >> I would appreciate if a potentially needed resend for my selection
> >> of update suggestions could become smaller (when reviewed steps
> >> could be already integrated for example).
> > 
> > I'm not entirely sure what you're trying to say,
> > in any of your responses.
> 
> I imagine that acceptance for these changes could be influenced
> also by review comments from other contributors.

Influenced yes, but I will also need to review them.

You can't 'go around' me, if that's what you're thinking.

> > If you want to rebase your patches, to see what has been applied and
> > what hasn't, you can use the MFD repo and its next-next branch.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next-next
> 
> How are the chances that further update suggestions will be integrated
> just because I sent them as small patch series in the threaded way?
> 
> Examples:
> * tps65910: Adjustments for four function implementations
>   https://lkml.org/lkml/2018/1/16/313
> 
> * abx500-core: Adjustments for eight function implementations
>   https://lkml.org/lkml/2018/1/16/186

In order to not make my life difficult, I've kindly requested that you
gather all of your MFD patches and send them as one single set.

Is there a good reason why you're not willing to do so?

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: mfd: Patch management?

[Lee Jones]

On Fri, 26 Jan 2018, SF Markus Elfring wrote:

> >> I am curious if more positive feedback could evolve till then.
> >> I would appreciate if a potentially needed resend for my selection
> >> of update suggestions could become smaller (when reviewed steps
> >> could be already integrated for example).
> > 
> > I'm not entirely sure what you're trying to say,
> > in any of your responses.
> 
> I imagine that acceptance for these changes could be influenced
> also by review comments from other contributors.

Influenced yes, but I will also need to review them.

You can't 'go around' me, if that's what you're thinking.

> > If you want to rebase your patches, to see what has been applied and
> > what hasn't, you can use the MFD repo and its next-next branch.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next-next
> 
> How are the chances that further update suggestions will be integrated
> just because I sent them as small patch series in the threaded way?
> 
> Examples:
> * tps65910: Adjustments for four function implementations
>   https://lkml.org/lkml/2018/1/16/313
> 
> * abx500-core: Adjustments for eight function implementations
>   https://lkml.org/lkml/2018/1/16/186

In order to not make my life difficult, I've kindly requested that you
gather all of your MFD patches and send them as one single set.

Is there a good reason why you're not willing to do so?

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mfd: Patch management?

[SF Markus Elfring]

>> I imagine that acceptance for these changes could be influenced
>> also by review comments from other contributors.
> 
> Influenced yes, but I will also need to review them.

Yes. - This is the usual process.


> You can't 'go around' me, if that's what you're thinking.

I do not think this. - I hope somehow that additional review comments
(by other contributors) could make the handling of shown update candidates
more promising.


>> How are the chances that further update suggestions will be integrated
>> just because I sent them as small patch series in the threaded way?
>>
>> Examples:
>> * tps65910: Adjustments for four function implementations
>>   https://lkml.org/lkml/2018/1/16/313
>>
>> * abx500-core: Adjustments for eight function implementations
>>   https://lkml.org/lkml/2018/1/16/186
> 
> In order to not make my life difficult,

There are more options to make it a bit easier, aren't there?


> I've kindly requested that you gather all of your MFD patches

Or the remaining ones …?


> and send them as one single set.

Do you still insist to get these seven update steps in a bigger patch series
despite of their threaded structure?


> Is there a good reason why you're not willing to do so?

I am trying to find out if a few formal details are really hindering
progress on the clarification of affected implementation details.

I assume that additional hints could occur until I might rebase mentioned
change combinations on another recent commit.

Regards,
Markus

Re: mfd: Patch management?

[SF Markus Elfring]

>> I imagine that acceptance for these changes could be influenced
>> also by review comments from other contributors.
> 
> Influenced yes, but I will also need to review them.

Yes. - This is the usual process.


> You can't 'go around' me, if that's what you're thinking.

I do not think this. - I hope somehow that additional review comments
(by other contributors) could make the handling of shown update candidates
more promising.


>> How are the chances that further update suggestions will be integrated
>> just because I sent them as small patch series in the threaded way?
>>
>> Examples:
>> * tps65910: Adjustments for four function implementations
>>   https://lkml.org/lkml/2018/1/16/313
>>
>> * abx500-core: Adjustments for eight function implementations
>>   https://lkml.org/lkml/2018/1/16/186
> 
> In order to not make my life difficult,

There are more options to make it a bit easier, aren't there?


> I've kindly requested that you gather all of your MFD patches

Or the remaining ones …?


> and send them as one single set.

Do you still insist to get these seven update steps in a bigger patch series
despite of their threaded structure?


> Is there a good reason why you're not willing to do so?

I am trying to find out if a few formal details are really hindering
progress on the clarification of affected implementation details.

I assume that additional hints could occur until I might rebase mentioned
change combinations on another recent commit.

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html