Some new 2021 version of ASUS gamer laptops are using an updated
N-Key keyboard with the PID of 0x19b6. This version is using the
same init sequence and brightness control as the 0x1866 keyboard.
Signed-off-by: NLuke D Jones <luke@ljones.dev>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add 1 additional hammer-like device.
Signed-off-by: NShou-Chieh Hsu <shouchieh@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Al root-caused a new warning from syzbot to the ttyprintk tty driver
returning a write count larger than the data the tty layer actually gave
it.  Which confused the tty write code mightily, and with the new
iov_iter based code, caused a WARNING in iov_iter_revert().

syzbot correctly bisected the source of the new warning to commit
9bb48c82 ("tty: implement write_iter"), but the oddity goes back
much further, it just didn't get caught by anything before.

Reported-by: syzbot+3d2c27c2b7dc2a94814d@syzkaller.appspotmail.com
Fixes: 9bb48c82 ("tty: implement write_iter")
Debugged-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes the rlc reference clock used for GPU timestamps.
Value is 100Mhz.  Confirmed with hardware team.

v2: reword commit message.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1480Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Disable it on those boards.  No functional change, this just
removes the message about VCE failing to initialize.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197327Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

memalloc_nofs_save/restore are no longer sufficient to prevent recursive
lock warnings when holding locks that can be taken in MMU notifiers. Use
memalloc_noreclaim_save/restore instead.

Fixes: f920e413 ("mm: track mmu notifiers in fs_reclaim_acquire/release")
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NPhilip Yang <Philip.Yang@amd.com>
Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org # 5.10.x

dcn21_validate_bandwidth() calls functions that use floating point math.
On my machine this sometimes results in simd exceptions when there are
other FPU users such as KVM virtual machines running. The screen freezes
completely in this case.

Wrapping the function with DC_FP_START()/DC_FP_END() seems to solve the
problem. This mirrors the approach used for dcn20_validate_bandwidth.

Tested on a AMD Ryzen 7 PRO 4750U (Renoir).

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206987Signed-off-by: NJan Kokemüller <jan.kokemueller@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fix potential integer overflow by casting actual_calculated_clock_100hz
to u64, in order to give the compiler complete information about the
proper arithmetic to use.

Notice that such variable is used in a context that expects
an expression of type u64 (64 bits, unsigned) and the following
expression is currently being evaluated using 32-bit arithmetic:

actual_calculated_clock_100hz * post_divider

Fixes: 7a03fdf6 ("drm/amd/display: fix 64bit division issue on 32bit OS")
Addresses-Coverity-ID: 1501691 ("Unintentional integer overflow")
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes: 9037246b ("drm/amd/display: Add sysfs interface for set/get srm")
Signed-off-by: NNirmoy Das <nirmoy.das@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This fixes incorrect TCC harvesting info reported to userspace.
The impact was a very very tiny performance degradation (unnecessary
GL2 cache flushes).
Signed-off-by: NMarek Olšák <marek.olsak@amd.com>
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The DualSense features 5 player LEDs below its touchpad, which are
meant as player id indications. The LEDs are configured with a
player ID determined by an ID allocator, which assign player ids
to ps_device instances.

This patch is a combination of the following original patches
minus use of LED framework APIs:
- HID: playstation: add DualSense player LEDs support.
- HID: playstation: DualSense set LEDs to default player id.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: NBarnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

The DualSense controller has a built-in microphone exposed as an
audio device over USB (or HID using Bluetooth). A dedicated
button on the controller handles mute, but software has to configure
the device to mute the audio stream.

This patch captures the mute button and schedules an output report
to mute/unmute the audio stream as well as toggle the mute LED.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: NBarnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Provide initial support for the DualSense lightbar and configure it
with a default PlayStation blue color.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: NBarnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

If no n_latch value will be provided at driver probe then all pins will
be used as an input:

    gpio->out = ~n_latch;

In that case initial state for all pins is "one":

    gpio->status = gpio->out;

So if pcf857x IRQ happens with change pin value from "zero" to "one"
then we miss it, because of "one" from IRQ and "one" from initial state
leaves corresponding pin unchanged:
change = (gpio->status ^ status) & gpio->irq_enabled;

The right solution will be to read actual state at driver probe.

Cc: stable@vger.kernel.org
Fixes: 6e20a0a4 ("gpio: pcf857x: enable gpio_to_irq() support")
Signed-off-by: NMaxim Kiselev <bigunclemax@gmail.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>

