From 46c4dc22ac7cde305fcace1342fe1c64776bec26 Mon Sep 17 00:00:00 2001
From: Florin Sarbu <florin@balena.io>
Date: Thu, 29 Nov 2018 11:13:46 +0100
Subject: [PATCH] Revert "random: fix crng_ready() test"

This reverts commit 6e513bc2


from our kernel tree.

We revert this because with that patch, balena gets started
with a delay (it times out the very first time it starts actually)
because of the lack of entropy.

Upstream-Status: Inappropriate [configuration]
Signed-off-by: Florin Sarbu <florin@balena.io>

5.4.106-ti-r42 bb.org_defconfig
BBDTBS: https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/commit/8713eb53254bdfb9fa6c157e08ef989fd49f425f



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: v5.10.111
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

GCC 11 on ARM now complains like the following when trying to determine if
an arch is supported. Presumably because it enforces the default option
'--with-float=hard' which GCC 10 didn't do?

  $ arm-linux-gnueabihf-gcc-11 -march=armv7-a -c -x c /dev/null
  cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU

Due to that, the kernel build system selects the wrong compiler options
which throws errros like this during the build:

  /tmp/ccrHfZPj.s: Assembler messages:
  /tmp/ccrHfZPj.s:116: Error: selected processor does not support `dmb ish' in ARM mode
  /tmp/ccrHfZPj.s:150: Error: selected processor does not support `isb ' in ARM mode
  /tmp/ccrHfZPj.s:160: Error: selected processor does not support `mrrc p15,1,r4,r5,c14' in ARM mode
  /tmp/ccrHfZPj.s:245: Error: selected processor does not support `dmb ish' in ARM mode
  /tmp/ccrHfZPj.s:503: Error: selected processor does not support `dmb ish' in ARM mode
  /tmp/ccrHfZPj.s:527: Error: selected processor does not support `dmb ish' in ARM mode
  /tmp/ccrHfZPj.s:698: Error: selected processor does not support `dmb ish' in ARM mode
  /tmp/ccrHfZPj.s:731: Error: selected processor does not support `isb ' in ARM mode

Fix that by adding '-msoft-float' to KBUILD_CFLAGS before the definition of
the 'arch-$(CONFIG_CPU_<foo>)' instruction selection macros.

Signed-off-by: Juerg Haefliger <juergh@canonical.com>

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

the of_id module parameter is still supported to add another id

During probe every time driver gets resource it should usually check for
error printk some message if it is not -EPROBE_DEFER and return the error.
This pattern is simple but requires adding few lines after any resource
acquisition code, as a result it is often omitted or implemented only
partially.
dev_err_probe helps to replace such code sequences with simple call,
so code:
	if (err != -EPROBE_DEFER)
		dev_err(dev, ...);
	return err;
becomes:
	return dev_err_probe(dev, err, ...);

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200713144324.23654-2-a.hajda@samsung.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

From
https://github.com/Seeed-Studio/seeed-linux-dtoverlays/tree/master/modules/hm3301

already default on BBB/X15, just calcuated everybootup

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

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

#<Daulity> is there a kernel option to not reset gpio state at linux boot ?
#<zmatt> Daulity: the kernel does not reset any gpio unless explicitly requested to by a driver
#<zmatt> though by default if cape-universal is enabled then a gpio-of-helper device gets set up which configures all gpios as input... though that is normally the state they are in anyway after reset
#<zmatt> Daulity: why? are you setting gpios in u-boot?
#<Daulity> yes u-boot sets a few gpio's before it boots the kernel they get reset to a certain state not certain if u-boot or linux kernel
#<Daulity> was just wondering
#<zmatt> the annoying bit is that this isn't really fixable by applying an overlay on top of cape-universal due the the limitations of overlays and the fact that status="disabled"; doesn't work on individual gpios of a gpio-of-helper device node
#<zmatt> so your options are to modify the cape-universal overlay or disable cape-universal entirely and use an overlay to declare/export gpios (with initialization of your choice)
#<Daulity> i see
#<zmatt> (or fix the gpio-of-helper drivers to respect the status property of individual gpios... which is probably a 2-line patch)
#<zmatt> *driver
#<zmatt> interesting, if CONFIG_OF_KOBJ=n then nodes with non-okay status property don't even get deserialized, however in practice CONFIG_OF_KOBJ is always y (specifically, it is only n in kernels that lack sysfs support)
#<zmatt> yeah it's definitely a 2-line fix
#<zmatt> https://pastebin.com/f8V8pz1V


