- Nov 05, 2023
-
-
Jason Kridner authoredFrom 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>
-
- Jun 27, 2023
-
-
Robert Nelson authored
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>
-
Robert Nelson authored
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Reference: v5.10.111 Signed-off-by: -
Juerg Haefliger authored
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>
-
Matthijs van Duin authored
"uio" for generic use "ti,pruss-shmem" for backwards compatibility the of_id module parameter is still supported to add another id
-
Matthijs van Duin authored
-
Andrzej Hajda authored
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>
-
Jason Kridner authored
-
-
Robert Nelson authored
already default on BBB/X15, just calcuated everybootup Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
#<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 authored
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 authored
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:
-
frost authored
-
bigguiness@gmail.com authored
------=_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 -
Robert Nelson authored
This reverts commit 3c9dc275 . Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Will Eccles authored
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>
-
Jay at Control Module Industries authored
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:
-
Pantelis Antoniou authored
-
Robert Nelson authored
Signed-off-by: -
Shivamurthy Shastri authored
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:
-
Robert Nelson authored
This reverts commit 956b200a . Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Dimitar Dimitrov authored
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>
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
v5.4.18-2021_0114 Signed-off-by: -
Robert Nelson authored
Reference: v5.4.18 Signed-off-by: -
Robert Nelson authored
Reference: v5.5.19 Signed-off-by: -
Robert Nelson authored
Reference: 1657f11c Signed-off-by:
-
Robert Nelson authored
Reference: v5.4.189 Signed-off-by: -
Robert Nelson authored
Reference: v5.12.19 Signed-off-by: -
-
-
