| Message ID | 1434362256-239992-7-git-send-email-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, 15 Jun 2015, Andy Shevchenko wrote: > The newly introduced device_for_each_child_reverse() would be used when MFD > core removes the device. > > After this patch applied the devices will be removed in a reversed order. This > behaviour is useful when devices have implicit dependency on order, i.e. > consider MFD device with serial bus controller, such as SPI, and DMA IP that is > attached to serial bus controller: before remove the DMA driver we have to be > ensured that no DMA transfers is ongoing and the requested channel are unused. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > drivers/mfd/mfd-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c > index 1aed3b7..79eeaa5 100644 > --- a/drivers/mfd/mfd-core.c > +++ b/drivers/mfd/mfd-core.c > @@ -300,7 +300,7 @@ void mfd_remove_devices(struct device *parent) > { > atomic_t *cnts = NULL; > > - device_for_each_child(parent, &cnts, mfd_remove_devices_fn); > + device_for_each_child_reverse(parent, &cnts, mfd_remove_devices_fn); > kfree(cnts); > } > EXPORT_SYMBOL(mfd_remove_devices);
On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: > On Mon, 15 Jun 2015, Andy Shevchenko wrote: > > > The newly introduced device_for_each_child_reverse() would be used > > when MFD > > core removes the device. > > > > After this patch applied the devices will be removed in a reversed > > order. This > > behaviour is useful when devices have implicit dependency on order, > > i.e. > > consider MFD device with serial bus controller, such as SPI, and > > DMA IP that is > > attached to serial bus controller: before remove the DMA driver we > > have to be > > ensured that no DMA transfers is ongoing and the requested channel > > are unused. > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > --- > > drivers/mfd/mfd-core.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Applied, thanks. Hmm… Seems kinda mistake. I can't see this applied (and required previous patches 4 and 5) to any of your branch neither in (today's) linux-next. > > > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c > > index 1aed3b7..79eeaa5 100644 > > --- a/drivers/mfd/mfd-core.c > > +++ b/drivers/mfd/mfd-core.c > > @@ -300,7 +300,7 @@ void mfd_remove_devices(struct device *parent) > > { > > atomic_t *cnts = NULL; > > > > - device_for_each_child(parent, &cnts, > > mfd_remove_devices_fn); > > + device_for_each_child_reverse(parent, &cnts, > > mfd_remove_devices_fn); > > kfree(cnts); > > } > > EXPORT_SYMBOL(mfd_remove_devices); >
On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: >> On Mon, 15 Jun 2015, Andy Shevchenko wrote: >> >> > The newly introduced device_for_each_child_reverse() would be used >> > when MFD >> > core removes the device. >> > >> > After this patch applied the devices will be removed in a reversed >> > order. This >> > behaviour is useful when devices have implicit dependency on order, >> > i.e. >> > consider MFD device with serial bus controller, such as SPI, and >> > DMA IP that is >> > attached to serial bus controller: before remove the DMA driver we >> > have to be >> > ensured that no DMA transfers is ongoing and the requested channel >> > are unused. >> > >> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> >> > --- >> > drivers/mfd/mfd-core.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Applied, thanks. > > Hmm… Seems kinda mistake. I can't see this applied (and required > previous patches 4 and 5) to any of your branch neither in (today's) > linux-next. New stuff applied after v4.1 couldn't show up in -next before v4.2-rc1 was released (which just happened last night)? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2015-07-06 at 11:24 +0200, Geert Uytterhoeven wrote: > On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: > > > On Mon, 15 Jun 2015, Andy Shevchenko wrote: > > > > > > > The newly introduced device_for_each_child_reverse() would be > > > > used > > > > when MFD > > > > core removes the device. > > > > > > > > After this patch applied the devices will be removed in a > > > > reversed > > > > order. This > > > > behaviour is useful when devices have implicit dependency on > > > > order, > > > > i.e. > > > > consider MFD device with serial bus controller, such as SPI, > > > > and > > > > DMA IP that is > > > > attached to serial bus controller: before remove the DMA driver > > > > we > > > > have to be > > > > ensured that no DMA transfers is ongoing and the requested > > > > channel > > > > are unused. > > > > > > > > Signed-off-by: Andy Shevchenko < > > > > andriy.shevchenko@linux.intel.com> > > > > --- > > > > drivers/mfd/mfd-core.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Applied, thanks. > > > > Hmm… Seems kinda mistake. I can't see this applied (and required > > previous patches 4 and 5) to any of your branch neither in > > (today's) > > linux-next. > > New stuff applied after v4.1 couldn't show up in -next before v4.2 > -rc1 was > released (which just happened last night)? Might be, I would like to resend new version of my series and that's why I would like to have a branch to check what is already applied. So, if I can't see it does it mean it is brewed in the private repository?
On Mon, 06 Jul 2015, Andy Shevchenko wrote: > On Mon, 2015-07-06 at 11:24 +0200, Geert Uytterhoeven wrote: > > On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: > > > > On Mon, 15 Jun 2015, Andy Shevchenko wrote: > > > > > > > > > The newly introduced device_for_each_child_reverse() would be > > > > > used > > > > > when MFD > > > > > core removes the device. > > > > > > > > > > After this patch applied the devices will be removed in a > > > > > reversed > > > > > order. This > > > > > behaviour is useful when devices have implicit dependency on > > > > > order, > > > > > i.e. > > > > > consider MFD device with serial bus controller, such as SPI, > > > > > and > > > > > DMA IP that is > > > > > attached to serial bus controller: before remove the DMA driver > > > > > we > > > > > have to be > > > > > ensured that no DMA transfers is ongoing and the requested > > > > > channel > > > > > are unused. > > > > > > > > > > Signed-off-by: Andy Shevchenko < > > > > > andriy.shevchenko@linux.intel.com> > > > > > --- > > > > > drivers/mfd/mfd-core.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > Applied, thanks. > > > > > > Hmm… Seems kinda mistake. I can't see this applied (and required > > > previous patches 4 and 5) to any of your branch neither in > > > (today's) > > > linux-next. > > > > New stuff applied after v4.1 couldn't show up in -next before v4.2 > > -rc1 was > > released (which just happened last night)? > > Might be, I would like to resend new version of my series and that's > why I would like to have a branch to check what is already applied. So, > if I can't see it does it mean it is brewed in the private repository? If you have patches that depend on this, they either need to come through my tree, or you have to wait until the next kernel version (which you probably don't want, right?). The alternative is that I unapply this patch and the whole lot can be sucked up by the most appropriate subsystem.
On Mon, Jul 6, 2015 at 5:50 PM, Lee Jones <lee.jones@linaro.org> wrote: > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > >> On Mon, 2015-07-06 at 11:24 +0200, Geert Uytterhoeven wrote: >> > On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko >> > <andriy.shevchenko@linux.intel.com> wrote: >> > > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: >> > > > On Mon, 15 Jun 2015, Andy Shevchenko wrote: [] >> > > > Applied, thanks. >> > > >> > > Hmm… Seems kinda mistake. I can't see this applied (and required >> > > previous patches 4 and 5) to any of your branch neither in >> > > (today's) >> > > linux-next. >> > >> > New stuff applied after v4.1 couldn't show up in -next before v4.2 >> > -rc1 was >> > released (which just happened last night)? >> >> Might be, I would like to resend new version of my series and that's >> why I would like to have a branch to check what is already applied. So, >> if I can't see it does it mean it is brewed in the private repository? > > If you have patches that depend on this, they either need to come > through my tree, or you have to wait until the next kernel version > (which you probably don't want, right?). > > The alternative is that I unapply this patch and the whole lot can be > sucked up by the most appropriate subsystem. I resent a new version for other comments(still with all patches included). Meanwhile the patches 4-6 (from v4 or v5, where they are the same) could be applied in the first place. Can you clarify what exactly you have applied? The idea is to put the rest via your subsystem since it's most appropriate for this series.
On Mon, 06 Jul 2015, Andy Shevchenko wrote: > On Mon, Jul 6, 2015 at 5:50 PM, Lee Jones <lee.jones@linaro.org> wrote: > > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > > > >> On Mon, 2015-07-06 at 11:24 +0200, Geert Uytterhoeven wrote: > >> > On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko > >> > <andriy.shevchenko@linux.intel.com> wrote: > >> > > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: > >> > > > On Mon, 15 Jun 2015, Andy Shevchenko wrote: > > [] > > >> > > > Applied, thanks. > >> > > > >> > > Hmm… Seems kinda mistake. I can't see this applied (and required > >> > > previous patches 4 and 5) to any of your branch neither in > >> > > (today's) > >> > > linux-next. > >> > > >> > New stuff applied after v4.1 couldn't show up in -next before v4.2 > >> > -rc1 was > >> > released (which just happened last night)? > >> > >> Might be, I would like to resend new version of my series and that's > >> why I would like to have a branch to check what is already applied. So, > >> if I can't see it does it mean it is brewed in the private repository? > > > > If you have patches that depend on this, they either need to come > > through my tree, or you have to wait until the next kernel version > > (which you probably don't want, right?). > > > > The alternative is that I unapply this patch and the whole lot can be > > sucked up by the most appropriate subsystem. > > I resent a new version for other comments(still with all patches > included). Meanwhile the patches 4-6 (from v4 or v5, where they are > the same) could be applied in the first place. Can you clarify what > exactly you have applied? The idea is to put the rest via your > subsystem since it's most appropriate for this series. Easiest thing for me to do is unapply. We can take the whole series when all the Acks have been accrued.
On Monday, July 06, 2015 05:05:29 PM Lee Jones wrote: > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > > > On Mon, Jul 6, 2015 at 5:50 PM, Lee Jones <lee.jones@linaro.org> wrote: > > > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > > > > > >> On Mon, 2015-07-06 at 11:24 +0200, Geert Uytterhoeven wrote: > > >> > On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko > > >> > <andriy.shevchenko@linux.intel.com> wrote: > > >> > > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: > > >> > > > On Mon, 15 Jun 2015, Andy Shevchenko wrote: > > > > [] > > > > >> > > > Applied, thanks. > > >> > > > > >> > > Hmm… Seems kinda mistake. I can't see this applied (and required > > >> > > previous patches 4 and 5) to any of your branch neither in > > >> > > (today's) > > >> > > linux-next. > > >> > > > >> > New stuff applied after v4.1 couldn't show up in -next before v4.2 > > >> > -rc1 was > > >> > released (which just happened last night)? > > >> > > >> Might be, I would like to resend new version of my series and that's > > >> why I would like to have a branch to check what is already applied. So, > > >> if I can't see it does it mean it is brewed in the private repository? > > > > > > If you have patches that depend on this, they either need to come > > > through my tree, or you have to wait until the next kernel version > > > (which you probably don't want, right?). > > > > > > The alternative is that I unapply this patch and the whole lot can be > > > sucked up by the most appropriate subsystem. > > > > I resent a new version for other comments(still with all patches > > included). Meanwhile the patches 4-6 (from v4 or v5, where they are > > the same) could be applied in the first place. Can you clarify what > > exactly you have applied? The idea is to put the rest via your > > subsystem since it's most appropriate for this series. > > Easiest thing for me to do is unapply. > > We can take the whole series when all the Acks have been accrued. So are there any ACKs missing from the last series posted by Andy? Rafael -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 07 Jul 2015, Rafael J. Wysocki wrote: > On Monday, July 06, 2015 05:05:29 PM Lee Jones wrote: > > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > > > > > On Mon, Jul 6, 2015 at 5:50 PM, Lee Jones <lee.jones@linaro.org> wrote: > > > > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > > > > > > > >> On Mon, 2015-07-06 at 11:24 +0200, Geert Uytterhoeven wrote: > > > >> > On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko > > > >> > <andriy.shevchenko@linux.intel.com> wrote: > > > >> > > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: > > > >> > > > On Mon, 15 Jun 2015, Andy Shevchenko wrote: > > > > > > [] > > > > > > >> > > > Applied, thanks. > > > >> > > > > > >> > > Hmm… Seems kinda mistake. I can't see this applied (and required > > > >> > > previous patches 4 and 5) to any of your branch neither in > > > >> > > (today's) > > > >> > > linux-next. > > > >> > > > > >> > New stuff applied after v4.1 couldn't show up in -next before v4.2 > > > >> > -rc1 was > > > >> > released (which just happened last night)? > > > >> > > > >> Might be, I would like to resend new version of my series and that's > > > >> why I would like to have a branch to check what is already applied. So, > > > >> if I can't see it does it mean it is brewed in the private repository? > > > > > > > > If you have patches that depend on this, they either need to come > > > > through my tree, or you have to wait until the next kernel version > > > > (which you probably don't want, right?). > > > > > > > > The alternative is that I unapply this patch and the whole lot can be > > > > sucked up by the most appropriate subsystem. > > > > > > I resent a new version for other comments(still with all patches > > > included). Meanwhile the patches 4-6 (from v4 or v5, where they are > > > the same) could be applied in the first place. Can you clarify what > > > exactly you have applied? The idea is to put the rest via your > > > subsystem since it's most appropriate for this series. > > > > Easiest thing for me to do is unapply. > > > > We can take the whole series when all the Acks have been accrued. > > So are there any ACKs missing from the last series posted by Andy? Yes, I have requested a Clk Ack, as there are some, lets say interesting code in the MFD driver which I am unsure about. However, we have caught Mike at an awkward time, as he is in the middle of transitioning jobs. Perhaps Stephen Boyd (now Cc'ed) might have a look.
On 07/06/2015 11:51 PM, Lee Jones wrote: > On Tue, 07 Jul 2015, Rafael J. Wysocki wrote: >> So are there any ACKs missing from the last series posted by Andy? > Yes, I have requested a Clk Ack, as there are some, lets say > interesting code in the MFD driver which I am unsure about. However, > we have caught Mike at an awkward time, as he is in the middle of > transitioning jobs. > > Perhaps Stephen Boyd (now Cc'ed) might have a look. > Context? I found the cover letter. clkdev is maintained by Russell. You could get his ack for the usage of the clkdev_create() API, but I'm not sure why it's needed. The API was merged into Linus' tree so I think you have everything you need. $ git tag -l --contains 2568999835d7797afce3dcc3a3f368051ffcaf1f v4* v4.2-rc1
On Tue, 07 Jul 2015, Stephen Boyd wrote: > On 07/06/2015 11:51 PM, Lee Jones wrote: > > On Tue, 07 Jul 2015, Rafael J. Wysocki wrote: > >> So are there any ACKs missing from the last series posted by Andy? > > Yes, I have requested a Clk Ack, as there are some, lets say > > interesting code in the MFD driver which I am unsure about. However, > > we have caught Mike at an awkward time, as he is in the middle of > > transitioning jobs. > > > > Perhaps Stephen Boyd (now Cc'ed) might have a look. > > > > Context? I found the cover letter. > > clkdev is maintained by Russell. You could get his ack for the usage of > the clkdev_create() API, but I'm not sure why it's needed. The API was > merged into Linus' tree so I think you have everything you need. > > $ git tag -l --contains 2568999835d7797afce3dcc3a3f368051ffcaf1f v4* > v4.2-rc1 mfd: Add support for Intel Sunrisepoint LPSS devices I also just bounced the original patch submission to you. I'm particularly concerned with the use of IDA to match clocks by name.
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c index 1aed3b7..79eeaa5 100644 --- a/drivers/mfd/mfd-core.c +++ b/drivers/mfd/mfd-core.c @@ -300,7 +300,7 @@ void mfd_remove_devices(struct device *parent) { atomic_t *cnts = NULL; - device_for_each_child(parent, &cnts, mfd_remove_devices_fn); + device_for_each_child_reverse(parent, &cnts, mfd_remove_devices_fn); kfree(cnts); } EXPORT_SYMBOL(mfd_remove_devices);
The newly introduced device_for_each_child_reverse() would be used when MFD core removes the device. After this patch applied the devices will be removed in a reversed order. This behaviour is useful when devices have implicit dependency on order, i.e. consider MFD device with serial bus controller, such as SPI, and DMA IP that is attached to serial bus controller: before remove the DMA driver we have to be ensured that no DMA transfers is ongoing and the requested channel are unused. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/mfd/mfd-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)