| Message ID | 7d68a9e5dd338081342dd8b06310c2f3e61fccc0.1473996370.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
On 16-09-16, 08:56, Viresh Kumar wrote: > These can fit in a single line (80 columns), don't split lines > unnecessarily. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > --- > V1->V2: New patch > --- > drivers/mfd/wm8994-core.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) Ping!! -- viresh
On Mon, 03 Oct 2016, Viresh Kumar wrote: > On 16-09-16, 08:56, Viresh Kumar wrote: > > These can fit in a single line (80 columns), don't split lines > > unnecessarily. > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > > --- > > V1->V2: New patch > > --- > > drivers/mfd/wm8994-core.c | 6 ++---- > > 1 file changed, 2 insertions(+), 4 deletions(-) > > Ping!! Don't do that! -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
On 04-10-16, 15:41, Lee Jones wrote: > On Mon, 03 Oct 2016, Viresh Kumar wrote: > > > On 16-09-16, 08:56, Viresh Kumar wrote: > > > These can fit in a single line (80 columns), don't split lines > > > unnecessarily. > > > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > > > > --- > > > V1->V2: New patch > > > --- > > > drivers/mfd/wm8994-core.c | 6 ++---- > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > Ping!! > > Don't do that! Okay, but what's exactly wrong with that? Its been 20 days that I have heard anything from you on this. Pinging the maintainers is the only option other people have, right? -- viresh
On Wed, 05 Oct 2016, Viresh Kumar wrote: > On 04-10-16, 15:41, Lee Jones wrote: > > On Mon, 03 Oct 2016, Viresh Kumar wrote: > > > > > On 16-09-16, 08:56, Viresh Kumar wrote: > > > > These can fit in a single line (80 columns), don't split lines > > > > unnecessarily. > > > > > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > > > > > > --- > > > > V1->V2: New patch > > > > --- > > > > drivers/mfd/wm8994-core.c | 6 ++---- > > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > > > Ping!! > > > > Don't do that! > > Okay, but what's exactly wrong with that? Its been 20 days that I have > heard anything from you on this. Pinging the maintainers is the only > option other people have, right? You are experienced enough to know better than this. a) Contentless pings have never been acceptable. If you genuinely think a patch has been forgotten you should resubmit with a [RESEND]. That is their entire purpose. b) You submitted this patch right at the end of the release cycle, and your ping was sent during the merge-window. Most Maintainers, myself included, like to have patches soak tested in -next for at least a couple of weeks prior to acceptance. c) The merge-window is open. We are likely conducting final tests and formatting pull-requests during this time. As an experienced submitter, I would have expected you to follow the release cycle and know that sending patches late is cause for delay. d) Maintainers take vacations and attend conferences, so some delays are to be expected. FYI: Your patch has not slipped through the net. It is in the pile to be reviewed. Please be more patient, especially around merge time. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
On 05-10-16, 09:49, Lee Jones wrote: > You are experienced enough to know better than this. :) > a) Contentless pings have never been acceptable. If you genuinely > think a patch has been forgotten you should resubmit with a > [RESEND]. That is their entire purpose. Sure, but I really believe a light *ping* is much better than a complete resend to start with. It generates far less noise. > b) You submitted this patch right at the end of the release cycle, and > your ping was sent during the merge-window. Most Maintainers, myself > included, like to have patches soak tested in -next for at least a > couple of weeks prior to acceptance. I agree to that, I sent it after rc6. I wasn't looking to get this merged during this cycle, but was wondering if it got missed or something like that. I still don't think that a simple Ping was that bad of an option, but its fine. Take your time to review this, no issues. Cheers. -- viresh
On Wed, 05 Oct 2016, Viresh Kumar wrote: > On 05-10-16, 09:49, Lee Jones wrote: > > You are experienced enough to know better than this. > > :) > > > a) Contentless pings have never been acceptable. If you genuinely > > think a patch has been forgotten you should resubmit with a > > [RESEND]. That is their entire purpose. > > Sure, but I really believe a light *ping* is much better than a complete resend > to start with. It generates far less noise. Contentless pings are generally not accepted. It also has the unfortunate side-effect of placing your patches at the top of the pile, and since I process patches in reverse chronological order, you just put yourself at the back of the list. ;) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
On Fri, 16 Sep 2016, Viresh Kumar wrote: > These can fit in a single line (80 columns), don't split lines > unnecessarily. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > --- > V1->V2: New patch > --- > drivers/mfd/wm8994-core.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c > index 7eec619a6023..1990b2c90732 100644 > --- a/drivers/mfd/wm8994-core.c > +++ b/drivers/mfd/wm8994-core.c > @@ -401,8 +401,7 @@ static int wm8994_device_init(struct wm8994 *wm8994, int irq) > goto err; > } > > - ret = regulator_bulk_enable(wm8994->num_supplies, > - wm8994->supplies); > + ret = regulator_bulk_enable(wm8994->num_supplies, wm8994->supplies); > if (ret != 0) { > dev_err(wm8994->dev, "Failed to enable supplies: %d\n", ret); > goto err; > @@ -606,8 +605,7 @@ static void wm8994_device_exit(struct wm8994 *wm8994) > pm_runtime_disable(wm8994->dev); > mfd_remove_devices(wm8994->dev); > wm8994_irq_exit(wm8994); > - regulator_bulk_disable(wm8994->num_supplies, > - wm8994->supplies); > + regulator_bulk_disable(wm8994->num_supplies, wm8994->supplies); > } > > static const struct of_device_id wm8994_of_match[] = { -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c index 7eec619a6023..1990b2c90732 100644 --- a/drivers/mfd/wm8994-core.c +++ b/drivers/mfd/wm8994-core.c @@ -401,8 +401,7 @@ static int wm8994_device_init(struct wm8994 *wm8994, int irq) goto err; } - ret = regulator_bulk_enable(wm8994->num_supplies, - wm8994->supplies); + ret = regulator_bulk_enable(wm8994->num_supplies, wm8994->supplies); if (ret != 0) { dev_err(wm8994->dev, "Failed to enable supplies: %d\n", ret); goto err; @@ -606,8 +605,7 @@ static void wm8994_device_exit(struct wm8994 *wm8994) pm_runtime_disable(wm8994->dev); mfd_remove_devices(wm8994->dev); wm8994_irq_exit(wm8994); - regulator_bulk_disable(wm8994->num_supplies, - wm8994->supplies); + regulator_bulk_disable(wm8994->num_supplies, wm8994->supplies); } static const struct of_device_id wm8994_of_match[] = {
These can fit in a single line (80 columns), don't split lines unnecessarily. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- V1->V2: New patch --- drivers/mfd/wm8994-core.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.7.1.410.g6faf27b