| Message ID | 1272923655-31807-1-git-send-email-timur@freescale.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Commit | 4c5ddd52695f7bac6362ad13fd3dc878212d1368 |
| Delegated to: | Kumar Gala |
| Headers | show |
On Mon, May 03, 2010 at 04:54:15PM -0500, Timur Tabi wrote: > { .compatible = "simple-bus", }, > - { .compatible = "gianfar", }, > + /* So that the DMA channel nodes can be probed individually: */ > + { .compatible = "fsl,eloplus-dma", }, > {} The removal of gianfar looks a bit surprising here - if it's not a mistake a note in the changelog would be useful.
Mark Brown wrote: > On Mon, May 03, 2010 at 04:54:15PM -0500, Timur Tabi wrote: > >> { .compatible = "simple-bus", }, >> - { .compatible = "gianfar", }, >> + /* So that the DMA channel nodes can be probed individually: */ >> + { .compatible = "fsl,eloplus-dma", }, >> {} > > The removal of gianfar looks a bit surprising here - if it's not a > mistake a note in the changelog would be useful. The changelog says this: Also remove the "gianfar" compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610. The 8610 is almost unique among our high-end PowerPC chips in that it literally has no on-board networking. The board provides networking via a PCI device.
On May 3, 2010, at 4:54 PM, Timur Tabi wrote: > A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual > DMA channel nodes, so the DMA controller nodes' compatible string must be listed > in mpc8610_ids[] for the probe to work. > > Also remove the "gianfar" compatible from mpc8610_ids[], since there is no > gianfar (or any other networking device) on the 8610. > > Signed-off-by: Timur Tabi <timur@freescale.com> > --- Acked-by: Kumar Gala <galak@kernel.crashing.org> - k
On Tue, May 04, 2010 at 10:11:34AM -0500, Timur Tabi wrote: > Also remove the "gianfar" compatible from mpc8610_ids[], since there is no > gianfar (or any other networking device) on the 8610. Meh, sorry. Though this is a very good example of why you shouldn't randomly mix unrelated changes into one patch :)
On Tue, May 04, 2010 at 12:20:13PM -0500, Kumar Gala wrote: > On May 3, 2010, at 4:54 PM, Timur Tabi wrote: > > A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual > > DMA channel nodes, so the DMA controller nodes' compatible string must be listed > > in mpc8610_ids[] for the probe to work. > > > > Also remove the "gianfar" compatible from mpc8610_ids[], since there is no > > gianfar (or any other networking device) on the 8610. > > > > Signed-off-by: Timur Tabi <timur@freescale.com> > Acked-by: Kumar Gala <galak@kernel.crashing.org> Just looking at the scheduling here with regard to the merge window and the fact that this doesn't seem to hurt the existing drivers perhaps it makes sense to merge this via the PowerPC tree immediately?
On Wed, May 5, 2010 at 6:22 AM, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > Just looking at the scheduling here with regard to the merge window and > the fact that this doesn't seem to hurt the existing drivers perhaps it > makes sense to merge this via the PowerPC tree immediately? Aren't we a little late in the cycle for a patch that doesn't do anything? I was expecting this patch to go into Liam's tree.
On Wed, May 05, 2010 at 06:39:01AM -0500, Timur Tabi wrote: > On Wed, May 5, 2010 at 6:22 AM, Mark Brown > > Just looking at the scheduling here with regard to the merge window and > > the fact that this doesn't seem to hurt the existing drivers perhaps it > > makes sense to merge this via the PowerPC tree immediately? > Aren't we a little late in the cycle for a patch that doesn't do anything? It seems to be safe enough for -next.
Mark Brown wrote: > On Wed, May 05, 2010 at 06:39:01AM -0500, Timur Tabi wrote: >> On Wed, May 5, 2010 at 6:22 AM, Mark Brown > >>> Just looking at the scheduling here with regard to the merge window and >>> the fact that this doesn't seem to hurt the existing drivers perhaps it >>> makes sense to merge this via the PowerPC tree immediately? > >> Aren't we a little late in the cycle for a patch that doesn't do anything? > > It seems to be safe enough for -next. Sure, -next is fine.
On May 3, 2010, at 4:54 PM, Timur Tabi wrote: > A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual > DMA channel nodes, so the DMA controller nodes' compatible string must be listed > in mpc8610_ids[] for the probe to work. > > Also remove the "gianfar" compatible from mpc8610_ids[], since there is no > gianfar (or any other networking device) on the 8610. > > Signed-off-by: Timur Tabi <timur@freescale.com> > --- > > Kumar, the ASoC mainters are willing to pick up this patch, but they want an > ACK from you first. Or, you could pick it up, since by itself it's harmless. > > arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) applied to next - k
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c index 5abe137..018cc67 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -83,7 +83,8 @@ static struct of_device_id __initdata mpc8610_ids[] = { { .compatible = "fsl,mpc8610-immr", }, { .compatible = "fsl,mpc8610-guts", }, { .compatible = "simple-bus", }, - { .compatible = "gianfar", }, + /* So that the DMA channel nodes can be probed individually: */ + { .compatible = "fsl,eloplus-dma", }, {} };
A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual DMA channel nodes, so the DMA controller nodes' compatible string must be listed in mpc8610_ids[] for the probe to work. Also remove the "gianfar" compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610. Signed-off-by: Timur Tabi <timur@freescale.com> --- Kumar, the ASoC mainters are willing to pick up this patch, but they want an ACK from you first. Or, you could pick it up, since by itself it's harmless. arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)