Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 23 10月, 2015 1 次提交
  3. 21 10月, 2015 2 次提交
  5. 20 10月, 2015 1 次提交
  7. 19 10月, 2015 1 次提交
    • T
      ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init · 57df5380
      由 Tony Lindgren 提交于 
      Some omaps are producing imprecise external aborts because we are
wrongly trying to init SRAM for device tree based booting. Only
omap3 is still using the legacy SRAM code, so we need to make it
omap3 specific. Otherwise we can get errors like this on at least
dm814x:

Unhandled fault: imprecise external abort (0xc06) at 0xc08b156c
...
(omap_rev) from [<c08b12e0>] (omap_sram_init+0xf8/0x3e0)
(omap_sram_init) from [<c08aca0c>] (omap_sdrc_init+0x10/0xb0)
(omap_sdrc_init) from [<c08b581c>] (pdata_quirks_init+0x18/0x44)
(pdata_quirks_init) from [<c08b5478>] (omap_generic_init+0x10/0x1c)
(omap_generic_init) from [<c08a57e0>] (customize_machine+0x1c/0x40)
(customize_machine) from [<c00098a4>] (do_one_initcall+0x80/0x1dc)
(do_one_initcall) from [<c08a2ec4>] (kernel_init_freeable+0x218/0x2e8)
(kernel_init_freeable) from [<c063a554>] (kernel_init+0x8/0xec)
(kernel_init) from [<c000f890>] (ret_from_fork+0x14/0x24)

Let's fix the issue by making sure omap_sdrc_init only gets called for
omap3. To do that, we need to have compatible "ti,omap3" in the dts
files. And let's also use "ti,omap3630" instead of "ti,omap36xx" like
we're supposed to.
Signed-off-by: NTony Lindgren <tony@atomide.com>
      57df5380
  9. 17 10月, 2015 1 次提交
    • T
      ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory · 6a3b764b
      由 Tony Lindgren 提交于 
      On boards with more than 2GB of RAM booting goes wrong with things not
working and we're getting lots of l3 warnings:

WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x260/0x384()
44000000.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle):
Data Access in User mode during Functional access
...
[<c044e158>] (scsi_add_host_with_dma) from [<c04705c8>]
(ata_scsi_add_hosts+0x5c/0x18c)
[<c04705c8>] (ata_scsi_add_hosts) from [<c046b13c>]
(ata_host_register+0x150/0x2cc)
[<c046b13c>] (ata_host_register) from [<c046b38c>]
(ata_host_activate+0xd4/0x124)
[<c046b38c>] (ata_host_activate) from [<c047f42c>]
(ahci_host_activate+0x5c/0x194)
[<c047f42c>] (ahci_host_activate) from [<c0480854>]
(ahci_platform_init_host+0x1f0/0x3f0)
[<c0480854>] (ahci_platform_init_host) from [<c047c9dc>]
(ahci_probe+0x70/0x98)
[<c047c9dc>] (ahci_probe) from [<c04220cc>]
(platform_drv_probe+0x54/0xb4)

Let's fix the issue by enabling ZONE_DMA for LPAE. Note that we need to
limit dma_zone_size to 2GB as the rest of the RAM is beyond the 4GB limit.

Let's also fix things for dra7 as done in similar patches in the TI tree
by Lokesh Vutla <lokeshvutla@ti.com>.
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      6a3b764b
  11. 15 10月, 2015 4 次提交
    • T
      ARM: tegra: Comment out gpio-ranges properties · 4f1d8414
      由 Thierry Reding 提交于 
      While the addition of these properties is technically correct it unveils
a bug with deferred probe. The problem is that the presence of the gpio-
range property causes the gpio-tegra driver to defer probe (it needs the
pinctrl driver to be ready). That's technically correct, but it causes a
couple of issues:

  - The keyboard on Chromebooks stops working. The reason for that is
    that the gpio-tegra device has not registered an IRQ domain by the
    time the EC SPI device is registered, hence the interrupt number
    resolves to 0. This is technically a bug in the SPI core, since it
    should really resolve the interrupt at probe time and defer if the
    IRQ domain isn't available yet. This is similar to what's done for
    I2C and platform device already.

  - The gpio-tegra device deferring probe means that it is moved to the
    end of the dpm_list. This list defines the suspend/resume order for
    devices. However the core lacks a way to move all users of the
    gpio-tegra device to the end of the dpm_list at the same time. This
    in turn results in a subtle bug on Jetson TK1, where the gpio-keys
    device is used to expose the power key as input. The power key is a
    convenient way to wake the system from suspend. Interestingly, the
    gpio-keys device ends up getting probed at a point after gpio-tegra
    has been probed successfully from having been deferred earlier. As
    such the driver doesn't need to defer the probe itself, and hence
    the device isn't moved to the end of the dpm_list. This causes the
    gpio-tegra device to be suspended before gpio-keys, which in turn
    leaves gpio-keys unable to wake the system from suspend.