#<Daulity> thanks :)
#<zmatt> rcn-ee: can you include that patch?  that way overlays can disable cape-universal's gpio export for individual gpios used by the overlay
#<zmatt> e.g. &ocp { cape-universal { P9_14 { status = "disabled"; }; }; };
#<zmatt> Daulity: you can use that in an overlay and then if you still want the gpio exported you can just declare your own gpio-of-helper ... unfortunately it doesn't support exporting a gpio without initializing it, but at least you can choose *how* to initialize it (input, output-low, output-high) and whether or not linux userspace is allowed to change the direction of the gpio

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

hack: gpiolib: yes we have drivers stomping on each other, we need to find a better way to share gpio...

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

Authors:
Pantelis Antoniou <panto@antoniou-consulting.com>
Charles Steinkuehler <charles@steinkuehler.net>
Jason Kridner <jdk@ti.com>
Robert Nelson <robertcnelson@gmail.com>
Tobias Müller <Tobias_Mueller@twam.info>
Matthijs van Duin <matthijsvanduin@gmail.com>

This patch was derived from 19 commits:
https://github.com/RobertCNelson/linux-dev/tree/35e301ae8436e9f56f65bf1a7440021eda42f948/patches/drivers/ti/gpio



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

------=_Part_422_1349561576.1515022447432
Content-Type: text/plain; charset="UTF-8"

Hello all,

The TI touch screen driver does not work _right_ with the libts-bin package
in the jessie image.

$ cat /etc/dogtag
BeagleBoard.org Debian Image 2018-01-01

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.10 (jessie)
Release:        8.10
Codename:       jessie

$ dpkg -l | grep  libts-bin
ii  libts-bin                             1.14-1rcnee0~jessie+20171122
                      armhf        touch screen library utilities

$ sudo ts_calibrate
ts_setup: No such file or directory

It is possible to make it work by setting the TSLIB_TSDEVICE environment
variable:

$ sudo su
# export TSLIB_TSDEVICE=/dev/input/event2
# ts_calibrate

But, that's a bit of a pain since the environment variable always needs to
be set in order to use the touchscreen.

It appears that this version of the utilities uses the INPUT_PROP_DIRECT
propbit to automatically detect which /dev/input/event device is the
touchscreen.

It looks like the following is the only change needed to make it work.

Unfortunately, I don't have currently have a way to build a custom kernel
for the BeagleBone in order to test it. If there is anyone that could I
would
appreciate it.

Regards,
Hartley

This reverts commit 3c9dc275

.

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

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

When CONFIG_PM is not enabled, the function
davinci_mdio_update_dt_from_phymask is not defined. This patch fixes
this so that the build does not fail with CONFIG_PM disabled.

Signed-off-by: Will Eccles <will@eccles.dev>

I have encountered the same issue(s) on A6A boards.

I couldn't find a patch,  so I wrote this patch to update the device tree
in the davinci_mdio driver in the 3.15.1 tree, it seems to correct it. I
would welcome any input on a different approach.

https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ



v4.1-rcX: added hack around CONFIG_OF_OVERLAY
v4.2-rc3+: added if (of_machine_is_compatible("ti,am335x-bone")) so we do
not break dual ethernet am335x devices

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

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

Add compatible string for Micron SPI NOR Authenta device.

Signed-off-by: Shivamurthy Shastri <sshivamurthy@micron.com>
Link: https://lore.kernel.org/r/20210419204015.1769-1-sshivamurthy@micron.com


Signed-off-by: Mark Brown <broonie@kernel.org>

This reverts commit 956b200a

.

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

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

PRU IRAM addresses need to be masked before being handled to
remoteproc. This is due to PRU Binutils' lack of separate address
spaces for IRAM and DRAM.

Signed-off-by: Dimitar Dimitrov <dinuxbg@gmail.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>

v5.4.18-2021_0114

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

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

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

Reference: 1657f11c


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

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

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

https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/tree/v5.4.x-ti-overlays

https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/commit/8713eb53254bdfb9fa6c157e08ef989fd49f425f


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

http://git.ti.com/gitweb/?p=processor-firmware/ti-amx3-cm3-pm-firmware.git;a=commit;h=fb484c5e54f2e31cf0a338d2927a06a2870bcc2c


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