strncpy() is deprecated for use on NUL-terminated destination strings [1]
and as such we should prefer more robust and less ambiguous string
interfaces.
Since all these structs are copied out to userspace let's keep them
NUL-padded by using strscpy_pad() which guarantees NUL-termination of the
destination buffer while also providing the NUL-padding behavior that
strncpy() has.
Let's also opt to use the more idiomatic strscpy() usage of: 'dest, src,
sizeof(dest)' in cases where the compiler can determine the size of the
destination buffer. Do this for all cases of strscpy...() in this file.
To be abundantly sure we don't leak stack data out to user space let's also
change a strscpy() to strscpy_pad(). This strscpy() was introduced in
commit dbe37c71d1 ("scsi: message: fusion: Replace all non-returning
strlcpy() with strscpy()")
Note that since we are creating these structs with a copy_from_user() and
modifying fields and then copying back out to the user it is probably OK
not to explicitly NUL-pad everything as any data leak is probably just data
from the user themselves. If this is too eager, let's opt for strscpy()
which is still in the spirit of removing deprecated strncpy() usage
treewide.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Link: https://lore.kernel.org/r/20230927-strncpy-drivers-message-fusion-mptctl-c-v1-1-bb2eddc1743c@google.com
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The target discovery buffer that the VIOS populates with targets is
currently a host adapter field. To facilitate the discovery of NVMe targets
as well as SCSI another discovery buffer is required. Move the discovery
buffer out of the host struct and into the ibmvfc_channels struct so that
each channels instance for a given protocol has its own discovery buffer.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://lore.kernel.org/r/20230921225435.3537728-11-tyreld@linux.ibm.com
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Commit 0217a272fe ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ
during cleanup") wrongly changed the busy loop check to use
rtas_busy_delay() instead of H_BUSY and H_IS_LONG_BUSY(). The busy return
codes for RTAS and hypercalls are not the same.
Fix this issue by restoring the use of H_BUSY and H_IS_LONG_BUSY().
Fixes: 0217a272fe ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ during cleanup")
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://lore.kernel.org/r/20230921225435.3537728-5-tyreld@linux.ibm.com
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Extend ibmvfc_queue, ibmvfc_event, and ibmvfc_event_pool to provide queue
depths for general I/O commands and reserved commands as well as proper
accounting of the free events of each type from the general event
pool. Further, calculate the negotiated max command limit with the VIOS at
NPIV login time as a function of the number of queues times their total
queue depth (general and reserved depths combined).
This does away with the legacy max_request value, and allows the driver to
better manage and track it resources.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://lore.kernel.org/r/20230921225435.3537728-3-tyreld@linux.ibm.com
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In practice the driver should never send more commands than are allocated
to a queue's event pool. In the unlikely event that this happens, the code
asserts a BUG_ON, and in the case that the kernel is not configured to
crash on panic returns a junk event pointer from the empty event list
causing things to spiral from there. This BUG_ON is a historical artifact
of the ibmvfc driver first being upstreamed, and it is well known now that
the use of BUG_ON is bad practice except in the most unrecoverable
scenario. There is nothing about this scenario that prevents the driver
from recovering and carrying on.
Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL
pointer in the case of an empty event pool. Update all call sites to
ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate
failure or recovery action.
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Link: https://lore.kernel.org/r/20230921225435.3537728-2-tyreld@linux.ibm.com
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently, if CONFIG_SCSI_HISI_SAS_DEBUGFS_DEFAULT_ENABLE is enabled, the
memory space used by DFX is allocated during device initialization, which
occupies a large number of memory resources. The memory usage before and
after the driver is loaded is as follows:
Memory usage before the driver is loaded:
$ free -m
total used free shared buff/cache available
Mem: 867352 2578 864037 11 735 861681
Swap: 4095 0 4095
Memory usage after the driver which include 4 HBAs is loaded:
$ insmod hisi_sas_v3_hw.ko
$ free -m
total used free shared buff/cache available
Mem: 867352 4760 861848 11 743 859495
Swap: 4095 0 4095
The driver with 4 HBAs connected will allocate about 110 MB of memory
without enabling debugfs.
Therefore, to avoid wasting memory resources, DFX memory is allocated
during dump triggering. The dump may fail due to memory allocation
failure. After this change, each dump costs about 10 MB of memory, and each
dump lasts about 100 ms.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
Link: https://lore.kernel.org/r/1694571327-78697-4-git-send-email-chenxiang66@hisilicon.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To
improve here there is a quest to make the remove callback return void. In
the first step of this quest all drivers are converted to .remove_new()
which already returns void. Eventually after all drivers are converted,
.remove_new() is renamed to .remove().
All platform drivers below drivers/ufs/ unconditionally return zero in
their remove callback and so can be converted trivially to the variant
returning void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230917145722.1131557-1-u.kleine-koenig@pengutronix.de
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Damien Le Moal <dlemoal@kernel.org> says:
The first patch of this series fixes an issue with IRQ setup which
prevents the controller from resuming after a system suspend. The
following patches are code cleanup without any functional changes.
[mkp: The first patch went into v6.6-rc2 and thus this merge
constitutes the remaining patches of the series]
Link: https://lore.kernel.org/r/20230911232745.325149-1-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove the macro PM8001_READ_VPD used to define if a controller WWN should
be retrieved from the device. Instead, define the better named boolean
module parameter "read_wwn" to control this.
The code to set a fixed address for a phy device address when read_wwn is
set to false is simplified and fixed to avoid sparse warnings.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20230911232745.325149-11-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove the macro PM8001_USE_TASKLET used to conditionally use tasklets for
MSI-X interrupts handling and replace it with the boolean module parameter
pm8001_use_tasklet. This parameter defaults to true and can be true only if
pm8001_use_msix is also true.
Code conditionnaly defined with PM8001_USE_TASKLET is modified to instead
use the parameter pm8001_use_tasklet.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20230911232745.325149-10-dlemoal@kernel.org
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The pm8001 driver does not compile if PM8001_USE_MSIX is not defined in
pm8001_sas.h because various fields and functions conditionally defined are
used unconditionally without a "#ifdef PM8001_USE_MSIX" protection. This
macro is rather useless anyway and not convenient as diabling MSI-X use
requires recompiling the driver.
Remove this macro and replace it with the bool module parameter "use_msix"
which defaults to true. The use of MSI-X interrupts for an adapter is gated
by this module parameter for adapters that actually support MSI-X. The
"use_msix" boolean field is added to struct pm8001_hba_info and all code
defined depending on PM8001_USE_MSIX is modified to rely on
pm8001_hba_info->use_msix instead.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20230911232745.325149-9-dlemoal@kernel.org
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
pm8001_chip_msix_interrupt_enable() and
pm8001_chip_msix_interrupt_disable() are always cold with the vector
argument equal to 0. This allows simplifying the code for these
functions. With this change, the functions are simple enough and can be
removed by open coding them directly in pm8001_chip_interrupt_enable() and
pm8001_chip_interrupt_disable(). Also do the same for the functions
pm8001_chip_intx_interrupt_enable() and
pm8001_chip_intx_interrupt_disable() and remove these functions.
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20230911232745.325149-7-dlemoal@kernel.org
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Nitin Rawat <quic_nitirawa@quicinc.com> says:
This patch series adds programming support for Qualcomm UFS V4 and
above to align avoid with Hardware Specification. This patch series
will address stability and performance issues.
In this patch series below changes are taken care.
1) Register layout for DME_VS_CORE_CLK_CTRL has changed for v4 and above.
2) Adds Support to configure PA_VS_CORE_CLK_40NS_CYCLES attibute for UFS V4
and above.
3) Adds Support to configure multiple unipro frequencies like 403MHz,
300MHz, 202MHz, 150 MHz, 75Mhz, 37.5 MHz for Qualcomm UFS Controller V4
and above.
4) Allow configuration of SYS1CLK_1US_REG for UFS V4 and above.
Link: https://lore.kernel.org/r/20230905052400.13935-1-quic_nitirawa@quicinc.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The "hs_gear" variable is used to program the PHY settings (submode) during
ufs_qcom_power_up_sequence(). Currently, it is being updated every time the
agreed gear changes. Due to this, if the gear got downscaled before suspend
(runtime/system), then while resuming, the PHY settings for the lower gear
will be applied first and later when scaling to max gear with REINIT, the
PHY settings for the max gear will be applied.
This adds a latency while resuming and also really not needed as the PHY
gear settings are backwards compatible i.e., we can continue using the PHY
settings for max gear with lower gear speed.
So let's update the "hs_gear" variable _only_ when the agreed gear is
greater than the current one. This guarantees that the PHY settings will be
changed only during probe time and fatal error condition.
Due to this, UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH can now be skipped
when the PM operation is in progress.
Cc: stable@vger.kernel.org
Fixes: 96a7141da3 ("scsi: ufs: core: Add support for reinitializing the UFS device")
Reported-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20230908145329.154024-1-manivannan.sadhasivam@linaro.org
Reviewed-by: Can Guo <quic_cang@quicinc.com>
Tested-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
SYS1CLK_1US represents the required number of system 1-clock cycles for one
microsecond. UFS Host Controller V4.0 and above mandates to write
SYS1CLK_1US_REG register and also these timer configuration needs to be
called from clk scaling pre ops as per HPG.
Refactor ufs_qcom_cfg_timers and add the below code support to align
with HPG.
a)Configure SYS1CLK_1US_REG for UFS V4 and above.
b)Introduce a new argument is_pre_scale_up for ufs_qcom_cfg_timers
to configure SYS1CLK_1US for max freq during prescale and link startup
condition.
c)Move ufs_qcom_cfg_timers from clk scaling post change ops
to clk scaling pre change ops.
Co-developed-by: Naveen Kumar Goud Arepalli <quic_narepall@quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall@quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
Link: https://lore.kernel.org/r/20230905052400.13935-6-quic_nitirawa@quicinc.com
Reviewed-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
PA_VS_CORE_CLK_40NS_CYCLES attribute represents the required number of
Qunipro core clock for 40 nanoseconds. For UFS host controller V4 and above
PA_VS_CORE_CLK_40NS_CYCLES needs to be programmed as per frequency of
unipro core clk of UFS host controller.
Add Support to configure PA_VS_CORE_CLK_40NS_CYCLES for Controller V4 and
above to align with the hardware specification and to avoid functionality
issues like h8 enter/exit failure, command timeout.
Co-developed-by: Naveen Kumar Goud Arepalli <quic_narepall@quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall@quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
Link: https://lore.kernel.org/r/20230905052400.13935-4-quic_nitirawa@quicinc.com
Reviewed-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Qualcomm UFS Controller V4 and above supports multiple unipro frequencies
like 403MHz, 300MHz, 202MHz, 150 MHz, 75Mhz, 37.5 MHz. Current code
supports only 150MHz and 75MHz which have performance impact due to low UFS
controller frequencies.
For targets which supports frequencies other than 150 MHz and 75 Mhz, needs
an update of MAX_CORE_CLK_1US_CYCLES to match the configured frequency to
avoid functionality issues. Add multiple frequency support for
MAX_CORE_CLK_1US_CYCLES based on the frequency configured.
Co-developed-by: Naveen Kumar Goud Arepalli <quic_narepall@quicinc.com>
Signed-off-by: Naveen Kumar Goud Arepalli <quic_narepall@quicinc.com>
Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com>
Link: https://lore.kernel.org/r/20230905052400.13935-3-quic_nitirawa@quicinc.com
Reviewed-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
