aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2021-09-21ARM: dts: at91: tse850: the emac<->phy interface is rmiiPeter Rosin1-1/+1
This went unnoticed until commit 7897b071ac3b ("net: macb: convert to phylink") which tickled the problem. The sama5d3 emac has never been capable of rgmii, and it all just happened to work before that commit. Fixes: 21dd0ece34c2 ("ARM: dts: at91: add devicetree for the Axentia TSE-850") Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/ea781f5e-422f-6cbf-3cf4-d5a7bac9392d@axentia.se
2021-09-21x86/setup: Call early_reserve_memory() earlierJuergen Gross1-12/+14
Commit in Fixes introduced early_reserve_memory() to do all needed initial memblock_reserve() calls in one function. Unfortunately, the call of early_reserve_memory() is done too late for Xen dom0, as in some cases a Xen hook called by e820__memory_setup() will need those memory reservations to have happened already. Move the call of early_reserve_memory() before the call of e820__memory_setup() in order to avoid such problems. Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations") Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210920120421.29276-1-jgross@suse.com
2021-09-21xen/x86: fix PV trap handling on secondary processorsJan Beulich1-6/+9
The initial observation was that in PV mode under Xen 32-bit user space didn't work anymore. Attempts of system calls ended in #GP(0x402). All of the sudden the vector 0x80 handler was not in place anymore. As it turns out up to 5.13 redundant initialization did occur: Once from cpu_initialize_context() (through its VCPUOP_initialise hypercall) and a 2nd time while each CPU was brought fully up. This 2nd initialization is now gone, uncovering that the 1st one was flawed: Unlike for the set_trap_table hypercall, a full virtual IDT needs to be specified here; the "vector" fields of the individual entries are of no interest. With many (kernel) IDT entries still(?) (i.e. at that point at least) empty, the syscall vector 0x80 ended up in slot 0x20 of the virtual IDT, thus becoming the domain's handler for vector 0x20. Make xen_convert_trap_info() fit for either purpose, leveraging the fact that on the xen_copy_trap_info() path the table starts out zero-filled. This includes moving out the writing of the sentinel, which would also have lead to a buffer overrun in the xen_copy_trap_info() case if all (kernel) IDT entries were populated. Convert the writing of the sentinel to clearing of the entire table entry rather than just the address field. (I didn't bother trying to identify the commit which uncovered the issue in 5.14; the commit named below is the one which actually introduced the bad code.) Fixes: f87e4cac4f4e ("xen: SMP guest support") Cc: stable@vger.kernel.org Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/7a266932-092e-b68f-f2bb-1473b61adc6e@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-21arm64: dts: meson-g12b-odroid-n2: add 5v regulator gpioAnand Moon1-0/+2
As described in the Odroid-n2 & Odroid-n2-plus schematics, the 5V regulator is controlled by GPIOH_8 and in Open Drain since this GPIO doesn't support Push-Pull. Fixes: c35f6dc5c377 ("arm64: dts: meson: Add minimal support for Odroid-N2") Fixes: ef599f5f3e10 ("arm64: dts: meson: convert ODROID-N2 to dtsi") Cc: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210920204739.950-1-linux.amoon@gmail.com
2021-09-21arm64: dts: meson-sm1: Fix the pwm regulator supply propertiesAnand Moon4-4/+4
After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VDDCPU pwm regulator to 12V regulator supply instead of dummy regulator. [ 11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property in node /regulator-vddcpu failed [ 11.602344] VDDCPU: supplied by regulator-dummy [ 11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT [ 11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled Fixes: 88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi") Fixes: 700ab8d83927 ("arm64: dts: khadas-vim3: add support for the SM1 based VIM3L") Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS") Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts") Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210919202918.3556-4-linux.amoon@gmail.com
2021-09-21arm64: dts: meson-g12b: Fix the pwm regulator supply propertiesAnand Moon3-6/+6
After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs. Changes help link VDDCP_A and VDDCPU_B pwm regulator to 12V regulator supply instead of dummy regulator. [ 4.147196] VDDCPU_A: will resolve supply early: pwm [ 4.147216] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply from device tree [ 4.147227] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply property in node /regulator-vddcpu-a failed [ 4.147258] VDDCPU_A: supplied by regulator-dummy [ 4.147288] regulator-dummy: could not add device link regulator.12: -ENOENT [ 4.147353] VDDCPU_A: 721 <--> 1022 mV at 871 mV, enabled [ 4.152014] VDDCPU_B: will resolve supply early: pwm [ 4.152035] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply from device tree [ 4.152047] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply property in node /regulator-vddcpu-b failed [ 4.152079] VDDCPU_B: supplied by regulator-dummy [ 4.152108] regulator-dummy: could not add device link regulator.13: -ENOENT Fixes: c6d29c66e582 ("arm64: dts: meson-g12b-khadas-vim3: add initial device-tree") Fixes: d14734a04a8a ("arm64: dts: meson-g12b-odroid-n2: enable DVFS") Fixes: 3cb74db9b256 ("arm64: dts: meson: convert ugoos-am6 to common w400 dtsi") Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210919202918.3556-3-linux.amoon@gmail.com
2021-09-21arm64: dts: meson-g12a: Fix the pwm regulator supply propertiesAnand Moon3-3/+3
After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VDDCPU pwm regulator to 12V regulator supply instead of dummy regulator. [ 11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property in node /regulator-vddcpu failed [ 11.602344] VDDCPU: supplied by regulator-dummy [ 11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT [ 11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled Fixes: e9bc0765cc12 ("arm64: dts: meson-g12a: enable DVFS on G12A boards") Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210919202918.3556-2-linux.amoon@gmail.com
2021-09-20x86/fault: Fix wrong signal when vsyscall fails with pkeyJiashuo Liang2-10/+18
The function __bad_area_nosemaphore() calls kernelmode_fixup_or_oops() with the parameter @signal being actually @pkey, which will send a signal numbered with the argument in @pkey. This bug can be triggered when the kernel fails to access user-given memory pages that are protected by a pkey, so it can go down the do_user_addr_fault() path and pass the !user_mode() check in __bad_area_nosemaphore(). Most cases will simply run the kernel fixup code to make an -EFAULT. But when another condition current->thread.sig_on_uaccess_err is met, which is only used to emulate vsyscall, the kernel will generate the wrong signal. Add a new parameter @pkey to kernelmode_fixup_or_oops() to fix this. [ bp: Massage commit message, fix build error as reported by the 0day bot: https://lkml.kernel.org/r/202109202245.APvuT8BX-lkp@intel.com ] Fixes: 5042d40a264c ("x86/fault: Bypass no_context() for implicit kernel faults from usermode") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jiashuo Liang <liangjs@pku.edu.cn> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lkml.kernel.org/r/20210730030152.249106-1-liangjs@pku.edu.cn
2021-09-20x86/mce: Drop copyin special case for #MCTony Luck1-13/+0
Fixes to the iterator code to handle faults that are not on page boundaries mean that the special case for machine check during copy from user is no longer needed. For a full list of those fixes, see the output of: git log --oneline v5.14 ^v5.13 -- lib/iov_iter.c Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210818002942.1607544-4-tony.luck@intel.com
2021-09-20arm64: dts: ti: k3-am65: Relocate thermal-zones to SoC specific locationNishanth Menon2-4/+4
When commit 64f9147d914d ("arm64: dts: ti: am654: Add thermal zones") introduced thermal-zones for am654, it defined as under the common am65-wakeup bus segment, when it is am654 specific (other SoC spins can have slightly different thermal characteristics). Futher, thermal-zones is introduced under simple-bus node, when it has no actual register or base address. So, move it to it's rightful place under am654 SoC dtsi under the base node. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Keerthy <j-keerthy@ti.com> Link: https://lore.kernel.org/r/20210916181801.32588-1-nm@ti.com
2021-09-20arm64: dts: ti: ti-k3*: Introduce aliases for mmc nodesNishanth Menon4-0/+9
Since probe order of mmc can vary depending on device tree dependencies, Lets try and introduce a consistent definition of what mmc0, 1 are across platforms. NOTE: Certain platforms may choose to have overrides due to various legacy reasons, we permit that in the board specific alias definition. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20210915135415.5706-1-nm@ti.com
2021-09-20arm64: dts: ti: k3-am65-main: Cleanup "ranges" property in "pcie" DT nodeKishon Vijay Abraham I1-4/+4
*dtbs_check* on "Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml" YAML file resulted in the following errors. pcie@5500000: ranges: 'oneOf' conditional failed, one must be fixed: pcie@5600000: ranges: 'oneOf' conditional failed, one must be fixed Cleanup "ranges" property in "pcie" DT node to fix the above errors. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-7-kishon@ti.com
2021-09-20arm64: dts: ti: j7200-main: Add *max-virtual-functions* for pcie-ep DT nodeKishon Vijay Abraham I1-0/+1
J7200 has 4 virtual functions for the first four physical function. Add *max-virtual-functions* in pcie-ep DT node to represent the same. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-6-kishon@ti.com
2021-09-20arm64: dts: ti: j7200-main: Fix "bus-range" upto 256 bus number for PCIeKishon Vijay Abraham I1-1/+1
commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added PCIe bus numbers from 0 to 15 (copy-paste from J721E node). Enable all the supported bus numbers from 0 to 255 defined in PCIe spec here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-5-kishon@ti.com
2021-09-20arm64: dts: ti: j7200-main: Fix "vendor-id"/"device-id" properties of pcie nodeKishon Vijay Abraham I1-2/+2
commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added "vendor-id" and "device-id" as 16-bit properties though both of them are 32-bit properties. Fix it here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-4-kishon@ti.com
2021-09-20arm64: dts: ti: k3-j721e-main: Fix "bus-range" upto 256 bus number for PCIeKishon Vijay Abraham I1-4/+4
commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") restricted PCIe bus numbers from 0 to 15 (due to SMMU restriction in J721E). However since SMMU is not enabled, allow the full supported bus numbers from 0 to 255. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-3-kishon@ti.com
2021-09-20arm64: dts: ti: k3-j721e-main: Fix "max-virtual-functions" in PCIe EP nodesKishon Vijay Abraham I1-4/+4
commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") added "max-virtual-functions" to have 16 bit values. Fix "max-virtual-functions" in PCIe endpoint (EP) nodes to have 8 bit values instead of 16. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-2-kishon@ti.com
2021-09-20sparc64: fix pci_iounmap() when CONFIG_PCI is not setLinus Torvalds1-0/+2
Guenter reported [1] that the pci_iounmap() changes remain problematic, with sparc64 allnoconfig and tinyconfig still not building due to the header file changes and confusion with the arch-specific pci_iounmap() implementation. I'm pretty convinced that sparc should just use GENERIC_IOMAP instead of doing its own thing, since it turns out that the sparc64 version of pci_iounmap() is somewhat buggy (see [2]). But in the meantime, this just fixes the build by avoiding the trivial re-definition of the empty case. Link: https://lore.kernel.org/lkml/20210920134424.GA346531@roeck-us.net/ [1] Link: https://lore.kernel.org/lkml/CAHk-=wgheheFx9myQyy5osh79BAazvmvYURAtub2gQtMvLrhqQ@mail.gmail.com/ [2] Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: David Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-20arm64: defconfig: Everyone who had PANEL_SIMPLE now gets PANEL_EDPDouglas Anderson1-0/+1
In the patch ("drm/panel-simple-edp: Split eDP panels out of panel-simple") we split the PANEL_SIMPLE driver in 2. Let's enable the new config. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.6.Ied5c4da3ea36f8c49343176eda342027b6f19586@changeid
2021-09-20ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_EDPDouglas Anderson15-0/+15
In the patch ("drm/panel-simple-edp: Split eDP panels out of panel-simple") we will split the PANEL_SIMPLE driver in two. By default let's give everyone who had the old driver enabled the new driver too. If folks want to opt-out of one or the other they always can later. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.5.I02250cd7d4799661b068bcc65849a456ed411734@changeid
2021-09-20swiotlb-xen: this is PV-only on x86Jan Beulich1-1/+0
The code is unreachable for HVM or PVH, and it also makes little sense in auto-translated environments. On Arm, with xen_{create,destroy}_contiguous_region() both being stubs, I have a hard time seeing what good the Xen specific variant does - the generic one ought to be fine for all purposes there. Still Arm code explicitly references symbols here, so the code will continue to be included there. Instead of making PCI_XEN's "select" conditional, simply drop it - SWIOTLB_XEN will be available unconditionally in the PV case anyway, and is - as explained above - dead code in non-PV environments. This in turn allows dropping the stubs for xen_{create,destroy}_contiguous_region(), the former of which was broken anyway - it failed to set the DMA handle output. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/5947b8ae-fdc7-225c-4838-84712265fc1e@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-20xen/pci-swiotlb: reduce visibility of symbolsJan Beulich2-7/+3
xen_swiotlb and pci_xen_swiotlb_init() are only used within the file defining them, so make them static and remove the stubs. Otoh pci_xen_swiotlb_detect() has a use (as function pointer) from the main pci-swiotlb.c file - convert its stub to a #define to NULL. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/aef5fc33-9c02-4df0-906a-5c813142e13c@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-20xen/x86: drop redundant zeroing from cpu_initialize_context()Jan Beulich1-4/+0
Just after having obtained the pointer from kzalloc() there's no reason at all to set part of the area to all zero yet another time. Similarly there's no point explicitly clearing "ldt_ents". Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrvsky@oracle.com> Link: https://lore.kernel.org/r/14881835-a48e-29fa-0870-e177b10fcf65@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-20arm64: dts: rockchip: align operating-points table name with dtschemaKrzysztof Kozlowski6-11/+11
Align the name of operating-points node to dtschema to fix warnings like: opp-table0: $nodename:0: 'opp-table0' does not match '^opp-table(-[a-z0-9]+)?$' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210819182311.223443-2-krzysztof.kozlowski@canonical.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20ARM: dts: rockchip: swap timer clock-namesJohan Jonker3-6/+6
With the conversion of rockchip,rk-timer.yaml the clock-names order was set to "pclk", "timer", but nothing was fixed in the ARM dts section of the mainline kernel, so the swap timer clock-names that don't fit. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210828102659.7348-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20ARM: dts: rockchip: add more angle brackets to operating-points property on rk3066aJohan Jonker1-9/+8
After the conversion to YAML of the Operating Performance Points(OPP) binding the operating-points property expects values in a uint32-matrix with 2 items, so fix the notifications by adding angle brackets. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/opp/opp-v1.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210828091233.19992-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20ARM: dts: rockchip: rename opp-table node namesJohan Jonker5-6/+6
After the conversion to YAML of the Operating Performance Points(OPP) binding the operating-points-v2 property expects the nodename to have the '^opp-table(-[a-z0-9]+)?$' format, so rename all Rockchip ARM dts opp-table node names. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/opp/opp-v2.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210828094512.26862-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20ARM: dts: rockchip: change rv1108 gmac nodenameJohan Jonker1-1/+1
The rv1108 gmac node is checked with rockchip-dwmac.yaml, snps,dwmac.yaml and ethernet-controller.yaml. The nodename should have a pattern: "^ethernet(@.*)?$", so change to nodename. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210828114240.12231-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20ARM: dts: rockchip: add adc-keys node to rk3066a-mk808Johan Jonker1-0/+27
The MK808 has a button inside the cover for the boot loader to do some action. Add the adc-keys node to the rk3066a-mk808.dts file. The rk3066 has a higher maximum DC supply voltage for the analog part of SAR-ADC VDDA_SARADC of 2.75V then other Rockchip SoCs. For the "rockchip,saradc" node is a vref-supply property required, so add a regulator for it as well. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210828092755.24560-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20arm64: dts: rockchip: hook up camera on px30-evbHeiko Stuebner1-0/+52
Enable the isp and csi phy on px30-evb and connect it to the board's ov5695 camera. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Link: https://lore.kernel.org/r/20210830141318.66744-2-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20arm64: dts: rockchip: add isp node for px30Heiko Stuebner1-0/+41
Add the rkisp1 node and iommu for the px30 soc. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Link: https://lore.kernel.org/r/20210830141318.66744-1-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20arm64: dts: rockchip: add Coresight debug range for RK3399Brian Norris1-0/+48
Per Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt. This IP block can be used for sampling the PC of any given CPU, which is useful in certain panic scenarios where you can't get the CPU to stop cleanly (e.g., hard lockup). Reviewed-by: Leo Yan <leo.yan@linaro.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20210908111337.v2.3.Ibc87b4785709543c998cc852c1edaeb7a08edf5c@changeid Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20arm64: dts: rockchip: Correct regulator for USB host on Odroid-Go2Chris Morgan1-1/+11
When writing a battery driver, I noticed that the USB voltage was ~3.7V while running off of battery on a mainline kernel. After consulting the schematics for the Odroid Go Advance, it appears that the BOOST regulator is involved in the process of powering the USB host. Power for the USB host goes from the vccsys regulator into the PMIC, then out from the PMIC BOOST regulator into the FC9516A (which is controlled by GPIO), which then feeds power into the USB host. I named the regulator usb_midu because on the datasheet the pin is described as "MIDU/BOOST - middle point of USB power supply / boost output". Making these changes solved the USB power issue on battery and I'm now reading approximately 5v. Note that on my board at least there is a difference in time from the USB PHY probing and the regulators being powered on. This causes the USB port to be undervolted for a few seconds during boot up. The solutions to this problem are either 1) to add the proper phy-supply on the host port, or to 2) add regulator-boot-on to the regulator. I chose to add regulator-boot-on because there is an issue with the phy clk that causes a warning when booting (see v1 of this patch series). Basically the clock usb480m is a child of the usb480m_phy clock (used by the USB PHY) and also a critical clock. Setting the phy-supply causes this driver to be EPROBE_DEFERed until the regulator is ready, however upon unregistering the driver to be probed later the system cannot remove the usb480m_phy clock due to a child being marked critical. Changes since v2: - Added notes about clk problem and regulator voltage at boot. - Added regulator-boot-on as a workaround for the voltage at boot. - Removed note about fixed regulator warning, as that has been fixed upstream. Changes since v1: - Removed phy-supply, as this generated a warning in dmesg. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20210916190938.6175-1-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20arm64: dts: rockchip: fix PCI reg address warning on rk3399-gruTommaso Merciai1-1/+1
Warning (pci_device_reg): /pcie@f8000000/pcie@0,0:reg: PCI reg address is not configuration space Signed-off-by: Tommaso Merciai <tomm.merciai@gmail.com> Link: https://lore.kernel.org/r/20210918164153.207146-1-tomm.merciai@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20arm: dts: mt7623: add otg nodes for bpi-r2Frank Wunderlich1-0/+25
Add OTG-Nodes for BananaPi-R2 Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Link: https://lore.kernel.org/r/20210830145958.108605-1-linux@fw-web.de Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-09-20arm: dts: mt7623: add musb device nodesSungbo Eo2-0/+37
MT7623 has an musb controller that is compatible with the one from MT2701. Signed-off-by: Sungbo Eo <mans0n@gorani.run> Tested-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210830155903.13907-2-mans0n@gorani.run Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-09-20KVM: arm64: Fix PMU probe orderingMarc Zyngier2-4/+8
Russell reported that since 5.13, KVM's probing of the PMU has started to fail on his HW. As it turns out, there is an implicit ordering dependency between the architectural PMU probing code and and KVM's own probing. If, due to probe ordering reasons, KVM probes before the PMU driver, it will fail to detect the PMU and prevent it from being advertised to guests as well as the VMM. Obviously, this is one probing too many, and we should be able to deal with any ordering. Add a callback from the PMU code into KVM to advertise the registration of a host CPU PMU, allowing for any probing order. Fixes: 5421db1be3b1 ("KVM: arm64: Divorce the perf code from oprofile helpers") Reported-by: "Russell King (Oracle)" <linux@armlinux.org.uk> Tested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/YUYRKVflRtUytzy5@shell.armlinux.org.uk Cc: stable@vger.kernel.org
2021-09-20KVM: arm64: nvhe: Fix missing FORCE for hyp-reloc.S build ruleZenghui Yu1-1/+1
Add FORCE so that if_changed can detect the command line change. We'll otherwise see a compilation warning since commit e1f86d7b4b2a ("kbuild: warn if FORCE is missing for if_changed(_dep,_rule) and filechk"). arch/arm64/kvm/hyp/nvhe/Makefile:58: FORCE prerequisite is missing Cc: David Brazdil <dbrazdil@google.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210907052137.1059-1-yuzenghui@huawei.com
2021-09-20arm64: dts: renesas: r8a779a0: Add iommus into sdhi nodeYoshihiro Shimoda1-0/+1
Add iommus into sdhi node. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210901111305.570206-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: r8a779a0: Add IPMMU nodesYoshihiro Shimoda1-0/+97
Add IPMMU nodes for r8a779a0. Note that this patch sets the power domain of IPMMU-VC0 is Always-On tentatively because the SoC doesn't have A3VC power domain. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210901111305.570206-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: r8a779a0: Add TPU device nodeDuc Nguyen1-0/+11
This patch adds TPU node for R-Car V3U (r8a779a0) SoC. Signed-off-by: Duc Nguyen <duc.nguyen.ub@renesas.com> Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20210901091725.35610-3-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: r8a77961: Add TPU device nodeWolfram Sang1-0/+11
Add the missing TPU node for the R-Car M3-W+ SoC. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20210827073819.29992-1-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: r9a07g044: Add SSI supportBiju Das1-0/+76
Add SSI{0,1,2,3} nodes to RZ/G2L SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210814135526.15561-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: r9a07g044: Add external audio clock nodesBiju Das1-0/+14
Add external audio clocks nodes to RZ/G2L (a.k.a R9A07G044) SoC DTSI. The external audio clocks are configured as 0 Hz fixed frequency clocks by default. Boards that provide audio clocks should override them. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210814135526.15561-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: r9a07g044: Add USB2.0 device supportBiju Das1-0/+19
Add USB2.0 device support to RZ/G2L SoC DT. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210812151808.7916-4-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: r9a07g044: Add USB2.0 phy and host supportBiju Das1-0/+95
Add USB2.0 phy and host support to SoC DT. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20210812151808.7916-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-09-20arm64: dts: renesas: Add support for Salvator-XS with R-Car M3Ne-2GGeert Uytterhoeven2-0/+38
Add support for the Renesas Salvator-X 2nd version development board equipped with an R-Car M3Ne-2G SiP. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/efced5c7ff71b0a0ae359be12112e0d4dfb21a72.1628766192.git.geert+renesas@glider.be
2021-09-20arm64: dts: renesas: Add Renesas R8A779M8 SoC supportGeert Uytterhoeven1-0/+12
Add support for the Renesas R-Car H3Ne (R8A779M8) SoC, which is a different grading of the R-Car H3-N (R8A77951) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/99ff5658889e22ea8e723733e6972c27370930bf.1628766192.git.geert+renesas@glider.be
2021-09-20arm64: dts: renesas: Add Renesas R8A779M7 SoC supportGeert Uytterhoeven1-0/+12
Add support for the Renesas R-Car D3e (R8A779M7) SoC, which is a different grading of the R-Car D3 (R8A77995) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/2aa5b34d5b50f757092bc6442bb59a8534f2ff24.1628766192.git.geert+renesas@glider.be
2021-09-20arm64: dts: renesas: Add Renesas R8A779M6 SoC supportGeert Uytterhoeven1-0/+12
Add support for the Renesas R-Car E3e (R8A779M6) SoC, which is a different grading of the R-Car E3 (R8A77990) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/004e837531de4160ac4815fe7836b1f05d6fad85.1628766192.git.geert+renesas@glider.be