In order to make the underneath API easier to change in the future,
prevent users from dereferencing fwnode from struct device.
Instead, use the specific dev_fwnode() API for that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220223191948.31325-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When operating on a mix of DFS and non-DFS channels, the driver only checks
the CAC status of the control channel. This causes beacons/tx to fail if the
control channel is on a non-DFS channel.
Fix this by calling cfg80211_reg_can_beacon to determine the DFS status of
all affected channels
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Fix following coccicheck warning:
./drivers/net/wireless/mediatek/mt76/mt7915/mac.c:768:29-31:
WARNING !A || A && B is equivalent to !A || B
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Similar to mt7915 driver, do not aggregate injected frames in
HW A-MSDU block.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
By default, mt7915e does not enable thermal management until the default
thermal zone does not reach a trip point. If the rest of the system
have better cooling than the wireless hardware, then it is possible that
the wireless chip can overheat while the rest of the system is fine.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The firmware-controlled actual throttle state was previously available
by reading the cooling_device, but this confused the thermal subsystem.
Add a hwmon attribute to get it instead.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
mt7915e registers a cooling_device with wrong semantics:
1. cooling_device expect that higher states values should cool more, but
mt7915e did the opposite... with the exception of state == 0, which
should "disable thermal management", but does not seem to have any
effect since the previous state is kept.
The result is that when the thermal zone heats up a bit and bumps the
cooling_device state from 0 to 1 to cool a bit, the performance is
destroyed, and when going back from 1 to 0, the performance stays bad.
2. Reading the cooling_device state does not always return the last
written state, but can return the actual hardware throttle state,
which is different.
This is a problem because the mt7915 firmware actually implement the
equivalent of a thermal zone with trip points. Setting the cooling
device state actually changes the throttles at each trip point, so the
following could occur if the first issue is fixed:
- thermal subsystem set state to 100% power (state=0)
- mt7915e driver set trip throttles to [100%, 50%, 25%, 12%]
- hardware heats up and decides to switch to 50% power
- thermal subsystem see that power is 50% (state=50), decide to increase
it to 60% (state=40) because the rest of the system is cool.
- mt7915e driver set trip throttle to [60%, 30%, 15%, 7%]
- hardware thus switches to 30% power
[race to the bottom continues...]
This patch corrects the semantics of the cooling_device to the one that
the thermal subsystem expect it.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Instead of just taking the maximum per-chain signal strength values,
add an approximation for the sum of the combined signal.
This should more accurately reflect the real signal strength, especially
if the per-chain signal strength values are close to each other
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Use min_t() in order to make code cleaner.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The muru enable/disable are only set after the first station connection.
Without this patch, the firmware couldn't enable muru
if the first connected station is non-HE type.
Fixes: 16bff457dd ("mt76: mt7915: rework mt7915_mcu_sta_muru_tlv()")
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Newer chips such as MT7915 require up to 16-bits for this field.
Fixes: 49126ac1f8 ("mt76: connac: move mt76_connac_mcu_bss_basic_tlv in connac module")
Signed-off-by: Chad Monroe <chad.monroe@smartrg.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Fix the following sparse warning in mt7915_mac_tx_free routine:
warning: incorrect type in assignment (different base types)
expected unsigned int [usertype] *cur_info
got restricted __le32 *
warning: cast to restricted __le32
Fixes: c17780e7b2 ("mt76: mt7915: add txfree event v3")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Fix the following sparse warnings:
warning: incorrect type in initializer (different base types)
expected restricted __le16 [usertype] msg_type
got int
warning: incorrect type in assignment (different base types)
expected restricted __le32 [usertype] timestamp
got unsigned int
Fixes: 988845c936 ("mt76: mt7915: add support for passing chip/firmware debug data to user space")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The following error is see from the compiler:
mt7615/debugfs.c: In function ‘mt7615_ext_mac_addr_read’:
mt7615/debugfs.c:465:1: warning: the frame size of 1072 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
The issue is due to allocating a buffer as string storage.
Fix by converting to a dynamical allocation of the buffer.
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The wfsys of MT7986 has only single adie chip for non-dbdc devices,
and it binds to band1 by default. Hence this patch adds band_idx to
explicitly configure phy accordingly.
Co-developed-by: Sujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com>
Co-developed-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The X1000 has the same TCU / PWM hardware as other Ingenic SoCs,
but it has only 5 channels.
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Status quo is that variables of type struct vt8500_chip * are named
"vt8500", "chip". Because usually only struct pwm_device * variables
are named "pwm" and "chip" is usually used for variabled of type
struct pwm_chip *.
So consistently use the same and non-conflicting name "vt8500".
Signed-off-by: zhaoxiao <zhaoxiao@uniontech.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM hardware on the X1000 SoC is almost identical to other
Ingenic SoCs, so it can be used with only minor driver changes.
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
fsnotify() treats FS_MODIFY events specially - it does not skip them
even if the FS_MODIFY event does not apear in the object's fsnotify
mask. This is because send_to_group() checks if FS_MODIFY needs to
clear ignored mask of marks.
The common case is that an object does not have any mark with ignored
mask and in particular, that it does not have a mark with ignored mask
and without the FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY flag.
Set FS_MODIFY in object's fsnotify mask during fsnotify_recalc_mask()
if object has a mark with an ignored mask and without the
FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY flag and remove the special
treatment of FS_MODIFY in fsnotify(), so that FS_MODIFY events could
be optimized in the common case.
Call fsnotify_recalc_mask() from fanotify after adding or removing an
ignored mask from a mark without FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY
or when adding the FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY flag to a mark
with ignored mask (the flag cannot be removed by fanotify uapi).
Performance results for doing 10000000 write(2)s to tmpfs:
vanilla patched
without notification mark 25.486+-1.054 24.965+-0.244
with notification mark 30.111+-0.139 26.891+-1.355
So we can see the overhead of notification subsystem has been
drastically reduced.
Link: https://lore.kernel.org/r/20220223151438.790268-3-amir73il@gmail.com
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
fsnotify_parent() does not consider the parent's mark at all unless
the parent inode shows interest in events on children and in the
specific event.
So unless parent added an event to both its mark mask and ignored mask,
the event will not be ignored.
Fix this by declaring the interest of an object in an event when the
event is in either a mark mask or ignored mask.
Link: https://lore.kernel.org/r/20220223151438.790268-2-amir73il@gmail.com
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Linus reports that some Renesas pin control sub-drivers are still
including <linux/gpio.h> instead of <linux/gpio/driver.h>. As these
sub-drivers don't need either, the includes can just be removed.
Reported-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/578825d779b45af745cc7623c7f69d2ddeadac4b.1645605227.git.geert+renesas@glider.be
During the driver probe, registers are not set to their POR value.
Signed-off-by: Lionel Vitte <lionel.vitte@free.fr>
Acked-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The checker failed to validate all enum IDs in the description of a
register with fixed-width register fields, due to a miscalculation of
the number of described states: each register field of n bits can have
"1 << n" possible states, not "1".
Increase SH_PFC_MAX_ENUMS accordingly, now more enum IDs are checked
(SH-Mobile AG5 has more than 4000 enum IDs defined).
Fixes: 12d057bad6 ("pinctrl: sh-pfc: checker: Add check for enum ID conflicts")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/6d8a6a05564f38f9d20464c1c17f96e52740cf6a.1645460429.git.geert+renesas@glider.be
The variable timeout is being initialized with a value that is never
read, it is being re-assigned the same value later on. Remove the
redundant initialization and keep the latter assignment because it's
closer to the use of the variable.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Since commit f9a8ee8c8b ("pwm: Always allocate PWM chip base ID
dynamically") there is no effect any more for assigning this variable.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The Renesas RZ/G2L, RZ/G2LC, RZ/G2UL and RZ/V2L SoCs have identical IP
blocks for which drivers are common. To avoid updating the Kconfig
files for drivers in common to each SoC, introduce the ARCH_RZG2L config
option.
The ARCH_RZG2L config option will be selected by the above mentioned
SoCs, and the ARCH_RZG2L config option will be used as a dependency for
the drivers in common.
While at it, move PM and PM_GENERIC_DOMAINS under the ARCH_RZG2L config
option instead of keeping it for individual SoCs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20220224092114.25737-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
To eventually get rid of all legacy drivers convert this driver to the
modern world implementing .apply().
The conversion wasn't quite straight forward because .config() and
.enable() were special to effectively swap their usual order. This resulted
in calculating the required values twice in some cases when
pwm_apply_state() was called. This is optimized en passant, and the order
of the callbacks is preserved without special jumping through hoops.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
To eventually get rid of all legacy drivers convert this driver to the
modern world implementing .apply(). This just pushes down a slightly
optimized variant of how legacy drivers are handled in the core.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The battery on the 2nd hand Surface 3 which I recently bought appears to
not have a serial number programmed in. This results in any I2C reads from
the registers containing the serial number failing with an I2C NACK.
This was causing mshw0011_bix() to fail causing the battery readings to
not work at all.
Ignore EREMOTEIO (I2C NACK) errors when retrieving the serial number and
continue with an empty serial number to fix this.
Fixes: b1f81b496b ("platform/x86: surface3_power: MSHW0011 rev-eng implementation")
BugLink: https://github.com/linux-surface/linux-surface/issues/608
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220224101848.7219-1-hdegoede@redhat.com
commit 59348401eb ("platform/x86: amd-pmc: Add special handling for
timer based S0i3 wakeup") adds support for using another platform timer
in lieu of the RTC which doesn't work properly on some systems. This path
was validated and worked well before submission. During the 5.16-rc1 merge
window other patches were merged that caused this to stop working properly.
When this feature was used with 5.16-rc1 or later some OEM laptops with the
matching firmware requirements from that commit would shutdown instead of
program a timer based wakeup.
This was bisected to commit 8d89835b04 ("PM: suspend: Do not pause
cpuidle in the suspend-to-idle path"). This wasn't supposed to cause any
negative impacts and also tested well on both Intel and ARM platforms.
However this changed the semantics of when CPUs are allowed to be in the
deepest state. For the AMD systems in question it appears this causes a
firmware crash for timer based wakeup.
It's hypothesized to be caused by the `amd-pmc` driver sending `OS_HINT`
and all the CPUs going into a deep state while the timer is still being
programmed. It's likely a firmware bug, but to avoid it don't allow setting
CPUs into the deepest state while using CZN timer wakeup path.
If later it's discovered that this also occurs from "regular" suspends
without a timer as well or on other silicon, this may be later expanded to
run in the suspend path for more scenarios.
Cc: stable@vger.kernel.org # 5.16+
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/linux-acpi/BL1PR12MB51570F5BD05980A0DCA1F3F4E23A9@BL1PR12MB5157.namprd12.prod.outlook.com/T/#mee35f39c41a04b624700ab2621c795367f19c90e
Fixes: 8d89835b04 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
Fixes: 23f62d7ab2 ("PM: sleep: Pause cpuidle later and resume it earlier during system transitions")
Fixes: 59348401eb ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup"
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220223175237.6209-1-mario.limonciello@amd.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Include generic pwm.yaml schema, which enforces PWM node naming. Keep
the old name in bindings as deprecated.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
This patch updates the tegra20-asus-tf101 device tree to replace the
deprecated `revision-id1` binding with the new `revision-id` binding in
its "jedec,lpddr2"-compatible node. This was the only DTS in the tree
using this binding.
The revision-id2 (mode register 7) of this memory chip was not given in
the existing device tree, so let's assume 0 for now until it becomes
relevant.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use devm_work_autocancel() instead of hand writing it.
It saves a few lines of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Use devm_delayed_work_autocancel() instead of hand writing it.
It saves a few lines of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This driver only uses managed resources, except for the delayed work, if
it is used.
Use devm_delayed_work_autocancel() to also manage the delayed work.
The error handling path of the probe and the remove function can both be
removed.
This saves a few lines of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This driver can use an interrupt or polling in order get the charger's
status.
When using polling, a delayed work is used.
However, the remove() function unconditionally call
cancel_delayed_work_sync(), even if the delayed work is not used and is not
initialized.
In order to fix it, use devm_delayed_work_autocancel() and remove the now
useless remove() function.
Fixes: feb583e37f ("power: supply: add sbs-charger driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Adds a brief desciption of the "Long Life" charge type and adds "Long Life"
to the list of valid values.
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This patch remaps the bypass operation from POWER_SUPPLY_CHARGE_TYPE_FAST
to POWER_SUPPLY_CHARGE_TYPE_BYPASS.
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Adds a POWER_SUPPLY_CHARGE_TYPE_BYPASS option to the POWER_SUPPLY_PROP_CHARGE_TYPE
property to facilitate bypass charging operation.
In bypass charging operation, the charger bypasses the charging path around the
integrated converter allowing for a "smart" wall adaptor to perform the power
conversion externally.
This operational mode is critical for the USB PPS standard of power adaptors and is
becoming a common feature in modern charging ICs such as:
- BQ25980
- BQ25975
- BQ25960
- LN8000
- LN8410
Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
