Re: [GIT PULL] Two omap fixes for v3.18 merge window
On Fri, Oct 10, 2014 at 1:49 PM, Tony Lindgren t...@atomide.com wrote: The following changes since commit f86dc4b04dd5292cae3708c16ca6e46dbb5c95fa: Merge tag 'defconfig-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2014-10-08 17:38:52 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/fixes-for-v3.18-merge-window Merged, thanks. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: sbc-t3x: add DVI display data
Add DSS related pinmux and display data nodes required to support
DVI video out on SBC-T3530, SBC-T3730 and SBC-T3517.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap3-cm-t3517.dts | 22 +++
arch/arm/boot/dts/omap3-cm-t3530.dts | 22 +++
arch/arm/boot/dts/omap3-cm-t3730.dts | 24
arch/arm/boot/dts/omap3-cm-t3x.dtsi | 28 +++
arch/arm/boot/dts/omap3-sb-t35.dtsi | 49 +
arch/arm/boot/dts/omap3-sbc-t3517.dts | 14 +
arch/arm/boot/dts/omap3-sbc-t3530.dts | 14 +
arch/arm/boot/dts/omap3-sbc-t3730.dts | 14 +
8 files changed, 187 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-cm-t3517.dts
b/arch/arm/boot/dts/omap3-cm-t3517.dts
index d00502f..65abe17 100644
--- a/arch/arm/boot/dts/omap3-cm-t3517.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3517.dts
@@ -93,6 +93,17 @@
OMAP3_CORE1_IOPAD(0x2184, PIN_OUTPUT | MUX_MODE4)
/* mcbsp4_clkx.gpio_152 - USB HUB RST */
;
};
+
+ dss_dpi_pins_cm_t3517: pinmux_dss_dpi_pins_cm_t3517 {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)
/* dss_data0.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)
/* dss_data1.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)
/* dss_data2.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)
/* dss_data3.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)
/* dss_data4.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)
/* dss_data5.dss_data5 */
+ ;
+ };
};
hsusb1_phy {
@@ -134,3 +145,14 @@
bus-width = 4;
cap-power-off-card;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins_common
+ dss_dpi_pins_cm_t3517
+ ;
+};
+
diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
b/arch/arm/boot/dts/omap3-cm-t3530.dts
index d145849..c1465a4 100644
--- a/arch/arm/boot/dts/omap3-cm-t3530.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
@@ -36,6 +36,17 @@
OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
/* sdmmc2_dat7.sdmmc2_clkin */
;
};
+
+ dss_dpi_pins_cm_t3530: pinmux_dss_dpi_pins_cm_t3530 {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE0)
/* dss_data0.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE0)
/* dss_data1.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE0)
/* dss_data2.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE0)
/* dss_data3.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE0)
/* dss_data4.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE0)
/* dss_data5.dss_data5 */
+ ;
+ };
};
mmc2 {
@@ -46,3 +57,14 @@
bus-width = 4;
cap-power-off-card;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins_common
+ dss_dpi_pins_cm_t3530
+ ;
+};
+
diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts
b/arch/arm/boot/dts/omap3-cm-t3730.dts
index b3f9a50..4b36d80 100644
--- a/arch/arm/boot/dts/omap3-cm-t3730.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
@@ -31,6 +31,19 @@
};
};
+omap3_pmx_wkup {
+ dss_dpi_pins_cm_t3730: pinmux_dss_dpi_pins_cm_t3730 {
+ pinctrl-single,pins =
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18
*/
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19
*/
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20
*/
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21
*/
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22
*/
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23
*/
+ ;
+ };
+};
+
omap3_pmx_core {
mmc2_pins: pinmux_mmc2_pins {
@@ -61,3 +74,14 @@
bus-width = 4;
cap-power-off-card;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins_common
+ dss_dpi_pins_cm_t3730
+ ;
+};
+
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index c671a22..6b6c2f4 100644
---
Re: omap USB_DPLL not configured as per manual
On 10/14/2014 10:49 PM, Tero Kristo wrote: On 10/14/2014 01:47 PM, Roger Quadros wrote: Hi Tero, The USB_DPLL doesn't have recommended M/N settings as per the TRM [1] Thus the omapconf audit fails. Any ideas of how we can fix this up? Should we add a new clock.ops structure for USB_DPLL to make sure that we don't violate the TRM recommended settings? or should we just add some flags in dpll_data? We would need a new compatible id for sure. [1] - OMAP4460_ES1.x_NDA_TRM_vP.pdf - 3.6.3.9.5 DPLL_USB Preferred Settings The version of TRM I have doesn't have the recommended settings chapter, I need to download the doc. I guess we probably should introduce new fields to the dpll_data for this, does the TRM list an expected minimum divider / multiplier or just a single pair of recommended values? Do the other DPLLs have similar values? Looking at the DM I have here I see a recommended internal reference clock values for the DPLLs (min/max) and is calculated based on the refclk + N value. At least for the USB_DPLL it is single M:N pair for each possible sysclk frequency. For other DPLLs they seem to depend on OPP as well as sys_clk. cheers, -roger panda4460 omapconf audit dpll -d usb |-| | DPLL_USB AUDIT (@OPP OPP100, sysclk=38.4MHz) | Current Setting | Expected | STATUS | |-| | Status | Locked | Locked | Pass | | Mode | Lock| Lock | Pass | | Autoidle Mode| Auto LPST | Auto LPST | Pass | | Low-Power Mode | Disabled| Disabled | Pass | | REGM4XEN Mode| Disabled| Disabled | Pass | | DCC Mode | Disabled| Disabled | Pass | | M Divider| 25 | 400 | FAIL | | N Divider| 0 | 15 | FAIL | | Lock Frequency | 960.0MHz| 960.0MHz | Pass | | M2 Divider | 2 | 2 | Pass | | CLKOUT Output Rate | 480.0MHz| 480.0MHz | Pass | | CLKDCOLDO Output Rate| 960.0MHz| 960.0MHz | Pass | |-| cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 07/18] ASoC: codecs/hdmi: Mark the maximum significant bits to HDMI codec
On Tue, Oct 14, 2014 at 08:29:26PM +0300, Jyri Sarha wrote: HDMI audio can not have more than 24 bits even if on i2s bus there would be 32 bit samples. Mark this by adding .sig_bits = 24 to playback stream definition. Applied, thanks. Please use subject lines matching the style for the subsystem (no codecs/). signature.asc Description: Digital signature
Re: [PATCH v6 08/18] ASoC: codecs/hdmi: HDMI codec doesn't benefit from pmdown delay
On Tue, Oct 14, 2014 at 08:29:27PM +0300, Jyri Sarha wrote: Adds .ignore_pmdown_time = true to codec driver struct. HDMI codec is currently a dummy codec and doesn't benefit from pmdown delay. Even if in the future the codec would controll HDMI encoder, it would still be a digital to digital interface that should have no need for pmdown delay. Applied, thanks. signature.asc Description: Digital signature
Re: cpuidle and SW sleep
On Wed, Oct 15, 2014 at 10:25 AM, Ran Shalit ransha...@gmail.com wrote: Hello, Is there anyone who can please explain the relation between SW sleep (such as udelay), to change of C-state as done by cpuidle ? These are two different things, Ran. udelay is a way to put simple delay between two functions. The cpu will continue to perform other operations in a multithreded platform. CPUIdle sleep states are mainly to achieve power saving by programming cpus to difference states depending on how much time (estimated) a cpu is going to be idle with algorithm. So each state will have latency associated with it - enter, exit latency. If the cpu idle time falls within any of C-state's latency that will be programmed. In different state cpu will be programmed with different modes to achieve diff power saving. How is wakeup done ? As far as I understand udelay is sw delay not HW. System Wake up can be achieved by programming a wakeup source such as keypad. Thanks for you comments, Ran -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks and Regards Pramod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] video: fbdev: omap2: omapfb: remove __exit annotation
Hi,
On 14/10/14 21:28, Felipe Balbi wrote:
if we leave __exit annotation, driver can't be unbound
through sysfs.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index ec2d132..9cbf1ce 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -2619,7 +2619,7 @@ err0:
return r;
}
-static int __exit omapfb_remove(struct platform_device *pdev)
+static int omapfb_remove(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = platform_get_drvdata(pdev);
@@ -2636,7 +2636,7 @@ static int __exit omapfb_remove(struct platform_device
*pdev)
static struct platform_driver omapfb_driver = {
.probe = omapfb_probe,
- .remove = __exit_p(omapfb_remove),
+ .remove = omapfb_remove,
.driver = {
.name = omapfb,
.owner = THIS_MODULE,
Interesting. I don't know if I'm doing something funny, but without this
patch, I can unbind omapfb, kind of.
echo omapfb unbind goes ok, but remove is obviously not called.
Somehow omapfb device is still unbound from the driver, as I can then
bind it again, causing probe to be called. Which breaks everything.
I would've thought that unbinding is not possible if remove is missing,
but that doesn't seem to be the case. I guess it just means that remove
is not called when the driver device are unbound.
We have 18 __exit_p()s in omapdss and related drivers. I guess they are
all broken the same way.
Note that omapfb unbind bind does not work even with this patch, but
results in a crash as some old state is left into omapdss. The same
happens also with unloading and loading omapfb module (but keeping
omapdss module loaded).
So there seems to be more issues around this.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/3] video: fbdev: omap2: omapfb: add missing MODULE_ALIAS()
On 14/10/14 21:28, Felipe Balbi wrote: without MODULE_ALIAS(), omapfb won't get loaded automatically. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c index 9cbf1ce..b4b9244 100644 --- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c @@ -2651,6 +2651,7 @@ module_param_named(mirror, def_mirror, bool, 0); module_platform_driver(omapfb_driver); +MODULE_ALIAS(platform:omapfb); MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com); MODULE_DESCRIPTION(OMAP2/3 Framebuffer); MODULE_LICENSE(GPL v2); Thanks, I've queued this. Unfortunately it's somewhat based on luck if the automatic loading works correctly. We can't add more displays after omapfb has been probed, so all the panel and encoder drivers have to be loaded before omapfb. We have two workarounds there, which help the situation a bit. First is that if omapfb finds no displays, it returns EPROBE_DEFER. The second is that if there are displays, but no main display (display0), then omapfb returns EPROBE_DEFER. So even with these workarounds it is possible that drivers for secondary displays are loaded after omapfb, causing them to be ignored. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/3] arm: boot: dts: am437x-sk: fix lcd enable pin mux data
On 14/10/14 21:28, Felipe Balbi wrote:
Caused by a copy paste error. Note that even with
this bug AM437x SK display still works because GPIO
mux mode is always enabled. It's still wrong to mux
somebody else's pin.
Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
isn't used for anything.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-sk-evm.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 859ff3d..681be00 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -320,8 +320,7 @@
lcd_pins: lcd_pins {
pinctrl-single,pins =
- /* GPIO 5_8 to select LCD / HDMI */
- 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
+ 0x1c (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
gpcm_ad7.gpio1_7 */
;
};
};
I didn't verify the offset, but based on the comments this looks fine to me.
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/3] video: fbdev: omap2: omapfb: add missing MODULE_ALIAS()
On 14/10/14 21:34, Felipe Balbi wrote: On Tue, Oct 14, 2014 at 01:28:54PM -0500, Felipe Balbi wrote: without MODULE_ALIAS(), omapfb won't get loaded automatically. Signed-off-by: Felipe Balbi ba...@ti.com little note here. This makes omapfb load automatically, but display still doesn't work with DSS as modules. Backlight is working and pixel clock is running just fine. Still, nothing on display. I thought I'd leave that for Tomi to deal with. I presume this is about am437x-sk. I don't have the board, so there's not too much I can do except send emails. So the panel works fine if display drivers are built-in? The compatible string seems to be wrong in the .dts file. It says osddisplays,osd057T0559-34ts which is not the panel used. But that shouldn't affect this. What do you mean with pixel clock is running? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/3] video: fbdev: omap2: omapfb: add missing MODULE_ALIAS()
HI, On Wed, Oct 15, 2014 at 03:46:10PM +0300, Tomi Valkeinen wrote: On 14/10/14 21:34, Felipe Balbi wrote: On Tue, Oct 14, 2014 at 01:28:54PM -0500, Felipe Balbi wrote: without MODULE_ALIAS(), omapfb won't get loaded automatically. Signed-off-by: Felipe Balbi ba...@ti.com little note here. This makes omapfb load automatically, but display still doesn't work with DSS as modules. Backlight is working and pixel clock is running just fine. Still, nothing on display. I thought I'd leave that for Tomi to deal with. I presume this is about am437x-sk. I don't have the board, so there's not too much I can do except send emails. So the panel works fine if display drivers are built-in? yup. The compatible string seems to be wrong in the .dts file. It says osddisplays,osd057T0559-34ts which is not the panel used. But that shouldn't affect this. I got that from Darren, IIRC. Still, if it's wrong, it's wrong. What should it be ? What do you mean with pixel clock is running? poking at the pixel clock with a scope, I can see it clocking. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] video: fbdev: omap2: omapfb: add missing MODULE_ALIAS()
On Wed, Oct 15, 2014 at 03:20:19PM +0300, Tomi Valkeinen wrote: On 14/10/14 21:28, Felipe Balbi wrote: without MODULE_ALIAS(), omapfb won't get loaded automatically. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c index 9cbf1ce..b4b9244 100644 --- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c @@ -2651,6 +2651,7 @@ module_param_named(mirror, def_mirror, bool, 0); module_platform_driver(omapfb_driver); +MODULE_ALIAS(platform:omapfb); MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com); MODULE_DESCRIPTION(OMAP2/3 Framebuffer); MODULE_LICENSE(GPL v2); Thanks, I've queued this. Unfortunately it's somewhat based on luck if the automatic loading works correctly. We can't add more displays after omapfb has been probed, so all the panel and encoder drivers have to be loaded before omapfb. We have two workarounds there, which help the situation a bit. First is that if omapfb finds no displays, it returns EPROBE_DEFER. The second is that if there are displays, but no main display (display0), then omapfb returns EPROBE_DEFER. So even with these workarounds it is possible that drivers for secondary displays are loaded after omapfb, causing them to be ignored. then there is another case to fix, right ? :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] watchdog: Fix omap watchdogs to enable the magic close bit
On Tue, Oct 14, 2014 at 12:25:19PM -0700, Tony Lindgren wrote:
This allows testing the watchdog easily with distros just by
doing pkill -9 watchdog.
Reported-by: Thomas Dziedzic gos...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Reviewed-by: Felipe Balbi ba...@ti.com
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -189,7 +189,7 @@ static int omap_wdt_set_timeout(struct watchdog_device
*wdog,
}
static const struct watchdog_info omap_wdt_info = {
- .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
.identity = OMAP Watchdog,
};
--- a/drivers/watchdog/retu_wdt.c
+++ b/drivers/watchdog/retu_wdt.c
@@ -94,7 +94,7 @@ static int retu_wdt_set_timeout(struct watchdog_device
*wdog,
}
static const struct watchdog_info retu_wdt_info = {
- .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
.identity = Retu watchdog,
};
--- a/drivers/watchdog/twl4030_wdt.c
+++ b/drivers/watchdog/twl4030_wdt.c
@@ -57,7 +57,7 @@ static int twl4030_wdt_set_timeout(struct watchdog_device
*wdt,
}
static const struct watchdog_info twl4030_wdt_info = {
- .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
.identity = TWL4030 Watchdog,
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/3] video: fbdev: omap2: omapfb: remove __exit annotation
Hi,
On Wed, Oct 15, 2014 at 03:13:34PM +0300, Tomi Valkeinen wrote:
Hi,
On 14/10/14 21:28, Felipe Balbi wrote:
if we leave __exit annotation, driver can't be unbound
through sysfs.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index ec2d132..9cbf1ce 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -2619,7 +2619,7 @@ err0:
return r;
}
-static int __exit omapfb_remove(struct platform_device *pdev)
+static int omapfb_remove(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = platform_get_drvdata(pdev);
@@ -2636,7 +2636,7 @@ static int __exit omapfb_remove(struct
platform_device *pdev)
static struct platform_driver omapfb_driver = {
.probe = omapfb_probe,
- .remove = __exit_p(omapfb_remove),
+ .remove = omapfb_remove,
.driver = {
.name = omapfb,
.owner = THIS_MODULE,
Interesting. I don't know if I'm doing something funny, but without this
patch, I can unbind omapfb, kind of.
echo omapfb unbind goes ok, but remove is obviously not called.
remove isn't called because it won't exist if it's built-in. Look at the
definition of __exit_p()
Somehow omapfb device is still unbound from the driver, as I can then
bind it again, causing probe to be called. Which breaks everything.
I would've thought that unbinding is not possible if remove is missing,
but that doesn't seem to be the case. I guess it just means that remove
is not called when the driver device are unbound.
if no remove it provided on platform_driver structure, platform bus
assumes you have nothing to do on your -remove(), so you end up leaking
all resources you allocated on -probe() (unless you *really* don't need
to do anything on -remove).
We have 18 __exit_p()s in omapdss and related drivers. I guess they are
all broken the same way.
yup, I should've grepped.
Note that omapfb unbind bind does not work even with this patch, but
results in a crash as some old state is left into omapdss. The same
happens also with unloading and loading omapfb module (but keeping
omapdss module loaded).
It worked fine for me. I unbound and bound omapfb multiple times.
So there seems to be more issues around this.
quite a few more, I'd say
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7
Hi,
On Tue, Oct 14, 2014 at 10:25:00AM +0530, Vivek Gautam wrote:
Hi Felipe,
On Tue, Oct 14, 2014 at 4:14 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Oct 13, 2014 at 01:54:59PM +0900, Anton Tikhomirov wrote:
Hi Vivek,
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
by the driver. Adding only sclk is not enough.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 3951a65..7dc6a98 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
The clock clk in Exynos5 just gated all that above 7 clocks, which
we should control separately now in Exynos7.
should I drop this patch for now ?
Yes, better to hold this for some time till we get more clarity
from our h/w team.
now dropped. Please a new one if needed.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/3] video: fbdev: omap2: omapfb: remove __exit annotation
On 15/10/14 17:41, Felipe Balbi wrote: Interesting. I don't know if I'm doing something funny, but without this patch, I can unbind omapfb, kind of. echo omapfb unbind goes ok, but remove is obviously not called. remove isn't called because it won't exist if it's built-in. Look at the definition of __exit_p() Yes, that's what I meant with obviously. Somehow omapfb device is still unbound from the driver, as I can then bind it again, causing probe to be called. Which breaks everything. I would've thought that unbinding is not possible if remove is missing, but that doesn't seem to be the case. I guess it just means that remove is not called when the driver device are unbound. if no remove it provided on platform_driver structure, platform bus assumes you have nothing to do on your -remove(), so you end up leaking all resources you allocated on -probe() (unless you *really* don't need to do anything on -remove). Yep. That's quite odd, still. grep shows quite many uses of __exit_p(), and all for remove callback. So, if you have something to release in remove(), you should set it always, for both module and built-in. And if you don't have anything to release, you would always just set .release to NULL. I mean, what's the use case for __exit_p()? With a quick glance, at least some of the other users also use __exit_p() the same way omapdss does (i.e. in the wrong way). We have 18 __exit_p()s in omapdss and related drivers. I guess they are all broken the same way. yup, I should've grepped. Note that omapfb unbind bind does not work even with this patch, but results in a crash as some old state is left into omapdss. The same happens also with unloading and loading omapfb module (but keeping omapdss module loaded). It worked fine for me. I unbound and bound omapfb multiple times. Hmm, ok. Odd, the bug was quite clear and I think it should happen every time. Well, I was using omap4. If you used AM4xx, that's basically omap3 DSS. Maybe there's a diff there. So there seems to be more issues around this. quite a few more, I'd say Yep, I'll have a look at this. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/3] video: fbdev: omap2: omapfb: add missing MODULE_ALIAS()
On 15/10/14 17:38, Felipe Balbi wrote: On Wed, Oct 15, 2014 at 03:20:19PM +0300, Tomi Valkeinen wrote: On 14/10/14 21:28, Felipe Balbi wrote: without MODULE_ALIAS(), omapfb won't get loaded automatically. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c index 9cbf1ce..b4b9244 100644 --- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c @@ -2651,6 +2651,7 @@ module_param_named(mirror, def_mirror, bool, 0); module_platform_driver(omapfb_driver); +MODULE_ALIAS(platform:omapfb); MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@nokia.com); MODULE_DESCRIPTION(OMAP2/3 Framebuffer); MODULE_LICENSE(GPL v2); Thanks, I've queued this. Unfortunately it's somewhat based on luck if the automatic loading works correctly. We can't add more displays after omapfb has been probed, so all the panel and encoder drivers have to be loaded before omapfb. We have two workarounds there, which help the situation a bit. First is that if omapfb finds no displays, it returns EPROBE_DEFER. The second is that if there are displays, but no main display (display0), then omapfb returns EPROBE_DEFER. So even with these workarounds it is possible that drivers for secondary displays are loaded after omapfb, causing them to be ignored. then there is another case to fix, right ? :-) Yes, but don't hold your breath. The issue's been there for ages and no good solutions have been found. The same problem is there for omapdrm. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] video: fbdev: omap2: omapfb: remove __exit annotation
Hi, On Wed, Oct 15, 2014 at 06:43:40PM +0300, Tomi Valkeinen wrote: Somehow omapfb device is still unbound from the driver, as I can then bind it again, causing probe to be called. Which breaks everything. I would've thought that unbinding is not possible if remove is missing, but that doesn't seem to be the case. I guess it just means that remove is not called when the driver device are unbound. if no remove it provided on platform_driver structure, platform bus assumes you have nothing to do on your -remove(), so you end up leaking all resources you allocated on -probe() (unless you *really* don't need to do anything on -remove). Yep. That's quite odd, still. grep shows quite many uses of __exit_p(), and all for remove callback. So, if you have something to release in remove(), you should set it always, for both module and built-in. And if you don't have anything to release, you would always just set .release to NULL. I mean, what's the use case for __exit_p()? With a quick glance, at least some of the other users also use __exit_p() the same way omapdss does (i.e. in the wrong way). __exit_p() meant something else a few years back, perhaps those were left over from some tree-wide cleanups. We have 18 __exit_p()s in omapdss and related drivers. I guess they are all broken the same way. yup, I should've grepped. Note that omapfb unbind bind does not work even with this patch, but results in a crash as some old state is left into omapdss. The same happens also with unloading and loading omapfb module (but keeping omapdss module loaded). It worked fine for me. I unbound and bound omapfb multiple times. Hmm, ok. Odd, the bug was quite clear and I think it should happen every time. Well, I was using omap4. If you used AM4xx, that's basically omap3 DSS. Maybe there's a diff there. could very well be :-) So there seems to be more issues around this. quite a few more, I'd say Yep, I'll have a look at this. alright -- balbi signature.asc Description: Digital signature
Re: [PATCH 09/13] dmaengine: edma: check for echan-edesc = NULL in edma_dma_pause()
On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote:
I added book keeping of whether or not the 8250-dma driver has an RX
transfer pending or not so we don't BUG here if it calls
dmaengine_pause() on a channel which has not a pending transfer. Guess
what, this is not enough.
The following can be triggered with a busy RX channel and hackbench in
background:
- DMA transfer completes. The callback is delayed via
vchan_cookie_complete() into a tasklet so it das not happen asap.
- hackbench keeps the system busy so the tasklet does not run soon.
- the UART collected enough data and generates an timeout-interrupt.
Since 8250-dma *thinks* the DMA-transfer is still pending it tries to
cancel it via invoking dmaengine_pause() first. This causes the segfault
because echan-edesc is NULL now that the transfer completed (however
the callback did not run yet).
With this patch we don't BUG in the scenario described.
Applied thanks
--
~Vinod
Cc: vinod.k...@intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..123f578d6dd3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan,
static int edma_dma_pause(struct edma_chan *echan)
{
/* Pause/Resume only allowed with cyclic mode */
- if (!echan-edesc-cyclic)
+ if (!echan-edesc || !echan-edesc-cyclic)
return -EINVAL;
edma_pause(echan-ch_num);
--
2.1.0
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] dmaengine: edma: check for echan-edesc = NULL in edma_dma_pause()
On Mon, Sep 29, 2014 at 08:06:45PM +0200, Sebastian Andrzej Siewior wrote:
I added book keeping of whether or not the 8250-dma driver has an RX
transfer pending or not so we don't BUG here if it calls
dmaengine_pause() on a channel which has not a pending transfer. Guess
what, this is not enough.
The following can be triggered with a busy RX channel and hackbench in
background:
- DMA transfer completes. The callback is delayed via
vchan_cookie_complete() into a tasklet so it das not happen asap.
- hackbench keeps the system busy so the tasklet does not run soon.
- the UART collected enough data and generates an timeout-interrupt.
Since 8250-dma *thinks* the DMA-transfer is still pending it tries to
cancel it via invoking dmaengine_pause() first. This causes the segfault
because echan-edesc is NULL now that the transfer completed (however
the callback did not run yet).
With this patch we don't BUG in the scenario described.
Applied, thanks
--
~Vinod
Cc: vinod.k...@intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..123f578d6dd3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan,
static int edma_dma_pause(struct edma_chan *echan)
{
/* Pause/Resume only allowed with cyclic mode */
- if (!echan-edesc-cyclic)
+ if (!echan-edesc || !echan-edesc-cyclic)
return -EINVAL;
edma_pause(echan-ch_num);
--
2.1.0
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] rtc: omap: fixes and power-off feature
Hi, On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote: This series fixes a few issues with the omap rtc-driver, cleans up a bit and finally adds support for the PMIC control feature found in some revisions of this RTC IP block. Ultimately, this allows for powering off the Beaglebone and waking it up again on RTC alarms. I noticed yesterday that Lokesh Vutla recently posted some patches to add regulator support to this driver. [1] While that series has some issues that needs to be addressed, I still think it could be a good idea to rebase my pmic_power_en patch on top of it as it adds some long overdue device abstraction. That would be needed anyway in order to support the new power-off infrastructure that's in the pipe in a clean way. [2] So my suggestion is to merge the first seven patches, rebase Lokesh series on top of that, and then I rebase my final five patches on top of that in turn. Hopefully, the new power-off handler call chain will have stabilised by then. BTW, how do you test this series ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 00/12] rtc: omap: fixes and power-off feature
On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote: Hi, On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote: This series fixes a few issues with the omap rtc-driver, cleans up a bit and finally adds support for the PMIC control feature found in some revisions of this RTC IP block. Ultimately, this allows for powering off the Beaglebone and waking it up again on RTC alarms. I noticed yesterday that Lokesh Vutla recently posted some patches to add regulator support to this driver. [1] While that series has some issues that needs to be addressed, I still think it could be a good idea to rebase my pmic_power_en patch on top of it as it adds some long overdue device abstraction. That would be needed anyway in order to support the new power-off infrastructure that's in the pipe in a clean way. [2] So my suggestion is to merge the first seven patches, rebase Lokesh series on top of that, and then I rebase my final five patches on top of that in turn. Hopefully, the new power-off handler call chain will have stabilised by then. BTW, how do you test this series ? Set a 30 second wakealarm using the sysfs attribute of the rtc class device and power off the BBB: echo +30 wakealarm; poweroff Johan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] rtc: omap: fixes and power-off feature
On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote: On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote: Hi, On Thu, Oct 09, 2014 at 09:06:22PM +0200, Johan Hovold wrote: This series fixes a few issues with the omap rtc-driver, cleans up a bit and finally adds support for the PMIC control feature found in some revisions of this RTC IP block. Ultimately, this allows for powering off the Beaglebone and waking it up again on RTC alarms. I noticed yesterday that Lokesh Vutla recently posted some patches to add regulator support to this driver. [1] While that series has some issues that needs to be addressed, I still think it could be a good idea to rebase my pmic_power_en patch on top of it as it adds some long overdue device abstraction. That would be needed anyway in order to support the new power-off infrastructure that's in the pipe in a clean way. [2] So my suggestion is to merge the first seven patches, rebase Lokesh series on top of that, and then I rebase my final five patches on top of that in turn. Hopefully, the new power-off handler call chain will have stabilised by then. BTW, how do you test this series ? Set a 30 second wakealarm using the sysfs attribute of the rtc class device and power off the BBB: echo +30 wakealarm; poweroff sweet It worked just fine :-) Too bad there's yet another DRM bug: [ 271.150158] Kernel panic - not syncing: Attempted to kill init! exitcode=0x [ 271.150158] [ 271.159725] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.17.0-08392-g7fe2269-dirty #326 [ 271.168567] [c00175a4] (unwind_backtrace) from [c00132f0] (show_stack+0x20/0x24) [ 271.176668] [c00132f0] (show_stack) from [c06573a4] (dump_stack+0x8c/0xa4) [ 271.184215] [c06573a4] (dump_stack) from [c0654f10] (panic+0xa0/0x220) [ 271.191405] [c0654f10] (panic) from [c0049e54] (do_exit+0x974/0x9d0) [ 271.198410] [c0049e54] (do_exit) from [c0067694] (SyS_reboot+0x14c/0x1e8) [ 271.205870] [c0067694] (SyS_reboot) from [c000f080] (ret_fast_syscall+0x0/0x48) [ 271.214023] drm_kms_helper: panic occurred, switching back to text console [ 271.221312] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x In any case, board still powered up after 30 seconds(-ish). So this gets a: Tested-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: RCU bug with v3.17-rc3 ?
On Tue, Oct 14, 2014 at 04:06:40AM +0200, Greg KH wrote: On Mon, Oct 13, 2014 at 12:43:07PM +0100, Russell King - ARM Linux wrote: I think the only viable solution here is that: 1. We blacklist the bad compiler versions outright in the kernel. Yes, please do this, it's what we have done for other buggy compiler versions, no need to do something different here. Remember, it's the distro's choice to fix these buggy compilers, so the onus is on _them_ to deal with the mess they've created by doing so. I totally agree. Is someone going to send this patch, or do I have to write it myself? As I said, I have a patch in progress, but it seems that there needed to be some discussion about exactly which compiler versions are affected. It seems that it's not as trivial as looking at the GCC bug entry. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RCU bug with v3.17-rc3 ?
On Wed, Oct 15, 2014 at 10:23:10PM +0100, Russell King - ARM Linux wrote: As I said, I have a patch in progress, but it seems that there needed to be some discussion about exactly which compiler versions are affected. It seems that it's not as trivial as looking at the GCC bug entry. ... and in any case, it has been a known bug for well over a year now, and it seems that it doesn't affect _that_ many people. So taking some extra time to get it properly correct is the _right_ thing to do. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
These stock GCC versions miscompile the kernel by incorrectly optimising the function epilogue code - by first increasing the stack pointer, and then loading entries from below the stack. This means that an opportune interrupt or exception will corrupt the current function's saved state, which may result in the parent function seeing different register values. As this bug has been known to result in corrupted filesystems, and these buggy compiler versions seem to be frequently used, we have little option but to blacklist these compiler versions. Distributions may have fixed PR58854, but as their compilers are totally indistinguishable from the buggy versions, it is unfortunate that this also results in those also being blacklisted. Given the filesystem corruption potential of the original, this is the lesser evil. People who want to build with their fixed compiler versions will need to adjust the kernel source. (Distros need to think about the implications of fixing such a compiler bug, and consider how to ensure that their fixed compiler versions can be detected if they wish to avoid this.) Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- This is what I came up with - this places the build check right at the beginning of the kernel build, rather than at some point where linux/compiler.h gets included. Note that this is where we have previous ARM specific GCC version blacklisting. I'm blacklisting GCC 4.8.0 to GCC 4.8.2 inclussive, which seems to be the right versions for stock GCC. I was in two minds whether to include 4.8.3 as Linaro released a buggy toolchain which identifies itself as 4.8.3, but I decided that's also a distro problem. IMHO Linaro should really think about taking that compiler down given the seriousness of this bug and it being indistinguishable from the fixed stock version. arch/arm/kernel/asm-offsets.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c index 713e807621d2..e14c1a12b414 100644 --- a/arch/arm/kernel/asm-offsets.c +++ b/arch/arm/kernel/asm-offsets.c @@ -10,6 +10,7 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ +#include linux/compiler.h #include linux/sched.h #include linux/mm.h #include linux/dma-mapping.h @@ -39,10 +40,19 @@ * GCC 3.2.x: miscompiles NEW_AUX_ENT in fs/binfmt_elf.c *(http://gcc.gnu.org/PR8896) and incorrect structure * initialisation in fs/jffs2/erase.c + * GCC 4.8.0-4.8.2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 + * miscompiles find_get_entry(), and can result in EXT3 and EXT4 + * filesystem corruption (possibly other FS too). */ +#ifdef __GNUC__ #if (__GNUC__ == 3 __GNUC_MINOR__ 3) #error Your compiler is too buggy; it is known to miscompile kernels. -#errorKnown good compilers: 3.3 +#errorKnown good compilers: 3.3, 4.x +#endif +#if GCC_VERSION = 40800 || GCC_VERSION 40803 +#error Your compiler is too buggy; it is known to miscompile kernels +#error and result in filesystem corruption and oopses. +#endif #endif int main(void) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On 10/15/2014 05:56 PM, Russell King wrote: These stock GCC versions miscompile the kernel by incorrectly optimising the function epilogue code - by first increasing the stack pointer, and then loading entries from below the stack. This means that an opportune interrupt or exception will corrupt the current function's saved state, which may result in the parent function seeing different register values. As this bug has been known to result in corrupted filesystems, and these buggy compiler versions seem to be frequently used, we have little option but to blacklist these compiler versions. Distributions may have fixed PR58854, but as their compilers are totally indistinguishable from the buggy versions, it is unfortunate that this also results in those also being blacklisted. Given the filesystem corruption potential of the original, this is the lesser evil. People who want to build with their fixed compiler versions will need to adjust the kernel source. (Distros need to think about the implications of fixing such a compiler bug, and consider how to ensure that their fixed compiler versions can be detected if they wish to avoid this.) Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- This is what I came up with - this places the build check right at the beginning of the kernel build, rather than at some point where linux/compiler.h gets included. Note that this is where we have previous ARM specific GCC version blacklisting. I'm blacklisting GCC 4.8.0 to GCC 4.8.2 inclussive, which seems to be the right versions for stock GCC. I was in two minds whether to include 4.8.3 as Linaro released a buggy toolchain which identifies itself as 4.8.3, but I decided that's also a distro problem. IMHO Linaro should really think about taking that compiler down given the seriousness of this bug and it being indistinguishable from the fixed stock version. Maybe it's unfair to blame them; Linaro just took a snapshot and released what was there. If gcc is going to retain the change release number then add all the new features model, some kind of prerelease indicator would help eliminate this kind of problem. And that indicator should be both a preprocessor define and parseable from the command line :) arch/arm/kernel/asm-offsets.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c index 713e807621d2..e14c1a12b414 100644 --- a/arch/arm/kernel/asm-offsets.c +++ b/arch/arm/kernel/asm-offsets.c @@ -10,6 +10,7 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ +#include linux/compiler.h #include linux/sched.h #include linux/mm.h #include linux/dma-mapping.h @@ -39,10 +40,19 @@ * GCC 3.2.x: miscompiles NEW_AUX_ENT in fs/binfmt_elf.c *(http://gcc.gnu.org/PR8896) and incorrect structure * initialisation in fs/jffs2/erase.c + * GCC 4.8.0-4.8.2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 + * miscompiles find_get_entry(), and can result in EXT3 and EXT4 + * filesystem corruption (possibly other FS too). */ +#ifdef __GNUC__ #if (__GNUC__ == 3 __GNUC_MINOR__ 3) #error Your compiler is too buggy; it is known to miscompile kernels. -#errorKnown good compilers: 3.3 +#errorKnown good compilers: 3.3, 4.x +#endif +#if GCC_VERSION = 40800 || GCC_VERSION 40803 ^^ +#error Your compiler is too buggy; it is known to miscompile kernels +#error and result in filesystem corruption and oopses. +#endif #endif int main(void) Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On Wed, Oct 15, 2014 at 06:18:30PM -0400, Peter Hurley wrote: On 10/15/2014 05:56 PM, Russell King wrote: I was in two minds whether to include 4.8.3 as Linaro released a buggy toolchain which identifies itself as 4.8.3, but I decided that's also a distro problem. IMHO Linaro should really think about taking that compiler down given the seriousness of this bug and it being indistinguishable from the fixed stock version. Maybe it's unfair to blame them; Linaro just took a snapshot and released what was there. If gcc is going to retain the change release number then add all the new features model, some kind of prerelease indicator would help eliminate this kind of problem. And that indicator should be both a preprocessor define and parseable from the command line :) My comment is not to attribute blame to them, my comment is entirely on a technical level. My reasoning is that the bug is just as prevalent in userspace, though it will occur less often. Any program which uses signal handlers is a candidate for exactly the same kind of corruption, since you can receive that signal between the point that the stack pointer is modified and the function loads the parent context. Of course, there are ways around that: don't use signal handlers, or if you do, use alternate signal stacks. Neither of those can be guaranteed for any program though. So, let me put this another way: a compiler with this bug is _completely_ unsuitable for use for compiling programs for use under the Linux kernel _as well_ as the Linux kernel itself. The difference is that the Linaro compilers come with an expectation that they are usable on ARM... whereas stock versions cover a lot more and so the ARM arch is probably very small number of their users. Hence why I recommend that Linaro takes down their buggy compiler. Their 4.8.3 version should not be used *anywhere*, just the same as the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on ARM either. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On 10/15/2014 08:18 PM, Russell King - ARM Linux wrote: Hence why I recommend that Linaro takes down their buggy compiler. Their 4.8.3 version should not be used *anywhere*, just the same as the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on ARM either. Completely agree. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
