5.10.168-ti-arm64-r108 bb.org_defconfig
TI SDK: 08.06.00.007
5.10 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/76b3e88d569210a51399e8d8c8babd995af29d11...2c23e6c538c879e380401ae4b236f54020618eaa
BBDTBS: https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/commit/b377ecd1e5b21074adcadb02541486ae092ad36d
AUFS: https://github.com/sfjro/aufs-standalone/commit/7d72a088928cc75b73509f42595186cc17325973
WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=ae1421fc746f456c6124d6265413c28460a85f31
KSMBD: https://github.com/cifsd-team/ksmbd/commit/bf249dcef4d5a20eabf9656154419a0042769b90
WPANUSB: https://git.beagleboard.org/beagleconnect/linux/wpanusb/-/commit/6aa9bf65b9d88a2c9a111e7b4aed03de2be9413d
BCFSERIAL: https://git.beagleboard.org/beagleconnect/linux/bcfserial/-/commit/db467023bd136c97c2e13c3a8b9e41dbdfafbc66



Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Reference: v6.0.19
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Since gcc13, each member of an enum has the same type as the enum [1]. And
that is inherited from its members. Provided:
  VTIME_PER_SEC_SHIFT     = 37,
  VTIME_PER_SEC           = 1LLU << VTIME_PER_SEC_SHIFT,
  ...
  AUTOP_CYCLE_NSEC        = 10LLU * NSEC_PER_SEC,
the named type is unsigned long.

This generates warnings with gcc-13:
  block/blk-iocost.c: In function 'ioc_weight_prfill':
  block/blk-iocost.c:3037:37: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int'

  block/blk-iocost.c: In function 'ioc_weight_show':
  block/blk-iocost.c:3047:34: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int'

So split the anonymous enum with large values to a separate enum, so
that they don't affect other members.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113



Cc: Martin Liska <mliska@suse.cz>
Cc: Tejun Heo <tj@kernel.org>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: cgroups@vger.kernel.org
Cc: linux-block@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20221213120826.17446-1-jirislaby@kernel.org


Signed-off-by: Jens Axboe <axboe@kernel.dk>

The behavior of 'enum' types has changed in gcc-13, so now the
UNBUSY_THR_PCT constant is interpreted as a 64-bit number because
it is defined as part of the same enum definition as some other
constants that do not fit within a 32-bit integer. This in turn
leads to some inefficient code on 32-bit architectures as well
as a link error:

