summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-12-08PCI: Reduce pci_set_cacheline_size() message to debug levelHeiner Kallweit
Drivers like ehci_hcd and xhci_hcd use pci_set_mwi() and emit an annnoying message like the following that results in user questions whether something is broken: xhci_hcd 0000:00:15.0: cache line size of 64 is not supported Root cause of the message is that on several chips the Cache Line Size register is hard-wired to 0. Change this message to debug level; an interested caller can still inform the user (if deemed helpful) based on the return code. Link: https://lore.kernel.org/r/be1ed3a2-98b9-ee1d-20b8-477f3d93961d@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-08PCI: Remove unused HAVE_PCI_SET_MWIHeiner Kallweit
Remove unused HAVE_PCI_SET_MWI. Link: https://lore.kernel.org/r/03f20cac-708d-7897-c7c7-cb4e63cfd991@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-08[regression fix] really dumb fuckup in sparc64 __csum_partial_copy() changesAl Viro
~0U is -1, not 1 Reported-by: Anatoly Pugachev <matorola@gmail.com> Tested-by: Anatoly Pugachev <matorola@gmail.com> Fixes: fdf8bee96f9a "sparc64: propagate the calling convention changes down to __csum_partial_copy_...()" X-brown-paperbag: yes Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2020-12-08netfilter: nftables: comment indirect serialization of commit_mutex with ↵Pablo Neira Ayuso
rtnl_mutex Add an explicit comment in the code to describe the indirect serialization of the holders of the commit_mutex with the rtnl_mutex. Commit 90d2723c6d4c ("netfilter: nf_tables: do not hold reference on netdevice from preparation phase") already describes this, but a comment in this case is better for reference. Reported-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-12-08Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds
Pull seq_file fix from Al Viro: "This fixes a regression introduced in this cycle wrt iov_iter based variant for reading a seq_file" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fix return values of seq_read_iter()
2020-12-08thermal: rcar_gen3_thermal: Add r8a779a0 supportNiklas Söderlund
Add support for R-Car V3U. The new THCODE values are taken from the example in the datasheet. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126223028.3119044-4-niklas.soderlund+renesas@ragnatech.se
2020-12-08dt-bindings: thermal: rcar-gen3-thermal: Add r8a779a0 supportNiklas Söderlund
Add support for R-Car V3U. The V3U IP differs a bit from its siblings in such way that it have 4 TSC nodes and the interrupts are not routed to the INTC-AP but to the ECM. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201126223028.3119044-2-niklas.soderlund+renesas@ragnatech.se
2020-12-08Merge branch 'net-hns3-updates-for-next'Jakub Kicinski
Huazhong Tan says: ==================== net: hns3: updates for -next There are some updates for the HNS3 ethernet driver. promiscuous configuration more flexible, #2 adds ethtool private flags to control whether enable tx unicast promisc. previous version: https://patchwork.kernel.org/project/netdevbpf/cover/1606997936-22166-1-git-send-email-tanhuazhong@huawei.com/ ==================== Link: https://lore.kernel.org/r/1607227575-56689-1-git-send-email-tanhuazhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-08net: hns3: refine the VLAN tag handle for port based VLANGuojia Liao
For DEVICE_VERSION_V2, the hardware only supports max two layer VLAN tags, including port based tag inserted by hardware, tag in tx buffer descriptor(get from skb->tci) and tag in packet. For transmit packet: If port based VLAN disabled, and vf driver gets a VLAN tag from skb, the VLAN tag must be filled to the Outer_VLAN_TAG field (tag near to DMAC) of tx buffer descriptor, otherwise it may be inserted after the tag in packet. If port based VLAN enabled, and vf driver gets a VLAN tag from skb, the VLAN tag must be filled to the VLAN_TAG field (tag far to DMAC) of tx buffer descriptor, otherwise it may be conflicted with port based VLAN, and raise a hardware error. For receive packet: The hardware will strip the VLAN tags and fill them in the rx buffer descriptor, no matter port based VLAN enable or not. Because port based VLAN tag is useless for stack, so vf driver needs to discard the port based VLAN tag get from rx buffer descriptor when port based VLAN enabled. So vf must know about the port based VLAN state. For DEVICE_VERSION_V3, the hardware provides some new configuration to improve it. For transmit packet: When enable tag shift mode, hardware will handle the VLAN tag in outer_VLAN_TAG field as VLAN_TAG, so it won't conflict with port based VLAN. And hardware also make sure the tag before the tag in packet. So vf driver doesn't need to specify the tag position according to the port based VLAN state anymore. For receive packet: When enable discard mode, hardware will strip and discard the port based VLAN tag, so vf driver doesn't need to identify it from rx buffer descriptor. So modify the port based VLAN configuration, simplify the process for vf handling the VLAN tag. Signed-off-by: Guojia Liao <liaoguojia@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-08net: hns3: add priv flags support to switch limit promisc modeJian Shen
Currently, the tx unicast promisc is always enabled when promisc mode on. If tx unicast promisc on, a function will receive all unicast packet from other functions belong to the same port. Add a ethtool private flag to control whether enable tx unicast promisc. Then the function is able to filter the unknown unicast packets from other function. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-08net: hns3: add support for extended promiscuous commandGuojia Liao
For DEVICE_VERSION_V2, the hardware supports enable tx and rx promiscuous separately. But tx or rx promiscuous is active for unicast, multicast and broadcast promiscuous simultaneously. To support traffics between functions belong to the same port, we always enable tx promiscuous for broadcast promiscuous, so tx promiscuous for unicast and multicast promiscuous is also enabled. For DEVICE_VERSION_V3, the hardware decouples the above relationship. Tx unicast promiscuous, rx unicast promiscuous, tx multicast promiscuous, rx multicast promiscuous, tx broadcast promiscuous and rx broadcast promiscuous can be enabled separately. So add support for the new promiscuous command. Signed-off-by: Guojia Liao <liaoguojia@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-08netfilter: nft_dynset: fix timeouts later than 23 daysPablo Neira Ayuso
Use nf_msecs_to_jiffies64 and nf_jiffies64_to_msecs as provided by 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger than 23 days"), otherwise ruleset listing breaks. Fixes: a8b1e36d0d1d ("netfilter: nft_dynset: fix element timeout for HZ != 1000") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2020-12-08net/mlx5e: Fill mlx5e_create_cq_param in a functionMaxim Mikityanskiy
Create a function to fill the fields of struct mlx5e_create_cq_param based on a channel. The purpose is code reuse between normal CQs, XSK CQs and the upcoming QoS CQs. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Split between RX/TX tunnel FW support indicationAya Levin
Use the new FW caps to advertise for ip-in-ip tunnel support separately for RX and TX. Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5: Fix passing zero to 'PTR_ERR'YueHaibing
Fix smatch warnings: drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c:105 esw_acl_egress_lgcy_setup() warn: passing zero to 'PTR_ERR' drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_ofld.c:177 esw_acl_egress_ofld_setup() warn: passing zero to 'PTR_ERR' drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_lgcy.c:184 esw_acl_ingress_lgcy_setup() warn: passing zero to 'PTR_ERR' drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_ofld.c:262 esw_acl_ingress_ofld_setup() warn: passing zero to 'PTR_ERR' esw_acl_table_create() never returns NULL, so NULL test should be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5: Arm only EQs with EQEsShay Drory
Currently, when more than one EQ is sharing an IRQ, and this IRQ is being interrupted, all the EQs sharing the IRQ will be armed. This is done regardless of whether an EQ has EQE. When multiple EQs are sharing an IRQ, one or more EQs can have valid EQEs. Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Remove duplicated includeYueHaibing
Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: remove unnecessary memsetZhu Yanjun
Since kvzalloc will initialize the allocated memory, it is not necessary to initialize it once again. Fixes: 11b717d61526 ("net/mlx5: E-Switch, Get reg_c0 value on CQE") Signed-off-by: Zhu Yanjun <yanjunz@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Add TX port timestamp supportEran Ben Elisha
Transmitted packet timestamping accuracy can be improved when using timestamp from the port, instead of packet CQE creation timestamp, as it better reflects the actual time of a packet's transmit. TX port timestamping is supported starting from ConnectX6-DX hardware. Although at the original completion, only CQE timestamp can be attached, we are able to get TX port timestamping via an additional completion over a special CQ associated with the SQ (in addition to the regular CQ). Driver to ignore the original packet completion timestamp, and report back the timestamp of the special CQ completion. If the absolute timestamp diff between the two completions is greater than 1 / 128 second, ignore the TX port timestamp as it has a jitter which is too big. No skb will be generate out of the extra completion. Allocate additional CQ per ptpsq, to receive the TX port timestamp. Driver to hold an skb FIFO in order to map between transmitted skb to the two expected completions. When using ptpsq, hold double refcount on the skb, to gaurantee it will not get released before both completions arrive. Expose dedicated counters of the ptp additional CQ and connect it to the TX health reporter. This patch improves TX Hardware timestamping offset to be less than 40ns at a 100Gbps line rate, compared to 600ns before. With that, making our HW compliant with G.8273.2 class C, and allow Linux systems to be deployed in the 5G telco edge, where this standard is a must. Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Add TX PTP port object supportEran Ben Elisha
Add TX PTP port object support for better TX timestamping accuracy. Currently, driver supports CQE based TX port timestamp. Device also offers TX port timestamp, which has less jitter and better reflects the actual time of a packet's transmit. Define new driver layout called ptpsq, on which driver will create SQs that will support TX port timestamp for their transmitted packets. Driver to identify PTP TX skbs and steer them to these dedicated SQs as part of the select queue ndo. Driver to hold ptpsq per TC and report them at netif_set_real_num_tx_queues(). Add support for all needed functionality in order to xmit and poll completions received via ptpsq. Add ptpsq to the TX reporter recover, diagnose and dump methods. Creation of ptpsqs is disabled by default, and can be enabled via tx_port_ts private flag. This patch steer all timestamp related packets to a ptpsq, but it does not open the port timestamp support for it. The support will be added in the following patch. Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Move MLX5E_RX_ERR_CQE macroEran Ben Elisha
MLX5E_RX_ERR_CQE Macro is used only in data-path, move it to the appropriate header file. Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Split SW group counters update functionEran Ben Elisha
SW group counter update function aggregates sw stats out of many mlx5e_*_stats resides in a given mlx5e_channel_stats struct. Split the function into a few helper functions. This will be used later in the series to calculate specific mlx5e_*_stats which are not defined inside mlx5e_channel_stats. Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Change skb fifo push/pop API to be used without SQEran Ben Elisha
The skb fifo push/pop API used pre-defined attributes within the mlx5e_txqsq. In order to share the skb fifo API with other non-SQ use cases, change the API input to get newly defined mlx5e_skb_fifo struct. Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Allow SQ outside of channel contextEran Ben Elisha
In order to be able to create an SQ outside of a channel context, remove sq->channel direct pointer. This requires adding a direct pointer to: netdevice, priv and mlx5_core in order to support SQs that are part of mlx5e_channel. Use channel_stats from the corresponding CQ. Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Allow RQ outside of channel contextAya Levin
In order to be able to create an RQ outside of a channel context, remove rq->channel direct pointer. This requires adding a direct pointer to: ICOSQ and priv in order to support RQs that are part of mlx5e_channel. Use channel_stats from the corresponding CQ. Signed-off-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Allow CQ outside of channel contextAya Levin
In order to be able to create a CQ outside of a channel context, remove cq->channel direct pointer. This requires adding a direct pointer to channel statistics, netdevice, priv and to mlx5_core in order to support CQs that are a part of mlx5e_channel. In addition, parameters the were previously derived from the channel like napi, NUMA node, channel stats and index are now assembled in struct mlx5e_create_cq_param which is given to mlx5e_open_cq() instead of channel pointer. Generalizing mlx5e_open_cq() allows opening CQ outside of channel context which will be used in following patches in the patch-set. Signed-off-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Eran Ben Elisha <eranbe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08net/mlx5e: Free drop RQ in a dedicated functionTariq Toukan
The drop RQ has very limited objects to be freed, and differs from regular RQs in the context that it is freed from. Add a dedicated function for it, use it where needed, and remove the drop_rq-specific checks in the generic function. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-12-08bonding: fix feature flag setting at init timeJarod Wilson
Don't try to adjust XFRM support flags if the bond device isn't yet registered. Bad things can currently happen when netdev_change_features() is called without having wanted_features fully filled in yet. This code runs both on post-module-load mode changes, as well as at module init time, and when run at module init time, it is before register_netdevice() has been called and filled in wanted_features. The empty wanted_features led to features also getting emptied out, which was definitely not the intended behavior, so prevent that from happening. Originally, I'd hoped to stop adjusting wanted_features at all in the bonding driver, as it's documented as being something only the network core should touch, but we actually do need to do this to properly update both the features and wanted_features fields when changing the bond type, or we get to a situation where ethtool sees: esp-hw-offload: off [requested on] I do think we should be using netdev_update_features instead of netdev_change_features here though, so we only send notifiers when the features actually changed. Fixes: a3b658cfb664 ("bonding: allow xfrm offload setup post-module-load") Reported-by: Ivan Vecera <ivecera@redhat.com> Suggested-by: Ivan Vecera <ivecera@redhat.com> Cc: Jay Vosburgh <j.vosburgh@gmail.com> Cc: Veaceslav Falico <vfalico@gmail.com> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Jarod Wilson <jarod@redhat.com> Link: https://lore.kernel.org/r/20201205172229.576587-1-jarod@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-08net: dsa: print the MTU value that could not be setRasmus Villemoes
These warnings become somewhat more informative when they include the MTU value that could not be set and not just the errno. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Link: https://lore.kernel.org/r/20201205133944.10182-1-rasmus.villemoes@prevas.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-12-08ALSA: hda/proc - print DP-MST connectionsKai Vehmanen
To help in debugging issues with DisplayPort Multi-Stream Transport (aka DP-MST) support, print information of active connections for each device of a display audio pin widget. Example output with the patch with two monitors connected to a DP-MST hub: Devices: 4 Dev 00: PD = 0, ELDV = 0, IA = 0, Connections [ 0x03* 0x05 0x07 0x09 ] Dev 01: PD = 1, ELDV = 1, IA = 0, Connections [ 0x03* 0x05 0x07 0x09 ] *Dev 02: PD = 1, ELDV = 1, IA = 0, Connections [ 0x03 0x05* 0x07 0x09 ] Dev 03: PD = 0, ELDV = 0, IA = 0, Connections [ 0x03* 0x05 0x07 0x09 ] Connection: 4 0x03 0x05* 0x07 0x09 Format of existing "Connection:" entry is left intact to keep compatibility. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20201208185736.2877541-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-12-08coresight: etm4x: Modify core-commit to avoid HiSilicon ETM overflowQi Liu
The ETM device can't keep up with the core pipeline when cpu core is at full speed. This may cause overflow within core and its ETM. This is a common phenomenon on ETM devices. On HiSilicon Hip08 platform, a specific feature is added to set core pipeline. So commit rate can be reduced manually to avoid ETM overflow. Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Qi Liu <liuqi115@huawei.com> [Modified changelog title and Kconfig description] Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208182651.1597945-4-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-08coresight: remove broken __exit annotationsArnd Bergmann
Functions that are annotated __exit are discarded for built-in drivers, but the .remove callback in a device driver must still be kept around to allow bind/unbind operations. There is now a linker warning for the discarded symbol references: `tmc_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-tmc-core.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-tmc-core.o `tpiu_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-tpiu.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-tpiu.o `etb_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-etb10.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-etb10.o `static_funnel_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-funnel.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-funnel.o `dynamic_funnel_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-funnel.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-funnel.o `static_replicator_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-replicator.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-replicator.o `dynamic_replicator_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-replicator.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-replicator.o `catu_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-catu.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-catu.o Remove all those annotations. Fixes: 8b0cf82677d1 ("coresight: stm: Allow to build coresight-stm as a module") Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208182651.1597945-3-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-08coresight: tmc-etr: Fix barrier packet insertion for perf bufferSuzuki K Poulose
When the ETR is used in perf mode with a larger buffer (configured via sysfs or the default size of 1M) than the perf aux buffer size, we end up inserting the barrier packet at the wrong offset, while moving the offset forward. i.e, instead of the "new moved offset", we insert it at the current hardware buffer offset. These packets will not be visible as they are never copied and could lead to corruption in the trace decoding side, as the decoder is not aware that it needs to reset the decoding. Fixes: ec13c78d7b45 ("coresight: tmc-etr: Add barrier packets when moving offset forward") Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: stable@vger.kernel.org Reported-by: Al Grant <al.grant@arm.com> Tested-by: Mike Leach <mike.leach@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208182651.1597945-2-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-08USB: legotower: fix logical error in recent commitAlan Stern
Commit d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()") contained an elementary logical error. The check of the return code from the new usb_control_msg_recv() function was inverted. Reported-and-tested-by: syzbot+9be25235b7a69b24d117@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20201208163042.GD1298255@rowland.harvard.edu Fixes: d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()") Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-08ACPI: scan: Fix up _DEP-related terminology with supplier/consumerRafael J. Wysocki
The ACPI namespace scanning code uses the terms master/slave when populating the list of _DEP dependencies, but that use has no external exposures and is not mandated by nor associated with any external specifications. Change the language used through-out to supplier/consumer. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2020-12-08ACPI: scan: Drop INT3396 from acpi_ignore_dep_ids[]Rafael J. Wysocki
According to Hans, all device objects where the _HID returns "INT3396" also have a _CID returning "PNP0D80", so the former need not be present in acpi_ignore_dep_ids[] any more. Link: https://lore.kernel.org/linux-acpi/52a2b98c-6bf3-760b-eca9-93cf05fb4877@redhat.com/ Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com>
2020-12-08docs: Update documentation to reflect what TAINT_CPU_OUT_OF_SPEC meansMathieu Chouquet-Stringer
Here's a patch updating the meaning of TAINT_CPU_OUT_OF_SPEC after Borislav introduced changes in a7e1f67ed29f and upcoming patches in tip. TAINT_CPU_OUT_OF_SPEC now means a bit more what it implies as the flag isn't set just because of a CPU misconfiguration or mismatch. Historically it was for SMP kernel oops on an officially SMP incapable processor but now it also covers CPUs whose MSRs have been incorrectly poked at from userspace, drivers being used on non supported architectures, broken firmware, mismatched CPUs, ... Update documentation and script to reflect that. Signed-off-by: Mathieu Chouquet-Stringer <me@mathieu.digital> Link: https://lore.kernel.org/r/20201202153244.709752-1-me@mathieu.digital Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08docs: add a reset controller chapter to the driver API docsPhilipp Zabel
Add initial reset controller API documentation. This is mostly intended to describe the concepts to users of the consumer API, and to tie the kerneldoc comments we already have into the driver API documentation. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Amjad Ouled-Ameur <aouledameur@baylibre.fr> Link: https://lore.kernel.org/r/20201201115754.1713-1-p.zabel@pengutronix.de Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08x86/cpu/amd: Remove dead code for TSEG region remappingArvind Sankar
Commit 26bfa5f89486 ("x86, amd: Cleanup init_amd") moved the code that remaps the TSEG region using 4k pages from init_amd() to bsp_init_amd(). However, bsp_init_amd() is executed well before the direct mapping is actually created: setup_arch() -> early_cpu_init() -> early_identify_cpu() -> this_cpu->c_bsp_init() -> bsp_init_amd() ... -> init_mem_mapping() So the change effectively disabled the 4k remapping, because pfn_range_is_mapped() is always false at this point. It has been over six years since the commit, and no-one seems to have noticed this, so just remove the code. The original code was also incomplete, since it doesn't check how large the TSEG address range actually is, so it might remap only part of it in any case. Hygon has copied the incorrect version, so the code has never run on it since the cpu support was added two years ago. Remove it from there as well. Committer notes: This workaround is incomplete anyway: 1. The code must check MSRC001_0113.TValid (SMM TSeg Mask MSR) first, to check whether the TSeg address range is enabled. 2. The code must check whether the range is not 2M aligned - if it is, there's nothing to work around. 3. In all the BIOSes tested, the TSeg range is in a e820 reserved area and those are not mapped anymore, after 66520ebc2df3 ("x86, mm: Only direct map addresses that are marked as E820_RAM") which means, there's nothing to be worked around either. So let's rip it out. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201127171324.1846019-1-nivedita@alum.mit.edu
2020-12-08docs: make reporting-bugs.rst obsoleteThorsten Leemhuis
Make various places which point to Documentation/admin-guide/reporting-bugs.rst point to Documentation/admin-guide/reporting-issues.rst instead. That document is brand new and as of now is not completely finished. But even at this stage it's a lot more helpful and accurate than reporting-bugs.rst. Hence also add a note to reporting-bugs.rst, telling people they're better off reading reporting-issues.rst instead. reporting-bugs.rst is scheduled for removal once reporting-issues.rst is considered ready. Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Link: https://lore.kernel.org/r/3df7c2d16de112b47bb6e6158138608e78562bf5.1607063223.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08docs: Add a new text describing how to report bugsThorsten Leemhuis
Add a mostly finished document describing how to report issues with the Linux kernel to its developers. It is designed to be a lot more straight forward and easier to follow than the current text about this (Documentation/admin-guide/reporting-bugs.rst); at the same time the new text should be more helpful for people unfamiliar with the topic, as it provides a lot more details, too. The main work on the text is done, but some polishing is still needed. The text also needs to be reviewed by more people and a few issues still might need some discussion. To make these tasks easier, it was decided ([1]) to add this document to the kernel sources in parallel to the existing text; the latter will be removed once this text is considered good enough(tm). This document is quite long and provides a lot of details, but was carefully crafted to make sure it's can also serve people that are in a hurry. That's mainly achieved by having a TDLR and a step-by-step guide, which should be good enough for quite a lot of people. Everybody that wants or need more explanations can find them in a reference section, which describes all the needed steps in detail. Thanks to this structure the text can work for kernel developers that just need to look something up, experienced FLOSS contributors that are unfamiliar with the kernel's bug reporting workflow, and users reporting something upstream for the first time. The text is thus a bit like the kernel itself, which works well for embedded machines, a typical desktop PC, cloud servers, and HPC. The document was written in the hope it will improve the quality of the bug reports, especially those that come from people unfamiliar with how Linux kernel development works. Sadly quite a few reports from this group are currently of poor quality and/or get submitted to the wrong place. Part of the problem is the old reporting-bugs document, as it makes its essence hard to grasp; it's and also inaccurate and slightly outdated in a few spots. Due to this quite a few valid reports are ignored in the end, which is annoying for those that compiled them and bad for the kernel's quality. The document near the top points out that it's still unfinished, but nevertheless ready for consumption. Those few areas in the text that might need some further discussion contain a note pointing this out. Besides lack of review from core developers there is only one major issue left: the section 'Decode failure message' is known to be outdated: it's waiting for someone familiar with the topic to write something up or give at least provide some hints and pointers what to write there. The new document is dual-licensed under GPL-2.0+ or CC-BY-4.0. The latter is way more liberal and makes it attractive to use this text as a base when writing about this topic on websites or in books. This hopefully increases the chances that such texts are accurate and stick to official way of doing things. [1] https://lkml.kernel.org/r/20201118172958.5b014a44@lwn.net Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> CC: Thomas Gleixner <tglx@linutronix.de> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/e2db808f954744b79f10937a923d9c99bdca1fca.1607063223.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08LICENSES: Add the CC-BY-4.0 licenseThorsten Leemhuis
Add the full text of the CC-BY-4.0 license to the kernel tree as well as the required tags for reference and tooling. The license text was copied directly from the following url, but for clarification a 'Creative Commons' was added before 'Attribution 4.0 International' in the first line: https://creativecommons.org/licenses/by/4.0/legalcode.txt CC-BY-4.0 is GPLv2 compatible, but when for example used for the kernel's documentation it can easily happen that sphinx during processing combines it with text or code from files using a more restrictive license[1]. This bears pitfalls, hence point that risk out and suggest to only use this license in combination with the GPLv2. [1] https://lkml.kernel.org/r/20201201144314.GA14256@lst.de Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Thomas Gleixner <tglx@linutronix.de> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/7115b6c20ae3e6db0370fe4002dd586011205e1c.1607063223.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08Documentation: fix multiple typos found in the admin-guide subdirectoryAndrew Klychkov
Fix thirty five typos in dm-integrity.rst, dm-raid.rst, dm-zoned.rst, verity.rst, writecache.rst, tsx_async_abort.rst, md.rst, bttv.rst, dvb_references.rst, frontend-cardlist.rst, gspca-cardlist.rst, ipu3.rst, remote-controller.rst, mm/index.rst, numaperf.rst, userfaultfd.rst, module-signing.rst, imx-ddr.rst, intel-speed-select.rst, intel_pstate.rst, ramoops.rst, abi.rst, kernel.rst, vm.rst Signed-off-by: Andrew Klychkov <andrew.a.klychkov@gmail.com> Link: https://lore.kernel.org/r/20201204072848.GA49895@spblnx124.lan Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08Documentation: fix typos found in admin-guide subdirectoryAndrew Klychkov
Fixed twelve typos in cppc_sysfs.rst, binderfs.rst, paride.rst, zram.rst, bug-hunting.rst, introduction.rst, usage.rst, dm-crypt.rst Signed-off-by: Andrew Klychkov <andrew.a.klychkov@gmail.com> Reviewed-by: Jonathan Corbet <corbet@lwn.net> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20201204070235.GA48631@spblnx124.lan Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08kernel-doc: Fix example in Nested structs/unionsBen Widawsky
Add missing ';' as well as fixes the indent for the first struct. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Link: https://lore.kernel.org/r/20201207210027.1049346-1-ben.widawsky@intel.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08docs: clean up sysctl/kernel: titles, versionStephen Kitt
This cleans up a few titles with extra colons, and removes the reference to kernel 2.2. The docs don't yet cover *all* of 5.10 or 5.11, but I think they're close enough. Most entries are documented, and have been checked against current kernels. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20201208074922.30359-1-steve@sk2.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08PM / EM: Micro optimization in em_cpu_energyPavankumar Kondeti
When the sum of the utilization of CPUs in a power domain is zero, return the energy as 0 without doing any computations. Acked-by: Quentin Perret <qperret@google.com> Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-08docs: trace: fix event state structure nameArtem Bityutskiy
The documentation refers to a non-existent 'struct synth_trace_state' structure. The correct name is 'struct synth_event_trace_state'. In other words, this patch is a mechanical substitution: s/synth_trace_state/synth_event_trace_state/g Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Reviewed-by: Tom Zanussi <zanussi@kernel.org> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20201104122113.322452-1-dedekind1@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2020-12-08Merge series "regulator: da9121: bug fixes" from Adam Ward ↵Mark Brown
<Adam.Ward.opensource@diasemi.com>: This patch fixes a couple of bugs in the DA9121 driver. One in an uninialised string I forgot to remove when changing to of_parse_cb() The other is an index for an optional DT property which overflows Adam Ward (2): regulator: da9121: Remove uninitialised string variable regulator: da9121: Fix index used for DT property drivers/regulator/da9121-regulator.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.9.1
2020-12-08Merge series "ASoC: Intel: cht_bsw_nau8824: 2 fixes for usage with ↵Mark Brown
sof-audio-acpi" from Hans de Goede <hdegoede@redhat.com>: Hi All, Here are 2 simple fixes which are necessary to make the cht_bsw_nau8824 machine driver work together with the sof-audio-acpi driver. Note that atm the sof topology files are missing a .tplg file for this setup. Simply copying over the standard sof-byte-codec.tplg file does the trick, but then some mixer setting changes are necessary to fix the right speaker/headphones channel not working; and those mixer settings break the right channel when used with the sst-acpi driver. I've been trying to fix this at the tplg level so that we do not need to change the mixer settings, but no luck sofar. I'll post a RFC with the topology changes which I have and we can discuss this further there. These 2 simple fixes are necessary to make the sof-audio-acpi driver work regardless of the topology issue. Regards, Hans