This change switches to the new devm_iio_triggered_buffer_setup_ext()
function and removes the iio_buffer_set_attrs() call, for assigning the
HW FIFO attributes to the buffer.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-5-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change adds a parameter to the {devm_}iio_triggered_buffer_setup()
functions to assign the extra sysfs buffer attributes that are typically
assigned via iio_buffer_set_attrs().
The functions also get renamed to iio_triggered_buffer_setup_ext() &
devm_iio_triggered_buffer_setup_ext().
For backwards compatibility the old {devm_}iio_triggered_buffer_setup()
functions are now macros wrap the new (renamed) functions with NULL for the
buffer attrs.
The aim is to remove iio_buffer_set_attrs(), so in the
iio_triggered_buffer_setup_ext() function the attributes are assigned
directly to 'buffer->attrs'.
When adding multiple IIO buffers per IIO device, it can be pretty
cumbersome to first allocate a set of buffers, then to dig them out of IIO
to assign extra attributes (with iio_buffer_set_attrs()).
Naturally, the best way would be to provide them at allocation time, which
is what this change does.
At this moment, buffers allocated with {devm_}iio_triggered_buffer_setup()
are the only ones in mainline IIO to call iio_buffer_set_attrs().
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-4-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change is mostly cosmetic, but it's also a pre-cursor to the
the change for 'iio_buffer_set_attrs()', where the helper gets updated to
better support multiple IIO buffers for 1 IIO device.
The only functional change is that the error message for the trigger alloc
failure is bound to the parent device vs the IIO device object.
Also, the new at91_adc_buffer_and_trigger_init() function was moved after
the definition of the 'at91_adc_fifo_attributes'.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-3-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_buffer_set_attrs() helper will be removed in this series. So, just
assign the attributes of the DMAEngine buffer logic directly.
This is IIO buffer core context, so there is direct access to the
buffer->attrs object.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200929125949.69934-2-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Example `display-subsystem` has an incorrect compatible string.
Required properties section tells that developers should use
"fsl,imx-display-subsystem" as "compatible" string but the example
misses 'imx-' prefix.
Change example to have correct "compatible" string.
Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
Link: https://lore.kernel.org/r/20201113150618.417424-1-cengiz@kernel.wtf
Signed-off-by: Rob Herring <robh@kernel.org>
The kernel uses ACPI Boot Error Record Table (BERT) to report fatal
errors that occurred in a previous boot. The MCA errors in the BERT are
reported using the x86 Processor Error Common Platform Error Record
(CPER) format. Currently, the record prints out the raw MSR values and
AMD relies on the raw record to provide MCA information.
Extract the raw MSR values of MCA registers from the BERT and feed them
into mce_log() to decode them properly.
The implementation is SMCA-specific as the raw MCA register values are
given in the register offset order of the SMCA address space.
[ bp: Massage. ]
[ Fix a build breakage in patch v1. ]
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lkml.kernel.org/r/20201119182938.151155-1-Smita.KoralahalliChannabasappa@amd.com
In the patch to be fixed, horizontal_backporch_byte become too large
for some panel, so roll back that patch. For small hfp or hbp panel,
using vm->hfront_porch + vm->hback_porch to calculate
horizontal_backporch_byte would make it negtive, so
use horizontal_backporch_byte itself to make it positive.
Fixes: 35bf948f1e ("drm/mediatek: dsi: Fix scrolling of panel with small hfp or hbp")
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Tested-by: Bilal Wasim <bilal.wasim@imgtec.com>
'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by
an equivalent 'dma_set_mask_and_coherent()' which is much less verbose.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20201121083747.1330299-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use TEST %reg,%reg which sets the zero flag in the same way as CMP
$0,%reg, but the encoding uses one byte less.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Link: https://lkml.kernel.org/r/20201029160258.139216-1-ubizjak@gmail.com
The only usage of the ops field in the loopback_cable struct is to call
its members, the field it self is never changed. Make it a pointer to
const. This allows us to constify two static loopback_ops structs to
allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20201120231046.76758-1-rikard.falkeborn@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Thomas Falcon says:
====================
ibmvnic: Performance improvements and other updates
The first three patches utilize a hypervisor call allowing multiple
TX and RX buffer replenishment descriptors to be sent in one operation,
which significantly reduces hypervisor call overhead. The xmit_more
and Byte Queue Limit API's are leveraged to provide this support
for TX descriptors.
The subsequent two patches remove superfluous code and members in
TX completion handling function and TX buffer structure, respectively,
and remove unused routines.
Finally, four patches which ensure that device queue memory is
cache-line aligned, resolving slowdowns observed in PCI traces,
as well as optimize the driver's NAPI polling function and
to RX buffer replenishment are provided by Dwip Banerjee.
This series provides significant performance improvements, allowing
the driver to fully utilize 100Gb NIC's.
====================
Link: https://lore.kernel.org/r/1605748345-32062-1-git-send-email-tlfalcon@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reduce the amount of time spent replenishing RX buffers by only doing
so once available buffers has fallen under a certain threshold, in this
case half of the total number of buffers, or if the polling loop exits
before the packets processed is less than its budget. Non-exhaustion of
NAPI budget implies lower incoming packet pressure, allowing the leeway
to refill the buffers in preparation for any impending burst.
Signed-off-by: Dwip N. Banerjee <dnbanerg@us.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Take advantage of the additional optimizations in netdev_alloc_skb when
allocating socket buffers to be used for packet reception.
Signed-off-by: Dwip N. Banerjee <dnbanerg@us.ibm.com>
Acked-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If the current NAPI polling loop exits without completing it's
budget, only re-enable interrupts if there are no entries remaining
in the queue and napi_complete_done is successful. If there are entries
remaining on the queue that were missed, restart the polling loop.
Signed-off-by: Dwip N. Banerjee <dnbanerg@us.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
PCI bus slowdowns were observed on IBM VNIC devices as a result
of partial cache line writes and non-cache aligned full cache line writes.
Ensure that packet data buffers are cache-line aligned to avoid these
slowdowns.
Signed-off-by: Dwip N. Banerjee <dnbanerg@us.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
It is not longer used, so remove it.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Acked-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Remove unused and superfluous code and members in
existing TX implementation and data structures.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Include support for the xmit_more feature utilizing the
H_SEND_SUB_CRQ_INDIRECT hypervisor call which allows the sending
of multiple subordinate Command Response Queue descriptors in one
hypervisor call via a DMA-mapped buffer. This update reduces hypervisor
calls and thus hypervisor call overhead per TX descriptor.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Utilize the H_SEND_SUB_CRQ_INDIRECT hypervisor call to send
multiple RX buffer descriptors to the device in one hypervisor
call operation. This change will reduce the number of hypervisor
calls and thus hypervisor call overhead needed to transmit
RX buffer descriptors to the device.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch introduces the infrastructure to send batched subordinate
Command Response Queue descriptors, which are used by the ibmvnic
driver to send TX frame and RX buffer descriptors.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Acked-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The main purpose of the loop is to load the memory to the SCP SRAM.
If filesz is 0, can go to next program header directly.
We don't need to try to validate the FW binary for those filesz==0
segments.
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201116084413.3312631-3-tzungbi@google.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
It is valid if offset+length == sram_size.
For example, sram_size=100, offset=99, length=1. Accessing offset 99
with length 1 is valid.
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201116084413.3312631-2-tzungbi@google.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Fixes the following sparse errors on dma_alloc_coherent() and
dma_free_coherent().
On drivers/remoteproc/mtk_scp.c:559:23:
warning: incorrect type in assignment (different address spaces)
expected void [noderef] __iomem *cpu_addr
got void *
On drivers/remoteproc/mtk_scp.c:572:56:
warning: incorrect type in argument 3 (different address spaces)
expected void *cpu_addr
got void [noderef] __iomem *cpu_addr
The cpu_addr is not a __iomem address. Removes the marker.
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201116082537.3287009-3-tzungbi@google.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Julian Wiedmann says:
====================
s390/qeth: fixes 2020-11-20
This brings several fixes for qeth's af_iucv-specific code paths.
Also one fix by Alexandra for the recently added BR_LEARNING_SYNC
support. We want to trust the feature indication bit, so that HW can
mask it out if there's any issues on their end.
====================
Link: https://lore.kernel.org/r/20201120090939.101406-1-jwi@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When qeth_iqd_tx_complete() detects that a TX buffer requires additional
async completion via QAOB, it might fail to replace the queue entry's
metadata (and ends up triggering recovery).
Assume now that the device gets torn down, overruling the recovery.
If the QAOB notification then arrives before the tear down has
sufficiently progressed, the buffer state is changed to
QETH_QDIO_BUF_HANDLED_DELAYED by qeth_qdio_handle_aob().
The tear down code calls qeth_drain_output_queue(), where
qeth_cleanup_handled_pending() will then attempt to replace such a
buffer _again_. If it succeeds this time, the buffer ends up dangling in
its replacement's ->next_pending list ... where it will never be freed,
since there's no further call to qeth_cleanup_handled_pending().
But the second attempt isn't actually needed, we can simply leave the
buffer on the queue and re-use it after a potential recovery has
completed. The qeth_clear_output_buffer() in qeth_drain_output_queue()
will ensure that it's in a clean state again.
Fixes: 72861ae792 ("qeth: recovery through asynchronous delivery")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The two expected notification sequences are
1. TX_NOTIFY_PENDING with a subsequent TX_NOTIFY_DELAYED_*, when
our TX completion code first observed the pending TX and the QAOB
then completes at a later time; or
2. TX_NOTIFY_OK, when qeth_qdio_handle_aob() picked up the QAOB
completion before our TX completion code even noticed that the TX
was pending.
But as qeth_iqd_tx_complete() and qeth_qdio_handle_aob() can run
concurrently, we may end up with a race that results in a sequence of
TX_NOTIFY_DELAYED_* followed by TX_NOTIFY_PENDING. Which would confuse
the af_iucv code in its tracking of pending transmits.
Rework the notification code, so that qeth_qdio_handle_aob() defers its
notification if the TX completion code is still active.
Fixes: b333293058 ("qeth: add support for af_iucv HiperSockets transport")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Calling into socket code is ugly already, at least check whether we are
dealing with the expected sk_family. Only looking at skb->protocol is
bound to cause troubles (consider eg. af_packet).
Fixes: b333293058 ("qeth: add support for af_iucv HiperSockets transport")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Remove workaround that supported early hardware implementations
of PNSO OC3. Rely on the 'enarf' feature bit instead.
Fixes: fa115adff2 ("s390/qeth: Detect PNSO OC3 capability")
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Julian Wiedmann <jwi@linux.ibm.com>
[jwi: use logical instead of bit-wise AND]
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert the b53 DSA device tree bindings to YAML in order to allow
for automatic checking and such.
Reviewed-by: Rob Herring <robh@kernel.org>
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kurt Kanzenbach <kurt@kmk-computers.de>
Provide an empty 'ports' container node with the correct #address-cells
and #size-cells properties. This silences the following warning:
arch/arm/boot/dts/bcm958522er.dt.yaml:
ethernet-switch@36000: 'oneOf' conditional failed, one must be fixed:
'ports' is a required property
'ethernet-ports' is a required property
From schema:
Documentation/devicetree/bindings/net/dsa/b53.yaml
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Provide a valid compatible string for the Ethernet switch node based on
the board including the switch. This allows us to have sane defaults and
silences the following warnings:
arch/arm/boot/dts/bcm958522er.dt.yaml:
ethernet-switch@36000: compatible: 'oneOf' conditional failed,
one
must be fixed:
['brcm,bcm5301x-srab'] is too short
'brcm,bcm5325' was expected
'brcm,bcm53115' was expected
'brcm,bcm53125' was expected
'brcm,bcm53128' was expected
'brcm,bcm5365' was expected
'brcm,bcm5395' was expected
'brcm,bcm5389' was expected
'brcm,bcm5397' was expected
'brcm,bcm5398' was expected
'brcm,bcm11360-srab' was expected
'brcm,bcm5301x-srab' is not one of ['brcm,bcm53010-srab',
'brcm,bcm53011-srab', 'brcm,bcm53012-srab', 'brcm,bcm53018-srab',
'brcm,bcm53019-srab']
'brcm,bcm5301x-srab' is not one of ['brcm,bcm11404-srab',
'brcm,bcm11407-srab', 'brcm,bcm11409-srab', 'brcm,bcm58310-srab',
'brcm,bcm58311-srab', 'brcm,bcm58313-srab']
'brcm,bcm5301x-srab' is not one of ['brcm,bcm58522-srab',
'brcm,bcm58523-srab', 'brcm,bcm58525-srab', 'brcm,bcm58622-srab',
'brcm,bcm58623-srab', 'brcm,bcm58625-srab', 'brcm,bcm88312-srab']
'brcm,bcm5301x-srab' is not one of ['brcm,bcm3384-switch',
'brcm,bcm6328-switch', 'brcm,bcm6368-switch']
From schema:
Documentation/devicetree/bindings/net/dsa/b53.yaml
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
The register name should be "sgmii_config", not "sgmii", this is not a
functional change since no code is currently looking for that register
by name (or at all).
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Update the switch unit name from srab to ethernet-switch, allowing us
to fix warnings such as:
CHECK arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml:
srab@18007000: $nodename:0: 'srab@18007000' does not match
'^(ethernet-)?switch(@.*)?$'
From schema:
Documentation/devicetree/bindings/net/dsa/b53.yaml
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Provide an empty 'ports' container node with the correct #address-cells
and #size-cells properties. This silences the following warning:
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml:
ethernet-switch@18007000: 'oneOf' conditional failed, one must be fixed:
'ports' is a required property
'ethernet-ports' is a required property
From schema:
Documentation/devicetree/bindings/net/dsa/b53.yaml
Acked-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Provide a default compatible string which is based on the 53011 SRAB
compatible by default. The 4709 and 47094 default to the 53012 SRAB
compatible.
This allows us to have sane defaults and silences the following
warnings:
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml:
ethernet-switch@18007000: compatible: 'oneOf' conditional failed, one
must be fixed:
['brcm,bcm5301x-srab'] is too short
'brcm,bcm5325' was expected
'brcm,bcm53115' was expected
'brcm,bcm53125' was expected
'brcm,bcm53128' was expected
'brcm,bcm5365' was expected
'brcm,bcm5395' was expected
'brcm,bcm5389' was expected
'brcm,bcm5397' was expected
'brcm,bcm5398' was expected
'brcm,bcm11360-srab' was expected
'brcm,bcm5301x-srab' is not one of ['brcm,bcm53010-srab',
'brcm,bcm53011-srab', 'brcm,bcm53012-srab', 'brcm,bcm53018-srab',
'brcm,bcm53019-srab']
'brcm,bcm5301x-srab' is not one of ['brcm,bcm11404-srab',
'brcm,bcm11407-srab', 'brcm,bcm11409-srab', 'brcm,bcm58310-srab',
'brcm,bcm58311-srab', 'brcm,bcm58313-srab']
'brcm,bcm5301x-srab' is not one of ['brcm,bcm58522-srab',
'brcm,bcm58523-srab', 'brcm,bcm58525-srab', 'brcm,bcm58622-srab',
'brcm,bcm58623-srab', 'brcm,bcm58625-srab', 'brcm,bcm88312-srab']
'brcm,bcm5301x-srab' is not one of ['brcm,bcm3384-switch',
'brcm,bcm6328-switch', 'brcm,bcm6368-switch']
From schema:
Documentation/devicetree/bindings/net/dsa/b53.yaml
Acked-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Update the switch unit name from srab to ethernet-switch, allowing us to
fix warnings such as:
CHECK arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml:
srab@18007000: $nodename:0: 'srab@18007000' does not match
'^(ethernet-)?switch(@.*)?$'
From schema:
Documentation/devicetree/bindings/net/dsa/b53.yaml
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
The 'sfp' and 'managed' properties are commonly used to describe
Ethernet switch ports connecting to SFP/SFF cages, describe these two
properties as valid that we inherit from ethernet-controller.yaml.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Upon discussion with Kurt, Rob and Vladimir it appears that we should be
allowing ethernet-switch as a node name, update dsa.yaml accordingly.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
In order to use generic arch_stack_walk() code, make stack walk
callback consistent with it.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Alex Elder says:
====================
net: ipa: add a driver shutdown callback
The final patch in this series adds a driver shutdown callback for
the IPA driver. The patches leading up to that address some issues
encountered while ensuring that callback worked as expected:
- The first just reports a little more information when channels
or event rings are in unexpected states
- The second patch recognizes a condition where an as-yet-unused
channel does not require a reset during teardown
- The third patch explicitly ignores a certain error condition,
because it can't be avoided, and is harmless if it occurs
- The fourth properly handles requests to retry a channel HALT
request
- The fifth makes a second attempt to stop modem activity during
shutdown if it's busy
The shutdown callback is implemented by calling the existing remove
callback function (reporting if that returns an error).
====================
Link: https://lore.kernel.org/r/20201119224929.23819-1-elder@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A system shutdown can happen at essentially any time, and it's
possible that the IPA driver is busy when a shutdown is underway.
IPA hardware accesses IMEM and SMEM memory regions using an IOMMU,
and at some point during shutdown, needed I/O mappings could become
invalid. This could be disastrous for any "in flight" IPA activity.
Avoid this by defining a new driver shutdown callback that stops all
IPA activity and cleanly shuts down the driver. It merely calls the
driver's existing remove callback, reporting the error if it returns
one.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The IPA driver remove callback, ipa_remove(), calls ipa_modem_stop()
if the setup stage of initialization is complete. If a concurrent
call to ipa_modem_start() or ipa_modem_stop() has begin but not
completed, ipa_modem_stop() can return an error (-EBUSY).
The next patch adds a driver shutdown callback, which will simply
call ipa_remove(). We really want our shutdown callback to clean
things up. So add a single retry to the ipa_modem_stop() call in
ipa_remove() after a short (millisecond) delay. This offers no
guarantee the shutdown will complete successfully, but we'll at
least try a little harder before giving up.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When stopping an AP RX channel, there can be a transient period
while the channel enters STOP_IN_PROC state before reaching the
final STOPPED state. In that case we make another attempt to stop
the channel.
Similarly, when stopping a modem channel (using a GSI generic
command issued from the AP), it's possible that multiple attempts
will be required before the channel reaches STOPPED state.
Add a field to the GSI structure to record an errno representing the
result code provided when a generic command completes. If the
result learned in gsi_isr_gp_int1() is RETRY, record -EAGAIN in the
result code, otherwise record 0 for success, or -EIO for any other
result.
If we time out nf gsi_generic_command() waiting for the command to
complete, return -ETIMEDOUT (as before). Otherwise return the
result stashed by gsi_isr_gp_int1().
Add a loop in gsi_modem_channel_halt() to reissue the HALT command
if the result code indicates -EAGAIN. Limit this to 10 retries
(after the initial attempt).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
IPA v4.2 has a hardware quirk that requires the AP to allocate GSI
channels for the modem to use. It is recommended that these modem
channels get stopped (with a HALT generic command) by the AP when
its IPA driver gets removed.
The AP has no way of knowing the current state of a modem channel.
So when the IPA driver issues a HALT command it's possible the
channel is not running, and in that case we get an error indication.
This error simply means we didn't need to stop the channel, so we
can ignore it.
This patch adds an explanation for this situation, and arranges for
this condition to *not* report an error message.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
