linux-stable.git/drivers, branch linux-5.19.y

drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers

2022-10-24T07:58:32+00:00

commit d3a7051841f0a4bcb1ee26a1b721c6150cc4c2b1 upstream.

The current scheme for generating the LFP data table pointers
(when the block including them is missing from the VBT) expects
the 0xffff sequence to only appear in the fp_timing terminator
entries. However some VBTs also have extra 0xffff sequences
elsewhere in the LFP data. When looking for the terminators
we may end up finding those extra sequeneces insted, which means
we deduce the wrong size for the fp_timing table. The code
then notices the inconsistent looking values and gives up on
the generated data table pointers, preventing us from parsing
the LFP data table entirely.

Let's give up on the "search for the terminators" approach
and instead just hardcode the expected size for the fp_timing
table.

We have enough sanity checks in place to make sure we
shouldn't end up parsing total garbage even if that size
should change in the future (although that seems unlikely
as the fp_timing and dvo_timing tables have been declared
obsolete as of VBT version 229).

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915/bios: Validate fp_timing terminator presence

2022-10-24T07:58:32+00:00

commit 4e78d6023c15c6acce8fbe42e13027c460395522 upstream.

Validate the LFP data block a bit hardwer by making sure the
fp_timing terminators (0xffff) are where we expect them to be.

Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Rename block_size()/block_offset()

2022-10-24T07:58:32+00:00

commit 39b1bc4b5bcccac781267bb826b035fbb99c8b9d upstream.

Give block_size()/block_offset() a "raw_" prefix since they
both operate on the "raw" (as in not duplicated) BDB block
contents.

What actually spurred this was a conflict between intel_bios.c
block_size() vs. block_size() from blkdev.h. That only
happened to me on a custom tree where we somehow manage to
include blkdev.h into intel_bios.c. But I think the rename
makes sense anyway to clarify the purpose of these functions.

Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20220519140010.10600-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

HID: uclogic: Add missing suffix for digitalizers

2022-10-24T07:58:31+00:00

commit 0977fda0587cbc5403651ba169e264aa01e8a026 upstream.

