* [PATCH v5 0/2] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Markus Mayer @ 2017-01-19 0:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Mayer <mmayer@broadcom.com>
This CPUfreq driver provides basic frequency scaling for older Broadcom
STB SoCs that do not use AVS firmware with DVFS support. There is no
support for voltage scaling.
v4 of this patch can be found at: https://patchwork.kernel.org/patch/9482357/
Changes since v4:
- Simplified (and hopefully clarified) binding document
- No code changes
v3 of this patch can be found at: https://lkml.org/lkml/2016/11/22/747
Changes since v3:
- added binding document
- got rid of calls to __clk_lookup(), using devm_clk_get() instead
- re-worked clock lookup code a bit, along with switching to devm_clk_get()
- get_frequencies() became a void function, removing the need for some
error checking
- fixed CONFIG_ARM_BRCM_AVS_CPUFREQ typo
- fixed MODULE_DEVICE_TABLE declaration
Markus Mayer (2):
dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
.../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 27 ++
MAINTAINERS | 1 +
drivers/cpufreq/Kconfig.arm | 12 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/brcmstb-cpufreq.c | 377 +++++++++++++++++++++
5 files changed, 418 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
create mode 100644 drivers/cpufreq/brcmstb-cpufreq.c
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: Reduce "CPU: shutdown" message to debug level
From: Florian Fainelli @ 2017-01-19 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232029.GU27312@n2100.armlinux.org.uk>
On 01/18/2017 03:20 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 18, 2017 at 02:53:26PM -0800, Florian Fainelli wrote:
>> Similar to c68b0274fb3c ("ARM: reduce "Booted secondary processor"
>> message to debug level"), demote the "CPU: shutdown" pr_notice() into a
>> pr_debug().
>
> Much better, and thanks for dropping the "performance" argument as well.
> CPU hotplug isn't about performance :)
>
> Please put this in the patch system, thanks.
Done, #8644, thanks!
--
Florian
^ permalink raw reply
* [GIT PULL] ARM: aspeed: devicetree for 4.11
From: Olof Johansson @ 2017-01-19 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XffqYCRipx+KzxyH0z-5=t53ezPjRv+MxOj7-tj2kbG2A@mail.gmail.com>
On Wed, Jan 18, 2017 at 09:50:02AM +1100, Joel Stanley wrote:
> Hello Arnd and Olof,
>
> Please pull the Aspeed devicetree ...tree for 4.11.
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
> tags/aspeed-4.11-devicetree
>
> for you to fetch changes up to 8f9bafbb92c0308cf8d33536803c822e14bed4d7:
>
> ARM: dts: aspeed: Add Romulus BMC platform (2017-01-10 21:55:46 +1100)
>
> ----------------------------------------------------------------
> Aspeed devicetree updates for 4.11
>
> This introduces the first OpenPower Power9 BMC system, Romulus. Romulus is
> based on the ast2500 SoC from Aspeed.
>
> These commits also add newly upstreamed drivers to the Palmetto BMC and ast2500
> eval board. We now have working network, ipmi bt, gpio and pinmux on
> all platforms.
>
> ARM: dts: aspeed: Add Romulus BMC platform
> ARM: dts: aspeed: Add ftgmac100 to g4 and g5 platforms
> ARM: dts: aspeed: Correct palmetto device tree
> ARM: dts: aspeed: Reserve framebuffer memory
> ARM: dts: aspeed-g5: Add gpio controller to devicetree
> ARM: dts: aspeed-g5: Add syscon and pin controller nodes
> ARM: dts: aspeed-g5: Add LPC Controller node
> ARM: dts: aspeed-g5: Add SoC Display Controller node
> ARM: dts: aspeed-g4: Add gpio controller to devicetree
> ARM: dts: aspeed-g4: Add syscon and pin controller nodes
Hi,
Merged, but for the future there's no need for you to list the patches in the
tag message, git inserts a list when we merge (--log), and git request-pull
already provides the shortlog.
(512MB RAM on a BMC? That's just insane :).
-Olof
^ permalink raw reply
* [GIT PULL] ARM: aspeed: soc for 4.11
From: Olof Johansson @ 2017-01-19 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XfSGGJq9M8D6yswBhFiX3tyNebx4MHY2a0Bxh_1icLDBA@mail.gmail.com>
On Wed, Jan 18, 2017 at 09:48:22AM +1100, Joel Stanley wrote:
> Hello Arnd and Olof,
>
> Please pull the Aspeed soc tree for 4.11.
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
> tags/aspeed-4.11-soc
>
> for you to fetch changes up to 43c08c1c1ae576a1517b31c9e3b615104c5ff131:
>
> ARM: aspeed: Select pinctrl drivers (2017-01-10 22:36:06 +1100)
>
> ----------------------------------------------------------------
> Apseed SoC updates for 4.11
>
> One commit that selects the newly upstreamed pinctrl driver for all
> SoCs.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] ARM: aspeed: defconfig for 4.11
From: Olof Johansson @ 2017-01-19 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XdfRoJjRX_txZjx2gxS4sqtUZNnUMvQS8Z=WXRQY3rKPw@mail.gmail.com>
On Wed, Jan 18, 2017 at 09:46:50AM +1100, Joel Stanley wrote:
> Hello Arnd and Olof,
>
> Please pull the Aspeed defconfig tree for 4.11.
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
> tags/aspeed-4.11-defconfig
>
> for you to fetch changes up to 0e81eb77f5f81be9a3fd4a080eba9abfb6e54a3a:
>
> ARM: configs: Update Aspeed with new drivers (2017-01-10 23:01:35 +1100)
>
> ----------------------------------------------------------------
> Aspeed defconfig updates for 4.11
>
> Just the one commit that updates our defconfigs with network (ftgmac100
> and ncsi), bt ipmi, gpio and ncsi.
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
From: Andreas Färber @ 2017-01-19 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484758245-9354-1-git-send-email-narmstrong@baylibre.com>
Hi,
Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
> this patch adds these reserved zones.
>
> Without such reserved memory zones, running the following stress command :
> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
> multiple times:
>
> Could lead to the following kernel crashes :
> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
> ...
> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
> ...
> Instead of the OOM killer.
>
I miss a Fixes: or Cc: here for the backport you desired. To have it
fixed back to my very introduction:
Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
People backporting it would need to handle the meson-{gx => gxbb}.dtsi
transition for 4.9 down to 4.6, which seems fairly straightforward.
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> Changes since v4 at [5]:
> - Move start of ddr memory to reserved-memory node
> - Drop memory node move
> - Fix typo in sizes
>
> Changes since resent v2 at [4]:
> - Fix invalid comment of useable memory attributes
>
> Changes since original v2 at [3]:
> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>
> Changes since v2 at [2]:
> - Moved all memory node out of dtsi
> - Added comment about useable memory
> - Fixed comment about secmon reserved zone
>
> Changes since v1 at [1] :
> - Renamed reg into linux,usable-memory to ovveride u-boot memory
> - only kept secmon memory zone
>
> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong at baylibre.com
> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong at baylibre.com
> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong at baylibre.com
> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong at baylibre.com
> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong at baylibre.com
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index eada0b5..63d52b7 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -55,6 +55,24 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 16 MiB reserved for Hardware ROM Firmware */
> + hwrom: hwrom {
Both sub-nodes get a label that is unused, but reserved-memory itself
does not (my v4 remark). Intentional?
> + reg = <0x0 0x0 0x0 0x1000000>;
> + no-map;
> + };
> +
> + /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
> + secmon: secmon {
I note that this .dtsi further down has a node /firmware/secure-monitor
with label sm.
a) Is there any naming convention such as secmon_mem to adopt here to
avoid mixups with sm?
b) Should this secmon node be referenced in the secure-monitor node via
memory-node = <&secmon>; to model their connection, thereby giving the
label a use? Or should we maybe merge the two nodes by moving the
compatible string here?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> + reg = <0x0 0x10000000 0x0 0x200000>;
> + no-map;
> + };
> + };
> +
> cpus {
> #address-cells = <0x2>;
> #size-cells = <0x0>;
Anyway, objection resolved,
Reviewed-by: Andreas F?rber <afaerber@suse.de>
I don't expect breakage from these more confined additions, but I can
try to test tomorrow.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [GIT PULL] ARM: at91: defconfig for 4.11
From: Olof Johansson @ 2017-01-19 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117201055.6jcirstom52lowxa@piout.net>
On Tue, Jan 17, 2017 at 09:10:55PM +0100, Alexandre Belloni wrote:
> Arnd, Olof,
>
> A single patch, adding the drivers needed by the newly added Axentia
> TSE-850
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-defconfig
>
> for you to fetch changes up to f46b1d47d4a14ddf0f935283c7c0bd0d446c54b0:
>
> ARM: sama5_defconfig: add support for the Axentia TSE-850 board (2017-01-10 16:13:48 +0100)
>
> ----------------------------------------------------------------
> defconfig for 4.11:
>
> - Add driver support for the Axentia TSE-850
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH 2/7] ARM: Add Broadcom Brahma-B15 readahead cache support
From: Florian Fainelli @ 2017-01-19 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118225630.GS27312@n2100.armlinux.org.uk>
On 01/18/2017 02:56 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 18, 2017 at 12:29:21PM -0800, Florian Fainelli wrote:
>> The readahead cache only intercepts reads, not writes, as such, some
>> data can remain stale in any of its buffers, such that we need to flush
>> it, which is an operation that needs to happen in a particular order:
>>
>> - disable the readahead cache
>> - flush it
>> - call the appropriate cache-v7.S function
>> - re-enable
>
> I really do hope that the above explanation is wrong, because if that's
> really how it's implemented, it's going to cause coherency problems.
>
> It's got to at least monitor writes, otherwise how do you guarantee
> that the CPU doesn't see stale data? IOW:
Yes, it does monitor writes, the explanation given here was wrong. Thanks!
>
> Consider this at the L2 memory-side interface (iow, downstream of the
> point-of-coherency):
>
> CPU1 CPU2 Read-ahead buffer
> read cache line C
> reads cache line C and C+1
> writes cache line C+1
> read cache line C+1
>
> What ensures that CPU2 sees the written out cache line from CPU1?
--
Florian
^ permalink raw reply
* [GIT PULL] ARM: at91: DT for 4.11
From: Olof Johansson @ 2017-01-19 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117200947.lkx2gz6e2fxbhv5f@piout.net>
On Tue, Jan 17, 2017 at 09:09:47PM +0100, Alexandre Belloni wrote:
> Arnd, Olof,
>
> Here is the DT pull request, adding a few boards and improving
> sama5d2 and sama5d4 support.
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-dt
>
> for you to fetch changes up to 21dd0ece34c2a07432a1cd0bbcb4815ce2b49173:
>
> ARM: dts: at91: add devicetree for the Axentia TSE-850 (2017-01-10 16:16:33 +0100)
>
> ----------------------------------------------------------------
> DT for 4.11:
>
> - New boards: Axentia TSE-850, sama5d36ek CMP
> - new device definitions for sama5d2
> - Fix DMA allocation on sama5d4 for secure peripherals
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: at91: drivers for 4.11
From: Olof Johansson @ 2017-01-19 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117200303.ycriqdrdwo5usccc@piout.net>
On Tue, Jan 17, 2017 at 09:03:03PM +0100, Alexandre Belloni wrote:
> Arnd, Olof,
>
> This is a single fix for the atmel-ebi.
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-drivers
>
> for you to fetch changes up to ee194289502a6901cc77dc9a893bf2afd351ac5e:
>
> memory/atmel-ebi: Fix ns <-> cycles conversions (2017-01-10 16:01:34 +0100)
>
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: at91: soc for 4.11
From: Olof Johansson @ 2017-01-19 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117200201.iab5vcvmjbfw33nf@piout.net>
On Tue, Jan 17, 2017 at 09:02:01PM +0100, Alexandre Belloni wrote:
> Hi Arnd, Olof
>
> A single cleanup for mach-at91. Maybe I'll send another pull request
> later with further PM cleanup. Else, that will probably be all for 4.11
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.11-soc
>
> for you to fetch changes up to 6cc7fbdf8d931eefa2d0aabf0d2840e94ba09ae5:
>
> ARM: at91: pm: remove useless extern definition (2017-01-11 13:21:24 +0100)
>
> ----------------------------------------------------------------
> SoC for 4.11:
>
> - small cleanup
>
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL v2] arm64: dts: juno: updates for v4.11
From: Olof Johansson @ 2017-01-19 0:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118184221.GA21734@e107155-lin>
On Wed, Jan 18, 2017 at 06:42:21PM +0000, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> v1->v2:
> - Fixed device node names for coresight components as suggested by Olof
> - Removed nested dtsi inclusions(again Olof's suggestions - Thanks)
> - Added some minor cleanup and updates from Robin
>
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
>
> Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-4.11
>
> for you to fetch changes up to 1492a864364ed46be2abeaaaf3b1a248f19e6644:
>
> arm64: dts: juno: remove motherboard USB node (2017-01-18 14:01:20 +0000)
>
> ----------------------------------------------------------------
> ARMv8 Vexpress/Juno DT updates for v4.11
>
> 1. Addition of Coresight support on Juno R1 and R2 variants
>
> 2. Addition of STM(System Trace Macrocell) support on all Juno variants
>
> 3. Removed incorrect nesting of dtsi files
>
> 4. Removed untested USB hub only available on initial Juno R0 motherboard
>
> 5. Added ETR SMMU power domain and dma-ranges property
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] DaVinci fix for v4.10
From: Olof Johansson @ 2017-01-19 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <214ce380-3c45-423c-a7bc-e19ea1ce2a2d@ti.com>
Hi Sekhar,
On Wed, Jan 18, 2017 at 04:23:55PM +0530, Sekhar Nori wrote:
> The following changes since commit 49def1853334396f948dcb4cedb9347abb318df5:
>
> Linux 4.10-rc4 (2017-01-15 16:21:59 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.10-part2
>
> for you to fetch changes up to 6f042ee9cc09792c1c0f0cd8f275c2b4b29eaa96:
>
> ARM: dts: da850-evm: fix read access to SPI flash (2017-01-18 15:38:08 +0530)
>
> ----------------------------------------------------------------
> This patch uses fast-read opcode to read the
> SPI flash. This is needed for error-free read
> at 30Mhz.
>
> ----------------------------------------------------------------
> Fabien Parent (1):
> ARM: dts: da850-evm: fix read access to SPI flash
You're ahead of our branch since this is based on -rc4 when it doesn't
have to. Want to respin, or should I cherry-pick the patch?
-Olof
^ permalink raw reply
* [GIT PULL] omap fixes for v4.10-rc4
From: Olof Johansson @ 2017-01-19 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587eb2e1.21d2540a.b610a.992bSMTPIN_ADDED_BROKEN@mx.google.com>
On Tue, Jan 17, 2017 at 04:12:09PM -0800, Tony Lindgren wrote:
> The following changes since commit 1a38de880992764d4bd5bccbd306b87d860e377d:
>
> ARM: dts: am572x-idk: Add gpios property to control PCIE_RESETn (2016-12-30 10:59:56 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/fixes-rc4
>
> for you to fetch changes up to 1ea6af3216b092ec97129ac81bd95cf254c4b140:
>
> ARM: dts: omap3: Fix Card Detect and Write Protect on Logic PD SOM-LV (2017-01-17 13:50:55 -0800)
>
> ----------------------------------------------------------------
> Fixes for omaps for v4.10-rc cycle. Mostly a DMA regression fix for
> omap1, and then a handful of trivial fixes for boards and devices to
> work:
>
> - Fixes TI wilink bluetooth strange platform data baud rate
>
> - Remove duplicate pinmux line for am335x-icev2
>
> - Fix omap1 dma regression
>
> - Fix uninitialized return value for wkup_m3_ipc_probe()
>
> - Fix Ethernet PHY binding typo for dra72-evm
>
> - Fix init for omap5 and dra7 sata ports
>
> - Fix mmc card detect pin for Logic PD SOM-LV
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH 2/5] ARM: Makefile: Generalize qcom platform text offset
From: Stephen Boyd @ 2017-01-18 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118233115.GV27312@n2100.armlinux.org.uk>
On 01/18, Russell King - ARM Linux wrote:
> On Wed, Jan 18, 2017 at 03:27:23PM -0800, Stephen Boyd wrote:
> > Some qcom platforms need a specific text offset because the first
> > 2MB of memory is reserved for shared memory. Let's just always
> > shift the text segment up by 2MB when ARCH_QCOM is selected so
> > that we don't have to specify the specific platforms that exhibit
> > this problem in Kconfig.
>
> I was really hoping that this sillyness would stop, but I guess
> expecting it to stop is asking too much...
>
> Is there really no other option?
>
The only other option is to make up some qcom specific config
like I_HAVE_A_QCOM_SOC_THAT_NEEDS_2MB_OFFSET that can be selected
when the configurator (not a word) knows that they are using that
SoC.
Overall, this practice has stopped inside the company over 3
years ago and has not continued as far as I know. This patch is
just taking the easy way out and forcing ARCH_QCOM to always do
the shift.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Baicar, Tyler @ 2017-01-18 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587F80A7.10008@arm.com>
Hello James,
On 1/18/2017 7:50 AM, James Morse wrote:
> Hi Tyler,
>
> On 12/01/17 18:15, Tyler Baicar wrote:
>> ARM APEI extension proposal added SEA (Synchrounous External
> Nit: Synchronous
I'll fix that :)
>> Abort) notification type for ARMv8.
>> Add a new GHES error source handling function for SEA. If an error
>> source's notification type is SEA, then this function can be registered
>> into the SEA exception handler. That way GHES will parse and report
>> SEA exceptions when they occur.
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 2acbc60..87efe26 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -767,6 +772,62 @@ static struct notifier_block ghes_notifier_sci = {
>> .notifier_call = ghes_notify_sci,
>> };
>>
>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>> +static LIST_HEAD(ghes_sea);
>> +
>> +static int ghes_notify_sea(struct notifier_block *this,
>> + unsigned long event, void *data)
>> +{
>> + struct ghes *ghes;
>> + int ret = NOTIFY_DONE;
>> +
>> + nmi_enter();
> Can we move this into the arch code? Its because we got here from a
> synchronous-exception that makes this nmi-like, I think it only makes sense for
> it be called from under /arch/.
So move the nmi_enter/exit calls into do_sea of the previous patch? I
can do that in the next patchset.
> Where did the rcu_read_lock() go? I can see its missing from ghes_notify_nmi()
> too, but I don't know enough about RCU to know if that's safe!
>
> The second paragraph in the comment above rcu_read_lock() describes it as
> preventing call_rcu() during a read-side critical section that was running
> concurrently. Doesn't this mean we can race with ghes_sea_remove() on another
> CPU because we wait for the wrong grace period?
>
> The same comment talks about how these read-side critical sections can nest, so
> I think its quite safe to make these 'lock' calls here.
Sorry, I thought we wanted nmi_enter/exit instead of the
rcu_read_lock/unlock. I guess the rcu locks
will not cause the deadlock scenario you described in the previous
patchset if we have the
nmi_enter/exit wrapped around the rcu critical section.
>> + list_for_each_entry_rcu(ghes, &ghes_sea, list) {
>> + if (!ghes_proc(ghes))
>> + ret = NOTIFY_OK;
>> + }
>> + nmi_exit();
>> +
>> + return ret;
>> +}
>> +
>> +static struct notifier_block ghes_notifier_sea = {
>> + .notifier_call = ghes_notify_sea,
>> +};
>> +
>> +static int ghes_sea_add(struct ghes *ghes)
>> +{
>> + mutex_lock(&ghes_list_mutex);
>> + if (list_empty(&ghes_sea))
>> + register_sea_notifier(&ghes_notifier_sea);
>> + list_add_rcu(&ghes->list, &ghes_sea);
>> + mutex_unlock(&ghes_list_mutex);
>> + return 0;
>> +}
>> +
>> +static void ghes_sea_remove(struct ghes *ghes)
>> +{
>> + mutex_lock(&ghes_list_mutex);
>> + list_del_rcu(&ghes->list);
>> + if (list_empty(&ghes_sea))
>> + unregister_sea_notifier(&ghes_notifier_sea);
>> + mutex_unlock(&ghes_list_mutex);
> ghes_nmi_remove() has:
>> /*
>> * To synchronize with NMI handler, ghes can only be
>> * freed after NMI handler finishes.
>> */
>> synchronize_rcu()
> This 'waits until a grace period has elapsed'. This is because ghes_remove()
> goes and kfree()s the ghes object while another CPU may be holding that entry in
> the list in ghes_notify_sea().
I will add synchronize_rcu() in the next patchset.
>> +}
>> +#else /* CONFIG_HAVE_ACPI_APEI_SEA */
>> +static inline int ghes_sea_add(struct ghes *ghes)
>> +{
>> + pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not supported\n",
>> + ghes->generic->header.source_id);
>> + return -ENOTSUPP;
>> +}
>> +
>> +static inline void ghes_sea_remove(struct ghes *ghes)
>> +{
>> + pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not supported\n",
>> + ghes->generic->header.source_id);
>> +}
>> +#endif /* CONFIG_HAVE_ACPI_APEI_SEA */
>> +
>> #ifdef CONFIG_HAVE_ACPI_APEI_NMI
>> /*
>> * printk is not safe in NMI context. So in NMI handler, we allocate
>> @@ -1011,6 +1072,14 @@ static int ghes_probe(struct platform_device *ghes_dev)
>> case ACPI_HEST_NOTIFY_EXTERNAL:
>> case ACPI_HEST_NOTIFY_SCI:
>> break;
>> + case ACPI_HEST_NOTIFY_SEA:
>> + if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_SEA)) {
>> + pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEA is not supported\n",
>> + generic->header.source_id);
>> + rc = -ENOTSUPP;
>> + goto err;
>> + }
>> + break;
>> case ACPI_HEST_NOTIFY_NMI:
>> if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
>> pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
>> @@ -1022,6 +1091,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
>> pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
>> generic->header.source_id);
>> goto err;
>
>> + case ACPI_HEST_NOTIFY_GPIO:
>> + case ACPI_HEST_NOTIFY_SEI:
>> + case ACPI_HEST_NOTIFY_GSIV:
> These three weren't mentioned in the commit message. I guess they are drive-by
> cleanup?
SEI and GSIV were also added in the ACPI 6.1 spec (18.3.2.9 Hardware
Error Notification) and GPIO was missing, so I added all three.
Thanks,
Tyler
>> + pr_warn(GHES_PFX "Generic hardware error source: %d notified via notification type %u is not supported\n",
>> + generic->header.source_id, generic->header.source_id);
>> + rc = -ENOTSUPP;
>> + goto err;
>> default:
>> pr_warning(FW_WARN GHES_PFX "Unknown notification type: %u for generic hardware error source: %d\n",
>> generic->notify.type, generic->header.source_id);
>
> Thanks,
>
> James
>
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [kernel-hardening] Re: [PATCH] ARM: mm: add testcases for RODATA
From: Russell King - ARM Linux @ 2017-01-18 23:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46bae2bb-4b4f-158b-6a8d-3737e181ad74@redhat.com>
On Wed, Jan 18, 2017 at 03:38:52PM -0800, Laura Abbott wrote:
> On 01/18/2017 02:36 PM, Russell King - ARM Linux wrote:
> > I don't see why this needs to be in cacheflush.h - it doesn't seem to
> > have anything to do with cache flushing, and placing it in here means
> > that if you change the state of CONFIG_DEBUG_RODATA_TEST, most likely
> > the entire kernel gets rebuilt. Please put it in a separate header
> > file.
>
> cacheflush.h seems to be where all the set_memory_* functions have
> ended up. I was just looking at cleaning that up unless someone
> beats me to it.
+1
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/3] Documentation: devicetree: amlogic: Add R-Box Pro
From: Kevin Hilman @ 2017-01-18 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9439ba55-c56c-71bf-00a5-870e2f4dd07b@suse.de>
Andreas F?rber <afaerber@suse.de> writes:
> Am 18.01.2017 um 10:35 schrieb Neil Armstrong:
>> On 01/17/2017 11:54 PM, Andreas F?rber wrote:
>>> Cc: ada at kingnoval.com
>>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>>> ---
>>> Originally I thought we would group by SoC (6, 8, 8b, gxbb, gxl, gmx, etc.)
>>> but this got out of order with nexbox,a95x - so inserting kingnovel between
>>> amlogic and nexbox here. If that's what we want going forward, we should move
>>> the old entries to make the scheme clearer. The alternative would be to
>>> reorder alphabetically within each SoC group, but nexbox,a95x with two SoCs
>>> makes it difficult to categorize, we could choose gxbb as the earlier one.
>>
>> Andreas,
>>
>> Feel free to provide a fixup.
>
> Sure, the question is which way. ;) Kevin? Carlo?
I don't have a strong preference, but continuing to group by SoC makes
the most sense based on what we have there now.
Moving nexbox,a95x up to the first one (gxbb) is fine with me.
Kevin
^ permalink raw reply
* [kernel-hardening] Re: [PATCH] ARM: mm: add testcases for RODATA
From: Laura Abbott @ 2017-01-18 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118223629.GQ27312@n2100.armlinux.org.uk>
On 01/18/2017 02:36 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 18, 2017 at 11:20:54AM -0800, Laura Abbott wrote:
>> On 01/18/2017 05:53 AM, Jinbum Park wrote:
>>> diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
>>> index bdd283b..741e2e8 100644
>>> --- a/arch/arm/include/asm/cacheflush.h
>>> +++ b/arch/arm/include/asm/cacheflush.h
>>> @@ -498,6 +498,16 @@ static inline void set_kernel_text_rw(void) { }
>>> static inline void set_kernel_text_ro(void) { }
>>> #endif
>>>
>>> +#ifdef CONFIG_DEBUG_RODATA_TEST
>>> +extern const int rodata_test_data;
>>> +int rodata_test(void);
>>> +#else
>>> +static inline int rodata_test(void)
>>> +{
>>> + return 0;
>>> +}
>>> +#endif
>>> +
>
> I don't see why this needs to be in cacheflush.h - it doesn't seem to
> have anything to do with cache flushing, and placing it in here means
> that if you change the state of CONFIG_DEBUG_RODATA_TEST, most likely
> the entire kernel gets rebuilt. Please put it in a separate header
> file.
>
cacheflush.h seems to be where all the set_memory_* functions have
ended up. I was just looking at cleaning that up unless someone
beats me to it.
Thanks,
Laura
^ permalink raw reply
* [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Thomas Petazzoni @ 2017-01-18 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118222010.ivc6jxpnrumemvdf@rob-hp-laptop>
Hello,
On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
> > > Rob, Mark, any opinion?
> >
>
> Sigh, is how to do compatibles really not yet understood?
Well, it seems like not everyone necessarily understands what is the
best strategy to adopt (me included).
> > I agree that a clarification would be good. There are really two
> > options:
> >
> > 1. Have two compatible strings in the DT, the one that matches the
> > exact SoC where the IP is found (first compatible string) and the
> > one that matches some other SoC where the same IP is found (second
> > compatible string). Originally, Linux only supports the second
> > compatible string in its device driver, but if it happens that a
> > difference is found between two IPs that we thought were the same,
> > we can add support for the first compatible string in the driver,
> > with a slightly different behavior.
>
> This. And no wildcards in the compatible string.
OK. So it means that today we do something like:
compatible = "baz,foo-12", "baz,foo-00";
and support only baz,foo-00 in the driver. If tomorrow we discover
that there is in fact a difference between the two IP blocks, we can
add support for baz,foo-12 in the driver, and handle the differences.
But then, the DT still contains:
compatible = "baz,foo-12", "baz,foo-00";
and therefore pretends that the IP block is compatible with
"baz,foo-00" which is in fact *not* the case. It was a mistake to
consider it as compatible. So we keep living with a DT that has
incorrect information.
>
> > 2. Have a single compatible string in the DT, matching the exact SoC
> > where the IP is found. This involves adding immediately this
> > compatible string in the corresponding driver.
>
> I wouldn't object to this from a DT perspective as I have no clue
> generally if IP blocks are "the same" or not. Subsystem maintainers will
> object though.
Knowing if IP blocks are "the same" is in fact not necessarily trivial.
What appears to be identical IP blocks today might be discovered later
as actually having subtle differences (sometimes not even visible in
the datasheet).
> > I've not really been able to figure out which of the two options is the
> > most future-proof/appropriate.
>
> They are both future-proof. #2 has the disadvantage of requiring a
> kernel update for a new SoC.
Which is generally anyway needed because a new SoC will almost always
require some new drivers, adjusting pin-muxing or clock drivers, etc.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 06/10] soc/qbman: Add ARM equivalent for flush_dcache_range()
From: Scott Wood @ 2017-01-18 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118231206.GT27312@n2100.armlinux.org.uk>
On 01/18/2017 05:12 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 18, 2017 at 05:39:36PM -0500, Roy Pledge wrote:
>> From: Claudiu Manoil <claudiu.manoil@nxp.com>
>>
>> Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
>> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
>> Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
>> ---
>> drivers/soc/fsl/qbman/qman_ccsr.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c b/drivers/soc/fsl/qbman/qman_ccsr.c
>> index 43feaa9..67ae073 100644
>> --- a/drivers/soc/fsl/qbman/qman_ccsr.c
>> +++ b/drivers/soc/fsl/qbman/qman_ccsr.c
>> @@ -446,8 +446,14 @@ static int zero_priv_mem(struct device *dev, struct device_node *node,
>> return -ENOMEM;
>>
>> memset(tmpp, 0, sz);
>> +#ifdef CONFIG_PPC
>> flush_dcache_range((unsigned long)tmpp,
>> (unsigned long)tmpp + sz);
>> +#elif defined(CONFIG_ARM)
>> + __cpuc_flush_dcache_area(tmpp, sz);
>
> Please do not fiddle about under the covers, there be dragons there.
>
> It looks to me like you're trying to use __cpuc_flush_dcache_area()
> on an area that's been ioremap()'d, which is a waste of CPU cycles.
> ioremap()'d areas are mapped as "device" memory type, which means
> the region isn't even cached. So I don't think this is necessary.
It is mapped cachable, via memremap() (see patch 1/10). This is RAM
that the device uses, non-coherently, for its own purposes (but requires
software to clear it first).
Is there a non-"under the covers" way to say "flush this region" without
the arch second-guessing whether it really needs to be flushed?
-Scott
^ permalink raw reply
* [PATCH] ARM: mm: add testcases for RODATA
From: Kees Cook @ 2017-01-18 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118223629.GQ27312@n2100.armlinux.org.uk>
On Wed, Jan 18, 2017 at 2:36 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Jan 18, 2017 at 11:20:54AM -0800, Laura Abbott wrote:
>> On 01/18/2017 05:53 AM, Jinbum Park wrote:
>> > diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
>> > index bdd283b..741e2e8 100644
>> > --- a/arch/arm/include/asm/cacheflush.h
>> > +++ b/arch/arm/include/asm/cacheflush.h
>> > @@ -498,6 +498,16 @@ static inline void set_kernel_text_rw(void) { }
>> > static inline void set_kernel_text_ro(void) { }
>> > #endif
>> >
>> > +#ifdef CONFIG_DEBUG_RODATA_TEST
>> > +extern const int rodata_test_data;
>> > +int rodata_test(void);
>> > +#else
>> > +static inline int rodata_test(void)
>> > +{
>> > + return 0;
>> > +}
>> > +#endif
>> > +
>
> I don't see why this needs to be in cacheflush.h - it doesn't seem to
> have anything to do with cache flushing, and placing it in here means
> that if you change the state of CONFIG_DEBUG_RODATA_TEST, most likely
> the entire kernel gets rebuilt. Please put it in a separate header
> file.
>
>> > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> > index 4127f57..3c15f3b 100644
>> > --- a/arch/arm/mm/init.c
>> > +++ b/arch/arm/mm/init.c
>> > @@ -716,6 +716,7 @@ void fix_kernmem_perms(void)
>> > int __mark_rodata_ro(void *unused)
>> > {
>> > update_sections_early(ro_perms, ARRAY_SIZE(ro_perms));
>> > + rodata_test();
>>
>> We don't do anything with this return value, should we at least
>> spit out a warning?
>>
>> > return 0;
>> > }
>> >
>> > @@ -740,6 +741,11 @@ void set_kernel_text_ro(void)
>> > static inline void fix_kernmem_perms(void) { }
>> > #endif /* CONFIG_DEBUG_RODATA */
>> >
>> > +#ifdef CONFIG_DEBUG_RODATA_TEST
>> > +const int rodata_test_data = 0xC3;
Oh, I missed this the first time: this may be misleading: 0xc3 is x86
"ret", and is used on x86 for it's test_nx.c file. (Which, IIRC,
hasn't worked correctly for years now since the exception tables were
made relative on x86. Getting this fixed too would be nice!)
>> This isn't accessed outside of test_rodata.c, it can just
>> be moved there.
Just for background, on x86 it's referenced by both test_rodata.c and test_nx.c.
> I think the intention was to place it in some .c file which gets built
> into the kernel, rather than a module, so testing whether read-only
> data in the kernel image is read-only.
>
> If it's placed in a module, then you're only checking that read-only
> data in the module is read-only (which is another test which should
> be done!)
>
> In any case, placing it in arch/arm/mm/init.c seems unnecessary, I'd
> rather it went in its own separate file.
>
>> > diff --git a/arch/arm/mm/test_rodata.c b/arch/arm/mm/test_rodata.c
>> > new file mode 100644
>> > index 0000000..133d092
>> > --- /dev/null
>> > +++ b/arch/arm/mm/test_rodata.c
>> > @@ -0,0 +1,79 @@
>> > +/*
>> > + * test_rodata.c: functional test for mark_rodata_ro function
>> > + *
>> > + * (C) Copyright 2017 Jinbum Park <jinb.park7@gmail.com>
>> > + *
>> > + * This program is free software; you can redistribute it and/or
>> > + * modify it under the terms of the GNU General Public License
>> > + * as published by the Free Software Foundation; version 2
>> > + * of the License.
>> > + */
>> > +#include <asm/cacheflush.h>
>> > +#include <asm/sections.h>
>> > +
>> > +int rodata_test(void)
>> > +{
>> > + unsigned long result;
>> > + unsigned long start, end;
>> > +
>> > + /* test 1: read the value */
>> > + /* If this test fails, some previous testrun has clobbered the state */
>> > +
>> > + if (!rodata_test_data) {
>> > + pr_err("rodata_test: test 1 fails (start data)\n");
>> > + return -ENODEV;
>> > + }
>> > +
>> > + /* test 2: write to the variable; this should fault */
>> > + /*
>> > + * If this test fails, we managed to overwrite the data
>> > + *
>> > + * This is written in assembly to be able to catch the
>> > + * exception that is supposed to happen in the correct
>> > + * case
>> > + */
>> > +
>> > + result = 1;
>> > + asm volatile(
>> > + "0: str %[zero], [%[rodata_test]]\n"
>> > + " mov %[rslt], %[zero]\n"
>> > + "1:\n"
>> > + ".pushsection .text.fixup,\"ax\"\n"
>> > + ".align 2\n"
>> > + "2:\n"
>> > + "b 1b\n"
>> > + ".popsection\n"
>> > + ".pushsection __ex_table,\"a\"\n"
>> > + ".align 3\n"
>> > + ".long 0b, 2b\n"
>> > + ".popsection\n"
>> > + : [rslt] "=r" (result)
>> > + : [zero] "r" (0UL), [rodata_test] "r" (&rodata_test_data)
>> > + );
>> > +
>> > + if (!result) {
>> > + pr_err("rodata_test: test data was not read only\n");
>> > + return -ENODEV;
>> > + }
>> > +
>> > + /* test 3: check the value hasn't changed */
>> > + /* If this test fails, we managed to overwrite the data */
>> > + if (!rodata_test_data) {
>> > + pr_err("rodata_test: Test 3 fails (end data)\n");
>> > + return -ENODEV;
>> > + }
>>
>> I'm confused why we are checking this again when we have the result
>> check above. Is there a case where we would still have result = 1
>> but rodata_test_data overwritten?
>
> Seems sensible when you consider that "result" tests that _a_ fault
> happened. Verifying that the data wasn't changed seems like a belt
> and braces approach, which ensures that the location really has not
> been modified.
>
> IOW, the test is "make sure that read-only data is not modified" not
> "make sure that writing to read-only data causes a fault". They're
> two subtly different tests.
>
>> As Mark mentioned, this is possibly redundant with LKDTM. It
>> would be good to explain what benefit this is bringing in addition
>> to LKDTM.
>
> Finding https://lwn.net/Articles/198690/ and github links, it doesn't
> seem obvious that LKDTM actually does this. It seems more focused on
> creating crashdumps than testing that (in this instance) write
> protection works - and it seems to be a destructive test.
The WRITE_RO and EXEC_RODATA tests perform similar tests, but yes, it
is intentionally destructive: it is exercising the entire protection
and kernel oops, etc.
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH 2/5] ARM: Makefile: Generalize qcom platform text offset
From: Russell King - ARM Linux @ 2017-01-18 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232726.22876-3-sboyd@codeaurora.org>
On Wed, Jan 18, 2017 at 03:27:23PM -0800, Stephen Boyd wrote:
> Some qcom platforms need a specific text offset because the first
> 2MB of memory is reserved for shared memory. Let's just always
> shift the text segment up by 2MB when ARCH_QCOM is selected so
> that we don't have to specify the specific platforms that exhibit
> this problem in Kconfig.
I was really hoping that this sillyness would stop, but I guess
expecting it to stop is asking too much...
Is there really no other option?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 5/5] ARM: multi_v7_defconfig: Remove qcom SoC configs
From: Stephen Boyd @ 2017-01-18 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232726.22876-1-sboyd@codeaurora.org>
Now that these configs are gone let's remove them from the
defconfig.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/configs/multi_v7_defconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index f084a0a928b8..1d05f6df8a5f 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -70,9 +70,6 @@ CONFIG_SOC_AM43XX=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_QCOM=y
CONFIG_ARCH_MEDIATEK=y
-CONFIG_ARCH_MSM8X60=y
-CONFIG_ARCH_MSM8960=y
-CONFIG_ARCH_MSM8974=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_ARCH_SOCFPGA=y
CONFIG_PLAT_SPEAR=y
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 4/5] ARM: qcom_defconfig: Drop SoC specific configs
From: Stephen Boyd @ 2017-01-18 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118232726.22876-1-sboyd@codeaurora.org>
Now that these configs are gone let's remove them from the
defconfig.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/configs/qcom_defconfig | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 8c3a0108a231..03fc52964902 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -20,10 +20,6 @@ CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MSM8X60=y
-CONFIG_ARCH_MSM8960=y
-CONFIG_ARCH_MSM8974=y
-CONFIG_ARCH_MDM9615=y
CONFIG_SMP=y
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_PREEMPT=y
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox