aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-03-25ARM: dts: rockchip: Remove #address/#size-cells from rk3288 mipi_dsiDouglas Anderson1-2/+0
They are pointless. As dtc points out: Warning (avoid_unnecessary_addr_size): /mipi@ff960000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Let's remove them. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-03-25ARM: dts: rockchip: Fix gpu opp node names for rk3288Douglas Anderson1-6/+6
The device tree compiler yells like this: Warning (unit_address_vs_reg): /gpu-opp-table/opp@100000000: node has a unit name, but no reg property Let's match the cpu opp node names and use a dash. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-03-25ARM: dts: rockchip: Add vdd_logic to rk3288-veyronDouglas Anderson1-0/+17
The vdd_logic rail controls the voltage supplied to misc logic on rk3288, including the voltage supplied to the memory controller. The vcc logic is implemented by a PWM regulator. Right now there are no consumers of vdd_logic on veyron but if anyone ever wants to try to add DDR Freq they'd need it. Note that in the downstream Chrome OS kernel the PWM regulator has a voltage table with these points: 1350000 0% 1300000 10% 1250000 20% 1200000 31% 1150000 41% 1125000 46% 1100000 52% 1050000 62% 1000000 72% 950000 83% The DDR Freq driver in the downstream kernel only uses some of those points, namely: DDR3: 1200000, 1150000, 1100000, 1050000 LPDDR: 1150000, 1100000, 1050000 When adapting the downstream kernel to upstream I have opted to switch to using the "continuous" mode of the PWM regulator driver. This was the only way I could get the upstream driver to achieve _exactly_ the same voltages as the downstream driver could. Specifically note that the old driver in downstream Chrome OS 3.14 _didn't_ have the DIV_ROUND_CLOSEST_ULL() in the Rockchip PLL driver. That means if I use the same (downstream) table I might end up with a duty cycle that's 1 larger than was used downstream, leading to a slightly different voltage. Due to the way the rounding worked I couldn't even just adjust the "percent" by 1 for a given voltage level--certain duty cycles just aren't achievable with the upstream math for voltage tables. Using continuous mode you can achieve the exact same duty cycle by simply adjusting the voltage you use by a tad bit. The voltages that are equivalent to the ones used in the downstream kernel's table are: 1350000, 1304472, 1255691, 1200407, 1154878, 1128862, 1099593, 1050813, 1005285, 950000 Note that the top/bottom voltage is exactly the same just due to the way that continuous mode is calculated and the fact that I used those as anchors. I didn't make any attempt to do the resistor math (as was done on rk3399-gru). If anyone ever gets DDRFreq working on veyron upstream they should thus adjust the voltage specified in the DDRFreq operating points slightly (as per the above) to obtain the existing/tested values. AKA you'd use: DDR3: 1200407, 1154878, 1099593, 1050813 LPDDR: 1154878, 1099593, 1050813 A few other notes: - The "period" here (1994) is different than the "period" downstream (2000) for similar reasons: there's a DIV_ROUND_CLOSEST_ULL() that wasn't downstream. With 1994 upstream comes up with the same value (0x94) to program into the hardware that downstream put there. As far as I can tell 0x94 actually means 1993.27. - The duty cycle unit of 0x94 was picked by just matching the period which nicely allows us to insert 0x7b as that value to program into the hardware for 950mV. The 0x7b was found by observing what the downstream kernel calculated (not that the system can actually run with vdd_log at 950 mV). - The downstream kernel can also be seen to program a different value into the CTRL field. Upstream achieves 0x0b and downstream 0x1b. This is because the upstream commit bc834d7b07b4 ("pwm: rockchip: Move the configuration of polarity") fixed a bug by adding "ctrl &= ~PWM_POLARITY_MASK". Downstream accidentally left bit 4 set. Luckily this bit doesn't matter--it's only used when the PWM goes inactive (AKA if it's in oneshot mode or is disabled) and we don't do that for the PWM regulator. I measured the voltage of vdd_log while adjusting it and found that with the upstream kernel voltage difference between requested and actual was 9.2 mV at 950 mV and 13.4 mV at 1350 mV with in-between voltages consistently showing ~1% error. This error is likely expected as voltage can be seen to sag a bit when more load is put on the rail. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-03-25ARM: dts: rockchip: Add dvs-gpios to rk3288-veyron-jerryDouglas Anderson1-1/+3
When the rk3288-jerry device tree was first submitted we left out the dvs-gpios because I pointed out that the property "dvs-gpios" wasn't yet supported upstream [1]. Soon after that the property was added in commit bad47ad2eef3 ("regulator: rk808: fixed the overshoot when adjust voltage"). ...but we forgot to go back and add the property to the jerry device tree file. Let's do so now. NOTE: without this patch, jerry is likely still stable (thanks to the fallback of making many small jumps in the rk808 regulator code) but it'll take quite a bit longer to make voltage transitions. [1] https://lore.kernel.org/linux-arm-kernel/CAD=FV=WwFgjzbk9xF5TU_ie6UnHQMyrZ176D4+jJTWWOoaKC2Q@mail.gmail.com/ Fixes: f3ee390e4ef2 ("ARM: dts: rockchip: add veyron-jerry board") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-03-25ARM: dts: rockchip: Add rk3288-veyron-jerry rev 10-15Douglas Anderson1-1/+4
As far as I can tell/remember rev10 was originally created to support making a SKU of jerry that had a different LCD. rev11-rev15 were added to give some wiggle room for future builds. Downstream has a separate device tree for rev10-rev15 (compared to rev3-rev7) with the expectation that differences relating to the LCD would be accounted for there but nothing was ever added to the rev10-rev15 making it identical to the rev3-rev7 one. It's likely nothing actually shipped with rev10-rev15 but they are listed in the downstream kernel's device tree and it seems like it should add a little safety if we match them here just in case something actually shipped with one of these revisions and that device will break if we don't claim support. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-03-25ARM: dts: iwg23s-sbc: Add HDMI supportFabrizio Castro1-0/+79
This patch adds HDMI video output support to the iwg23s board from iWave. Due to a problem with the bootloader not dealing with the configuration of one of the pins correctly, we have to use a gpio-hog for the interrupt line to make sure the pin is configured as GPIO-input when requesting the interrupt. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-03-25ARM: dts: r8a77470: Add DU supportFabrizio Castro1-0/+32
This commit adds DU support to the RZ/G1C (a.k.a. r8a77470) specific device tree. Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-03-25ARM: dts: sun8i: a33: Reintroduce default pinctrl muxingMaxime Ripard1-0/+2
Commit d02752149759 ("ARM: dts: sun8i-a23-a33: Move NAND controller device node to sort by address") moved the NAND controller node around, but dropped the default muxing in the process. Reintroduce it. Fixes: d02752149759 ("ARM: dts: sun8i-a23-a33: Move NAND controller device node to sort by address") Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-03-25m68k: defconfig: Update defconfigs for v5.1-rc1Geert Uytterhoeven12-96/+72
Actual changes: -CONFIG_FS_ENCRYPTION=m -CONFIG_NET_DEVLINK=m -CONFIG_NFT_CHAIN_NAT_IPV4=m -CONFIG_NFT_CHAIN_NAT_IPV6=m -CONFIG_NFT_MASQ_IPV4=m -CONFIG_NFT_MASQ_IPV6=m -CONFIG_NFT_REDIR_IPV4=m -CONFIG_NFT_REDIR_IPV6=m +CONFIG_CRYPTO_CTS=m +CONFIG_CRYPTO_XTS=m +CONFIG_TEST_STACKINIT=m +CONFIG_TEST_VMALLOC=m +# CONFIG_VALIDATE_FS_PARSER is not set +CONFIG_XDP_SOCKETS_DIAG=m Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: mvme16x: Handle timer counter overflowFinn Thain1-13/+32
Reading the timer counter races with timer overflow (and the corresponding interrupt). This is resolved by reading the overflow register and taking this value into account. The interrupt handler must clear the overflow register when it eventually executes. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: mvme16x: Convert to clocksource APIFinn Thain1-6/+31
Add a platform clocksource by adapting the existing arch_gettimeoffset implementation. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: mvme147: Handle timer counter overflowFinn Thain2-10/+12
Reading the timer counter races with timer overflow (and the corresponding interrupt). This is resolved by reading the overflow register and taking this value into account. The interrupt handler must clear the overflow register when it eventually executes. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: mvme147: Convert to clocksource APIFinn Thain2-7/+30
Add a platform clocksource by adapting the existing arch_gettimeoffset implementation. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: mac: Convert to clocksource APIFinn Thain1-9/+36
Add a platform clocksource by adapting the existing arch_gettimeoffset implementation. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: hp300: Handle timer counter overflowFinn Thain1-16/+24
Because hp300_read_clk() never checks the timer interrupt flag it may fail to notice that the timer has wrapped, allowing the clock to jump backwards. This is not a new problem. This is resolved by checking the interrupt flag and, if need be, taking wrap-around into account. The interrupt handler clears the flag when it eventually executes. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: hp300: Convert to clocksource APIFinn Thain1-7/+30
Add a platform clocksource by adapting the existing arch_gettimeoffset implementation. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: bvme6000: Convert to clocksource APIFinn Thain1-16/+41
Add a platform clocksource by adapting the existing arch_gettimeoffset implementation. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: atari: Convert to clocksource APIFinn Thain1-16/+35
Add a platform clocksource by adapting the existing arch_gettimeoffset implementation. Normally the MFP timer C interrupt flag would be used to check for timer counter wrap-around. Unfortunately, that flag gets cleared by the MFP itself (due to automatic End-of-Interrupt mode). This means that mfp_timer_c_handler() and atari_read_clk() must race when accounting for counter wrap-around. That problem is avoided by effectively stopping the clock when it might otherwise jump backwards (due to interrupt latency). Note that this may affect clock accuracy. After the timer interrupt is asserted, wait for the counter to be reloaded so that atari_read_clk() will not see the intermediate state as that would cause the clock to jump backwards. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Michael Schmitz <schmitzmic@gmail.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: amiga: Convert to clocksource APIFinn Thain1-9/+37
Add a platform clocksource by adapting the existing arch_gettimeoffset implementation. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Michael Schmitz <schmitzmic@gmail.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: Drop ARCH_USES_GETTIMEOFFSETFinn Thain9-17/+0
The functions that implement arch_gettimeoffset are re-used by new clocksource drivers in subsequent patches. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: apollo, q40, sun3, sun3x: Remove arch_gettimeoffset implementationsFinn Thain7-32/+0
These dummy implementations are no better than default_arch_gettimeoffset() so remove them. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: mac: Fix VIA timer counter accessesFinn Thain1-49/+53
This resolves some bugs that affect VIA timer counter accesses. Avoid lost interrupts caused by reading the counter low byte register. Make allowance for the fact that the counter will be decremented to 0xFFFF before being reloaded. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-25m68k: Call timer_interrupt() with interrupts disabledFinn Thain11-47/+105
Some platforms execute their timer handler with the interrupt priority level set below 6. That means the handler could be interrupted by another driver and this could lead to re-entry of the timer core. Avoid this by use of local_irq_save/restore for timer interrupt dispatch. This provides mutual exclusion around the timer interrupt flag access which is needed later in this series for the clocksource conversion. Reported-by: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1811131407120.2697@nanos.tec.linutronix.de Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-03-24x86/resctrl: Remove unused variablePeng Hao1-3/+0
Variable "struct rdt_resource *r" is set but not used. So remove it. Signed-off-by: Peng Hao <peng.hao2@zte.com.cn> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/1552152584-26087-1-git-send-email-peng.hao2@zte.com.cn
2019-03-24Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds12-58/+52
Pull x86 fixes from Thomas Gleixner: "A set of x86 fixes: - Prevent potential NULL pointer dereferences in the HPET and HyperV code - Exclude the GART aperture from /proc/kcore to prevent kernel crashes on access - Use the correct macros for Cyrix I/O on Geode processors - Remove yet another kernel address printk leak - Announce microcode reload completion as requested by quite some people. Microcode loading has become popular recently. - Some 'Make Clang' happy fixlets - A few cleanups for recently added code" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/gart: Exclude GART aperture from kcore x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error x86/mm/pti: Make local symbols static x86/cpu/cyrix: Remove {get,set}Cx86_old macros used for Cyrix processors x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors x86/microcode: Announce reload operation's completion x86/hyperv: Prevent potential NULL pointer dereference x86/hpet: Prevent potential NULL pointer dereference x86/lib: Fix indentation issue, remove extra tab x86/boot: Restrict header scope to make Clang happy x86/mm: Don't leak kernel addresses x86/cpufeature: Fix various quality problems in the <asm/cpu_device_hd.h> header
2019-03-24Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-1/+1
Pull irq fixes from Thomas Gleixner: "A set of fixes for the interrupt subsystem: - Remove secondary GIC support on systems w/o device-tree support - A set of small fixlets in various irqchip drivers - static and fall-through annotations - Kernel doc and typo fixes" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq: Mark expected switch case fall-through genirq/devres: Remove excess parameter from kernel doc irqchip/irq-mvebu-sei: Make mvebu_sei_ap806_caps static irqchip/mbigen: Don't clear eventid when freeing an MSI irqchip/stm32: Don't set rising configuration registers at init irqchip/stm32: Don't clear rising/falling config registers at init dt-bindings: irqchip: renesas-irqc: Document r8a774c0 support irqchip/mmp: Make mmp_irq_domain_ops static irqchip/brcmstb-l2: Make two init functions static genirq: Fix typo in comment of IRQD_MOVE_PCNTXT irqchip/gic-v3-its: Fix comparison logic in lpi_range_cmp irqchip/gic: Drop support for secondary GIC in non-DT systems irqchip/imx-irqsteer: Fix of_property_read_u32() error handling
2019-03-24x86/MCE: Group AMD function prototypes in <asm/mce.h>Yazen Ghannam1-14/+11
There are two groups of "ifdef CONFIG_X86_MCE_AMD" function prototypes in <asm/mce.h>. Merge these two groups. No functional change. [ bp: align vertically. ] Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "clemej@gmail.com" <clemej@gmail.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Pu Wen <puwen@hygon.cn> Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Cc: "rafal@milecki.pl" <rafal@milecki.pl> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190322202848.20749-3-Yazen.Ghannam@amd.com
2019-03-23x86/CPU/hygon: Fix phys_proc_id calculation logic for multi-die processorsPu Wen1-0/+5
The Hygon family 18h multi-die processor platform supports 1, 2 or 4-Dies per socket. The topology looks like this: System View (with 1-Die 2-Socket): |------------| ------ ----- SOCKET0 | D0 | | D1 | SOCKET1 ------ ----- System View (with 2-Die 2-socket): -------------------- | -------------|------ | | | | ------------ ------------ SOCKET0 | D1 -- D0 | | D3 -- D2 | SOCKET1 ------------ ------------ System View (with 4-Die 2-Socket) : -------------------- | -------------|------ | | | | ------------ ------------ | D1 -- D0 | | D7 -- D6 | | | \/ | | | | \/ | | SOCKET0 | | /\ | | | | /\ | | SOCKET1 | D2 -- D3 | | D4 -- D5 | ------------ ------------ | | | | ------|------------| | -------------------- Currently phys_proc_id = initial_apicid >> bits calculates the physical processor ID from the initial_apicid by shifting *bits*. However, this does not work for 1-Die and 2-Die 2-socket systems. According to document [1] section 2.1.11.1, the bits is the value of CPUID_Fn80000008_ECX[12:15]. The possible values are 4, 5 or 6 which mean: 4 - 1 die 5 - 2 dies 6 - 3/4 dies. Hygon programs the initial ApicId the same way as AMD. The ApicId is read from CPUID_Fn00000001_EBX (see section 2.1.11.1 of referrence [1]) and the definition is as below (see section 2.1.10.2.1.3 of [1]): ------------------------------------------------- Bit | 6 | 5 4 | 3 | 2 1 0 | |-----------|---------|--------|----------------| IDs | Socket ID | Node ID | CCX ID | Core/Thread ID | ------------------------------------------------- So for 3/4-Die configurations, the bits variable is 6, which is the same as the ApicID definition field. For 1-Die and 2-Die configurations, bits is 4 or 5, which will cause the right shifted result to not be exactly the value of socket ID. However, the socket ID should be obtained from ApicId[6]. To fix the problem and match the ApicID field definition, set the shift bits to 6 for all Hygon family 18h multi-die CPUs. Because AMD doesn't have 2-Socket systems with 1-Die/2-Die processors (see reference [2]), this doesn't need to be changed on the AMD side but only for Hygon. References: [1] https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf [2] https://www.amd.com/en/products/specifications/processors [bp: heavily massage commit message. ] Signed-off-by: Pu Wen <puwen@hygon.cn> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Thomas Lendacky <Thomas.Lendacky@amd.com> Cc: Yazen Ghannam <yazen.ghannam@amd.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1553355740-19999-1-git-send-email-puwen@hygon.cn
2019-03-23x86/gart: Exclude GART aperture from kcoreKairui Song1-7/+13
On machines where the GART aperture is mapped over physical RAM, /proc/kcore contains the GART aperture range. Accessing the GART range via /proc/kcore results in a kernel crash. vmcore used to have the same issue, until it was fixed with commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore")', leveraging existing hook infrastructure in vmcore to let /proc/vmcore return zeroes when attempting to read the aperture region, and so it won't read from the actual memory. Apply the same workaround for kcore. First implement the same hook infrastructure for kcore, then reuse the hook functions introduced in the previous vmcore fix. Just with some minor adjustment, rename some functions for more general usage, and simplify the hook infrastructure a bit as there is no module usage yet. Suggested-by: Baoquan He <bhe@redhat.com> Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Jiri Bohac <jbohac@suse.cz> Acked-by: Baoquan He <bhe@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Omar Sandoval <osandov@fb.com> Cc: Dave Young <dyoung@redhat.com> Link: https://lkml.kernel.org/r/20190308030508.13548-1-kasong@redhat.com
2019-03-22arm64: dts: meson-g12a-sei510: add regulatorsJerome Brunet1-0/+57
Add some regulators. Still missing * VDD_EE (0.8V - PWM controlled) * VDD_CPU(PWM controlled) * VDDQ1_5 Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson-g12a-x96-max: add uart_AO pinctrlNeil Armstrong1-0/+2
Add pinctrl on the always-enabled debug UART AO. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson-g12a-sei510: add uart_AO pinctrlNeil Armstrong1-0/+2
Add pinctrl on the always-enabled debug UART AO. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson-g12a-u200: add uart_AO pinctrlNeil Armstrong1-0/+2
Add pinctrl on the always-enabled debug UART AO. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson: g12a: Add UART A, B & C nodes and pinsNeil Armstrong1-0/+72
This patch adds the 3 UART nodes in the EE power domain with the corresponding pinctrl nodes. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson: g12a: add reset controllerJerome Brunet1-0/+7
Add the reset controller device of g12a SoC family Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson: g12a: add uart_ao_a pinctrlJerome Brunet1-0/+18
Add the always on UART pinctrl setting to the g12a soc DT. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson: g12a: add pinctrl support controllersJerome Brunet1-0/+42
Add the peripheral and always-on pinctrl controllers to the g12a soc. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22arm64: dts: meson: g12a: Add AO Clock + Reset Controller supportNeil Armstrong1-0/+17
Add nodes and properties for the AO Clocks and Resets. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2019-03-22ARM: dts: am335x-evmsk: Correct the regulators for the audio codecPeter Ujfalusi1-4/+22
Correctly map the regulators used by tlv320aic3106. Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators. Cc: <Stable@vger.kernel.org> # v4.14+ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-03-22ARM: dts: am335x-evm: Correct the regulators for the audio codecPeter Ujfalusi1-4/+22
Correctly map the regulators used by tlv320aic3106. Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators. Cc: <Stable@vger.kernel.org> # v4.14+ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-03-22ARM: OMAP2+: add missing of_node_put after of_device_is_availableJulia Lawall1-1/+3
Add an of_node_put when a tested device node is not available. The semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ identifier f; local idexpression e; expression x; @@ e = f(...); ... when != of_node_put(e) when != x = e when != e = x when any if (<+...of_device_is_available(e)...+>) { ... when != of_node_put(e) ( return e; | + of_node_put(e); return ...; ) } // </smpl> Fixes: e0c827aca0730 ("drm/omap: Populate DSS children in omapdss driver") Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-03-22ARM: OMAP1: ams-delta: Fix broken GPIO ID allocationJanusz Krzysztofik1-0/+2
In order to request dynamic allocationn of GPIO IDs, a negative number should be passed as a base GPIO ID via platform data. Unfortuntely, commit 771e53c4d1a1 ("ARM: OMAP1: ams-delta: Drop board specific global GPIO numbers") didn't follow that rule while switching to dynamically allocated GPIO IDs for Amstrad Delta latches, making their IDs overlapping with those already assigned to OMAP GPIO devices. Fix it. Fixes: 771e53c4d1a1 ("ARM: OMAP1: ams-delta: Drop board specific global GPIO numbers") Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: stable@vger.kernel.org Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-03-22Merge tag 'powerpc-5.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds7-29/+25
Pull powerpc fixes from Michael Ellerman: "One fix for a boot failure on 32-bit, introduced during the merge window. A fix for our handling of CLOCK_MONOTONIC in the 64-bit VDSO. Changing the wall clock across the Y2038 boundary could cause CLOCK_MONOTONIC to jump forward and backward. Our spectre_v2 reporting was a bit confusing due to a bug I introduced. On some systems it was reporting that the count cache was disabled and also that we were flushing the count cache on context switch. Only the former is true, and given that the count cache is disabled it doesn't make any sense to flush it. No one reported it, so presumably the presence of any mitigation is all people check for. Finally a small build fix for zsmalloc on 32-bit. Thanks to: Ben Hutchings, Christophe Leroy, Diana Craciun, Guenter Roeck, Michael Neuling" * tag 'powerpc-5.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/security: Fix spectre_v2 reporting powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations powerpc/6xx: fix setup and use of SPRN_SPRG_PGDIR for hash32 powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038
2019-03-22Merge branch 'x86/cpu' into x86/urgentThomas Gleixner1-16/+15
Merge the forgotten cleanup patch for the new file, so the mess does not propagate further.
2019-03-22x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an errorNathan Chancellor1-0/+1
When building with -Wsometimes-uninitialized, Clang warns: arch/x86/kernel/hw_breakpoint.c:355:2: warning: variable 'align' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized] The default cannot be reached because arch_build_bp_info() initializes hw->len to one of the specified cases. Nevertheless the warning is valid and returning -EINVAL makes sure that this cannot be broken by future modifications. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: clang-built-linux@googlegroups.com Link: https://github.com/ClangBuiltLinux/linux/issues/392 Link: https://lkml.kernel.org/r/20190307212756.4648-1-natechancellor@gmail.com
2019-03-22x86/tsc: Add option to disable tsc clocksource watchdogJuri Lelli1-1/+4
Clocksource watchdog has been found responsible for generating latency spikes (in the 10-20 us range) when woken up to check for TSC stability. Add an option to disable it at boot. Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: bigeasy@linutronix.de Cc: linux-rt-users@vger.kernel.org Cc: peterz@infradead.org Cc: bristot@redhat.com Cc: williams@redhat.com Link: https://lkml.kernel.org/r/20190307120913.13168-1-juri.lelli@redhat.com
2019-03-22crypto: arm64 - convert to use crypto_simd_usable()Eric Biggers15-34/+47
Replace all calls to may_use_simd() in the arm64 crypto code with crypto_simd_usable(), in order to allow testing the no-SIMD code paths. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-03-22crypto: arm - convert to use crypto_simd_usable()Eric Biggers10-19/+29
Replace all calls to may_use_simd() in the arm crypto code with crypto_simd_usable(), in order to allow testing the no-SIMD code paths. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-03-22crypto: x86 - convert to use crypto_simd_usable()Eric Biggers12-36/+44
Replace all calls to irq_fpu_usable() in the x86 crypto code with crypto_simd_usable(), in order to allow testing the no-SIMD code paths. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-03-22crypto: arm64/gcm-aes-ce - fix no-NEON fallback codeEric Biggers1-4/+6
The arm64 gcm-aes-ce algorithm is failing the extra crypto self-tests following my patches to test the !may_use_simd() code paths, which previously were untested. The problem is that in the !may_use_simd() case, an odd number of AES blocks can be processed within each step of the skcipher_walk. However, the skcipher_walk is being done with a "stride" of 2 blocks and is advanced by an even number of blocks after each step. This causes the encryption to produce the wrong ciphertext and authentication tag, and causes the decryption to incorrectly fail. Fix it by only processing an even number of blocks per step. Fixes: c2b24c36e0a3 ("crypto: arm64/aes-gcm-ce - fix scatterwalk API violation") Fixes: 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on two input blocks at a time") Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.