- Dec 19, 2013
-
-
Tony Lindgren authored
This adds support for CompuLab SBC-T3530, also known as cm-t3730: http://compulab.co.il/products/sbcs/sbc-t3530/ It seems that with the sbc-3xxx mainboard is also used on SBC-T3517 and SBC-T3730 with just a different CPU module: http://compulab.co.il/products/sbcs/sbc-t3517/ http://compulab.co.il/products/sbcs/sbc-t3730/ So let's add a common omap3-sb-t35.dtsi and then separate SoC specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and omap3-sbc-t3517.dts. I've tested this with SBC-T3730 as that's the only one I have. At least serial, both Ethernet controllers, MMC, and wl12xx WLAN work. Note that WLAN seems to be different for SBC-T3530. And SBC-T3517 may need some changes for the EMAC Ethernet if that's used instead of the smsc911x. Cc: devicetree@vger.kernel.org Cc: Mike Rapoport <mike@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- Dec 09, 2013
-
-
Tony Lindgren authored
Let's add the Ethernet so NFSroot works and the first MMC card so people can patch in more support easily. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
As the emac uses the system control module registers for reset and interrupts, we need to pass those in the platform data until we have a separate system control module driver. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
As we currently need to support a mix of legacy platform data and device tree intialized data, let's make sure things keep working for the TWL GPIOs. Mostly the issue is caused by the fact that DSS does not yet have device tree bindings, so we need to rely on the TWL GPIO callback for setting up things like LCD backlight for some boards. As of_platform_populate() for the TWL GPIO is called by twl-core after the I2C bus has been initialized, we cannot pass the auxdata table from the board init code to twl-core like we used to with just legacy platform data. So let's use the omap_device bus hook to patch in the platform data for TWL GPIO until we have sorted out the issues with the TWL GPIOs and device tree bindings. The other option was be to initialize twl core using legacy platform data, which seems like a step backwards as we're moving to device tree only initialization. And we really don't want to add custom configuration functions to the TWL GPIO driver either for this. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- Dec 07, 2013
-
-
Tony Lindgren authored
Commit 7ce93f31 (ARM: OMAP2+: Fix more missing data for omap3.dtsi file) fixed missing device tree data for omaps, but did not account for some of the hardware modules being inaccessible for secure omaps. This causes the following error on secure omaps: Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0c5048 SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0-rc2+ #446 task: ce057b40 ti: ce058000 task.ti: ce058000 PC is at omap_aes_dma_stop+0x24/0x3c LR is at omap_aes_probe+0x1cc/0x584 psr: 60000113 sp : ce059e20 ip : ce0b4ee0 fp : 00000000 r10: c0573ae8 r9 : c0749508 r8 : 00000000 r7 : ce0b4e00 r6 : 00000000 r5 : ce0b4e10 r4 : ce274890 r3 : fa0c5048 r2 : 00000048 r1 : 0000002c r0 : ce274890 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xce058248) Stack: (0xce059e20 to 0xce05a000) 9e20: c0749508 0000a1ff 00000000 c016cd8c c06b5a06 ce2a45f0 ce2a4570 ce0b5fb0 9e40: 00000000 480c5000 480c504f c0abe4e4 00000200 00000000 00000000 00000000 9e60: ce0b4e10 ce0b4e10 c082da3c c082da3c c02b8c70 c077c610 c0749508 00000000 9e80: 00000000 c02b9e7c c02b9e64 ce0b4e10 00000000 c02b8b20 ce0b4e10 ce0b4e44 9ea0: c082da3c c02b8cd8 00000000 ce059eb8 c082da3c c02b7408 ce079edc ce0b1a34 9ec0: c082da3c c082da3c ce2a0280 00000000 c08158d8 c02b8358 c0663405 c0663405 9ee0: 00000073 c082da3c c079e4e8 c07ab3bc c0844340 c02b9334 00000000 00000006 9f00: c079e4e8 c0008920 c067f6bf c0ac7c6b 00000000 c0712e28 00000000 00000000 9f20: c0712e38 ce059f38 00000093 c0ac7c82 00000000 c0058994 00000000 c07130e8 9f40: c07127b8 00000093 00000006 00000006 00000001 00000006 00000006 c079e4e8 9f60: c07ab3bc c0844340 00000093 c0749508 c079e4f4 c0749c64 00000006 00000006 9f80: c0749508 00000000 00000000 c0517e2c 00000000 00000000 00000000 00000000 9fa0: 00000000 c0517e34 00000000 c000dfb8 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff (omap_aes_probe+0x1cc/0x584) (platform_drv_probe+0x18/0x48) (driver_probe_device+0xb0/0x200) (__driver_attach+0x68/0x8c) (bus_for_each_dev+0x50/0x88) (bus_add_driver+0xcc/0x1c8) (driver_register+0x9c/0xe0) (do_one_initcall+0x98/0x140) (kernel_init_freeable+0x16c/0x23c) (kernel_init+0x8/0x100) (ret_from_fork+0x14/0x3c) Code: e1811002 e5932020 e590300c e0833002 (e593c000) Let's fix the issue by adding omap34xx-hs.dtsi and omap36xx-hs.dtsi and make n900, n9 and n950 to use them. This way we have the aes, sham and timer12 disabled for secure devices the same way legacy booting does based on the omap34xx_gp_hwmod_ocp_ifs and omap36xx_gp_hwmod_ocp_ifs arrays in omap_hwmod_3xxx_data.c. Reported-by: Sebastian Reichel <sre@debian.org> Acked-By: Sebastian Reichel <sre@debian.org> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Nishanth Menon authored
The am3517 is wrongly booting as omap3 which means that the am3517 specific devices like Ethernet won't work when booted with device tree. Now with the new devices defined in am3517.dtsi, let's use that instead of the omap3.dtsi, and add a separate machine entry for am3517 so am3517-evm can use it. Signed-off-by: Nishanth Menon <nm@ti.com> [tony@atomide.com: updated comments and fixed build without omap3] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
On am3517 there are some extra devices compared to omap3.dtsi that we currently have not defined. Let's fix that by adding am3517.dtsi file. Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
We have some device tree properties where the ti,hwmod have multiple values: am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2"; omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone"; omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone"; omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3"; omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3"; That's not correct way of doing things in this case because these are separate devices with their own address space, interrupts, SYSCONFIG registers and can set their PM states independently. So they should all be fixed up to be separate devices in the .dts files. We also have the related data removed for at least omap4 in commit 3b9b1015 (ARM: OMAP4: hwmod data: Clean up the data file), so that data is wrongly initialized as null data. So we need to fix two bugs: 1. We are only checking the first entry of the ti,hwmods property This means that we're only initializing the first hwmods entry instead of the ones listed in the ti,hwmods property. 2. We are only checking the child nodes, not the nodes themselves This means that anything listed at OCP level is currently just ignored and unitialized and at least the omap4 case, with the legacy data missing from the hwmod. Fix both of the issues by using an index to the ti,hwmods property and changing the hwmod lookup function to also check the current node for ti,hwmods property instead of just the children. While at it, let's also add some warnings for the bad data so it's easier to fix. Cc: "Benoît Cousson" <bcousson@baylibre.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- Dec 05, 2013
-
-
Fenghua Yu authored
Since erratum AVR31 in "Intel Atom Processor C2000 Product Family Specification Update" is now published, I added a justification comment for disabling IO APIC before Local APIC, as changed in commit: 522e6646 x86/apic: Disable I/O APIC before shutdown of the local APIC Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Link: http://lkml.kernel.org/r/1386202069-51515-1-git-send-email-fenghua.yu@intel.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
-
H. Peter Anvin authored
In checkin: 0c44c2d0 x86: Use asm goto to implement better modify_and_test() functions the various functions which do modify and test were unified and optimized using "asm goto". However, this change missed the detail that the bitops require an "Ir" constraint rather than an "er" constraint ("I" = integer constant from 0-31, "e" = signed 32-bit integer constant). This would cause code to miscompile if these functions were used on constant bit positions 32-255 and the build to fail if used on constant bit positions above 255. Add the constraints as a parameter to the GEN_BINARY_RMWcc() macro to avoid this problem. Reported-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/529E8719.4070202@zytor.com
-
- Dec 04, 2013
-
-
H. Peter Anvin authored
Always pass in the -mno-sse argument, regardless if -preferred-stack-boundary is supported. We never want to generate SSE instructions in the kernel unless we *really* know what we're doing. According to H. J. Lu, any version of gcc new enough that we support it at all should handle the -mno-sse option, so just add it unconditionally. Reported-by: Kevin B. Smith <kevin.b.smith@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: H. J. Lu <hjl.tools@gmail.com> Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org Cc: <stable@vger.kernel.org> # build fix only
-
Helge Deller authored
Signed-off-by: Helge Deller <deller@gmx.de>
-
Dinh Nguyen authored
Some of the clocks that were designated gate-clk do not have a gate, so change those clocks to be of periph-clk type. Signed-off-by: Dinh Nguyen <dinguyen@altera.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Dinh Nguyen authored
Update Kconfig to enable TWD. Signed-off-by: Dinh Nguyen <dinguyen@altera.com> Reviewed-by: Pavel Machek <pavel@denx.de> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Olof Johansson authored
Enable MMC/SD on the Broadcom mobile platforms, and increase the block minors from the default 8 to 16 (since the Broadcom board by default has root on the 8th partition). Signed-off-by: Olof Johansson <olof@lixom.net> Cc: stable@vger.kernel.org # v3.12
-
Olof Johansson authored
This enables a few more options on the sunxi defconfigs such that I can use nfsroot to boot them (there is no local storage support yet). It also enables PRINTK_TIME and tmpfs since it's a common distro requirement. Signed-off-by: Olof Johansson <olof@lixom.net>
-
Olof Johansson authored
BeagleBone Black uses the TI CPSW ethernet controller, enable it in the multi_v7_defconfig for testing coverage purposes. Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Tony Lindgren <tony@atomide.com> Cc: stable@vger.kernel.org # v3.12
-
- Dec 03, 2013
-
-
Florian Vaussard authored
drivers/net/ethernet/smsc/smsc911x.c is expecting supplies named "vdd33a" and "vddvario". Currently the shared DTS file provides "vmmc" and "vmmc_aux", and the supply lookup will fail: smsc911x 2c000000.ethernet: Looking up vdd33a-supply from device tree smsc911x 2c000000.ethernet: Looking up vdd33a-supply property in node /ocp/gpmc@6e000000/ethernet@gpmc failed smsc911x 2c000000.ethernet: Looking up vddvario-supply from device tree smsc911x 2c000000.ethernet: Looking up vddvario-supply property in node /ocp/gpmc@6e000000/ethernet@gpmc failed Fix it! Looks like commmit 6b2978ac (ARM: dts: Shared file for omap GPMC connected smsc911x) made the problem more visible by moving the smc911x configuration from the omap3-igep0020.dts file to the generic file. But it seems we've had this problem since commit d72b4415 (ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support). Tested on OMAP3 Overo platform. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> [tony@atomide.com: updated comments for the commits causing the problem] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Rajendra Nayak authored
Commit 'cd8abed1' "ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm" leads to the following Smatch complaint: arch/arm/mach-omap2/powerdomain.c:131 _pwrdm_register() error: we previously assumed 'arch_pwrdm' could be null (see line 105) So, fix the unchecked dereference of arch_pwrdm. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Jarkko Nikula authored
This adds typical McBSP2-TWL4030 audio description to the legacy Beagle Board. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Balaji T K authored
Mux mode for wlan/sdmmc5 should be MODE0 in pinmux_wl12xx_pins and Enable Pull up on sdmmc5_clk to detect SDIO card. This fixes WLAN on omap4-sdp that got broken in v3.10 when we moved omap4 to boot using device tree only as I did not have the WL12XX card in my omap4 SDP to test with. The commit that attempted to make WL12XX working on omap4 SDP was 775d2418 (ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for blaze). Signed-off-by: Balaji T K <balajitk@ti.com> [tony@atomide.com: updated comments for the regression] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
Balaji T K authored
pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core. Fix the following error message: pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38) pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 56x SDIO card is not detected after moving pin mux to omap4_pmx_core since sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card. This fixes a regression where WLAN did not work after a warm reset or after one up/down cycle that happened when we move omap4 to boot using device tree only. For reference, the kernel bug is described at: https://bugzilla.kernel.org/show_bug.cgi?id=63821 Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Balaji T K <balajitk@ti.com> [tony@atomide.com: update comments to describe the regression] Signed-off-by: Tony Lindgren <tony@atomide.com>
-
- Dec 02, 2013
-
-
Brent Taylor authored
If CONFIG_PM is not defined, then arch/arm/mach-at91/pm.c is not compiled in. This patch creates an inline function that does nothing if CONFIG_PM is not defined. Signed-off-by: Brent Taylor <motobud@gmail.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-
Nicolas Ferre authored
Alias was missing for SoC of the at91sam9x5 familly that embed USART3. Reported-by: Jiri Prchal <jiri.prchal@aksignal.cz> [b.brezillon@overkiz.com: advised to place changes in at91sam9x5_usart3.dtsi] Acked-by: Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-
Ludovic Desroches authored
With some devices, transfer hangs during I2C frame transmission. This issue disappears when reducing the internal frequency of the TWI IP. Even if it is indicated that internal clock max frequency is 66MHz, it seems we have oversampling on I2C signals making TWI believe that a transfer in progress is done. This fix has no impact on the I2C bus frequency. Cc: <stable@vger.kernel.org> #3.10+ Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-
- Dec 01, 2013
-
-
Richard Weinberger authored
On UML SUBARCH can be x86, x86_64 and i386 and if it is x86 we use uname -m to select a defconfig. Therefore we can no longer use -mcmodel=large only if SUBARCH is x86_64. Reported-and-tested-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: Richard Weinberger <richard@nod.at>
-
Richard Weinberger authored
We cannot use print_stack_trace because the name conflicts with linux/stacktrace.h. Reported-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Richard Weinberger <richard@nod.at>
-
Fabio Estevam authored
Currently mx53 (CortexA8) running at 1GHz reports: Calibrating delay loop... 663.55 BogoMIPS (lpj=3317760) Tom Evans verified that alignments of 0x0 and 0x8 run the two instructions of __loop_delay in one clock cycle (1 clock/loop), while alignments of 0x4 and 0xc take 3 clocks to run the loop twice. (1.5 clock/loop) The original object code looks like this: 00000010 <__loop_const_udelay>: 10: e3e01000 mvn r1, #0 14: e51f201c ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8> 18: e5922000 ldr r2, [r2] 1c: e0800921 add r0, r0, r1, lsr #18 20: e1a00720 lsr r0, r0, #14 24: e0822b21 add r2, r2, r1, lsr #22 28: e1a02522 lsr r2, r2, #10 2c: e0000092 mul r0, r2, r0 30: e0800d21 add r0, r0, r1, lsr #26 34: e1b00320 lsrs r0, r0, #6 38: 01a0f00e moveq pc, lr 0000003c <__loop_delay>: 3c: e2500001 subs r0, r0, #1 40: 8afffffe bhi 3c <__loop_delay> 44: e1a0f00e mov pc, lr After adding the 'align 3' directive to __loop_delay (align to 8 bytes): 00000010 <__loop_const_udelay>: 10: e3e01000 mvn r1, #0 14: e51f201c ldr r2, [pc, #-28] ; 0 <__loop_udelay-0x8> 18: e5922000 ldr r2, [r2] 1c: e0800921 add r0, r0, r1, lsr #18 20: e1a00720 lsr r0, r0, #14 24: e0822b21 add r2, r2, r1, lsr #22 28: e1a02522 lsr r2, r2, #10 2c: e0000092 mul r0, r2, r0 30: e0800d21 add r0, r0, r1, lsr #26 34: e1b00320 lsrs r0, r0, #6 38: 01a0f00e moveq pc, lr 3c: e320f000 nop {0} 00000040 <__loop_delay>: 40: e2500001 subs r0, r0, #1 44: 8afffffe bhi 40 <__loop_delay> 48: e1a0f00e mov pc, lr 4c: e320f000 nop {0} , which now reports: Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736) Some more test results: On mx31 (ARM1136) running at 532 MHz, before the patch: Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184) On mx31 (ARM1136) running at 532 MHz after the patch: Calibrating delay loop... 528.79 BogoMIPS (lpj=2643968) Also tested on mx6 (CortexA9) and on mx27 (ARM926), which shows the same BogoMIPS value before and after this patch. Reported-by: Tom Evans <tom_usenet@optusnet.com.au> Suggested-by: Tom Evans <tom_usenet@optusnet.com.au> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Dave Martin authored
Copying a function with memcpy() and then trying to execute the result isn't trivially portable to Thumb. This patch modifies the kexec soft restart code to copy its assembler trampoline relocate_new_kernel() using fncpy() instead, so that relocate_new_kernel can be in the same ISA as the rest of the kernel without problems. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Reported-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Tested-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Victor Kamensky authored
After "ARM: signal: sigreturn_codes should be endian neutral to work in BE8" commit, thumb only platforms, like armv7m, fails to compile sigreturn_codes.S. The reason is that for such arch values '.arm' directive and arm opcodes are not allowed. Fix conditionally enables arm opcodes only if no CONFIG_CPU_THUMBONLY defined and it uses .org instructions to keep sigreturn_codes layout. Suggested-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org> Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
- The LEDs register is write-only: it can't be read-modify-written. - The LEDs are write-1-for-off not 0. - The check for the platform was inverted. Fixes: cf6856d6 ("ARM: mach-footbridge: retire custom LED code") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: stable@vger.kernel.org
-
Helge Deller authored
Signed-off-by: Helge Deller <deller@gmx.de>
-
Helge Deller authored
When building a 64bit kernel sometimes functions in the .init section were not able to reach the standard kernel function. Main reason for this problem is, that the linkage tables (.plt, .opd, .dlt) tend to become pretty huge and thus the distance gets too big for short calls. One option to avoid this is to use the -mlong-calls compiler option, but this increases the binary size and introduces a performance penalty. Instead, with this patch we just lay out the binary differently. Init code is stored first, followed by text, R/O and finally R/W data. This means, that init and text code is now much closer to each other, which is sufficient to reach each other by short calls. Signed-off-by: Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by: Helge Deller <deller@gmx.de>
-
Chen Gang authored
If architectures don't support SERIAL_PORT_DFNS, they need not define it to "nothing", the related drivers need do it by themselves (e.g. 8250 serial driver). Signed-off-by: Chen Gang <gang.chen@asianux.com> Signed-off-by: Helge Deller <deller@gmx.de>
-
Helge Deller authored
Sadly the correct names for machines which end with a question-mark aren't known, so let's give it a best-guessed-name. Signed-off-by: Helge Deller <deller@gmx.de>
-
Helge Deller authored
locale-gen on Debian showed a strange problem on parisc: mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000 mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument) Basically it was just trying to re-mmap() a file at the same address which it was given by a previous mmap() call. But this remapping failed with EINVAL. The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't included the mapping-based offset when we verified the alignment of the given fixed address against the offset which we calculated it in the previous call. Signed-off-by: Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # 3.10+
-
- Nov 30, 2013
-
-
Russell King authored
It's no good setting vga_base after the VGA console has been initialised, because if we do that we get this: Unable to handle kernel paging request at virtual address 000b8000 pgd = c0004000 [000b8000] *pgd=07ffc831, *pte=00000000, *ppte=00000000 0Internal error: Oops: 5017 [#1] ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49 task: c03e2974 ti: c03d8000 task.ti: c03d8000 PC is at vgacon_startup+0x258/0x39c LR is at request_resource+0x10/0x1c pc : [<c01725d0>] lr : [<c0022b50>] psr: 60000053 sp : c03d9f68 ip : 000b8000 fp : c03d9f8c r10: 000055aa r9 : 4401a103 r8 : ffffaa55 r7 : c03e357c r6 : c051b460 r5 : 000000ff r4 : 000c0000 r3 : 000b8000 r2 : c03e0514 r1 : 00000000 r0 : c0304971 Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel which is an access to the 0xb8000 without the PCI offset required to make it work. Fixes: cc22b4c1 ("ARM: set vga memory base at run-time") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: <stable@vger.kernel.org>
-
Russell King authored
Commit f6f91b0d (ARM: allow kuser helpers to be removed from the vector page) required two pages for the vectors code. Although the code setting up the initial page tables was updated, the code which allocates page tables for new processes wasn't, neither was the code which tears down the mappings. Fix this. Fixes: f6f91b0d ("ARM: allow kuser helpers to be removed from the vector page") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: <stable@vger.kernel.org>
-
Russell King authored
Some buses have negative offsets, which causes the DMA mask checks to falsely fail. Fix this by using the actual amount of memory fitted in the system. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-