The `wacom_feature_mapping` function is careful to only set the the
touch_max value a single time, but this care does not extend to the
`wacom_wac_finger_event` function. In particular, if a device sends
multiple HID_DG_CONTACTMAX items in a single feature report, the
driver will end up retaining the value of last item.

The HID descriptor for the Cintiq Companion 2 does exactly this. It
incorrectly sets a "Report Count" of 2, which will cause the driver
to process two HID_DG_CONTACTCOUNT items. The first item has the actual
count, while the second item should have been declared as a constant
zero. The constant zero is the value the driver ends up using, however,
since it is the last HID_DG_CONTACTCOUNT in the report.

    Report ID (16),
    Usage (Contact Count Maximum),  ; Contact count maximum (55h, static value)
    Report Count (2),
    Logical Maximum (10),
    Feature (Variable),

To address this, we add a check that the touch_max is not already set
within the `wacom_wac_finger_event` function that processes the
HID_DG_TOUCHMAX item. We emit a warning if the value is set and ignore
the updated value.

This could potentially cause problems if there is a tablet which has
a similar issue but requires the last item to be used. This is unlikely,
however, since it would have to have a different non-zero value for
HID_DG_CONTACTMAX earlier in the same report, which makes no sense
except in the case of a firmware bug. Note that cases where the
HID_DG_CONTACTMAX items are in different reports is already handled
(and similarly ignored) by `wacom_feature_mapping` as mentioned above.

Link: https://github.com/linuxwacom/input-wacom/issues/223
Fixes: 184eccd4 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report")
Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
CC: stable@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Static checkers complained about an off by one read overflow in
otx2_get_fecparam() and we applied two conflicting fixes for it.

Correct: b0aae0bd ("octeontx2: Fix condition.")
  Wrong: 93efb0c6 ("octeontx2-pf: Fix out-of-bounds read in otx2_get_fecparam()")

Revert the incorrect fix.

Fixes: 93efb0c6 ("octeontx2-pf: Fix out-of-bounds read in otx2_get_fecparam()")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

