- Dec 05, 2022
-
-
Aleksa Savic authored
Add support for reading and writing flow sensor pulses value on the Aquacomputer Quadro. Implemented by Leonard Anderweit [1]. [1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/pull/45 Originally-from: Leonard Anderweit <leonard.anderweit@gmail.com> Signed-off-by:
Aleksa Savic <savicaleksa83@gmail.com> Link: https://lore.kernel.org/r/20221126071313.34356-1-savicaleksa83@gmail.com Signed-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Joaquín Ignacio Aramendía authored
Add support for the AOK ZOE A1 and OXP Mini PRO handheld devices. DMI strings are added to this driver since the same EC layout is used and has similar specs as the OXP mini AMD. The added devices are: - OneXPlayer mini PRO (AMD 6800U) - AOK ZOE A1 (AMD 6800U) Signed-off-by:
Joaquín Ignacio Aramendía <samsagax@gmail.com> Link: https://lore.kernel.org/r/20221125114901.11309-1-samsagax@gmail.com Signed-off-by:
-
Joaquín Ignacio Aramendía authored
Sensors driver for OXP Handhelds from One-Netbook that expose fan reading and control via hwmon sysfs. As far as I could gather all OXP boards have the same DMI strings and they can be told appart only by the boot cpu vendor (Intel/AMD). Currently only AMD boards are supported since Intel have different EC registers and values to read/write. Fan control is provided via pwm interface in the range [0-255]. AMD boards have [0-100] as range in the EC, the written value is scaled to accommodate for that. Signed-off-by:
-
Quan Nguyen authored
Improve documentation grammar and formatting for the Ampere(R)'s Altra(R) SMpro hwmon driver. Thanks Bagas for the changes in the link below. Link: https://lore.kernel.org/lkml/Y1aHiaZ1OpHZIzS9@google.com/T/#mfea2167b99384486a1b75d9304536015116c1821 Signed-off-by:
Quan Nguyen <quan@os.amperecomputing.com> Reviewed-by:
Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20221102062103.3135417-1-quan@os.amperecomputing.com Signed-off-by:
-
Aleksa Savic authored
Add support for reading and writing temperature sensor offsets on the Aquacomputer D5 Next, Farbwerk 360, Octo and Quadro, for which the needed offsets are known. Implemented by Leonard Anderweit [1]. [1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/pull/22 Originally-from: Leonard Anderweit <leonard.anderweit@gmail.com> Signed-off-by:
-
Quan Nguyen authored
Add documentation for the Ampere(R)'s Altra(R) SMpro hwmon driver. Signed-off-by:
Thu Nguyen <thu@os.amperecomputing.com> Signed-off-by:
-
- Oct 22, 2022
-
-
Wilken Gottwalt authored
Also update the documentation accordingly. Signed-off-by:
Wilken Gottwalt <wilken.gottwalt@posteo.net> Link: https://lore.kernel.org/r/Y0FghqQCHG/cX5Jz@monster.localdomain Signed-off-by:
-
- Oct 02, 2022
-
-
Wilken Gottwalt authored
Also updates the documentation accordingly. Signed-off-by:
-
- Sep 25, 2022
-
-
Alexander Stein authored
This adds the enable attribute which is used to select if zero PWM duty means to switch off regulator and PWM or to keep them enabled but at inactive PWM output level. Depending on the select enable mode, turn off the regulator and PWM if the PWM duty is zero, or keep them enabled. This is especially important for fan using inverted PWM signal polarity. Having regulator supplied and PWM disabled, some PWM controllers provide the active, rather than inactive signal. With this change the shutdown as well as suspend/resume paths require modifcations as well. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20220914153137.613982-6-alexander.stein@ew.tq-group.com Signed-off-by:
-
Duke Du authored
Add the pmbus driver for TEXAS tps546d24 Buck Converter. The vout mode of tps546d24 supported relative data format, which is not supported by the PMBus core. Signed-off-by:
Duke Du <dukedu83@gmail.com> Link: https://lore.kernel.org/r/1662951668-9849-1-git-send-email-Duke.Du@quantatw.com [groeck: Add __maybe_unused to tps546d24_of_match declaration] Signed-off-by:
-
- Sep 20, 2022
-
-
Ibrahim Tilki authored
Adding documentation for max31760 fan speed controller Signed-off-by:
Ibrahim Tilki <Ibrahim.Tilki@analog.com> Link: https://lore.kernel.org/r/20220910171945.48088-3-Ibrahim.Tilki@analog.com Signed-off-by:
-
- Sep 19, 2022
-
-
Aleksa Savic authored
Extend aquacomputer_d5next driver to expose various hardware sensors of the Aquacomputer High Flow Next flow sensor, which communicates through a proprietary USB HID protocol. The High Flow Next exposes +5V voltages, water quality, conductivity and flow readings. A temperature sensor can be connected to it, in which case it provides its reading and an estimation of the dissipated/absorbed power in the liquid cooling loop. Additionally, serial number and firmware version are exposed through debugfs. Registry offsets were discovered and tested by users on Github [1] [2]. [1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/issues/8 [2] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/pull/34 Signed-off-by:
-
Michael Shych authored
Add description of emc2305 driver. Signed-off-by:
Michael Shych <michaelsh@nvidia.com> Reviewed-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20220810171552.56417-4-michaelsh@nvidia.com [groeck: Fixed htmldocs warnings] Signed-off-by:
-
Justin Ledford authored
The MAX31790 has a tach input enable bit in each fan's configuration register. This is only enabled by the driver if RPM mode is selected, but the driver doesn't provide a way to independently enable tachometer input regardless of the regulator mode. By adding the fanN_enable sysfs files, we can decouple the tach input from the regulator mode. Also update the documentation. Signed-off-by:
Justin Ledford <justinledford@google.com> Link: https://lore.kernel.org/r/20220829195930.2521755-1-justinledford@google.com Signed-off-by:
-
Wilken Gottwalt authored
Add reporting if the PSU is running in single or multi rail mode via ocpmode debugfs entry. Also update the documentation and driver comments accordingly. Signed-off-by:
-
Aleksa Savic authored
Add support for reading virtual temperature sensors for the D5 Next, Octo, Quadro and Farbwerk 360. Virtual temperature sensors are written to the device by the user, pulling from an arbitrary value source. Writing to them is not yet reverse engineered, so the only way to set them for now is to use the official software. Signed-off-by:
-
Eugene Shalygin authored
This driver utilises a WMI interface found in AMD 500 series ASUS boards, to read EC registers. But it turned out that ASUS abandoned the interface, as it disappeared from Intel 600 series boards. Additionally, the WMI interface was incredibly slow. Therefore this driver was deprecated in favor of the asus_ec_sensors driver, which supports more boards, more sensors, and is faster. Signed-off-by:
Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20220720072016.102086-2-eugene.shalygin@gmail.com Signed-off-by:
-
- Jul 27, 2022
-
-
Aleksa Savic authored
Extend aquacomputer_d5next driver to expose hardware temperature sensors and fans of the Aquacomputer Quadro fan controller, which communicates through a proprietary USB HID protocol. Implemented by Jack Doan [1]. Four temperature sensors and PWM controllable fans are available. The liquid flow sensor is also exposed, implemented by Leonard Anderweit [2]. Additionally, serial number, firmware version and power-on count are exposed through debugfs. This driver has been tested on x86_64. [1] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/pull/5 [2] https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/pull/9 Originally-from: Jack Doan <me@jackdoan.com> Originally-from: Leonard Anderweit <leonard.anderweit@gmail.com> Signed-off-by:
-
Armin Wolf authored
Notify users of this driver that each pwmX attribute controls fan number X, meaning that probing of pwm channels is unnecessary. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20220727083004.5684-1-W_Armin@gmx.de Signed-off-by:
-
- Jul 14, 2022
-
-
Lukas Bulwahn authored
Commit 31b24bee ("docs: add a warning to submitting-drivers.rst") in October 2016 already warns "This (...) should maybe just be deleted, but I'm not quite ready to do that yet". Maybe, six years ago, we were not ready but let us remove old content for the better now and structure and maintain less content in the kernel documentation with a better result. Drop this already outdated document and adjust all textual references. Here is an argument why deleting the content will not remove any useful information to the existing kernel documentation, individually broken down for each section. Section "Allocating Device Numbers" refers to https://www.lanana.org/, and then refers to Documentation/admin-guide/devices.rst. However, the devices.rst clearly states: "The version of this document at lanana.org is no longer maintained." Everything needed for submitting drivers is already stated in devices.rst and the reference to https://www.lanana.org/ is outdated, and should be just deleted. Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before the new release version scheme; the mentioned developers are still around, but actually not the first developers to contact anymore. Section "What Criteria Determine Acceptance" has a few bullet points: Licensing and Copyright is well-covered in process/kernel-license.rst. Interfaces, Code, Portability, Clarity state some obvious things about ensuring kernel code quality. Control suggests to add a MAINTAINERS entry, which is already mentioned in 6.Followthrough.rst: "... added yourself to the MAINTAINERS file..." PM support states a bit about implementing and testing power management of a driver, it remains an open question where to place that in the process documents. Driver developers interested in power management will find the corresponding part on power management in the kernel documentation anyway. In section "What Criteria Do Not Determine Acceptance", the points Vendor and Author states something basic consequence of the kernel being an open-source community software development. Probably no need to mention it nowadays. Section "Resources" lists resources that are also mentioned elsewhere more central. - Linux kernel tree and mailing list is mentioned in many places. - https://lwn.net/Kernel/LDD3/ is mentioned in Documentation/process/kernel-docs.rst. - https://lwn.net/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - https://kernelnewbies.org/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - http://www.linux-usb.org/ is mentioned in Documentation/driver-api/usb/usb.rst - https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf is mentioned in Documentation/process/kernel-docs.rst - https://kernelnewbies.org/KernelJanitors is mentioned in Documentation/process/howto.rst - https://git-scm.com/ is mentioned in - Documentation/process/2.Process.rst - Documentation/process/7.AdvancedTopics.rst - Documentation/process/howto.rst Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Jul 13, 2022
-
-
Urs Schroffenegger authored
Add definitions for ROG ZENITH II EXTREME and some unknown yet temperature sensors in the second EC bank. Details are available at [1, 2]. [1] https://github.com/zeule/asus-ec-sensors/pull/26 [2] https://github.com/zeule/asus-ec-sensors/issues/16 Signed-off-by:
Urs Schroffenegger <nabajour@lampshade.ch> Signed-off-by:
-
Michael Carns authored
Add definitions for ROG MAXIMUS XI HERO and ROG MAXIMUS XI HERO (WI-FI) boards. Signed-off-by:
Michael Carns <mike@carns.com> Signed-off-by:
-
Shady Nawara authored
adds T_Sensor and VRM Temp sensors for the Asus Strix z690-a D4 motherboard Signed-off-by:
Shady Nawara <shady.nawara@outlook.com> Signed-off-by:
-
Guenter Roeck authored
Add support for Analog Devices LT7182S Dual Channel 6A, 20V PolyPhase Step-Down Silent Switcher with Digital Power System Management. Signed-off-by: -
Guenter Roeck authored
NE1618 is similar to NE1617 but supports manufacturer and chip ID registers as well as 11 bit external temperature resolution. Signed-off-by: -
Guenter Roeck authored
ADM1020 is compatible with ADM1021 but has a separate chip revision and a limited I2C address range. Signed-off-by: -
Guenter Roeck authored
NCT218 is compatible to NCT72 and NCT214. It also supports PEC (packet error checking). Similar to NCT72 and NCT214, PEC support is undocumented. Unlike NCT214 and NCT72, NCT218 does not support the undocumented secondary chip and manufacturer ID registers at 0x3e and 0x3f and returns 0x00 when reading those registers. The value for the chip revision register is not documented but was observed to be 0xca. Use that information to improve chip detection accuracy. Signed-off-by: -
Guenter Roeck authored
NCT214 and NCT72 are compatible to ADT7461/ADT7461A but have full PEC (packet error checking) support. PEC support is undocumented. Both chips support the undocumented secondary chip and manufacturer ID registers at 0x3e and 0x3f, and return 0x61 as chip ID. Use this information to improve the accuracy of chip detection code. Signed-off-by: -
Guenter Roeck authored
Unlike ADM1023 and compatible chips, NCT210 does not support a temperature offset register. A real chip was found to have a chip revision of 0x3f. Use it to detect NCT210 explicitly. Signed-off-by: -
Guenter Roeck authored
All chips supported by the ADM1021 driver are also supported by the LM90 driver. Make that support official. After this change, the adm1021 driver is only needed if the lm90 driver is disabled. Also, the adm1021 driver misdetects a variety of chips as MAX1617A, which is unwanted if any of those chips is in the system. For this reason. make the adm1021 driver dependent on !SENSORS_LM90 to show that it is not needed if the lm90 driver is enabled, and to avoid misdetection if a chip supported by the lm90 driver is in the system. Devicetree nodes are not added for the added chips since it is quite unlikely that such old chips will ever be used in a devicetree based system. They can be added later if needed. Signed-off-by: -
Guenter Roeck authored
Both chips are quite similar to other chips of this series, so add support for them to the lm90 driver. Also mention ON Semiconductor NCT210, which is pin and register compatible to ADM1021A. None of the chips support the secondary manufacturer and chip ID registers at 0x3e and 0x3f, but return 0 when reading from those registers. Use that information to improve the accuracy of chip detection code. Devicetree nodes are not added for the added chips since it is quite unlikely that such old chips will ever be used in a devicetree based system. They can be added later if needed. Signed-off-by: -
Guenter Roeck authored
MAX1617 and LM84 are stripped-down versions of LM90, so they can easily be supported by the LM90 driver. The most difficult part is chip detection, since those old chips do not support manufacturer ID or chip ID registers. The "alarms" attribute is enabled for both chips to match the functionality of the adm1021 driver. Chip detection was improved and is less prone to misdetection than the chip detection in the adm1021 driver. Devicetree nodes are not added for the added chips since it is quite unlikely that such old chips will ever be used in a devicetree based system. They can be added later if needed. Signed-off-by: -
Guenter Roeck authored
MAX6642 is a reduced version of LM90 with no low limits and no conversion rate register. Its alert functionality is broken, similar to many other chips supported by the lm90 driver. After this change, the stand-alone max6642 driver is only needed if the lm90 driver is disabled. Make it dependent on SENSORS_LM90=n to show that it is not needed if the lm90 driver is enabled. A devicetree node is not added for this chip since it is quite unlikely that such an old chip will ever be used in a devicetree based system. It can be added later if needed. Signed-off-by: -
Guenter Roeck authored
MAX6690 is all but identical to MAX6654. Revision 1 of its datasheet lists the same chip ID as MAX6654, and a chip labeled MAX6654 was found to have the chip ID listed as MAX6690 chip ID in Revision 2 of its datasheet. A devicetree node is not added for this chip since it is quite unlikely that such an old chip will ever be used in a devicetree based system. It can be added later if needed. Signed-off-by: -
Guenter Roeck authored
ADT7481, ADT7482, and ADT7483 are similar to ADT7461, but support two external temperature sensors, similar to MAX6695/6696. They support an extended temperature range similar to ADT7461. Registers for the second external channel can be accessed directly or by using the same method as used by MAX6695/6696. For simplicity, the access method implemented for MAX6695/6696 is used. The chips support PEC (packet error checking). Set the PEC feature flag and let the user decide if it should be enabled or not (it is by default disabled). Even though it is only documented for ADT7483, all three chips support a secondary manufacturer ID register at 0x3e and a chip ID register at 0x3f. Use the contents of those registers register for improved chip detection accuracy. Add the same check to the ADT7461A detection code since this chip also supports the same (undocumented) registers. Devicetree nodes are not added for the added chips since it is quite unlikely that such old chips will ever be used in a devicetree based system. They can be added later if needed. Reviewed-by:
Slawomir Stepien <sst@poczta.fm> Signed-off-by:
-
Guenter Roeck authored
Unlike MAX6646/MAX6647/MAX6649, MAX6648 and MAX6692 only support a temperature range of 0..127 degrees C. Separate support for the two sets of chips to be able to support maximum temperature ranges correctly for all chips. Introduce new feature flag to indicate temperature support up to 255 degrees C. Since the chips are almost identical except for the supported temperature range, automatic chip detection is limited. Effectively this means that MAX6648 may be mis-detected as MAX6649 when auto-detected, but there is nothing we can do about that. Devicetree nodes are not added for the added chips since it is quite unlikely that such old chips will ever be used in a devicetree based system. They can be added later if needed. Signed-off-by: -
Guenter Roeck authored
Revision 0 of the ADT7461 datasheet suggests that the chip supports PEC (packet error checking). This information is gone in later versions of the datasheet. Experiments show that PEC support on ADT7461 is similar to PEC support in ADM1032, ie it is only supported for read operations. Add support for it to the driver. Signed-off-by: -
Guenter Roeck authored
PEC (packet error checking) support for ADM1032 is currently only enabled if the chip was auto-detected, but not if a chip is instantiated explicitly. Always enable PEC support by introducing a chip feature flag indicating partial PEC support. Also, for consistency, disable PEC support by default to match existing functionality if the chip was not auto- detected. At the same time, introduce generic support for PEC with a separate feature flag. This will be used when support for chips with full PEC functionality is added. Signed-off-by: -
Guenter Roeck authored
Enabling and disabling PEC for PMBus devices is currently only supported with a debugfs attribute, which requires debugfs to be enabled and is thus less than perfect. Take the lm90 driver as example and add a 'pec' attribute to the I2C device if both the I2C adapter and the PMBus device support it. Remove the now obsolete 'pec' attribute from debugfs. Cc: Andrew Jeffery <andrew@aj.id.au> Signed-off-by:
-
- May 22, 2022
-
-
Guenter Roeck authored
Various attempts were made recently to "convert" the old hwmon_device_register() API to devm_hwmon_device_register_with_info() by just changing the function name without actually converting the driver. Prevent this from happening by making the 'chip' parameter of devm_hwmon_device_register_with_info() mandatory. Signed-off-by:
-