arm-linux-gnueabi/bin/arm-linux-gnueabi-ld: block/blk-iocost.o: in function `ioc_timer_fn':
blk-iocost.c:(.text+0x68e8): undefined reference to `__aeabi_uldivmod'
arm-linux-gnueabi-ld: blk-iocost.c:(.text+0x6908): undefined reference to `__aeabi_uldivmod'

Split the enum definition to keep the 64-bit timing constants in
a separate enum type from those constants that can clearly fit
within a smaller type.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/20230118080706.3303186-1-arnd@kernel.org


Signed-off-by: Jens Axboe <axboe@kernel.dk>

gcc-13 slightly changes the type of constant expressions that are defined
in an enum, which triggers a compile time sanity check in libata:

linux/drivers/ata/libahci.c: In function 'ahci_led_store':
linux/include/linux/compiler_types.h:357:45: error: call to '__compiletime_assert_302' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
357 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

The new behavior is that sizeof() returns the same value for the
constant as it does for the enum type, which is generally more sensible
and consistent.

The problem in libata is that it contains a single enum definition for
lots of unrelated constants, some of which are large positive (unsigned)
integers like 0xffffffff, while others like (1<<31) are interpreted as
negative integers, and this forces the enum type to become 64 bit wide
even though most constants would still fit into a signed 32-bit 'int'.

Fix this by changing the entire enum definition to use BIT(x) in place
of (1<<x), which results in all values being seen as 'unsigned' and
fitting into an unsigned 32-bit type.

Upstream-Status: Backport

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107917
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405


Reported-by: Luis Machado <luis.machado@arm.com>
Cc: linux-ide@vger.kernel.org
Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: stable@vger.kernel.org
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Luis Machado <luis.machado@arm.com>
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>

The upcoming GCC release has refactored the gimple plugin interface a
bit and unless gimple-iterator.h is included before gimple-fold.h I end
up with a bunch of missing declarations when building the stack
protector plugin.

Upstream-Status: Backport [https://lore.kernel.org/all/20230113173033.4380-1-palmer@rivosinc.com/

]
Reported-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Link: https://lore.kernel.org/all/20230113173033.4380-1-palmer@rivosinc.com/


Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>

binutils 2.39 changed the signature of init_disassemble_info(),
which now causes perf and bpftool to fail to compile.

Relevant binutils commit: [1]

There is a proper fix in development upstream[2].
This is a work-around for older kernels.

[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=60a3da00bd5407f07d64dff82a4dae98230dfaac
[2] https://patchwork.kernel.org/project/netdevbpf/cover/20220801013834.156015-1-andres@anarazel.de/



Upstream-Status: Pending
Signed-off-by: Anton Antonov <Anton.Antonov@arm.com>

 tools/perf/util/annotate.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Using standard mode, rare false ACK responses were appearing with
i2cdetect tool. This was happening due to NACK interrupt triggering
ISR thread before register access interrupt was ready. Removing the
NACK interrupt's ability to trigger ISR thread lets register access
ready interrupt do this instead.

Cc: <stable@vger.kernel.org> # v3.7+
Fixes: 3b2f8f82

 ("i2c: omap: switch to threaded IRQ support")
Signed-off-by: Reid Tonking <reidt@ti.com>

In case of error, genlmsg_unicast already cancel the skb and free it.
Return the error code and don't cancel and free the skb.

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>

Hardcode LED configuration for LED2 signal to be link status
and LED0 signal to be rx/tx

Signed-off-by: Nishanth Menon <nm@ti.com>

So far tidss Driver only had support for display panels and bridges
that are compatible with connector framework. However, there are
drivers that aren't compatible with the same. TIDSS traditionally has
only supported the standard connector framework oriented drivers. Now,
using a module parameter that can be set to select between the bridge
drivers that need a bit of a "support".

This is still a hack, since this approach still applies the hack to
all bridges and panel instead of selectively applying the hack just to
the bridges that need this workaround.

Due to the nature of this workaround - the workaround is ONLY applied
for AM62x platform - leaving all other platforms as they stand.

For example: bootargs (via uEnv.txt or extlinux.conf) can be modified by
setting: tidss.no_connector_hack=0

Signed-off-by: Dhruva Gole <d-gole@ti.com>
Tested-by: Aradhya Bhatia <a-bhatia1@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
get ignored unless somebody calls drm_bridge_hpd_enable(). When the
connector for the bridge is bridge_connector, such a call is done from
drm_bridge_connector_enable_hpd().

However drm_bridge_connector_enable_hpd() is never called on init paths,
documentation suggests that it is intended for suspend/resume paths.

In result, once encoders are switched to bridge_connector,
bridge-detected HPD stops working.

This patch adds a call to that API on init path.

This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD
events via interrupts.

Fixes: c24110a8

 ("drm: rcar-du: Use drm_bridge_connector_init() helper")
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211225063151.2110878-1-nikita.yoush@cogentembedded.com

This takes a leaf from drivers/gpu/drm/rockchip/rockchip_rgb.c

This is a bit of a chicken or hen issue at this point. when the call chain
looks like this:
tidss_atomic_check
drm_atomic_check_only
drm_atomic_commit
drm_client_modeset_commit_atomic
drm_client_modeset_commit_locked
drm_client_modeset_commit
drm_fb_helper_set_par
fbcon_init
visual_init

The bridge_attach is invoked, but bridge_enable is NOT invoked yet, at
this stage, we cannot really confirm the display format.

So, it begs the question - what do others do? why do they work?

Signed-off-by: Nishanth Menon <nm@ti.com>

This takes a leaf from drivers/gpu/drm/rockchip/rockchip_rgb.c

Most of the bridge drivers seem to invoke connector_init and
attach_encoder in the modeset_init function. this seems to let the DRM
framework call the necessary hooks to get the bridges to probe
successfully.

This might imply our DSS drivers are'nt compatible with quite a many
bridges out there.. this needs to be dug in deeper.

The current hack is introduced solely for AM625 - unfortunately, that
also means that drivers like SK Sii9022 wont work.

Signed-off-by: Nishanth Menon <nm@ti.com>

Add a function to lookup the subrevision of the tidss component. this
can be used to introduce a hack later in the series.

Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Commit 165cd04f

 upstream
and related patches to phy layer.

This is not a clean backport, needs work to properly
pick the necessary patches.

Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>

On some boards the HDMI bridge takes a 24bit DPI input,  but only 16
data pins are actually enabled from the SoC.  This new property
forces the output to be RGB565 on a specific video port if the
bridge requests a 24bit RGB color space.

This assumes that the video port is connected like so:

SoC : Bridge
R0 ->   R3
R1 ->   R4
R2 ->   R5
R3 ->   R6
R4 ->   R7
G0 ->   G2
G1 ->   G3
G2 ->   G4
G3 ->   G5
G4 ->   G6
G5 ->   G7
B0 ->   B3
B1 ->   B4
B2 ->   B5
B3 ->   B6
B4 ->   B7

On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.

The bridge sees 24bits of data,  but the lsb's are always zero.

Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

TC358762 wants the DSI host to be prepared before it is powered up, so
set the flag to request that the upstream bridges have their
pre_enable called first.

Link: https://github.com/raspberrypi/linux/commit/f57b6e4732ddbedc785c8d1d52c4f1c7101dbfa1



Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

DSI sink devices typically want the DSI host powered up and configured
before they are powered up. pre_enable is the place this would normally
happen, but they are called in reverse order from panel/connector towards
the encoder, which is the "wrong" order.

Add a new flag pre_enable_upstream_first that any bridge can set
to swap the order of pre_enable (and post_disable) for that and the
immediately upstream bridge.
Should the immediately upstream bridge also set the
pre_enable_upstream_first flag, the bridge upstream of that will be called
before either of those which requested pre_enable_upstream_first.

eg:
- Panel
- Bridge 1
- Bridge 2 pre_enable_upstream_first
- Bridge 3
- Bridge 4 pre_enable_upstream_first
- Bridge 5 pre_enable_upstream_first
- Bridge 6
- Encoder
Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3,
Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder.

Link: https://lore.kernel.org/all/ec19836b0fbbc1bb53a6ba6ce93eec2184676aae.1646406653.git.dave.stevenson@raspberrypi.com/



Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

Mapping to the drm_bridge flag pre_enable_upstream_first,
add a new flag prepare_upstream_first to drm_panel to allow
the panel driver to request that the upstream bridge should
be pre_enabled before the panel prepare.

Link: https://lore.kernel.org/all/a593a187fe3e6fc1ca5bf3db001ed87457e3d4ee.1646406653.git.dave.stevenson@raspberrypi.com/



Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

Update VESA standard timings for RPi panel

Signed-off-by: Rahul T R <r-ravikumar@ti.com>

The Raspberry Pi 7" 800x480 panel uses a Toshiba TC358762 DSI
to DPI bridge chip, so there is a requirement for the timings
to be specified for the end panel. Add such a definition.

upstream link: https://lore.kernel.org/lkml/20220131191517.30249-1-detlev.casanova@collabora.com/T/



Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

If no interrupt is defined then a timer and workqueue are used
to poll the controller.
On remove these were not being cleaned up correctly.

Fixes: ca61fdaba79f "Input: edt-ft5x06: Poll the device if no interrupt is
configured."

Link: https://github.com/raspberrypi/linux/commit/ba209048b9ee073bc25a71297759cbafd00c68eb



Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

Not all systems have the interrupt line wired up, so switch to
polling the touchscreen off a timer if no interrupt line is
configured.

Link: https://github.com/raspberrypi/linux/commit/ca61fdaba79fa29fc950b3b731c99557d6781ff5



Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

commit 1d746d44

 upstream.

The driver was implementing a get_brightness function that
tried to read back the PWM setting of the display to report
as the current brightness.
The controller on the display does not support that, therefore
we end up reporting a brightness of 0, and that confuses
systemd's backlight service.

Remove the hook so that the framework returns the current
brightness automatically.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-8-detlev.casanova@collabora.com


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

commit 8c518eb4

 upstream.

We need independent control of the resets for the panel&bridge,
vs the touch controller.

Expose the reset lines that are on the Atmel's port C via the GPIO
API so that they can be controlled appropriately.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-7-detlev.casanova@collabora.com


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

commit 4866e35e

 upstream.

The Atmel was doing a load of automatic sequencing of
control lines, however it was combining the touch controller's
reset with the bridge/panel control.

Change to control the control signals directly rather than
through the automatic POWERON control.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-6-detlev.casanova@collabora.com


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

commit 89339a2a

 upstream.

The initial state of the Atmel is not defined, so ensure the
backlight PWM is set to 0 by default.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-5-detlev.casanova@collabora.com


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

commit 00440bcd

 upstream.

The driver was using the regmap lock to serialise the
individual accesses, but we really need to protect the
timings of enabling the regulators, including any communication
with the Atmel.

Use a mutex within the driver to control overall accesses to
the Atmel, instead of the regmap lock.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-4-detlev.casanova@collabora.com


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

commit 7291e7d6

 upstream.

There's no reason why 2 Raspberry Pi DSI displays can't be
attached to a Pi Compute Module, so the backlight names need to
be unique.

Use the parent dev_name. It's not as readable, but is unique.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20220124220129.158891-2-detlev.casanova@collabora.com


Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rahul T R <r-ravikumar@ti.com>

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

"uio" for generic use
"ti,pruss-shmem" for backwards compatibility

the of_id module parameter is still supported to add another id