summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-21dmaengine: Move dma_get_{,any_}slave_channel() to private dmaengine.hGeert Uytterhoeven
The functions dma_get_slave_channel() and dma_get_any_slave_channel() are called from DMA engine drivers only. Hence move their declarations from the public header file <linux/dmaengine.h> to the private header file drivers/dma/dmaengine.h. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200121093311.28639-4-geert+renesas@glider.be Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: Remove dma_request_slave_channel_compat() wrapperGeert Uytterhoeven
At its original introduction, dma_request_slave_channel_compat() used a wrapper, to accommodate filter functions that modify the mask passed. Filter functions can no longer modify masks, and the mask parameter was made const in commit a53e28da574a40bc ("dma: Make the 'mask' parameter of __dma_request_channel const") consecutively. Hence remove the wrapper, and rename __dma_request_slave_channel_compat() to dma_request_slave_channel_compat(), to get rid of one more function name starting with a double underscore. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200121093311.28639-3-geert+renesas@glider.be Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: Remove dma_device_satisfies_mask() wrapperGeert Uytterhoeven
Commit aa1e6f1a385eb2b0 ("dmaengine: kill struct dma_client and supporting infrastructure") removed the last user of the dma_device_satisfies_mask() wrapper. Remove the wrapper, and rename __dma_device_satisfies_mask() to dma_device_satisfies_mask(), to get rid of one more function starting with a double underscore. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200121093311.28639-2-geert+renesas@glider.be Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dt-bindings: fsl-imx-sdma: Add i.MX8MM/i.MX8MN/i.MX8MP compatible stringAnson Huang
Add imx8mm/imx8mn/imx8mp sdma support. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/1578893602-14395-1-git-send-email-Anson.Huang@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: zynqmp_dma: fix burst length configurationMatthias Fend
Since the dma engine expects the burst length register content as power of 2 value, the burst length needs to be converted first. Additionally add a burst length range check to avoid corrupting unrelated register bits. Signed-off-by: Matthias Fend <matthias.fend@wolfvision.net> Link: https://lore.kernel.org/r/20200115102249.24398-1-matthias.fend@wolfvision.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21ipv6: sr: remove SKB_GSO_IPXIP6 on End.D* actionsYuki Taguchi
After LRO/GRO is applied, SRv6 encapsulated packets have SKB_GSO_IPXIP6 feature flag, and this flag must be removed right after decapulation procedure. Currently, SKB_GSO_IPXIP6 flag is not removed on End.D* actions, which creates inconsistent packet state, that is, a normal TCP/IP packets have the SKB_GSO_IPXIP6 flag. This behavior can cause unexpected fallback to GSO on routing to netdevices that do not support SKB_GSO_IPXIP6. For example, on inter-VRF forwarding, decapsulated packets separated into small packets by GSO because VRF devices do not support TSO for packets with SKB_GSO_IPXIP6 flag, and this degrades forwarding performance. This patch removes encapsulation related GSO flags from the skb right after the End.D* action is applied. Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local") Signed-off-by: Yuki Taguchi <tagyounit@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-21arm64: Kconfig: select HAVE_FUTEX_CMPXCHGVladimir Murzin
arm64 provides always working implementation of futex_atomic_cmpxchg_inatomic(), so there is no need to check it runtime. Reported-by: Piyush swami <Piyush.swami@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-21dmaengine: sun4i: Add support for cyclic requests with dedicated DMAStefan Mavrodiev
Currently the cyclic transfers can be used only with normal DMAs. They can be used by pcm_dmaengine module, which is required for implementing sound with sun4i-hdmi encoder. This is so because the controller can accept audio only from a dedicated DMA. This patch enables them, following the existing style for the scatter/gather type transfers. Signed-off-by: Stefan Mavrodiev <stefan@olimex.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20200110141140.28527-2-stefan@olimex.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21Merge branch 'master' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2020-01-21 1) Fix packet tx through bpf_redirect() for xfrm and vti interfaces. From Nicolas Dichtel. 2) Do not confirm neighbor when do pmtu update on a virtual xfrm interface. From Xu Wang. 3) Support output_mark for offload ESP packets, this was forgotten when the output_mark was added initially. From Ulrich Weber. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-21dmaengine: fsl-qdma: fix duplicated argument to &&Chen Zhou
There is duplicated argument to && in function fsl_qdma_free_chan_resources, which looks like a typo, pointer fsl_queue->desc_pool also needs NULL check, fix it. Detected with coccinelle. Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs") Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Reviewed-by: Peng Ma <peng.ma@nxp.com> Tested-by: Peng Ma <peng.ma@nxp.com> Link: https://lore.kernel.org/r/20200120125843.34398-1-chenzhou10@huawei.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: ti: k3-psil: make symbols staticPeter Ujfalusi
Fixe the following warnings by making these static drivers/dma/ti/k3-psil-j721e.c:62:16: warning: symbol 'j721e_src_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-j721e.c:172:16: warning: symbol 'j721e_dst_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-j721e.c:216:20: warning: symbol 'j721e_ep_map' was not declared. Should it be static? CC drivers/dma/ti/k3-psil-j721e.o drivers/dma/ti/k3-psil-am654.c:52:16: warning: symbol 'am654_src_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-am654.c:127:16: warning: symbol 'am654_dst_ep_map' was not declared. Should it be static? drivers/dma/ti/k3-psil-am654.c:169:20: warning: symbol 'am654_ep_map' was not declared. Should it be static? Reported-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20200121070104.4393-1-peter.ujfalusi@ti.com [vkoul: updated patch title] Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21drm/i915: Align engine->uabi_class/instance with i915_drm.hTvrtko Ursulin
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates implicit coupling with type widths used in, also ABI, struct i915_engine_class_instance. One place where we export engine->uabi_class I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the type of the former is u8 in contrast to u16 defined in the ABI, 254 will be returned instead of 65534 which userspace would legitimately expect. Another place is I915_CONTEXT_PARAM_ENGINES. Therefore we need to align the type used to store engine ABI class and instance. v2: * Update the commit message mentioning get_engines and cc stable. (Chris) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v5.3+ Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200116134508.25211-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 0b3bd0cdc329a1e2e00995cffd61aacf58c87cb4) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-01-21drm/i915/userptr: fix size calculationMatthew Auld
If we create a rather large userptr object(e.g 1ULL << 32) we might shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT, resulting in a totally bogus sg_table, which fortunately will eventually manifest as: gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size) kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463! v2: more unsigned long prefer I915_GTT_PAGE_SIZE Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200117132413.1170563-2-matthew.auld@intel.com (cherry picked from commit 8e78871bc1e5efec22c950d3fd24ddb63d4ff28a) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-01-21dmaengine: ti: k3-udma: Add glue layer for non DMAengine usersGrygorii Strashko
Certain users can not use right now the DMAengine API due to missing features in the core. Prime example is Networking. These users can use the glue layer interface to avoid misuse of DMAengine API and when the core gains the needed features they can be converted to use generic API. The most prominent features the glue layer clients are depending on: - most PSI-L native peripheral use extra rflow ranges on a receive channel and depending on the peripheral's configuration packets from a single free descriptor ring is going to be received to different receive ring - it is also possible to have different free descriptor rings per rflow and an rflow can also support 4 additional free descriptor ring based on the size of the incoming packet - out of order completion of descriptors on a channel - when we have several queues to handle different priority packets the descriptors will be completed 'out-of-order' - the notion of prep_slave_sg is not matching with what the streaming type of operation is demanding for networking - Streaming type of operation - Ability to fill the free descriptor ring with descriptors in anticipation of incoming traffic and when a packet arrives UDMAP will form a packet and gives it to the client driver - the descriptors are not backed with exact size data buffers as we don't know the size of the packet we will receive, but as a generic pool of buffers to be used by the receive channel - NAPI type of operation (polling instead of interrupt driven transfer) - without this we can not sustain gigabit speeds and we need to support NAPI - not to limit this to networking, but other high performance operations Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-12-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: ti: New driver for K3 UDMAPeter Ujfalusi
Split patch for review containing: defines, structs, io and low level functions and interrupt callbacks. DMA driver for Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P) The UDMA-P is intended to perform similar (but significantly upgraded) functions as the packet-oriented DMA used on previous SoC devices. The UDMA-P module supports the transmission and reception of various packet types. The UDMA-P is architected to facilitate the segmentation and reassembly of SoC DMA data structure compliant packets to/from smaller data blocks that are natively compatible with the specific requirements of each connected peripheral. Multiple Tx and Rx channels are provided within the DMA which allow multiple segmentation or reassembly operations to be ongoing. The DMA controller maintains state information for each of the channels which allows packet segmentation and reassembly operations to be time division multiplexed between channels in order to share the underlying DMA hardware. An external DMA scheduler is used to control the ordering and rate at which this multiplexing occurs for Transmit operations. The ordering and rate of Receive operations is indirectly controlled by the order in which blocks are pushed into the DMA on the Rx PSI-L interface. The UDMA-P also supports acting as both a UTC and UDMA-C for its internal channels. Channels in the UDMA-P can be configured to be either Packet-Based or Third-Party channels on a channel by channel basis. The initial driver supports: - MEM_TO_MEM (TR mode) - DEV_TO_MEM (Packet / TR mode) - MEM_TO_DEV (Packet / TR mode) - Cyclic (Packet / TR mode) - Metadata for descriptors Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-11-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dt-bindings: dma: ti: Add document for K3 UDMAPeter Ujfalusi
New binding document for Texas Instruments K3 NAVSS Unified DMA – Peripheral Root Complex (UDMA-P). UDMA-P is introduced as part of the K3 architecture and can be found in AM654 and j721e. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-10-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: ti: k3 PSI-L remote endpoint configurationPeter Ujfalusi
In K3 architecture the DMA operates within threads. One end of the thread is UDMAP, the other is on the peripheral side. The UDMAP channel configuration depends on the needs of the remote endpoint and it can be differ from peripheral to peripheral. This patch adds database for am654 and j721e and small API to fetch the PSI-L endpoint configuration from the database which should only used by the DMA driver(s). Another API is added for native peripherals to give possibility to pass new configuration for the threads they are using, which is needed to be able to handle changes caused by different firmware loaded for the peripheral for example. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-9-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: ti: Add cppi5 header for K3 NAVSS/UDMAPeter Ujfalusi
The K3 DMA architecture uses CPPI5 (Communications Port Programming Interface) specified descriptors over PSI-L bus within NAVSS. The header provides helpers, macros to work with these descriptors in a consistent way. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-8-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: Add helper function to convert direction value to textPeter Ujfalusi
dmaengine_get_direction_text() can be useful when the direction is printed out. The text is easier to comprehend than the number. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-7-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: Add support for reporting DMA cached data amountPeter Ujfalusi
A DMA hardware can have big cache or FIFO and the amount of data sitting in the DMA fabric can be an interest for the clients. For example in audio we want to know the delay in the data flow and in case the DMA have significantly large FIFO/cache, it can affect the latenc/delay Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-6-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: Add metadata_ops for dma_async_tx_descriptorPeter Ujfalusi
The metadata is best described as side band data or parameters traveling alongside the data DMAd by the DMA engine. It is data which is understood by the peripheral and the peripheral driver only, the DMA engine see it only as data block and it is not interpreting it in any way. The metadata can be different per descriptor as it is a parameter for the data being transferred. If the DMA supports per descriptor metadata it can implement the attach, get_ptr/set_len callbacks. Client drivers must only use either attach or get_ptr/set_len to avoid misconfiguration. Client driver can check if a given metadata mode is supported by the channel during probe time with dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_CLIENT); dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_ENGINE); and based on this information can use either mode. Wrappers are also added for the metadata_ops. To be used in DESC_METADATA_CLIENT mode: dmaengine_desc_attach_metadata() To be used in DESC_METADATA_ENGINE mode: dmaengine_desc_get_metadata_ptr() dmaengine_desc_set_metadata_len() Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-5-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21dmaengine: doc: Add sections for per descriptor metadata supportPeter Ujfalusi
Update the provider and client documentation with details about the metadata support. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20191223110458.30766-4-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21Merge TI ringacc driver from SantoshVinod Koul
This is for dependency of new TI ringacc dmaengine drivers Merge tag 'drivers_soc_for_5.6' into topic/ti SOC: TI Keystone Ring Accelerator driver The Ring Accelerator (RINGACC or RA) provides hardware acceleration to enable straightforward passing of work between a producer and a consumer. There is one RINGACC module per NAVSS on TI AM65x SoCs. Signed-off-by: Vinod Koul <vkoul@kernel.org>
2020-01-21scsi: RDMA/isert: Fix a recently introduced regression related to logoutBart Van Assche
iscsit_close_connection() calls isert_wait_conn(). Due to commit e9d3009cb936 both functions call target_wait_for_sess_cmds() although that last function should be called only once. Fix this by removing the target_wait_for_sess_cmds() call from isert_wait_conn() and by only calling isert_wait_conn() after target_wait_for_sess_cmds(). Fixes: e9d3009cb936 ("scsi: target: iscsi: Wait for all commands to finish before freeing a session"). Link: https://lore.kernel.org/r/20200116044737.19507-1-bvanassche@acm.org Reported-by: Rahul Kundu <rahul.kundu@chelsio.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Acked-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-01-20scsi: fnic: do not queue commands during fwresetHannes Reinecke
When a link is going down the driver will be calling fnic_cleanup_io(), which will traverse all commands and calling 'done' for each found command. While the traversal is handled under the host_lock, calling 'done' happens after the host_lock is being dropped. As fnic_queuecommand_lck() is being called with the host_lock held, it might well be that it will pick the command being selected for abortion from the above routine and enqueue it for sending, but then 'done' is being called on that very command from the above routine. Which of course confuses the hell out of the scsi midlayer. So fix this by not queueing commands when fnic_cleanup_io is active. Link: https://lore.kernel.org/r/20200116102053.62755-1-hare@suse.de Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-01-20Input: pm8xxx-vib - fix handling of separate enable registerStephan Gerhold
Setting the vibrator enable_mask is not implemented correctly: For regmap_update_bits(map, reg, mask, val) we give in either regs->enable_mask or 0 (= no-op) as mask and "val" as value. But "val" actually refers to the vibrator voltage control register, which has nothing to do with the enable_mask. So we usually end up doing nothing when we really wanted to enable the vibrator. We want to set or clear the enable_mask (to enable/disable the vibrator). Therefore, change the call to always modify the enable_mask and set the bits only if we want to enable the vibrator. Fixes: d4c7c5c96c92 ("Input: pm8xxx-vib - handle separate enable register") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200114183442.45720-1-stephan@gerhold.net Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-01-20io_uring: fix compat for IORING_REGISTER_FILES_UPDATEEugene Syromiatnikov
fds field of struct io_uring_files_update is problematic with regards to compat user space, as pointer size is different in 32-bit, 32-on-64-bit, and 64-bit user space. In order to avoid custom handling of compat in the syscall implementation, make fds __u64 and use u64_to_user_ptr in order to retrieve it. Also, align the field naturally and check that no garbage is passed there. Fixes: c3a31e605620c279 ("io_uring: add support for IORING_REGISTER_FILES_UPDATE") Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-01-20tracing: Do not set trace clock if tracefs lockdown is in effectMasami Ichikawa
When trace_clock option is not set and unstable clcok detected, tracing_set_default_clock() sets trace_clock(ThinkPad A285 is one of case). In that case, if lockdown is in effect, null pointer dereference error happens in ring_buffer_set_clock(). Link: http://lkml.kernel.org/r/20200116131236.3866925-1-masami256@gmail.com Cc: stable@vger.kernel.org Fixes: 17911ff38aa58 ("tracing: Add locked_down checks to the open calls of files created for tracefs") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1788488 Signed-off-by: Masami Ichikawa <masami256@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-01-20tracing: Fix histogram code when expression has same var as valueSteven Rostedt (VMware)
While working on a tool to convert SQL syntex into the histogram language of the kernel, I discovered the following bug: # echo 'first u64 start_time u64 end_time pid_t pid u64 delta' >> synthetic_events # echo 'hist:keys=pid:start=common_timestamp' > events/sched/sched_waking/trigger # echo 'hist:keys=next_pid:delta=common_timestamp-$start,start2=$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger Would not display any histograms in the sched_switch histogram side. But if I were to swap the location of "delta=common_timestamp-$start" with "start2=$start" Such that the last line had: # echo 'hist:keys=next_pid:start2=$start,delta=common_timestamp-$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' > events/sched/sched_switch/trigger The histogram works as expected. What I found out is that the expressions clear out the value once it is resolved. As the variables are resolved in the order listed, when processing: delta=common_timestamp-$start The $start is cleared. When it gets to "start2=$start", it errors out with "unresolved symbol" (which is silent as this happens at the location of the trace), and the histogram is dropped. When processing the histogram for variable references, instead of adding a new reference for a variable used twice, use the same reference. That way, not only is it more efficient, but the order will no longer matter in processing of the variables. From Tom Zanussi: "Just to clarify some more about what the problem was is that without your patch, we would have two separate references to the same variable, and during resolve_var_refs(), they'd both want to be resolved separately, so in this case, since the first reference to start wasn't part of an expression, it wouldn't get the read-once flag set, so would be read normally, and then the second reference would do the read-once read and also be read but using read-once. So everything worked and you didn't see a problem: from: start2=$start,delta=common_timestamp-$start In the second case, when you switched them around, the first reference would be resolved by doing the read-once, and following that the second reference would try to resolve and see that the variable had already been read, so failed as unset, which caused it to short-circuit out and not do the trigger action to generate the synthetic event: to: delta=common_timestamp-$start,start2=$start With your patch, we only have the single resolution which happens correctly the one time it's resolved, so this can't happen." Link: https://lore.kernel.org/r/20200116154216.58ca08eb@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers") Reviewed-by: Tom Zanuss <zanussi@kernel.org> Tested-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-01-20Merge tag 'fixes_for_v5.5-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull reiserfs fix from Jan Kara: "A fixup of a recently merged reiserfs fix which has caused problem when xattrs were not compiled in" * tag 'fixes_for_v5.5-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: reiserfs: fix handling of -EOPNOTSUPP in reiserfs_for_each_xattr
2020-01-20irqdomain: Fix a memory leak in irq_domain_push_irq()Kevin Hao
Fix a memory leak reported by kmemleak: unreferenced object 0xffff000bc6f50e80 (size 128): comm "kworker/23:2", pid 201, jiffies 4294894947 (age 942.132s) hex dump (first 32 bytes): 00 00 00 00 41 00 00 00 86 c0 03 00 00 00 00 00 ....A........... 00 a0 b2 c6 0b 00 ff ff 40 51 fd 10 00 80 ff ff ........@Q...... backtrace: [<00000000e62d2240>] kmem_cache_alloc_trace+0x1a4/0x320 [<00000000279143c9>] irq_domain_push_irq+0x7c/0x188 [<00000000d9f4c154>] thunderx_gpio_probe+0x3ac/0x438 [<00000000fd09ec22>] pci_device_probe+0xe4/0x198 [<00000000d43eca75>] really_probe+0xdc/0x320 [<00000000d3ebab09>] driver_probe_device+0x5c/0xf0 [<000000005b3ecaa0>] __device_attach_driver+0x88/0xc0 [<000000004e5915f5>] bus_for_each_drv+0x7c/0xc8 [<0000000079d4db41>] __device_attach+0xe4/0x140 [<00000000883bbda9>] device_initial_probe+0x18/0x20 [<000000003be59ef6>] bus_probe_device+0x98/0xa0 [<0000000039b03d3f>] deferred_probe_work_func+0x74/0xa8 [<00000000870934ce>] process_one_work+0x1c8/0x470 [<00000000e3cce570>] worker_thread+0x1f8/0x428 [<000000005d64975e>] kthread+0xfc/0x128 [<00000000f0eaa764>] ret_from_fork+0x10/0x18 Fixes: 495c38d3001f ("irqdomain: Add irq_domain_{push,pop}_irq() functions") Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200120043547.22271-1-haokexin@gmail.com
2020-01-20irqchip: Add NXP INTMUX interrupt multiplexer supportJoakim Zhang
The Interrupt Multiplexer (INTMUX) expands the number of peripherals that can interrupt the core: * The INTMUX has 8 channels that are assigned to 8 NVIC interrupt slots. * Each INTMUX channel can receive up to 32 interrupt sources and has 1 interrupt output. * The INTMUX routes the interrupt sources to the interrupt outputs. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200117060653.27485-3-qiangqing.zhang@nxp.com
2020-01-20dt-bindings: interrupt-controller: Add binding for NXP INTMUX interrupt ↵Joakim Zhang
multiplexer This patch adds the DT bindings for the NXP INTMUX interrupt multiplexer for i.MX8 family SoCs. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200117060653.27485-2-qiangqing.zhang@nxp.com
2020-01-20irqchip: Define EXYNOS_IRQ_COMBINERHyunki Koo
This patch is written to clean up dependency of ARCH_EXYNOS Not all exynos device have IRQ_COMBINER, especially aarch64 EXYNOS but it is built for all exynos devices. Thus add the config for EXYNOS_IRQ_COMBINER remove direct dependency between ARCH_EXYNOS and exynos-combiner.c and only selected on the aarch32 devices Signed-off-by: Hyunki Koo <hyunki00.koo@samsung.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20191224211108.7128-1-hyunki00.koo@gmail.com
2020-01-20irqchip/meson-gpio: Add support for meson a1 SoCsQianggui Song
The meson a1 Socs have some changes compared with previous chips. For A113L, it contains 62 pins and can be spied on: - 62:128 undefined - 61:50 12 pins on bank A - 49:37 13 pins on bank F - 36:20 17 pins on bank X - 19:13 7 pins on bank B - 12:0 13 pins on bank P There are five relative registers for gpio interrupt controller, details are as below: - PADCTRL_GPIO_IRQ_CTRL0 bit[31]: enable/disable the whole irq lines bit[16-23]: both edge trigger bit[8-15]: single edge trigger bit[0-7]: pol trigger - PADCTRL_GPIO_IRQ_CTRL[X] bit[0-6]: 7 bits to choose gpio source for irq line 2*[X] - 2 bit[16-22]: 7 bits to choose gpio source for irq line 2*[X] - 1 where X =1,2,3,4 Signed-off-by: Qianggui Song <qianggui.song@amlogic.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191216123645.10099-4-qianggui.song@amlogic.com
2020-01-20irqchip/meson-gpio: Rework meson irqchip driver to support meson-A1 SoCsQianggui Song
Since Meson-A1 SoCs register layout of gpio interrupt controller has difference with previous chips, registers to decide irq line and offset of trigger method are all changed, the current driver should be modified. Signed-off-by: Qianggui Song <qianggui.song@amlogic.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191216123645.10099-3-qianggui.song@amlogic.com
2020-01-20dt-bindings: interrupt-controller: New binding for Meson-A1 SoCsQianggui Song
Update dt-binding document for GPIO interrupt controller of Meson-A1 SoCs Signed-off-by: Qianggui Song <qianggui.song@amlogic.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191216123645.10099-2-qianggui.song@amlogic.com
2020-01-20irqchip/mbigen: Set driver .suppress_bind_attrs to avoid remove problemsJohn Garry
The following crash can be seen for setting CONFIG_DEBUG_TEST_DRIVER_REMOVE=y for DT FW (which some people still use): Hisilicon MBIGEN-V2 60080000.interrupt-controller: Failed to create mbi-gen irqdomain Hisilicon MBIGEN-V2: probe of 60080000.interrupt-controller failed with error -12 [...] Unable to handle kernel paging request at virtual address 0000000000005008 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000041fb9990000 [0000000000005008] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 7 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc6-00002-g3fc42638a506-dirty #1622 Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 pstate: 40000085 (nZcv daIf -PAN -UAO) pc : mbigen_set_type+0x38/0x60 lr : __irq_set_trigger+0x6c/0x188 sp : ffff800014b4b400 x29: ffff800014b4b400 x28: 0000000000000007 x27: 0000000000000000 x26: 0000000000000000 x25: ffff041fd83bd0d4 x24: ffff041fd83bd188 x23: 0000000000000000 x22: ffff80001193ce00 x21: 0000000000000004 x20: 0000000000000000 x19: ffff041fd83bd000 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000119098c8 x14: ffff041fb94ec91c x13: ffff041fb94ec1a1 x12: 0000000000000030 x11: 0101010101010101 x10: 0000000000000040 x9 : 0000000000000000 x8 : ffff041fb98c6680 x7 : ffff800014b4b380 x6 : ffff041fd81636c8 x5 : 0000000000000000 x4 : 000000000000025f x3 : 0000000000005000 x2 : 0000000000005008 x1 : 0000000000000004 x0 : 0000000080000000 Call trace: mbigen_set_type+0x38/0x60 __setup_irq+0x744/0x900 request_threaded_irq+0xe0/0x198 pcie_pme_probe+0x98/0x118 pcie_port_probe_service+0x38/0x78 really_probe+0xa0/0x3e0 driver_probe_device+0x58/0x100 __device_attach_driver+0x90/0xb0 bus_for_each_drv+0x64/0xc8 __device_attach+0xd8/0x138 device_initial_probe+0x10/0x18 bus_probe_device+0x90/0x98 device_add+0x4c4/0x770 device_register+0x1c/0x28 pcie_port_device_register+0x1e4/0x4f0 pcie_portdrv_probe+0x34/0xd8 local_pci_probe+0x3c/0xa0 pci_device_probe+0x128/0x1c0 really_probe+0xa0/0x3e0 driver_probe_device+0x58/0x100 __device_attach_driver+0x90/0xb0 bus_for_each_drv+0x64/0xc8 __device_attach+0xd8/0x138 device_attach+0x10/0x18 pci_bus_add_device+0x4c/0xb8 pci_bus_add_devices+0x38/0x88 pci_host_probe+0x3c/0xc0 pci_host_common_probe+0xf0/0x208 hisi_pcie_almost_ecam_probe+0x24/0x30 platform_drv_probe+0x50/0xa0 really_probe+0xa0/0x3e0 driver_probe_device+0x58/0x100 device_driver_attach+0x6c/0x90 __driver_attach+0x84/0xc8 bus_for_each_dev+0x74/0xc8 driver_attach+0x20/0x28 bus_add_driver+0x148/0x1f0 driver_register+0x60/0x110 __platform_driver_register+0x40/0x48 hisi_pcie_almost_ecam_driver_init+0x1c/0x24 The specific problem here is that the mbigen driver real probe has failed as the mbigen_of_create_domain()->of_platform_device_create() call fails, the reason for that being that we never destroyed the platform device created during the remove test dry run and there is some conflict. Since we generally would never want to unbind this driver, and to save adding a driver tear down path for that, just set the driver .suppress_bind_attrs member to avoid this possibility. Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/1579196323-180137-1-git-send-email-john.garry@huawei.com
2020-01-20irqchip: Add Aspeed SCU interrupt controllerEddie James
The Aspeed SOCs provide some interrupts through the System Control Unit registers. Add an interrupt controller that provides these interrupts to the system. Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/1579123790-6894-3-git-send-email-eajames@linux.ibm.com
2020-01-20dt-bindings: interrupt-controller: Add Aspeed SCU interrupt controllerEddie James
Document the Aspeed SCU interrupt controller and add an include file for the interrupts it provides. Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/1579123790-6894-2-git-send-email-eajames@linux.ibm.com
2020-01-20gpio/sifive: Add GPIO driver for SiFive SoCsYash Shah
Adds the GPIO driver for SiFive RISC-V SoCs. Signed-off-by: Wesley W. Terpstra <wesley@sifive.com> [Atish: Various fixes and code cleanup] Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Yash Shah <yash.shah@sifive.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/1575976274-13487-6-git-send-email-yash.shah@sifive.com
2020-01-20regulator: core: Fix exported symbols to the exported GPL versionEnric Balletbo i Serra
Change the exported symbols introduced by commit e9153311491da ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for all the core parts. Fixes: e9153311491da ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage") Reported-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20200120123921.1204339-1-enric.balletbo@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-20netfilter: ipset: use bitmap infrastructure completelyKadlecsik József
The bitmap allocation did not use full unsigned long sizes when calculating the required size and that was triggered by KASAN as slab-out-of-bounds read in several places. The patch fixes all of them. Reported-by: syzbot+fabca5cbf5e54f3fe2de@syzkaller.appspotmail.com Reported-by: syzbot+827ced406c9a1d9570ed@syzkaller.appspotmail.com Reported-by: syzbot+190d63957b22ef673ea5@syzkaller.appspotmail.com Reported-by: syzbot+dfccdb2bdb4a12ad425e@syzkaller.appspotmail.com Reported-by: syzbot+df0d0f5895ef1f41a65b@syzkaller.appspotmail.com Reported-by: syzbot+b08bd19bb37513357fd4@syzkaller.appspotmail.com Reported-by: syzbot+53cdd0ec0bbabd53370a@syzkaller.appspotmail.com Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-01-20selinux: fix regression introduced by move_mount(2) syscallStephen Smalley
commit 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around") introduced a new move_mount(2) system call and a corresponding new LSM security_move_mount hook but did not implement this hook for any existing LSM. This creates a regression for SELinux with respect to consistent checking of mounts; the existing selinux_mount hook checks mounton permission to the mount point path. Provide a SELinux hook implementation for move_mount that applies this same check for consistency. In the future we may wish to add a new move_mount filesystem permission and check as well, but this addresses the immediate regression. Fixes: 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around") Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Reviewed-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2020-01-20hsr: Fix a compilation errorxiaofeng.yan
A compliation error happen when building branch 5.5-rc7 In file included from net/hsr/hsr_main.c:12:0: net/hsr/hsr_main.h:194:20: error: two or more data types in declaration specifiers static inline void void hsr_debugfs_rename(struct net_device *dev) So Removed one void. Fixes: 4c2d5e33dcd3 ("hsr: rename debugfs file when interface name is changed") Signed-off-by: xiaofeng.yan <yanxiaofeng7@jd.com> Acked-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-20mmc: sdhci-of-esdhc: fix serious issue clock is always disabledYangbo Lu
This patch is to fix a serious issue that clock is always disabled in esdhc_of_set_clock(). Fixes: 1b21a701aed9 ("mmc: sdhci-of-esdhc: fix clock setting for different controller versions") Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Link: https://lore.kernel.org/r/20200120094835.28050-1-yangbo.lu@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-of-esdhc: fix transfer mode register readingYangbo Lu
The standard SD controller uses two 16-bit registers for command sending. 0xC: Transfer Mode Register 0xE: Command Register But the eSDHC controller uses one 32-bit register instead. 0xC: XFERTYPE For Transfer Mode Register and Command Register writing, the eSDHC driver will store Transfer Mode Register value in a variable first. When Command Register writing happens, driver will directly write a 32-bit value into XFERTYPE register. But for Transfer Mode Register reading, driver just returns a actual value. This may cause issue for some read-modify-write operations. We should make both reading and write on that variable for Transfer Mode Register. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Link: https://lore.kernel.org/r/20200117063858.37296-1-yangbo.lu@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-brcmstb: Fix incorrect switch to HS modeAl Cooper
When switching from any MMC speed mode that requires 1.8v (HS200, HS400 and HS400ES) to High Speed (HS) mode, the system ends up configured for SDR12 with a 50MHz clock which is an illegal mode. This happens because the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register is left set and when this bit is set, the speed mode is controlled by the SDHCI_CTRL_UHS field in the SDHCI_HOST_CONTROL2 register. The SDHCI_CTRL_UHS field will end up being set to 0 (SDR12) by sdhci_set_uhs_signaling() because there is no UHS mode being set. The fix is to change sdhci_set_uhs_signaling() to set the SDHCI_CTRL_UHS field to SDR25 (which is the same as HS) for any switch to HS mode. This was found on a new eMMC controller that does strict checking of the speed mode and the corresponding clock rate. It caused the switch to HS400 mode to fail because part of the sequence to switch to HS400 requires a switch from HS200 to HS before going to HS400. This issue was previously fixed by commit c894e33ddc191 ("mmc: sdhci: Fix incorrect switch to HS mode") and later removed by commit 07bcc411567c ("Revert \"mmc: sdhci: Fix incorrect switch to HS mode\"") because it caused failures with some SD cards on AM65X systems. The fix will now be done in a platform specific callback instead of common sdhci code. Signed-off-by: Al Cooper <alcooperx@gmail.com> Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20200113210706.11972-7-alcooperx@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-brcmstb: Add support for Command Queuing (CQE)Al Cooper
The latest Arasan controller first used in the 7216 now supports CQE so enable this feature. Signed-off-by: Al Cooper <alcooperx@gmail.com> Link: https://lore.kernel.org/r/20200113210706.11972-6-alcooperx@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-01-20mmc: sdhci-brcmstb: Add shutdown callbackAl Cooper
Shutdown controller and disable it's clocks to insure max power savings in S5 on systems that leave power on. Signed-off-by: Al Cooper <alcooperx@gmail.com> Link: https://lore.kernel.org/r/20200113210706.11972-5-alcooperx@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>