On Wed, 31 Aug 2016, Marcin Niestroj wrote:
> On 31.08.2016 13:17, Lee Jones wrote:
> > On Wed, 31 Aug 2016, Marcin Niestroj wrote:
> >
> > > On 30.08.2016 11:50, Lee Jones wrote:
> > > > On Tue, 30 Aug 2016, Marcin Niestroj wrote:
> > > >
> > > > > On 30.08.2016 11:03, Lee Jones wrote:
> > > > > > On Mon, 29 Aug 2016, Marcin Niestroj wrote:
> > > > > >
> > > > > > > ping
> > > > > >
> > > > > > Don't do that!
> > > > > >
> > > > > > If you think the patch hasn't attracted attention in >2 weeks, then
> > > > > > it's probably slipped through the gaps and you need to send a
> > > > > > [RESEND].
> > > > >
> > > > > Clear.
> > > > >
> > > > > >
> > > > > > However ...
> > > > > >
> > > > > > > On 20.06.2016 12:50, Marcin Niestroj wrote:
> > > > > > > > Add tps65217 power buttor subdevice with assigned IRQ resources.
> > > > > > > >
> > > > > > > > Signed-off-by: Marcin Niestroj <m.niestroj@xxxxxxxxxxxxxxxx>
> > > > > > > > Acked-by: Lee Jones <lee.jones@xxxxxxxxxx>
> > > > > >
> > > > > > This patch has a maintainer Ack, so why are you pinging?
> > > > >
> > > > > Because I didn't see it applied anywhere and there were no new
> > > > > comments, so I thought it slipped somewhere.
> > > > >
> > > > > So my question is: what happens with the patch after maintainer Ack?
> > > > > Are we still waiting for some comments from the community? Do I still
> > > > > need to worry, that the patch might slipped? What is author's role now?
> > > >
> > > > Since you sent the patches as a set, it is assumed there are some
> > > > dependencies between them, or they are at least in some way related.
> > > > To that end, it is normal for Maintainers (especially for me as the
> > > > MFD Maintainer, since there often some complex ties into the leaf
> > > > driver's changes) to wait until *all* of the patches have either been
> > > > accepted or have acquired an Ack of their own to proceed.
> > > >
> > > > I believe we are still waiting on other patches to be reviewed, no?
> > >
> > > I've just noticed, that patch 5 was only partially Acked.
> > >
> > > I will send a RESEND. However patch 2 is already in mainline. Should I
> > > contain this patch or remove it from the patch set? Additionally
> > > patch 3 has been queued into power-supply's -next branch.
> >
> > You should rebase the set and drop any patches which have already been
> > applied.
>
> So include or drop patch 3?
You said it's been applied, so drop it.
> > > > > > > > ---
> > > > > > > > Depends on patch 1 in series
> > > > > > > >
> > > > > > > > Changes v1 -> v4: none
> > > > > > > >
> > > > > > > > drivers/mfd/tps65217.c | 10 ++++++++++
> > > > > > > > 1 file changed, 10 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> > > > > > > > index 41b5d59..57c8741 100644
> > > > > > > > --- a/drivers/mfd/tps65217.c
> > > > > > > > +++ b/drivers/mfd/tps65217.c
> > > > > > > > @@ -38,6 +38,10 @@ static struct resource charger_resources[] = {
> > > > > > > > DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_USB, "USB"),
> > > > > > > > };
> > > > > > > >
> > > > > > > > +static struct resource pb_resources[] = {
> > > > > > > > + DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_PB, "PB"),
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > struct tps65217_irq {
> > > > > > > > int mask;
> > > > > > > > int interrupt;
> > > > > > > > @@ -122,6 +126,12 @@ static struct mfd_cell tps65217s[] = {
> > > > > > > > .resources = charger_resources,
> > > > > > > > .of_compatible = "ti,tps65217-charger",
> > > > > > > > },
> > > > > > > > + {
> > > > > > > > + .name = "tps65217-pwrbutton",
> > > > > > > > + .num_resources = ARRAY_SIZE(pb_resources),
> > > > > > > > + .resources = pb_resources,
> > > > > > > > + .of_compatible = "ti,tps65217-pwrbutton",
> > > > > > > > + },
> > > > > > > > };
> > > > > > > >
> > > > > > > > static irqreturn_t tps65217_irq_thread(int irq, void *data)
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
