add vendor hooks to support link data path feature.
1.android_vh_dc_send_copy
For send copy pkt on the other ways
2.android_vh_dc_receive
For Drop duplicated pkt when dual connection connected
Bug: 343838581
Change-Id: I31acba1827205c366a4f54c4b940d4d8f2c21bff
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
(cherry picked from commit 86dd89554f8308fcd58af6156fd67ac2ac7facbf)
This adds:
geni_se_rx_init_dma
geni_se_tx_init_dma
to the symbol list for db845c as it uses the spi-geni drivers,
and recent changes would break building modules for db845c
without the new exported symbols.
Bug: 370629635
Change-Id: I3325c7f4f4de5de736d7bb6f89c1a9c797a0f744
Signed-off-by: John Stultz <jstultz@google.com>
The spi geni driver in SE DMA mode, unlike GSI DMA, is not making use of
DMA mapping functionality available in the framework.
The driver does mapping internally which makes dma buffer fields available
in spi_transfer struct superfluous while requiring additional members in
spi_geni_master struct.
Conform to the design by having framework handle map/unmap and do only
DMA transfer in the driver; this also simplifies code a bit.
Fixes: e5f0dfa78a ("spi: spi-geni-qcom: Add support for SE DMA mode")
Suggested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/1684325894-30252-3-git-send-email-quic_vnivarth@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 370629635
Change-Id: I4140cf94b0efe0cdebe3d998915a19e2e3d7e172
(cherry picked from commit 3a76c7ca9e)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
This reverts commit 5c7e105cd1.
As identified by KASAN, the simplification done by the cleanup patch
was not legal.
>From tracing through the code, it can be seen that we're transmitting
from a 4096-byte circular buffer. We copy anywhere from 1-4 bytes from
it each time. The simplification runs into trouble when we get near
the end of the circular buffer. For instance, we might start out with
xmit->tail = 4094 and we want to transfer 4 bytes. With the code
before simplification this was no problem. We'd read buf[4094],
buf[4095], buf[0], and buf[1]. With the new code we'll do a
memcpy(&buf[4094], 4) which reads 2 bytes past the end of the buffer
and then skips transmitting what's at buf[0] and buf[1].
KASAN isn't 100% consistent at reporting this for me, but to be extra
confident in the analysis, I added traces of the tail and tx_bytes and
then wrote a test program:
while true; do
echo -n "abcdefghijklmnopqrstuvwxyz0" > /dev/ttyMSM0
sleep .1
done
I watched the traces over SSH and saw:
qcom_geni_serial_send_chunk_fifo: 4093 4
qcom_geni_serial_send_chunk_fifo: 1 3
Which indicated that one byte should be missing. Sure enough the
output that should have been:
abcdefghijklmnopqrstuvwxyz0
In one case was actually missing a byte:
abcdefghijklmnopqrstuvwyz0
Running "ls -al" on large directories also made the missing bytes
obvious since columns didn't line up.
While the original code may not be the most elegant, we only talking
about copying up to 4 bytes here. Let's just go back to the code that
worked.
Fixes: 5c7e105cd1 ("tty: serial: simplify qcom_geni_serial_send_chunk_fifo()")
Cc: stable <stable@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20240304174952.1.I920a314049b345efd1f69d708e7f74d2213d0b49@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 370629635
Change-Id: I0946e0e50b0433da1d926f5778dbe7b8a651f72b
(cherry picked from commit 3d9319c27ceb35fa3d2c8b15508967f3fc7e5b78)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
As of commit d7402513c935 ("arm64: smp: IPI_CPU_STOP and
IPI_CPU_CRASH_STOP should try for NMI"), if we've got pseudo-NMI
enabled then we'll use it to stop CPUs at panic time. This is nice,
but it does mean that there's a pretty good chance that we'll end up
stopping a CPU while it holds the port lock for the console
UART. Specifically, I see a CPU get stopped while holding the port
lock nearly 100% of the time on my sc7180-trogdor based Chromebook by
enabling the "buddy" hardlockup detector and then doing:
sysctl -w kernel.hardlockup_all_cpu_backtrace=1
sysctl -w kernel.hardlockup_panic=1
echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT
UART drivers are _supposed_ to handle this case OK and this is why
UART drivers check "oops_in_progress" and only do a "trylock" in that
case. However, before we enabled pseudo-NMI to stop CPUs it wasn't a
very well-tested situation.
Now that we're testing the situation a lot, it can be seen that the
Qualcomm GENI UART driver is pretty broken. Specifically, when I run
my test case and look at the console output I just see a bunch of
garbled output like:
[ 201.069084] NMI backtrace[ 201.069084] NM[ 201.069087] CPU: 6
PID: 10296 Comm: dnsproxyd Not tainted 6.7.0-06265-gb13e8c0ede12
#1 01112b9f14923cbd0b[ 201.069090] Hardware name: Google Lazor
([ 201.069092] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DI[
201.069095] pc : smp_call_function_man[ 201.069099]
That's obviously not so great. This happens because each call to the
console driver exits after the data has been written to the FIFO but
before it's actually been flushed out of the serial port. When we have
multiple calls into the console one after the other then (if we can't
get the lock) each call tells the UART to throw away any data in the
FIFO that hadn't been transferred yet.
I've posted up a patch to change the arm64 core to avoid this
situation most of the time [1] much like x86 seems to do, but even if
that patch lands the GENI driver should still be fixed.
>From testing, it appears that we can just delete the cancel/abort in
the case where we weren't able to get the UART lock and the output
looks good. It makes sense that we'd be able to do this since that
means we'll just call into __qcom_geni_serial_console_write() and
__qcom_geni_serial_console_write() looks much like
qcom_geni_serial_poll_put_char() but with a loop. However, it seems
safest to poll the FIFO and make sure it's empty before our
transfer. This should reliably make sure that we're not
interrupting/clobbering any existing transfers.
As part of this change, we'll also avoid re-setting up a TX at the end
of the console write function if we weren't able to get the lock,
since accessing "port->tx_remaining" without the lock is not
safe. This is only needed to re-start userspace initiated transfers.
[1] https://lore.kernel.org/r/20231207170251.1.Id4817adef610302554b8aa42b090d57270dc119c@changeid
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20240112150307.2.Idb1553d1d22123c377f31eacb4486432f6c9ac8d@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 370629635
Change-Id: I0d8abd6cb1471f96d8be5c51061dbd830bed236e
(cherry picked from commit 9e957a155005b16af057e86c6bcc1197cd70a6af)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231110152927.70601-32-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 370629635
Change-Id: I5d64129414dbd303ae50544ffa9385611dfabda7
(cherry picked from commit dd4d4497be8ff2a72e4345c3c1b6450cadfa75d6)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
When a serial port is used for kernel console output, then all
modifications to the UART registers which are done from other contexts,
e.g. getty, termios, are interference points for the kernel console.
So far this has been ignored and the printk output is based on the
principle of hope. The rework of the console infrastructure which aims to
support threaded and atomic consoles, requires to mark sections which
modify the UART registers as unsafe. This allows the atomic write function
to make informed decisions and eventually to restore operational state. It
also allows to prevent the regular UART code from modifying UART registers
while printk output is in progress.
All modifications of UART registers are guarded by the UART port lock,
which provides an obvious synchronization point with the console
infrastructure.
To avoid adding this functionality to all UART drivers, wrap the
spin_[un]lock*() invocations for uart_port::lock into helper functions
which just contain the spin_[un]lock*() invocations for now. In a
subsequent step these helpers will gain the console synchronization
mechanisms.
Converted with coccinelle. No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Link: https://lore.kernel.org/r/20230914183831.587273-50-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 370629635
Change-Id: Id50c4ae6fdb869fda1c55ea491f73c581e8fddec
(cherry picked from commit b8ba915d960d03bd7e24eab80f0820bdd19203ec)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Update the symbol list with new vendor hooks used by xiaomi
2 function symbol(s) added
int __traceiter_android_vh_alloc_flags_cma_adjust(gfp_t gfp_mask,
unsigned int *alloc_flags)
int __traceiter_android_vh_rmqueue_cma_fallback(struct zone *zone,
unsigned int order, struct page **page)
Bug: 374857413
Change-Id: If7ff8cef7d65a4f913afb32d3ff0ef5e56732035
Signed-off-by: 杨辉 <yanghui10@xiaomi.corp-partner.google.com>
ALLOC_CMA is hard binded to GFP_CMA now, introduce a vh for adjusting.
Bug: 291181967
Bug: 374857413
Test: build pass
Change-Id: Idd4c1a2b5971920881b8f42fdc9358918ef2a946
Signed-off-by: zhaoyang.huang <zhaoyang.huang@unisoc.com>
(cherry picked from commit 79353327f1a51082c2308733ed38b4235d5956e0)
send_message() does not block in the MBOX implementation. This is
because the mailbox layer has its own queue. However, this confuses
the per xfer timeouts as they all start their timeout ticks in
parallel.
Consider a case where the xfer timeout is 30ms and a SCMI transaction
takes 25ms:
| 0ms: Message #0 is queued in mailbox layer and sent out, then sits
| at scmi_wait_for_message_response() with a timeout of 30ms
| 1ms: Message #1 is queued in mailbox layer but not sent out yet.
| Since send_message() doesn't block, it also sits at
| scmi_wait_for_message_response() with a timeout of 30ms
| ...
| 25ms: Message #0 is completed, txdone is called and message #1 is sent
| 31ms: Message #1 times out since the count started at 1ms. Even though
| it has only been inflight for 6ms.
Bug: 374939101
Fixes: 5c8a47a5a9 ("firmware: arm_scmi: Make scmi core independent of the transport type")
Change-Id: I0ab132221c28d4594f0bbc161f431ceb49830824
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Message-Id: <20241014160717.1678953-1-justin.chen@broadcom.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
(cherry picked from commit da1642bc97c4ef67f347edcd493bd0a52f88777b)
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
Signed-off-by: Pierre Couillaud <pierre@broadcom.com>
On sc7180 Chromebooks, I did the following:
* Didn't enable earlycon in the kernel command line.
* Didn't enable serial console in the kernel command line.
* Didn't enable an agetty or any other client of "/dev/ttyMSM0".
* Added "kgdboc=ttyMSM0" to the kernel command line.
After I did that, I tried to enter kdb with this command over an ssh
session:
echo g > /proc/sysrq-trigger
When I did that the system just hung.
Although I thought I'd tested this scenario before, I couldn't go back
and find a time when it was working. Previous testing must have relied
on either the UART acting as the kernel console or an agetty running.
It turns out to be pretty easy to fix: we can just use
qcom_geni_serial_port_setup() as the .poll_init() function. This,
together with the patch ("serial: uart_poll_init() should power on the
UART"), allows the debugger to work even if there are no other users
of the serial port.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230316132027.RESEND.2.Ie678853bb101091afe78cc8c22344bf3ff3aed74@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 370629635
Change-Id: I9e362aeffbb0a6a4e68f516e5325451288409172
(cherry picked from commit d8851a96ba)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
A recent commit added back the calls top stop tx and rx to shutdown()
which had previously been removed by commit e83766334f ("tty: serial:
qcom_geni_serial: No need to stop tx/rx on UART shutdown") in order to
be able to use kgdb after stopping the getty.
Not only did this again break kgdb, but it also broke serial consoles
more generally by hanging TX when stopping the getty during reboot.
The underlying problem has been there since the driver was first merged
and fixing it is going to be a bit involved so simply stop calling the
broken stop functions during shutdown for consoles for now.
Fixes: d8aca2f968 ("tty: serial: qcom-geni-serial: stop operations in progress at shutdown")
Cc: stable <stable@kernel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride
Link: https://lore.kernel.org/r/20230307164405.14218-2-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 370629635
Change-Id: Ib532b26b318d720f74e02543e74fa26775ad4c4a
(cherry picked from commit 9aff74cc4e)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
The qcom-geni-serial driver currently only works in SE FIFO mode. This
limits the UART speed to around 180 kB/s. In order to achieve higher
speeds we need to use SE DMA mode.
Keep the console port working in FIFO mode but extend the code to use
DMA
for the high-speed port.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20221229155030.418800-15-brgl@bgdev.pl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 370629635
Change-Id: I0880354e27e04cb1a49a4759d6df7fe315311574
(cherry picked from commit 2aaa43c707)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
After the SQ cleanup fix, the CQ will receive a response with
the corresponding tag marked as OCS: ABORTED. To align with
the behavior of Legacy SDB mode, the handling of OCS: ABORTED
has been changed to match that of OCS_INVALID_COMMAND_STATUS
(SDB), with both returning a SCSI result of DID_REQUEUE.
Furthermore, the workaround implemented before the SQ cleanup
fix can be removed.
Bug: 373785306
Fixes: ab248643d3 ("scsi: ufs: core: Add error handling for MCQ mode")
Change-Id: Id1d51f2921a519aa5d2a83b7fc70e17a45fb26b9
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/all/20241001091917.6917-3-peter.wang@mediatek.com/
When setting the ICU bit without using read-modify-write,
SQRTCy will restart SQ again and receive an RTC return
error code 2 (Failure - SQ not stopped).
Additionally, the error log has been modified so that
this type of error can be observed.
Bug: 373785306
Fixes: ab248643d3 ("scsi: ufs: core: Add error handling for MCQ mode")
Change-Id: I46fca8eaeaa17c622349b26f97fc100aa182dea2
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/all/20241001091917.6917-2-peter.wang@mediatek.com/
Don't run a protected VCPU in pKVM if it isn't in a runnable PSCI
state. For protected VMs, the PSCI state is the reference state
for whether they are runnable or not.
Bug: 278749606
Bug: 373638114
Reported-by: Dmytro Maluka <dmaluka@google.com>
Change-Id: I17cc60852aa45225e65fe810f9b196e3afe88a70
Signed-off-by: Fuad Tabba <tabba@google.com>
BmAttributes controls the maximum number of streams supported by the endpoint.
streaming is a data transmission mode that allows multiple data packets
to be sent simultaneously in one transmission cycle.
Set bmAttributes to 16, bulk endpoint with more than 65536 streams,
can effectively improve data throughput.
Modify bmAttributes to 16.
The 5Gbps peak rate increases from 350MB/s to 400MB/s.
The 10Gbps peak rate is increased from 500MB/s to 600MB/s.
Bug: 373314134
Change-Id: I4b6c9554ff39a7b2222461e1949825dd6148c006
Signed-off-by: Lianqin Hu <hulianqin@vivo.corp-partner.google.com>
Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Spi geni driver switches between FIFO and DMA modes based on xfer length.
FIFO mode relies on M_CMD_DONE_EN interrupt for completion while DMA mode
relies on XX_DMA_DONE.
During dynamic switching, if FIFO mode is chosen, FIFO related interrupts
are enabled and DMA related interrupts are disabled. And viceversa.
Chip select shares M_CMD_DONE_EN interrupt with FIFO to check completion.
Now, if a chip select operation is preceded by a DMA xfer, M_CMD_DONE_EN
interrupt would have been disabled and hence it will never receive one
resulting in timeout.
For chip select, in addition to setting the xfer mode to FIFO,
select_mode() to FIFO so that required interrupts are enabled.
Fixes: e5f0dfa78a ("spi: spi-geni-qcom: Add support for SE DMA mode")
Suggested-by: Praveen Talari <quic_ptalari@quicinc.com
Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com
Reviewed-by: Douglas Anderson <dianders@chromium.org
Link: https://lore.kernel.org/r/1683626496-9685-1-git-send-email-quic_vnivarth@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org
Bug: 370629635
Change-Id: Icd72416f413abc7fd67ac69c1a56251d9b2b4149
(cherry picked from commit 4c329f5da7)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
If topup_hyp_memcache() fails mid-way through a memcache top-up, we
should still account for the pages that were successfully added.
Don't skip accounting when topup_hyp_memcache() fails.
Bug: 373813803
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I2ffcfbe45452600994f5b69b73ea2bd00d64aeae
When VM creation fails part-way through __pkvm_create_hyp_vm(), we end
up destroying the partial state by calling pkvm_destroy_hyp_vm()
before the memory accounting metadata has been updated. Consequently,
we underflow the 'protected_hyp_mem' counter and run into the following
warning:
18446744073709518848B of donations to the nVHE hyp are missing
Rework the accounting updates so that the per-VM structures are
accounted immediately after initialising the VM, with the vCPU memory
being accounted one-by-one as they are initialised.
Bug: 373813803
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: If4ae9816df009ca2a74aff5964676465c25fe6dc
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230303172041.2103336-30-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Bug: 370629635
Change-Id: I604c1be770a2413f9370befef1acbbcb05b5191d
(cherry picked from commit d0b52f6539)
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
