Pull char/misc driver updates from Greg KH:
"Here is the large set of char/misc and other driver subsystem changes
for 6.2-rc1. Nothing earth-shattering in here at all, just a lot of
new driver development and minor fixes.
Highlights include:
- fastrpc driver updates
- iio new drivers and updates
- habanalabs driver updates for new hardware and features
- slimbus driver updates
- speakup module parameters added to aid in boot time configuration
- i2c probe_new conversions for lots of different drivers
- other small driver fixes and additions
One semi-interesting change in here is the increase of the number of
misc dynamic minors available to 1048448 to handle new huge-cpu
systems.
All of these have been in linux-next for a while with no reported
problems"
* tag 'char-misc-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (521 commits)
extcon: usbc-tusb320: Convert to i2c's .probe_new()
extcon: rt8973: Convert to i2c's .probe_new()
extcon: fsa9480: Convert to i2c's .probe_new()
extcon: max77843: Replace irqchip mask_invert with unmask_base
chardev: fix error handling in cdev_device_add()
mcb: mcb-parse: fix error handing in chameleon_parse_gdd()
drivers: mcb: fix resource leak in mcb_probe()
coresight: etm4x: fix repeated words in comments
coresight: cti: Fix null pointer error on CTI init before ETM
coresight: trbe: remove cpuhp instance node before remove cpuhp state
counter: stm32-lptimer-cnt: fix the check on arr and cmp registers update
misc: fastrpc: Add dma_mask to fastrpc_channel_ctx
misc: fastrpc: Add mmap request assigning for static PD pool
misc: fastrpc: Safekeep mmaps on interrupted invoke
misc: fastrpc: Add support for audiopd
misc: fastrpc: Rework fastrpc_req_munmap
misc: fastrpc: Use fastrpc_map_put in fastrpc_map_create on fail
misc: fastrpc: Add fastrpc_remote_heap_alloc
misc: fastrpc: Add reserved mem support
misc: fastrpc: Rename audio protection domain to root
...
These cases were done with this Coccinelle:
@@
expression H;
expression L;
@@
- (get_random_u32_below(H) + L)
+ get_random_u32_inclusive(L, H + L - 1)
@@
expression H;
expression L;
expression E;
@@
get_random_u32_inclusive(L,
H
- + E
- - E
)
@@
expression H;
expression L;
expression E;
@@
get_random_u32_inclusive(L,
H
- - E
- + E
)
@@
expression H;
expression L;
expression E;
expression F;
@@
get_random_u32_inclusive(L,
H
- - E
+ F
- + E
)
@@
expression H;
expression L;
expression E;
expression F;
@@
get_random_u32_inclusive(L,
H
- + E
+ F
- - E
)
And then subsequently cleaned up by hand, with several automatic cases
rejected if it didn't make sense contextually.
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> # for infiniband
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The Foxconn T99W175 modem has an HP variant, which has
the following output from lspci:
01:00.0 Wireless controller [0d40]: Device 03f0:0a6c
It also has some HP-specific serial numbers on the
metal case. It works well with this driver, so add
support for this to the pci_generic driver.
Signed-off-by: Song Fuchang <song.fc@gmail.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
[mani: manually applied the patch]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
There is a race condition where mhi_prepare_channel() updates the
read and write pointers as the base address and in parallel, if
an M0 transition occurs, the tasklet goes ahead and rings
doorbells for all channels with a delta in TRE rings assuming
they are already enabled. This causes a null pointer access. Fix
it by adding a channel enabled check before ringing channel
doorbells.
Cc: stable@vger.kernel.org # 5.19
Fixes: a6e2e3522f "bus: mhi: core: Add support for PM state transitions"
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/1665889532-13634-1-git-send-email-quic_qianyu@quicinc.com
[mani: CCed stable list]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Pull char/misc and other driver updates from Greg KH:
"Here is the large set of char/misc and other small driver subsystem
changes for 6.1-rc1. Loads of different things in here:
- IIO driver updates, additions, and changes. Probably the largest
part of the diffstat
- habanalabs driver update with support for new hardware and
features, the second largest part of the diff.
- fpga subsystem driver updates and additions
- mhi subsystem updates
- Coresight driver updates
- gnss subsystem updates
- extcon driver updates
- icc subsystem updates
- fsi subsystem updates
- nvmem subsystem and driver updates
- misc driver updates
- speakup driver additions for new features
- lots of tiny driver updates and cleanups
All of these have been in the linux-next tree for a while with no
reported issues"
* tag 'char-misc-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (411 commits)
w1: Split memcpy() of struct cn_msg flexible array
spmi: pmic-arb: increase SPMI transaction timeout delay
spmi: pmic-arb: block access for invalid PMIC arbiter v5 SPMI writes
spmi: pmic-arb: correct duplicate APID to PPID mapping logic
spmi: pmic-arb: add support to dispatch interrupt based on IRQ status
spmi: pmic-arb: check apid against limits before calling irq handler
spmi: pmic-arb: do not ack and clear peripheral interrupts in cleanup_irq
spmi: pmic-arb: handle spurious interrupt
spmi: pmic-arb: add a print in cleanup_irq
drivers: spmi: Directly use ida_alloc()/free()
MAINTAINERS: add TI ECAP driver info
counter: ti-ecap-capture: capture driver support for ECAP
Documentation: ABI: sysfs-bus-counter: add frequency & num_overflows items
dt-bindings: counter: add ti,am62-ecap-capture.yaml
counter: Introduce the COUNTER_COMP_ARRAY component type
counter: Consolidate Counter extension sysfs attribute creation
counter: Introduce the Count capture component
counter: 104-quad-8: Add Signal polarity component
counter: Introduce the Signal polarity component
counter: interrupt-cnt: Implement watch_validate callback
...
Manivannan writes:
"MHI Host
--------
- Print the modem name while probing the MHI host pci-generic driver. This has
been exposed as a debug information so far but on a low storate embedded
devices such as OpenWRT based products, this helps in identifying the
attached modem without enabling the debug logs."
* tag 'mhi-for-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi:
bus: mhi: host: always print detected modem name
This harmless print provides a very easy way of knowing
if the modem is detected properly during probing.
Promote it to an informational print so no hassle is required
enabling kernel debugging info to obtain it.
The rationale here is that:
On a lot of low-storage embedded devices, extensive kernel
debugging info is not always present as this would
increase it's size to much causing partition size issues.
Signed-off-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
Link: https://lore.kernel.org/r/20220831100349.1488762-1-koen.vandeputte@citymesh.com
[mani: added missing review tags]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
During runtime, the MHI endpoint may be powered up/down several times.
So instead of allocating and destroying the IRQs all the time, let's just
enable/disable IRQs during power up/down.
The IRQs will be allocated during mhi_register_controller() and freed
during mhi_unregister_controller(). This works well for things like PCI
hotplug also as once the PCI device gets removed, the controller will
get unregistered. And once it comes back, it will get registered back
and even if the IRQ configuration changes (MSI), that will get accounted.
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/1655952183-66792-1-git-send-email-quic_qianyu@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Manivannan writes:
MHI changes for v5.19
MHI Host
--------
Support for new modems:
- Foxconn Cinterion MV32-WA/MV32-WB based on SDX62/SDX65
- Telit FN980 v1 based on SDX55
- Telit FN990 based on SDX65
- Foxconn T99W373/T99W368 based on SDX62/SDX65
Core changes:
- During the recycle of event ring elements, compute the ctxt_wp based on the
local cached value instead of reading from shared memory. This is to prevent
the possible corruption of the ctxt_wp as some of the endpoint devices could
modify the value in shared memory.
- Add sysfs support for resetting the endpoint based on the MHI spec. The MHI
spec allows the host to hard reset the device in the case of an unrecoverable
error and all other reset mechanisms have failed.
- During MHI shutdown, wait for the endpoint device to enter the ready state
post reset before proceeding. This is to avoid a possible race where host
would remove the interrupt handler and device will send ready state
interrupt, resulting in IOMMU fault.
- Bail out updating the MHI register if the read has failed during
read/modify/write.
- Use mhi_write_reg() instead of mhi_write_reg_field() for writing the whole
register fields in mhi_init_mmio().
MAINTAINERS change:
- Since Qualcomm has moved the email domain for its employess from codeaurora
domain to quicinc, update the same for Hemant.
* tag 'mhi-for-v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi: (29 commits)
bus: mhi: host: Add support for Foxconn T99W373 and T99W368
bus: mhi: host: pci_generic: add Telit FN990
bus: mhi: host: pci_generic: add Telit FN980 v1 hardware revision
bus: mhi: host: Add support for Cinterion MV32-WA/MV32-WB
bus: mhi: host: Optimize and update MMIO register write method
bus: mhi: host: Bail on writing register fields if read fails
bus: mhi: host: Wait for ready state after reset
bus: mhi: host: Add soc_reset sysfs
bus: mhi: host: pci_generic: Sort mhi_pci_id_table based on the PID
bus: mhi: host: Use cached values for calculating the shared write pointer
MAINTAINERS: Update Hemant's email id
bus: mhi: ep: Add uevent support for module autoloading
bus: mhi: ep: Add support for suspending and resuming channels
bus: mhi: ep: Add support for queueing SKBs to the host
bus: mhi: ep: Add support for processing channel rings
bus: mhi: ep: Add support for reading from the host
bus: mhi: ep: Add support for processing command rings
bus: mhi: ep: Add support for handling SYS_ERR condition
bus: mhi: ep: Add support for handling MHI_RESET
bus: mhi: ep: Add support for powering down the MHI endpoint stack
...
After the device has signaled the end of reset by clearing the reset bit,
it will automatically reinit MHI and the internal device structures. Once
That is done, the device will signal it has entered the ready state.
Signaling the ready state involves sending an interrupt (MSI) to the host
which might cause IOMMU faults if it occurs at the wrong time.
If the controller is being powered down, and possibly removed, then the
reset flow would only wait for the end of reset. At which point, the host
and device would start a race. The host may complete its reset work, and
remove the interrupt handler, which would cause the interrupt to be
disabled in the IOMMU. If that occurs before the device signals the ready
state, then the IOMMU will fault since it blocked an interrupt. While
harmless, the fault would appear like a serious issue has occurred so let's
silence it by making sure the device hits the ready state before the host
completes its reset processing.
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Hemant Kumar <quic_hemantk@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1650302562-30964-1-git-send-email-quic_jhugo@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The MHI bus supports a standardized hardware reset, which is known as the
"SoC Reset". This reset is similar to the reset sysfs for PCI devices -
a hardware mechanism to reset the state back to square one.
The MHI SoC Reset is described in the spec as a reset of last resort. If
some unrecoverable error has occurred where other resets have failed, SoC
Reset is the "big hammer" that ungracefully resets the device. This is
effectivly the same as yanking the power on the device, and reapplying it.
However, depending on the nature of the particular issue, the underlying
transport link may remain active and configured. If the link remains up,
the device will flag a MHI system error early in the boot process after
the reset is executed, which allows the MHI bus to process a fatal error
event, and clean up appropiately.
While the SoC Reset is generally intended as a means of recovery when all
else has failed, it can be useful in non-error scenarios. For example,
if the device loads firmware from the host filesystem, the device may need
to be fully rebooted inorder to pick up the new firmware. In this
scenario, the system administrator may use the soc_reset sysfs to cause
the device to pick up the new firmware that the admin placed on the
filesystem.
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Bhaumik Bhatt <quic_bbhatt@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1650302327-30439-1-git-send-email-quic_jhugo@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
mhi_recycle_ev_ring() computes the shared write pointer for the ring
(ctxt_wp) using a read/modify/write pattern where the ctxt_wp value in the
shared memory is read, incremented, and written back. There are no checks
on the read value, it is assumed that it is kept in sync with the locally
cached value. Per the MHI spec, this is correct. The device should only
read ctxt_wp, never write it.
However, there are devices in the wild that violate the spec, and can
update the ctxt_wp in a specific scenario. This can cause corruption, and
violate the above assumption that the ctxt_wp is in sync with the cached
value.
This can occur when the device has loaded firmware from the host, and is
transitioning from the SBL EE to the AMSS EE. As part of shutting down
SBL, the SBL flushes it's local MHI context to the shared memory since
the local context will not persist across an EE change. In the case of
the event ring, SBL will flush its entire context, not just the parts that
it is allowed to update. This means SBL will write to ctxt_wp, and
possibly corrupt it.
An example:
Host Device
---- ---
Update ctxt_wp to 0x1f0
SBL observes 0x1f0
Update ctxt_wp to 0x0
Starts transition to AMSS EE
Context flush, writes 0x1f0 to ctxt_wp
Update ctxt_wp to 0x200
Update ctxt_wp to 0x210
AMSS observes 0x210
0x210 exceeds ring size
AMSS signals syserr
The reason the ctxt_wp goes off the end of the ring is that the rollover
check is only performed on the cached wp, which is out of sync with
ctxt_wp.
Since the host is the authority of the value of ctxt_wp per the MHI spec,
we can fix this issue by not reading ctxt_wp from the shared memory, and
instead compute it based on the cached value. If SBL corrupts ctxt_wp,
the host won't observe it, and will correct the value at some point later.
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Hemant Kumar <quic_hemantk@quicinc.com>
Reviewed-by: Bhaumik Bhatt <quic_bbhatt@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1649868113-18826-1-git-send-email-quic_jhugo@quicinc.com
[mani: used the quicinc domain for Hemant and Bhaumik]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
During hibernation process, once thaw() stage completes, the MHI endpoint
devices will be in M0 state post recovery. After that, the devices will be
powered down so that the system can enter the target sleep state. During
this stage, the PCI core will put the devices in D3hot. But this transition
is allowed by the MHI spec. The devices can only enter D3hot when it is in
M3 state.
So for fixing this issue, let's add the poweroff() callback that will get
executed before putting the system in target sleep state during
hibernation. This callback will power down the device properly so that it
could be restored during restore() or thaw() stage.
Cc: stable@vger.kernel.org
Fixes: 5f0c2ee1fe ("bus: mhi: pci-generic: Fix hibernation")
Reported-by: Hemant Kumar <quic_hemantk@quicinc.com>
Suggested-by: Hemant Kumar <quic_hemantk@quicinc.com>
Link: https://lore.kernel.org/r/20220405125907.5644-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Functions like mhi_read_reg_field(), mhi_poll_reg_field() and
mhi_write_reg_field() could be modified to not depend on the shift value
passed as an argument. Instead, the bitfield operation could be used to
extract the shift value from the mask itself.
This eliminates the need to define _SHIFT (and _SHFT) macros and
simplifies the code a bit. For shift values those cannot be determined
during build time, "__ffs()" helper is used find the shift value during
runtime.
While at it, let's also get rid of 32-bit masks like CHDBOFF_CHDBOFF_MASK
by doing the full 32-bit register read.
Suggested-by: Alex Elder <elder@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220301160308.107452-6-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
