Unexpected behavior on SPI Device on kernel 4.19

Hi.

I detected this problem.
I have 2 SPI Devices on the same bus (spidev2.0 and spidev2.1).
On kernel 4.14 is working fine. After the upgrade to 4.19 I cannot use both devices. If I tried to initialize the first device(on CS1) and after that I tried to initialize the second device (on CS0) I cannot initilize this device - is like the SPIbus is in on wait or in block state.
There is a way do debug the spi bus ? There is a way to check what is happening ? I'm using ardupilot software and everything as I said is working on 4.14 but in 4.19 not.

Thanks
root@beaglebone:~# /opt/scripts/tools/version.sh
git:/opt/scripts/:[20c080bc91f243ef852a704758788a31083b0f9e]
eeprom:[A335BNLTBBG1BBG219100724]
model:[TI_AM335x_BeagleBone_Green]
dogtag:[BeagleBoard.org Debian Stretch Console Image 2020-09-21]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-gc9b3922522]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-UIO-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[M-BB-BBG-00A0]
kernel:[4.19.142-bone-rt-r56]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.14.20201021.1-0~stretch+20201021]
pkg:[bb-customizations]:[1.20200826.0-0~stretch+20200826]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~stretch+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~stretch+20200813]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~stretch+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal input bluetooth netdev gpio admin spi iio i2c docker tisdk weston-launch xenomai cloud9ide pwm eqep remoteproc]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 1.047028] remoteproc remoteproc0: wkup_m3 is available
[ 1.152080] remoteproc remoteproc0: powering up wkup_m3
[ 1.152101] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[ 1.154288] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[ 0.606521] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[ 0.617964] gpio-of-helper ocp:cape-universal: ready
END

Reproduce the issue on the BeagleBone Green using kernel 4.14 and 4.19, with spidev2.0 and spidev2.1 initialized in the reported order. Start by comparing dmesg output and the SPI device initialization behavior; done means both devices initialize and can be used, or the kernel-side cause is isolated.

Written by the indexing model from the issue text.