aboutsummaryrefslogtreecommitdiff
path: root/include/linux
AgeCommit message (Collapse)AuthorFilesLines
2020-12-14SUNRPC: Fixes for xdr_align_data()Trond Myklebust1-1/+1
The main use case right now for xdr_align_data() is to shift the page data to the left, and in practice shrink the total XDR data buffer. This patch ensures that we fix up the accounting for the buffer length as we shift that data around. Signed-off-by: Trond Myklebust <[email protected]>
2020-12-14Merge branches 'edac-spr', 'edac-igen6' and 'edac-misc' into ↵Borislav Petkov1-2/+14
edac-updates-for-v5.11 Signed-off-by: Borislav Petkov <[email protected]>
2020-12-13ntp: Fix prototype in the !CONFIG_GENERIC_CMOS_UPDATE caseIngo Molnar1-0/+2
In the !CONFIG_GENERIC_CMOS_UPDATE case the update_persistent_clock64() function gets defined as a stub in ntp.c - make the prototype in <linux/timekeeping.h> conditional on CONFIG_GENERIC_CMOS_UPDATE as well. Fixes: 76e87d96b30b5 ("ntp: Consolidate the RTC update implementation") Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Thomas Gleixner <[email protected]>
2020-12-12Merge branch 'master' of ↵Jakub Kicinski1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2020-12-12 Just one patch this time: 1) Redact the SA keys with kernel lockdown confidentiality. If enabled, no secret keys are sent to uuserspace. From Antony Antony. * 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next: xfrm: redact SA secret with lockdown confidentiality ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-12-12Merge tag 'mac80211-next-for-net-next-2020-12-11' of ↵Jakub Kicinski2-5/+28
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== A new set of wireless changes: * validate key indices for key deletion * more preamble support in mac80211 * various 6 GHz scan fixes/improvements * a common SAR power limitations API * various small fixes & code improvements * tag 'mac80211-next-for-net-next-2020-12-11' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (35 commits) mac80211: add ieee80211_set_sar_specs nl80211: add common API to configure SAR power limitations mac80211: fix a mistake check for rx_stats update mac80211: mlme: save ssid info to ieee80211_bss_conf while assoc mac80211: Update rate control on channel change mac80211: don't filter out beacons once we start CSA mac80211: Fix calculation of minimal channel width mac80211: ignore country element TX power on 6 GHz mac80211: use bitfield helpers for BA session action frames mac80211: support Rx timestamp calculation for all preamble types mac80211: don't set set TDLS STA bandwidth wider than possible mac80211: support driver-based disconnect with reconnect hint cfg80211: support immediate reconnect request hint mac80211: use struct assignment for he_obss_pd cfg80211: remove struct ieee80211_he_bss_color nl80211: validate key indexes for cfg80211_registered_device cfg80211: include block-tx flag in channel switch started event mac80211: disallow band-switch during CSA ieee80211: update reduced neighbor report TBTT info length cfg80211: Save the regulatory domain when setting custom regulatory ... ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2020-12-12kernel: remove checking for TIF_NOTIFY_SIGNALJens Axboe3-10/+0
It's available everywhere now, no need to check or add dummy defines. Signed-off-by: Jens Axboe <[email protected]>
2020-12-12signal: kill JOBCTL_TASK_WORKJens Axboe1-3/+1
It's no longer used, get rid of it. Signed-off-by: Jens Axboe <[email protected]>
2020-12-12ACPI: Use fwnode_init() to set up fwnodeSaravana Kannan1-1/+1
Commit 01bb86b380a3 ("driver core: Add fwnode_init()") was supposed to fix up all instances of fwnode creation to use fwnode_init(). But looks like this instance was missed. This causes a NULL pointer dereference during device_add() [1]. So, fix it. [ 60.792324][ T1] Call trace: [ 60.795495][ T1] device_add+0xf60/0x16b0 __fw_devlink_link_to_consumers at drivers/base/core.c:1583 (inlined by) fw_devlink_link_device at drivers/base/core.c:1726 (inlined by) device_add at drivers/base/core.c:3088 [ 60.799813][ T1] platform_device_add+0x274/0x628 [ 60.804833][ T1] acpi_iort_init+0x9d8/0xc50 [ 60.809415][ T1] acpi_init+0x45c/0x4e8 [ 60.813556][ T1] do_one_initcall+0x170/0xb70 [ 60.818224][ T1] kernel_init_freeable+0x6a8/0x734 [ 60.823332][ T1] kernel_init+0x18/0x12c [ 60.827566][ T1] ret_from_fork+0x10/0x1c [ 60.838756][ T1] ---[ end trace fa5c8ce17a226d83 ]--- [1] - https://lore.kernel.org/linux-arm-kernel/[email protected]/ Fixes: 01bb86b380a3 ("driver core: Add fwnode_init()") Reported-by: Qian Cai <[email protected]> Suggested-by: Robin Murphy <[email protected]> Tested-by: Marc Zyngier <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Saravana Kannan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski10-12/+61
xdp_return_frame_bulk() needs to pass a xdp_buff to __xdp_return(). strlcpy got converted to strscpy but here it makes no functional difference, so just keep the right code. Conflicts: net/netfilter/nf_tables_api.c Signed-off-by: Jakub Kicinski <[email protected]>
2020-12-11elfcore: fix building with clangArnd Bergmann1-0/+22
kernel/elfcore.c only contains weak symbols, which triggers a bug with clang in combination with recordmcount: Cannot find symbol for section 2: .text. kernel/elfcore.o: failed Move the empty stubs into linux/elfcore.h as inline functions. As only two architectures use these, just use the architecture specific Kconfig symbols to key off the declaration. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Barret Rhoden <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-11kbuild: avoid static_assert for genksymsArnd Bergmann1-0/+5
genksyms does not know or care about the _Static_assert() built-in, and sometimes falls back to ignoring the later symbols, which causes undefined behavior such as WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned. ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation Redefine static_assert for genksyms to avoid that. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Suggested-by: Ard Biesheuvel <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Michal Marek <[email protected]> Cc: Kees Cook <[email protected]> Cc: Rikard Falkeborn <[email protected]> Cc: Marco Elver <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-11x86,swiotlb: Adjust SWIOTLB bounce buffer size for SEV guestsAshish Kalra1-0/+8
For SEV, all DMA to and from guest has to use shared (un-encrypted) pages. SEV uses SWIOTLB to make this happen without requiring changes to device drivers. However, depending on the workload being run, the default 64MB of it might not be enough and it may run out of buffers to use for DMA, resulting in I/O errors and/or performance degradation for high I/O workloads. Adjust the default size of SWIOTLB for SEV guests using a percentage of the total memory available to guest for the SWIOTLB buffers. Adds a new sev_setup_arch() function which is invoked from setup_arch() and it calls into a new swiotlb generic code function swiotlb_adjust_size() to do the SWIOTLB buffer adjustment. v5 fixed build errors and warnings as Reported-by: kbuild test robot <[email protected]> Signed-off-by: Ashish Kalra <[email protected]> Co-developed-by: Borislav Petkov <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
2020-12-11Merge back cpufreq material for v5.11.Rafael J. Wysocki1-5/+0
2020-12-11Merge tag 'devfreq-next-for-5.11' of ↵Rafael J. Wysocki1-4/+0
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Pull devfreq updates for 5.11 from Chanwoo Choi: 1. Update devfreq core - Add new devfreq_frequency tracepoint to show the frequency change information. - Add governor feature flag. The devfreq governor is able to set the specific flag in order to support a non-common feature. For example, if the governor supports the 'immutable' feature, don't allow user space to change the governor via sysfs. - Add governor sysfs attribute flag for each sysfs file. Prior to that the devfreq subsystem allowed all of the sysfs files to be accessed regardless of the governor type. But some sysfs fils are not supported by specific devfreq governors. In order to only allow the sysfs files supported by the governor to be accessed, clarify the access permissions of sysfs attributes according to the governor. When adding the devfreq governor, specify the available attribute information by using DEVFREQ_GOV_ATTR_* symbols. The user can read or write the sysfs attributes in accordance to the specified access permissions. - Clean-up the code to reduce duplication for the devfreq tracepoint and to remove redundant governor_name field from struct devfreq. 2. Update exynos-bus.c devfreq driver - Add interconnect API support to the Samsung Exynos Bus Frequency driver, exynos-bus.c. Complementing the devfreq driver with interconnect functionality allows to ensure that the QoS requirements regarding devices accessing the system memory (e.g. video processing devices) will be met and allows to avoid issues like DMA underrun. 3. Update tegra devfreq driver - Add interconnect support and OPP interface to tegra30-devfreq.c. Also, it is to guarantee the QoS requirement of some devices like the display controller. - Move tegra20-devfreq.c from drivers/devfreq/ into drivers/memory/tegra/ in order to use the more proper monitoring feature such as EMC_STAT which is located in drivers/memory/tegra/. - Separate the configuration information for different SoCs in tegra30-devfrqe.c. The tegra30-devfreq.c had been supporting both tegra30-actmon and tegra124-actmon devices. In order to use the more correct configuration data, separate them. - Use dev_err_probe() to handle the deferred probe error in tegra30-devfreq.c. 4. Pull the request of 'Tegra SoC and clock controller changes for v5.11' sent by Krzysztof Kozlowski <[email protected]> in order to avoid a build error." * tag 'devfreq-next-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: PM / devfreq: tegra30: Separate configurations per-SoC generation PM / devfreq: tegra30: Support interconnect and OPPs from device-tree PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver PM / devfreq: exynos-bus: Add registration of interconnect child device dt-bindings: devfreq: Add documentation for the interconnect properties soc/tegra: fuse: Add stub for tegra_sku_info soc/tegra: fuse: Export tegra_read_ram_code() clk: tegra: Export Tegra20 EMC kernel symbols PM / devfreq: tegra30: Silence deferred probe error PM / devfreq: tegra20: Relax Kconfig dependency PM / devfreq: tegra20: Silence deferred probe error PM / devfreq: Remove redundant governor_name from struct devfreq PM / devfreq: Add governor attribute flag for specifc sysfs nodes PM / devfreq: Add governor feature flag PM / devfreq: Add tracepoint for frequency changes PM / devfreq: Unify frequency change to devfreq_update_target func trace: events: devfreq: Use fixed indentation size to improve readability
2020-12-11dma-buf: Fix kerneldoc formattingDaniel Vetter1-1/+1
I wanted to look up something and noticed the hyperlink doesn't work. While fixing that also noticed a trivial kerneldoc comment typo in the same section, fix that too. Reviewed-by: Michael J. Ruhl <[email protected]> Reviewed-by: Simon Ser <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-11dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMAVignesh Raghavendra1-0/+8
This commit adds support for PKTDMA in k3-udma glue driver. Use new psil_endpoint_config struct to get static data for a given channel or a flow during setup. Make sure that the RX flows being mapped to a RX channel is within the range of flows that is been allocated to that RX channel. Signed-off-by: Vignesh Raghavendra <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-11soc: ti: k3-ringacc: add AM64 DMA rings support.Grygorii Strashko1-0/+17
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a separate and generic ringacc is used. The ring SW interface is similar to ringacc with some major architectural differences, like They are part of the DMA (BCDMA or PKTDMA). They are dual mode rings are modeled as pair of Rings objects which has common configuration and memory buffer, but separate real-time control register sets for each direction mem2dev (forward) and dev2mem (reverse). The ringacc driver must be initialized for DMA rings use with k3_ringacc_dmarings_init() as it is not an independent device as ringacc is. AM64 rings must be requested only using k3_ringacc_request_rings_pair(), and forward ring must always be initialized/configured. After this any other Ringacc APIs can be used without any callers changes. Signed-off-by: Grygorii Strashko <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-11dmaengine: ti: Add support for k3 event routersPeter Ujfalusi1-0/+16
In k3 architecture a DMA channel (in TR momde) can be triggered by global events, origination from different modules. The events for triggers can be sent from any module which is connected to PSI-L fabric, but the event number to be sent is DMA channel specific, it is only known after the channel itself is requested. The router operation needs to be split up: - route_allocate: configure the dma_spec for the DMA and store the configuration which is needed for the router's input - set_event: callback used by the DMA driver to set the event number for the channel and enable the routing Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-11dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMAPeter Ujfalusi1-0/+16
Additional fields needed for K3 PKTDMA to be able to handle the mapped channels (channels are locked to handle specific threads) and flow ranges for these mapped threads. PKTDMA also introduces tflow for tx channels which can not be found in K3 UDMA architecture. Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-11dmaengine: Add support for per channel coherency handlingPeter Ujfalusi1-0/+12
If the DMA device supports per channel coherency configuration (a channel can be configured to have coherent or not coherent view) then a single device (the DMA controller's device) can not be used for dma_api for all channels as channels can have different coherency. Introduce custom_dma_mapping flag for the dma_chan and a new helper to get the device pointer to be used for dma_api for the given channel. Client drivers should be updated to be able to support per channel coherency by: - dma_map_single(chan->device->dev, ptr, size, DMA_TO_DEVICE); + struct device *dma_dev = dmaengine_get_dma_device(chan); + + dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE); Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-11dmaengine: of-dma: Add support for optional router configuration callbackPeter Ujfalusi1-0/+2
Additional configuration for the DMA event router might be needed for a channel which can not be done during device_alloc_chan_resources callback since the router information is not yet present for the drivers. If there is a need for additional configuration for the channel if DMA router is in use, then the driver can implement the device_router_config callback. Signed-off-by: Peter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-11dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA APIPeter Ujfalusi1-0/+4
Glue layer users should use the device of the DMA for DMA mapping and allocations as it is the DMA which accesses to descriptors and buffers, not the clients Signed-off-by: Peter Ujfalusi <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-12-11Merge tag 'tags/drivers_soc_for_5.11' into dmaengine/nextVinod Koul2-29/+61
drivers: soc: TI SOC changes for 5.11 - ti_sci changes towards DMSS support - Static warning fixes - Kconfig update for Keystone ARM64 socs - AM64X SOC family support
2020-12-11Merge tag 'usb-serial-5.11-rc1' of ↵Greg Kroah-Hartman1-2/+0
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for 5.11-rc1 Here are the USB-serial updates for 5.11-rc1, including: - keyspan_pda write-implementation fixes - digi_acceleport write-wakeup fix - mos7720 parport-restore fix - mos7720 parport-tasklet removal - cp210x termios-handling cleanups - option device-flag fix - ftdi_sio GPIO CBUS-configuration improvements - removal of in_interrupt() uses Included are also various clean ups. All have been in linux-next with no reported issues. * tag 'usb-serial-5.11-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: (30 commits) USB: serial: ftdi_sio: log the CBUS GPIO validity USB: serial: ftdi_sio: drop GPIO line checking dead code USB: serial: ftdi_sio: report the valid GPIO lines to gpiolib USB: serial: option: add interface-number sanity check to flag handling USB: serial: cp210x: clean up dtr_rts() USB: serial: cp210x: refactor flow-control handling USB: serial: cp210x: drop flow-control debugging USB: serial: cp210x: set terminal settings on open USB: serial: cp210x: clean up line-control handling USB: serial: cp210x: return early on unchanged termios USB: serial: mos7720: defer state restore to a workqueue USB: serial: mos7720: fix parallel-port state restore USB: serial: remove write wait queue USB: serial: digi_acceleport: fix write-wakeup deadlocks USB: serial: keyspan_pda: drop redundant usb-serial pointer USB: serial: keyspan_pda: use BIT() macro USB: serial: keyspan_pda: clean up comments and whitespace USB: serial: keyspan_pda: clean up xircom/entrega support USB: serial: keyspan_pda: add write-fifo support USB: serial: keyspan_pda: increase transmitter threshold ...
2020-12-11driver core: platform: Add devm_platform_get_irqs_affinity()John Garry1-0/+6
Drivers for multi-queue platform devices may also want managed interrupts for handling HW queue completion interrupts, so add support. The function accepts an affinity descriptor pointer, which covers all IRQs expected for the device. The function is devm class as the only current in-tree user will also use devm method for requesting the interrupts; as such, the function is made as devm as it can ensure ordering of freeing the irq and disposing of the mapping. Signed-off-by: John Garry <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Acked-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11resource: Add irqresource_disabled()John Garry1-0/+7
Add a common function to set the fields for a irq resource to disabled, which mimics what is done in acpi_dev_irqresource_disabled(), with a view to replace that function. Signed-off-by: John Garry <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11genirq/affinity: Add irq_update_affinity_desc()John Garry1-0/+8
Add a function to allow the affinity of an interrupt be switched to managed, such that interrupts allocated for platform devices may be managed. This new interface has certain limitations, and attempts to use it in the following circumstances will fail: - For when the kernel is configured for generic IRQ reservation mode (in config GENERIC_IRQ_RESERVATION_MODE). The reason being that it could conflict with managed vs. non-managed interrupt accounting. - The interrupt is already started, which should not be the case during init - The interrupt is already configured as managed, which means double init Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: John Garry <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11Revert "genirq: Add fasteoi IPI flow"Valentin Schneider1-1/+0
handle_percpu_devid_fasteoi_ipi() has no more users, and handle_percpu_devid_irq() can do all that it was supposed to do. Get rid of it. This reverts commit c5e5ec033c4ab25c53f1fd217849e75deb0bf7bf. Signed-off-by: Valentin Schneider <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11regulator: pfuze100: Convert the driver to DT-onlyFabio Estevam1-6/+0
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code by removing the unused non-DT support. Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-12-11thermal/core: Add critical and hot opsDaniel Lezcano1-0/+3
Currently there is no way to the sensors to directly call an ops in interrupt mode without calling thermal_zone_device_update assuming all the trip points are defined. A sensor may want to do something special if a trip point is hot or critical. This patch adds the critical and hot ops to the thermal zone device, so a sensor can directly invoke them or let the thermal framework to call the sensor specific ones. Tested-by: Kai-Heng Feng <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Reviewed-by: Lukasz Luba <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11thermal: devfreq_cooling: remove old power model and use EMLukasz Luba1-17/+0
Remove old power model and use new Energy Model to calculate the power budget. It drops static + dynamic power calculations and power table in order to use Energy Model performance domain data. This model should be easy to use and could find more users. It is also less complicated to setup the needed structures. Reviewed-by: Ionela Voinescu <[email protected]> Signed-off-by: Lukasz Luba <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11thermal: devfreq_cooling: add new registration functions with Energy ModelLukasz Luba1-0/+10
The Energy Model (EM) framework supports devices such as Devfreq. Create new registration function which automatically register EM for the thermal devfreq_cooling devices. This patch prepares the code for coming changes which are going to replace old power model with the new EM. Reviewed-by: Ionela Voinescu <[email protected]> Signed-off-by: Lukasz Luba <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11ieee80211: update reduced neighbor report TBTT info lengthAvraham Stern1-4/+4
A new field (20MHz PSD - 1 byte) was added to the RNR TBTT info field. Adjust the expected TBTT info length accordingly. Signed-off-by: Avraham Stern <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.b503adccce6a.Ie684e1d3039c111bf2d521bf762aaec3f7a24d2e@changeid Signed-off-by: Johannes Berg <[email protected]>
2020-12-11cfg80211: Parse SAE H2E only membership selectorIlan Peer1-0/+1
This extends the support for drivers that rebuild IEs in the FW (same as with HT/VHT/HE). Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.4012647275f3.I1a93ae71c57ef0b6f58f99d47fce919d19d65ff0@changeid Signed-off-by: Johannes Berg <[email protected]>
2020-12-11rfkill: add a reason to the HW rfkill stateEmmanuel Grumbach1-1/+23
The WLAN device may exist yet not be usable. This can happen when the WLAN device is controllable by both the host and some platform internal component. We need some arbritration that is vendor specific, but when the device is not available for the host, we need to reflect this state towards the user space. Add a reason field to the rfkill object (and event) so that userspace can know why the device is in rfkill: because some other platform component currently owns the device, or because the actual hw rfkill signal is asserted. Capable userspace can now determine the reason for the rfkill and possibly do some negotiation on a side band channel using a proprietary protocol to gain ownership on the device in case the device is owned by some other component. When the host gains ownership on the device, the kernel can remove the RFKILL_HARD_BLOCK_NOT_OWNER reason and the hw rfkill state will be off. Then, the userspace can bring the device up and start normal operation. The rfkill_event structure is enlarged to include the additional byte, it is now 9 bytes long. Old user space will ask to read only 8 bytes so that the kernel can know not to feed them with more data. When the user space writes 8 bytes, new kernels will just read what is present in the file descriptor. This new byte is read only from the userspace standpoint anyway. If a new user space uses an old kernel, it'll ask to read 9 bytes but will get only 8, and it'll know that it didn't get the new state. When it'll write 9 bytes, the kernel will again ignore this new byte which is read only from the userspace standpoint. Signed-off-by: Emmanuel Grumbach <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2020-12-11fsnotify: fix events reported to watching parent and childAmir Goldstein1-3/+3
fsnotify_parent() used to send two separate events to backends when a parent inode is watching children and the child inode is also watching. In an attempt to avoid duplicate events in fanotify, we unified the two backend callbacks to a single callback and handled the reporting of the two separate events for the relevant backends (inotify and dnotify). However the handling is buggy and can result in inotify and dnotify listeners receiving events of the type they never asked for or spurious events. The problem is the unified event callback with two inode marks (parent and child) is called when any of the parent and child inodes are watched and interested in the event, but the parent inode's mark that is interested in the event on the child is not necessarily the one we are currently reporting to (it could belong to a different group). So before reporting the parent or child event flavor to backend we need to check that the mark is really interested in that event flavor. The semantics of INODE and CHILD marks were hard to follow and made the logic more complicated than it should have been. Replace it with INODE and PARENT marks semantics to hopefully make the logic more clear. Thanks to Hugh Dickins for spotting a bug in the earlier version of this patch. Fixes: 497b0c5a7c06 ("fsnotify: send event to parent and child with single callback") CC: [email protected] Link: https://lore.kernel.org/r/[email protected] Reported-by: Hugh Dickins <[email protected]> Signed-off-by: Amir Goldstein <[email protected]> Signed-off-by: Jan Kara <[email protected]>
2020-12-11USB: typec: tcpm: Add a 30ms room for tPSSourceOn in PR_SWAPKyle Tso1-0/+1
TCPM state machine needs 20-25ms to enter the ErrorRecovery state after tPSSourceOn timer timeouts. Change the timer from max 480ms to 450ms to ensure that the timer complies with the Spec. In order to keep the flexibility for other usecases using tPSSourceOn, add another timer only for PR_SWAP. Cc: Guenter Roeck <[email protected]> Cc: Heikki Krogerus <[email protected]> Cc: Badhri Jagan Sridharan <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Signed-off-by: Kyle Tso <[email protected]> Signed-off-by: Will McVicker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-12-11ntp: Make the RTC sync offset less obscureThomas Gleixner1-6/+29
The current RTC set_offset_nsec value is not really intuitive to understand. tsched twrite(t2.tv_sec - 1) t2 (seconds increment) The offset is calculated from twrite based on the assumption that t2 - twrite == 1s. That means for the MC146818 RTC the offset needs to be negative so that the write happens 500ms before t2. It's easier to understand when the whole calculation is based on t2. That avoids negative offsets and the meaning is obvious: t2 - twrite: The time defined by the chip when seconds increment after the write. twrite - tsched: The time for the transport to the point where the chip is updated. ==> set_offset_nsec = t2 - tsched ttransport = twrite - tsched tRTCinc = t2 - twrite ==> set_offset_nsec = ttransport + tRTCinc tRTCinc is a chip property and can be obtained from the data sheet. ttransport depends on how the RTC is connected. It is close to 0 for directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the time required to send the update over the bus. This can be estimated or even calibrated, but that's a different problem. Adjust the implementation and update comments accordingly. Signed-off-by: Thomas Gleixner <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11ntp, rtc: Move rtc_set_ntp_time() to ntp codeThomas Gleixner1-34/+0
rtc_set_ntp_time() is not really RTC functionality as the code is just a user of RTC. Move it into the NTP code which allows further cleanups. Requested-by: Alexandre Belloni <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-11ntp: Make the RTC synchronization more reliableThomas Gleixner1-1/+0
Miroslav reported that the periodic RTC synchronization in the NTP code fails more often than not to hit the specified update window. The reason is that the code uses delayed_work to schedule the update which needs to be in thread context as the underlying RTC might be connected via a slow bus, e.g. I2C. In the update function it verifies whether the current time is correct vs. the requirements of the underlying RTC. But delayed_work is using the timer wheel for scheduling which is inaccurate by design. Depending on the distance to the expiry the wheel gets less granular to allow batching and to avoid the cascading of the original timer wheel. See 500462a9de65 ("timers: Switch to a non-cascading wheel") and the code for further details. The code already deals with this by splitting the 660 seconds period into a long 659 seconds timer and then retrying with a smaller delta. But looking at the actual granularities of the timer wheel (which depend on the HZ configuration) the 659 seconds timer ends up in an outer wheel level and is affected by a worst case granularity of: HZ Granularity 1000 32s 250 16s 100 40s So the initial timer can be already off by max 12.5% which is not a big issue as the period of the sync is defined as ~11 minutes. The fine grained second attempt schedules to the desired update point with a timer expiring less than a second from now. Depending on the actual delta and the HZ setting even the second attempt can end up in outer wheel levels which have a large enough granularity to make the correctness check fail. As this is a fundamental property of the timer wheel there is no way to make this more accurate short of iterating in one jiffies steps towards the update point. Switch it to an hrtimer instead which schedules the actual update work. The hrtimer will expire precisely (max 1 jiffie delay when high resolution timers are not available). The actual scheduling delay of the work is the same as before. The update is triggered from do_adjtimex() which is a bit racy but not much more racy than it was before: if (ntp_synced()) queue_delayed_work(system_power_efficient_wq, &sync_work, 0); which is racy when the work is currently executed and has not managed to reschedule itself. This becomes now: if (ntp_synced() && !hrtimer_is_queued(&sync_hrtimer)) queue_work(system_power_efficient_wq, &sync_work, 0); which is racy when the hrtimer has expired and the work is currently executed and has not yet managed to rearm the hrtimer. Not a big problem as it just schedules work for nothing. The new implementation has a safe guard in place to catch the case where the hrtimer is queued on entry to the work function and avoids an extra update attempt of the RTC that way. Reported-by: Miroslav Lichvar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Miroslav Lichvar <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-12-10Merge tag 'fixes-v5.10a' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull namespaced fscaps fix from James Morris: "Fix namespaced fscaps when !CONFIG_SECURITY (Serge Hallyn)" * tag 'fixes-v5.10a' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: [SECURITY] fix namespaced fscaps when !CONFIG_SECURITY
2020-12-10Merge tag 'nfs-for-5.10-3' of git://git.linux-nfs.org/projects/anna/linux-nfsLinus Torvalds1-0/+4
Pull NFS client fixes from Anna Schumaker: "Here are a handful more bugfixes for 5.10. Unfortunately, we found some problems with the new READ_PLUS operation that aren't easy to fix. We've decided to disable this codepath through a Kconfig option for now, but a series of patches going into 5.11 will clean up the code and fix the issues at the same time. This seemed like the best way to go about it. Summary: - Fix array overflow when flexfiles mirroring is enabled - Fix rpcrdma_inline_fixup() crash with new LISTXATTRS - Fix 5 second delay when doing inter-server copy - Disable READ_PLUS by default" * tag 'nfs-for-5.10-3' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFS: Disable READ_PLUS by default NFSv4.2: Fix 5 seconds delay when doing inter server copy NFS: Fix rpcrdma_inline_fixup() crash with new LISTXATTRS operation pNFS/flexfiles: Fix array overflow when flexfiles mirroring is enabled
2020-12-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds2-1/+5
Pull networking fixes from David Miller: 1) IPsec compat fixes, from Dmitry Safonov. 2) Fix memory leak in xfrm_user_policy(). Fix from Yu Kuai. 3) Fix polling in xsk sockets by using sk_poll_wait() instead of datagram_poll() which keys off of sk_wmem_alloc and such which xsk sockets do not update. From Xuan Zhuo. 4) Missing init of rekey_data in cfgh80211, from Sara Sharon. 5) Fix destroy of timer before init, from Davide Caratti. 6) Missing CRYPTO_CRC32 selects in ethernet driver Kconfigs, from Arnd Bergmann. 7) Missing error return in rtm_to_fib_config() switch case, from Zhang Changzhong. 8) Fix some src/dest address handling in vrf and add a testcase. From Stephen Suryaputra. 9) Fix multicast handling in Seville switches driven by mscc-ocelot driver. From Vladimir Oltean. 10) Fix proto value passed to skb delivery demux in udp, from Xin Long. 11) HW pkt counters not reported correctly in enetc driver, from Claudiu Manoil. 12) Fix deadlock in bridge, from Joseph Huang. 13) Missing of_node_pur() in dpaa2 driver, fromn Christophe JAILLET. 14) Fix pid fetching in bpftool when there are a lot of results, from Andrii Nakryiko. 15) Fix long timeouts in nft_dynset, from Pablo Neira Ayuso. 16) Various stymmac fixes, from Fugang Duan. 17) Fix null deref in tipc, from Cengiz Can. 18) When mss is biog, coose more resonable rcvq_space in tcp, fromn Eric Dumazet. 19) Revert a geneve change that likely isnt necessary, from Jakub Kicinski. 20) Avoid premature rx buffer reuse in various Intel driversm from Björn Töpel. 21) retain EcT bits during TIS reflection in tcp, from Wei Wang. 22) Fix Tso deferral wrt. cwnd limiting in tcp, from Neal Cardwell. 23) MPLS_OPT_LSE_LABEL attribute is 342 ot 8 bits, from Guillaume Nault 24) Fix propagation of 32-bit signed bounds in bpf verifier and add test cases, from Alexei Starovoitov. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (81 commits) selftests: fix poll error in udpgro.sh selftests/bpf: Fix "dubious pointer arithmetic" test selftests/bpf: Fix array access with signed variable test selftests/bpf: Add test for signed 32-bit bound check bug bpf: Fix propagation of 32-bit signed bounds from 64-bit bounds. MAINTAINERS: Add entry for Marvell Prestera Ethernet Switch driver net: sched: Fix dump of MPLS_OPT_LSE_LABEL attribute in cls_flower net/mlx4_en: Handle TX error CQE net/mlx4_en: Avoid scheduling restart task if it is already running tcp: fix cwnd-limited bug for TSO deferral where we send nothing net: flow_offload: Fix memory leak for indirect flow block tcp: Retain ECT bits for tos reflection ethtool: fix stack overflow in ethnl_parse_bitset() e1000e: fix S0ix flow to allow S0i3.2 subset entry ice: avoid premature Rx buffer reuse ixgbe: avoid premature Rx buffer reuse i40e: avoid premature Rx buffer reuse igb: avoid transmit queue timeout in xdp path igb: use xdp_do_flush igb: skb add metasize for xdp ...
2020-12-10fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode()Hao Li1-2/+1
If generic_drop_inode() returns true, it means iput_final() can evict this inode regardless of whether it is dirty or not. If we check I_DONTCACHE in generic_drop_inode(), any inode with this bit set will be evicted unconditionally. This is not the desired behavior because I_DONTCACHE only means the inode shouldn't be cached on the LRU list. As for whether we need to evict this inode, this is what generic_drop_inode() should do. This patch corrects the usage of I_DONTCACHE. This patch was proposed in [1]. [1]: https://lore.kernel.org/linux-fsdevel/[email protected]/ Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer") Signed-off-by: Hao Li <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Ira Weiny <[email protected]> Signed-off-by: Al Viro <[email protected]>
2020-12-10vfio/type1: Add vfio_group_iommu_domain()Lu Baolu1-0/+4
Add the API for getting the domain from a vfio group. This could be used by the physical device drivers which rely on the vfio/mdev framework for mediated device user level access. The typical use case like below: unsigned int pasid; struct vfio_group *vfio_group; struct iommu_domain *iommu_domain; struct device *dev = mdev_dev(mdev); struct device *iommu_device = mdev_get_iommu_device(dev); if (!iommu_device || !iommu_dev_feature_enabled(iommu_device, IOMMU_DEV_FEAT_AUX)) return -EINVAL; vfio_group = vfio_group_get_external_user_from_dev(dev); if (IS_ERR_OR_NULL(vfio_group)) return -EFAULT; iommu_domain = vfio_group_iommu_domain(vfio_group); if (IS_ERR_OR_NULL(iommu_domain)) { vfio_group_put_external_user(vfio_group); return -EFAULT; } pasid = iommu_aux_get_pasid(iommu_domain, iommu_device); if (pasid < 0) { vfio_group_put_external_user(vfio_group); return -EFAULT; } /* Program device context with pasid value. */ ... Signed-off-by: Lu Baolu <[email protected]> Signed-off-by: Alex Williamson <[email protected]>
2020-12-10mtd: rawnand: mxc: Remove platform data supportFabio Estevam1-19/+0
i.MX is a devicetree-only platform now and the existing platform data support in this driver was only useful for old non-devicetree platforms. Get rid of the platform data support since it is no longer used. Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Sascha Hauer <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2020-12-10mtd: rawnand: fix a kernel-doc markupMauro Carvalho Chehab1-1/+2
Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/9ed47a57d12c40e73a9b01612ee119d39baa6236.1603469755.git.mchehab+huawei@kernel.org
2020-12-10mtd: nand: Add helpers to manage ECC engines and configurationsMiquel Raynal1-0/+4
Add the logic in the NAND core to find the right ECC engine depending on the NAND chip requirements and the user desires. Right now, the choice may be made between (more will come): * software Hamming * software BCH * on-die (SPI-NAND devices only) Once the ECC engine has been found, the ECC engine must be configured. Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2020-12-10mtd: nand: Let on-die ECC engines be retrieved from the NAND coreMiquel Raynal1-0/+1
Before making use of the ECC engines, we must retrieve them. Add the necessary boilerplate. Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2020-12-10mtd: spinand: Instantiate a SPI-NAND on-die ECC engineMiquel Raynal1-0/+9
Make use of the existing functions taken from the SPI-NAND core to instantiate an on-die ECC engine specific to the SPI-NAND core. The next step will be to tweak the core to use this object instead of calling the helpers directly. Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.