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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