These defines are used with set_bit() and test_bit() which take a bit
number.  In other words, the code is doing:

	if (BIT(BIT(1)) & pf->hw.cap_flag) {

This was done consistently so it did not cause a problem at runtime but
it's still worth fixing.

Fixes: facede82 ("octeontx2-pf: cn10k: Add mbox support for CN10K")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch populates the PCI bus info in the ethtool driver query data.

Users will be able to view PCI bus info using 'ethtool -i <interface>'.
Signed-off-by: NWong Vee Khee <vee.khee.wong@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Code clean-up.
Signed-off-by: NVincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Code clean-up.
Signed-off-by: NVincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Code clean-up.

* Remove blank line between variable declarations.
* Remove blank line between:
	err = blah(...)

	if (err)
		...
* Remove unnecessary blank line before/after loop constructs.
Signed-off-by: NVincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Code clean-up.

* Remove unnecessary \n termination from dev_*() messages.
* Remove 'char *fmt' to define strings to stay within 80 column
  limit.  Not needed since coding guidelines increased to
  100 columns limit.
  Keeping format in place allows static code checkers to
  validate the arguments.
* Tighten up vertical spacing.
Signed-off-by: NVincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Removed unused header declarations.
Signed-off-by: NVincent Cheng <vincent.cheng.xh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When enabling output using PTP_CLK_REQ_PEROUT, need to align the output
clock to the internal 1 PPS clock.
Signed-off-by: NVincent Cheng <vincent.cheng.xh@renesas.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Part of the device initialization aligns the rising edge of the output
clock to the internal 1 PPS clock. If the system APLL and DPLL is not
locked, then the alignment will fail and there will be a fixed offset
between the internal 1 PPS clock and the output clock.

After loading the device firmware, poll the system APLL and DPLL for
locked state prior to initialization, timing out after 2 seconds.
Signed-off-by: NVincent Cheng <vincent.cheng.xh@renesas.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Ethernet MAC and PHY are usually major consumers of power on boards
which may not be able to fully power off (those with no PMIC). Powering
down the MAC and internal PHY saves power while these boards are "off".
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Adjust the spacing and use an explicit "return 0" in the success path
to make the function easier to parse.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use the appropriate function instead of reimplementing it,
and update the error message to match the code.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

sun8i_dwmac_unpower_internal_phy already checks if the PHY is powered,
so there is no need to do it again here.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is a deinitialization function that always returned zero, and that
return value was always ignored. Have it return void instead.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NSamuel Holland <samuel@sholland.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use macro pm_ptr(), this helps to avoid some ifdeffery.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We have no in-tree users, also update the sfp-phylink.rst documentation
to indicate that phy_attach_direct() is used instead of of_phy_attach().
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Ocelot now uses include/linux/dsa/ocelot.h which makes use of
CONFIG_PACKING to pack/unpack bits into the Injection/Extraction Frame
Headers. So it needs to explicitly select it, otherwise there might be
build errors due to the missing dependency.

Fixes: 40d3f295 ("net: mscc: ocelot: use common tag parsing code with DSA")
Reported-by: NNaresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The comparison of value with the array size ps_gamepad_hat_mapping
appears to be off-by-one. Fix this by using >= rather than > for the
size comparison.

Addresses-Coverity: ("Out-of-bounds read")
Fixes: bc2e15a9 ("HID: playstation: initial DualSense USB support.")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

freq_qos_update_request() returns 1 if the effective constraint value
has changed, 0 if the effective constraint value has not changed, or a
negative error code on failures.

The frequency constraints for CPUs can be set by different parts of the
kernel. If the maximum frequency constraint set by other parts of the
kernel are set at a lower value than the one corresponding to cooling
state 0, then we will never be able to cool down the system as
freq_qos_update_request() will keep on returning 0 and we will skip
updating cpufreq_state and thermal pressure.

Fix that by doing the updates even in the case where
freq_qos_update_request() returns 0, as we have effectively set the
constraint to a new value even if the consolidated value of the
actual constraint is unchanged because of external factors.

Cc: v5.7+ <stable@vger.kernel.org> # v5.7+
Reported-by: NThara Gopinath <thara.gopinath@linaro.org>
Fixes: f12e4f66 ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping")
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: NLukasz Luba <lukasz.luba@arm.com>
Tested-by: NLukasz Luba <lukasz.luba@arm.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Thara Gopinath<thara.gopinath@linaro.org>
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/b2b7e84944937390256669df5a48ce5abba0c1ef.1613540713.git.viresh.kumar@linaro.org

The ret variable in ps_battery_get_property is set in an error path,
but never actually returned. Change the function to return ret.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

Retrieve DualSense hardware and firmware information using a vendor
specific feature report. Report the data through sysfs and also
report using hid_info as there can be signficant differences between
versions.
Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
Reviewed-by: NBarnabás Pőcze <pobrn@protonmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>

The surface_state_base is an offset into the batch, so we need to pass
the correct batch address for STATE_BASE_ADDRESS.

Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.7+
Link: https://patchwork.freedesktop.org/patch/msgid/20210210122728.20097-1-chris@chris-wilson.co.uk
(cherry picked from commit 1914911f4aa08ddc05bae71d3516419463e0c567)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

ilk+ planes get notably unhappy when the plane x+w exceeds
the stride. This wasn't a problem previously because we
always aligned SURF to the closest tile boundary so the
x offset never got particularly large. But now with async
flips we have to align to 256KiB instead and thus this
becomes a real issue.

On ilk/snb/ivb it looks like the accesses just wrap
early to the next tile row when scanout goes past the
SURF+n*stride boundary, hsw/bdw suffer more heavily and
start to underrun constantly. i965/g4x appear to be immune.
vlv/chv I've not yet checked.

Let's borrow another trick from the skl+ code and search
backwards for a better SURF offset in the hopes of getting the
x offset below the limit. IIRC when I ran into a similar issue
on skl years ago it was causing the hardware to fall over
pretty hard as well.

And let's be consistent and include i965/g4x in the check
as well, just in case I just got super lucky somehow when
I wasn't able to reproduce the issue. Not that it really
matters since we still use 4k SURF alignment for i965/g4x
anyway.

Fixes: 6ede6b06 ("drm/i915: Implement async flips for vlv/chv")
Fixes: 4bb18054 ("drm/i915: Implement async flip for ilk/snb")
Fixes: 2a636e24 ("drm/i915: Implement async flip for ivb/hsw")
Fixes: cda195f1 ("drm/i915: Implement async flips for bdw")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 59fb8218)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo also exported some functions from intel_display.c during backport]

Signed-off-by: NJakub Kicinski <kuba@kernel.org>