aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/exported-sql-viewer.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-08-05firmware: arm_scmi: Add virtio transportIgor Skalkin8-0/+535
This transport enables communications with an SCMI platform through virtio; the SCMI platform will be represented by a virtio device. Implement an SCMI virtio driver according to the virtio SCMI device spec [1]. Virtio device id 32 has been reserved for the SCMI device [2]. The virtio transport has one Tx channel (virtio cmdq, A2P channel) and at most one Rx channel (virtio eventq, P2A channel). The following feature bit defined in [1] is not implemented: VIRTIO_SCMI_F_SHARED_MEMORY. The number of messages which can be pending simultaneously is restricted according to the virtqueue capacity negotiated at probing time. As soon as Rx channel message buffers are allocated or have been read out by the arm-scmi driver, feed them back to the virtio device. Since some virtio devices may not have the short response time exhibited by SCMI platforms using other transports, set a generous response timeout. SCMI polling mode is not supported by this virtio transport since deemed meaningless: polling mode operation is offered by the SCMI core to those transports that could not provide a completion interrupt on the TX path, which is never the case for virtio whose core callbacks can easily call into core scmi_rx_callback upon messages reception. [1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex [2] https://www.oasis-open.org/committees/ballot.php?id=3496 Link: https://lore.kernel.org/r/20210803131024.40280-16-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: simplified driver logic, changed link_supplier and channel available/setup logic, removed dummy callbacks ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add priv parameter to scmi_rx_callbackCristian Marussi4-8/+18
Add a new opaque void *priv parameter to scmi_rx_callback which can be optionally provided by the transport layer when invoking scmi_rx_callback and that will be passed back to the transport layer in xfer->priv. This can be used by transports that needs to keep track of their specific data structures together with the valid xfers. Link: https://lore.kernel.org/r/20210803131024.40280-15-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05dt-bindings: arm: Add virtio transport for SCMIIgor Skalkin1-1/+7
Document the properties for arm,scmi-virtio compatible nodes. The backing virtio SCMI device is described in patch [1]. While doing that, make shmem property required only for pre-existing mailbox and smc transports, since virtio-scmi does not need it. [1] https://lists.oasis-open.org/archives/virtio-comment/202102/msg00018.html Link: https://lore.kernel.org/r/20210803131024.40280-14-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: converted to yaml format, moved shmen required property. ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add optional link_supplier() transport opPeter Hilber2-0/+8
Some transports are also effectively registered with other kernel subsystem in order to be properly probed and initialized; as a consequence such kind of transports, and their related devices, might still not have been probed and initialized at the time the main SCMI core driver is probed. Add an optional .link_supplier() transport operation which can be used by the core SCMI stack to dynamically check if the transport is ready and dynamically link its device to the SCMI platform instance device. Link: https://lore.kernel.org/r/20210803131024.40280-13-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: reworded commit message ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add message passing abstractions for transportsPeter Hilber4-0/+133
Add abstractions for future transports using message passing, such as virtio. Derive the abstractions from the shared memory abstractions. Abstract the transport SDU through the opaque struct scmi_msg_payld. Also enable the transport to determine all other required information about the transport SDU. Link: https://lore.kernel.org/r/20210803131024.40280-12-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Adapted to new SCMI Kconfig layout, updated Copyrights ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add method to override max message numberIgor Skalkin2-6/+43
The maximum number of simultaneously pending messages is a transport specific quantity that is usually described statically in struct scmi_desc. Some transports, though, can calculate such number only at run-time after some initial transport specific setup and probing is completed; moreover the resulting max message numbers could also be different between rx and tx channels. Add an optional get_max_msg() operation so that a transport can report more accurate max message numbers for each channel type. The value in scmi_desc.max_msg is still used as default when transport does not provide any get_max_msg() method. Link: https://lore.kernel.org/r/20210803131024.40280-11-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: refactored how get_max_msg() is used to minimize core changes ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make shmem support optional for transportsIgor Skalkin2-1/+9
Upcoming new SCMI transports won't need any kind of shared memory support. Compile shmem.c only if a shmem based transport is selected. Link: https://lore.kernel.org/r/20210803131024.40280-10-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Adapted patch/commit_msg to new SCMI Kconfig layout ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make SCMI transports configurableCristian Marussi5-38/+80
Add configuration options to be able to select which SCMI transports have to be compiled into the SCMI stack. Mailbox and SMC are by default enabled if their related dependencies are satisfied. While doing that move all SCMI related config options in their own dedicated submenu. Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make polling mode optionalCristian Marussi1-1/+6
Add a check for the presence of .poll_done transport operation so that transports that do not need to support polling mode have no need to provide a dummy .poll_done callback either and polling mode can be disabled in the SCMI core for that tranport. Link: https://lore.kernel.org/r/20210803131024.40280-8-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make .clear_channel optionalCristian Marussi1-4/+11
Make transport operation .clear_channel optional since some transports do not need it and so avoid to have them implement dummy callbacks. Link: https://lore.kernel.org/r/20210803131024.40280-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Handle concurrent and out-of-order messagesCristian Marussi2-41/+246
Even though in case of asynchronous commands an SCMI platform is constrained to emit the delayed response message only after the related message response has been sent, the configured underlying transport could still deliver such messages together or in inverted order, causing races due to the concurrent or out-of-order access to the underlying xfer. Introduce a mechanism to grant exclusive access to an xfer in order to properly serialize concurrent accesses to the same xfer originating from multiple correlated messages. Add additional state information to xfer descriptors so as to be able to identify out-of-order message deliveries and act accordingly: - when a delayed response is expected but delivered before the related response, the synchronous response is considered as successfully received and the delayed response processing is carried on as usual. - when/if the missing synchronous response is subsequently received, it is discarded as not congruent with the current state of the xfer, or simply, because the xfer has been already released and so, now, the monotonically increasing sequence number carried by the late response is stale. Link: https://lore.kernel.org/r/20210803131024.40280-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Introduce monotonically increasing tokensCristian Marussi2-35/+251
Tokens are sequence numbers embedded in the each SCMI message header: they are used to correlate commands with responses (and delayed responses), but their usage and policy of selection is entirely up to the caller (usually the OSPM agent), while they are completely opaque to the callee (i.e. SCMI platform) which merely copies them back from the command into the response message header. This also means that the platform does not, can not and should not enforce any kind of policy on received messages depending on the contained sequence number: platform can perfectly handle concurrent requests carrying the same identifiying token if that should happen. Moreover the platform is not required to produce in-order responses to agent requests, the only constraint in these regards is that in case of an asynchronous message the delayed response must be sent after the immediate response for the synchronous part of the command transaction. Currenly the SCMI stack of the OSPM agent selects a token for the egressing commands picking the lowest possible number which is not already in use by an existing in-flight transaction, which means, in other words, that we immediately reuse any token after its transaction has completed or it has timed out: this policy indeed does simplify management and lookup of tokens and associated xfers. Under the above assumptions and constraints, since there is really no state shared between the agent and the platform to let the platform know when a token and its associated message has timed out, the current policy of early reuse of tokens can easily lead to the situation in which a spurious or late received response (or delayed_response), related to an old stale and timed out transaction, can be wrongly associated to a newer valid in-flight xfer that just happens to have reused the same token. This misbehaviour on such late/spurious responses is more easily exposed on those transports that naturally have an higher level of parallelism in processing multiple concurrent in-flight messages. This commit introduces a new policy of selection of tokens for the OSPM agent: each new command transfer now gets the next available, monotonically increasing token, until tokens are exhausted and the counter rolls over. Such new policy mitigates the above issues with late/spurious responses since the tokens are now reused as late as possible (when they roll back ideally) and so it is much easier to identify such late/spurious responses to stale timed out transactions: this also helps in simplifying the specific transports implementation since stale transport messages can be easily identified and discarded early on in the rx path without the need to cross check their actual state with the core transport layer. This mitigation is even more effective when, as is usually the case, the maximum number of pending messages is capped by the platform to a much lower number than the whole possible range of tokens values (2^10). This internal policy change in the core SCMI transport layer is fully transparent to the specific transports so it has not and should not have any impact on the transports implementation. Link: https://lore.kernel.org/r/20210803131024.40280-5-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add optional transport_init/exit supportCristian Marussi2-0/+65
Some SCMI transport could need to perform some transport specific setup before they can be used by the SCMI core transport layer: typically this early setup consists in registering with some other kernel subsystem. Add the optional capability for a transport to provide a couple of init and exit functions that are assured to be called early during the SCMI core initialization phase, well before the SCMI core probing step. [ Peter: Adapted RFC patch by Cristian for submission to upstream. ] Link: https://lore.kernel.org/r/20210803131024.40280-4-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Fixed scmi_transports_exit point of invocation ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Remove scmi_dump_header_dbg() helperCristian Marussi1-16/+0
Being a while that we have SCMI trace events in the SCMI stack, remove this debug helper and its call sites. Link: https://lore.kernel.org/r/20210803131024.40280-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add support for type handling in common functionsCristian Marussi2-1/+6
Add SCMI type handling to pack/unpack_scmi_header common helper functions. Initialize hdr.type properly when initializing a command xfer. Link: https://lore.kernel.org/r/20210803131024.40280-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-13firmware: arm_scmi: Fix range check for the maximum number of pending messagesCristian Marussi1-2/+3
SCMI message headers carry a sequence number and such field is sized to allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an acceptable maximum number of pending in-flight messages. Fix accordingly the checks performed on the value exported by transports in scmi_desc.max_msg Link: https://lore.kernel.org/r/20210712141833.6628-3-cristian.marussi@arm.com Reported-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: updated the patch title and error message] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-13firmware: arm_scmi: Avoid padding in sensor message structureCristian Marussi1-2/+4
scmi_resp_sensor_reading_complete structure is meant to represent an SCMI asynchronous reading complete message. The readings field with a 64bit type forces padding and breaks reads in scmi_sensor_reading_get. Split it in two adjacent 32bit readings_low/high subfields to avoid the padding within the structure. Alternatively we could to mark the structure packed. Link: https://lore.kernel.org/r/20210628170042.34105-1-cristian.marussi@arm.com Fixes: e2083d3673916 ("firmware: arm_scmi: Add SCMI v3.0 sensors timestamped reads") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-13firmware: arm_scmi: Fix kernel doc warnings about return valuesCristian Marussi2-0/+6
Kernel doc validation script still complains about the following: |No description found for return value of 'scmi_get_protocol_device' |No description found for return value of 'scmi_devm_notifier_register' |No description found for return value of 'scmi_devm_notifier_unregister' Fix adding missing Return kernel-doc statements. Link: https://lore.kernel.org/r/20210712143504.33541-1-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-13firmware: arm_scpi: Fix kernel doc warningsSudeep Holla1-0/+8
Kernel doc validation script is unhappy and complains with the below set of warnings. | Function parameter or member 'device_domain_id' not described in 'scpi_ops' | Function parameter or member 'get_transition_latency' not described in 'scpi_ops' | Function parameter or member 'add_opps_to_device' not described in 'scpi_ops' | Function parameter or member 'sensor_get_capability' not described in 'scpi_ops' | Function parameter or member 'sensor_get_info' not described in 'scpi_ops' | Function parameter or member 'sensor_get_value' not described in 'scpi_ops' | Function parameter or member 'device_get_power_state' not described in 'scpi_ops' | Function parameter or member 'device_set_power_state' not described in 'scpi_ops' Fix them adding appropriate documents or missing keywords. Link: https://lore.kernel.org/r/20210712130801.2436492-1-sudeep.holla@arm.com Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-13firmware: arm_scmi: Fix kernel doc warningsSudeep Holla1-5/+9
Kernel doc validation script is unhappy and complains with the below set of warnings. | Function parameter or member 'fast_switch_possible' not described in 'scmi_perf_proto_ops' | Function parameter or member 'power_scale_mw_get' not described in 'scmi_perf_proto_ops' | cannot understand function prototype: 'struct scmi_sensor_reading ' | cannot understand function prototype: 'struct scmi_range_attrs ' | cannot understand function prototype: 'struct scmi_sensor_axis_info ' | cannot understand function prototype: 'struct scmi_sensor_intervals_info ' Fix them adding appropriate documents or missing keywords. Link: https://lore.kernel.org/r/20210712130801.2436492-2-sudeep.holla@arm.com Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-12firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflowSudeep Holla1-3/+4
The scmi_linux_errmap buffer access index is supposed to depend on the array size to prevent element out of bounds access. It uses SCMI_ERR_MAX to check bounds but that can mismatch with the array size. It also changes the success into -EIO though scmi_linux_errmap is never used in case of success, it is expected to work for success case too. It is slightly confusing code as the negative of the error code is used as index to the buffer. Fix it by negating it at the start and make it more readable. Link: https://lore.kernel.org/r/20210707135028.1869642-1-sudeep.holla@arm.com Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-12firmware: arm_scmi: Ensure drivers provide a probe functionSudeep Holla1-0/+3
The bus probe callback calls the driver callback without further checking. Better be safe than sorry and refuse registration of a driver without a probe function to prevent a NULL pointer exception. Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices") Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-12firmware: arm_scmi: Simplify device probe function on the busSudeep Holla1-5/+0
When the driver core calls the probe callback it already checked that the devices match, so there is no need to call the match callback again. Link: https://lore.kernel.org/r/20210624095059.4010157-1-sudeep.holla@arm.com Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-07-11Linux 5.14-rc1Linus Torvalds1-2/+2
2021-07-11mm/rmap: try_to_migrate() skip zone_device !device_privateHugh Dickins1-3/+3
I know nothing about zone_device pages and !device_private pages; but if try_to_migrate_one() will do nothing for them, then it's better that try_to_migrate() filter them first, than trawl through all their vmas. Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/1241d356-8ec9-f47b-a5ec-9b2bf66d242@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-11mm/rmap: fix new bug: premature return from page_mlock_one()Hugh Dickins1-6/+5
In the unlikely race case that page_mlock_one() finds VM_LOCKED has been cleared by the time it got page table lock, page_vma_mapped_walk_done() must be called before returning, either explicitly, or by a final call to page_vma_mapped_walk() - otherwise the page table remains locked. Fixes: cd62734ca60d ("mm/rmap: split try_to_munlock from try_to_unmap") Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reported-by: kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/lkml/20210711151446.GB4070@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/lkml/f71f8523-cba7-3342-40a7-114abc5d1f51@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-11mm/rmap: fix old bug: munlocking THP missed other mlocksHugh Dickins1-5/+8
The kernel recovers in due course from missing Mlocked pages: but there was no point in calling page_mlock() (formerly known as try_to_munlock()) on a THP, because nothing got done even when it was found to be mapped in another VM_LOCKED vma. It's true that we need to be careful: Mlocked accounting of pte-mapped THPs is too difficult (so consistently avoided); but Mlocked accounting of only-pmd-mapped THPs is supposed to work, even when multiple mappings are mlocked and munlocked or munmapped. Refine the tests. There is already a VM_BUG_ON_PAGE(PageDoubleMap) in page_mlock(), so page_mlock_one() does not even have to worry about that complication. (I said the kernel recovers: but would page reclaim be likely to split THP before rediscovering that it's VM_LOCKED? I've not followed that up) Fixes: 9a73f61bdb8a ("thp, mlock: do not mlock PTE-mapped file huge pages") Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/lkml/cfa154c-d595-406-eb7d-eb9df730f944@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-11mm/rmap: fix comments left over from recent changesHugh Dickins2-7/+2
Parallel developments in mm/rmap.c have left behind some out-of-date comments: try_to_migrate_one() also accepts TTU_SYNC (already commented in try_to_migrate() itself), and try_to_migrate() returns nothing at all. TTU_SPLIT_FREEZE has just been deleted, so reword the comment about it in mm/huge_memory.c; and TTU_IGNORE_ACCESS was removed in 5.11, so delete the "recently referenced" comment from try_to_unmap_one() (once upon a time the comment was near the removed codeblock, but they drifted apart). Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/563ce5b2-7a44-5b4d-1dfd-59a0e65932a9@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-10mm/page_alloc: Revert pahole zero-sized workaroundMel Gorman2-14/+0
Commit dbbee9d5cd83 ("mm/page_alloc: convert per-cpu list protection to local_lock") folded in a workaround patch for pahole that was unable to deal with zero-sized percpu structures. A superior workaround is achieved with commit a0b8200d06ad ("kbuild: skip per-CPU BTF generation for pahole v1.18-v1.21"). This patch reverts the dummy field and the pahole version check. Fixes: dbbee9d5cd83 ("mm/page_alloc: convert per-cpu list protection to local_lock") Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-10rtc: pcf8523: rename register and bit definesAlexandre Belloni1-73/+73
arch/arm/mach-ixp4xx/include/mach/platform.h now gets included indirectly and defines REG_OFFSET. Rename the register and bit definition to something specific to the driver. Fixes: 7fd70c65faac ("ARM: irqstat: Get rid of duplicated declaration") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210710211431.1393589-1-alexandre.belloni@bootlin.com
2021-07-10rtc: pcf2127: handle timestamp interruptsMian Yousaf Kaukab1-59/+133
commit 03623b4b041c ("rtc: pcf2127: add tamper detection support") added support for timestamp interrupts. However they are not being handled in the irq handler. If a timestamp interrupt occurs it results in kernel disabling the interrupt and displaying the call trace: [ 121.145580] irq 78: nobody cared (try booting with the "irqpoll" option) ... [ 121.238087] [<00000000c4d69393>] irq_default_primary_handler threaded [<000000000a90d25b>] pcf2127_rtc_irq [rtc_pcf2127] [ 121.248971] Disabling IRQ #78 Handle timestamp interrupts in pcf2127_rtc_irq(). Save time stamp before clearing TSF1 and TSF2 flags so that it can't be overwritten. Set a flag to mark if the timestamp is valid and only report to sysfs if the flag is set. To mimic the hardware behavior, don’t save another timestamp until the first one has been read by the userspace. However, if the alarm irq is not configured, keep the old way of handling timestamp interrupt in the timestamp0 sysfs calls. Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> Reviewed-by: Bruno Thomsen <bruno.thomsen@gmail.com> Tested-by: Bruno Thomsen <bruno.thomsen@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210629150643.31551-1-ykaukab@suse.de
2021-07-10rtc: at91sam9: Remove unnecessary offset variable checksNobuhiro Iwamatsu1-1/+1
The offset variable is checked by at91_rtc_readalarm(), but this check is unnecessary because the previous check knew that the value of this variable was not 0. This removes that unnecessary offset variable checks. Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210708051340.341345-1-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: s5m: Check return value of s5m_check_peding_alarm_interrupt()Nobuhiro Iwamatsu1-3/+1
s5m_check_peding_alarm_interrupt() in s5m_rtc_read_alarm() gets the return value, but doesn't use it. This modifies using the s5m_check_peding_alarm_interrupt()"s return value as the s5m_rtc_read_alarm()'s return value. Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210708051304.341278-1-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: spear: convert to SPDX identifierNobuhiro Iwamatsu1-4/+1
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-11-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: tps6586x: convert to SPDX identifierNobuhiro Iwamatsu1-14/+1
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-9-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: tps80031: convert to SPDX identifierNobuhiro Iwamatsu1-14/+1
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-8-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: rtd119x: Fix format of SPDX identifierNobuhiro Iwamatsu1-2/+1
For C files, use the C99 format (//). Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-7-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: sc27xx: Fix format of SPDX identifierNobuhiro Iwamatsu1-1/+1
For C files, use the C99 format (//). Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Baolin Wang <baolin.wang7@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-6-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: palmas: convert to SPDX identifierNobuhiro Iwamatsu1-14/+1
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-5-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: max6900: convert to SPDX identifierNobuhiro Iwamatsu1-5/+3
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-4-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: ds1374: convert to SPDX identifierNobuhiro Iwamatsu1-5/+2
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-3-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-10rtc: au1xxx: convert to SPDX identifierNobuhiro Iwamatsu1-4/+1
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210707075804.337458-2-nobuhiro1.iwamatsu@toshiba.co.jp
2021-07-09Revert "PCI: Coalesce host bridge contiguous apertures"Bjorn Helgaas1-46/+4
This reverts commit 65db04053efea3f3e412a7e0cc599962999c96b4. Guenter reported that after 65db04053efe, the ppc:sam460ex qemu emulation no longer boots from nvme: nvme nvme0: Device not ready; aborting initialisation, CSTS=0x0 nvme nvme0: Removing after probe failure status: -19 Link: https://lore.kernel.org/r/20210709231529.GA3270116@roeck-us.net Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-07-10rtc: pcf85063: Update the PCF85063A datasheet revisionFabio Estevam1-1/+1
After updating the datasheet URL, the PCF85063A datasheet revision has changed. Adjust it accordingly. Reported-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210624120953.2313378-1-festevam@gmail.com
2021-07-10dt-bindings: rtc: ti,bq32k: take maintainershipAlexandre Belloni1-1/+1
Take maintainership of the binding as PAvel said he doesn't have the hardware anymore. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20210620224030.1115356-1-alexandre.belloni@bootlin.com
2021-07-09perf test: Add free() calls for scandir() returned dirent entriesRiccardo Mancini1-4/+11
ASan reported a memory leak for items of the entlist returned from scandir(). In fact, scandir() returns a malloc'd array of malloc'd dirents. This patch adds the missing (z)frees. Fixes: da963834fe6975a1 ("perf test: Iterate over shell tests in alphabetical order") Signed-off-by: Riccardo Mancini <rickyman7@gmail.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Fabian Hemmer <copy@copy.sh> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Remi Bernon <rbernon@codeweavers.com> Link: http://lore.kernel.org/lkml/20210709163454.672082-1-rickyman7@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-07-09libperf: Add tests for perf_evlist__set_leader()Jiri Olsa1-6/+21
Add a test for the newly added perf_evlist__set_leader() function. Committer testing: $ cd tools/lib/perf/ $ sudo make tests [sudo] password for acme: running static: - running tests/test-cpumap.c...OK - running tests/test-threadmap.c...OK - running tests/test-evlist.c...OK - running tests/test-evsel.c...OK running dynamic: - running tests/test-cpumap.c...OK - running tests/test-threadmap.c...OK - running tests/test-evlist.c...OK - running tests/test-evsel.c...OK $ Signed-off-by: Jiri Olsa <jolsa@kernel.org> Requested-by: Shunsuke Nakamura <nakamura.shun@fujitsu.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20210706151704.73662-8-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-07-09libperf: Remove BUG_ON() from library code in get_group_fd()Arnaldo Carvalho de Melo1-7/+16
We shouldn't just panic, return a value that doesn't clash with what perf_evsel__open() was already returning in case of error, i.e. errno when sys_perf_event_open() fails. Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Shunsuke Nakamura <nakamura.shun@fujitsu.com> Link: http://lore.kernel.org/lkml/YOiOA5zOtVH9IBbE@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2021-07-09cifs: update internal version numberSteve French1-1/+1
To 2.33 Signed-off-by: Steve French <stfrench@microsoft.com>
2021-07-09cifs: prevent NULL deref in cifs_compose_mount_options()Paulo Alcantara1-0/+3
The optional @ref parameter might contain an NULL node_name, so prevent dereferencing it in cifs_compose_mount_options(). Addresses-Coverity: 1476408 ("Explicit null dereferenced") Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Steve French <stfrench@microsoft.com>