Upgrade 'next' NILRT development kernel from 6.0.y-rt to 6.1.y-rt#112
Closed
gratian wants to merge 68 commits intoni:rebase/stable-rt/v6.1-rtfrom
Closed
Upgrade 'next' NILRT development kernel from 6.0.y-rt to 6.1.y-rt#112gratian wants to merge 68 commits intoni:rebase/stable-rt/v6.1-rtfrom
gratian wants to merge 68 commits intoni:rebase/stable-rt/v6.1-rtfrom
Conversation
Signed-off-by: Ben Shelton <ben.shelton@ni.com> Acked-by: Scot Salmon <scot.salmon@ni.com> Acked-by: Terry Wilcox <terry.wilcox@ni.com> Natinst-ReviewBoard-ID: 69848 [gratian: convert to new syscall table format for arm] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [bstreiff: update the number for this painful out-of-tree syscall] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> [gratian: update due to new syscall introduced by ecb8ac8 ("mm/madvise: introduce process_madvise() syscall: an external memory hinting AP")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: update syscall numbers to account for upstream additions; dropped arm bits] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: bump syscall number to account for upstream process_mrelease addition] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: bump syscall number to account for upstream 'futex_waitv' and 'set_mempolicy_home_node' additions] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
… warm reboot Another group is requesting that we provide an API to allow them to signal that the next reboot should be "cold". They need this to guarantee that the FPGA will not be running and cause the system to reboot at a bad time. This change creates a RW file at /sys/kernel/ni_requested_reboot_type. The default value is 0. - If when we reboot the value is 0 then we do the normal reset behavior. - If the value is 1 we attempt to do a PCI reboot (using the CF9 register) and fall back to the normal reboot method if that fails. - If the value is 2 we attempt to do an ACPI reboot and fall back to the normal reboot method if that fails. We selected a reboot using the CF9 register over attempting to do an EFI reboot because we don't have much time to test this feature and we've found EFI features to be fairly buggy. For next release the plan is to do an EFI cold reboot, but put it in early enough to properly test it. Rebooting using the CF9 register should work on all x64 hardware that we will support for 2014 (smasher and hammerhead). Signed-off-by: Terry Wilcox <terry.wilcox@ni.com> Acked-by: Brad Mouring <brad.mouring@ni.com> Natinst-ReviewBoard-ID: 68018
Currently, we provide NI cold boot support on x64 targets. However, at some future point, we may wish to provide this support on other targets as well. Adding a config option to specify that a target supports NI cold boot functionality; this fixes the build for Zynq targets and doesn't paint us into a corner later. Signed-off-by: Ben Shelton <ben.shelton@ni.com> [gratian: fix trivial conflict with ceea991 ("bpf: Move bpf_dispatcher function out of ftrace locations")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Implement polling on procfs' "interrupts" file which observes changes to IRQ action handlers. The poll fires each time an action handler is registered or unregistered. This change enables daemons to watch for changes and apply certain system policies relating to IRQ processing. For example, modify execution priority of dedicated IRQ tasks after they're created. include/linux/interrupt.h kernel/irq/manage.c Add change counter for handler registrations and a wait queue to notify tasks on updates. fs/proc/interrupts.c Add polling callback on aforementioned counter and wait queue. Signed-off-by: Haris Okanovic <haris.okanovic@ni.com> Signed-off-by: Ovidiu-Adrian Vancea <ovidiu.vancea@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Natinst-ReviewBoard-ID: 111860, 163902 [gratian: fixed small rebase conflict] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [bstreiff: un-trivialize from changes in fddda2b ("proc: introduce proc_create_seq{,_data}") and convert file_operations to proc_ops] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com>
The issue is, if core soft reset is issued while Intel Apollo Lake
USB mux is in Host role mode, it takes close to 7 minutes before we
are able to switch USB mux from Host mode to Device mode. This is
due to RTL bug.
The workaround is to let BIOS issue the core soft reset via _DSM
method. It will ensure that USB mux is in Device role mode before
issuing core soft reset, and will inform the driver whether the
reset is success within the timeout value, or the timeout is exceeded.
commit cd78b8067c6e ("usb: dwc3: call _DSM for core soft reset")
originated from http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.1/
Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
[akash.mankar@ni.com: changed the way has_dsm_for_softreset property is
set in dwc3-pci.c and read in core.c]
Signed-off-by: Akash Mankar <akash.mankar@ni.com>
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Acked-by: Gratian Crisan <gratian.crisan@ni.com>
Acked-by: Brandon Streiff <brandon.streif@ni.com>
Natinst-ReviewBoard-ID: 178124
[gratian: fixed merge conflicts, mainly due to dwc3_soft_reset removal]
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
[bstreiff: fixed merge conflicts due to property refactor by 1a7b12f
("usb: dwc3: pci: Supply device properties via driver data")]
[gratian: fix merge conflict with f580170
("usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc")]
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
[gratian: fix conflict with 582ab24
("usb: dwc3: pci: Set "linux,phy_charger_detect" property on some Bay Trail boards")]
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com> [gratian: fix conflict with fa32e85 ("tracing: Add new trace_marker_raw"); rename NI specific implementation until we can replace it] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [bstreiff: fixups due to struct member renames in 1329249 ("tracing: Make struct ring_buffer less ambiguous")] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> [gratian: update for 22c36b1 ("tracing: make tracing_init_dentry() returns an integer instead of a d_entry pointer")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fixups due to tracing contex introduction in edbaaa1 ("tracing: Merge irqflags + preemt counter, add RT bits")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fixups due to tracing_gen_ctx_flags() API change in 8cac5db ("tracing: Merge irqflags + preemt counter, add RT bits")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: use always_inlined __trace_buffer_lock_reserve() introduced by 3e9a8aa ("tracing: Create a always_inlined __trace_buffer_lock_reserve()")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
The clocksource watchdog is used to detect instabilities in the current clocksource. This is a beneficial feature on new/unknown hardware however it can create problems by falsely triggering when the watchdog wraps. The reason is that an interrupt storm and/or high priority (FIFO/RR) tasks can preempt the timer softirq long enough for the watchdog to wrap if it has a limited number of bits available by comparison with the main clocksource. One observed example is on a Intel Baytrail platform where TSC is the main clocksource, HPET is disabled due to a hardware bug and acpi_pm gets selected as the watchdog clocksource. Provide the option to disable the clocksource watchdog for hardware where the clocksource stability has been validated. Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fix trivial conflict with fc153c1 ("clocksource: Add a Kconfig option for WATCHDOG_MAX_SKEW")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fix trivial conflict with 7cf8f44 ("x86: fs: kmsan: disable CONFIG_DCACHE_WORD_ACCESS")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
This reverts commit e1d7ba8. NI has a use case that involves distributed networked Linux devices that need to share the same concept of time using a mechanism like IEEE-1588 or 802.1AS. The “master” device (ie. the device with the time all other devices will be synchronized to) is often a device that boots up set to the Posix Epoch, mainly because it lacks a battery-backed RTC. (note: the existence of an RTC does not prevent a device from booting up at or very near the Posix Epoch, it just greatly reduces the likelihood). If a slave device attempted to synchronize its CLOCK_REALTIME to that of the master – and the master’s time was < Epoch+slave uptime, that slave would not be able to synchronize. This use case is believed to be very common among embedded devices, especially those without RTCs. Long term: We (NI Timing & Sync) are planning on engaging with the upstream community to educate them on our use case and hopefully put a different solution in place which solves the original problem (preventing a negative boot time representation) while also allowing our use case to continue working as it did prior to the change we’re reverting. Once that happens, we can drop this revert. Signed-off-by: Brad Mouring <brad.mouring@ni.com> Reported-by: Vineeth Acharya <vineeth.acharya@ni.com> Tested-by: Rick Ratzel <rick.ratzel@ni.com> Natinst-CAR-ID: 629499 [bstreiff: reduced control flow in do_settimeofday64 due to unassigned 'ret'] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> [gratian: fix conflict with b8ac29b ("timekeeping: contribute wall clock to rng on time change")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
The cRIO-903x architecture is sort of special, we do not connect
a dimm to the SPD because we use flash instead, but the SPD is still
present because the processor expects it. However, enumerating and
registering the SPD i2c bus is causing interrupt storms, so for now
we skip the registration on all 903x devices.
Fixes: 01590f3 ("i2c: i801: Instantiate SPD EEPROMs automatically")
Signed-off-by: Bill Pittman <bill.pittman@ni.com>
Natinst-AZDO-ID: 1573148
(cherry picked from commit 4de019e)
Added an NI RT features driver. This is an ACPI device that exposes LEDs, switches, and other hardware features of the Smasher controllers. Not all of the proposed features of the device work as expected, and some features may be removed in the future. Development work on this device by the hardware team is currently not a high priority. These issues will be addressed once the hardware team gets back to this device. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com> [gratian: fix conflict with 7a6ff4c ("misc: hisi_hikey_usb: Driver to support onboard USB gpio hub on Hikey960")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fix conflict with bb3b655 ("staging: hikey9xx: split hi6421v600 irq into a separate driver")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fix conflict with f396ede ("misc: open-dice: Add driver to expose DICE data to userspace")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fix trivial conflict with 6c93c6f ("misc: Add a mechanism to detect stalls on guest vCPUs")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [gratian: fix trivial conflict with 393fc2f ("misc: microchip: pci1xxxx: load auxiliary bus driver for the PIO function in the multi-function endpoint of pci1xxxx device.")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
On our Zynq targets, we expose the power-on reset status of the controller via a soft_reset sysfs file. The same underlying bit in the CPLD is exposed as hard_boot on our Smasher targets. In this commit we change the Smasher implementation to match Zynq. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
On systems where FPGA autoload is controlled by software, we need a way to determine if a system has just had power applied. This is necessary to implement the autoload on every power-on feature. Once the FPGA has been autloaded after power-on, software sets a bit in the CPLD so that subsequent (non power-on) resets don't cause the FPGA to be autoloaded again. The CPLD provides the HARD_BOOT_N bit for this purpose. On systems where FPGA autoload is controlled by hardware, such as Smasher, we need to set this bit at some point after power-on so that software can correctly determine the reset state of the controller. Since software has no insight into the status of FPGA autoload on these systems, we can just set this bit if necessary when the driver loads. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Changed the strings returned by the reset_source sysfs file to match those returned on Zynq. Changed the algorithm used to determine the reset source to match Zynq. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com> (Note that the Smasher CPLD currently returns incorrect values for the reset source in some cases. See CARs 458093 and 458094.)
In nirtfeatures_acpi_add, we create several sysfs files. As currently implemented, there is a window where access to a sysfs file may cause our spinlock to be used before it's been initialized, or may cause us to write an incorrect value to an I/O port. We can close this window by moving the creation of the sysfs files closer to the end of the function. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
The Smasher CPLD has recently exposed some new registers. In this commit we display the values of these registers in the output of the register_dump sysfs file. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
When we built Hammerhead, we used ID 4 instead of 1. We don't want to rework all of the boards to match the documentation, so we're just changing the documentation and driver to match what we built. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
The existing recovery_mode and no_fpga bits are now read only. A new bit, no_fpga_sw, exists for software to tell the CPLD to assert NO_FPGA at the next reset. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
The driver currently returns an error from init if it doesn't recognize the backplane ID. This causes the kernel to hang on boot. Although this is probably a bug somewhere else in the kernel, there's no real benefit to returning an error in this case. It's sufficient to print an error message to the console and return "Unknown" as the backplane ID. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
The BIOS will set the HARD_BOOT_N bit at post, so the driver no longer needs to do this. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Remove the unused NI_HW_REBOOT config option. We're not going to use this. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Updated registers to match the latest CPLD documentation, removed several sysfs files that were only used for development debugging, and removed several now unused constants. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
These changes add support for PIEs (physical interface elements), which
are defined as physical elements fixed to a controller/chassis with
which a user can interact (e.g. LEDs and switches) and whose meaning
is user-defined and implementation-specific.
The support for these elements, in terms of enumerating and interacting
with them (i.e. retrieving the list of elements, getting/setting their
current state, enabling notifications, etc.) is embedded within the
BIOS as a set of ACPI methods. The changes to the CPLD driver act as a
bridge between these methods and existing Linux kernel facilities as
described below to expose the elements and any applicable metadata to
user mode. The metadata or knowledge needed for the interpretation
thereof is not a prerequisite to interacting with the elements--it is
there for upper-level value add software to use to improve the user
experience. In other words, Linux users familiar with the class drivers
by which the elements are surfaced should not have any issues
interfacing with them without knowing the meaning of the attached
metadata.
Output elements, which consist currently of LEDs, are surfaced via the
LED class driver. Each LED and color becomes its own LED class device
with the naming convention 'nilrt:{name}:{color}'. Any additional
attributes/metadata intended for upper-level software are appended to
the name, each separated by colons, as suggested by the LED class driver
documentation in the Linux kernel proper, except where there is already
a standard way to communicate a specific piece of metadata (e.g.,
maximum brightness, which is exposed via the /sys/class/leds/.../
max_brightness attribute node).
Input elements as surfaced via the input class driver. As with output
elements, each input element registers its own separate driver whose
name and associated metadata are transmitted via the name attribute
attached to the input device, retrievable via the EVIOCGNAME ioctl,
using the same convention as described above for output elements. The
input class driver model is that events are pushed (i.e. reported) to
indicate state changes, so to facilitate this, the CPLD driver has an
ACPI notify callback that is invoked when an input element changes state
and its BIOS support generates a general purpose event per the ACPI
GPE model. The notify callback checks the instantaneous state of the
input element and reports a keyboard event on its particular device with
a scan code of 256 (BTN_0), where a key down event means that the input
element is in the '1' state (down, engaged, on, pressed, etc.) and a key
up event means that the input element is in the '0' state (off,
disengaged, released, etc.). User mode software can then monitor for
these specific events to determine when the state of the element has
changed, or can use the EVIOCGKEY ioctl on the appropriate input device
to retrieve the instantaneous state of the element.
Signed-off-by: Aaron Rossetto <aaron.rossetto@ni.com>
(joshc: fixed up strnicmp -> strncasecmp for 4.0)
Signed-off-by: Josh Cartwright <joshc@ni.com>
For compatibility with myRIO, don't change the name of the wireless PIE LEDs. Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com> Reviewed-by: Jaeden Amero <jaeden.amero@ni.com> Reviewed-by: Josh Cartwright <joshc@ni.com> Natinst-ReviewBoard-ID: 107067 Natinst-CAR-ID: 540272
The MMC driver will enable/disable external regulators as part of enabling/disabling the SD Host Controller. The WLAN_PWD_L line (controlled from the CPLD) must be enabled/disabled at the same time that the controller is enabled/disabled. Allow the MMC driver to just control that pin directly via the regulator framework. Signed-off-by: James Minor <james.minor@ni.com>
Add the new Fire Eagle backplane ID so we stop complaining on boot. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Xander Huff <xander.huff@ni.com> Natinst-ReviewBoard-ID: 152156
Fix checkpatch warnings: Block comments use * on subsequent lines Block comments use a trailing */ on a separate line Comparisons should place the constant on the right side of the test break is not useful after a goto or return Signed-off-by: Xander Huff <xander.huff@ni.com> Natinst-ReviewBoard-ID: 157395
This commit assumes that BIOS will implement a change to add a new field to PIEC capability structure. Also bumping the capabilities version by 1. Adding IRQ mechanism for user Push button instead of GPIO This change registers and requests an IRQ for User push button.Adds a new handler pushbutton_interrupt_handler() to handle the interrupt when the button is pressed or released. Adds a new field to struct nirtfeatures_pie_descriptor called notification_method. If this field is 1, it indicates interrupt mechanism. We check this field only for caps version=3 and pie_type=switch. Also bumps the MAX_PIE_CAPS_VERSION to 3. The kernel and BIOS have to be updated at the same time in order for this change to be successful. If kernel is updated first on a controller, user button will simply not function but will have no other side effects. If BIOS is updated first, then system will end in kernel panic and reboot constantly. Signed-off-by: Akash Mankar <akash.mankar@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Zach Hindes <zach.hindes@ni.com> Acked-by: Aaron Rossetto <aaron.rossetto@ni.com> Natinst-ReviewBoard-ID: 174593
On Fire Eagle, the Ironclad ASIC has an internal watchdog which will reset the chip if the its firmware hangs. Unless we're in button- directed safemode, this will also reset the whole system. Add this reset reason to our strings so we can tell when this happens. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: James Minor <james.minor@ni.com> Acked-by: Zach Brown <zach.brown@ni.com> Acked-by: Akash Mankar <akash.mankar@ni.com> Natinst-ReviewBoard-ID: 176049
Adding a new ACPI resource to device BIOS exposed the fact that our error handling on a failed device probe is very broken. To fix this, use managed allocation (devm_*) for all resources which support it. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: James Minor <james.minor@ni.com> Acked-by: Zach Brown <zach.brown@ni.com> Acked-by: Akash Mankar <akash.mankar@ni.com> Natinst-ReviewBoard-ID: 176049
This commit is a merge of two upstream-unfriendly commits: commit ba93f2d ("8250: Make SERIAL_8250_RUNTIME_UARTS work correctly") commit 0d1ed2d ("Revert "serial: 8250: Do nothing if nr_uarts=0"") This was an attempt to resolve an architectural oddity in the 8250 core code, which was that, by design, it will create a static (build- or cmdline-specified) number of ttyS* devices, which is at odds with how most other Linux kernel drivers work. The original commit messages did not accurately describe the problem, so this is a merge-and-replace in order to get a better commit description. So, without further ado: The current state of affairs is as follows: There exists two build-time constants. - CONFIG_SERIAL_8250_NR_UARTS: the build-time max number of 8250 UARTs. - CONFIG_SERIAL_8250_RUNTIME_UARTS: the boot-time number of 8250 UARTs. (confusingly, this is also the default setting of 8250.nr_uarts) The way that the 8250 driver handles creation of ttyS* device is that, at initialize time, we create min(8250.nr_uarts, NR_UARTS) ttyS* devices up-front, and when a UART is registered, serial8250_find_match_or_unused will either merge it in under an existing ttyS* or find an unused one. There also exists code in the 8250 driver to automatically enumerate the UARTs specified in the SERIAL_PORT_DFNS table; these are the "well-known" ports at 0x3F8/0x2F8/0x3E8/0x2E8 from the IBM PC platform, and they are added this way because they predate the use of ACPI tables for enumeration. (Oh, and also you can point the ttyS* devices to completely different addresses from userspace via TIOCSSERIAL.) This has two ramifications for NI devices: 1) There is a limit on number of UARTs with 8250_core; this is a noteworthy problem when you are also a vendor of multiport serial cards, such as the PXIe-8430/16. However, the user experience of increasing the limit with a generic platform kernel is also bad; if, as a distro, we release a kernel with a default limit of 128, then users that have PXI systems that don't have any multiport serial cards will still be presented with devices named ttyS0 through ttyS127, even though most of them are just "empty" slots that are not backed by real devices. 2) ttyS0 through ttyS3 will always be given the addresses for the "legacy" serial ports, even if on-board controller ports are at different addresses. This is the case on several NI controllers; for example, on some sbRIO products [1] the UARTs are at 0x3F8, 0x350, 0x360, etc. However, because the legacy ports get first-dibs, those ports will be ttyS0, ttyS4, ttyS5, ... because the legacy 0x2f8/0x3E8/0x2E8 get S1-S3. Our initial attempt at resolving this was to redefine 8250.nr_uarts to mean "the number of automatically-created UART entries" and define it to be 0 (because we neither want the legacy ports nor the extra "empty" ports). On NI platforms, all serial ports are described in the ACPI table, so legacy enumeration is neither necessary nor desirable. However, this approach got soundly rejected upstream because it "caused existing kernel configurations to act differently from before" [2]. We're not alone in finding the upstream behavior to be counterintuitive; I have found at least two other attempts [3, 4] to resolve it with similar pushback of the form "this breaks existing users". A "proper" upstreamable solution probably needs two parts, with the default settings such that the current behavior is retained but can be opted-out (via Kconfig and/or kernel cmdline). - a config token for "don't create a bunch of empty devices" (1) - a config token for "don't add legacy ports, let ACPI handle it" (2) Until that arrives, we're stuck keeping this around, because we're _also_ stuck with not wanting to renumber ttyS* devices from the way we've shipped them. [1] https://github.com/ni/meta-nilrt/blob/8106f31da6980ee4ee94fa0e03b991479d9aa43e/recipes-kernel/kernel-tests/kernel-tests-files/test_kernel_serial_devices.sh#L127 [2] https://lore.kernel.org/lkml/20130603213754.GA15479@kroah.com/ [3] https://lore.kernel.org/linux-serial/1420513785-23660-1-git-send-email-peter@hurleysoftware.com/ [4] https://lore.kernel.org/linux-serial/20221025073944.102437-1-martin@geanix.com/ [SBOs from initial patches] Natinst-CAR-ID: 634278 Signed-off-by: Karthik Manamcheri <karthik.manamcheri@ni.com> Signed-off-by: Richard Tollerton <rich.tollerton@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Natinst-ReviewBoard-ID: 183619 Upstream-Status: Denied [rejected upstream] Natinst-AzDO-ID: 2133864 Signed-off-by: Brenda Streiff <brenda.streiff@ni.com>
The National Instruments (NI) 16550 is a standard 16550 with larger FIFOs and embedded RS-232/RS-485 transceiver control circuitry. This patch adds a driver that can operate this UART. Originally by: Jaeden Amero <jaeden.amero@ni.com> Originally by: Karthik Manamcheri <karthik.manamcheri@ni.com> Modified extensively to move enumeration and other logic into a self-contained platform_driver instead of being shoved into 8250_pnp. Signed-off-by: Brenda Streiff <brenda.streiff@ni.com> Acked-by: Gratian Crisan <gratian.crisan@ni.com> Acked-by: Jason Smith <jason.smith@ni.com>
Add bindings for the NI 16550 UART. Signed-off-by: Brenda Streiff <brenda.streiff@ni.com> Acked-by: Gratian Crisan <gratian.crisan@ni.com> Acked-by: Jason Smith <jason.smith@ni.com>
When in AP mode, we should force scans to happen from the wext compatibility layer. This won't hurt when in station mode, and only affects the wl12xx driver. This change is to retain parity with NI's shipped 3.2 kernel. It can be dropped when we switch away from using the WEXT interface, and should not be upstreamed. Signed-off-by: James Minor <james.minor@ni.com> Reviewed-by: Ben Shelton <ben.shelton@ni.com> Reviewed-by: Jaeden Amero <jaeden.amero@ni.com> Natinst-ReviewBoard-ID: 92027
This is a hack to get CONFIG_WIRELESS_EXT enabled, since if it is turned on in the defconfig it will not propogate to the .config (as it is not user selectable). Even though the driver does not need it, the current NI user-mode software stacks require this support for scanning and interface enumeration. With this change, it will propogate to the wl12xx driver build (from compat-wireless) and thus include WEXT support in that driver and wireless networking modules. Signed-off-by: Sundar Subbiah <sundar.subbiah@ni.com> Acked-by: James Minor <james.minor@ni.com> Acked-by: Josh Cartwright <josh.cartwright@ni.com> Acked-by: Jeff Westfahl <jeff.westfahl@ni.com> Acked-by: Ken Sharp <ken.sharp@ni.com> Natinst-ReviewBoard-ID: 37925
Use the BIOS DMI tables to select an initial region for regulatory info. The region in BIOS will be set in manufacturing based on where the product is to be used. This is intended to facilitate channel and power level selection based on the product's SKU. Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com> Signed-off-by: James Minor <james.minor@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Natinst-CAR-ID: 578408 Natinst-ReviewBoard-ID: 120508 Natinst-ReviewBoard-ID: 130950 Natinst-Trello-ID: https://trello.com/c/xCpOlFJt [bstreiff: remove elvisiii dts changes as part of zynq removal] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> [gratian: update Kconfig '---help---' to 'help'] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: James Minor <james.minor@ni.com> [gratian: update Kconfig '---help---' to 'help'] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
In addition to setting the region on the device, switch board files based on the selected region from BIOS. This allows different boards to load files with different power levels for regulatory purposes. Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Xander Huff <xander.huff@ni.com> Acked-by: James Minor <james.minor@ni.com> Natinst-CAR-ID: 578408 Natinst-ReviewBoard-ID: 130950
Some firmwares offer the ability to directly set the RSN with WMI_SET_RSN_CAP_CMDID instead of using WMI_SET_IE_CMDID. Add the flags and functions to make that work. Signed-off-by: James Minor <james.minor@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 133028 Natinst-CAR-ID: 577496
Silex uses different command IDs for the commands WMI_SET_APPIE_CMDID and WMI_SET_RSN_CAP_SILEX_CMDID. In case of the Silex firmware, remap them to the correct command ID. Signed-off-by: James Minor <james.minor@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 133028 Natinst-CAR-ID: 577496
Sometimes the devices will fail to boot the first time, but will work fine when retried. Retry the initialization a few times before failing (and reset the hardware properly when it fails). Signed-off-by: James Minor <james.minor@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Natinst-ReviewBoard-ID: 130170 Natinst-CAR-ID: 566029
Sometimes the AR6234 gives us a error "ath6kl: Unable to enable sdio func: -62". This indicates that the enable bit for the function did not result in the function's status bit in the SDIO_CCCR_IORx register getting set within a reasonable period of time (like 400ms). The guess at this point is that the radio is coming up in some strange state and the power-on reset did not clean things up as it should have. This occurs about once every thousand or so reboots. Experimentation has shown that resetting the device after this has happened allows the function enable to correctly set the function's bit in the SDIO_CCCR_IORx. This change will reset the AR6234 and try the function enable again if the module parameter boot_attempts is set to >0. This has been tested over several thousand reboots, and the driver will recover correctly when it would have otherwise failed to initialize. Signed-off-by: James Minor <james.minor@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Acked-by: Xander Huff <xander.huff@ni.com> Natinst-ReviewBoard-ID: 135864 Natinst-CAR-ID: 579000
Linux upstream had accepted the load of different board file using DTS method with board file name format of "bdata.XX.bin". Hence, we need to modify BIOS code to use same board file name format to match with the upstream code. Signed-off-by: Wilson Lee <wilson.lee@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Keng Soon Cheah <keng.soon.cheah@ni.com> Acked-by: Joseph Hershberger <joseph.hershberger@ni.com> Acked-by: Chen Yee Chew <chen.yee.chew@ni.com> Natinst-ReviewBoard-ID: 203623 Perforce-ReviewBoard-ID: 203621
To support the single antenna board files for products with 1 antenna, separate out the selection of the region from the selection of the board file. On OF platforms, there will now be 2 device tree entries: atheros,region-code - The region code (like US) atheros,board-id - The board file code (like 00, 10, etc) In the process, do a small refactor of the CONFIG_ATH6KL_NI_BIOS_DOMAIN case to be more consistent with the device tree case. Signed-off-by: James Minor <james.minor@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Acked-by: Kyle Roeschley <kyle.roeschley@ni.com> Natinst-ReviewBoard-ID: 223288 Natinst-CAR-ID: 686866
This reverts commit 4324f6d. The SD Physical Layer Simplified Specification Version 6.00 §4.2.4.5 says that tuning is only supported for SDR50 and SDR104 modes, not DDR50 mode. As a result, tuning always fails for DDR50 cards. Remove "support" for this in the kernel, as it only adds unnecessary error prints. This was tested with a variety of industrial and consumer microSD cards from Swissbit, Unirex, Patriot, SanDisk, and Link Depot. None of the cards were able to execute tuning in DDR50 mode. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Tony Liechty <tony.liechty@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 236135
This will prevent SD card from doing SD high-speed timing. It will not do SD high-speed timing for high-speed or standard-speed card. Signed-off-by: Chen Yee Chew <chen.yee.chew@ni.com> Reviewed-by: Keng Soon Cheah <keng.soon.cheah@ni.com> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> Natinst-CAR-ID: 519438 Natinst-ReviewBoard-ID: 99036 [bstreiff: convert to device_property_present as per 8199d31 ("mmc: sdhci-pltfm: Convert DT properties to generic device properties")] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com>
The SD spec version 6.0 section 6.4.1.5 requires that Vdd must be lowered to less than 0.5V for a minimum of 1 ms when powering off a card. Increase our wait to 15 ms so that voltage has time to drain down to 0.5V. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: James Minor <james.minor@ni.com> Acked-by: Brandon Streiff <brandon.streiff@ni.com> Natinst-ReviewBoard-ID: 203804
Per the SD Host Controller Simplified Specification v4.20 §3.2.3, change the SD card clock parameters only after first disabling the external card clock. Doing this fixes a spurious clock pulse on Baytrail and Apollo Lake SD controllers which otherwise breaks voltage switching with a specific Swissbit SD card. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Tony Liechty <tony.liechty@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 236135 Natinst-CAR-ID: 694815
Some SD controllers require a delay between clearing SDHCI_CLOCK_CARD_EN and changing the SD clock dividers in order to avoid a runt clock pulse which can otherwise cause problems with some SD cards. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Tony Liechty <tony.liechty@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 236135 [bstreiff: minor fix to renumber flag bit] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> [gratian: renumber flag bit due to commit 43e5c20 ("mmc: sdhci-tegra: Issue CMD and DAT resets together")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
On some SD host controllers, we can see two SD card insert interrupts when inserting a card. This causes mmc_rescan() to be called twice in quick succession and generate one or two SD card clock pulses, which can cause some SD cards to become unresponsive. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Tony Liechty <tony.liechty@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 236135 [gratian: fix conflict with fec7967 ("mmc: sdhci: Factor out sdhci_enable_clk")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> [bstreiff: minor change to renumber flag bit] Signed-off-by: Brandon Streiff <brandon.streiff@ni.com> [gratian: minor change to renumber flag bit] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
With the Baytrail SD controllers on cRIO-905x, we can run into two conditions which cause functional problems with the NI-recommended microSD card. The first is a runt pulse after SD card clock disable, which is fixed by using SDHCI_QUIRK2_NEED_DELAY_AFTER_CLK_DISABLE to wait after disabling the clock. The second is receiving two SDHCI_INT_CARD_INSERT interrupts, which causes us to set up the card twice a make our recommended microSD card unresponsive. Work around this by using SDHCI_QUIRK2_SPURIOUS_CARD_INSERT_INTERRUPT. Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Tony Liechty <tony.liechty@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 236135 Natinst-CAR-ID: 696865 Natinst-CAR-ID: 694815
Per the §2.2.19 of the SD Host Controller Simplified Specification Version 4.20, the Tuning Error interrupt is set when an unrecoverable error is detected by the host controller in the tuning circuit when not executing the tuning procedure. Handle this interrupt by printing a useful error message and re-tuning (also per the spec). Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Tony Liechty <tony.liechty@ni.com> Acked-by: Nathan Sullivan <nathan.sullivan@ni.com> Natinst-ReviewBoard-ID: 236135 Natinst-CAR-ID: 696866 [gratian: adjust includes for 5857b29 ("mmc: core: Move public functions from host.h to private headers")] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Upstream removed spin lock usage in the set_ios path with commit d1e4f74 ("mmc: sdhci: Do not use spin lock in set_ios paths"), which means that our calls to spin_(un)lock_irq() in sdhci_set_clock() now cause an error on boot if a card is not present or a crash if one is present. Remove these calls so we don't do that and to match upstream's change. Fixes: 815777e ("mmc: sdhci: Add quirk for delay between clock disable and param change") Fixes: 30d2f45 ("mmc: sdhci: Add quirk work around double rescan") Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Acked-by: Gratian Crisan <gratian.crisan@ni.com> Acked-by: Brandon Streiff <brandon.streiff@ni.com> Natinst-ReviewBoard-ID: 264712 Natinst-CAR-ID: 720310
[gratian: squash all defconfig commits accumulated up to 6.0.19-rt14 and regenerate for 6.1.12-rt7] Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Contributor
|
Pushed as |
gratian
pushed a commit
to gratian/linux
that referenced
this pull request
Feb 28, 2024
[ Upstream commit b16904f ] With latest upstream llvm18, the following test cases failed: $ ./test_progs -j ni#13/2 bpf_cookie/multi_kprobe_link_api:FAIL ni#13/3 bpf_cookie/multi_kprobe_attach_api:FAIL ni#13 bpf_cookie:FAIL ni#77 fentry_fexit:FAIL ni#78/1 fentry_test/fentry:FAIL ni#78 fentry_test:FAIL ni#82/1 fexit_test/fexit:FAIL ni#82 fexit_test:FAIL ni#112/1 kprobe_multi_test/skel_api:FAIL ni#112/2 kprobe_multi_test/link_api_addrs:FAIL [...] ni#112 kprobe_multi_test:FAIL #356/17 test_global_funcs/global_func17:FAIL #356 test_global_funcs:FAIL Further analysis shows llvm upstream patch [1] is responsible for the above failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c, without [1], the asm code is: 0000000000000400 <bpf_fentry_test7>: 400: f3 0f 1e fa endbr64 404: e8 00 00 00 00 callq 0x409 <bpf_fentry_test7+0x9> 409: 48 89 f8 movq %rdi, %rax 40c: c3 retq 40d: 0f 1f 00 nopl (%rax) ... and with [1], the asm code is: 0000000000005d20 <bpf_fentry_test7.specialized.1>: 5d20: e8 00 00 00 00 callq 0x5d25 <bpf_fentry_test7.specialized.1+0x5> 5d25: c3 retq ... and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7> and this caused test failures for ni#13/ni#77 etc. except #356. For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog looks like: 0000000000000000 <global_func17>: 0: b4 00 00 00 2a 00 00 00 w0 = 0x2a 1: 95 00 00 00 00 00 00 00 exit ... which passed verification while the test itself expects a verification failure. Let us add 'barrier_var' style asm code in both places to prevent function specialization which caused selftests failure. [1] llvm/llvm-project#72903 Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231127050342.1945270-1-yonghong.song@linux.dev Signed-off-by: Sasha Levin <sashal@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a rebase of our commits from nilrt/master/6.0 to the latest stable-rt/v6.1-rt branch (currently at version v6.1.12-rt7).
Clean-up before rebase:
drop all commits that were reverted in 6.0:
reorder commits that logically belong together
squashed accumulated defconfig changes:
Verified that the clean-up did not accidentally dropped or introduced any changes via
git diff origin/nilrt/master/6.0which resulted in an empty diff.Dropped old NI serial patches in favor of new driver introduced by PR #100:
Rebased on top of stable-rt/v6.1-rt branch and fixed the following conflicts in-place:
Testing:
.configagainst 6.0 version; no unexplained or unusual config changes noticed.Procedural notes:
linux-stabletree 6.1 branch has additional changes that are not yet present inlinux-stable-rt. We will handle that upgrade as a separate PR after this rebase is complete.