Re: [PATCH 2/9] omap: mux: Add new style pin multiplexing code for omap3

["Cousson, Benoit" <b-cousson@ti.com>]

On 8/27/2010 4:29 AM, rockefeller wrote:
> Hi Tony,
>     In the implementation of omap_mux_init_signal(char *muxname, int val)
> in arch/arm/mach-omap2/mux.c, it will modify the muxname of
> caller that passed in and not recover it, did you mean to implement
> to do so?(I try to explain my point of view as 2 examples below).

I'm not sure it was really done on purpose. It works today because none 
of the following cases are really happening.

>
> [Example 1]
> For a XIP device(NOR type), a caller function might be codeed like
> below:
>
> omap_mux_init_signal("muxname.mode7", 0xFFFF);
>
> and in this case, the string "muxname.mode7" might be a const string
> and not be modified.

That case seems to be a valid one.

>
> [Example 2]
> For a NAND device, a caller might be coded like below:
>
> static char *pin_mux_name = "muxname.mode7";
>
> function1()
> {
> omap_mux_init_signal(pin_mux_name, 0xFFFF);
> }
>
> function2()
> {
> omap_mux_init_signal(pin_mux_name, 0x0000);
> }
>
> void main()
> {
> function1();
> function2();
> }
>
> Because "muxname.mode7" in in RAM is modifiable, after function call
> to function1(), the *pine_mux_name will be "muxname" and therefore when
> calls to function2() to try to set this pin in mode7 with value 0x0000
> might be un-expected result.

In theory the pin mux is done once at init time, so I'm not sure this 
case is supposed to happen. Is it a real case?

Anyway, I think that a simple strlcpy(tmp, muxname, 32) in 
omap_mux_init_signal can fix it.

Do you mind submitting a patch to fix that?

Thanks,
Benoit