The Pen (0x02) application usage was changed to Digitalizer (0x01) in
commit f7d8e387d9ae ("HID: uclogic: Switch to Digitizer usage for
styluses"). However, a suffix was not selected for the new usage.

Handle the digitalizer application usage in uclogic_input_configured()
and add the required suffix.

Signed-off-by: José Expósito 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix build breakage with CONFIG_DEBUG_FS=n

2022-10-24T07:58:31+00:00

commit 2130b87b2273389cafe6765bf09ef564cda01407 upstream.

After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr
transition"), a build with CONFIG_DEBUG_FS=n is broken due to a
misplaced brace, along the lines of:

  In file included from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_trace.h:39,
                   from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:41:
  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: At top level:
  ./include/drm/drm_atomic.h:864:9: error: expected identifier or ‘(’ before ‘for’
    864 |         for ((__i) = 0;                                                 \
        |         ^~~
  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8317:9: note: in expansion of macro ‘for_each_new_crtc_in_state’
   8317 |         for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~

Move the brace within the #ifdef so that the file can be built with or
without CONFIG_DEBUG_FS.

Fixes: 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr transition")
Signed-off-by: Nathan Chancellor 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "drm/amd/display: correct hostvm flag"

2022-10-24T07:58:30+00:00

commit 96ab3cb3b0f862308a03046d01d66c7b4154846b upstream.

This reverts commit 796d6a37ff5ffaf9f2dc0f3f4bf9f4a1034c00de.

4K144 resolution isn't available on DCN31.

Reviewed-by: Sherry Wang 
Acked-by: Hamza Mahfooz 
Signed-off-by: Aric Cyr 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

net: ethernet: ti: davinci_mdio: fix build for mdio bitbang uses

2022-10-24T07:58:30+00:00

commit 35bbe652c421037822aba29423f5f1f7d0d69f3f upstream.

davinci_mdio.c uses mdio bitbang APIs, so it should select
MDIO_BITBANG to prevent build errors.

arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdio_remove':
drivers/net/ethernet/ti/davinci_mdio.c:649: undefined reference to `free_mdio_bitbang'
arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdio_probe':
drivers/net/ethernet/ti/davinci_mdio.c:545: undefined reference to `alloc_mdio_bitbang'
arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdiobb_read':
drivers/net/ethernet/ti/davinci_mdio.c:236: undefined reference to `mdiobb_read'
arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdiobb_write':
drivers/net/ethernet/ti/davinci_mdio.c:253: undefined reference to `mdiobb_write'

Fixes: d04807b80691 ("net: ethernet: ti: davinci_mdio: Add workaround for errata i2329")
Signed-off-by: Randy Dunlap 
Cc: Grygorii Strashko 
Cc: Ravi Gunasekaran 
Cc: Eric Dumazet 
Cc: Paolo Abeni 
Cc: Naresh Kamboju 
Cc: Sudip Mukherjee (Codethink) 
Link: https://lore.kernel.org/r/20220824024216.4939-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

clk: bcm2835: Round UART input clock up

2022-10-24T07:58:29+00:00

[ Upstream commit f690a4d7a8f66430662975511c86819dc9965bcc ]

It was reported that RPi3[1] and RPi Zero 2W boards have issues with
the Bluetooth. It turns out that when switching from initial to
operation speed host and device no longer can talk each other because
host uses incorrect UART baud rate.

The UART driver used in this case is amba-pl011. Original fix, see
below Github link[2], was inside pl011 module, but somehow it didn't
look as the right place to fix. Beside that this original rounding
function is not exactly perfect for all possible clock values. So I
deiced to move the hack to the platform which actually need it.

The UART clock is initialised to be as close to the requested
frequency as possible without exceeding it. Now that there is a
clock manager that returns the actual frequencies, an expected
48MHz clock is reported as 47999625. If the requested baud rate
== requested clock/16, there is no headroom and the slight
reduction in actual clock rate results in failure.

If increasing a clock by less than 0.1% changes it from ..999..
to ..000.., round it up.

[1] https://bugzilla.suse.com/show_bug.cgi?id=1188238
[2] https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7

Cc: Phil Elwell 
Signed-off-by: Ivan T. Ivanov 
Reviewed-by: Stefan Wahren 
Link: https://lore.kernel.org/r/20220912081306.24662-1-iivanov@suse.de
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: bcm2835: Make peripheral PLLC critical

2022-10-24T07:58:29+00:00

[ Upstream commit 6c5422851d8be8c7451e968fd2e6da41b6109e17 ]

When testing for a series affecting the VEC, it was discovered that
turning off and on the VEC clock is crashing the system.

It turns out that, when disabling the VEC clock, it's the only child of
the PLLC-per clock which will also get disabled. The source of the crash
is PLLC-per being disabled.

It's likely that some other device might not take a clock reference that
it actually needs, but it's unclear which at this point. Let's make
PLLC-per critical so that we don't have that crash.

Reported-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
Link: https://lore.kernel.org/r/20220926084509.12233-1-maxime@cerno.tech
Reviewed-by: Stefan Wahren 
Acked-by: Noralf Trønnes 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

usb: typec: ucsi: Don't warn on probe deferral

2022-10-24T07:58:29+00:00

[ Upstream commit fce703a991b7e8c7e1371de95b9abaa832ecf9c3 ]

Deferred probe is an expected return value for fwnode_usb_role_switch_get().
Given that the driver deals with it properly, there's no need to output a
warning that may potentially confuse users.

--
V2 -> V3: remove the Fixes and Cc
V1 -> V2: adjust the coding style for better reading format.
 drivers/usb/typec/ucsi/ucsi.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

Signed-off-by: Wayne Chang 
Acked-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20220927134512.2651067-1-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin