Many Lenovo BIOS's support the ability to send a debug command which
is useful for debugging and testing unreleased or early features.
Adding support for this feature as a module parameter.
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210817001501.293501-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This symbol is not used outside of vc4_hdmi.c, so marks it static.
Fix the following sparse warning:
drivers/gpu/drm/vc4/vc4_hdmi.c:1479:25: warning: symbol
'vc4_hdmi_codec_pdata' was not declared. Should it be static?
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/1627640794-15718-1-git-send-email-jiapeng.chong@linux.alibaba.com
Driver enabling various pieces of Limits Management Hardware(LMh) for cpu
cluster0 and cpu cluster1 namely kick starting monitoring of temperature,
current, battery current violations, enabling reliability algorithm and
setting up various temperature limits.
The following has been explained in the cover letter. I am including this
here so that this remains in the commit message as well.
LMh is a hardware infrastructure on some Qualcomm SoCs that can enforce
temperature and current limits as programmed by software for certain IPs
like CPU. On many newer LMh is configured by firmware/TZ and no programming
is needed from the kernel side. But on certain SoCs like sdm845 the
firmware does not do a complete programming of the h/w. On such soc's
kernel software has to explicitly set up the temperature limits and turn on
various monitoring and enforcing algorithms on the hardware.
Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630
Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210809191605.3742979-3-thara.gopinath@linaro.org
The wrong enum was used here, leading to warnings.
Just use a u32 instead.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 0d2ab3aea5 ("nl80211: add support for BSS coloring")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Commit b7fb14d3ac ("ide: remove the legacy ide driver") removes the
definition of the config IDE_GD_ATA.
So, remove the obsolete reference in ./drivers/leds/trigger/Kconfig.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The 9-channel one is called LP5009, not LP509.
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Pull LKMM changes from Paul E. McKenney:
"These changes focus on documentation, providing additional
examples and use cases."
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Pull KCSAN updates from Paul E. McKenney:
- improve comments
- introduce CONFIG_KCSAN_STRICT (which RCU uses)
- optimize use of get_ctx() by kcsan_found_watchpoint()
- rework atomic.h into permissive.h
- add the ability to ignore writes that change only one bit of a given data-racy variable.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This patch adds support for "default-state" devicetree property, which
allows to defer pwm init to first use of led.
This allows to configure the PWM early in bootloader to let the LED
blink until an application in Linux userspace sets something different.
Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This patch introduces a new function to read initial
default_state from fwnode.
Suggested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
On systems with many cores using dm-crypt, heavy spinlock contention in
percpu_counter_compare() can be observed when the page allocation limit
for a given device is reached or close to be reached. This is due
to percpu_counter_compare() taking a spinlock to compute an exact
result on potentially many CPUs at the same time.
Switch to non-exact comparison of allocated and allowed pages by using
the value returned by percpu_counter_read_positive() to avoid taking
the percpu_counter spinlock.
This may over/under estimate the actual number of allocated pages by at
most (batch-1) * num_online_cpus().
Currently, batch is bounded by 32. The system on which this issue was
first observed has 256 CPUs and 512GB of RAM. With a 4k page size, this
change may over/under estimate by 31MB. With ~10G (2%) allowed dm-crypt
allocations, this seems an acceptable error. Certainly preferred over
running into the spinlock contention.
This behavior was reproduced on an EC2 c5.24xlarge instance with 96 CPUs
and 192GB RAM as follows, but can be provoked on systems with less CPUs
as well.
* Disable swap
* Tune vm settings to promote regular writeback
$ echo 50 > /proc/sys/vm/dirty_expire_centisecs
$ echo 25 > /proc/sys/vm/dirty_writeback_centisecs
$ echo $((128 * 1024 * 1024)) > /proc/sys/vm/dirty_background_bytes
* Create 8 dmcrypt devices based on files on a tmpfs
* Create and mount an ext4 filesystem on each crypt devices
* Run stress-ng --hdd 8 within one of above filesystems
Total %system usage collected from sysstat goes to ~35%. Write throughput
on the underlying loop device is ~2GB/s. perf profiling an individual
kworker kcryptd thread shows the following profile, indicating spinlock
contention in percpu_counter_compare():
99.98% 0.00% kworker/u193:46 [kernel.kallsyms] [k] ret_from_fork
|
--ret_from_fork
kthread
worker_thread
|
--99.92%--process_one_work
|
|--80.52%--kcryptd_crypt
| |
| |--62.58%--mempool_alloc
| | |
| | --62.24%--crypt_page_alloc
| | |
| | --61.51%--__percpu_counter_compare
| | |
| | --61.34%--__percpu_counter_sum
| | |
| | |--58.68%--_raw_spin_lock_irqsave
| | | |
| | | --58.30%--native_queued_spin_lock_slowpath
| | |
| | --0.69%--cpumask_next
| | |
| | --0.51%--_find_next_bit
| |
| |--10.61%--crypt_convert
| | |
| | |--6.05%--xts_crypt
...
After applying this patch and running the same test, %system usage is
lowered to ~7% and write throughput on the loop device increases
to ~2.7GB/s. perf report shows mempool_alloc() as ~8% rather than ~62%
in the profile and not hitting the percpu_counter() spinlock anymore.
|--8.15%--mempool_alloc
| |
| |--3.93%--crypt_page_alloc
| | |
| | --3.75%--__alloc_pages
| | |
| | --3.62%--get_page_from_freelist
| | |
| | --3.22%--rmqueue_bulk
| | |
| | --2.59%--_raw_spin_lock
| | |
| | --2.57%--native_queued_spin_lock_slowpath
| |
| --3.05%--_raw_spin_lock_irqsave
| |
| --2.49%--native_queued_spin_lock_slowpath
Suggested-by: DJ Gregor <dj@corelight.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Arne Welzel <arne.welzel@corelight.com>
Fixes: 5059353df8 ("dm crypt: limit the number of allocated pages")
Cc: stable@vger.kernel.org
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
When CONFIG_PM is not set, there is an unused function warning:
sound/pci/hda/patch_analog.c:115:13: warning: unused function
'ad198x_shutup' [-Wunused-function]
static void ad198x_shutup(struct hda_codec *codec)
^
1 warning generated.
Sink ad198x_shutup() into ad198x_suspend(), as it is only called in that
one space. Move the CONFIG_PM guards above ad198x_power_eapd_write() as
it is only called in ad198x_power_eapd(), which is in turn only called
in ad198x_power_eapd(). Those two functions are large enough that they
are left alone.
Fixes: 327b34f2a9 ("ALSA: hda: Nuke unused reboot_notify callback")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20210818012705.311963-2-nathan@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When CONFIG_PM is not set, there is an unused function warning:
sound/pci/hda/patch_sigmatel.c:4383:13: warning: unused function
'stac_shutup' [-Wunused-function]
static void stac_shutup(struct hda_codec *codec)
^
1 warning generated.
Sink the contents of stac_shutup() into stac_suspend() since
stac_shutup() is only called in that one location now.
Fixes: 327b34f2a9 ("ALSA: hda: Nuke unused reboot_notify callback")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20210818012705.311963-1-nathan@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The sd_spinup_disk() function logs what is happening. Unfortunately this
output stops if the media was marked as removed in the meantime. Add a
print for this case too.
Link: https://lore.kernel.org/r/CWXP265MB26803209FD08A64222EEEA02C4FD9@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The initial device scan might take some time, and there really is no need
to wait for it during probe(). So return immediately from scsi_scan_host()
during probe() and avoid any udev stalls during booting.
Link: https://lore.kernel.org/r/20210817075306.11315-1-mwilck@suse.com
Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
TCM fails to pass the following tests in libiscsi:
SCSI.ExtendedCopy.DescrType
SCSI.ExtendedCopy.DescrLimits
SCSI.ExtendedCopy.ParamHdr
SCSI.ExtendedCopy.ValidSegDescr
SCSI.ExtendedCopy.ValidTgtDescr
The xcopy code always returns the same NOT READY sense key for all detected
errors. Change the sense key for invalid requests to ILLEGAL REQUEST, and
for aborted transfers to COPY ABORTED.
Link: https://lore.kernel.org/r/20210803145410.80147-3-s.samoylenko@yadro.com
Fixes: d877d7275b ("target: Fix a deadlock between the XCOPY code and iSCSI session shutdown")
Reviewed-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Konstantin Shelekhin <k.shelekhin@yadro.com>
Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently, backend drivers can fail I/O with SAM_STAT_CHECK_CONDITION which
gets us TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE.
Add a new helper that allows backend drivers to fail with specific sense
codes.
This is based on a patch from Mike Christie <michael.christie@oracle.com>.
Cc: Mike Christie <michael.christie@oracle.com>
Link: https://lore.kernel.org/r/20210803145410.80147-2-s.samoylenko@yadro.com
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The return value of transport_kmap_data_sg() is assigned to the variable
buf:
buf = transport_kmap_data_sg(cmd);
And then it is checked:
if (!buf) {
This indicates that buf can be NULL. However, it is dereferenced in the
following statements:
if (!(buf[3] & 0x80))
buf[3] |= 0x80;
if (!(buf[2] & 0x80))
buf[2] |= 0x80;
To fix these possible null-pointer dereferences, dereference buf and call
transport_kunmap_data_sg() only when buf is not NULL.
Link: https://lore.kernel.org/r/20210810040414.248167-1-islituo@gmail.com
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Reviewed-by: Bodo Stroesser <bostroesser@gmail.com>
Signed-off-by: Tuo Li <islituo@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
It is never read, so get rid of it.
Link: https://lore.kernel.org/r/1628862553-179450-4-git-send-email-john.garry@huawei.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
is_flush_rq() is called from bt_iter()/bt_tags_iter(), and runs the
following check:
hctx->fq->flush_rq == req
but the passed hctx from bt_iter()/bt_tags_iter() may be NULL because:
1) memory re-order in blk_mq_rq_ctx_init():
rq->mq_hctx = data->hctx;
...
refcount_set(&rq->ref, 1);
OR
2) tag re-use and ->rqs[] isn't updated with new request.
Fix the issue by re-writing is_flush_rq() as:
return rq->end_io == flush_end_io;
which turns out simpler to follow and immune to data race since we have
ordered WRITE rq->end_io and refcount_set(&rq->ref, 1).
Fixes: 2e315dc07d ("blk-mq: grab rq->refcount before calling ->fn in blk_mq_tagset_busy_iter")
Cc: "Blank-Burian, Markus, Dr." <blankburian@uni-muenster.de>
Cc: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210818010925.607383-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Nguyen, Anthony L says:
====================
40GbE Intel Wired LAN Driver Updates 2021-08-17
This series contains updates to iavf and i40e drivers.
Stefan Assmann converts use of flag based locking of critical sections
to mutexes for iavf.
Colin King fixes a spelling error for i40e.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
i40e: Fix spelling mistake "dissable" -> "disable"
iavf: use mutexes for locking of critical sections
====================
Link: https://lore.kernel.org/r/20210817203549.3529860-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In ixgbe_xsk_pool_enable(), if ixgbe_xsk_wakeup() fails,
We should restore the previous state and clean up the
resources. Add the missing clear af_xdp_zc_qps and unmap dma
to fix this bug.
Fixes: d49e286d35 ("ixgbe: add tracking of AF_XDP zero-copy state for each queue pair")
Fixes: 4a9b32f30f ("ixgbe: fix potential RX buffer starvation for AF_XDP")
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://lore.kernel.org/r/20210817203736.3529939-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
interrupt.c: asm/interrupt.h has been included at line 12, so remove the
duplicate one at line 10.
time.c: linux/sched/clock.h has been included at line 33,so remove the
duplicate one at line 56 and move sched/cputime.h under sched including
segament.
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Reviewed-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210323062916.295346-1-wanjiabing@vivo.com
"reset_fn" indicates whether the device supports any reset mechanism.
Remove the use of reset_fn in favor of the reset_methods array that tracks
supported reset mechanisms of a device and their ordering.
The octeon driver incorrectly used reset_fn to detect whether the device
supports FLR or not. Use pcie_reset_flr() to probe whether it supports FLR.
Co-developed-by: Alex Williamson <alex.williamson@redhat.com>
Link: https://lore.kernel.org/r/20210817180500.1253-5-ameynarkhede03@gmail.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Add reset_methods[] in struct pci_dev to keep track of reset mechanisms
supported by the device and their ordering.
Refactor probing and reset functions to take advantage of calling
convention of reset functions.
Co-developed-by: Alex Williamson <alex.williamson@redhat.com>
Link: https://lore.kernel.org/r/20210817180500.1253-4-ameynarkhede03@gmail.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
The Samsung Exynos SoC SATA bindings are not implemented in the kernel,
not used and superseded by generic
Documentation/devicetree/bindings/ata/ahci-platform.txt bindings.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20210811083859.28234-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Rob Herring <robh@kernel.org>
First set of fixes for v5.14 and nothing major this time. New devices
for iwlwifi and one fix for a compiler warning.
iwlwifi
* support for new devices
mt76
* fix compiler warning about MT_CIPHER_NONE
-----BEGIN PGP SIGNATURE-----
iQFJBAABCgAzFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmEb7SAVHGt2YWxvQGNv
ZGVhdXJvcmEub3JnAAoJEG4XJFUm622bDaEH/1TH5IlBXq4dNPGNwgZ0L4sXFlVk
U7mSbuv2BdH+5edozGwdGl4d6o/vqzcoYSF/dh6d4rpX//zacSsB4LpACW1knlh5
aJxjP5PdxLty/90JXtpBxL79WfQ9kVQ72ldKAg1Gk9XFk1UOqXSaOaLccNBtFk78
n97hNwEeKKX1bw//fNLgyxUAlMoIVCaNjtcY9xJpoC5xLHQxM7ixhxqZF7XSeujQ
z63CRUnT/7gFr4DbOLsZSZVYhCX9v+rz4imIsNbly3e6vLH9Mp2pkyHFfaHKFk6X
tV/Kkd1Bq6OjQAGSq7mbddi7XqXSd3/1rUZChUy0ZSiyKlly52iqxWhWBBI=
=YqJK
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-2021-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for v5.14
First set of fixes for v5.14 and nothing major this time. New devices
for iwlwifi and one fix for a compiler warning.
iwlwifi
* support for new devices
mt76
* fix compiler warning about MT_CIPHER_NONE
* tag 'wireless-drivers-2021-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers:
mt76: fix enum type mismatch
iwlwifi: add new so-jf devices
iwlwifi: add new SoF with JF devices
iwlwifi: pnvm: accept multiple HW-type TLVs
====================
Link: https://lore.kernel.org/r/20210817171027.EC1E6C43460@smtp.codeaurora.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drop #ifdef DEBUG and use ktime_us_delta()
for improved precision.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20210814190516.26718-1-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Mark function i8k_get_fan_nominal_speed() as __init since
it is only used in code also marked as __init.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20210814143637.11922-5-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Both the config and the DMI tables never change and
are only used during module init for setting up
the device data struct.
Mark all of them as const and __initconst for a
smaller runtime memory footprint.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20210814143637.11922-2-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
BPD-RS600 modules running firmware v5.70 misreport the MFR_PIN_MAX.
The indicate a maximum of 1640W instead of 700W. Detect the invalid
reading and return a sensible value instead.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20210812014000.26293-3-chris.packham@alliedtelesis.co.nz
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In the initial implementation a number of PMBUS_x_WARN_LIMITs were
mapped to MFR fields. This was incorrect as these MFR limits reflect the
rated limit as opposed to a limit which will generate warning. Instead
return -ENXIO like we were already doing for other WARN_LIMITs.
Subsequently these rated limits have been exposed generically as new
fields in the sysfs ABI so the values are still available.
Fixes: 15b2703e5e ("hwmon: (pmbus) Add driver for BluTek BPA-RS600")
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20210812014000.26293-2-chris.packham@alliedtelesis.co.nz
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The HW has some predefined points where it will associate a PWM value.
However some users might want to better set these points to their
usecases. This patch exposes these points as pwm auto_points:
* pwm1_auto_point1_temp_hyst: temperature threshold below which PWM should
be 0%;
* pwm1_auto_point1_temp: temperature threshold above which PWM should be
25%;
* pwm1_auto_point2_temp_hyst: temperature threshold below which PWM should
be 25%;
* pwm1_auto_point2_temp: temperature threshold above which PWM should be
50%;
* pwm1_auto_point3_temp_hyst: temperature threshold below which PWM should
be 50%;
* pwm1_auto_point3_temp: temperature threshold above which PWM should be
75%;
* pwm1_auto_point4_temp_hyst: temperature threshold below which PWM should
be 75%;
* pwm1_auto_point4_temp: temperature threshold above which PWM should be
100%;
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210811114853.159298-4-nuno.sa@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The core will now start out of reset at boot as soon as clocking is
available. Hence, by the time we unmask the interrupts we already might
have some of them set. Thus, it's important to handle them in the
natural order the core generates them. Otherwise, we could process
'ADI_IRQ_SRC_PWM_CHANGED' before 'ADI_IRQ_SRC_TEMP_INCREASE' and
erroneously set 'update_tacho_params' to true.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210811114853.159298-3-nuno.sa@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The core will only work if it's clock is enabled. This patch is a
minor enhancement to make sure that's the case.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20210811114853.159298-2-nuno.sa@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
When doing a PMBus write for the LED control on the IBM Common Form
Factor Power Supplies (ibm-cffps), the DAh command requires that bit 7
be low and bit 6 be high in order to indicate that you are truly
attempting to do a write.
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>
Link: https://lore.kernel.org/r/20210806225131.1808759-1-bjwyman@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
I2C devices should match on the proper compatible string.
This is already used in one device tree in the kernel (MIPS)
so let's add the matches.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210729230543.2853485-2-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This adds a device tree binding for the Winbond W83781D and its
sibling HW monitoring ICs. This is used in for example the Freecom
FSG-3 router/NAS.
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210729230543.2853485-1-linus.walleij@linaro.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
