aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-06-18hwmon: (pmbus/dps920ab) Delete some dead codeDan Carpenter1-2/+0
The debugfs_create_dir() function returns error pointers, it doesn't return NULL. But debugfs functions don't need to be checked in normal situations and we can just delete this code. Fixes: 1f442e213ce5 ("hwmon: (pmbus) Add driver for Delta DPS-920AB PSU") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/YMyjmR54ErLtc1sH@mwanda Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (ntc_thermistor) Drop unused headers.Jonathan Cameron1-4/+0
The IIO usage in this driver is purely consumer so it should only be including linux/iio/consumer.h Whilst here drop pm_runtime.h as there is no runtime power management in the driver. Found using include-what-you-use and manual inspection of the suggestions. Signed-off-by: Jonathan Cameron <[email protected]> Cc: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17MAINTAINERS: Add Delta DPS920AB PSU driverRobert Marko1-0/+7
Add maintainers entry for the Delta DPS920AB PSU driver. Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17dt-bindings: trivial-devices: Add Delta DPS920ABRobert Marko1-0/+2
Add trivial device entry for Delta DPS920AB PSU. Signed-off-by: Robert Marko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Add driver for Delta DPS-920AB PSURobert Marko5-0/+292
This adds support for the Delta DPS-920AB PSU. Only missing feature is fan control which the PSU supports. Signed-off-by: Robert Marko <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Add MODULE_IMPORT_NS(PMBUS);] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus/pim4328) Add documentation for the pim4328 PMBus driverErik Rosen2-0/+106
Add documentation and index link for pim4328 PMBus driver. Signed-off-by: Erik Rosen <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus/pim4328) Add PMBus driver for PIM4006, PIM4328 and PIM4820Erik Rosen3-0/+243
Add hardware monitoring support for Flex power interface modules PIM4006, PIM4328 and PIM4820. Signed-off-by: Erik Rosen <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Allow phase function even if it's not on pageErik Rosen1-8/+8
Allow the use of a phase function even if it does not exist on the associated page. Signed-off-by: Erik Rosen <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Add support for reading direct mode coefficientsErik Rosen2-0/+124
Add support for reading and decoding direct format coefficients to the PMBus core driver. If the new flag PMBUS_USE_COEFFICIENTS_CMD is set, the driver will use the COEFFICIENTS register together with the information in the pmbus_sensor_attr structs to initialize relevant coefficients for the direct mode format. Signed-off-by: Erik Rosen <[email protected]> [groeck: Initialize ret with -EINVAL in pmbus_init_coefficients()] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Add new pmbus flag NO_WRITE_PROTECTErik Rosen2-3/+14
Some PMBus chips respond with invalid data when reading the WRITE_PROTECT register. For such chips, this flag should be set so that the PMBus core driver doesn't use the WRITE_PROTECT command to determine its behavior. Signed-off-by: Erik Rosen <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17docs: hwmon: adm1177.rst: avoid using ReSt :doc:`foo` markupMauro Carvalho Chehab1-1/+2
The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/32b0db7e79a3ed0e817213113c607a1b819e3867.1622898327.git.mchehab+huawei@kernel.org Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus_core) Check adapter PEC supportMadhava Reddy Siddareddygari1-3/+6
Currently, for Packet Error Checking (PEC) only the controller is checked for support. This causes problems on the cisco-8000 platform where a SMBUS transaction errors are observed. This is because PEC has to be enabled only if both controller and adapter support it. Added code to check PEC capability for adapter and enable it only if both controller and adapter supports PEC. Signed-off-by: Madhava Reddy Siddareddygari <[email protected]> [Upstream from SONiC https://github.com/Azure/sonic-linux-kernel/pull/215] Signed-off-by: Paul Menzel <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Dropped unnecessary continuation line] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (ina3221) use CVRF only for single-shot conversionNinad Malwade1-11/+11
As per current logic the wait time per conversion is arouns 430ms for 512 samples and around 860ms for 1024 samples for 3 channels considering 140us as the bus voltage and shunt voltage sampling conversion time. This waiting time is a lot for the continuous mode and even for the single shot mode. For continuous mode when moving average is considered the waiting for CVRF bit is not required and the data from the previous conversion is sufficuent. As mentioned in the datasheet the conversion ready bit is provided to help coordinate single-shot conversions, we can restrict the use to single-shot mode only. Also, the conversion time is for the averaged samples, the wait time for the polling can omit the number of samples consideration. Signed-off-by: Ninad Malwade <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (max31790) Detect and report zero fan speedGuenter Roeck1-1/+6
If a fan is not running or not connected, of if fan monitoring is disabled, the fan count register returns a fixed value of 0xffe0. So far this is then translated to a RPM value larger than 0. Since this is misleading and does not really make much sense, report a fan RPM of 0 in this situation. Cc: Jan Kundrát <[email protected]> Cc: Václav Kubernát <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Tested-by: Václav Kubernát <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-06-17hwmon: (max31790) Clear fan fault after reporting itGuenter Roeck1-1/+15
Fault bits in MAX31790 are sticky and have to be cleared explicitly. A write operation into either the 'Target Duty Cycle' register or the 'Target Count' register is necessary to clear a fault. At the same time, we can never clear cached fault status values before reading them because the companion fault status for any given fan is cleared as well when clearing a fault. Cc: Jan Kundrát <[email protected]> Cc: Václav Kubernát <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Tested-by: Václav Kubernát <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-06-17hwmon: (max31790) Fix pwmX_enable attributesGuenter Roeck2-16/+27
pwmX_enable supports three possible values: 0: Fan control disabled. Duty cycle is fixed to 0% 1: Fan control enabled, pwm mode. Duty cycle is determined by values written into Target Duty Cycle registers. 2: Fan control enabled, rpm mode Duty cycle is adjusted such that fan speed matches the values in Target Count registers The current code does not do this; instead, it mixes pwm control configuration with fan speed monitoring configuration. Worse, it reports that pwm control would be disabled (pwmX_enable==0) when it is in fact enabled in pwm mode. Part of the problem may be that the chip sets the "TACH input enable" bit on its own whenever the mode bit is set to RPM mode, but that doesn't mean that "TACH input enable" accurately reflects the pwm mode. Fix it up and only handle pwm control with the pwmX_enable attributes. In the documentation, clarify that disabling pwm control (pwmX_enable=0) sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN is set together with RPM_MODE. While at it, only update the configuration register if the configuration has changed, and only update the cached configuration if updating the chip configuration was successful. Cc: Jan Kundrát <[email protected]> Cc: Václav Kubernát <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Tested-by: Václav Kubernát <[email protected]> Reviewed-by: Jan Kundrát <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-06-17hwmon: (max31790) Report correct current pwm duty cyclesGuenter Roeck2-4/+5
The MAX31790 has two sets of registers for pwm duty cycles, one to request a duty cycle and one to read the actual current duty cycle. Both do not have to be the same. When reporting the pwm duty cycle to the user, the actual pwm duty cycle from pwm duty cycle registers needs to be reported. When setting it, the pwm target duty cycle needs to be written. Since we don't know the actual pwm duty cycle after a target pwm duty cycle has been written, set the valid flag to false to indicate that actual pwm duty cycle should be read from the chip instead of using cached values. Cc: Jan Kundrát <[email protected]> Cc: Václav Kubernát <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Tested-by: Václav Kubernát <[email protected]> Reviewed-by: Jan Kundrát <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-06-17hwmon: (max31790) Fix fan speed reporting for fan7..12Guenter Roeck1-1/+1
Fans 7..12 do not have their own set of configuration registers. So far the code ignored that and read beyond the end of the configuration register range to get the tachometer period. This resulted in more or less random fan speed values for those fans. The datasheet is quite vague when it comes to defining the tachometer period for fans 7..12. Experiments confirm that the period is the same for both fans associated with a given set of configuration registers. Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API") Fixes: 195a4b4298a7 ("hwmon: Driver for Maxim MAX31790") Cc: Jan Kundrát <[email protected]> Reviewed-by: Jan Kundrát <[email protected]> Cc: Václav Kubernát <[email protected]> Reviewed-by: Jan Kundrát <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-06-17hwmon: (sht4x) Fix sht4x_read_values return valueJoe Perches1-50/+45
Kernel doc for sht4x_read_values() shows 0 on success, 1 on failure but the return value on success is actually always positive as it is set to SHT4X_RESPONSE_LENGTH by a successful call to i2c_master_recv(). Miscellanea: o Update the kernel doc for sht4x_read_values to 0 for success or -ERRNO o Remove incorrectly used kernel doc /** header for other _read functions o Typo fix succesfull->successful o Reverse a test to unindent a block and use goto unlock o Declare cmd[SHT4X_CMD_LEN] rather than cmd[] At least for gcc 10.2, object size is reduced a tiny bit. $ size drivers/hwmon/sht4x.o* text data bss dec hex filename 1752 404 256 2412 96c drivers/hwmon/sht4x.o.new 1825 404 256 2485 9b5 drivers/hwmon/sht4x.o.old Signed-off-by: Joe Perches <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed by: Navin Sankar Velliangiri <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: Add sht4x Temperature and Humidity Sensor DriverNavin Sankar Velliangiri5-0/+359
This patch adds a hwmon driver for the SHT4x Temperature and Humidity sensor. Signed-off-by: Navin Sankar Velliangiri <[email protected]> [groeck: dropped unnecessary empty line and continuation lines] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17docs: hwmon: Add an entry for mp2888Fabio Estevam1-0/+1
The entry for mp2888 is missing and it causes the following 'make htmldocs' build warning: Documentation/hwmon/mp2888.rst: WARNING: document isn't included in any toctree Add the mp2888 entry. Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (adm1275) enable adm1272 temperature reportingChu Lin1-8/+6
adm1272 supports temperature reporting but it is disabled by default. Tested: ls temp1_* temp1_crit temp1_highest temp1_max temp1_crit_alarm temp1_input temp1_max_alarm cat temp1_input 26642 Signed-off-by: Chu Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Updated subject to reflect correct driver] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17dt-bindings: Add MP2888 voltage regulator deviceVadim Pasternak1-0/+2
Monolithic Power Systems, Inc. (MPS) dual-loop, digital, multi-phase controller. Signed-off-by: Vadim Pasternak <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Add support for MPS Multi-phase mp2888 controllerVadim Pasternak4-0/+531
Add support for mp2888 device from Monolithic Power Systems, Inc. (MPS) vendor. This is a digital, multi-phase, pulse-width modulation controller. This device supports: - One power rail. - Programmable Multi-Phase up to 10 Phases. - PWM-VID Interface - One pages 0 for telemetry. - Programmable pins for PMBus Address. - Built-In EEPROM to Store Custom Configurations. - Can configured VOUT readout in direct or VID format and allows setting of different formats on rails 1 and 2. For VID the following protocols are available: VR13 mode with 5-mV DAC; VR13 mode with 10-mV DAC, IMVP9 mode with 5-mV DAC. Signed-off-by: Vadim Pasternak <[email protected]> Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Add MODULE_IMPORT_NS] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Increase maximum number of phases per pageVadim Pasternak1-1/+1
Increase maximum number of phases from 8 to 10 to support multi-phase devices allowing up to 10 phases. Signed-off-by: Vadim Pasternak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (bt1-pvt) Remove redundant error printing in pvt_request_regs()Zhen Lei1-3/+1
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zhen Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Add support for additional Flex BMR converters to pmbusErik Rosen3-9/+28
Add support for Flex BMR310, BMR456, BMR457, BMR458, BMR480, BMR490, BMR491 and BMR492 to the pmbus driver Signed-off-by: Erik Rosen <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Fixed minor whitespace error] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Add documentation for new flagsErik Rosen1-4/+38
Add documentation for the new pmbus flags PMBUS_WRITE_PROTECTED, PMBUS_NO_CAPABILITY and PMBUS_READ_STATUS_AFTER_FAILED_CHECK Signed-off-by: Erik Rosen <[email protected]> Link: https://lore.kernel.org/r/[email protected] [groeck: Added newline at end of file] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus) Add new flag PMBUS_READ_STATUS_AFTER_FAILED_CHECKErik Rosen2-0/+15
Some PMBus chips end up in an undefined state when trying to read an unsupported register. For such chips, it is necessary to reset the chip pmbus controller to a known state after a failed register check. This can be done by reading a known register. By setting this flag the driver will try to read the STATUS register after each failed register check. This read may fail, but it will put the chip into a known state. Signed-off-by: Erik Rosen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (sch56xx-common) Simplify sch56xx_device_addArmin Wolf1-23/+4
Use platform_device_register_simple() instead of manually calling platform_device_alloc()/platform_device_add(). Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (sch56xx-common) Use helper functionArmin Wolf1-4/+3
Use watchdog_set_nowayout() to process param setting and change param type to bool. Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (sch56xx-common) Use strscpyArmin Wolf1-2/+1
strlcpy is considered deprecated. Replace it with strscpy. Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (sch56xx) Use devres functions for watchdogArmin Wolf4-43/+16
Use devm_kzalloc()/devm_watchdog_register() for watchdog registration since it allows us to remove the sch56xx_watchdog_data struct from the drivers own data structs. Remove sch56xx_watchdog_unregister since devres takes care of that now. Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> [groeck: Dropped unnecessary return; at end of void function] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (lm70) Use SPI_MODE_X_MASKAndy Shevchenko1-1/+1
Use SPI_MODE_X_MASK instead of open coded variant. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (max31722) Remove non-standard ACPI device IDsGuenter Roeck1-9/+0
Valid Maxim Integrated ACPI device IDs would start with MXIM, not with MAX1. On top of that, ACPI device IDs reflecting chip names are almost always invalid. Remove the invalid ACPI IDs. Fixes: 04e1e70afec6 ("hwmon: (max31722) Add support for MAX31722/MAX31723 temperature sensors") Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (lm70) Revert "hwmon: (lm70) Add support for ACPI"Guenter Roeck1-25/+1
This reverts commit b58bd4c6dfe709646ed9efcbba2a70643f9bc873. None of the ACPI IDs introduced with the reverted patch is a valid ACPI device ID. Any ACPI users of this driver are advised to use PRP0001 and a devicetree-compatible device identification. Fixes: b58bd4c6dfe7 ("hwmon: (lm70) Add support for ACPI") Cc: Andrej Picej <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17docs: hwmon: avoid using UTF-8 charsMauro Carvalho Chehab2-2/+2
While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+2010 ('‐'): HYPHEN - U+2013 ('–'): EN DASH - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/ccdd1bf45963a7748188a97c75f667b37bd43d2f.1620641727.git.mchehab+huawei@kernel.org Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17docs: hwmon: ir36021.rst: replace some charactersMauro Carvalho Chehab1-1/+1
The conversion tools used during DocBook/LaTeX/html/Markdown->ReST conversion and some cut-and-pasted text contain some characters that aren't easily reachable on standard keyboards and/or could cause troubles when parsed by the documentation build system. Replace the occurences of the following characters: - U+2010 ('‐'): HYPHEN as ASCII HYPHEN is preferred over U+2010 Signed-off-by: Mauro Carvalho Chehab <[email protected]> Link: https://lore.kernel.org/r/ba8b5122ac9d4918fd966d0eb0a5ca9d89044b04.1621159997.git.mchehab+huawei@kernel.org Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17dt-bindings: hwmon: Add Texas Instruments TMP1075Robert Marko1-0/+1
Document the DT compatible for TI TMP1075 which is a LM75 compatible sensor. Signed-off-by: Robert Marko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Rob Herring <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (lm75) Add TI TMP1075 supportRobert Marko2-2/+17
TI TMP1075 is a LM75 compatible sensor, so lets add support for it. Signed-off-by: Robert Marko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus/zl6100) Update documentation for zl6100 driverErik Rosen1-43/+89
Update documentation for zl6100 driver and fix dead links to technical specifications Signed-off-by: Erik Rosen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus/zl6100) Add support for ZLS1003, ZLS4009 and ZL8802Erik Rosen1-14/+80
Add support for Renesas ZL8802 Dual Channel/Dual Phase PMBus DC/DC Digital Controller as well as ZLS1003 and ZLS4009 custom DC/DC controller chips. Signed-off-by: Erik Rosen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-17hwmon: (pmbus/bpa-rs600) Handle Vin readings >= 256VChris Packham1-0/+29
The BPA-RS600 doesn't follow the PMBus spec for linear data. Specifically it treats the mantissa as an unsigned 11-bit value instead of a two's complement 11-bit value. At this point it's unclear whether this only affects Vin or if Pin/Pout1 are affected as well. Erring on the side of caution only Vin is dealt with here. Fixes: 15b2703e5e02 ("hwmon: (pmbus) Add driver for BluTek BPA-RS600") Signed-off-by: Chris Packham <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2021-06-13Linux 5.13-rc6Linus Torvalds1-1/+1
2021-06-13Merge tag 'perf-tools-fixes-for-v5.13-2021-06-13' of ↵Linus Torvalds2-5/+3
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Correct buffer copying when peeking events - Sync cpufeatures/disabled-features.h header with the kernel sources * tag 'perf-tools-fixes-for-v5.13-2021-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: tools headers cpufeatures: Sync with the kernel sources perf session: Correct buffer copying when peeking events
2021-06-13Merge tag 'nfs-for-5.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds5-13/+33
Pull NFS client bugfixes from Trond Myklebust: "Highlights include: Stable fixes: - Fix use-after-free in nfs4_init_client() Bugfixes: - Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode() - Fix second deadlock in nfs4_evict_inode() - nfs4_proc_set_acl should not change the value of NFS_CAP_UIDGID_NOMAP - Fix setting of the NFS_CAP_SECURITY_LABEL capability" * tag 'nfs-for-5.13-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4: Fix second deadlock in nfs4_evict_inode() NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode() NFS: FMODE_READ and friends are C macros, not enum types NFS: Fix a potential NULL dereference in nfs_get_client() NFS: Fix use-after-free in nfs4_init_client() NFS: Ensure the NFS_CAP_SECURITY_LABEL capability is set when appropriate NFSv4: nfs4_proc_set_acl needs to restore NFS_CAP_UIDGID_NOMAP on error.
2021-06-13Merge tag 'scsi-fixes' of ↵Linus Torvalds1-21/+26
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Four reasonably small fixes to the core for scsi host allocation failure paths. The root problem is that we're not freeing the memory allocated by dev_set_name(), which involves a rejig of may of the free on error paths to do put_device() instead of kfree which, in turn, has several other knock on ramifications and inspection turned up a few other lurking bugs" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: core: Only put parent device if host state differs from SHOST_CREATED scsi: core: Put .shost_dev in failure path if host state changes to RUNNING scsi: core: Fix failure handling of scsi_add_host_with_dma() scsi: core: Fix error handling of scsi_host_alloc()
2021-06-12Merge tag 'riscv-for-linus-5.13-rc6' of ↵Linus Torvalds6-16/+36
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A pair of XIP fixes: one to fix alternatives, and one to turn off the rest of the features that require code modification - A fix to a type that was causing some alternatives to break - A build fix for BUILTIN_DTB * tag 'riscv-for-linus-5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Fix BUILTIN_DTB for sifive and microchip soc riscv: alternative: fix typo in macro name riscv: code patching only works on !XIP_KERNEL riscv: xip: support runtime trap patching
2021-06-12mm: relocate 'write_protect_seq' in struct mm_structFeng Tang1-7/+20
0day robot reported a 9.2% regression for will-it-scale mmap1 test case[1], caused by commit 57efa1fe5957 ("mm/gup: prevent gup_fast from racing with COW during fork"). Further debug shows the regression is due to that commit changes the offset of hot fields 'mmap_lock' inside structure 'mm_struct', thus some cache alignment changes. From the perf data, the contention for 'mmap_lock' is very severe and takes around 95% cpu cycles, and it is a rw_semaphore struct rw_semaphore { atomic_long_t count; /* 8 bytes */ atomic_long_t owner; /* 8 bytes */ struct optimistic_spin_queue osq; /* spinner MCS lock */ ... Before commit 57efa1fe5957 adds the 'write_protect_seq', it happens to have a very optimal cache alignment layout, as Linus explained: "and before the addition of the 'write_protect_seq' field, the mmap_sem was at offset 120 in 'struct mm_struct'. Which meant that count and owner were in two different cachelines, and then when you have contention and spend time in rwsem_down_write_slowpath(), this is probably *exactly* the kind of layout you want. Because first the rwsem_write_trylock() will do a cmpxchg on the first cacheline (for the optimistic fast-path), and then in the case of contention, rwsem_down_write_slowpath() will just access the second cacheline. Which is probably just optimal for a load that spends a lot of time contended - new waiters touch that first cacheline, and then they queue themselves up on the second cacheline." After the commit, the rw_semaphore is at offset 128, which means the 'count' and 'owner' fields are now in the same cacheline, and causes more cache bouncing. Currently there are 3 "#ifdef CONFIG_XXX" before 'mmap_lock' which will affect its offset: CONFIG_MMU CONFIG_MEMBARRIER CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES The layout above is on 64 bits system with 0day's default kernel config (similar to RHEL-8.3's config), in which all these 3 options are 'y'. And the layout can vary with different kernel configs. Relayouting a structure is usually a double-edged sword, as sometimes it can helps one case, but hurt other cases. For this case, one solution is, as the newly added 'write_protect_seq' is a 4 bytes long seqcount_t (when CONFIG_DEBUG_LOCK_ALLOC=n), placing it into an existing 4 bytes hole in 'mm_struct' will not change other fields' alignment, while restoring the regression. Link: https://lore.kernel.org/lkml/20210525031636.GB7744@xsang-OptiPlex-9020/ [1] Reported-by: kernel test robot <[email protected]> Signed-off-by: Feng Tang <[email protected]> Reviewed-by: John Hubbard <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Cc: Peter Xu <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-06-12Merge tag 'usb-5.13-rc6' of ↵Linus Torvalds40-144/+357
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are a number of tiny USB fixes for 5.13-rc6. There are more than I would normally like, but there's been a bunch of people banging on the gadget and dwc3 and typec code recently for I think an Android release, which has resulted in a number of small fixes. It's nice to see companies send fixes upstream for this type of work, a notable change from years ago. Anyway, fixes in here are: - usb-serial device id updates - usb-serial cp210x driver fixes for broken firmware versions - typec fixes for crazy charging devices and other reported problems - dwc3 fixes for reported problems found - gadget fixes for reported problems - tiny xhci fixes - other small fixes for reported issues. - revert of a problem fix found by linux-next testing All of these have passed 0-day and linux-next testing with no reported problems (the revert for the found linux-next build problem included)" * tag 'usb-5.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (44 commits) Revert "usb: gadget: fsl: Re-enable driver for ARM SoCs" usb: typec: mux: Fix copy-paste mistake in typec_mux_match usb: typec: ucsi: Clear PPM capability data in ucsi_init() error path usb: gadget: fsl: Re-enable driver for ARM SoCs usb: typec: wcove: Use LE to CPU conversion when accessing msg->header USB: serial: cp210x: fix CP2102N-A01 modem control USB: serial: cp210x: fix alternate function for CP2102N QFN20 usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource() usb: dwc3: ep0: fix NULL pointer exception usb: gadget: eem: fix wrong eem header operation usb: typec: intel_pmc_mux: Put ACPI device using acpi_dev_put() usb: typec: intel_pmc_mux: Add missed error check for devm_ioremap_resource() usb: typec: intel_pmc_mux: Put fwnode in error case during ->probe() usb: typec: tcpm: Do not finish VDM AMS for retrying Responses usb: fix various gadget panics on 10gbps cabling usb: fix various gadgets null ptr deref on 10gbps cabling. usb: pci-quirks: disable D3cold on xhci suspend for s2idle on AMD Renoir usb: f_ncm: only first packet of aggregate needs to start timer USB: f_ncm: ncm_bitrate (speed) is unsigned MAINTAINERS: usb: add entry for isp1760 ...
Powered by cgit, Gruvboxed by Blaster4385.