aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-03-31dt-bindings: interrupt-controller: msi: Correct msi-controller@c's regBin Meng1-1/+1
The base address of msi-controller@c should be set to c. Signed-off-by: Bin Meng <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: spi: Add interconnect binding for QSPIAkash Asthana1-0/+9
Add documentation for the interconnect and interconnect-names properties for QSPI. Signed-off-by: Akash Asthana <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: spi: Convert QSPI bindings to YAMLAkash Asthana2-36/+79
Convert QSPI bindings to DT schema format using json-schema. Signed-off-by: Akash Asthana <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: thermal: rcar-thermal: Convert bindings to json-schemaNiklas Söderlund2-78/+139
Convert Renesas R-Car Thermal bindings documentation to json-schema. Signed-off-by: Niklas Söderlund <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: phy: Convert phy-mmp3-usb to json-schemaLubomir Rintel2-13/+42
A rather straightforward conversion of the phy-mmp3-usb binding to DT schema format using json-schema. Signed-off-by: Lubomir Rintel <[email protected]> [robh: add additionalProperties] Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: Add "mrvl", a legacy vendor prefix for MarvellLubomir Rintel1-0/+3
While the preferred vendor prefix is "marvell", "mrvl" is used by many older bindings already. Add it, while also marking it deprecated. Signed-off-by: Lubomir Rintel <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: arm: mrvl: Add missing compatible stringsLubomir Rintel1-1/+4
Add compatible strings for the boards we have in tree. At the same time, fix the MMP3 compatible string: the preferred vendor name for Marvell is "marvell", not "mrvl", and indeed "marvell,mmp3" has been actively used, not "mrvl,mmp3". Fixes: 95aecb71b84e ("dt-bindings: arm: mrvl: Document MMP3 compatible string") Signed-off-by: Lubomir Rintel <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: arm: l2x0: Tauros 3 is PL310 compatibleLubomir Rintel1-21/+24
The validation is unhappy about mmp3-dell-ariel declaring its marvell,tauros3-cache node to be compatible with arm,pl310-cache: mmp3-dell-ariel.dt.yaml: cache-controller@d0020000: compatible: Additional items are not allowed ('arm,pl310-cache' was unexpected) mmp3-dell-ariel.dt.yaml: cache-controller@d0020000: compatible: ['marvell,tauros3-cache', 'arm,pl310-cache'] is too long Let's allow this -- Tauros 3 is designed to be compatible with PL310. Signed-off-by: Lubomir Rintel <[email protected]> [robh: fixup indentation] Signed-off-by: Rob Herring <[email protected]>
2020-03-31dt-bindings: Add missing 'additionalProperties: false'Rob Herring116-0/+238
Setting 'additionalProperties: false' is frequently omitted, but is important in order to check that there aren't extra undocumented properties in a binding. Ideally, we'd just add this automatically and make this the default, but there's some cases where it doesn't work. For example, if a common schema is referenced, then properties in the common schema aren't part of what's considered for 'additionalProperties'. Also, sometimes there are bus specific properties such as 'spi-max-frequency' that go into bus child nodes, but aren't defined in the child node's schema. So let's stick with the json-schema defined default and add 'additionalProperties: false' where needed. This will be a continual review comment and game of wack-a-mole. Signed-off-by: Rob Herring <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Acked-by: Mark Brown <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Acked-by: Alexandru Ardelean <[email protected]> Reviewed-by: Benjamin Gaignard <[email protected]> Acked-by: Stephen Boyd <[email protected]> # clock Acked-by: Lee Jones <[email protected]>
2020-03-31KVM: x86: Fix BUILD_BUG() in __cpuid_entry_get_reg() w/ CONFIG_UBSAN=ySean Christopherson2-5/+5
Take the target reg in __cpuid_entry_get_reg() instead of a pointer to a struct cpuid_reg. When building with -fsanitize=alignment (enabled by CONFIG_UBSAN=y), some versions of gcc get tripped up on the pointer and trigger the BUILD_BUG(). Reported-by: Randy Dunlap <[email protected]> Fixes: d8577a4c238f8 ("KVM: x86: Do host CPUID at load time to mask KVM cpu caps") Fixes: 4c61534aaae2a ("KVM: x86: Introduce cpuid_entry_{get,has}() accessors") Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: VMX: Add a trampoline to fix VMREAD error handlingSean Christopherson2-7/+79
Add a hand coded assembly trampoline to preserve volatile registers across vmread_error(), and to handle the calling convention differences between 64-bit and 32-bit due to asmlinkage on vmread_error(). Pass @field and @fault on the stack when invoking the trampoline to avoid clobbering volatile registers in the context of the inline assembly. Calling vmread_error() directly from inline assembly is partially broken on 64-bit, and completely broken on 32-bit. On 64-bit, it will clobber %rdi and %rsi (used to pass @field and @fault) and any volatile regs written by vmread_error(). On 32-bit, asmlinkage means vmread_error() expects the parameters to be passed on the stack, not via regs. Opportunistically zero out the result in the trampoline to save a few bytes of code for every VMREAD. A happy side effect of the trampoline is that the inline code footprint is reduced by three bytes on 64-bit due to PUSH/POP being more efficent (in terms of opcode bytes) than MOV. Fixes: 6e2020977e3e6 ("KVM: VMX: Add error handling to VMREAD helper") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: SVM: Annotate svm_x86_ops as __initdataSean Christopherson1-1/+1
Tag svm_x86_ops with __initdata now the the struct is copied by value to a common x86 instance of kvm_x86_ops as part of kvm_init(). Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: VMX: Annotate vmx_x86_ops as __initdataSean Christopherson1-1/+1
Tag vmx_x86_ops with __initdata now the the struct is copied by value to a common x86 instance of kvm_x86_ops as part of kvm_init(). Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: x86: Drop __exit from kvm_x86_ops' hardware_unsetup()Sean Christopherson2-2/+2
Remove the __exit annotation from VMX hardware_unsetup(), the hook can be reached during kvm_init() by way of kvm_arch_hardware_unsetup() if failure occurs at various points during initialization. Removing the annotation also lets us annotate vmx_x86_ops and svm_x86_ops with __initdata; otherwise, objtool complains because it doesn't understand that the vendor specific __initdata is being copied by value to a non-__initdata instance. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: x86: Copy kvm_x86_ops by value to eliminate layer of indirectionSean Christopherson15-257/+257
Replace the kvm_x86_ops pointer in common x86 with an instance of the struct to save one pointer dereference when invoking functions. Copy the struct by value to set the ops during kvm_init(). Arbitrarily use kvm_x86_ops.hardware_enable to track whether or not the ops have been initialized, i.e. a vendor KVM module has been loaded. Suggested-by: Paolo Bonzini <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: x86: Set kvm_x86_ops only after ->hardware_setup() completesSean Christopherson1-2/+2
Set kvm_x86_ops with the vendor's ops only after ->hardware_setup() completes to "prevent" using kvm_x86_ops before they are ready, i.e. to generate a null pointer fault instead of silently consuming unconfigured state. An alternative implementation would be to have ->hardware_setup() return the vendor's ops, but that would require non-trivial refactoring, and would arguably result in less readable code, e.g. ->hardware_setup() would need to use ERR_PTR() in multiple locations, and each vendor's declaration of the runtime ops would be less obvious. No functional change intended. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: VMX: Configure runtime hooks using vmx_x86_opsSean Christopherson3-21/+24
Configure VMX's runtime hooks by modifying vmx_x86_ops directly instead of using the global kvm_x86_ops. This sets the stage for waiting until after ->hardware_setup() to set kvm_x86_ops with the vendor's implementation. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: VMX: Move hardware_setup() definition below vmx_x86_opsSean Christopherson1-153/+153
Move VMX's hardware_setup() below its vmx_x86_ops definition so that a future patch can refactor hardware_setup() to modify vmx_x86_ops directly instead of indirectly modifying the ops via the global kvm_x86_ops. No functional change intended. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: x86: Move init-only kvm_x86_ops to separate structSean Christopherson4-18/+36
Move the kvm_x86_ops functions that are used only within the scope of kvm_init() into a separate struct, kvm_x86_init_ops. In addition to identifying the init-only functions without restorting to code comments, this also sets the stage for waiting until after ->hardware_setup() to set kvm_x86_ops. Setting kvm_x86_ops after ->hardware_setup() is desirable as many of the hooks are not usable until ->hardware_setup() completes. No functional change intended. Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31KVM: Pass kvm_init()'s opaque param to additional arch funcsSean Christopherson7-16/+26
Pass @opaque to kvm_arch_hardware_setup() and kvm_arch_check_processor_compat() to allow architecture specific code to reference @opaque without having to stash it away in a temporary global variable. This will enable x86 to separate its vendor specific callback ops, which are passed via @opaque, into "init" and "runtime" ops without having to stash away the "init" ops. No functional change intended. Reviewed-by: Cornelia Huck <[email protected]> Tested-by: Cornelia Huck <[email protected]> #s390 Acked-by: Marc Zyngier <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Reviewed-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2020-03-31Merge tag 'kvm-ppc-next-5.7-1' of ↵Paolo Bonzini25-122/+205
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into HEAD KVM PPC update for 5.7 * Add a capability for enabling secure guests under the Protected Execution Framework ultravisor * Various bug fixes and cleanups.
2020-03-31Merge tag 'kvmarm-5.7' of ↵Paolo Bonzini663-11702/+7583
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm updates for Linux 5.7 - GICv4.1 support - 32bit host removal
2020-03-31pinctrl: qcom: fix compilation errorAnsuel Smith1-1/+0
pinctrl: qcom: use scm_call to route GPIO irq to Apps has a typo in the patch and introduced a compilation error. Fixes: 13bec8d4 pinctrl: qcom: use scm_call to route GPIO irq to Apps Signed-off-by: Ansuel Smith <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-03-31ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra ↵Andreas Steinmetz1-5/+24
endpoint descriptor The Miditech MIDIFACE 16x16 (USB ID 1290:1749) has more than one extra endpoint descriptor. The first extra descriptor is: 0x06 0x30 0x00 0x00 0x00 0x00 As the code in snd_usbmidi_get_ms_info() looks only at the first extra descriptor to find USB_DT_CS_ENDPOINT the device as such is recognized but there is neither input nor output configured. The patch iterates through the extra descriptors to find the proper one. With this patch the device is correctly configured. Signed-off-by: Andreas Steinmetz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-03-31Revert "ALSA: uapi: Drop asound.h inclusion from asoc.h"Takashi Iwai1-0/+1
This reverts commit 645c08f17f477915f6d900b767e789852f150054 which was reported to break the build a program using this header. The original issue was addressed in the alsa-lib side recently, so we can make the header more self-contained again. Reported-by: Dmitry V. Levin <[email protected]> Fixes: 645c08f17f47 ("ALSA: uapi: Drop asound.h inclusion from asoc.h") Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-03-31ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixupsThomas Hebb2-36/+0
patch_realtek.c has historically failed to properly configure the PC Beep Hidden Register for the ALC256 codec (among others). Depending on your kernel version, symptoms of this misconfiguration can range from chassis noise, picked up by a poorly-shielded PCBEEP trace, getting amplified and played on your internal speaker and/or headphones to loud feedback, which responds to the "Headphone Mic Boost" ALSA control, getting played through your headphones. For details of the problem, see the patch in this series titled "ALSA: hda/realtek - Set principled PC Beep configuration for ALC256", which fixes the configuration. These symptoms have been most noticed on the Dell XPS 13 9350 and 9360, popular laptops that use the ALC256. As a result, several model-specific fixups have been introduced to try and fix the problem, the most egregious of which locks the "Headphone Mic Boost" control as a hack to minimize noise from a feedback loop that shouldn't have been there in the first place. Now that the underlying issue has been fixed, remove all these fixups. Remaining fixups needed by the XPS 13 are all picked up by existing pin quirks. This change should, for the XPS 13 9350/9360 - Significantly increase volume and audio quality on headphones - Eliminate headphone popping on suspend/resume - Allow "Headphone Mic Boost" to be set again, making the headphone jack fully usable as a microphone jack too. Fixes: 8c69729b4439 ("ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3") Fixes: 423cd785619a ("ALSA: hda - Fix headphone noise on Dell XPS 13 9360") Fixes: e4c9fd10eb21 ("ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant") Fixes: 1099f48457d0 ("ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360") Cc: [email protected] Signed-off-by: Thomas Hebb <[email protected]> Link: https://lore.kernel.org/r/b649a00edfde150cf6eebbb4390e15e0c2deb39a.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <[email protected]>
2020-03-31ALSA: hda/realtek - Set principled PC Beep configuration for ALC256Thomas Hebb1-6/+9
The Realtek PC Beep Hidden Register[1] is currently set by patch_realtek.c in two different places: In alc_fill_eapd_coef(), it's set to the value 0x5757, corresponding to non-beep input on 1Ah and no 1Ah loopback to either headphones or speakers. (Although, curiously, the loopback amp is still enabled.) This write was added fairly recently by commit e3743f431143 ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") and is a safe default. However, it happens in the wrong place: alc_fill_eapd_coef() runs on module load and cold boot but not on S3 resume, meaning the register loses its value after suspend. Conversely, in alc256_init(), the register is updated to unset bit 13 (disable speaker loopback) and set bit 5 (set non-beep input on 1Ah). Although this write does run on S3 resume, it's not quite enough to fix up the register's default value of 0x3717. What's missing is a set of bit 14 to disable headphone loopback. Without that, we end up with a feedback loop where the headphone jack is being driven by amplified samples of itself[2]. This change eliminates the update in alc256_init() and replaces it with the 0x5757 write from alc_fill_eapd_coef(). Kailang says that 0x5757 is supposed to be the codec's default value, so using it will make debugging easier for Realtek. Affects the ALC255, ALC256, ALC257, ALC235, and ALC236 codecs. [1] Newly documented in Documentation/sound/hd-audio/realtek-pc-beep.rst [2] Setting the "Headphone Mic Boost" control from userspace changes this feedback loop and has been a widely-shared workaround for headphone noise on laptops like the Dell XPS 13 9350. This commit eliminates the feedback loop and makes the workaround unnecessary. Fixes: e1e8c1fdce8b ("ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236") Cc: [email protected] Signed-off-by: Thomas Hebb <[email protected]> Link: https://lore.kernel.org/r/bf22b417d1f2474b12011c2a39ed6cf8b06d3bf5.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <[email protected]>
2020-03-31ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256Thomas Hebb2-0/+130
This codec (among others) has a hidden set of audio routes, apparently designed to allow PC Beep output without a mixer widget on the output path, which are controlled by an undocumented Realtek vendor register. The default configuration of these routes means that certain inputs aren't accessible, necessitating driver control of the register. However, Realtek has provided no documentation of the register, instead opting to fix issues by providing magic numbers, most of which have been at least somewhat erroneous. These magic numbers then get copied by others into model-specific fixups, leading to a fragmented and buggy set of configurations. To get out of this situation, I've reverse engineered the register by flipping bits and observing how the codec's behavior changes. This commit documents my findings. It does not change any code. Cc: [email protected] Signed-off-by: Thomas Hebb <[email protected]> Link: https://lore.kernel.org/r/bd69dfdeaf40ff31c4b7b797c829bb320031739c.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <[email protected]>
2020-03-31PCI: endpoint: Fix clearing start entry in configfsKunihiko Hayashi1-0/+1
After an endpoint is started through configfs, if 0 is written to the configfs entry 'start', the controller stops but the epc_group->start value remains 1. A subsequent unlinking of the function from the controller would trigger a spurious WARN_ON_ONCE() in pci_epc_epf_unlink() despite right behavior. Fix it by setting epc_group->start = 0 when a controller is stopped using configfs. Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring EP functions") Signed-off-by: Kunihiko Hayashi <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]>
2020-03-31PCI: tegra: Add support for PCIe endpoint mode in Tegra194Vidya Sagar3-18/+695
Add support for the endpoint mode of Synopsys DesignWare core based dual mode PCIe controllers present in Tegra194 SoC. Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Thierry Reding <[email protected]>
2020-03-31Merge tag 'drm-msm-next-2020-03-22' of ↵Dave Airlie24-751/+724
https://gitlab.freedesktop.org/drm/msm into drm-next A bit smaller this time around.. there are still a couple uabi additions for vulkan waiting in the wings, but I punted on them this cycle due to running low on time. (They should be easy enough to rebase, and if it is a problem for anyone I can push a next+uabi branch so that tu work can proceed.) The bigger change is refactoring dpu resource manager and moving dpu to use atomic global state. Other than that, it is mostly cleanups and fixes. From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGuf1R4Xz-t9Z7_cwx9jD=b4wUvvwfqA5cHR8fCSXSd5XQ@mail.gmail.com Signed-off-by: Dave Airlie <[email protected]>
2020-03-31Merge v5.6 into drm-nextDave Airlie666-2881/+6433
msm needed rc6, so I just went and merged release (msm has been in drm-next outside of this tree) Signed-off-by: Dave Airlie <[email protected]>
2020-03-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller12-61/+115
2020-03-30netdevsim: dev: Fix memory leak in nsim_dev_take_snapshot_writeGustavo A. R. Silva1-0/+1
In case memory resources for dummy_data were allocated, release them before return. Addresses-Coverity-ID: 1491997 ("Resource leak") Fixes: 7ef19d3b1d5e ("devlink: report error once U32_MAX snapshot ids have been used") Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30Merge branch 'stmmac-Add-additional-EHL-PCI-info-and-PCI-ID'David S. Miller4-313/+602
Voon Weifeng says: ==================== stmmac: Add additional EHL PCI info and PCI ID Thanks Jose Miguel Abreu for the feedback. Summary of v2 patches: 1/3: As suggested to keep the stmmac_pci.c file simple. So created a new file dwmac-intel.c and moved all the Intel specific PCI device out of stmmac_pci.c. 2/3: Added Intel(R) Programmable Services Engine (Intel(R) PSE) MAC PCI ID and PCI info 3/3: Added EHL 2.5Gbps PCI ID and info Changes from v1: -Added a patch to move all Intel specific PCI device from stmmac_pci.c to a new file named dwmac-intel.c. -Combine v1 patch 1/3 and 2/3 into single patch. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: stmmac: add EHL 2.5Gbps PCI info and PCI IDVoon Weifeng1-8/+16
Add EHL SGMII 2.5Gbps PCI info and PCI ID Signed-off-by: Voon Weifeng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: stmmac: add EHL PSE0 & PSE1 1Gbps PCI info and PCI IDVoon Weifeng1-0/+75
Add EHL PSE0/1 RGMII & SGMII 1Gbps PCI info and PCI ID Signed-off-by: Voon Weifeng <[email protected]> Signed-off-by: Ong Boon Leong <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: stmmac: create dwmac-intel.c to contain all Intel platformVoon Weifeng4-313/+519
As stmmac_pci.c file is getting bigger and more complex, it is reasonable to separate all the Intel specific dwmac pci device to a different file. This move includes Intel Quark, TGL and EHL. A new kernel config CONFIG_DWMAC_INTEL is introduced and depends on X86. For this initial patch, all the necessary function such as probe() and exit() are identical besides the function name. Signed-off-by: Voon Weifeng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30Merge branch 'net-dsa-b53-and-bcm_sf2-updates-for-7278'David S. Miller3-42/+136
Florian Fainelli says: ==================== net: dsa: b53 & bcm_sf2 updates for 7278 This patch series contains some updates to the b53 and bcm_sf2 drivers specifically for the 7278 Ethernet switch. The first patch is technically a bug fix so it should ideally be backported to -stable, provided that Dan also agress with my resolution on this. Patches #2 through #4 are minor changes to the core b53 driver to restore VLAN configuration upon system resumption as well as deny specific bridge/VLAN operations on port 7 with the 7278 which is special and does not support VLANs. Patches #5 through #9 add support for matching VLAN TCI keys/masks to the CFP code. Changes in v2: - fixed some code comments and arrange some code for easier reading ==================== Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: bcm_sf2: Support specifying VLAN tag egress ruleFlorian Fainelli1-2/+38
The port to which the ASP is connected on 7278 is not capable of processing VLAN tags as part of the Ethernet frame, so allow an user to configure the egress VLAN policy they want to see applied by purposing the h_ext.data[1] field. Bit 0 is used to indicate that 0=tagged, 1=untagged. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: bcm_sf2: Add support for matching VLAN TCIFlorian Fainelli1-15/+38
Update relevant code paths to support the programming and matching of VLAN TCI, this is the only member of the ethtool_flow_ext that we can match, the switch does not permit matching the VLAN Ethernet Type field. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: bcm_sf2: Move writing of CFP_DATA(5) into slicing functionsFlorian Fainelli1-32/+32
In preparation for matching VLANs, move the writing of CFP_DATA(5) into the IPv4 and IPv6 slicing logic since they are part of the per-flow configuration. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: bcm_sf2: Check earlier for FLOW_EXT and FLOW_MAC_EXTFlorian Fainelli1-2/+3
We do not currently support matching on FLOW_EXT or FLOW_MAC_EXT, but we were not checking for those bits being set in the flow specification. The check for FLOW_EXT and FLOW_MAC_EXT are separated out because a subsequent commit will add support for matching VLAN TCI which are covered by FLOW_EXT. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: bcm_sf2: Disable learning for ASP portFlorian Fainelli1-1/+9
We don't want to enable learning for the ASP port since it only receives directed traffic, this allows us to bypass ARL-driven forwarding rules which could conflict with Broadcom tags and/or CFP forwarding. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: b53: Deny enslaving port 7 for 7278 into a bridgeFlorian Fainelli1-0/+6
On 7278, port 7 connects to the ASP which should only receive frames through the use of CFP rules, it is not desirable to have it be part of a bridge at all since that would make it pick up unwanted traffic that it may not even be able to filter or sustain. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: b53: Prevent tagged VLAN on port 7 for 7278Florian Fainelli1-0/+8
On 7278, port 7 of the switch connects to the ASP UniMAC which is not capable of processing VLAN tagged frames. We can still allow the port to be part of a VLAN entry, and we may want it to be untagged on egress on that VLAN because of that limitation. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: b53: Restore VLAN entries upon (re)configurationFlorian Fainelli1-0/+15
The first time b53_configure_vlan() is called we have not configured any VLAN entries yet, since that happens later when interfaces get brought up. When b53_configure_vlan() is called again from suspend/resume we need to restore all VLAN entries though. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30net: dsa: bcm_sf2: Fix overflow checksFlorian Fainelli1-6/+3
Commit f949a12fd697 ("net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc") tried to fix the some user controlled buffer overflows in bcm_sf2_cfp_rule_set() and bcm_sf2_cfp_rule_del() but the fix was using CFP_NUM_RULES, which while it is correct not to overflow the bitmaps, is not representative of what the device actually supports. Correct that by using bcm_sf2_cfp_rule_size() instead. The latter subtracts the number of rules by 1, so change the checks from greater than or equal to greater than accordingly. Fixes: f949a12fd697 ("net: dsa: bcm_sf2: fix buffer overflow doing set_rxnfc") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-03-30Merge tag 'x86-timers-2020-03-30' of ↵Linus Torvalds1-16/+112
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 timer updates from Thomas Gleixner: "A series of commits to make the MSR derived CPU and TSC frequency more accurate. It turned out that the frequency tables which have been taken from the SDM are inaccurate because the SDM provides truncated and rounded values, e.g. 83.3Mhz (83.3333...) or 116.7Mhz (116.6666...). This causes time drift in the range of ~1 second per hour (20-30 seconds per day). On some of these SoCs it's not possible to recalibrate the TSC because there is no reference (PIT, HPET) available. With some reverse engineering it was established that the possible frequencies are derived from the base clock with fixed multiplier / divider pairs. For the CPU models which have a known crystal frequency the kernel now uses multiplier / divider pairs which bring the frequencies closer to reality and fix the observed time drift issues" * tag 'x86-timers-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tsc_msr: Make MSR derived TSC frequency more accurate x86/tsc_msr: Fix MSR_FSB_FREQ mask for Cherry Trail devices x86/tsc_msr: Use named struct initializers
2020-03-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller107-1728/+6086
Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.