linux-stable.git/drivers/net/ipa, branch v5.7.7 Linux kernel stable tree net: ipa: program upper nibbles of sequencer type 2020-06-24T15:49:11+00:00 Alex Elder elder@linaro.org 2020-06-11T19:48:32+00:00 511db12b4dca2b1954004999d4ea328e9b6ea6f6 [ Upstream commit 636edeaad5577b6023f0de2b98a010d1cea73607 ] The upper two nibbles of the sequencer type were not used for SDM845, and were assumed to be 0. But for SC7180 they are used, and so they must be programmed by ipa_endpoint_init_seq(). Fix this bug. IPA_SEQ_PKT_PROCESS_NO_DEC_NO_UCP_DMAP doesn't have a descriptive comment, so add one. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 636edeaad5577b6023f0de2b98a010d1cea73607 ]

The upper two nibbles of the sequencer type were not used for
SDM845, and were assumed to be 0.  But for SC7180 they are used, and
so they must be programmed by ipa_endpoint_init_seq().  Fix this bug.

IPA_SEQ_PKT_PROCESS_NO_DEC_NO_UCP_DMAP doesn't have a descriptive
comment, so add one.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: ipa: do not clear interrupt in gsi_channel_start() 2020-06-22T07:32:45+00:00 Alex Elder elder@linaro.org 2020-05-15T20:07:31+00:00 208796e693a02630ba24520d15dc695e6bea0e6a [ Upstream commit 195ef57f870070cb02f2f3b99a63d69e8e8f798e ] In gsi_channel_start() there is harmless-looking comment "Clear the channel's event ring interrupt in case it's pending". The intent was to avoid getting spurious interrupts when first bringing up a channel. However we now use channel stop/start to implement suspend and resume, and an interrupt pending at the time we resume is actually something we don't want to ignore. The very first time we bring up the channel we do not expect an interrupt to be pending, and even if it were, the effect would simply be to schedule NAPI on that channel, which would find nothing to do, which is not a problem. Stop clearing any pending IEOB interrupt in gsi_channel_start(). That leaves one caller of the trivial function gsi_isr_ieob_clear(). Get rid of that function and just open-code it in gsi_isr_ieob() instead. This fixes a problem where suspend/resume IPA v4.2 would get stuck when resuming after a suspend. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 195ef57f870070cb02f2f3b99a63d69e8e8f798e ]

In gsi_channel_start() there is harmless-looking comment "Clear the
channel's event ring interrupt in case it's pending".  The intent
was to avoid getting spurious interrupts when first bringing up a
channel.

However we now use channel stop/start to implement suspend and
resume, and an interrupt pending at the time we resume is actually
something we don't want to ignore.

The very first time we bring up the channel we do not expect an
interrupt to be pending, and even if it were, the effect would
simply be to schedule NAPI on that channel, which would find nothing
to do, which is not a problem.

Stop clearing any pending IEOB interrupt in gsi_channel_start().
That leaves one caller of the trivial function gsi_isr_ieob_clear().
Get rid of that function and just open-code it in gsi_isr_ieob()
instead.

This fixes a problem where suspend/resume IPA v4.2 would get stuck
when resuming after a suspend.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: ipa: don't be a hog in gsi_channel_poll() 2020-05-16T22:14:54+00:00 Alex Elder elder@linaro.org 2020-05-15T19:52:03+00:00 f45a7bccdc190e2cf6ca3a527edbc4c80d7114ef The iteration count value used in gsi_channel_poll() is intended to limit poll iterations to the budget supplied as an argument. But it's never updated. Fix this bug by incrementing the count each time through the loop. Reported-by: Sharath Chandra Vurukala <sharathv@codeaurora.com> Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
The iteration count value used in gsi_channel_poll() is intended to
limit poll iterations to the budget supplied as an argument.  But
it's never updated.

Fix this bug by incrementing the count each time through the loop.

