error: implicit declaration of function 'machine_is_ventana'

error: implicit declaration of function 'machine_is_ventana'

[Stephen Warren]

Russell,

Commit 46dcfc806a9f6834e6007449eac175f781058c49 "ARM: Update mach-types"
removed the entry for Ventana (2927). In turn, this broke compilation of
sound/soc/tegra/tegra_wm8903.c, since that calls machine_is_ventana().
It looks like the machine is still registered at
http://www.arm.linux.org.uk/developer/machines/. Can you explain what the
removal policy is for arch/arm/tools/mach-types?

Thanks!

-- 
nvpublic

error: implicit declaration of function 'machine_is_ventana'

[Russell King - ARM Linux]

On Mon, Aug 22, 2011 at 04:11:50PM -0700, Stephen Warren wrote:
> Russell,
> 
> Commit 46dcfc806a9f6834e6007449eac175f781058c49 "ARM: Update mach-types"
> removed the entry for Ventana (2927). In turn, this broke compilation of
> sound/soc/tegra/tegra_wm8903.c, since that calls machine_is_ventana().
> It looks like the machine is still registered at
> http://www.arm.linux.org.uk/developer/machines/. Can you explain what the
> removal policy is for arch/arm/tools/mach-types?

The policy has always been that the machine_is_xxx() matches the other
constants.  Rather than having to edit those out by hand, the script
now does this for me automatically.

This means any I've missed in previous updates are now missing.  And
if that means stuff was merged with the non-conforming entries, then
that's a problem.

It's not something I particularly care about because the responsibility
has always been on the submitter to talk to me if they want to change
those constants.  As they haven't talked to me...

Please submit a patch to fix your use in the kernel, including updating
the mach-types file to conform.  I'll then fix the machine registry by
hand.

error: implicit declaration of function 'machine_is_ventana'

[Stephen Warren]

Russell King wrote at Monday, August 22, 2011 5:40 PM:
> On Mon, Aug 22, 2011 at 04:11:50PM -0700, Stephen Warren wrote:
> > Russell,
> >
> > Commit 46dcfc806a9f6834e6007449eac175f781058c49 "ARM: Update mach-types"
> > removed the entry for Ventana (2927). In turn, this broke compilation of
> > sound/soc/tegra/tegra_wm8903.c, since that calls machine_is_ventana().
> > It looks like the machine is still registered at
> > http://www.arm.linux.org.uk/developer/machines/. Can you explain what the
> > removal policy is for arch/arm/tools/mach-types?
> 
> The policy has always been that the machine_is_xxx() matches the other
> constants.  Rather than having to edit those out by hand, the script
> now does this for me automatically.

I'm very sorry for being so dense, but what "other constants" must the
entry match?

For reference, here's the entry I'm referring to:

-ventana                        MACH_VENTANA            VENTANA                 2927

... which seems to use the name "ventana" consistently, if that's what
you mean.

...
> Please submit a patch to fix your use in the kernel, including updating
> the mach-types file to conform.  I'll then fix the machine registry by
> hand.

I will happily submit the patch, once I understand exactly what needs to
change. Thanks for any enlightenment!

-- 
nvpublic

error: implicit declaration of function 'machine_is_ventana'

[Russell King - ARM Linux]

On Mon, Aug 22, 2011 at 04:49:06PM -0700, Stephen Warren wrote:
> Russell King wrote at Monday, August 22, 2011 5:40 PM:
> > On Mon, Aug 22, 2011 at 04:11:50PM -0700, Stephen Warren wrote:
> > > Russell,
> > >
> > > Commit 46dcfc806a9f6834e6007449eac175f781058c49 "ARM: Update mach-types"
> > > removed the entry for Ventana (2927). In turn, this broke compilation of
> > > sound/soc/tegra/tegra_wm8903.c, since that calls machine_is_ventana().
> > > It looks like the machine is still registered at
> > > http://www.arm.linux.org.uk/developer/machines/. Can you explain what the
> > > removal policy is for arch/arm/tools/mach-types?
> > 
> > The policy has always been that the machine_is_xxx() matches the other
> > constants.  Rather than having to edit those out by hand, the script
> > now does this for me automatically.
> 
> I'm very sorry for being so dense, but what "other constants" must the
> entry match?
> 
> For reference, here's the entry I'm referring to:
> 
> -ventana                        MACH_VENTANA            VENTANA                 2927
> 
> ... which seems to use the name "ventana" consistently, if that's what
> you mean.
> 
> ...
> > Please submit a patch to fix your use in the kernel, including updating
> > the mach-types file to conform.  I'll then fix the machine registry by
> > hand.
> 
> I will happily submit the patch, once I understand exactly what needs to
> change. Thanks for any enlightenment!

Ah, sorry, I thought you were talking about a platform which was merged
into mainline.  This platform is not present in mainline, so accordingly
it isn't marked as such in the machine database.

