-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends" #2716
Conversation
* Re-expose some dmi APIs for use in VCSM
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>
Signed-off-by: popcornmix <popcornmix@gmail.com>
Without this patch, removing a device tree overlay can crash here. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
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.
Initialise the level for each IRQ to avoid a warning from the arm arch timer code. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
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>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
The spi-bcm2835 driver automatically uses GPIO chip-selects due to some unreliability of the native ones. In doing so it chooses the same pins as the native chip-selects would use, but the existing code always uses pins 7 and 8, wherever the SPI function is mapped. Search the pinctrl group assigned to the driver for pins that correspond to native chip-selects, and use those for GPIO chip- selects. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Select software CS in bcm2708_common.dtsi, and disable the automatic conversion in the driver to allow hardware CS to be re-enabled with an overlay. See: raspberrypi#1547 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
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>
Without this alias, Device Tree won't cause the driver to be loaded. See: raspberrypi#1510
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>
…itical 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>
Avoids the 0x40000 cycles of warmup again if firmware has already used it
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>
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>
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>
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>
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>
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 raspberrypi#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>
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>
See commit dae803e -- 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>
Reduce the amount of duplicated code by creating a generic driver for Pi Hat digi cards using the WM8804 codec. This replaces the Allo DigiOne, Hifiberry Digi/Pro, JustBoom Digi and IQAudIO Digi dedicate soundcard drivers with a generic driver. There are no significant changes to the runtime behavior of the drivers and end users should not have to change any configuration settings after upgrading. Minor changes * Check the return value of snd_soc_component_update_bits * Added some pr_debug tracing * Various checkpatch tidyups * Updated allodigi-one to use use 128FS at > 96 Khz. This appears to be an omission in the original driver code so followed the Hifiberry DAC driver approach.
This reverts commit 14dd37f.
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
A couple of DVB drivers (CX231XX, AF9015, RTL28XXU) now depend on I2C_MUX so add I2C_MUX=m so we build the same set of DVB drivers as in 4.14. IR decoders no longer default to "y" in Kconfig and have to be enabled in the defconfig. defconfigs have been regenerated with "make savedefconfig" Signed-off-by: Matthias Reichl <hias@horus.com>
The driver_name shows up in /proc/asound/devices and is used to load the proper Alsa card conf from /usr/share/alsa/cards. But the length is limited to 15 characters and spaces are replaced by underscore so the mangled name currently is "RPI_WM8804_soun" which is not very nice. Use "RPi-WM8804" instead which won't be mangled and can be used unaltered as the card conf filename and card name in that file. Signed-off-by: Matthias Reichl <hias@horus.com>
…ty (v3)"" This reverts commit 6823be4.
The ARM coprocessor registers include dcache line size, but there is no function to expose this value. Rather than create a new one, use the read_cpuid_id function to derive the correct value, which is 32 for BCM2835 and 64 for BCM2836/7. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The size field in a Device Tree "reg" property is encoded in bytes, not words. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Retain a vestigial cache_line_size parameter to improve backwards- compatibility. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Rename the driver from "RPI simple soundcard" to "RPi-simple" so that the driver name won't be mangled allowing to be used unaltered as the card conf filename.
Signed-off-by: Serge Schneider <serge@raspberrypi.org> PoE HAT driver cleanup * Fix undeclared variable in rpi_poe_fan_suspend * Add SPDX-License-Identifier * Expand PoE acronym in Kconfig help * Give clearer error message on of_property_count_u32_elems fail * Add documentation * Add vendor to of_device_id compatible string. * Rename m_data_s struct to fw_data_s * Fix typos Fixes: raspberrypi#2665 Signed-off-by: Serge Schneider <serge@raspberrypi.org>
Rationalise the offset and update all call sites. Fixes raspberrypi#2408
It appears the GPU only sends us a message all 10ms to update the playback progress. Other than this, the playback position (what SNDRV_PCM_IOCTL_DELAY will return) is not updated at all. Userspace will see jitter up to 10ms in the audio position. Make this a bit nicer for userspace by interpolating the position using the CPU clock. I'm not sure if setting snd_pcm_runtime.delay is the right approach for this. Or if there is maybe an already existing mechanism for position interpolation in the ALSA core. I only set SNDRV_PCM_INFO_BATCH because this appears to remove at least one situation snd_pcm_runtime.delay is used, so I have to worry less in which place I have to update this field, or how it interacts with the rest of ALSA. In the future, it might be nice to use VC_AUDIO_MSG_TYPE_LATENCY. One problem is that it requires sending a videocore message, and waiting for a reply, which could make the implementation much harder due to locking and synchronization requirements.
…rrypi#2699) During a bulk transfer we request a DMA allocation to hold the scatter-gather list. Most of the time, this allocation is small (<< PAGE_SIZE), however it can be requested at a high enough frequency to cause fragmentation and/or stress the CMA allocator (think time spent in compaction here, or during allocations elsewhere). Implement a pool to serve up small DMA allocations, falling back to a coherent allocation if the request is greater than VCHIQ_DMA_POOL_SIZE. Signed-off-by: Oliver Gjoneski <ogjoneski@gmail.com>
The upstreamed driver for the GPIO expander has a different compatible string. Change the relevant Device Tree files to match. See: raspberrypi#2704 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Daniel Matuschek <daniel@hifiberry.com>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Create a new composite driver to support PCM512x based Pi-HAT DAC soundcards in order to reduce the maintenance overhead for upstream changes. This replaces the specific drivers for the following cards: * Allo Piano DAC * DionAudio Loco V2 * Justboom DAC * IQAudioIO DAC
commit 2f7d8db upstream. While having SECURITYFS enabled for the tpm subsystem is beneficial in most cases, it is not strictly necessary to have it enabled at all. Especially on platforms without any boot firmware integration of the TPM (e.g. raspberry pi) it does not add any value for the tpm subsystem, as there is no eventlog present. By turning it from 'select' to 'imply' it still gets selected per default, but enables users who want to save some kb of ram by turning SECURITYFS off. Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
This patch enables the support for SPI TPMs which follow the TCG TIS FIFO/PTP specification like the SLB9670. In order to decrease ram usage the weak dependency on CONFIG_SECURITFS is explictly set to 'n'. Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Device Tree overlay for the Infineon SLB9670 Trusted Platform Module add-on boards, which can be used as a secure key storage and hwrng. available as "Iridium SLB9670" by Infineon and "LetsTrust TPM" by pi3g. Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
This reverts commit 88078d9. Various people have been reporting seeing "eth0: hw csum failure" and callstacks dumped in the kernel log on 4.18, and since 4.14.71, on both SMSC9514 and LAN7800 adapters. This commit appears to be the reason, but potentially due to an issue further down the stack. Revert whilst investigating the trigger. raspberrypi#2713 raspberrypi#2659 raspberrypi#2712 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
@pelwell revert as discussed. Do we want to defer merging this one until we have a way to reproduce? Fixing 4.14 needs to be a priority as that is our supported kernel, but 4.18 isn't so may lead to someone giving us guaranteed steps to reproduce the issue and investigate. |
If we're realistically expecting 4.18 to be used by a significant number of users it should be released to the |
James has found https://patchwork.ozlabs.org/patch/982642/ which might be a candidate for a potential fix on 4.18 instead of revert. |
#2718 is a cherry-pick of the mailing list patch applied to 4.18 as an alternative to this revert. |
f540527
to
e7bbc87
Compare
Seeing as popcornmix has merged the net-dev patch, I'll close this for now. |
This reverts commit 88078d9.
Various people have been reporting seeing "eth0: hw csum failure"
and callstacks dumped in the kernel log on 4.18, and since 4.14.71,
on both SMSC9514 and LAN7800 adapters.
This commit appears to be the reason, but potentially due to an
issue further down the stack. Revert whilst investigating the
trigger.
#2713
#2659
#2712
Signed-off-by: Dave Stevenson dave.stevenson@raspberrypi.org