sh: ap325 camera without i2c driver fix
PATCH 1/1 sh: ap325 camera without i2c driver fix
From: Magnus Damm <[email protected]>
This patch fixes the ap325rxa ncm03j camera code to handle the case where no i2c driver is present. Without this fix i2c_transfer() may be passed NULL as adapter which results in a crash.
Triggered when i2c-sh_mobile.c failed to probe() due to missing MSTP clocks.
---
arch/sh/boards/board-ap325rxa.c | 3 +++ 1 file changed, 3 insertions(+)
arch/sh/boards/board-ap325rxa.c +3 -0
@@ -263,6 +263,9 @@ static int camera_probe(void)struct i2c_msg msg;int ret; +if (!a) +return -ENODEV ; +camera_power (1 ); msg.addr =0x6e ; msg.buf = camera_ncm03j_magic;
Quoted 7 lines · Magnus Damm
This patch fixes the ap325rxa ncm03j camera code to handle the case where no i2c driver is present. Without this fix
i2c_transfer()may be passed NULL as adapter which results in a crash.Triggered when
i2c-sh_mobile.cfailed toprobe()due to missing MSTP clocks.
Quoted 7 lines · Magnus Damm
This patch fixes the LCDC driver to avoid calling the function
sh_mobile_lcdc_start_stop(priv, 0)unless the same function has been called before to start the LCDC hardware.Triggered when
sh_mobile_lcdcfb.cfailed toprobe()due to missing MSTP clocks.
I was going to apply these, but as you provided no information as to what branch these should be applied to, I didn't bother. Is this a problem only in sh/clkfwk? Is this a problem with HEAD? Does it need to go in 2.6.30? If you are going to post a bunch of seemingly unrelated patches in one go, it helps to know what exactly you want done with them.
Quoted 15 lines · Paul Mundt
Quoted 7 lines · Magnus Damm
This patch fixes the ap325rxa ncm03j camera code to handle the case where no i2c driver is present. Without this fix
i2c_transfer()may be passed NULL as adapter which results in a crash.Triggered when
i2c-sh_mobile.cfailed toprobe()due to missing MSTP clocks.Quoted 5 lines · Magnus Damm
This patch fixes the LCDC driver to avoid calling the function
sh_mobile_lcdc_start_stop(priv, 0)unless the same function has been called before to start the LCDC hardware.
Quoted 8 lines
Quoted 2 lines
Triggered when
sh_mobile_lcdcfb.cfailed toprobe()due to missing MSTP clocks.I was going to apply these, but as you provided no information as to what branch these should be applied to, I didn't bother. Is this a problem only in sh/clkfwk? Is this a problem with HEAD? Does it need to go in 2.6.30? If you are going to post a bunch of seemingly unrelated patches in one go, it helps to know what exactly you want done with them.
These fixes are not sh/clkfwk specific. Does the branch modify these drivers?
Since they are not very critical I suggest adding them to 2.6.31, but if you're going to push things for 2.6.30 once more then you may include these as well.
Cheers,
/ magnus
Quoted 19 lines · Magnus Damm
Quoted 18 lines · Paul Mundt
Quoted 7 lines · Magnus Damm
This patch fixes the ap325rxa ncm03j camera code to handle the case where no i2c driver is present. Without this fix
i2c_transfer()may be passed NULL as adapter which results in a crash.Triggered when
i2c-sh_mobile.cfailed toprobe()due to missing MSTP clocks.Quoted 7 lines · Magnus Damm
This patch fixes the LCDC driver to avoid calling the function
sh_mobile_lcdc_start_stop(priv, 0)unless the same function has been called before to start the LCDC hardware.Triggered when
sh_mobile_lcdcfb.cfailed toprobe()due to missing MSTP clocks.
Quoted 8 lines
Quoted 5 lines
I was going to apply these, but as you provided no information as to what branch these should be applied to, I didn't bother. Is this a problem only in sh/clkfwk? Is this a problem with HEAD? Does it need to go in 2.6.30? If you are going to post a bunch of seemingly unrelated patches in one go, it helps to know what exactly you want done with them.
These fixes are not sh/clkfwk specific. Does the branch modify these drivers?
No, but there are plenty of MSTP related changes. If you are sending a set of patches where some are destined for some particular branch, you do need to specify precisely where you want them applied. If it's not immediately obvious, then they just aren't going to be applied, period.
Quoted 4 lines
Since they are not very critical I suggest adding them to 2.6.31, but if you're going to push things for 2.6.30 once more then you may include these as well.
I've rolled them in to the 2.6.30 queue now, thanks.