summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-10-08cfg80211: only allow S1G channels on S1G bandThomas Pedersen
As discovered by syzbot, cfg80211 was accepting S1G channel widths on non-S1G bands. Add a check for this, and consolidate the 1MHz frequency check as it ends up being a subset of the others. Reported-by: syzbot+92715a0eccd6c881bc32@syzkaller.appspotmail.com Fixes: 11b34737b18a ("nl80211: support setting S1G channels") Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20201005165122.17583-1-thomas@adapt-ip.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-10-08mac80211: initialize last_rate for S1G STAsThomas Pedersen
last_rate is initialized to zero by sta_info_alloc(), but this indicates legacy bitrate for the last TX rate (and invalid for the last RX rate). To avoid a warning when decoding the last rate as legacy (before a data frame has been sent), initialize them as S1G MCS. Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20201005164522.18069-2-thomas@adapt-ip.com [rename to ieee80211_s1g_sta_rate_init(), seems more appropriate] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-10-08x86/mce: Allow for copy_mc_fragile symbol checksum to be generatedBorislav Petkov
Add asm/mce.h to asm/asm-prototypes.h so that that asm symbol's checksum can be generated in order to support CONFIG_MODVERSIONS with it and fix: WARNING: modpost: EXPORT symbol "copy_mc_fragile" [vmlinux] version \ generation failed, symbol will not be versioned. For reference see: 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm") 334bb7738764 ("x86/kbuild: enable modversions for symbols exported from asm") Fixes: ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()") Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201007111447.GA23257@zn.tnic
2020-10-08mac80211: handle lack of sband->bitrates in ratesThomas Pedersen
Even though a driver or mac80211 shouldn't produce a legacy bitrate if sband->bitrates doesn't exist, don't crash if that is the case either. This fixes a kernel panic if station dump is run before last_rate can be updated with a data frame when sband->bitrates is missing (eg. in S1G bands). Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20201005164522.18069-1-thomas@adapt-ip.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-10-08MIPS: SGI-IP28: disable use of ll/sc in kernelThomas Bogendoerfer
SGI-IP28 systems only use broken R10k rev 2.5 CPUs, which could lock up, if ll/sc sequences are issued in certain order. Since those systems are all non-SMP, we can disable ll/sc usage in kernel. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-10-08MIPS: tx49xx: move tx4939_add_memory_regions into only userThomas Bogendoerfer
tx4939_add_memory_regions() is only used in txx9/rbtx4939/prom.c. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-10-08docs: w1: w1_therm: Fix broken xref, mistakes, clarify textIvan Zaentsev
sysfs attribute names are mixed with the same normal text terms. Use ReST to distinguish. Fix typos and mistakes. Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Ivan Zaentsev <ivan.zaentsev@wirenboard.ru> Link: https://lore.kernel.org/r/20201008054259.5461-1-ivan.zaentsev@wirenboard.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08usb: typec: tcpci_maxim: Add support for Sink FRSBadhri Jagan Sridharan
Upon receiving ALERT_EXTENDED.TCPC_SINK_FAST_ROLE_SWAP signal tcpm to start Sink fast role swap signal. Inform when TCPM is sourcing vbus. Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201008061556.1402293-9-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08usb: typec: tcpci: Implement callbacks for FRSBadhri Jagan Sridharan
Implement tcpc.enable_frs to enable TCPC to receive Fast role swap signal. Additionally set the sink disconnect threshold to 4v to prevent disconnect during Fast Role swap. Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201008061556.1402293-8-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)Badhri Jagan Sridharan
PD 3.0 spec defines a new mechanism for power role swap called Fast role swap. This change enables TCPM to support FRS when acting as sink. Once the explicit contract is negotiated, sink port is expected to query the source port for sink caps to determine whether the source is FRS capable. Bits 23 & 24 of fixed pdo of the sink caps from the source, when set, indicates the current needed by the source when fast role swap is in progress(Implicit contract phasae). 0 indicates that the source does not support Fast Role Swap. Upon receiving the FRS signal from the source, TCPC(TCPM_FRS_EVENT) informs TCPM to start the Fast role swap sequence. 1. TCPM sends FRS PD message: FR_SWAP_SEND 2. If response is not received within the expiry of SenderResponseTimer, Error recovery is triggered.: FR_SWAP_SEND_TIMEOUT 3. Upon receipt of the accept message, TCPM waits for PSSourceOffTimer for PS_READY message from the partner: FR_SWAP_SNK_SRC_NEW_SINK_READY. TCPC is expected to autonomously turn on vbus once the FRS signal is received and vbus voltage falls below vsafe5v within tSrcFrSwap. This is different from traditional power role swap where the vbus sourcing is turned on by TCPM. 4. By this time, TCPC most likely would have started to source vbus, TCPM waits for tSrcFrSwap to see if the lower level TCPC driver signals TCPM_SOURCING_VBUS event: FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED. 5. When TCPC signals sourcing vbus, TCPM sends PS_READY msg and changes the CC pin from Rd to Rp. This is the end of fast role swap sequence and TCPM initiates the sequnce to negotiate explicit contract by transitioning into SRC_STARTUP after SwapSrcStart. The code is written based on the sequence described in "Figure 8-107: Dual-role Port in Sink to Source Fast Role Swap State Diagram" of USB Power Delivery Specification Revision 3.0, Version 1.2. Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201008061556.1402293-7-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08usb: typec: tcpci_maxim: Chip level TCPC driverBadhri Jagan Sridharan
Chip level TCPC driver for Maxim's TCPCI implementation. This TCPC implementation does not support the following commands: COMMAND.SinkVbus, COMMAND.SourceVbusDefaultVoltage, COMMAND.SourceVbusHighVoltage. Instead the sinking and sourcing from vbus is supported by writes to custom registers. Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201008061556.1402293-5-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08usb: typec: tcpci: Add set_vbus tcpci callbackBadhri Jagan Sridharan
set_vbus callback allows TCPC which are TCPCI based, however, does not support turning on sink and source mode through Command.SinkVbus and Command.SourceVbusDefaultVoltage. Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201008061556.1402293-3-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08usb: typec: tcpci: Add a getter method to retrieve tcpm_port referenceBadhri Jagan Sridharan
Allow chip level drivers to retrieve reference to tcpm_port. Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201008061556.1402293-2-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08misc: Kconfig: fix a HISI_HIKEY_USB dependencyMauro Carvalho Chehab
The dependency should be just USB_ROLE_SWITCH, instead of CONFIG_USB_ROLE_SWITCH. Fixes: 2827d98bc5d6 ("misc: Kconfig: add a new dependency for HISI_HIKEY_USB") Reported-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/0b6dff854c4bb412c2c11f17803e84d61385415f.1602138248.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08media: dt-bindings: media: venus: Add an optional power domain for perf votingRajendra Nayak
Venus needs to vote for the performance state of a power domain (cx) to be able to support DVFS. This 'cx' power domain is controlled by rpmh and is a common power domain (scalable) not specific to venus alone. This is optional in the sense that, leaving this power domain out does not really impact the functionality but just makes the platform a little less power efficient. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-08media: rcar-vin: rcar-dma: Fix setting VNIS_REG for RAW8 formatsLad Prabhakar
pixelformat in vin priv structure holds V4L2_PIX_FMT_* and not MEDIA_BUS_FMT_* so make sure we check against V4L2_PIX_FMT_* formats while setting the VNIS_REG. Fixes: 8c3e0f67df6c9 ("media: rcar-vin: Extend RAW8 support to all RGB layouts") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-08media: staging: rkisp1: uapi: Do not use BIT() macroNiklas Söderlund
The BIT() macro is not available to uAPI headers, replace the few usages of it by open coding it. Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Acked-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-08media: v4l2-mem2mem: Fix spurious v4l2_m2m_buf_doneEzequiel Garcia
A seemingly bad rebase introduced a spurious v4l2_m2m_buf_done, which releases a buffer twice and therefore triggers a noisy warning on each job: WARNING: CPU: 0 PID: 0 at drivers/media/common/videobuf2/videobuf2-core.c:986 vb2_buffer_done+0x208/0x2a0 Fix it by removing the spurious v4l2_m2m_buf_done. Reported-by: Adrian Ratiu <adrian.ratiu@collabora.com> Fixes: 911ea8ec42dea ("media: v4l2-mem2mem: add v4l2_m2m_suspend, v4l2_m2m_resume") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Tested-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-08media: usbtv: Fix refcounting mixupOliver Neukum
The premature free in the error path is blocked by V4L refcounting, not USB refcounting. Thanks to Ben Hutchings for review. [v2] corrected attributions Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: 50e704453553 ("media: usbtv: prevent double free in error case") CC: stable@vger.kernel.org Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-08X.509: Fix modular build of public_key_sm2Herbert Xu
The sm2 code was split out of public_key.c in a way that breaks modular builds. This patch moves the code back into the same file as the original motivation was to minimise ifdefs and that has nothing to do with splitting the code out. Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3...") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-10-08crypto: xor - Remove unused variable count in do_xor_speedNathan Chancellor
Clang warns: crypto/xor.c:101:4: warning: variable 'count' is uninitialized when used here [-Wuninitialized] count++; ^~~~~ crypto/xor.c:86:17: note: initialize the variable 'count' to silence this warning int i, j, count; ^ = 0 1 warning generated. After the refactoring to use ktime that happened in this function, count is only assigned, never read. Just remove the variable to get rid of the warning. Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking") Link: https://github.com/ClangBuiltLinux/linux/issues/1171 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-10-08X.509: fix error return value on the failed pathTianjia Zhang
When memory allocation fails, an appropriate return value should be set. Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification") Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-10-08crypto: bcm - Verify GCM/CCM key length in setkeyHerbert Xu
The setkey function for GCM/CCM algorithms didn't verify the key length before copying the key and subtracting the salt length. This patch delays the copying of the key til after the verification has been done. It also adds checks on the key length to ensure that it's at least as long as the salt. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Cc: <stable@vger.kernel.org> Reported-by: kiyin(尹亮) <kiyin@tencent.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-10-08crypto: qat - drop input parameter from adf_enable_aer()Giovanni Cabiddu
Remove pointer to struct pci_driver from function adf_enable_aer() as it is possible to get it directly from pdev->driver. Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Fiona Trahe <fiona.trahe@intel.com> Reviewed-by: Wojciech Ziemba <wojciech.ziemba@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-10-08crypto: qat - fix function parameters descriptionsGiovanni Cabiddu
Fix description of function parameters. This is to fix the following warnings when compiling the driver with W=1: drivers/crypto/qat/qat_common/adf_sriov.c:133: warning: Function parameter or member 'numvfs' not described in 'adf_sriov_configure' drivers/crypto/qat/qat_common/adf_dev_mgr.c:296: warning: Function parameter or member 'pci_dev' not described in 'adf_devmgr_pci_to_accel_dev' drivers/crypto/qat/qat_common/adf_dev_mgr.c:296: warning: Excess function parameter 'accel_dev' description in 'adf_devmgr_pci_to_accel_dev' Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Fiona Trahe <fiona.trahe@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-10-07Merge branch 'libbpf: auto-resize relocatable LOAD/STORE instructions'Alexei Starovoitov
Andrii Nakryiko says: ==================== Patch set implements logic in libbpf to auto-adjust memory size (1-, 2-, 4-, 8-bytes) of load/store (LD/ST/STX) instructions which have BPF CO-RE field offset relocation associated with it. In practice this means transparent handling of 32-bit kernels, both pointer and unsigned integers. Signed integers are not relocatable with zero-extending loads/stores, so libbpf poisons them and generates a warning. If/when BPF gets support for sign-extending loads/stores, it would be possible to automatically relocate them as well. All the details are contained in patch #2 comments and commit message. Patch #3 is a simple change in libbpf to make advanced testing with custom BTF easier. Patch #4 validates correct uses of auto-resizable loads, as well as check that libbpf fails invalid uses. Patch #1 skips CO-RE relocation for programs that had bpf_program__set_autoload(prog, false) set on them, reducing warnings and noise. v2->v3: - fix copyright (Alexei); v1->v2: - more consistent names for instruction mem size convertion routines (Alexei); - extended selftests to use relocatable STX instructions (Alexei); - added a fix for skipping CO-RE relocation for non-loadable programs. Cc: Luka Perkov <luka.perkov@sartura.hr> Cc: Tony Ambardar <tony.ambardar@gmail.com> ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-10-08powerpc/papr_scm: Add PAPR command family to pass-through command-setVaibhav Jain
Add NVDIMM_FAMILY_PAPR to the list of valid 'dimm_family_mask' acceptable by papr_scm. This is needed as since commit 92fe2aa859f5 ("libnvdimm: Validate command family indices") libnvdimm performs a validation of 'nd_cmd_pkg.nd_family' received as part of ND_CMD_CALL processing to ensure only known command families can use the general ND_CMD_CALL pass-through functionality. Without this change the ND_CMD_CALL pass-through targeting NVDIMM_FAMILY_PAPR error out with -EINVAL. Fixes: 92fe2aa859f5 ("libnvdimm: Validate command family indices") Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200913211904.24472-1-vaibhav@linux.ibm.com
2020-10-08powerpc/lmb-size: Use addr #size-cells value when fetching lmb-sizeAneesh Kumar K.V
Make it consistent with other usages. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201007114836.282468-5-aneesh.kumar@linux.ibm.com
2020-10-08powerpc/book3s64/radix: Make radix_mem_block_size 64bitAneesh Kumar K.V
Similar to commit 89c140bbaeee ("pseries: Fix 64 bit logical memory block panic") make sure different variables tracking lmb_size are updated to be 64 bit. Fixes: af9d00e93a4f ("powerpc/mm/radix: Create separate mappings for hot-plugged memory") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201007114836.282468-4-aneesh.kumar@linux.ibm.com
2020-10-08powerpc/memhotplug: Make lmb size 64bitAneesh Kumar K.V
Similar to commit 89c140bbaeee ("pseries: Fix 64 bit logical memory block panic") make sure different variables tracking lmb_size are updated to be 64 bit. This was found by code audit. Cc: stable@vger.kernel.org Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201007114836.282468-3-aneesh.kumar@linux.ibm.com
2020-10-08powerpc/drmem: Make lmb_size 64 bitAneesh Kumar K.V
Similar to commit 89c140bbaeee ("pseries: Fix 64 bit logical memory block panic") make sure different variables tracking lmb_size are updated to be 64 bit. This was found by code audit. Cc: stable@vger.kernel.org Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Acked-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201007114836.282468-2-aneesh.kumar@linux.ibm.com
2020-10-08powerpc/security: Fix link stack flush instructionNicholas Piggin
The inline execution path for the hardware assisted branch flush instruction failed to set CTR to the correct value before bcctr, causing a crash when the feature is enabled. Fixes: 4d24e21cc694 ("powerpc/security: Allow for processors that flush the link stack using the special bcctr") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201007080605.64423-1-npiggin@gmail.com
2020-10-07selftests/bpf: Validate libbpf's auto-sizing of LD/ST/STX instructionsAndrii Nakryiko
Add selftests validating libbpf's auto-resizing of load/store instructions when used with CO-RE relocations. An explicit and manual approach with using bpf_core_read() is also demonstrated and tested. Separate BPF program is supposed to fail due to using signed integers of sizes that differ from kernel's sizes. To reliably simulate 32-bit BTF (i.e., the one with sizeof(long) == sizeof(void *) == 4), selftest generates its own custom BTF and passes it as a replacement for real kernel BTF. This allows to test 32/64-bitness mix on all architectures. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20201008001025.292064-5-andrii@kernel.org
2020-10-07libbpf: Allow specifying both ELF and raw BTF for CO-RE BTF overrideAndrii Nakryiko
Use generalized BTF parsing logic, making it possible to parse BTF both from ELF file, as well as a raw BTF dump. This makes it easier to write custom tests with manually generated BTFs. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20201008001025.292064-4-andrii@kernel.org
2020-10-07libbpf: Support safe subset of load/store instruction resizing with CO-REAndrii Nakryiko
Add support for patching instructions of the following form: - rX = *(T *)(rY + <off>); - *(T *)(rX + <off>) = rY; - *(T *)(rX + <off>) = <imm>, where T is one of {u8, u16, u32, u64}. For such instructions, if the actual kernel field recorded in CO-RE relocation has a different size than the one recorded locally (e.g., from vmlinux.h), then libbpf will adjust T to an appropriate 1-, 2-, 4-, or 8-byte loads. In general, such transformation is not always correct and could lead to invalid final value being loaded or stored. But two classes of cases are always safe: - if both local and target (kernel) types are unsigned integers, but of different sizes, then it's OK to adjust load/store instruction according to the necessary memory size. Zero-extending nature of such instructions and unsignedness make sure that the final value is always correct; - pointer size mismatch between BPF target architecture (which is always 64-bit) and 32-bit host kernel architecture can be similarly resolved automatically, because pointer is essentially an unsigned integer. Loading 32-bit pointer into 64-bit BPF register with zero extension will leave correct pointer in the register. Both cases are necessary to support CO-RE on 32-bit kernels, as `unsigned long` in vmlinux.h generated from 32-bit kernel is 32-bit, but when compiled with BPF program for BPF target it will be treated by compiler as 64-bit integer. Similarly, pointers in vmlinux.h are 32-bit for kernel, but treated as 64-bit values by compiler for BPF target. Both problems are now resolved by libbpf for direct memory reads. But similar transformations are useful in general when kernel fields are "resized" from, e.g., unsigned int to unsigned long (or vice versa). Now, similar transformations for signed integers are not safe to perform as they will result in incorrect sign extension of the value. If such situation is detected, libbpf will emit helpful message and will poison the instruction. Not failing immediately means that it's possible to guard the instruction based on kernel version (or other conditions) and make sure it's not reachable. If there is a need to read signed integers that change sizes between different kernels, it's possible to use BPF_CORE_READ_BITFIELD() macro, which works both with bitfields and non-bitfield integers of any signedness and handles sign-extension properly. Also, bpf_core_read() with proper size and/or use of bpf_core_field_size() relocation could allow to deal with such complicated situations explicitly, if not so conventiently as direct memory reads. Selftests added in a separate patch in progs/test_core_autosize.c demonstrate both direct memory and probed use cases. BPF_CORE_READ() is not changed and it won't deal with such situations as automatically as direct memory reads due to the signedness integer limitations, which are much harder to detect and control with compiler macro magic. So it's encouraged to utilize direct memory reads as much as possible. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20201008001025.292064-3-andrii@kernel.org
2020-10-07libbpf: Skip CO-RE relocations for not loaded BPF programsAndrii Nakryiko
Bypass CO-RE relocations step for BPF programs that are not going to be loaded. This allows to have BPF programs compiled in and disabled dynamically if kernel is not supposed to provide enough relocation information. In such case, there won't be unnecessary warnings about failed relocations. Fixes: d929758101fc ("libbpf: Support disabling auto-loading BPF programs") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20201008001025.292064-2-andrii@kernel.org
2020-10-07dm: fix request-based DM to not bounce through indirect dm_submit_bioMike Snitzer
It is unnecessary to force request-based DM to call into bio-based dm_submit_bio (via indirect disk->fops->submit_bio) only to have it then call blk_mq_submit_bio(). Fix this by establishing a request-based DM block_device_operations (dm_rq_blk_dops, which doesn't have .submit_bio) and update dm_setup_md_queue() to set md->disk->fops to it for DM_TYPE_REQUEST_BASED. Remove DM_TYPE_REQUEST_BASED conditional in dm_submit_bio and unexport blk_mq_submit_bio. Fixes: c62b37d96b6eb ("block: move ->make_request_fn to struct block_device_operations") Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-10-07dm: remove special-casing of bio-based immutable singleton target on NVMeMike Snitzer
Since commit 5a6c35f9af416 ("block: remove direct_make_request") there is no benefit to DM special-casing NVMe. Remove all code used to establish DM_TYPE_NVME_BIO_BASED. Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2020-10-07platform/x86: mlx-platform: Add capability field to platform FAN descriptionVadim Pasternak
Set 'capability' field to FAN core platform data.. The content of 'capability' register allows to set the mapping between the drawers and tachometers. The motivation is to avoid adding a new code in the future in order to distinct between the systems types supporting a different kinds of the FAN drawers. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200923172053.26296-6-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-10-07platform_data/mlxreg: Extend core platform structureVadim Pasternak
Add 'capability' field to structure 'mlxreg_core_platform_data'. The purpose of this filed to indicate the actual number of the components within the particular group. Such components could be, for example the number of the FAN drawers. Some systems are equipped with FAN drawers with one tachometer inside, others with FAN drawers with several tachometers inside. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200923172053.26296-5-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-10-07platform_data/mlxreg: Update module licenseVadim Pasternak
Update license to SPDX-License. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200923172053.26296-4-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-10-07platform/x86: mlx-platform: Remove PSU EEPROM configurationVadim Pasternak
Remove PSU EEPROM configuration for systems class equipped with Mellanox chip Spectrume-2. Till now all the systems from this class used few types of power units, all equipped with EEPROM device with address space two bytes. Thus, all these devices have been handled by EEPROM driver "24c32". There is a new requirement is to support power unit replacement by "off the shelf" device, matching electrical required parameters. Such device could be equipped with different EEPROM type, which could be one byte address space addressing or even could be not equipped with EEPROM. In such case "24c32" will not work. Fixes: 1bd42d94ccab ("platform/x86: mlx-platform: Add support for new 200G IB and Ethernet systems") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200923172053.26296-2-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-10-07can: xilinx_can: Fix incorrect variable and initialize with a default valueSrinivas Neeli
Some variables with incorrect type were passed to "of_property_read_u32" API, "of_property_read_u32" API was expecting an "u32 *" but the formal parameter that was passed was of type "int *". Fixed the issue by changing the variable types from "int" to "u32" and initialized with a default value. Fixed sparse warning. Addresses-Coverity: "incompatible_param" Addresses-Coverity: "UNINIT(Using uninitialized value)" Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/0651544d22f3c25893ca9d445b14823f0dfddfc8.1600073396.git.michal.simek@xilinx.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07can: xilinx_can: Check return value of set_reset_modeSrinivas Neeli
Check return value of set_reset_mode() for error. Addresses-Coverity: "check_return" Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/bac2c2b857986472a11db341b3f6f7a8905ad0dd.1600073396.git.michal.simek@xilinx.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07can: xilinx_can: Limit CANFD brp to 2Srinivas Neeli
Bit enlarging is observed for CANFD2.0 when brp is 1, So change brp_min value to 2. Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/bca871d7f3ca9c653d50e63c5b60028f2bdf3fb0.1600073396.git.michal.simek@xilinx.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07can: flexcan: remove ack_grp and ack_bit handling from driverMarc Kleine-Budde
Since commit: 048e3a34a2e7 can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment the driver polls the IP core's internal bit MCR[LPM_ACK] as stop mode acknowledge and not the acknowledgment on chip level. This means the 4th and 5th value of the property "fsl,stop-mode" isn't used anymore. This patch removes the used "ack_gpr" and "ack_bit" from the driver. Link: http://lore.kernel.org/r/20201006203748.1750156-15-mkl@pengutronix.de Fixes: 048e3a34a2e7 ("can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment") Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07dt-bindings: can: flexcan: remove ack_grp and ack_bit from fsl,stop-modeMarc Kleine-Budde
Since commit: 048e3a34a2e7 can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment the driver polls the IP core's internal bit MCR[LPM_ACK] as stop mode acknowledge and not the acknowledgment on chip level. This means the 4th and 5th value of the property "fsl,stop-mode" isn't used anymore. It will be removed from the driver in the next patch, so remove it from the binding documentation. Link: http://lore.kernel.org/r/20201006203748.1750156-14-mkl@pengutronix.de Fixes: 048e3a34a2e7 ("can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment") Cc: devicetree <devicetree@vger.kernel.org> Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07dt-bindings: can: flexcan: list supported processorsMichael Walle
The compatible is a pattern match. Explicitly list all possible values. Also mention that the ls1028ar1 must be followed by lx2160ar1. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20201001091131.30514-2-michael@walle.cc Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07dt-bindings: can: rcar_can: Document r8a774e1 supportLad Prabhakar
Document SoC specific bindings for RZ/G2H (R8A774E1) SoC. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201005081319.29322-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-10-07dt-bindings: can: rcar_canfd: Document r8a774e1 supportLad Prabhakar
Document the support for rcar_canfd on R8A774E1 SoC devices. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201005081319.29322-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit (git 2.34.1) at 2025-09-15 13:38:11 +0000