4.19.94-ti-rt-r73 bb.org_defconfig
4.19 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/5a23bc00e08d26bb83952953d909c95b42fab70c...
AUFS: https://github.com/sfjro/aufs4-standalone/commit/1bb4caf8d7ee47acc49f05deb4da9d34884c44b2
BBDTBS: https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/b22f92f3ee14e21abd4c8e3da2ff160f970f98ba
CAN-ISOTP: https://github.com/hartkopp/can-isotp/commit/4e965c81a18fa9fbec3a6f60ae7b55d4964a05db
RT: patch-4.19.94-rt39.patch.xz
TI_AMX3_CM3: http://git.ti.com/gitweb/?p=processor-firmware/ti-amx3-cm3-pm-firmware.git;a=commit;h=fb484c5e54f2e31cf0a338d2927a06a2870bcc2c
WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=166fbddc84ba13f17b133073331e015e0f52f0da



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.2.21
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>

already default on BBB/X15, just calcuated everybootup

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: Matt Ranostay <matt.ranostay@konsulko.com>

Ref: https://github.com/aristanetworks/sonic/blob/master/src/tmp468.c



Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>

Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>

Needs rework to upstreamble

Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>

Even with rate limited reporting this is very spammy and since
it is remote device that is providing bogus data there is no
need to report this as error.

Since real_len variable was used only to allow conditional error
message it is now also removed.

[72454.143336] bt_err_ratelimited: 10 callbacks suppressed
[72454.143337] Bluetooth: hci0: advertising data len corrected
[72454.296314] Bluetooth: hci0: advertising data len corrected
[72454.892329] Bluetooth: hci0: advertising data len corrected
[72455.051319] Bluetooth: hci0: advertising data len corrected
[72455.357326] Bluetooth: hci0: advertising data len corrected
[72455.663295] Bluetooth: hci0: advertising data len corrected
[72455.787278] Bluetooth: hci0: advertising data len corrected
[72455.942278] Bluetooth: hci0: advertising data len corrected
[72456.094276] Bluetooth: hci0: advertising data len corrected
[72456.249137] Bluetooth: hci0: advertising data len corrected
[72459.416333] bt_err_ratelimited: 13 callbacks suppressed
[72459.416334] Bluetooth: hci0: advertising data len corrected
[72459.721334] Bluetooth: hci0: advertising data len corrected
[72460.011317] Bluetooth: hci0: advertising data len corrected
[72460.327171] Bluetooth: hci0: advertising data len corrected
[72460.638294] Bluetooth: hci0: advertising data len corrected
[72460.946350] Bluetooth: hci0: advertising data len corrected
[72461.225320] Bluetooth: hci0: advertising data len corrected
[72461.690322] Bluetooth: hci0: advertising data len corrected
[72462.118318] Bluetooth: hci0: advertising data len corrected
[72462.427319] Bluetooth: hci0: advertising data len corrected
[72464.546319] bt_err_ratelimited: 7 callbacks suppressed
[72464.546319] Bluetooth: hci0: advertising data len corrected
[72464.857318] Bluetooth: hci0: advertising data len corrected
[72465.163332] Bluetooth: hci0: advertising data len corrected
[72465.278331] Bluetooth: hci0: advertising data len corrected
[72465.432323] Bluetooth: hci0: advertising data len corrected
[72465.891334] Bluetooth: hci0: advertising data len corrected
[72466.045334] Bluetooth: hci0: advertising data len corrected
[72466.197321] Bluetooth: hci0: advertising data len corrected
[72466.340318] Bluetooth: hci0: advertising data len corrected
[72466.498335] Bluetooth: hci0: advertising data len corrected
[72469.803299] bt_err_ratelimited: 10 callbacks suppressed

Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=203753


Cc: stable@vger.kernel.org
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

commit e33a814e

 upstream.

gcc 10 will default to -fno-common, which causes this error at link
time:

  (.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here

This is because both dtc-lexer as well as dtc-parser define the same
global symbol yyloc. Before with -fcommon those were merged into one
defintion. The proper solution would be to to mark this as "extern",
however that leads to:

  dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls]
   26 | extern YYLTYPE yylloc;
      |                ^~~~~~
In file included from dtc-lexer.l:24:
dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here
  127 | extern YYLTYPE yylloc;
      |                ^~~~~~
cc1: all warnings being treated as errors

which means the declaration is completely redundant and can just be
dropped.

Signed-off-by: Dirk Mueller <dmueller@suse.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[robh: cherry-pick from upstream]
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

- Added driver to use rpmsg with gpiochip interface.Requires PRU firmware Please follow instructions to load PRU firmware https://github.com/deebot/Beaglebone-BidirectionBus/blob/dev/bidirec_299/README.md - Added rule to compile rpmsg-gpio driver in Make and Kconfig

Signed-off-by: Jason Kridner <jdk@ti.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>

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

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

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

Call pm_runtime_get_sync() at the beginning of any functions that will
read or write to the memory mapped eQEP registers.  This is to ensure
that the eQEP peripheral is running and its clock is enabled.

Before this patch, an attempt to read the position file via sysfs would
results in a segmentation fault.  The kernel log would be contain this
error:

[ 2591.653471] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa304180
[ 2591.915165] [<bf005310>] (eqep_get_position [tieqep]) from [<c08930d0>] (dev_attr_show+0x2c/0x58)

More details:
https://gist.github.com/pdp7/fe07082d23f2bfbc362c733a7b0aea72

BeagleBoard mailing list thread:
https://groups.google.com/d/msg/beagleboard/_TdTH7oPEXE/MNvU-mY6DgAJ

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

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

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>

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

https://www.mikroe.com/oled-b-click

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>

#https://lkml.org/lkml/2016/6/14/967



Pwm channels don't send uevents when exported, this change adds the
channels to a pwm class and set their device type to pwm_channel so
uevents are sent.

To do this properly, the device names need to change to uniquely
identify a channel.  This change is from pwmN to pwm-(chip->base):N

Signed-off-by: David Hsu <davidhsu@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

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

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