- 01 12月, 2017 1 次提交
-
-
由 Peter Rosin 提交于
With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver is not always capable of avoiding the 25-35 ms timeout as specified by the SMBUS protocol. This may cause silent corruption of the last bit of any transfer, e.g. a one is read instead of a zero if the sensor chip times out. This also affects the eeprom half of the nxp-se97 chip, where this silent corruption was originally noticed. Other I2C adapters probably suffer similar issues, e.g. bit-banging comes to mind as risky... The SMBUS register in the nxp chip is not a standard Jedec register, but it is not special to the nxp chips either, at least the atmel chips have the same mechanism. Therefore, do not special case this on the manufacturer, it is opt-in via the device property anyway. Cc: stable@vger.kernel.org # 4.9+ Signed-off-by: NPeter Rosin <peda@axentia.se> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 28 11月, 2017 1 次提交
-
-
由 Robert Lippert 提交于
Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Fixes: 442aba78 ("hwmon: PMBus device driver") Signed-off-by: NRobert Lippert <rlippert@google.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 16 11月, 2017 5 次提交
-
-
由 Andy Shevchenko 提交于
Since i2c_unregister_device() became NULL-aware we may remove duplicate NULL check. Cc: Rudolf Marek <r.marek@assembler.cz> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Andy Shevchenko 提交于
Since i2c_unregister_device() became NULL-aware we may remove duplicate NULL check. Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Andy Shevchenko 提交于
Since i2c_unregister_device() became NULL-aware we may remove duplicate NULL check. Cc: Marc Hulsman <m.hulsman@tudelft.nl> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Andy Shevchenko 提交于
Since i2c_unregister_device() became NULL-aware we may remove duplicate NULL check. Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-hwmon@vger.kernel.org Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Acked-by: NWolfram Sang <wsa@the-dreams.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
Ryzen 1600X is a Ryzen 5 processor. Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 05 11月, 2017 2 次提交
-
-
由 Andrew Jeffery 提交于
The Maxim MAX31785 is a PMBus device providing closed-loop, multi-channel fan management with temperature and remote voltage sensing. It supports various fan control features, including PWM frequency control, temperature hysteresis, dual tachometer measurements, and fan health monitoring. This patch presents a basic driver using only the existing features of the PMBus subsystem. Signed-off-by: NAndrew Jeffery <andrew@aj.id.au> [groeck: Modified description to clarify that fan control is not yet provided] Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Joel 提交于
Sort the headers in preperation for future changes. Signed-off-by: NJoel Stanley <joel@jms.id.au> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 01 11月, 2017 1 次提交
-
-
由 hotran 提交于
This patch removes the un-necessary ifdef CONFIG_ACPI and directly uses the acpi_match_table from the driver pdev. Signed-off-by: NHoan Tran <hotran@apm.com> [groeck: Dropped unnecessary initialization] Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 30 10月, 2017 23 次提交
-
-
由 Dan Carpenter 提交于
We intended to test for failure here but accidentally tested for success. It means that we don't set "*val" to true and it means that if i2c_smbus_write_byte() does fail then we return success. Fixes: e7895864b0d7 ("hwmon: (max6621) Add support for Maxim MAX6621 temperature sensor") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NVadim Pasternak <vadimp@mellanox.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Colin Ian King 提交于
The setting of newval to zero is redundant as the following if/else stanzas will always update newval to a new value. Remove the redundant setting, cleans up clang build warning: drivers/hwmon/asc7621.c:582:2: warning: Value stored to 'newval' is never read Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 hotran 提交于
This patch supports xgene-hwmon v2 which uses the non-cachable memory as the PCC shared memory. Signed-off-by: NHoan Tran <hotran@apm.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Miquel Raynal 提交于
A previous commit changed the argument list of gpio_fan_get_of_data(), removing the "struct *dev" argument and retrieving it instead from the gpio_fan_data structure. The "dev" entry of gpio_fan_data was then dereferenced to access the of_node field, leading to a kernel panic during the probe as the "dev" entry of the gpio_fan_data structure was not filled yet. Fix this by setting fan_data->dev before calling gpio_fan_get_of_data(). Fixes: 5859d8d30737 ("hwmon: (gpio-fan) Get rid of platform data struct") Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
This converts the GPIO fan driver to use GPIO descriptors. This way we avoid indirection since the gpiolib anyway just use descriptors inside, and we also get rid of explicit polarity handling: the descriptors internally knows if the line is active high or active low. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> [groeck: Line length] Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
The "ctrl" and "num_ctrl" entries in the state container struct is ambiguously named "ctrl" and "num_ctrl" overlapping with some hwmon lingo and making it hard to understand. Since this array actually contains the GPIO line numbers, from the Linux global GPIO numberspace, used to control the different fan speeds. Rename these fields to "gpios" (pluralis) and "num_gpios" so as to make it unambiguous. Convert some instances of "unsigned" to "unsigned int" to keep checkpatch happy. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
There is no point in storing the GPIO alarm settings in their own struct so merge this into the main state container. Convert the variables from "unsigned" to "unsigned int" to make checkpatch happy. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
We are not passing the platform data struct into the driver from the outside, there is no point of having it around separately so instead of first populating the platform data struct and assigning the result into the same variables in the state container (struct gpio_fan_data) just assign the configuration from the device tree directly into the state container members. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
We have no users of platform data, we made platform data driver-local, so cut all #ifdefs for the platform data case, and depend on the Kconfig CONFIG_OF_GPIO symbol. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
The driver is storing the struct platform_device *pdev pointer but what it is really using and want to pass around is a struct device *dev pointer. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
There is not a single user of the platform data header in <linux/gpio-fan.h>. We can conclude that all current users are probing from the device tree, so start simplifying the code by pulling the header into the driver. Convert "unsigned" to "unsigned int" in the process to make checkpatch happy. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
Create local struct device *dev and device_node *np pointers to make the code easier to read. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Vadim Pasternak 提交于
MAX6621 is a PECI-to-I2C translator provides an efficient, low-cost solution for PECI-to-SMBus/I2C protocol conversion. It allows reading the temperature from the PECI-compliant host directly from up to four PECI-enabled CPUs. Signed-off-by: NVadim Pasternak <vadimp@mellanox.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Colin Ian King 提交于
Don't populate const array watchdog_minors on the stack, instead make it static. Makes the object code smaller by over 350 bytes: Before: text data bss dec hex filename 48019 38144 256 86419 15193 drivers/hwmon/w83793.o After: text data bss dec hex filename 47574 38232 256 86062 1502e drivers/hwmon/w83793.o (gcc 6.3.0, x86-64) Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Patrick Venture 提交于
The previous value reduced the time required to determine the fan value, however, it's also used as the final timeout mechanism. The prevous value would work for any fan speed greater than around 3k RPM. This increased value, lets the fan speeds return quickly but will wait longer to handle speeds below 3k RPM. Testing: this value was determined through experimentation on the ast2400 on the Quanta-q71l. This configurations runs 8 fans attached to the controller. Signed-off-by: NPatrick Venture <venture@google.com> Reviewed-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Alan Tull 提交于
Add new device tree binding for max1619. Signed-off-by: NAlan Tull <atull@kernel.org> Cc: Jean Delvare <jdelvare@suse.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Colin Ian King 提交于
A previous commit removed bit or'ing into to the integer status so now status is now always zero. This means that the non-zero check on status and the sht15_send_status call will never occur; it is deadcode. Clean this up by removing the dead code. Detected by: CoverityScan CID#1456835 ("Logically dead code") Fixes: aa7ab80c578c ("hwmon: (sht15) Root out platform data") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Linus Walleij 提交于
After finding out there are active users of this sensor I noticed: - It has a single PXA27x board file using the platform data - The platform data is only used to carry two GPIO pins, all other fields are unused - The driver does not use GPIO descriptors but the legacy GPIO API I saw we can swiftly fix this by: - Killing off the platform data entirely - Define a GPIO descriptor lookup table in the board file - Use the standard devm_gpiod_get() to grab the GPIO descriptors from either the device tree or the board file table. This compiles, but needs testing. Cc: arm@kernel.org Cc: Marco Franchi <marco.franchi@nxp.com> Cc: Davide Hug <d@videhug.ch> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Tested-by: NMarco Franchi <marco.franchi@nxp.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
Add support for handling temperature offset values for various AMD CPUs, similar to the code used in the coretemp driver for Intel CPUs. This is primarily for Ryzen CPUs (which has documented temperature offsets), but the code is kept generic to simplify adding additional CPUs. Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
Add support for temperature sensors on Family 17h (Ryzen) processors. Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Guenter Roeck 提交于
Introduce a local data structure and determine the temperature read function at probe time to reduce runtime complexity. Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Jean Delvare 提交于
Function snprintf already cares for the terminating NUL at the end of the string, the caller doesn't need to do it. Signed-off-by: NJean Delvare <jdelvare@suse.de> Cc: Andrea Merello <andrea.merello@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Edward A. James 提交于
The pmbus core may call read/write word data functions with a page value of -1, intending to perform the operation without setting the page. However, the read/write word data functions accept only unsigned 8-bit page numbers, and therefore cannot check for negative page number to avoid setting the page. This results in setting the page number to 0xFF. This may result in errors or undefined behavior of some devices (specifically the ir35221, which allows the page to be set to 0xFF, but some subsequent operations to read registers may fail). Switch the pmbus_set_page page parameter to an integer and perform the check for negative page there. Make read/write functions consistent in accepting an integer page number parameter. Signed-off-by: NEdward A. James <eajames@us.ibm.com> Fixes: cbcdec62 ("hwmon: (pmbus): Access word data for STATUS_WORD") Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 24 10月, 2017 1 次提交
-
-
由 Guenter Roeck 提交于
Commit 3d8f7a89 ("hwmon: (tmp102) Improve handling of initial read delay") reduced the initial temperature read delay and made it dependent on the chip's shutdown mode. If the chip was not in shutdown mode at probe, the read delay no longer applies. This ignores the fact that the chip initialization changes the temperature sensor resolution, and that the temperature register values change when the resolution is changed. As a result, the reported temperature is twice as high as the real temperature until the first temperature conversion after the configuration change is complete. This can result in unexpected behavior and, worst case, in a system shutdown. To fix the problem, let's just always wait for a conversion to complete before reporting a temperature. Fixes: 3d8f7a89 ("hwmon: (tmp102) Improve handling of initial read delay") Link: https://bugzilla.kernel.org/show_bug.cgi?id=197167Reported-by: NRalf Goebel <ralf.goebel@imago-technologies.com> Cc: Ralf Goebel <ralf.goebel@imago-technologies.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 22 10月, 2017 1 次提交
-
-
由 Martyn Welch 提交于
The TSI channel, which is usually used for touchscreen support, but can be used as 4 general purpose ADCs. When used as a touchscreen interface the touchscreen driver switches the device into 1ms sampling mode (rather than the default 10ms economy mode) as recommended by the manufacturer. When using the TSI channels as a general purpose ADC we are currently not doing this and testing suggests that this can result in ADC timeouts: [ 5827.198289] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5827.728293] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5993.808335] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5994.328441] da9052 spi2.0: timeout waiting for ADC conversion interrupt [ 5994.848291] da9052 spi2.0: timeout waiting for ADC conversion interrupt Switching to the 1ms timing resolves this issue. Fixes: 4f16cab1 ("hwmon: da9052: Add support for TSI channel") Signed-off-by: NMartyn Welch <martyn.welch@collabora.co.uk> Acked-by: NSteve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 01 10月, 2017 1 次提交
-
-
由 Christophe Jaillet 提交于
Commit 2ca492e2 has moved the call to 'kfifo_alloc()' from after the main 'if' statement to before it. But it has not updated the error handling paths accordingly. Fix all that: - if 'kfifo_alloc()' fails we can return directly - direct returns after 'kfifo_alloc()' must now go to 'out_mbox_free' - 'goto out_mbox_free' must be replaced by 'goto out', otherwise the '[pcc_]mbox_free_channel()' call will be missed. Fixes: 2ca492e2 ("hwmon: (xgene) Fix crash when alarm occurs before driver probe") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 14 9月, 2017 1 次提交
-
-
由 Christoph Hellwig 提交于
... and __initconst if applicable. Based on similar work for an older kernel in the Grsecurity patch. [JD: fix toshiba-wmi build] [JD: add htcpen] [JD: move __initconst where checkscript wants it] Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJean Delvare <jdelvare@suse.de>
-
- 01 9月, 2017 1 次提交
-
-
由 Florian Eckert 提交于
Add the lantiq cpu temperature sensor support for xrx200. Signed-off-by: NFlorian Eckert <fe@dev.tdt.de> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 31 8月, 2017 1 次提交
-
-
由 Vadim Pasternak 提交于
The below lists of VOUT_MODE command readout with their related VID protocols, Digital to Analog Converter steps, supported by the device: VR12.0 mode, 5-mV DAC - 0x21 VR12.5 mode, 10-mV DAC - 0x22 VR13.0 mode, 10-mV DAC - 0x24 IMVP8 mode, 5-mV DAC - 0x25 VR13.0 mode, 5-mV DAC - 0x27 Signed-off-by: NVadim Pasternak <vadimp@mellanox.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-