aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-08-03dt-bindings: iio: dac: Generalize DAC common propertiesKim Seer Paller1-0/+50
Introduce a generalized DAC binding that can be used by DACs that have similar properties adding output-range-microamp and output-range-microvolt. Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Kim Seer Paller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: ABI: add DAC 42kohm_to_gnd powerdown modeKim Seer Paller1-0/+1
Add a new powerdown mode for DACs with 42kohm resistor to GND. Signed-off-by: Kim Seer Paller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: ABI: Generalize ABI documentation for DACKim Seer Paller2-31/+61
Introduces a more generalized ABI documentation for DAC. Instead of having separate ABI files for each DAC, we now have a single ABI file that covers the common sysfs interface for all DAC. Signed-off-by: Kim Seer Paller <[email protected]> https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: backend: print message in case op is not implementedNuno Sa1-0/+4
For APIs that have a return value, -EOPNOTSUPP is returned in case the backend does not support the functionality. However, for APIs that do not have a return value we are left in silence. Hence, at least print a debug message in case the callback is not implemented by the backend. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/20240709-dev-iio-backend-add-debugfs-v1-2-fb4b8f2373c7@analog.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: backend: remove unused parameterNuno Sa3-7/+3
Indio_dev was not being used in iio_backend_extend_chan_spec() so remove it. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/20240709-dev-iio-backend-add-debugfs-v1-1-fb4b8f2373c7@analog.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03docs: iio: new docs for ad7380 driverJulien Stephan3-0/+90
This adds a new page to document how to use the ad7380 ADC driver. Credit: this docs is based on ad7944 docs. Signed-off-by: Julien Stephan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03docs: iio: add documentation for adxl380 driverAntoniu Miclaus2-0/+234
Add documentation for adxl380 driver which describes the driver device files and shows how the user may use the ABI for various scenarios (configuration, measurement, etc.). Signed-off-by: Ramona Gradinariu <[email protected]> Signed-off-by: Antoniu Miclaus <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: accel: add ADXL380 driverAntoniu Miclaus7-0/+2095
The ADXL380/ADXL382 is a low noise density, low power, 3-axis accelerometer with selectable measurement ranges. The ADXL380 supports the +/-4 g, +/-8 g, and +/-16 g ranges, and the ADXL382 supports +/-15 g, +/-30 g and +/-60 g ranges. The ADXL380/ADXL382 offers industry leading noise, enabling precision applications with minimal calibration. The low noise, and low power ADXL380/ADXL382 enables accurate measurement in an environment with high vibration, heart sounds and audio. In addition to its low power consumption, the ADXL380/ADXL382 has many features to enable true system level performance. These include a built-in micropower temperature sensor, single / double / triple tap detection and a state machine to prevent a false triggering. In addition, the ADXL380/ADXL382 has provisions for external control of the sampling time and/or an external clock. Signed-off-by: Ramona Gradinariu <[email protected]> Signed-off-by: Antoniu Miclaus <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03dt-bindings: iio: accel: add ADXL380Antoniu Miclaus2-0/+99
Add dt-bindings for ADXL380/ADLX382 low noise density, low power, 3-axis accelerometer with selectable measurement ranges. Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Ramona Gradinariu <[email protected]> Signed-off-by: Antoniu Miclaus <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: pressure: bmp280: Add triggered buffer supportVasileios Amoiridis4-19/+405
BMP2xx, BME280, BMP3xx, and BMP5xx use continuous buffers for their temperature, pressure and humidity readings. This facilitates the use of burst/bulk reads in order to acquire data faster. The approach is different from the one used in oneshot captures. BMP085 & BMP1xx devices use a completely different measurement process that is well defined and is used in their buffer_handler(). Suggested-by: Angel Iglesias <[email protected]> Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: pressure: bmp280: Add SCALE, RAW values in channels and refactorize themVasileios Amoiridis1-13/+83
Add extra IIO_CHAN_INFO_SCALE and IIO_CHAN_INFO_RAW channels in order to be able to calculate the processed value with standard userspace IIO tools. Can be used for triggered buffers as well. Even though it is not a good design choice to have SCALE, RAW and PROCESSED together, the PROCESSED channel is kept for ABI compatibility. While at it, separate BMPxxx and BMExxx device channels since BME supports also humidity measurements. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: pressure: bmp280: Generalize read_*() functionsVasileios Amoiridis2-73/+108
Add the coefficients for the IIO standard units and the IIO value inside the chip_info structure. Move the calculations for the IIO unit compatibility from inside the read_{temp,press,humid}() functions and move them to the general read_raw() function. In this way, all the data for the calculation of the value are located in the chip_info structure of the respective sensor. Signed-off-by: Vasileios Amoiridis <[email protected]> Acked-by: Adam Rizkalla <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: light: ltrf216a: Add LTR-308 supportMarek Vasut1-10/+43
Add LiteOn LTR-308 support into LTR-F216A kernel driver. The two devices seem to have almost identical register map, except that the LTR-308 does not have three CLEAR_DATA registers, which are unused by this driver. Furthermore, LTR-308 and LTR-F216A use different lux calculation constants, 0.6 and 0.45 respectively. Both differences are handled using chip info data. https://optoelectronics.liteon.com/upload/download/DS86-2016-0027/LTR-308ALS_Final_%20DS_V1%201.pdf https://optoelectronics.liteon.com/upload/download/DS86-2019-0016/LTR-F216A_Final_DS_V1.4.PDF Signed-off-by: Marek Vasut <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03dt-bindings: iio: light: ltrf216a: Document LTR-308 supportMarek Vasut1-1/+3
Document LiteOn LTR-308 support in LTR-F216A bindings. The two devices seem to have almost identical register map, except that the LTR-308 does not have three CLEAR_DATA registers, which are unused by this driver. Furthermore, LTR-308 and LTR-F216A use different lux calculation constants, 0.6 and 0.45 respectively. https://optoelectronics.liteon.com/upload/download/DS86-2016-0027/LTR-308ALS_Final_%20DS_V1%201.pdf https://optoelectronics.liteon.com/upload/download/DS86-2019-0016/LTR-F216A_Final_DS_V1.4.PDF Signed-off-by: Marek Vasut <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: bu27034: Add a read only HARDWAREGAINMatti Vaittinen1-1/+14
The ROHM BU27034 light sensor has two data channels for measuring different frequencies of light. The result from these channels is combined into Lux value while the raw channel values are reported via intensity channels. Both of the intensity channels have adjustable gain setting which impacts the scale of the raw channels. Eg, doubling the gain will double the values read from the raw channels, which halves the scale value. The integration time can also be set for the sensor. This does also have an impact to the scale of the intensity channels because increasing the integration time will also increase the values reported via the raw channels. Impact of integration time to the scale and the fact that the scale value does not start from '1', can make it hard for a human reader to compute the gain values based on the scale. Add read-only HARDWAREGAIN to help debugging. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://patch.msgid.link/ec349847cc994f3bd632e99b408a31e7c70581d0.1720176341.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03bu27034: ROHM BU27034ANUC correct lux calculationMatti Vaittinen1-126/+31
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this sensor. The lux computation based on the data from a BU27034ANUC is different from the computation for the data from an old BU27034NUC. Fix the lux computation. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://patch.msgid.link/b7bea76b54b28eb354dc523771a0e0a8b6f26095.1720176341.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03bu27034: ROHM BU27034ANUC correct gains and timesMatti Vaittinen1-19/+9
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this sensor. The BU27034ANUC does not support all the gains or all the integration times that were supported on BU27034NUC. Srop unsupported times and gains Signed-off-by: Matti Vaittinen <[email protected]> Link: https://patch.msgid.link/19f8cca2b5498fbfea6e657b7b9c90b78516866a.1720176341.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03bu27034: ROHM BU27034NUC to BU27034ANUC drop data2Matti Vaittinen1-104/+28
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this sensor. The BU27034ANUC does not have the data2 channel. Drop the data2 channel. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://patch.msgid.link/6f261d4499e9c0e161279717261cc9a20764a6bd.1720176341.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03bu27034: ROHM BU27034NUC to BU27034ANUCMatti Vaittinen1-3/+2
The ROHM BU27034NUC was cancelled and BU27034ANUC is replacing this sensor. These senors aren't compatible from the software point of view. According to ROHM, the BU27034NUC was never mass-produced. Hence dropping the BU27034NUC support and using this driver to support BU27034ANUC should not be a problem to users. We however need to ensure than people who use old kernel with the old BU27034NUC driver don't get the old driver probed for the new sensor. Prepare to use the BU27034NUC driver to support the new BU27034ANUC and change the compatible to prevent probing the old driver with the new sensor. Signed-off-by: Matti Vaittinen <[email protected]> Link: https://patch.msgid.link/ed8b963b0cd3a84c06a494c79969a136d5abcf92.1720176341.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03dt-bindings: iio: BU27034 => BU27034ANUCMatti Vaittinen1-6/+5
The BU27034NUC was cancelled before it entered mass production. It was replaced by a new variant BU27034ANUC (note, added 'A'). The new variant gained a few significant changes, like removal of the 3.rd data channel and dropping some of the gain settings. This means that, from software point of view these ICs are incompatible. Lux calculation based on the data from the sensors needs to be done differently, and on the BU27034ANUC the channel 3 data is missing. Also, the gain setting differencies matter. Unfortunately, the identification register was not changed so there is no safe way for the software to distinguish the variants. According to the ROHM HQ engineers, the old BU27034NUC should not be encountered in the wild. Hence it makes sense to remove the support for the old BU27034NUC and add support for the new BU27034ANUC. Change the compatible in order to not load the incompatible old driver for new sensor (or, if someone had the old sensor, the new driver for it). Drop the compatible for old sensor which should not be in the wild and add a new compatible for the new model with accurate model suffix 'anuc'. Rename the file to match the new compatible. Signed-off-by: Matti Vaittinen <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://patch.msgid.link/c39f9c67b3c07a27d7a13109c7b69cff9cfd2b9b.1720176341.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Refactorize reading functionsVasileios Amoiridis1-76/+116
The reading of the pressure and humidity value, requires an update of the t_fine variable which happens by reading the temperature value. So the bme680_read_{press/humid}() functions of the above sensors are internally calling the equivalent bme680_read_temp() function in order to update the t_fine value. By just looking at the code this relation is a bit hidden and is not easy to understand why those channels are not independent. This commit tries to clear these thing a bit by splitting the bme680_{read/compensate}_{temp/press/humid}() to the following: i. bme680_read_{temp/press/humid}_adc(): read the raw value from the sensor. ii. bme680_calc_t_fine(): calculate the t_fine variable. iii. bme680_get_t_fine(): get the t_fine variable. iv. bme680_compensate_{temp/press/humid}(): compensate the adc values and return the calculated value. v. bme680_read_{temp/press/humid}(): combine calls of the aforementioned functions to return the requested value. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Move forced mode setup in ->read_raw()Vasileios Amoiridis1-18/+10
Whenever the sensor is set to forced mode, a TPHG cycle is triggered and the values of temperature, pressure, humidity and gas become ready to be read. The setup of the forced mode to trigger measurements was located inside the read_{temp/gas}() functions. This was not posing a functional problem since read_{humid/press}() are internally calling read_temp() so the forced mode is set through this call. This is not very clear and it is kind of hidden that regardless of the measurement, the setup of the forced mode needs to happen before any measurement. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Remove redundant gas configurationVasileios Amoiridis1-7/+0
There is no need to explicitly configure the gas measurement registers every time a gas measurement takes place. These are initial configurations which are written in the beginning and they are not changed throughout the lifetime of the driver. If in the future, the device starts to support multiple configuration profiles with variable heater duration and heater temperature, then they could become members of the ->read_avail(). Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Move probe errors to dev_err_probe()Vasileios Amoiridis1-18/+11
There are multiple cases in the probe function that dev_err_probe() fits the needs, so use it. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Modify startup procedureVasileios Amoiridis2-7/+16
Modify the startup procedure to reflect the procedure of the Bosch BME68x Sensor API. The initial readings and configuration of the sensor need to happen in the following order: 1) Read calibration data [1,2] 2) Chip general configuration [3] 3) Gas configuration [4] After the chip configuration it is necessary to ensure that the sensor is in sleeping mode, in order to apply the gas configuration settings [5]. Also, after the soft reset, it is advised to wait for 5ms [6]. Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L162 # [1] Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/examples/forced_mode/forced_mode.c#L44 # [2] Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/examples/forced_mode/forced_mode.c#L53 # [3] Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/examples/forced_mode/forced_mode.c#L60 # [4] Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L640 # [5] Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L294 # [6] Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Make error checks consistentVasileios Amoiridis1-2/+4
In the majority of the error checks after a regmap_{read,write}() operation the following coding style is used: ret = regmap_{read,write}(data->regmap, ...); if (ret < 0) { dev_err(dev, ...); return ret; } In this particular case it was different so change it for consistency. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Add read buffers in read/write buffer unionVasileios Amoiridis2-23/+29
Move the buffers that are used in order to read data from the device in the union which handles all the device read/write buffers. Also create defines for the number of bytes that are being read from the device and don't use magic numbers. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Allocate IIO device before chip initializationVasileios Amoiridis1-19/+19
Move the IIO device allocation before the actual initialization of the chip to be more consistent with most IIO drivers and also to have the ability to use any driver specific data for the chip initialization. While at it, fix also a misaligned line. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Use bulk reads for calibration dataVasileios Amoiridis2-210/+97
Calibration data are located in contiguous-ish registers inside the chip. For that reason we can use bulk reads as is done as well in the BME68x Sensor API [1]. The arrays that are used for reading the data out of the sensor are located inside DMA safe buffer. Link: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L1769 # [1] Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Remove duplicate register readVasileios Amoiridis2-14/+9
The LSB of the gas register was read first to check if the following check was correct and then the MSB+LSB were read together. Simplify this by reading together the MSB+LSB immediately. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Sort headers alphabeticallyVasileios Amoiridis1-1/+2
Sort headers in alphabetical order and split the iio specific functions with a blank line Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Remove remaining ACPI-only stuffVasileios Amoiridis1-15/+0
The ACPI ID table was removed with the following 2 commits: Commit b73d21dccf68 ("iio: bme680_i2c: Remove acpi_device_id table") Commit f0e4057e97c1 ("iio: bme680_spi: Remove acpi_device_id table") Remove the remaining ACPI related stuff to this driver since they are not directly used. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Drop unnecessary casts and correct adc data typesVasileios Amoiridis1-8/+8
Delete any redundant casts in the code and use unsigned integers for the raw adc values. Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Fix typo in defineVasileios Amoiridis2-2/+2
Fix a define typo that instead of BME680_... it is saying BM6880_... Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: chemical: bme680: Fix read/write ops to device by adding mutexesVasileios Amoiridis1-0/+7
Add mutexes in the {read/write}_raw() functions of the device to guard the read/write of data from/to the device. This is necessary because for any operation other than temperature, multiple reads need to take place from the device. Even though regmap has a locking by itself, it won't protect us from multiple applications trying to read at the same time temperature and pressure since the pressure reading includes an internal temperature reading and there is nothing to ensure that this temperature+pressure reading will happen sequentially without any other operation interfering in the meantime. Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor") Signed-off-by: Vasileios Amoiridis <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03ABI: testing: fix admv8818 attr descriptionAntoniu Miclaus1-1/+1
Fix description of the filter_mode_available attribute by pointing to the correct name of the attribute that can be written with valid values. Fixes: bf92d87d7c67 ("iio:filter:admv8818: Add sysfs ABI documentation") Signed-off-by: Antoniu Miclaus <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03Merge tag 'tags/fixes-media-uvc-20230722' of ↵Hans Verkuil1-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux.git uvcvideo v6.11 regression fix: fix custom control mapping probing Signed-off-by: Hans Verkuil <[email protected]>
2024-08-02Merge patch series "smartpqi updates"Martin K. Petersen2-27/+151
Don Brace <[email protected]> says: These patches are based on Martin Petersen's 6.11/scsi-queue tree https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 6.11/scsi-queue The functional changes of note to smartpqi are for: multipath failover and improving the accuracy of our RAID bypass counter. For multipath we are: Reverting commit 94a68c814328 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") because under certain rare conditions involving encryption-enabled devices, a false path failure is reported to the SML causing multipath to failover to the other path. Improving errors returned from the driver back to the SML by checking for error codes returned from the firmware and returning the correct ASC/ASCQ codes to the SML. The other two patches add PCI-IDs for new controllers and change the driver version. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Update driver version to 2.1.28-025Don Brace1-3/+3
Update driver version to 2.1.28-025. Reviewed-by: Mike Tran <[email protected]> Reviewed-by: Gerry Morong <[email protected]> Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Improve handling of multipath failoverKevin Barnett1-1/+15
Improve multipath failovers by mapping firmware errors into I/O errors. In some rare instances, firmware does not return the proper error code for I/O errors caused by a multipath path failure. Map I/O errors returned by firmware into errors that help the multipath layer to detect the failure of a path. Reviewed-by: Gerry Morong <[email protected]> Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Signed-off-by: Kevin Barnett <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quicklyGilbert Wu1-18/+2
Correct a rare multipath failure issue by reverting commit 94a68c814328 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") [1]. Reason for revert: The patch propagated the path failure to SML quickly when one of the path fails during IO and AIO path gets disabled for a multipath device. But it created a new issue: when creating a volume on an encryption-enabled controller, the firmware reports the AIO path is disabled, which cause the driver to report a path failure to SML for a multipath device. There will be a new fix to handle "Illegal request" and "Invalid field in parameter list" on RAID path when the AIO path is disabled on a multipath device. [1] https://lore.kernel.org/all/[email protected]/ Fixes: 94a68c814328 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Signed-off-by: Gilbert Wu <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Improve accuracy/performance of raid-bypass-counterKevin Barnett2-5/+27
The original implementation of this counter used an atomic variable. However, this implementation negatively impacted performance in some configurations. Switch to using per_cpu variables. Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Co-developed-by: Mahesh Rajashekhara <[email protected]> Signed-off-by: Mahesh Rajashekhara <[email protected]> Signed-off-by: Kevin Barnett <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Add new controller PCI IDsDavid Strahan1-0/+104
All PCI ID entries in hex. Add new inagile PCI IDs: VID / DID / SVID / SDID ---- ---- ---- ---- SMART-HBA 8242-24i 9005 / 028f / 1ff9 / 0045 RAID 8236-16i 9005 / 028f / 1ff9 / 0046 RAID 8240-24i 9005 / 028f / 1ff9 / 0047 SMART-HBA 8238-16i 9005 / 028f / 1ff9 / 0048 PM8222-SHBA 9005 / 028f / 1ff9 / 004a RAID PM8204-2GB 9005 / 028f / 1ff9 / 004b RAID PM8204-4GB 9005 / 028f / 1ff9 / 004c PM8222-HBA 9005 / 028f / 1ff9 / 004f MT0804M6R 9005 / 028f / 1ff9 / 0051 MT0801M6E 9005 / 028f / 1ff9 / 0052 MT0808M6R 9005 / 028f / 1ff9 / 0053 MT0800M6H 9005 / 028f / 1ff9 / 0054 RS0800M5H24i 9005 / 028f / 1ff9 / 006b RS0800M5E8i 9005 / 028f / 1ff9 / 006c RS0800M5H8i 9005 / 028f / 1ff9 / 006d RS0804M5R16i 9005 / 028f / 1ff9 / 006f RS0800M5E24i 9005 / 028f / 1ff9 / 0070 RS0800M5H16i 9005 / 028f / 1ff9 / 0071 RS0800M5E16i 9005 / 028f / 1ff9 / 0072 RT0800M7E 9005 / 028f / 1ff9 / 0086 RT0800M7H 9005 / 028f / 1ff9 / 0087 RT0804M7R 9005 / 028f / 1ff9 / 0088 RT0808M7R 9005 / 028f / 1ff9 / 0089 RT1608M6R16i 9005 / 028f / 1ff9 / 00a1 Add new h3c pci_id: VID / DID / SVID / SDID ---- ---- ---- ---- UN RAID P4408-Mr-2 9005 / 028f / 193d / 1110 Add new powerleader pci ids: VID / DID / SVID / SDID ---- ---- ---- ---- PL SmartROC PM8204 9005 / 028f / 1f3a / 0104 Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Signed-off-by: David Strahan <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: sd: Keep the discard mode stableLi Feng1-4/+2
There is a scenario where a large number of discard commands are issued when the iscsi initiator connects to the target and then performs a session rescan operation. There is a time window, most of the commands are in UNMAP mode, and some discard commands become WRITE SAME with UNMAP. The discard mode has been negotiated during the SCSI probe. If the mode is temporarily changed from UNMAP to WRITE SAME with UNMAP, an I/O ERROR may occur because the target may not implement WRITE SAME with UNMAP. Keep the discard mode stable to fix this issue. Signed-off-by: Li Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02Merge patch series "Update lpfc to revision 14.4.0.4"Martin K. Petersen8-46/+112
Justin Tee <[email protected]> says: Update lpfc to revision 14.4.0.4 This patch set contains diagnostic logging improvements, a minor clean up when submitting abort requests, a bug fix related to reset and errata paths, and modifications to FLOGI and PRLO ELS command handling. The patches were cut against Martin's 6.11/scsi-queue tree. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Copyright updates for 14.4.0.4 patchesJustin Tee1-1/+1
Update copyrights to 2024 for files modified in the 14.4.0.4 patch set. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Update lpfc version to 14.4.0.4Justin Tee1-1/+1
Update lpfc version to 14.4.0.4 Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Update PRLO handling in direct attached topologyJustin Tee2-13/+36
A kref imbalance occurs when handling an unsolicited PRLO in direct attached topology. Rework PRLO rcv handling when in MAPPED state. Save the state that we were handling a PRLO by setting nlp_last_elscmd to ELS_CMD_PRLO. Then in the lpfc_cmpl_els_logo_acc() completion routine, manually restart discovery. By issuing the PLOGI, which nlp_gets, before nlp_put at the end of the lpfc_cmpl_els_logo_acc() routine, we are saving us from a final nlp_put. And, we are still allowing the unreg_rpi to happen. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached ↵Justin Tee3-23/+46
topology In direct attached topology, certain target vendors that are quick to issue FLOGI followed by a cable pull for more than dev_loss_tmo may result in a kref imbalance for the remote port ndlp object. Add an nlp_get when the defer_flogi_acc flag is set. This is expected to balance the nlp_put in the defer_flogi_acc clause in the lpfc_issue_els_flogi() routine. Because we need to retain the ndlp ptr, reorganize all of the defer_flogi_acc information into one lpfc_defer_flogi_acc struct. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Fix unintentional double clearing of vmid_flagJustin Tee2-2/+3
The vport->vmid_flag is unintentionally cleared twice after an issue_lip via the lpfc_reinit_vmid routine(). The first call to lpfc_reinit_vmid() is in lpfc_cmpl_els_flogi(). Then lpfc_cmpl_els_flogi_fabric() calls lpfc_register_new_vport(), which calls lpfc_cmpl_reg_new_vport() when the mbox command completes and calls lpfc_reinit_vmid() a second time. Fix by moving the vmid_flag clear outside of the lpfc_reinit_vmid() routine so that vmid_flag is only cleared once upon FLOGI completion. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.