There are sleep in atomic context bugs when the request to secure
element of st21nfca is timeout. The root cause is that kzalloc and
alloc_skb with GFP_KERNEL parameter and mutex_lock are called in
st21nfca_se_wt_timeout which is a timer handler. The call tree shows
the execution paths that could lead to bugs:
(Interrupt context)
st21nfca_se_wt_timeout
nfc_hci_send_event
nfc_hci_hcp_message_tx
kzalloc(..., GFP_KERNEL) //may sleep
alloc_skb(..., GFP_KERNEL) //may sleep
mutex_lock() //may sleep
This patch moves the operations that may sleep into a work item.
The work item will run in another kernel thread which is in
process context to execute the bottom half of the interrupt.
So it could prevent atomic context from sleeping.
Fixes: 2130fb97fe ("NFC: st21nfca: Adding support for secure element")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220518115733.62111-1-duoming@zju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The netif_receive_skb() function frees "skb" so store skb->len before
it is freed.
Fixes: fd3040b939 ("net: ethernet: Add driver for Sunplus SP7021")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YoUuy4iTjFAcSn03@kili
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Describe it in admin-guide/sysctl/net.rst like other Network core options.
Users need to know gro_normal_batch for performance tuning.
Fixes: 323ebb61e3 ("net: use listified RX for handling GRO_NORMAL skbs")
Reported-by: Prijesh Patel <prpatel@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://lore.kernel.org/r/acf8a2c03b91bcde11f67ff89b6050089c0712a3.1652888963.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Split the drivers/scsi/ufs directory into 'core' and 'host' directories
under the drivers/ufs/ directory. Move shared header files into the
include/ufs/ directory. This separation makes it clear which header files
UFS drivers are allowed to include (include/ufs/*.h) and which header files
UFS drivers are not allowed to include (drivers/ufs/core/*.h).
Update the MAINTAINERS file. Add myself as a UFS reviewer.
Link: https://lore.kernel.org/r/20220511212552.655341-1-bvanassche@acm.org
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Avri Altman <avri.altman@wdc.com>
Cc: Bean Huo <beanhuo@micron.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Keoseong Park <keosung.park@samsung.com>
Tested-by: Bean Huo <beanhuo@micron.com>
Tested-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Variable toke is being assigned a value that is never read. The variable is
redundant, remove it.
Cleans up clang scan build warning:
warning: Although the value stored to 'toke' is used in the enclosing
expression, the value is never actually read from 'toke'
[deadcode.DeadStores]
Link: https://lore.kernel.org/r/20220518102103.514701-1-colin.i.king@gmail.com
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Modify the NVMe I/O path to look for VMID support and call the transport to
obtain the I/O's appid value.
Link: https://lore.kernel.org/r/20220519123110.17361-5-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Co-developed-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com>
Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Rework lpfc_vmid_get_appid() arguments to remove scsi_cmnd dependency. The
function is now callable by the NVMe I/O path. Fix up SCSI call path to
accommodate the arg change.
Link: https://lore.kernel.org/r/20220519123110.17361-4-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Co-developed-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com>
Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove VMID code from its SCSI-specific location and move to a new file
solely for VMID code.
Link: https://lore.kernel.org/r/20220519123110.17361-3-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Co-developed-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com>
Signed-off-by: Gaurav Srivastava <gaurav.srivastava@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add nvme_fc_io_getuuid() to the nvme-fc transport. The routine is invoked
by the FC LLDD on a per-I/O request basis. The routine translates from the
FC-specific request structure to the bio and the cgroup structure in order
to obtain the FC appid stored in the cgroup structure. If a value is not
set or a bio is not found, a NULL appid (aka uuid) will be returned to the
LLDD.
Link: https://lore.kernel.org/r/20220519123110.17361-2-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In f2fs_read_inline_data(), it is confused with checking of
inline_data flag, as we checked it before calling. So this
patch add some comments for f2fs_has_inline_data().
Signed-off-by: Chao Liu <liuchao@coolpad.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
When doing DP AUX transfers there are two actors that need to be
powered in order for the DP AUX transfer to work: the DP source and
the DP sink. Commit bacbab58f0 ("drm: Mention the power state
requirement on side-channel operations") added some documentation
saying that the DP source is required to power itself up (if needed)
to do AUX transfers. However, that commit doesn't talk anything about
the DP sink.
For full fledged DP the sink isn't really a problem. It's expected
that if an external DP monitor isn't plugged in that attempting to do
AUX transfers won't work. It's also expected that if a DP monitor is
plugged in (and thus asserting HPD) then AUX transfers will work.
When we're looking at eDP, however, things are less obvious. Let's add
some documentation about expectations. Here's what we'll say:
1. We don't expect the DP AUX transfer function to power on an eDP
panel. If an eDP panel is physically connected but powered off then it
makes sense for the transfer to fail.
2. We'll document that the official way to power on a panel is via the
bridge chain, specifically by making sure that the panel's prepare
function has been called (which is called by
panel_bridge_pre_enable()). It's already specified in the kernel doc
of drm_panel_prepare() that this is the way to power the panel on and
also that after this call "it is possible to communicate with any
integrated circuitry via a command bus."
3. We'll also document that for code running in the panel driver
itself that it is legal for the panel driver to power itself up
however it wants (it doesn't need to officially call
drm_panel_pre_enable()) and then it can do AUX bus transfers. This is
currently the way that edp-panel works when it's running atop the DP
AUX bus.
NOTE: there was much discussion of all of this in response to v1 [1]
of this patch. A summary of that is:
* With the Intel i195 driver, apparently eDP panels do get powered
up. We won't forbid this but it is expected that code that wants to
run on a variety of platforms should ensure that the drm_panel's
prepare() function has been called.
* There is at least a reasonable amount of agreement that the
transfer() functions itself shouldn't be responsible for powering
the panel. It's proposed that if we need the DP AUX dev nodes to be
robust for eDP that the code handling the DP AUX dev nodes could
handle powering the panel by ensuring that the panel's prepare()
call was made. Potentially drm_dp_aux_dev_get_by_minor() could be a
good place to do this. This is left as a future exercise. Until
that's fixed the DP AUX dev nodes for eDP are probably best just
used for debugging.
* If a panel could be in PSR and DP AUX via the dev node needs to be
reliable then we need to be able to pull the panel out of PSR. On
i915 this is also apparently handled as part of the transfer()
function.
[1] https://lore.kernel.org/r/20220503162033.1.Ia8651894026707e4fa61267da944ff739610d180@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220509161733.v2.1.Ia8651894026707e4fa61267da944ff739610d180@changeid
Lenovo Thunderbolt 4 Dock, and other Lenovo USB Docks are using the
original Realtek USB ethernet Vendor and Product IDs
If the Network device is Realtek verify that it is on a Lenovo USB hub
before enabling the passthru feature
This also adds in the device IDs for the Lenovo USB Dongle and one other
USB-C dock
V2 fix formating of code
V3 remove Generic define for Device ID 0x8153 and change it to use value
V4 rearrange defines and case statement to put them in better order
v5 create helper function to do the testing work as suggested
Signed-off-by: David Ober <dober6023@gmail.com>
Link: https://lore.kernel.org/r/20220517180539.25839-1-dober6023@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As per Displayport spec section 5.2.1.2 ("Video Timing Format") says
that all detachable sinks shall support 640x480 @60Hz as a fail safe
mode.
A DP compliance test expected us to utilize the above fact when all
modes it presented to the DP source were not achievable. It presented
only modes that would be achievable with more lanes and/or higher
speeds than we had available and expected that when we couldn't do
that then we'd fall back to 640x480 even though it didn't advertise
this size.
In order to pass the compliance test (and also support any users who
might fall into a similar situation with their display), we need to
add 640x480 into the list of modes. However, we don't want to add
640x480 all the time. Despite the fact that the DP spec says all sinks
_shall support_ 640x480, they're not guaranteed to support it
_well_. Continuing to read the spec you can see that the display is
not required to really treat 640x480 equal to all the other modes. It
doesn't need to scale or anything--just display the pixels somehow for
failsafe purposes. It should also be noted that it's not hard to find
a display hooked up via DisplayPort that _doesn't_ support 640x480 at
all. The HP ZR30w screen I'm sitting in front of has a native DP port
and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI
display via a DP to HDMI adapter and that screen definitely doesn't
support 640x480.
As a compromise solution, let's only add the 640x480 mode if:
* We're on DP.
* All other modes have been pruned.
This acknowledges that 640x480 might not be the best mode to use but,
since sinks are _supposed_ to support it, we will at least fall back
to it if there's nothing else.
Note that we _don't_ add higher resolution modes like 1024x768 in this
case. We only add those modes for a failed EDID read where we have no
idea what's going on. In the case where we've pruned all modes then
instead we only want 640x480 which is the only defined "Fail Safe"
resolution.
This patch originated in response to Kuogee Hsieh's patch [1].
[1] https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khsieh@quicinc.com
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511155749.v3.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid
The drm_helper_probe_single_connector_modes() is a bit long. Let's
break a chunk off to update and validate modes. This helps avoid one
goto and also will allow us to more easily call the helper a second
time in a future patch without adding looping or another goto.
This change is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511155749.v3.1.I2dd93486c6952bd52f2020904de0133970d11b29@changeid
In tcmu_blocks_release(), lock_page() is called to prevent a race causing
possible data corruption. Since lock_page() might sleep, calling it while
holding XArray lock is a bug.
To fix this, replace the xas_for_each() call with xa_for_each_range().
Since the latter does its own handling of XArray locking, the xas_lock()
and xas_unlock() calls around the original loop are no longer necessary.
The switch to xa_for_each_range() slows down the loop slightly. This is
acceptable since tcmu_blocks_release() is not relevant for performance.
Link: https://lore.kernel.org/r/20220517192913.21405-1-bostroesser@gmail.com
Fixes: bb9b9eb0ae ("scsi: target: tcmu: Fix possible data corruption")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bodo Stroesser <bostroesser@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
adpt_post_wait_lock was declared and initialized by DEFINE_SPINLOCK so we
don't need to call spin_lock_init(). Drop the call.
Link: https://lore.kernel.org/r/1652176024-3981-1-git-send-email-baihaowen@meizu.com
Signed-off-by: Haowen Bai <baihaowen@meizu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The variable 'op' is assigned a value and is never read. The variable is
not used and is redundant, remove it.
Link: https://lore.kernel.org/r/20220517092518.93159-1-colin.i.king@gmail.com
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The memories for the slot should be observed to be written prior to
observing the slot as ready.
Prior to commit 26fc0ea74f ("scsi: libsas: Drop SAS_TASK_AT_INITIATOR"),
we had a spin_lock() + spin_unlock() immediately before marking the slot as
ready. The spin_unlock() - with release semantics - caused the slot memory
to be observed to be written.
Now that the spin_lock() + spin_unlock() is gone, use a smp_wmb().
Link: https://lore.kernel.org/r/1652774661-12935-1-git-send-email-john.garry@huawei.com
Fixes: 26fc0ea74f ("scsi: libsas: Drop SAS_TASK_AT_INITIATOR")
Reported-by: Yihang Li <liyihang6@hisilicon.com>
Tested-by: Yihang Li <liyihang6@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add sysfs attributes for exposing target device details such as SAS
address, firmware device handle, and persistent ID for the
controller-attached devices and RAID volumes.
Link: https://lore.kernel.org/r/20220517115310.13062-3-sreekanth.reddy@broadcom.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add shost related sysfs attributes to display the controller's firmware
version, queue depth, number of requests, and number of reply queues. Also
add an attribute to set & get the logging_level.
Link: https://lore.kernel.org/r/20220517115310.13062-2-sreekanth.reddy@broadcom.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
As memset() of bmbx is immediately followed by a memcpy() where bmbx is the
destination, the memset() is redundant.
Link: https://lore.kernel.org/r/20220505143703.45441-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
As memset() of scmd->sense_buffer is immediately followed by a memcpy()
where scmd->sense_buffer is the destination. The memset() is redundant.
Link: https://lore.kernel.org/r/20220505143214.44908-1-harshit.m.mogalapalli@oracle.com
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Return -ENOMEM instead of success if dma_alloc_coherent() fails.
Link: https://lore.kernel.org/r/YnOmMGHqCOtUCYQ1@kili
Fixes: 43ca110050 ("scsi: mpi3mr: Add support for PEL commands")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Removing an ATA device via sysfs means that the device may not be found
through re-scanning:
root@ubuntu:/home/john# lsscsi
[0:0:0:0] disk SanDisk LT0200MO P404 /dev/sda
[0:0:1:0] disk ATA HGST HUS724040AL A8B0 /dev/sdb
[0:0:8:0] enclosu 12G SAS Expander RevB -
root@ubuntu:/home/john# echo 1 > /sys/block/sdb/device/delete
root@ubuntu:/home/john# echo "- - -" > /sys/class/scsi_host/host0/scan
root@ubuntu:/home/john# lsscsi
[0:0:0:0] disk SanDisk LT0200MO P404 /dev/sda
[0:0:8:0] enclosu 12G SAS Expander RevB -
root@ubuntu:/home/john#
The problem is that the rescan of the device may conflict with the device
in being re-initialized, as follows:
- In the rescan we call hisi_sas_slave_alloc() in store_scan() ->
sas_user_scan() -> [__]scsi_scan_target() -> scsi_probe_and_add_lunc()
-> scsi_alloc_sdev() -> hisi_sas_slave_alloc() -> hisi_sas_init_device()
In hisi_sas_init_device() we issue an IT nexus reset for ATA devices
- That IT nexus causes the remote PHY to go down and this triggers a bcast
event
- In parallel libsas processes the bcast event, finds that the phy is down
and marks the device as gone
The hard reset issued in hisi_sas_init_device() is unncessary - as
described in the code comment - so remove it. Also set dev status as
HISI_SAS_DEV_NORMAL as the hisi_sas_init_device() call.
Link: https://lore.kernel.org/r/1652354134-171343-4-git-send-email-john.garry@huawei.com
Fixes: 36c6b7613e ("scsi: hisi_sas: Initialise devices in .slave_alloc callback")
Tested-by: Yihang Li <liyihang6@hisilicon.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We have seen errors like this when a SATA device is probed:
[524.566298] hisi_sas_v3_hw 0000L74:02.0: erroneous completion iptt=4096 ...
[524.582827] sas: TMF task open reject failed 500e004aaaaaaaa00
Since commit 21c7e97247 ("scsi: hisi_sas: Disable SATA disk phy for
severe I_T nexus reset failure"), we issue an ATA softreset to disks after
a phy reset to ensure that they are in sound working order. If the
softreset is issued before the remote phy has come back up then the
softreset will fail (errors as above). Remedy this by waiting for the phy
to come back up after the reset.
Link: https://lore.kernel.org/r/1652354134-171343-3-git-send-email-john.garry@huawei.com
Tested-by: Yihang Li <liyihang6@hisilicon.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Create function sas_ata_wait_after_reset() from sas_ata_hard_reset() as
some LLDDs may want to check for a remote ATA phy is up after reset.
Link: https://lore.kernel.org/r/1652354134-171343-2-git-send-email-john.garry@huawei.com
Tested-by: Yihang Li <liyihang6@hisilicon.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Terminate string after copying 16 bytes of ChipName data from Manufacturing
Page0 to prevent %s from printing junk characters.
Link: https://lore.kernel.org/r/20220511072621.30657-1-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
PTP one step sync packets cannot have CSUM padding and insertion in
SW since time stamp is inserted on the fly by HW.
In addition, ptp4l version 3.0 and above report an error when skb
timestamps are reported for packets that not processed for TX TS
after transmission.
Add a helper to identify PTP one step sync and fix the above two
errors. Add a common mask for PTP header flag field "twoStepflag".
Also reset ptp OSS bit when one step is not selected.
Fixes: ab91f0a9b5 ("net: macb: Add hardware PTP support")
Fixes: 653e92a917 ("net: macb: add support for padding and fcs computation")
Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20220518170756.7752-1-harini.katakam@xilinx.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As part of the effort to improve the MediaTek clk drivers, the next step
is to switch from the old 'struct clk' clk prodivder APIs to the new
'struct clk_hw' ones.
The MT8173 clk driver has one clk that is registered directly with the
clk provider APIs, instead of going through the MediaTek clk library.
Switch this instance to use the clk_hw provider API.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220519071610.423372-6-wenst@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
As part of the effort to improve the MediaTek clk drivers, the next step
is to switch from the old 'struct clk' clk prodivder APIs to the new
'struct clk_hw' ones.
In a previous patch, 'struct clk_onecell_data' was replaced with
'struct clk_hw_onecell_data', with (struct clk_hw *)->clk and
__clk_get_hw() bridging the new data structures and old code.
Now switch from the old 'clk_(un)?register*()' APIs to the new
'clk_hw_(un)?register*()' ones. This is done with the coccinelle script
below.
Unfortunately this also leaves clk-mt8173.c with a compile error that
would need a coccinelle script longer than the actual diff to fix. This
last part is fixed up by hand.
// Fix prototypes
@@
identifier F =~ "^mtk_clk_register_";
@@
- struct clk *
+ struct clk_hw *
F(...);
// Fix calls to mtk_clk_register_<singular>
@ reg @
identifier F =~ "^mtk_clk_register_";
identifier FS =~ "^mtk_clk_register_[a-z_]*s";
identifier I;
expression clk_data;
expression E;
@@
FS(...) {
...
- struct clk *I;
+ struct clk_hw *hw;
...
for (...;...;...) {
...
(
- I
+ hw
=
- clk_register_fixed_rate(
+ clk_hw_register_fixed_rate(
...
);
|
- I
+ hw
=
- clk_register_fixed_factor(
+ clk_hw_register_fixed_factor(
...
);
|
- I
+ hw
=
- clk_register_divider(
+ clk_hw_register_divider(
...
);
|
- I
+ hw
=
F(...);
)
...
if (
- IS_ERR(I)
+ IS_ERR(hw)
) {
pr_err(...,
- I
+ hw
,...);
...
}
- clk_data->hws[E] = __clk_get_hw(I);
+ clk_data->hws[E] = hw;
}
...
}
@ depends on reg @
identifier reg.I;
@@
return PTR_ERR(
- I
+ hw
);
// Fix mtk_clk_register_composite to return clk_hw instead of clk
@@
identifier I, R;
expression E;
@@
- struct clk *
+ struct clk_hw *
mtk_clk_register_composite(...) {
...
- struct clk *I;
+ struct clk_hw *hw;
...
- I = clk_register_composite(
+ hw = clk_hw_register_composite(
...);
if (IS_ERR(
- I
+ hw
)) {
...
R = PTR_ERR(
- I
+ hw
);
...
}
return
- I
+ hw
;
...
}
// Fix other mtk_clk_register_<singular> to return clk_hw instead of clk
@@
identifier F =~ "^mtk_clk_register_";
identifier I, D, C;
expression E;
@@
- struct clk *
+ struct clk_hw *
F(...) {
...
- struct clk *I;
+ int ret;
...
- I = clk_register(D, E);
+ ret = clk_hw_register(D, E);
...
(
- if (IS_ERR(I))
+ if (ret) {
kfree(C);
+ return ERR_PTR(ret);
+ }
|
- if (IS_ERR(I))
+ if (ret)
{
kfree(C);
- return I;
+ return ERR_PTR(ret);
}
)
- return I;
+ return E;
}
// Fix mtk_clk_unregister_<singular> to take clk_hw instead of clk
@@
identifier F =~ "^mtk_clk_unregister_";
identifier I, I2;
@@
static void F(
- struct clk *I
+ struct clk_hw *I2
)
{
...
- struct clk_hw *I2;
...
- I2 = __clk_get_hw(I);
...
(
- clk_unregister(I);
+ clk_hw_unregister(I2);
|
- clk_unregister_composite(I);
+ clk_hw_unregister_composite(I2);
)
...
}
// Fix calls to mtk_clk_unregister_*()
@@
identifier F =~ "^mtk_clk_unregister_";
expression I;
expression E;
@@
- F(I->hws[E]->clk);
+ F(I->hws[E]);
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220519071610.423372-5-wenst@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
As part of the effort to improve the MediaTek clk drivers, the next step
is to switch from the old 'struct clk' clk prodivder APIs to the new
'struct clk_hw' ones.
Instead of adding new APIs to the MediaTek clk driver library mirroring
the existing ones, moving all drivers to the new APIs, and then removing
the old ones, just migrate everything at the same time. This involves
replacing 'struct clk' with 'struct clk_hw', and 'struct clk_onecell_data'
with 'struct clk_hw_onecell_data', and fixing up all usages.
For now, the clk_register() and co. usage is retained, with __clk_get_hw()
and (struct clk_hw *)->clk used to bridge the difference between the APIs.
These will be replaced in subsequent patches.
Fix up mtk_{alloc,free}_clk_data to use 'struct clk_hw' by hand. Fix up
all other affected call sites with the following coccinelle script.
// Replace type
@@
@@
- struct clk_onecell_data
+ struct clk_hw_onecell_data
// Replace of_clk_add_provider() & of_clk_src_simple_get()
@@
expression NP, DATA;
symbol of_clk_src_onecell_get;
@@
- of_clk_add_provider(
+ of_clk_add_hw_provider(
NP,
- of_clk_src_onecell_get,
+ of_clk_hw_onecell_get,
DATA
)
// Fix register/unregister
@@
identifier CD;
expression E;
identifier fn =~ "unregister";
@@
fn(...,
- CD->clks[E]
+ CD->hws[E]->clk
,...
);
// Fix calls to clk_prepare_enable()
@@
identifier CD;
expression E;
@@
clk_prepare_enable(
- CD->clks[E]
+ CD->hws[E]->clk
);
// Fix pointer assignment
@@
identifier CD;
identifier CLK;
expression E;
@@
- CD->clks[E]
+ CD->hws[E]
=
(
- CLK
+ __clk_get_hw(CLK)
|
ERR_PTR(...)
)
;
// Fix pointer usage
@@
identifier CD;
expression E;
@@
- CD->clks[E]
+ CD->hws[E]
// Fix mtk_clk_pll_get_base()
@@
symbol clk, hw, data;
@@
mtk_clk_pll_get_base(
- struct clk *clk,
+ struct clk_hw *hw,
const struct mtk_pll_data *data
) {
- struct clk_hw *hw = __clk_get_hw(clk);
...
}
// Fix mtk_clk_pll_get_base() usage
@@
identifier CD;
expression E;
@@
mtk_clk_pll_get_base(
- CD->clks[E]
+ CD->hws[E]->clk
,...
);
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220519071610.423372-4-wenst@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
mtk_clk_register_ref2usb_tx() prints an error message if clk_register()
fails. It doesn't if kzalloc() fails though. The caller would then tack
on its own error message to handle this.
Also, All other clk registration functions in the MediaTek clk library
leave the error message printing to the bulk registration functions,
while the helpers that register individual clks just return error codes.
Drop the error message that is printed when clk_register() fails in
mtk_clk_register_ref2usb_tx() to make its behavior consistent both
across its failure modes, and with the rest of the driver library.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220519071610.423372-3-wenst@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
mtk_clk_register_composite() is not used anywhere outside of the file it
is defined.
Make it static.
Fixes: 9741b1a680 ("clk: mediatek: Add initial common clock support for Mediatek SoCs.")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220519071610.423372-2-wenst@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEBsvAIBsPu6mG7thcrX5LkNig010FAmKGpZwTHG1rbEBwZW5n
dXRyb25peC5kZQAKCRCtfkuQ2KDTXR4SB/4nr48LlHedhSR57kOl1Zm7gKhu60nK
EoNPGLODMsaWv4QdYXzU6HP5B8gUUb36DUlKHv7pH642UonPgfXudxpRKGuam35d
zxkapZbcs/A5LfF7yrFZYdBm+wUiepGHDmauhy3BJ2cR/bxkw7fL+yea0HCLWnjQ
qdt5KXGhnnWzvojKJsX6a4/tZpClruRbv1czrGYf9DjqSC+2Zf7t1tLxO0wk/zHi
kRQR2qpXR6YiBqwb/f64qXM0DB3KEQk7CAN8Z3V+4RX5f112EGFjaHVGufpMGIOh
dS+4u5v/kOChnR/91RqqR5o0fuw8XSHyb2PAcI2eLs/2e5xMUoPhIjfQ
=69VA
-----END PGP SIGNATURE-----
Merge tag 'linux-can-next-for-5.19-20220519' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
Marc Kleine-Budde says:
====================
pull-request: can-next 2022-05-19
Oliver Hartkopp contributes a patch for the ISO-TP CAN protocol to
update the validation of address information during bind.
The next patch is by Jakub Kicinski and converts the CAN network
drivers from netif_napi_add() to the netif_napi_add_weight() function.
Another patch by Oliver Hartkopp removes obsolete CAN specific LED
support.
Vincent Mailhol's patch for the mcp251xfd driver fixes a
-Wunaligned-access warning by clang-14.
* tag 'linux-can-next-for-5.19-20220519' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
can: mcp251xfd: silence clang's -Wunaligned-access warning
can: can-dev: remove obsolete CAN LED support
can: can-dev: move to netif_napi_add_weight()
can: isotp: isotp_bind(): do not validate unused address information
====================
Link: https://lore.kernel.org/r/20220519202308.1435903-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch set implements kexec_file_load() for RISC-V, which is
currently only allowed on rv64 due to some minor build issues on 32-bit
platforms in the generic code. This allows users to kexec() using an FD
as opposed to a buffer.
Link: https://lore.kernel.org/all/20220408100914.150110-1-lizhengyu3@huawei.com/
* palmer/riscv-kexec_file:
RISC-V: Load purgatory in kexec_file
RISC-V: Add purgatory
RISC-V: Support for kexec_file on panic
RISC-V: Add kexec_file support
RISC-V: use memcpy for kexec_file mode
kexec_file: Fix kexec_file.c build error for riscv platform
Remove include/rtw_debug.h, as all it now has are:
(1) A load of unused preprocessor definitions that expand to BIT(x)
variants.
(2) A preprocessor definition that expands to the name of the driver
and is only used in one place inside a pr_info_once call in
core/rtw_fw.c.
It is now surplus to requirements after fixing up the few places that
include the file.
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
Link: https://lore.kernel.org/r/20220519221047.6940-1-phil@philpotter.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The contents of the clock binding have been moved to the clock binding
schema in the dtschema repository. The desire is for common bindings to
be hosted in the dtschema repository.
Replace the contents with a link to the clock binding schema as there
are still many references to clock-bindings.txt in the tree. This will
prevent additions without a schema.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220428154154.2284317-1-robh@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Add a device tree for the n6000 instantiation of Agilex
Hard Processor System (HPS).
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Add the binding string for the Agilex based Intel n6000 board.
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Add device tree bindings documentation for the Intel Hard
Processor System (HPS) Copy Engine.
Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Some firmware includes unusable space (host bridge registers, hidden PCI
device BARs, etc) in PCI host bridge _CRS. As far as we know, there's
nothing in the ACPI, UEFI, or PCI Firmware spec that requires the OS to
remove E820 reserved regions from _CRS, so this seems like a firmware
defect.
As a workaround, 4dc2287c18 ("x86: avoid E820 regions when allocating
address space") has clipped out the unusable space in the past. This is
required for machines like the following:
- Dell Precision T3500 (the original motivator for 4dc2287c18); see
https://bugzilla.kernel.org/show_bug.cgi?id=16228
- Asus C523NA (Coral) Chromebook; see
https://lore.kernel.org/all/4e9fca2f-0af1-3684-6c97-4c35befd5019@redhat.com/
- Lenovo ThinkPad X1 Gen 2; see:
https://bugzilla.redhat.com/show_bug.cgi?id=2029207
But other firmware supplies E820 reserved regions that cover entire _CRS
windows, and clipping throws away the entire window, leaving none for
hot-added or uninitialized devices. This clipping breaks a whole range of
Lenovo IdeaPads, Yogas, Yoga Slims, and notebooks, as well as Acer Spin 5
and Clevo X170KM-G Barebone machines.
E820 reserved entries that cover a memory-mapped PCI host bridge, including
its registers and memory/IO windows, are probably *not* a firmware defect.
Per ACPI v5.4, sec 15.2, the E820 memory map may include:
Address ranges defined for baseboard memory-mapped I/O devices, such as
APICs, are returned as reserved.
Disable the E820 clipping by default for all post-2022 machines. We
already have quirks to disable clipping for pre-2023 machines, and we'll
likely need quirks to *enable* clipping for post-2022 machines that
incorrectly include unusable space in _CRS, including Chromebooks and
Lenovo ThinkPads.
Here's the rationale for doing this. If we do nothing, and continue
clipping by default:
- Future systems like the Lenovo IdeaPads, Yogas, etc, Acer Spin, and
Clevo Barebones will require new quirks to disable clipping.
- The problem here is E820 entries that cover entire _CRS windows that
should not be clipped out.
- I think these E820 entries are legal per spec, and it would be hard to
get BIOS vendors to change them.
- We will discover new systems that need clipping disabled piecemeal as
they are released.
- Future systems like Lenovo X1 Carbon and the Chromebooks (probably
anything using coreboot) will just work, even though their _CRS is
incorrect, so we will not notice new ones that rely on the clipping.
- BIOS updates will not require new quirks unless they change the DMI
model string.
If we add the date check in this commit that disables clipping, e.g., "no
clipping when date >= 2023":
- Future systems like Lenovo *IIL*, Acer Spin, and Clevo Barebones will
just work without new quirks.
- Future systems like Lenovo X1 Carbon and the Chromebooks will require
new quirks to *enable* clipping.
- The problem here is that _CRS contains regions that are not usable by
PCI devices, and we rely on the E820 kludge to clip them out.
- I think this use of E820 is clearly a firmware bug, so we have a
fighting chance of getting it changed eventually.
- BIOS updates after the cutoff date *will* require quirks, but only for
systems like Lenovo X1 Carbon and Chromebooks that we already think
have broken firmware.
It seems to me like it's better to add quirks for firmware that we think is
broken than for firmware that seems unusual but correct.
[bhelgaas: comment and commit log]
Link: https://lore.kernel.org/linux-pci/20220518220754.GA7911@bhelgaas/
Link: https://lore.kernel.org/r/20220519152150.6135-4-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Benoit Grégoire <benoitg@coeus.ca>
Cc: Hui Wang <hui.wang@canonical.com>
To avoid unusable space that some firmware includes in PCI host bridge
_CRS, Linux currently excludes E820 reserved regions from _CRS windows; see
4dc2287c18 ("x86: avoid E820 regions when allocating address space").
However, some systems supply E820 reserved regions that cover the entire
memory window from _CRS, so clipping them out leaves no space for hot-added
or uninitialized PCI devices.
For example, from a Lenovo IdeaPad 3 15IIL 81WE:
BIOS-e820: [mem 0x4bc50000-0xcfffffff] reserved
pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window]
pci 0000:00:15.0: BAR 0: [mem 0x00000000-0x00000fff 64bit]
pci 0000:00:15.0: BAR 0: no space for [mem size 0x00001000 64bit]
Add quirks to disable the E820 clipping for machines known to do this.
A single DMI_PRODUCT_VERSION "IIL" quirk matches all the below:
Lenovo IdeaPad 3 14IIL05
Lenovo IdeaPad 3 15IIL05
Lenovo IdeaPad 3 17IIL05
Lenovo IdeaPad 5 14IIL05
Lenovo IdeaPad 5 15IIL05
Lenovo IdeaPad Slim 7 14IIL05
Lenovo IdeaPad Slim 7 15IIL05
Lenovo IdeaPad S145-15IIL
Lenovo IdeaPad S340-14IIL
Lenovo IdeaPad S340-15IIL
Lenovo IdeaPad C340-15IIL
Lenovo BS145-15IIL
Lenovo V14-IIL
Lenovo V15-IIL
Lenovo V17-IIL
Lenovo Yoga C940-14IIL
Lenovo Yoga S740-14IIL
Lenovo Yoga Slim 7 14IIL05
Lenovo Yoga Slim 7 15IIL05
in addition to the following that don't actually need it because they have
no E820 reserved regions that overlap _CRS windows:
Lenovo IdeaPad Flex 5 14IIL05
Lenovo IdeaPad Flex 5 15IIL05
Lenovo ThinkBook 14-IIL
Lenovo ThinkBook 15-IIL
Lenovo Yoga S940-14IIL
Other quirks match these:
Acer Spin 5 (SP513-54N)
Clevo X170KM-G Barebone
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206459 Lenovo Yoga C940-14IIL
Link: https://bugzilla.kernel.org/show_bug.cgi?id=214259 Clevo X170KM Barebone
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 Lenovo IdeaPad 3 15IIL05
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1871793 Lenovo IdeaPad 5 14IIL05
Link: https://bugs.launchpad.net/bugs/1878279 Lenovo IdeaPad 5 14IIL05
Link: https://bugs.launchpad.net/bugs/1880172 Lenovo IdeaPad 3 14IIL05
Link: https://bugs.launchpad.net/bugs/1884232 Acer Spin SP513-54N
Link: https://bugs.launchpad.net/bugs/1921649 Lenovo IdeaPad S145
Link: https://bugs.launchpad.net/bugs/1931715 Lenovo IdeaPad S145
Link: https://bugs.launchpad.net/bugs/1932069 Lenovo BS145-15IIL
Link: https://lore.kernel.org/r/20220519152150.6135-3-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Benoit Grégoire <benoitg@coeus.ca>
Cc: Hui Wang <hui.wang@canonical.com>
Commit 1018faa6cf ("perf/x86/kvm: Fix Host-Only/Guest-Only
counting with SVM disabled") addresses an issue in which the
Host-Only bit in the counter control registers needs to be
masked off when SVM is not enabled.
The events need to be reloaded whenever SVM is enabled or
disabled for a CPU and this requires the PERF_CTL registers
to be reprogrammed using {enable,disable}_all(). However,
PerfMonV2 variants of these functions do not reprogram the
PERF_CTL registers. Hence, the legacy enable_all() function
should also be called.
Fixes: 9622e67e39 ("perf/x86/amd/core: Add PerfMonV2 counter control")
Reported-by: Like Xu <likexu@tencent.com>
Signed-off-by: Sandipan Das <sandipan.das@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20220518084327.464005-1-sandipan.das@amd.com
default_topology[] uses cpu_clustergroup_mask() for the CLS level
(guarded by CONFIG_SCHED_CLUSTER) which is currently provided by x86
(arch/x86/kernel/smpboot.c) and arm64 (drivers/base/arch_topology.c).
Fixes: 778c558f49 ("sched: Add cluster scheduler level in core and
related Kconfig for ARM64")
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Barry Song <baohua@kernel.org>
Link: https://lore.kernel.org/r/20220513093433.425163-1-dietmar.eggemann@arm.com
Because GCC-12 is fully stupid about array bounds and it's just really
hard to get a solid array definition from a linker script, flip the
array order to avoid needing negative offsets :-/
This makes the whole relational pointer magic a little less obvious, but
alas.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/YoOLLmLG7HRTXeEm@hirez.programming.kicks-ass.net