Reported-by: Sharath Chandra Vurukala <sharathv@codeaurora.com>
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers: ipa: fix typos for ipa_smp2p structure doc 2020-05-14T20:06:55+00:00 Wang Wenhu wenhu.wang@vivo.com 2020-05-14T11:02:22+00:00 16bb1b505c3c6ec6c0ec5943cef67b23f228979a Remove the duplicate "mutex", and change "Motex" to "Mutex". Also I recommend it's easier for understanding to make the "ready-interrupt" a bundle for it is a parallel description as "shutdown" which is appended after the slash. Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com> Cc: Alex Elder <elder@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Remove the duplicate "mutex", and change "Motex" to "Mutex". Also I
recommend it's easier for understanding to make the "ready-interrupt"
a bundle for it is a parallel description as "shutdown" which is appended
after the slash.

Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Cc: Alex Elder <elder@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: use tag process on modem crash 2020-05-11T21:00:29+00:00 Alex Elder elder@linaro.org 2020-05-07T19:14:04+00:00 2c4bb8093c3bfebc8113c683a5de83c64d43514c One part of recovering from a modem crash is performing a "tag sequence" of several IPA immediate commands, to clear the hardware pipeline. The sequence ends with a data transfer request on the command endpoint (which is not otherwise done). Unfortunately, attempting to do the data transfer led to a hang, so that request plus two other commands were commented out. The previous commit fixes the bug that was causing that hang. And with that bug fixed we can properly issue the tag sequence when the modem crashes, to return the hardware to a known state. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
One part of recovering from a modem crash is performing a "tag
sequence" of several IPA immediate commands, to clear the hardware
pipeline.  The sequence ends with a data transfer request on the
command endpoint (which is not otherwise done).  Unfortunately,
attempting to do the data transfer led to a hang, so that request
plus two other commands were commented out.

The previous commit fixes the bug that was causing that hang.  And
with that bug fixed we can properly issue the tag sequence when the
modem crashes, to return the hardware to a known state.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: set DMA length in gsi_trans_cmd_add() 2020-05-11T21:00:29+00:00 Alex Elder elder@linaro.org 2020-05-07T19:14:03+00:00 c781e1d4f3e23d5fc138dad2fd98ca0e0dd9c592 When a command gets added to a transaction for the AP->command channel we set the DMA address of its scatterlist entry, but not its DMA length. Fix this bug. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
When a command gets added to a transaction for the AP->command
channel we set the DMA address of its scatterlist entry, but not
its DMA length.  Fix this bug.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: zero return code before issuing generic EE command 2020-05-01T01:04:58+00:00 Alex Elder elder@linaro.org 2020-04-30T21:35:12+00:00 0b1ba18aec3e599c16cca7d99969282fb9db7e92 Zero the result code stored in a field of the scratch 0 register before issuing a generic EE command. This just guarantees that the value we read later was actually written as a result of the command. Also add the definitions of two more possible result codes that can be returned when issuing flow control enable or disable commands: INCORRECT_CHANNEL_STATE: - channel must be in started state INCORRECT_DIRECTION - flow control is only valid for TX channels Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Zero the result code stored in a field of the scratch 0 register
before issuing a generic EE command.  This just guarantees that
the value we read later was actually written as a result of the
command.

Also add the definitions of two more possible result codes that can
be returned when issuing flow control enable or disable commands:
  INCORRECT_CHANNEL_STATE: - channel must be in started state
  INCORRECT_DIRECTION - flow control is only valid for TX channels

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: fix an error message in gsi_channel_init_one() 2020-05-01T01:04:58+00:00 Alex Elder elder@linaro.org 2020-04-30T21:35:11+00:00 0721999f157006367965f4c4e7d5594bd4c9bf15 An error message about limiting the number of TREs used prints the wrong value. Fix this bug. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
An error message about limiting the number of TREs used prints the
wrong value.  Fix this bug.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipa: fix a bug in ipa_endpoint_stop() 2020-05-01T01:04:58+00:00 Alex Elder elder@linaro.org 2020-04-30T21:35:10+00:00 713b6ebb4c376b3fb65fdceb3b59e401c93248f9 In ipa_endpoint_stop(), for TX endpoints we set the number of retries to 0. When we break out of the loop, retries being 0 means we return EIO rather than the value of ret (which should be 0). Fix this by using a non-zero retry count for both RX and TX channels, and just break out of the loop after calling gsi_channel_stop() for TX channels. This way only RX channels will retry, and the retry count will be non-zero at the end for TX channels (so the proper value gets returned). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
In ipa_endpoint_stop(), for TX endpoints we set the number of retries
to 0.  When we break out of the loop, retries being 0 means we return
EIO rather than the value of ret (which should be 0).

Fix this by using a non-zero retry count for both RX and TX
channels, and just break out of the loop after calling
gsi_channel_stop() for TX channels.  This way only RX channels
will retry, and the retry count will be non-zero at the end
for TX channels (so the proper value gets returned).

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
soc: qcom: ipa: Add a missing '\n' in a log message 2020-04-12T18:44:18+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2020-04-11T07:30:04+00:00 2ba538989479b3ff34f66728ecfbaf3c5daf0797 Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'. Fixes: a646d6ec9098 ("soc: qcom: ipa: modem and microcontroller") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.

Fixes: a646d6ec9098 ("soc: qcom: ipa: modem and microcontroller")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>