FSI_SBEFIFO_READ_TIMEOUT_SECONDS ioctl sets the read timeout (in
seconds) for the response received by sbefifo device from sbe. The
timeout affects only the read operation on current sbefifo device fd.
Certain SBE operations can take long time to complete and the default
timeout of 10 seconds might not be sufficient to start receiving
response from SBE. In such cases, allow the timeout to be set to the
maximum of 120 seconds.
The kernel does not contain the definition of the various SBE
operations, so we must expose an interface to userspace to set the
timeout for the given operation.
Signed-off-by: Amitay Isaacs <amitay@ozlabs.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20220121053816.82253-3-joel@jms.id.au
Signed-off-by: Joel Stanley <joel@jms.id.au>
For some of the chip-ops where sbe needs to collect trace information,
sbe can take a long time (>30s) to respond. Currently these chip-ops
will timeout as the start of response timeout defaults to 10s.
Instead of default value, use specified value. The require timeout
value will be set using ioctl.
Signed-off-by: Amitay Isaacs <amitay@ozlabs.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20220121053816.82253-2-joel@jms.id.au
Signed-off-by: Joel Stanley <joel@jms.id.au>
If the driver sequence number coincidentally equals the previous
command response sequence number, the driver may proceed with
fetching the entire buffer before the OCC has processed the current
command. To be sure the correct response is obtained, check the
command type and also retry if any of the response parameters have
changed when the rest of the buffer is fetched. Also initialize the
driver with a random sequence number in order to reduce the chances
of this happening.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20220208152235.19686-1-eajames@linux.ibm.com
Signed-off-by: Joel Stanley <joel@jms.id.au>
Remove the second 'info'.
Replacements
'adventages' with 'advantages'
'strenth' with 'strength'
'atleast' with 'at least'
'thr'u'' with 'through'
'capabilty' with 'capability'
'controll' with 'control'
'ourself' with 'ourselves'
'noone' with 'no one'
'cores' to 'core's' and 'core'
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220213213121.2806376-1-trix@redhat.com
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.
Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.
@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}
@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, &E)
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)
@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(&mode, &E)
|
- memcpy(&mode, E, S)
+ drm_mode_copy(&mode, E)
)
@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode
Cc: Emma Anholt <emma@anholt.net>
Cc: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-18-ville.syrjala@linux.intel.com
Enable Wi-Fi/BT mailbox 0x45 handshake and Wi-Fi MIMO power save
mechanism for Bluetooth gaming controller.
BTCOEX Version: 22020720-2020
Desired_BT_Coex_Ver: 0x20
Desired_WL_FW_Ver: 9.9.11
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220215004855.4098-7-pkshih@realtek.com
In order to recognize the gaming controller HID, make a C2H/H2C/Mailbox
handshake to collect all the connected information from BT.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220215004855.4098-6-pkshih@realtek.com
To keep high sensitivity reaction, Bluetooth gaming controller will send
packet very frequently, it will make WLAN performance very poor. To solve
this situation, MIMO PS mechanism makes WLAN/BT own an antenna itself, WLAN
quits 2SS performance but it can get a stable 1SS performance and Bluetooth
gaming controller can keep sensitivity reaction at the same time.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220215004855.4098-5-pkshih@realtek.com
If BT PTA counter can not update regularly, it will lead coex mechanism
run into some unexpected state.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220215004855.4098-4-pkshih@realtek.com
Disable power save TDMA mechanism under HFP COEX, so WLAN can TX/RX full
time.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220215004855.4098-3-pkshih@realtek.com
In some case, wifi chip need to be configed to be TX/RX 1ss mode.
For this mode, wifi components, such as MAC/BB/RF, need to be
specially set, and driver need to send SMPS action frame to inform AP.
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220215004855.4098-2-pkshih@realtek.com
The OSMC Vero 4K+ device is based on the Amlogic S905D (P230)
reference design with the following specifications:
- 2GB DDR4 RAM
- 16GB eMMC
- HDMI 2.1 video
- S/PDIF optical output
- AV output
- 10/100/1000 Ethernet
- AP6255 Wireless (802.11 a/b/g/n/ac, BT 4.2)
- 2x USB 2.0 ports (1x OTG)
- IR receiver (internal)
- IR extender port (external)
- 1x micro SD card slot
- 1x Power LED (red)
- 1x Reset button (in AV jack)
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Chad Wagner <wagnerch42@gmail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20220211105311.30320-4-christianshewitt@gmail.com
Open Source Media Centre (Sam Nazarko Trading Ltd.) are a manufacturer
of Linux Set-Top Box devices.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20220211105311.30320-2-christianshewitt@gmail.com
Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug.
The root case is in missing validation check of actual number of endpoints.
Code should not blindly access usb_host_interface::endpoint array, since
it may contain less endpoints than code expects.
Fix it by adding missing validaion check and print an error if
number of endpoints do not match expected number
Fixes: c49c336378 ("HID: support for initialization of some Thrustmaster wheels")
Reported-and-tested-by: syzbot+35eebd505e97d315d01c@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
witherspoon hardware and p9 chips have very sensitive requirements for
the cfam-reset. We're seeing power faults with the kernel based cfam
reset due to this.
Could adapt the power application to use the new kernel based cfam reset
interface but there's not a lot to be gained there since the power
application is going away with p10 and this limitation is not present in
p10.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Link: https://lore.kernel.org/r/20210308225419.46530-17-eajames@linux.ibm.com
Signed-off-by: Joel Stanley <joel@jms.id.au>
The imx_pgc_power_down() starts by enabling the domain clocks, and thus
disables them in the error path. Commit 18c98573a4 ("soc: imx: gpcv2:
add domain option to keep domain clocks enabled") made the clock enable
conditional, but forgot to add the same condition to the error path.
This can result in a clock enable/disable imbalance. Fix it.
Fixes: 18c98573a4 ("soc: imx: gpcv2: add domain option to keep domain clocks enabled")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Tejas reported the following recursive locking issue:
swapper/0/1 is trying to acquire lock:
ffff8881074fd0a0 (&md->mutex){+.+.}-{3:3}, at: msi_get_virq+0x30/0xc0
but task is already holding lock:
ffff8881017cd6a0 (&md->mutex){+.+.}-{3:3}, at: __pci_enable_msi_range+0xf2/0x290
stack backtrace:
__mutex_lock+0x9d/0x920
msi_get_virq+0x30/0xc0
pci_irq_vector+0x26/0x30
vmd_msi_init+0xcc/0x210
msi_domain_alloc+0xbf/0x150
msi_domain_alloc_irqs_descs_locked+0x3e/0xb0
__pci_enable_msi_range+0x155/0x290
pci_alloc_irq_vectors_affinity+0xba/0x100
pcie_port_device_register+0x307/0x550
pcie_portdrv_probe+0x3c/0xd0
pci_device_probe+0x95/0x110
This is caused by the VMD MSI code which does a lookup of the Linux
interrupt number for an VMD managed MSI[X] vector. The lookup function
tries to acquire the already held mutex.
Avoid that by caching the Linux interrupt number at initialization time
instead of looking it up over and over.
Fixes: 82ff8e6b78 ("PCI/MSI: Use msi_get_virq() in pci_get_vector()")
Reported-by: "Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: "Surendrakumar Upadhyay, TejaskumarX" <tejaskumarx.surendrakumar.upadhyay@intel.com>
Cc: linux-pci@vger.kernel.org
Link: https://lore.kernel.org/r/87a6euub2a.ffs@tglx
The nid is only used to act as output parameter of __next_mem_range.
Since NULL can be passed to __next_mem_range as out_nid, we can thus
remove nid by passing NULL here.
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
[rppt: updated the commit message]
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Add checks for removing a region from reserved memory in different
scenarios:
- The requested region matches one in the collection of reserved
memory regions
- The requested region does not exist in memblock.reserved
- The region overlaps with one of the entries: from the top (its
end address is bigger than the base of the existing region) or
from the bottom (its base address is smaller than the end address
of one of the regions)
- The region is within an already defined region
Signed-off-by: Karolina Drobnik <karolinadrobnik@gmail.com>
Signed-off-by: Mike Rapoport <rppt@kernel.org>
Link: https://lore.kernel.org/r/30af95c82754ad8029404c3b528a5ef1c05d1ed6.1643796665.git.karolinadrobnik@gmail.com
Add checks for removing a region from available memory in different
scenarios:
- The requested region matches one in the collection of available
memory regions
- The requested region does not exist in memblock.memory
- The region overlaps with one of the entries: from the top (its end
address is bigger than the base of the existing region) or from the
bottom (its base address is smaller than the end address of one of
the regions)
- The region is within an already defined region
Signed-off-by: Karolina Drobnik <karolinadrobnik@gmail.com>
Signed-off-by: Mike Rapoport <rppt@kernel.org>
Link: https://lore.kernel.org/r/8e6aa005407bbe1a75b75e85ac04ebb51318a52a.1643796665.git.karolinadrobnik@gmail.com
Add checks for marking a region as reserved in different scenarios:
- The region does not overlap with existing entries
- The region overlaps with one of the previous entries: from the top
(its end address is bigger than the base of the existing region) or
from the bottom (its base address is smaller than the end address of
one of the regions)
- The region is within an already defined region
- The same region is marked as reserved twice
Signed-off-by: Karolina Drobnik <karolinadrobnik@gmail.com>
Signed-off-by: Mike Rapoport <rppt@kernel.org>
Link: https://lore.kernel.org/r/cac867d2b6c17e53d9e977b5d6cd88cc4e9453b6.1643796665.git.karolinadrobnik@gmail.com
Add checks for adding a new region in different scenarios:
- The region does not overlap with existing entries
- The region overlaps with one of the previous entries: from the top
(its end address is bigger than the base of the existing region) or
from the bottom (its base address is smaller than the end address of
one of the regions)
- The region is within an already defined region
- The same region is added twice to the collection of available memory
regions
Add checks for memblock initialization to verify it sets memblock data
structures to expected values.
Signed-off-by: Karolina Drobnik <karolinadrobnik@gmail.com>
Signed-off-by: Mike Rapoport <rppt@kernel.org>
Link: https://lore.kernel.org/r/b6c26525025bccec0bf7419473d4d1293eb82b3b.1643796665.git.karolinadrobnik@gmail.com
Set the usdhc root clock to 400MHz to be able to support
HS400/HS400ES modes for eMMC on phyCORE-i.MX8MP SoM.
Signed-off-by: Jonas Kuenstler <j.kuenstler@phytec.de>
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
LDO4 is not connected so disable it. And LDO5 is used for VSEL of
the NVCC_SD2 SD-Card bus. Having it disabled seems not to have an
impact on the functionality. We enable it, as it is used.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
To be able to trigger a reset also from an external source we
need to configure the WDOG pin as open drain.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Reduce drive strength on fec tx lines for signal quality improvements.
Measurements showed that TD0 and TD1 require X4 and the other lines
X2 for optimized settings.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Set eMMC drive strength for USDHC3_DATA lines (200Mhz)
to X4 for signal improvement.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
To fit spec requirements set minimum output impedance for dp83867
ethernet phy.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add support for the RaspberryPi Camera v2 which is an IMX219 8MP module:
- https://datasheets.raspberrypi.com/camera/camera-v2-schematics.pdf
- has its own on-board 24MHz osc so no clock required from baseboard
- pin 11 enables 1.8V and 2.8V LDO which is connected to
GW73xx MIPI_GPIO4 (IMX8MM GPIO1_IO1) so we use this as a gpio
Support is added via a device-tree overlay.
The IMX219 supports RAW8/RAW10 image formats.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add support for the RaspberryPi Camera v2 which is an IMX219 8MP module:
- https://datasheets.raspberrypi.com/camera/camera-v2-schematics.pdf
- has its own on-board 24MHz osc so no clock required from baseboard
- pin 11 enables 1.8V and 2.8V LDO which is connected to
GW73xx MIPI_GPIO4 (IMX8MM GPIO1_IO1) so we use this as a gpio
controlled regulator enable.
Support is added via a device-tree overlay.
The IMX219 supports RAW8/RAW10 image formats.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The imx8mm-venice-gw72xx-0x som+baseboard combination has a multi-protocol
RS-232/RS-485/RS-422 transceiver to an off-board connector which
can be configured in a number of ways via UART and GPIO configuration.
The default configuration per the imx8mm-venice-gw72xx-0x dts is for
UART2 TX/RX and UART4 TX/RX to be available as RS-232:
J15.1 UART2 TX out
J15.2 UART2 RX in
J15.3 UART4 TX out
J15.4 UART4 RX in
J15.5 GND
Add dt overlays to allow additional the modes of operation:
rs232-rts (UART2 RS-232 with RTS/CTS hardware flow control)
J15.1 TX out
J15.2 RX in
J15.3 RTS out
J15.4 CTS in
J15.5 GND
rs485 (UART2 RS-485 half duplex)
J15.1 TXRX-
J15.2 N/C
J15.3 TXRX+
J15.4 N/C
J15.5 GND
rs422 (UART2 RS-422 full duplex)
J15.1 TX-
J15.2 RX+
J15.3 TX+
J15.4 RX-
J15.5 GND
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The imx8mm-venice-gw73xx-0x som+baseboard combination has a multi-protocol
RS-232/RS-485/RS-422 transceiver to an off-board connector which
can be configured in a number of ways via UART and GPIO configuration.
The default configuration per the imx8mm-venice-gw73xx-0x dts is for
UART2 TX/RX and UART4 TX/RX to be available as RS-232:
J15.1 UART2 TX out
J15.2 UART2 RX in
J15.3 UART4 TX out
J15.4 UART4 RX in
J15.5 GND
Add dt overlays to allow additional the modes of operation:
rs232-rts (UART2 RS-232 with RTS/CTS hardware flow control)
J15.1 TX out
J15.2 RX in
J15.3 RTS out
J15.4 CTS in
J15.5 GND
rs485 (UART2 RS-485 half duplex)
J15.1 TXRX-
J15.2 N/C
J15.3 TXRX+
J15.4 N/C
J15.5 GND
rs422 (UART2 RS-422 full duplex)
J15.1 TX-
J15.2 RX+
J15.3 TX+
J15.4 RX-
J15.5 GND
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The GW7903 is based on the i.MX 8M Mini SoC featuring:
- LPDDR4 DRAM
- eMMC FLASH
- microSD connector with UHS support
- LIS2DE12 3-axis accelerometer
- Gateworks System Controller
- IMX8M FEC
- software selectable RS232/RS485/RS422 serial transceiver
- PMIC
- 2x off-board bi-directional opto-isolated digital I/O
- 1x M.2 A-E Key Socket and 1x MiniPCIe socket with USB2.0 and PCIe
(resistor loading to route PCIe/USB2 between M.2 and MiniPCIe socket)
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The GW7903 is based on the i.MX 8M Mini SoC featuring:
- LPDDR4 DRAM
- eMMC FLASH
- microSD connector with UHS support
- LIS2DE12 3-axis accelerometer
- Gateworks System Controller
- IMX8M FEC
- software selectable RS232/RS485/RS422 serial transceiver
- PMIC
- 2x off-board bi-directional opto-isolated digital I/O
- 1x M.2 A-E Key Socket and 1x MiniPCIe socket with USB2.0 and PCIe
(resistor loading to route PCIe/USB2 between M.2 and MiniPCIe socket)
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Layerscape SoCs contain a Security Fuse Processor which is basically a
efuse controller. Add the node, so userspace can read the efuses.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add support for i2c5, which is used to access the
external I2C bus on connector J22 of the imx8mp-evk.
Limit the speed to 100kHz since this is an external I2C bus.
Disabled by default, since it is shared with the CAN1 bus.
To enable i2c5, you need to disable the CAN1 function, enable the i2c5
function and also configure the CAN1/I2C5_SEL GPIO to HIGH to
select i2c5 instead of CAN1. This can be done by defining a gpio-hog
inside the pca6416 node, in your board device tree, like in this example:
&flexcan1 {
status = "disabled";
};
&i2c5 {
status = "okay";
};
&pca6416 {
can1-i2c5-sel-hog {
gpio-hog;
gpios = <2 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "can1-i2c5-sel";
};
};
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add gpio-line-names for the various GPIO's connected to the PCA6416
I/O expander on the imx8mp EVK.
This helps when using the new gpiod interface to find the GPIOs by name.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
