Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Commit <684d984038aa> ('powerpc/powernv: Add debugfs interface for
imc-mode and imc') added debugfs interface for the nest imc pmu
devices to support changing of different ucode modes. Primarily adding
this capability for debug. But when doing so, the code did not
consider the case of cpu-less nodes. So when reading the _cmd_ or
_mode_ file of a cpu-less node will create this crash.
Faulting instruction address: 0xc0000000000d0d58
Oops: Kernel access of bad area, sig: 11 [#1]
...
CPU: 67 PID: 5301 Comm: cat Not tainted 5.2.0-rc6-next-20190627+ #19
NIP: c0000000000d0d58 LR: c00000000049aa18 CTR:c0000000000d0d50
REGS: c00020194548f9e0 TRAP: 0300 Not tainted (5.2.0-rc6-next-20190627+)
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR:28022822 XER: 00000000
CFAR: c00000000049aa14 DAR: 000000000003fc08 DSISR:40000000 IRQMASK: 0
...
NIP imc_mem_get+0x8/0x20
LR simple_attr_read+0x118/0x170
Call Trace:
simple_attr_read+0x70/0x170 (unreliable)
debugfs_attr_read+0x6c/0xb0
__vfs_read+0x3c/0x70
vfs_read+0xbc/0x1a0
ksys_read+0x7c/0x140
system_call+0x5c/0x70
Patch fixes the issue with a more robust check for vbase to NULL.
Before patch, ls output for the debugfs imc directory
# ls /sys/kernel/debug/powerpc/imc/
imc_cmd_0 imc_cmd_251 imc_cmd_253 imc_cmd_255 imc_mode_0 imc_mode_251 imc_mode_253 imc_mode_255
imc_cmd_250 imc_cmd_252 imc_cmd_254 imc_cmd_8 imc_mode_250 imc_mode_252 imc_mode_254 imc_mode_8
After patch, ls output for the debugfs imc directory
# ls /sys/kernel/debug/powerpc/imc/
imc_cmd_0 imc_cmd_8 imc_mode_0 imc_mode_8
Actual bug here is that, we have two loops with potentially different
loop counts. That is, in imc_get_mem_addr_nest(), loop count is
obtained from the dt entries. But in case of export_imc_mode_and_cmd(),
loop was based on for_each_nid() count. Patch fixes the loop count in
latter based on the struct mem_info. Ideally it would be better to
have array size in struct imc_pmu.
Fixes: 684d984038 ('powerpc/powernv: Add debugfs interface for imc-mode and imc')
Reported-by: Qian Cai <cai@lca.pw>
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190827101635.6942-1-maddy@linux.vnet.ibm.com
Introduce two options to control the use of the tlbie instruction. A
boot time option which completely disables the kernel using the
instruction, this is currently incompatible with HASH MMU, KVM, and
coherent accelerators.
And a debugfs option can be switched at runtime and avoids using tlbie
for invalidating CPU TLBs for normal process and kernel address
mappings. Coherent accelerators are still managed with tlbie, as will
KVM partition scope translations.
Cross-CPU TLB flushing is implemented with IPIs and tlbiel. This is a
basic implementation which does not attempt to make any optimisation
beyond the tlbie implementation.
This is useful for performance testing among other things. For example
in certain situations on large systems, using IPIs may be faster than
tlbie as they can be directed rather than broadcast. Later we may also
take advantage of the IPIs to do more interesting things such as trim
the mm cpumask more aggressively.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190902152931.17840-7-npiggin@gmail.com
The various translation structure invalidations performed in early boot
when the MMU is off are not required, because everything is invalidated
immediately before a CPU first enables its MMU (see early_init_mmu
and early_init_mmu_secondary).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190902152931.17840-6-npiggin@gmail.com
Radix guests are responsible for managing their own translation caches,
so make them match bare metal radix and hash, and make each CPU flush
all its translations right before enabling its MMU.
Radix guests may not flush partition scope translations, so in
tlbiel_all, make these flushes conditional on CPU_FTR_HVMODE. Process
scope translations are the only type visible to the guest.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190902152931.17840-5-npiggin@gmail.com
There should be no functional changes.
- Use calls to existing radix_tlb.c functions in flush_partition.
- Rename radix__flush_tlb_lpid to radix__flush_all_lpid and similar,
because they flush everything, matching flush_all_mm rather than
flush_tlb_mm for the lpid.
- Remove some unused radix_tlb.c flush primitives.
Signed-off: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190902152931.17840-3-npiggin@gmail.com
Add an interface to debugfs for generating an EEH event on a given device.
This works by disabling memory accesses to and from the device by setting
the PCI_COMMAND register (or the VF Memory Space Enable on the parent PF).
This is a somewhat portable alternative to using the platform specific
error injection mechanisms since those tend to be either hard to use, or
straight up broken. For pseries the interfaces also requires the use of
/dev/mem which is probably going to go away in a post-LOCKDOWN world
(and it's a horrific hack to begin with) so moving to a kernel-provided
interface makes sense and provides a sane, cross-platform interface for
userspace so we can write more generic testing scripts.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-14-oohall@gmail.com
Detecting an frozen EEH PE usually occurs when an MMIO load returns a 0xFFs
response. When performing EEH testing using the EEH error injection feature
available on some platforms there is no simple way to kick-off the kernel's
recovery process since any accesses from userspace (usually /dev/mem) will
bypass the MMIO helpers in the kernel which check if a 0xFF response is due
to an EEH freeze or not.
If a device contains a 0xFF byte in it's config space it's possible to
trigger the recovery process via config space read from userspace, but this
is not a reliable method. If a driver is bound to the device an in use it
will frequently trigger the MMIO check, but this is also inconsistent.
To solve these problems this patch adds a debugfs file called
"eeh_dev_check" which accepts a <domain>:<bus>:<dev>.<fn> string and runs
eeh_dev_check_failure() on it. This is the same check that's done when the
kernel gets a 0xFF result from an config or MMIO read with the added
benifit that it can be reliably triggered from userspace.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-13-oohall@gmail.com
I am the RAS team. Hear me roar.
Roar.
On a more serious note, being able to locate failed devices can be helpful.
Set the attention indicator if the slot supports it once we've determined
the device is present and only clear it if the device is fully recovered.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-12-oohall@gmail.com
Currently we check that an IODA2 compatible PHB is upstream of this slot.
This is mainly to avoid pnv_php creating slots for the various "virtual
PHBs" that we create for NVLink. There's no real need for this restriction
so allow it on IODA3.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-10-oohall@gmail.com
When we reset PCI devices managed by a hotplug driver the reset may
generate spurious hotplug events that cause the PCI device we're resetting
to be torn down accidently. This is a problem for EEH (when the driver is
EEH aware) since we want to leave the OS PCI device state intact so that
the device can be re-set without losing any resources (network, disks,
etc) provided by the driver.
Generic PCI code provides the pci_bus_error_reset() function to handle
resetting a PCI Device (or bus) by using the reset method provided by the
hotplug slot driver. We can use this function if the EEH core has
requested a hot reset (common case) without tripping over the hotplug
driver.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-8-oohall@gmail.com
Currently we print a stack trace in the event handler to help with
debugging EEH issues. In the case of suprise hot-unplug this is unneeded,
so we want to prevent printing the stack trace unless we know it's due to
an actual device error. To accomplish this, we can save a stack trace at
the point of detection and only print it once the EEH recovery handler has
determined the freeze was due to an actual error.
Since the whole point of this is to prevent spurious EEH output we also
move a few prints out of the detection thread, or mark them as pr_debug
so anyone interested can get output from the eeh_check_dev_failure()
if they want.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-6-oohall@gmail.com
When a device is surprise removed while undergoing IO we will probably
get an EEH PE freeze due to MMIO timeouts and other errors. When a freeze
is detected we send a recovery event to the EEH worker thread which will
notify drivers, and perform recovery as needed.
In the event of a hot-remove we don't want recovery to occur since there
isn't a device to recover. The recovery process is fairly long due to
the number of wait states (required by PCIe) which causes problems when
devices are removed and replaced (e.g. hot swapping of U.2 NVMe drives).
To determine if we need to skip the recovery process we can use the
get_adapter_state() operation of the hotplug_slot to determine if the
slot contains a device or not, and if the slot is empty we can skip
recovery entirely.
One thing to note is that the slot being EEH frozen does not prevent the
hotplug driver from working. We don't have the EEH recovery thread
remove any of the devices since it's assumed that the hotplug driver
will handle tearing down the slot state.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-5-oohall@gmail.com
When hot-adding devices we rely on the hotplug driver to create pci_dn's
for the devices under the hotplug slot. Converse, when hot-removing the
driver will remove the pci_dn's that it created. This is a problem because
the pci_dev is still live until it's refcount drops to zero. This can
happen if the driver is slow to tear down it's internal state. Ideally, the
driver would not attempt to perform any config accesses to the device once
it's been marked as removed, but sometimes it happens. As a result, we
might attempt to access the pci_dn for a device that has been torn down and
the kernel may crash as a result.
To fix this, don't free the pci_dn unless the corresponding pci_dev has
been released. If the pci_dev is still live, then we mark the pci_dn with
a flag that indicates the pci_dev's release function should free it.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-3-oohall@gmail.com
When the last device in an eeh_pe is removed the eeh_pe structure itself
(and any empty parents) are freed since they are no longer needed. This
results in a crash when a hotplug driver is involved since the following
may occur:
1. Device is suprise removed.
2. Driver performs an MMIO, which fails and queues and eeh_event.
3. Hotplug driver receives a hotplug interrupt and removes any
pci_devs that were under the slot.
4. pci_dev is torn down and the eeh_pe is freed.
5. The EEH event handler thread processes the eeh_event and crashes
since the eeh_pe pointer in the eeh_event structure is no
longer valid.
Crashing is generally considered poor form. Instead of doing that use
the fact PEs are marked as EEH_PE_INVALID to keep them around until the
end of the recovery cycle, at which point we can safely prune any empty
PEs.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190903101605.2890-2-oohall@gmail.com
According to the AST2500/AST2520 specs, these SoCs support up to 228 GPIO
pins. However, 'gpio-ranges' value in 'aspeed-g5.dtsi' file is currently
setting the upper limit to 220 which isn't allowing access to all their
GPIOs. The correct upper limit value is 232 (actual number is 228 plus a
4-GPIO hole in GPIOAB). Without this patch, GPIOs AC5 and AC6 do not work
correctly on a AST2500 BMC running Linux Kernel v4.19
Fixes: 2039f90d13 ("ARM: dts: aspeed-g5: Add gpio controller to devicetree")
Signed-off-by: Oscar A Perez <linux@neuralgames.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Swift power supplies are version 2 of the IBM CFFPS.
Fixes: 8e8fd0cbd7 ("ARM: dts: aspeed: Add Swift BMC machine")
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Adds wdt2 section with 'alt-boot' option into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
The FMC supports five chip selects, so describe the five possible flash
chips.
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Samsung mach/soc changes for v5.4
1. Minor fixup in plat and mach code (S3C platforms),
2. Enable exynos-chipid driver to provide SoC related information,
3. Extend the patterns for Samsung maintainer entries to cover all
important files.
* tag 'samsung-soc-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
ARM: s3c64xx: squash samsung_usb_phy.h into setup-usb-phy.c
ARM: exynos: Enable exynos-chipid driver
ARM: samsung: Include GPIO driver header
Link: https://lore.kernel.org/r/20190904175002.10487-5-krzk@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Samsung DTS ARM changes for v5.4, part 2
1. Fix Exynos542x Chromebooks boot with multi_v7 defconfig,
2. Add GPU (Mali) support to Exynos5250 boards,
3. Minor cleanup for Exynos3250 ADC.
* tag 'samsung-dt-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: dts: exynos: Enable GPU/Mali T604 on Arndale board
ARM: dts: exynos: Enable GPU/Mali T604 on Chromebook Snow
ARM: dts: exynos: Add GPU/Mali T604 node to Exynos5250
ARM: dts: exynos: Fix min/max buck4 for GPU on Arndale board
ARM: dts: exynos: Mark LDO10 as always-on on Peach Pit/Pi Chromebooks
ARM: dts: exynos: Remove not accurate secondary ADC compatible
Link: https://lore.kernel.org/r/20190904175002.10487-4-krzk@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Samsung defconfig changes for v5.4
1. Enable AHCI platform driver on exynos defconfig for Exynos5250-based
Arndale board,
2. Make Max77802 PMIC regulator driver a built-in on multi_v7 defconfig
as it is essential early during boot.
* tag 'samsung-defconfig-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in
ARM: exynos_defconfig: Enable AHCI-platform SATA driver
Link: https://lore.kernel.org/r/20190904175002.10487-2-krzk@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This patch add support for perf callchain sampling on riscv platforms.
The return address of leaf function is retrieved from pt_regs as
it is not saved in the outmost frame.
Signed-off-by: Mao Han <han_mao@c-sky.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: linux-riscv <linux-riscv@lists.infradead.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Guo Ren <guoren@kernel.org>
Tested-by: Greentime Hu <greentime.hu@sifive.com>
[paul.walmsley@sifive.com: fixed some 'checkpatch.pl --strict' issues;
fixed patch description spelling]
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Tested with kmscube and some glmark2* tests on arndale board.
Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested with kmscube and some glmark2* tests on Chromebook snow.
Frequency adapts with load.
Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Required to have GPU voltage scaling working properly.
Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
mvebu dt64 for 5.4 (part 2)
Add support for Turris Mox board (Armada 3720 SoC based)
* tag 'mvebu-dt64-5.4-2' of git://git.infradead.org/linux-mvebu: (53 commits)
arm64: dts: marvell: add DTS for Turris Mox
dt-bindings: marvell: document Turris Mox compatible
arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl
arm64: dts: marvell: Add cpu clock node on Armada 7K/8K
arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply
arm64: dts: marvell: Add 7k/8k PHYs in PCIe nodes
arm64: dts: marvell: Add 7k/8k PHYs in USB3 nodes
arm64: dts: marvell: Add 7k/8k per-port PHYs in SATA nodes
arm64: dts: marvell: Add CP110 COMPHY clocks
arm64: dts: marvell: armada-37xx: add mailbox node
dt-bindings: gpio: Document GPIOs via Moxtet bus
drivers: gpio: Add support for GPIOs over Moxtet bus
bus: moxtet: Add sysfs and debugfs documentation
dt-bindings: bus: Document moxtet bus binding
bus: Add support for Moxtet bus
reset: Add support for resets provided by SCMI
firmware: arm_scmi: Add RESET protocol in SCMI v2.0
dt-bindings: arm: Extend SCMI to support new reset protocol
firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol
firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels
...
Link: https://lore.kernel.org/r/87h85two0r.fsf@FE-laptop
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Texas Instruments K3 SoC family changes for 5.4
- Typo fixes for gic-its unit addresses for both am654 and j721e
- HW spinlock nodes added for both am654 and j721e
- GPIO support for j721e
- power-domain cells update for both am654 / j721e for exclusive only
access
* tag 'ti-k3-soc-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux:
arm64: dts: ti: k3-j721e-main: Fix gic-its node unit-address
arm64: dts: ti: k3-am65-main: Fix gic-its node unit-address
arm64: dts: ti: k3-j721e-main: Add hwspinlock node
arm64: dts: ti: k3-am65-main: Add hwspinlock node
arm64: dts: k3-j721e: Add gpio-keys on common processor board
dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio modules
arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
arm64: dts: ti: k3-j721e: Update the power domain cells
arm64: dts: ti: k3-am654: Update the power domain cells
soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access
dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access
firmware: ti_sci: Allow for device shared and exclusive requests
Link: https://lore.kernel.org/r/b838d666-ab3b-7d41-67d4-09d606c732da@ti.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
SoC glue layer changes for SGX on omap variants for v5.4
For a while we've had omap4 sgx glue layer defined in dts and probed
with ti-sysc driver. This allows idling the sgx module for PM, and
removes the need for custom platform glue layer code for any further
driver changes.
We first drop the unused legacy platform data for omap4 sgx. Then for
omap5, we need add the missing clkctrl clock data so we can configure
sgx. And we configure sgx for omap34xx, omap36xx and am3517.
For am335x, we still have a dependency for rstctrl reset driver changes,
so that will be added later on.
Note that this branch is based on earlier ti-sysc branch for omap36xx
glue layer quirk handling.
* tag 'omap-for-v5.4/ti-sysc-sgx-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: ARM: dts: Configure interconnect target module for am3517sgx
ARM: dts: Configure interconnect target module for omap3 sgx
ARM: dts: Configure sgx for omap5
clk: ti: add clkctrl data omap5 sgx
ARM: OMAP2+: Drop legacy platform data for omap4 gpu
Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.com-4
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Drop legacy platform data omap variants for v5.4
We can now drop more platform data in favor of dts data for most
devices like cpsw, gpio, i2c, mmc, uart and watchdog.
In general we can do this by dropping legacy "ti,hwmods" custom dts
property, and the platform data assuming the related dts data is correct.
This is best done as single patch as otherwise we'd have to revert two
patches in case of any unexpected issues, and we're just removing data.
Fro cpsw, before we can do this, we need to configure the cpsw mdio clocks
properly in dts though in the first patch. For omap4 i2c, we've already
dropped the platform data earlier, but have been still allocting it
dynamically based on the dts data based on the "ti,hwmods" property, but
that is no longer needed. For d2d, we are missing the dts data, so we
first add it and then drop the platform data.
For dra7, we drop platform data and "ti,hwmods" for mcasp and mcspi.
We've already dropped platform data earlier for gpio, i2c, mmc, and
uart so we just need to drop "ti,hwmods" property for those.
Note that this branch is based on earlier ti-sysc-fixes branch.
* tag 'omap-for-v5.4/ti-sysc-drop-pdata-take2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: Drop legacy custom hwmods property for dra7 gpio
ARM: dts: Drop legacy custom hwmods property for dra7 mmc
ARM: dts: Drop legacy custom hwmods property for dra7 i2c
ARM: dts: Drop legacy custom hwmods property for dra7 uart
ARM: OMAP2+: Drop legacy platform data for dra7 mcasp
ARM: OMAP2+: Drop legacy platform data for dra7 mcspi
ARM: OMAP2+: Drop legacy platform data for omap4 d2d
ARM: dts: Configure d2d dts data for omap4
ARM: OMAP2+: Drop legacy watchdog platform data for omap4
ARM: dts: Drop custom hwmod property for omap4 i2c
ARM: OMAP2+: Drop legacy platform data for cpsw on dra7
ARM: OMAP2+: Drop legacy platform data for cpsw on am3 and am4
ARM: dts: Add fck for cpsw mdio for omap variants
Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.com-3
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This pull request contains Broadcom ARM-based SoCs Device Tree updates
for 5.4, please pull the following:
- Stefan does a bunch of preparatory work for supporting the Raspberry
Pi 4in the next merge window correct register ranges (SPI, I2C,
UART), define memory, HDMI and MMC properties at the board level
* tag 'arm-soc/for-5.4/devicetree' of https://github.com/Broadcom/stblinux:
ARM: dts: bcm283x: Enable HDMI at board level
ARM: dts: bcm283x: Define memory at board level
ARM: dts: bcm283x: Define MMC interfaces at board level
ARM: bcm283x: Reduce register ranges for UART, SPI and I2C
Qualcomm ARM Based defconfig Updates for v5.4
* Add DRM_MSM to ARCH_QCOM defconfigs
* tag 'qcom-defconfig-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
ARM: multi_v7_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM
ARM: qcom_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM
Contains a patch to switch to more generic compatible for SPI NOR.
This helps SPI NOR to work on newer board variants.
* tag 'davinci-for-v5.4/dt' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
ARM: dts: da850-evm: Use generic jedec, spi-nor for flash
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This converts the da8xx fbdev driver to use GPIO backlight device
and regulator devices. This will finally help get rid of legacy
GPIO API calls and simplify DaVinci GPIO driver.
* tag 'davinci-for-v5.4/fbdev' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
fbdev: da8xx: use resource management for dma
fbdev: da8xx-fb: drop a redundant if
fbdev: da8xx-fb: use devm_platform_ioremap_resource()
fbdev: da8xx: remove panel_power_ctrl() callback from platform data
ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc
fbdev: da8xx: add support for a regulator
ARM: davinci: da850-evm: model the backlight GPIO as an actual device
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Kbuild provides per-file compiler flag addition/removal:
CFLAGS_<basetarget>.o
CFLAGS_REMOVE_<basetarget>.o
AFLAGS_<basetarget>.o
AFLAGS_REMOVE_<basetarget>.o
CPPFLAGS_<basetarget>.lds
HOSTCFLAGS_<basetarget>.o
HOSTCXXFLAGS_<basetarget>.o
The <basetarget> is the filename of the target with its directory and
suffix stripped.
This syntax comes into a trouble when two files with the same basename
appear in one Makefile, for example:
obj-y += foo.o
obj-y += dir/foo.o
CFLAGS_foo.o := <some-flags>
Here, the <some-flags> applies to both foo.o and dir/foo.o
The real world problem is:
scripts/kconfig/util.c
scripts/kconfig/lxdialog/util.c
Both files are compiled into scripts/kconfig/mconf, but only the
latter should be given with the ncurses flags.
It is more sensible to use the relative path to the Makefile, like this:
obj-y += foo.o
CFLAGS_foo.o := <some-flags>
obj-y += dir/foo.o
CFLAGS_dir/foo.o := <other-flags>
At first, I attempted to replace $(basetarget) with $*. The $* variable
is replaced with the stem ('%') part in a pattern rule. This works with
most of cases, but does not for explicit rules.
For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
explicit rules, so $* will be empty, resulting in ignoring the per-file
AFLAGS.
I introduced a new variable, target-stem, which can be used also from
explicit rules.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Marc Zyngier <maz@kernel.org>
CONFIG_SHELL falls back to sh when bash is not installed on the system,
but nobody is testing such a case since bash is usually installed.
So, shell scripts invoked by CONFIG_SHELL are only tested with bash.
It makes it difficult to test whether the hashbang #!/bin/sh is real.
For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is
false. (I fixed it up)
Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension
and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may
not always be set to bash.
Probably, the right thing to do is to introduce BASH, which is bash by
default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL)
with $(BASH) for bash scripts.
If somebody tries to add bash-extension to a #!/bin/sh script, it will
be caught in testing because /bin/sh is a symlink to dash on some major
distributions.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