Any entry not marked as being present in mainline will be removed after
12 months after it was last touched - which apparantly was 18th June
2010.

So, the questions are:
1. why do we have driver code merged for a platform which shows no sign
   of being merged.
2. why do we have drivers depending on their platform anyway.

error: implicit declaration of function 'machine_is_ventana'

[Stephen Warren]

Russell King wrote at Monday, August 22, 2011 6:02 PM:
> On Mon, Aug 22, 2011 at 04:49:06PM -0700, Stephen Warren wrote:
> > Russell King wrote at Monday, August 22, 2011 5:40 PM:
> > > On Mon, Aug 22, 2011 at 04:11:50PM -0700, Stephen Warren wrote:
> > > > Russell,
> > > >
> > > > Commit 46dcfc806a9f6834e6007449eac175f781058c49 "ARM: Update mach-types"
> > > > removed the entry for Ventana (2927). In turn, this broke compilation of
> > > > sound/soc/tegra/tegra_wm8903.c, since that calls machine_is_ventana().
> > > > It looks like the machine is still registered at
> > > > http://www.arm.linux.org.uk/developer/machines/. Can you explain what the
> > > > removal policy is for arch/arm/tools/mach-types?
...
> Ah, sorry, I thought you were talking about a platform which was merged
> into mainline.  This platform is not present in mainline, so accordingly
> it isn't marked as such in the machine database.
> 
> Any entry not marked as being present in mainline will be removed after
> 12 months after it was last touched - which apparantly was 18th June
> 2010.

Ah, that I can understand.

> So, the questions are:
> 1. why do we have driver code merged for a platform which shows no sign
>    of being merged.

Well, I or someone probably would have pushed Ventana support into
mainline within the last few months, since it's pretty similar to Harmony
and Seaboard which are both already supported. However, I've been holding
due to the no-new-board-files thing, until Device-Tree gets fully baked,
and we can then support the board just by adding a simple .dts file.

> 2. why do we have drivers depending on their platform anyway.

The ASoC subsystem defines a "machine driver", which defines facets of
the audio system such as which pins on the audio codec are connected to
the headphone jack. This varies between boards, so the "machine driver"
picks the appropriate routing table at run-time based on the board that
the code is running on. Arguably, one could represent all this data in
board files using platform data, but IIUC, the ASoC maintainers prefer
to keep it all centralized in the sound directory tree.

I understand from Grant Likely that John Bonesio will be posting a patch
in the very near future to retrieve all this data from Device Tree, so
this won't be an issue moving forward, given that Tegra will probably
switch to Device Tree pretty aggressively.

Still, I suppose we could rip out explicit support for Ventana in the
sound driver in the interim if you want, rather than adding back the
Ventana machine definition.

-- 
nvpublic

error: implicit declaration of function 'machine_is_ventana'

[Russell King - ARM Linux]

On Mon, Aug 22, 2011 at 05:11:54PM -0700, Stephen Warren wrote:
> Russell King wrote at Monday, August 22, 2011 6:02 PM:
> > Any entry not marked as being present in mainline will be removed after
> > 12 months after it was last touched - which apparantly was 18th June
> > 2010.
> 
> Ah, that I can understand.
> 
> > So, the questions are:
> > 1. why do we have driver code merged for a platform which shows no sign
> >    of being merged.
> 
> Well, I or someone probably would have pushed Ventana support into
> mainline within the last few months, since it's pretty similar to Harmony
> and Seaboard which are both already supported. However, I've been holding
> due to the no-new-board-files thing, until Device-Tree gets fully baked,
> and we can then support the board just by adding a simple .dts file.
> 
> > 2. why do we have drivers depending on their platform anyway.
> 
> The ASoC subsystem defines a "machine driver", which defines facets of
> the audio system such as which pins on the audio codec are connected to
> the headphone jack. This varies between boards, so the "machine driver"
> picks the appropriate routing table at run-time based on the board that
> the code is running on. Arguably, one could represent all this data in
> board files using platform data, but IIUC, the ASoC maintainers prefer
> to keep it all centralized in the sound directory tree.
> 
> I understand from Grant Likely that John Bonesio will be posting a patch
> in the very near future to retrieve all this data from Device Tree, so
> this won't be an issue moving forward, given that Tegra will probably
> switch to Device Tree pretty aggressively.
> 
> Still, I suppose we could rip out explicit support for Ventana in the
> sound driver in the interim if you want, rather than adding back the
> Ventana machine definition.

Given that you're the second one to report breakage, I think it's probably
better if I drop the mach-types update from my 'fixes' branch, and punt
it into the stuff for the next merge window.

That means that the PXA stuff which was inappropriately merged without
its mach-type entry will stay broken until after the next merge window.
Unfortunate, but I'm not seeing much other option other than me having
to put lots of time into manually sorting out a mach-types update (which
I don't have the time nor motivation to do at the moment.)