There are patches in the works to fix both of the above issues, but they
are too involved to make it into v4.3, so in the meantime let's fix the
regressions by commenting out the gpio-ranges properties until the fixes
have landed.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4f1d8414
    • M
      ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board · 2e4e5da5
      由 Masahiro Yamada 提交于 
      The IRQ signal from external devices on this board is connected to
the XIRQ4 pin of the SoC.  The IRQ number should be 52, not 50.

Fixes: a5e921b4 ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b SoC/board support")
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2e4e5da5
    • M
      ARM: mvebu: correct a385-db-ap compatible string · db347f1a
      由 Marcin Wojtas 提交于 
      This commit enables standby support on Armada 385 DB-AP board, because
the PM initalization routine requires "marvell,armada380" compatible
string for all Armada 38x-based platforms.

Beside the compatible "marvell,armada38x" was wrong and should be fixed
in the stable kernels too.

[gregory.clement@free-electrons.com: add information, about the fixes]
Fixes: e5ee1281 ("ARM: mvebu: Add Armada 385 Access Point
Development Board support")
Signed-off-by: NMarcin Wojtas <mw@semihalf.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Cc: <stable@vger.kernel.org>
      db347f1a
    • C
      ARM: meson6: DTS: Fix wrong reg mapping and IRQ numbers · f9e5ca86
      由 Carlo Caione 提交于 
      The DTS erronously uses the wrong reg mapping and IRQ numbers for some
UART, WDT and timer nodes. Fix this.
Reported-by: NJohn Wehle <john@feith.com>
Signed-off-by: NCarlo Caione <carlo@endlessm.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      f9e5ca86
  13. 14 10月, 2015 2 次提交
  15. 13 10月, 2015 3 次提交
    • T
      ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on · 7e381ec6
      由 Tomi Valkeinen 提交于 
      LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
be kept always powered (see commit 5a0f93c6 ("ARM: dts: Add
am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
depending on whether an SD card is inserted or not.

This patch sets LDO1 regulator to always-on.

This patch has a side effect of fixing another issue, HDMI DDC not
working when SD card is not inserted:

Why this happens is that the tpd12s015 (HDMI level shifter/ESD
protection chip) has LS_OE GPIO input, which needs to be enabled for the
HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.

So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
off.

The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
framework manage the pin specific power.

Apparently this fixes also a third issue (copy paste from Kishon's
patch):

ldo1_reg in addition to being connected to the io lines is also
connected to the card detect line. On card removal, omap_hsmmc
driver does a regulator_disable causing card detect line to be
pulled down. This raises a card insertion interrupt and once the
MMC core detects there is no card inserted, it does a
regulator disable which again raises a card insertion interrupt.
This happens in a loop causing infinite MMC interrupts.

Fixes: 5a0f93c6 ("ARM: dts: Add am57xx-beagle-x15")
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NLouis McCarthy <compeoree@gmail.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      7e381ec6
    • A
      ARM: dts: Fix audio card detection on Peach boards · b8bb9baa
      由 Alim Akhtar 提交于 
      Since commit 2fad972d ("ARM: dts: Add mclk entry for Peach boards"),
sound card detection is broken on peach boards and gives below errors:

[    3.630457] max98090 7-0010: MAX98091 REVID=0x51
[    3.634233] max98090 7-0010: use default 2.8v micbias
[    3.640985] snow-audio sound: HiFi <-> 3830000.i2s mapping ok
[    3.645307] max98090 7-0010: Invalid master clock frequency
[    3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() failed: -22
[    3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[    3.664366] snow-audio: probe of sound failed with error -22

This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.

Fixes: 2fad972d ("ARM: dts: Add mclk entry for Peach boards")
Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NKukjin Kim <kgene@kernel.org>
      b8bb9baa
    • K
      ARM: EXYNOS: Fix double of_node_put() when parsing child power domains · 51a6256b
      由 Krzysztof Kozlowski 提交于 
      On each next iteration of for_each_compatible_node() the reference
counter for current device node is already decreased by the loop
iterator. The manual call to of_node_get() is required only on loop
break which is not happening here.

The double of_node_get() (with enabled CONFIG_OF_DYNAMIC) lead to
decreasing the counter below expected, initial value.

Fixes: fe4034a3 ("ARM: EXYNOS: Add missing of_node_put() when parsing power domains")
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NKukjin Kim <kgene@kernel.org>
      51a6256b
  17. 06 10月, 2015 1 次提交
  19. 05 10月, 2015 1 次提交
  21. 02 10月, 2015 1 次提交
  23. 30 9月, 2015 1 次提交
  25. 29 9月, 2015 4 次提交
  27. 28 9月, 2015 1 次提交
    • R
      ARM: make RiscPC depend on MMU · 868e87cc
      由 Russell King 提交于 
      RiscPC fails to build if MMU is disabled:

arch/arm/mach-rpc/ecard.c: In function 'ecard_init_pgtables':
arch/arm/mach-rpc/ecard.c:229:2: error: implicit declaration of function 'pgd_offset' [-Werror=implicit-function-declaration]

arrange for RiscPC to depend on MMU.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      868e87cc
  29. 25 9月, 2015 3 次提交
  31. 24 9月, 2015 2 次提交
    • F
      ARM: dts: fix usb pin control for imx-rex dts · 0af82211
      由 Felipe F. Tonello 提交于 
      This fixes a duplicated pin control causing this error:

imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
requested by regulators:regulator@2; cannot claim for 2184000.usb
imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
(MX6Q_PAD_GPIO_1) from group usbotggrp  on device 20e0000.iomuxc
imx_usb 2184000.usb: Error applying setting, reverse things
back
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already
requested by regulators:regulator@1; cannot claim for 2184200.usb
imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
from group usbh1grp  on device 20e0000.iomuxc
imx_usb 2184200.usb: Error applying setting, reverse things
back
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Fixes: e2047e33 ("ARM: dts: add initial Rex Pro board support")
Cc: <stable@vger.kernel.org>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      0af82211
    • R
      ARM: alignment: fix alignment handling for uaccess changes · 274e91b8
      由 Russell King 提交于 
      Jonathan Liu reports that the recent addition of CPU_SW_DOMAIN_PAN
causes wpa_supplicant to die due to the following kernel oops:

Unhandled fault: page domain fault (0x81b) at 0x001017a2
pgd = ee1b8000
[001017a2] *pgd=6ebee831, *pte=6c35475f, *ppte=6c354c7f
Internal error: : 81b [#1] SMP ARM
Modules linked in: rt2800usb rt2x00usb rt2800librt2x00lib crc_ccitt mac80211
CPU: 1 PID: 202 Comm: wpa_supplicant Not tainted 4.3.0-rc2 #1
Hardware name: Allwinner sun7i (A20) Family
task: ec872f80 ti: ee364000 task.ti: ee364000
PC is at do_alignment_ldmstm+0x1d4/0x238
LR is at 0x0
pc : [<c001d1d8>]    lr : [<00000000>]    psr: 600c0113
sp : ee365e18  ip : 00000000  fp : 00000002
r10: 001017a2  r9 : 00000002  r8 : 001017aa
r7 : ee365fb0  r6 : e8820018  r5 : 001017a2  r4 : 00000003
r3 : d49e30e0  r2 : 00000000  r1 : ee365fbc  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none[   34.393106] Control: 10c5387d  Table: 6e1b806a  DAC: 00000051
Process wpa_supplicant (pid: 202, stack limit = 0xee364210)
Stack: (0xee365e18 to 0xee366000)
...
[<c001d1d8>] (do_alignment_ldmstm) from [<c001d510>] (do_alignment+0x1f0/0x904)
[<c001d510>] (do_alignment) from [<c00092a0>] (do_DataAbort+0x38/0xb4)
[<c00092a0>] (do_DataAbort) from [<c0013d7c>] (__dabt_usr+0x3c/0x40)
Exception stack(0xee365fb0 to 0xee365ff8)
5fa0:                                     00000000 56c728c0 001017a2 d49e30e0
5fc0: 775448d2 597d4e74 00200800 7a9e1625 00802001 00000021 b6deec84 00000100
5fe0: 08020200 be9f4f20 0c0b0d0a b6d9b3e0 600c0010 ffffffff
Code: e1a0a005 e1a0000c 1affffe8 e5913000 (e4ea3001)
---[ end trace 0acd3882fcfdf9dd ]---

This is caused by the alignment handler not being fixed up for the
uaccess changes, and userspace issuing an unaligned LDM instruction.
So, fix the problem by adding the necessary fixups.
Reported-by: NJonathan Liu <net147@gmail.com>
Tested-by: NJonathan Liu <net147@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      274e91b8
  33. 22 9月, 2015 1 次提交
  35. 17 9月, 2015 10 次提交
    • M
      arm/arm64: KVM: Remove 'config KVM_ARM_MAX_VCPUS' · ef748917
      由 Ming Lei 提交于 
      This patch removes config option of KVM_ARM_MAX_VCPUS,
and like other ARCHs, just choose the maximum allowed
value from hardware, and follows the reasons:

1) from distribution view, the option has to be
defined as the max allowed value because it need to
meet all kinds of virtulization applications and
need to support most of SoCs;

2) using a bigger value doesn't introduce extra memory
consumption, and the help text in Kconfig isn't accurate
because kvm_vpu structure isn't allocated until request
of creating VCPU is sent from QEMU;

3) the main effect is that the field of vcpus[] in 'struct kvm'
becomes a bit bigger(sizeof(void *) per vcpu) and need more cache
lines to hold the structure, but 'struct kvm' is one generic struct,
and it has worked well on other ARCHs already in this way. Also,
the world switch frequecy is often low, for example, it is ~2000
when running kernel building load in VM from APM xgene KVM host,
so the effect is very small, and the difference can't be observed
in my test at all.

Cc: Dann Frazier <dann.frazier@canonical.com>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      ef748917
    • M
      arm: KVM: Disable virtual timer even if the guest is not using it · 688bc577
      由 Marc Zyngier 提交于 
      When running a guest with the architected timer disabled (with QEMU and
the kernel_irqchip=off option, for example), it is important to make
sure the timer gets turned off. Otherwise, the guest may try to
enable it anyway, leading to a screaming HW interrupt.

The fix is to unconditionally turn off the virtual timer on guest
exit.

Cc: stable@vger.kernel.org
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      688bc577
    • L
      ARM: imx53: qsrb: fix PMIC interrupt level · e1ffceb0
      由 Lucas Stach 提交于 
      The MC34708 PMIC interrupt level is active high, but was set to
active low in the devicetree, probably as a result of a copy and
paste error from the QSB board.

This caused IRQ storms and led to the kernel disabling the PMIC
interrupt.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      e1ffceb0
    • L
      ARM: imx53: include IRQ dt-bindings header · 34adba71
      由 Lucas Stach 提交于 
      Allows to use the more meaningful IRQ flag defines instead of
the raw values.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      34adba71
    • R
      ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2 · 84ad1bab
      由 Roger Quadros 提交于 
      The VBUS line of USB2 is connected to VBUS detect logic on
the PMIC. Use the palmas-usb driver to report VBUS events
to the USB driver.

As the palmas-usb driver supports GPIO based ID reporting
provide the GPIO for ID pin as well.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      84ad1bab
    • G
      ARM: omap2plus_defconfig: enable GPIO_PCA953X · f4746176
      由 Grazvydas Ignotas 提交于 
      This enables tca6424a GPIO expander driver that in turn enables
TPD12S015 HDMI ESD protection and level shifter on OMAP5 uevm.
In other words, it makes HDMI work on OMAP5 uevm.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      f4746176
    • G
      ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets · 1dbdad75
      由 Grazvydas Ignotas 提交于 
      The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
pins up, communication with tca6424a doesn't work (controller timeouts)
and it is not possible to enable HDMI.

Fixes: 9be495c4 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      1dbdad75
    • D
      ARM: OMAP2+: AM43XX: Enable autoidle for clks in am43xx_init_late · 08224a7d
      由 Dave Gerlach 提交于 
      Add omap2_clk_enable_autoidle_all to am43xx_init_late otherwise the call
to omap2_clk_disable_autoidle_all in am43xx_init_early may cause some
clocks to always stay active and prevent low power mode transitions.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      08224a7d
    • N
      ARM: dts: am57xx-beagle-x15: Update Phy supplies · 5005296e
      由 Nishanth Menon 提交于 
      Originally, all the SoC PHY rails were supplied by LDO3. However, as a
result of characterization, it was determined that this posed a risk in
extreme load  conditions. Hence the PHY rails are split between two
different LDOs. Update the related node as a result

LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3
LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie

NOTE: We break compatibility with pre-production boards with this change
since, the PMIC LDO4 is disabled at OTP level.

The new configuration is the plan of record and all pre-production
boards are supposed to be replaced with the latest boards matching the
mentioned configuration.

Some very few 10 something boards have been created and
stopped production till the latest modifications were done (PMIC USB
interrupt, LDO4 etc) - and all of those boards are now getting
scrapped.. If there are any (as per tracking information, there should
not be any), TI should be contacted to have them replaced.
Signed-off-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: updated commit about these being TI internal protos]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      5005296e
    • D
      ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints · 7ae85dc7
      由 Doug Anderson 提交于 
      In (23a4e405 arm: kgdb: Handle read-only text / modules) we moved to
using patch_text() to set breakpoints so that we could handle the case
when we had CONFIG_DEBUG_RODATA.  That patch used patch_text().
Unfortunately, patch_text() assumes that we're not in atomic context
when it runs since it needs to grab a mutex and also wait for other
CPUs to stop (which it does with a completion).

This would result in a stack crawl if you had
CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb.  The
crawl looked something like:

 BUG: scheduling while atomic: swapper/0/0/0x00010007
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34b #1073
 Hardware name: Rockchip (Device Tree)
  (unwind_backtrace) from [<c00133d4>] (show_stack+0x20/0x24)
  (show_stack) from [<c05400e8>] (dump_stack+0x84/0xb8)
  (dump_stack) from [<c004913c>] (__schedule_bug+0x54/0x6c)
  (__schedule_bug) from [<c054065c>] (__schedule+0x80/0x668)
  (__schedule) from [<c0540cfc>] (schedule+0xb8/0xd4)
  (schedule) from [<c0543a3c>] (schedule_timeout+0x2c/0x234)
  (schedule_timeout) from [<c05417c0>] (wait_for_common+0xf4/0x188)
  (wait_for_common) from [<c0541874>] (wait_for_completion+0x20/0x24)
  (wait_for_completion) from [<c00a0104>] (__stop_cpus+0x58/0x70)
  (__stop_cpus) from [<c00a0580>] (stop_cpus+0x3c/0x54)
  (stop_cpus) from [<c00a06c4>] (__stop_machine+0xcc/0xe8)
  (__stop_machine) from [<c00a0714>] (stop_machine+0x34/0x44)
  (stop_machine) from [<c00173e8>] (patch_text+0x28/0x34)
  (patch_text) from [<c001733c>] (kgdb_arch_set_breakpoint+0x40/0x4c)
  (kgdb_arch_set_breakpoint) from [<c00a0d68>] (kgdb_validate_break_address+0x2c/0x60)
  (kgdb_validate_break_address) from [<c00a0e90>] (dbg_set_sw_break+0x1c/0xdc)
  (dbg_set_sw_break) from [<c00a2e88>] (gdb_serial_stub+0x9c4/0xba4)
  (gdb_serial_stub) from [<c00a11cc>] (kgdb_cpu_enter+0x1f8/0x60c)
  (kgdb_cpu_enter) from [<c00a18cc>] (kgdb_handle_exception+0x19c/0x1d0)
  (kgdb_handle_exception) from [<c0016f7c>] (kgdb_compiled_brk_fn+0x30/0x3c)
  (kgdb_compiled_brk_fn) from [<c00091a4>] (do_undefinstr+0x1a4/0x20c)
  (do_undefinstr) from [<c001400c>] (__und_svc_finish+0x0/0x34)

It turns out that when we're in kgdb all the CPUs are stopped anyway
so there's no reason we should be calling patch_text().  We can
instead directly call __patch_text() which assumes that CPUs have
already been stopped.

Fixes: 23a4e405 ("arm: kgdb: Handle read-only text / modules")
Reported-by: NAapo Vienamo <avienamo@nvidia.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7ae85dc7