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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html