- Jun 18, 2020
-
-
Phil Elwell authored
The BCM2835 PL011 implementation seems to have a bug that can lead to a transmission lockup if CTS changes frequently. A workaround was added to the driver with a vendor-specific flag to enable it, but this flag is currently not set for ARM implementations. Add a "cts-event-workaround" property to Pi DTBs and use the presence of that property to force the flag to be enabled in the driver. See: https://github.com/raspberrypi/linux/issues/1280 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The pl011 register accessor functions use the _relaxed versions of the standard readl() and writel() functions, meaning that there are no automatic memory barriers. When polling a FIFO status register to check for fullness, it is necessary to ensure that any outstanding writes have completed; otherwise the flags are effectively stale, making it possible that the next write is to a full FIFO. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The UART clock is initialised to be as close to the requested frequency as possible without exceeding it. Now that there is a clock manager that returns the actual frequencies, an expected 48MHz clock is reported as 47999625. If the requested baudrate == requested clock/16, there is no headroom and the slight reduction in actual clock rate results in failure. Detect cases where it looks like a "round" clock was chosen and adjust the reported clock to match that "round" value. As the code comment says: /* * If increasing a clock by less than 0.1% changes it * from ..999.. to ..000.., round up. */ Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The pl011 driver looks for DT aliases of the form "serial<n>", and if found uses <n> as the device ID. This can cause /dev/ttyAMA0 to become /dev/ttyAMA1, which is confusing if the other serial port is provided by the 8250 driver which doesn't use the same logic.
-
Phil Elwell authored
For applications of the LAN78xx that don't have valid programmed EEPROMs or OTPs, enabling both LEDs and auto-negotiation by default seems reasonable. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The syscon node defines a register range that duplicates that used by the local_intc node on bcm2836/7. Since irq-bcm2835 and irq-bcm2836 are built in and always present together (both drivers are enabled by CONFIG_ARCH_BCM2835), it is possible to replace the syscon usage with a global variable that simplifies the code. Doing so does lose the locking provided by regmap, but as only one side is using the regmap interface (irq-bcm2835 uses readl and write) there is no loss of atomicity. See: https://github.com/raspberrypi/firmware/issues/926 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
Without a prompt string, a config setting can't be included in a defconfig. Give CONFIG_SND_SOC_ICS43432 a prompt so that Pi soundcards can use the driver. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Eric Anholt authored
See commit dae803e1 -- the warning is expected sometimes when using CMA. However, that commit still spams my kernel log with these warnings. Signed-off-by: Eric Anholt <eric@anholt.net>
-
Noralf Trønnes authored
This adds a debug module parameter to aid in debugging transfer issues by printing info to the kernel log. When enabled, status values are collected in the interrupt routine and msg info in bcm2835_i2c_start_transfer(). This is done in a way that tries to avoid affecting timing. Having printk in the isr can mask issues. debug values (additive): 1: Print info on error 2: Print info on all transfers 3: Print messages before transfer is started The value can be changed at runtime: /sys/module/i2c_bcm2835/parameters/debug Example output, debug=3: [ 747.114448] bcm2835_i2c_xfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1] [ 747.114463] bcm2835_i2c_xfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1] [ 747.117809] start_transfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1] [ 747.117825] isr: remain=2, status=0x30000055 : TA TXW TXD TXE [i2c1] [ 747.117839] start_transfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1] [ 747.117849] isr: remain=32, status=0xd0000039 : TA RXR TXD RXD [i2c1] [ 747.117861] isr: remain=20, status=0xd0000039 : TA RXR TXD RXD [i2c1] [ 747.117870] isr: remain=8, status=0x32 : DONE TXD RXD [i2c1] Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
-
Claggy3 authored
Christopher Alexander Tobias Schulze - May 2, 2015, 11:57 a.m. This patch fixes a problem with VFP state save and restore related to exception handling (panic with message "BUG: unsupported FP instruction in kernel mode") present on VFP11 floating point units (as used with ARM1176JZF-S CPUs, e.g. on first generation Raspberry Pi boards). This patch was developed and discussed on https://github.com/raspberrypi/linux/issues/859 A precondition to see the crashes is that floating point exception traps are enabled. In this case, the VFP11 might determine that a FPU operation needs to trap at a point in time when it is not possible to signal this to the ARM11 core any more. The VFP11 will then set the FPEXC.EX bit and store the trapped opcode in FPINST. (In some cases, a second opcode might have been accepted by the VFP11 before the exception was detected and could be reported to the ARM11 - in this case, the VFP11 also sets FPEXC.FP2V and stores the second opcode in FPINST2.) If FPEXC.EX is set, the VFP11 will "bounce" the next FPU opcode issued by the ARM11 CPU, which will be seen by the ARM11 as an undefined opcode trap. The VFP support code examines the FPEXC.EX and FPEXC.FP2V bits to decide what actions to take, i.e., whether to emulate the opcodes found in FPINST and FPINST2, and whether to retry the bounced instruction. If a user space application has left the VFP11 in this "pending trap" state, the next FPU opcode issued to the VFP11 might actually be the VSTMIA operation vfp_save_state() uses to store the FPU registers to memory (in our test cases, when building the signal stack frame). In this case, the kernel crashes as described above. This patch fixes the problem by making sure that vfp_save_state() is always entered with FPEXC.EX cleared. (The current value of FPEXC has already been saved, so this does not corrupt the context. Clearing FPEXC.EX has no effects on FPINST or FPINST2. Also note that many callers already modify FPEXC by setting FPEXC.EN before invoking vfp_save_state().) This patch also addresses a second problem related to FPEXC.EX: After returning from signal handling, the kernel reloads the VFP context from the user mode stack. However, the current code explicitly clears both FPEXC.EX and FPEXC.FP2V during reload. As VFP11 requires these bits to be preserved, this patch disables clearing them for VFP implementations belonging to architecture 1. There should be no negative side effects: the user can set both bits by executing FPU opcodes anyway, and while user code may now place arbitrary values into FPINST and FPINST2 (e.g., non-VFP ARM opcodes) the VFP support code knows which instructions can be emulated, and rejects other opcodes with "unhandled bounce" messages, so there should be no security impact from allowing reloading FPEXC.EX and FPEXC.FP2V. Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
-
Phil Elwell authored
At present there is no mechanism to specify driver load order, which can lead to deferrals and repeated retries until successful. Since this situation is expected, reduce the dmesg level to INFO and mention that the operation will be retried. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Eric Anholt authored
These divide off of PLLD_PER and are used for the ethernet and wifi PHYs source PLLs. Neither of them is currently represented by a phy device that would grab the clock for us. This keeps other drivers from killing the networking PHYs when they disable their own clocks and trigger PLLD_PER's refcount going to 0. v2: Skip marking as critical if they aren't on at boot. Signed-off-by: Eric Anholt <eric@anholt.net>
-
Phil Elwell authored
The VPU is responsible for managing the core clock, usually under direction from the bcm2835-cpufreq driver but not via the clk-bcm2835 driver. Since the core frequency can change without warning, it is safer to report the maximum clock rate to users of the core clock - I2C, SPI and the mini UART - to err on the safe side when calculating clock divisors. If the DT node for the clock driver includes a reference to the firmware node, use the firmware API to query the maximum core clock instead of reading the divider registers. Prior to this patch, a "100KHz" I2C bus was sometimes clocked at about 160KHz. In particular, switching to the 4.9 kernel was likely to break SenseHAT usage on a Pi3. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The claim-clocks property can be used to prevent PLLs and dividers from being marked as critical. It contains a vector of clock IDs, as defined by dt-bindings/clock/bcm2835.h. Use this mechanism to claim PLLD_DSI0, PLLD_DSI1, PLLH_AUX and PLLH_PIX for the vc4_kms_v3d driver. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The VPU configures and relies on several PLLs and dividers. Mark all enabled dividers and their PLLs as CRITICAL to prevent the kernel from switching them off. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
popcornmix authored
Avoids the 0x40000 cycles of warmup again if firmware has already used it
-
Martin Sperl authored
Register the clocks early during the boot process, so that special/critical clocks can get enabled early on in the boot process avoiding the risk of disabling a clock, pll_divider or pll when a claiming driver fails to install propperly - maybe it needs to defer. Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
-
popcornmix authored
-
popcornmix authored
-
Noralf Trønnes authored
The Raspberry Pi firmware looks at the RSTS register to know which partition to boot from. The reboot syscall command LINUX_REBOOT_CMD_RESTART2 supports passing in a string argument. Add support for passing in a partition number 0..63 to boot from. Partition 63 is a special partiton indicating halt. If the partition doesn't exist, the firmware falls back to partition 0. Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
-
Phil Elwell authored
Without this alias, Device Tree won't cause the driver to be loaded. See: https://github.com/raspberrypi/linux/pull/1510
-
popcornmix authored
-
Noralf Trønnes authored
Load driver early since at least bcm2708_fb doesn't support deferred probing and even if it did, we don't want the video driver deferred. Support the legacy DMA API which is needed by bcm2708_fb. Don't mask out channel 2. Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
-
Phil Elwell authored
An alternative strategy would be to use "rpi,spidev" instead, but that would require many Raspberry Pi Device Tree changes. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Noralf Trønnes authored
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
-
Noralf Trønnes authored
Add a duplicate irq range with an offset on the hwirq's so the driver can detect that enable_fiq() is used. Tested with downstream dwc_otg USB controller driver. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
-
Phil Elwell authored
Initialise the level for each IRQ to avoid a warning from the arm arch timer code. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The old arch-specific IRQ macros included a dsb to ensure the write to clear the mailbox interrupt completed before returning from the interrupt. The BCM2836 irqchip driver needs the same precaution to avoid spurious interrupts. Spurious interrupts are still possible for other reasons, though, so trap them early.
-
Phil Elwell authored
Without this patch, removing a device tree overlay can crash here. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
popcornmix authored
Signed-off-by: popcornmix <popcornmix@gmail.com>
-
Sam Nazarko authored
See: http://forum.kodi.tv/showthread.php?tid=285288
-
Steve Glendinning authored
smsc95xx is adjusting truesize when it shouldn't, and following a recent patch from Eric this is now triggering warnings. This patch stops smsc95xx from changing truesize. Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
-
Phil Elwell authored
This reverts commit ede44c90. See: https://github.com/raspberrypi/firmware/issues/1065 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Dan Pasanen authored
* Re-expose some dmi APIs for use in VCSM
-
- Jun 17, 2020
-
-
Greg Kroah-Hartman authored
-
Marc Zyngier authored
commit ef3e40a7 upstream. When using the PtrAuth feature in a guest, we need to save the host's keys before allowing the guest to program them. For that, we dump them in a per-CPU data structure (the so called host context). But both call sites that do this are in preemptible context, which may end up in disaster should the vcpu thread get preempted before reentering the guest. Instead, save the keys eagerly on each vcpu_load(). This has an increased overhead, but is at least safe. Cc: stable@vger.kernel.org Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marc Zyngier authored
commit 0370964d upstream. On a VHE system, the EL1 state is left in the CPU most of the time, and only syncronized back to memory when vcpu_put() is called (most of the time on preemption). Which means that when injecting an exception, we'd better have a way to either: (1) write directly to the EL1 sysregs (2) synchronize the state back to memory, and do the changes there For an AArch64, we already do (1), so we are safe. Unfortunately, doing the same thing for AArch32 would be pretty invasive. Instead, we can easily implement (2) by calling the put/load architectural backends, and keep preemption disabled. We can then reload the state back into EL1. Cc: stable@vger.kernel.org Reported-by: James Morse <james.morse@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mattia Dongili authored
commit 476d60b1 upstream. The thermal handle object may fail initialization when the module is loaded in the first place. Avoid attempting to use it on resume then. Fixes: 6d232b29 ("ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator") Reported-by: Dominik Mierzejewski <dominik@greysector.net> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491 Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mattia Dongili authored
commit 47828d22 upstream. After commit 6d232b29 ("ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator") ACPICA creates buffers even when new fields are small enough to fit into an integer. Many SNC calls counted on the old behaviour. Since sony-laptop already handles the INTEGER/BUFFER case in sony_nc_buffer_call, switch sony_nc_int_call to use its more generic function instead. Fixes: 6d232b29 ("ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator") Reported-by: Dominik Mierzejewski <dominik@greysector.net> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491 Reported-by: William Bader <williambader@hotmail.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1830150 Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Juergen Gross authored
commit c8d70a29 upstream. backend_connect() can fail, so switch the device to connected only if no error occurred. Fixes: 0a9c75c2 ("xen/pvcalls: xenbus state handling") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20200511074231.19794-1-jgross@suse.com Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-