sama7g5ek comes with a SPI NOR flash connected to the QSPI
controller. Enable the SPI NOR subsystem and the QSPI controller.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20211209153744.357465-2-tudor.ambarus@microchip.com
Some of the drivers do not set parent device. This may lead to obstacles
during debugging or understanding the device relations from the Linux
point of view. Assign parent device for GPIO chips created by these
drivers.
While at it, let GPIO library to assign of_node from the parent device.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
GPIO library does copy the of_node from the parent device of
the GPIO chip, there is no need to repeat this in the individual
drivers. Remove these assignment all at once.
For the details one may look into the of_gpio_dev_init() implementation.
While at it, remove duplicate parent device assignment where it is the case.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-By: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The return value of pm_runtime_resume_and_get() needs to be checked to
avoid a usage count imbalance in the error case. This fix is basically
the same as 92c959bae2 ("reset: renesas: Fix Runtime PM usage"),
and the last step before pm_runtime_resume_and_get() can be annotated
as __must_check.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/9fed506d-b780-55cd-45a4-9bd2407c910f@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Not all .S files include asm/assembler.h, however the SYM_FUNC_*
definitions invoke the 'bti' macro. Include asm/assembler.h in
asm/linkage.h.
Fixes: 9be34be87c ("arm64: Add macro version of the BTI instruction")
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
After calling dmaengine_submit(), the submitted transfer descriptor
belongs to the DMA engine. Pointer to that descriptor may no longer be
valid after the call and should be tested before awaiting transfer
completion.
Reported-by: Kevin Tian <kevin.tian@intel.com>
Suggested-by: Dave Jiang <dave.jiang@intel.com>
Fixes: 4fac9b31d0 ("ASoC: Intel: Add catpt base members")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20211216115743.2130622-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The qpnpint_irq_set_type() callback function configures the type
(edge vs level) and polarity (high, low, or both) of a particular
PMIC interrupt within a given peripheral. To do this, it reads
the three consecutive IRQ configuration registers, modifies the
specified IRQ bit within the register values, and finally writes
the three modified register values back to the PMIC. While a
spinlock is used to provide mutual exclusion on the SPMI bus
during the register read and write calls, there is no locking
around the overall read, modify, write sequence. This opens up
the possibility of a race condition if two tasks set the type of
a PMIC IRQ within the same peripheral simultaneously.
When the race condition is encountered, both tasks will read the
old value of the registers and IRQ bits set by one of the tasks
will be dropped upon the register write of the other task. This
then leads to PMIC IRQs being enabled with an incorrect type and
polarity configured. Such misconfiguration can lead to an IRQ
storm that overwhelms the system and causes it to crash.
This race condition and IRQ storm have been observed when using
a pair of pm8941-pwrkey devices to handle PMK8350 pwrkey and
resin interrupts. The independent devices probe asynchronously
in parallel and can simultaneously request and configure PMIC
IRQs in the same PMIC peripheral.
For a good case, the IRQ configuration calls end up serialized
due to timing deltas and the register read/write sequence looks
like this:
1. pwrkey probe: SPMI read(0x1311): 0x00, 0x00, 0x00
2. pwrkey probe: SPMI write(0x1311): 0x80, 0x80, 0x80
3. resin probe: SPMI read(0x1311): 0x80, 0x80, 0x80
4. resin probe: SPMI write(0x1311): 0xC0, 0xC0, 0xC0
The final register states after both devices have requested and
enabled their respective IRQs is thus:
0x1311: 0xC0
0x1312: 0xC0
0x1313: 0xC0
0x1314: 0x00
0x1315: 0xC0
For a bad case, the IRQ configuration calls end up occurring
simultaneously and the race condition is encountered. The
register read/write sequence then looks like this:
1. pwrkey probe: SPMI read(0x1311): 0x00, 0x00, 0x00
2. resin probe: SPMI read(0x1311): 0x00, 0x00, 0x00
3. pwrkey probe: SPMI write(0x1311): 0x80, 0x80, 0x80
4. resin probe: SPMI write(0x1311): 0x40, 0x40, 0x40
In this case, the final register states after both devices have
requested and enabled their respective IRQs is thus:
0x1311: 0x40
0x1312: 0x40
0x1313: 0x40
0x1314: 0x00
0x1315: 0xC0
This corresponds to the resin IRQ being configured for both
rising and falling edges, as expected. However, the pwrkey IRQ
is misconfigured as level type with both polarity high and low
set to disabled. The PMIC IRQ triggering hardware treats this
particular register configuration as if level low triggering is
enabled.
The raw pwrkey IRQ signal is low when the power key is not being
pressed. Thus, the pwrkey IRQ begins firing continuously in an
IRQ storm.
Fix the race condition by holding the spmi-pmic-arb spinlock for
the duration of the read, modify, write sequence performed in the
qpnpint_irq_set_type() function. Split the pmic_arb_read_cmd()
and pmic_arb_write_cmd() functions each into three parts so that
hardware register IO is decoupled from spinlock locking. This
allows a new function pmic_arb_masked_write() to be added which
locks the spinlock and then calls register IO functions to
perform SPMI read and write commands in a single atomic
operation.
Link: https://lore.kernel.org/r/20211118034719.28971-1-quic_collinsd@quicinc.com
Signed-off-by: David Collins <quic_collinsd@quicinc.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20211216190812.1574801-7-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add spmi support for MT8195.
Refine indent in spmi-mtk-pmif.c.
Link: https://lore.kernel.org/r/20211119034613.32489-5-james.lo@mediatek.com
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: James Lo <james.lo@mediatek.com>
Signed-off-by: Henry Chen <henryc.chen@mediatek.com>
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20211216190812.1574801-6-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's useful to know what particular device/component is having trouble
accessing the bus. Add the sid and address to error messages here so
that debugging is a little simpler.
Link: https://lore.kernel.org/r/20210920234849.3614036-1-swboyd@chromium.org
Cc: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Cc: satya priya <skakit@codeaurora.org>
Reviewed-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Reviewed-by: Satya Priya <skakit@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20211216190812.1574801-2-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The find.h APIs are designed to be used only on unsigned long arguments.
This can technically result in a over-read, but it is harmless in this
case. Regardless, fix it to avoid the warning seen under -Warray-bounds,
which we'd like to enable globally:
In file included from ./include/linux/bitmap.h:9,
from ./include/linux/cpumask.h:12,
from ./arch/x86/include/asm/cpumask.h:5,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/processor.h:22,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:60,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:78,
from ./include/linux/spinlock.h:55,
from ./include/linux/wait.h:9,
from ./include/linux/wait_bit.h:8,
from ./include/linux/fs.h:6,
from ./include/linux/debugfs.h:15,
from drivers/bus/mhi/core/init.c:7:
drivers/bus/mhi/core/init.c: In function 'to_mhi_pm_state_str':
./include/linux/find.h:187:37: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'enum mhi_pm_state[1]' [-Warray-bounds]
187 | unsigned long val = *addr & GENMASK(size - 1, 0);
| ^~~~~
drivers/bus/mhi/core/init.c:80:51: note: while referencing 'state'
80 | const char *to_mhi_pm_state_str(enum mhi_pm_state state)
| ~~~~~~~~~~~~~~~~~~^~~~~
Link: https://lore.kernel.org/r/20211215232446.2069794-1-keescook@chromium.org
[mani: changed the variable name "bits" to "pm_state"]
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20211216081227.237749-10-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a new API "mhi_prepare_for_transfer_autoqueue" for using with client
drivers like QRTR to request MHI core to autoqueue buffers for the DL
channel along with starting both UL and DL channels.
So far, the "auto_queue" flag specified by the controller drivers in
channel definition served this purpose but this will be removed at some
point in future.
Cc: netdev@vger.kernel.org
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Co-developed-by: Loic Poulain <loic.poulain@linaro.org>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20211216081227.237749-9-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During SYS_ERR condition, as a response to the MHI_RESET from host, some
devices tend to issue BHI interrupt without clearing the SYS_ERR state in
the device. This creates a race condition and causes a failure in booting
up the device.
The issue is seen on the Sierra Wireless EM9191 modem during SYS_ERR
handling in mhi_async_power_up(). Once the host detects that the device
is in SYS_ERR state, it issues MHI_RESET and waits for the device to
process the reset request. During this time, the device triggers the BHI
interrupt to the host without clearing SYS_ERR condition. So the host
starts handling the SYS_ERR condition again.
To fix this issue, let's register the IRQ handler only after handling the
SYS_ERR check to avoid getting spurious IRQs from the device.
Fixes: e18d4e9fa7 ("bus: mhi: core: Handle syserr during power_up")
Cc: stable@vger.kernel.org
Reported-by: Aleksander Morgado <aleksander@aleksander.es>
Tested-by: Aleksander Morgado <aleksander@aleksander.es>
Tested-by: Thomas Perrot <thomas.perrot@bootlin.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20211216081227.237749-8-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no reason for shutting down MHI ungracefully on freeze,
this causes the MHI host stack & device stack to not be aligned
anymore since the proper MHI reset sequence is not performed for
ungraceful shutdown.
Link: https://lore.kernel.org/r/1635268180-13699-1-git-send-email-loic.poulain@linaro.org
Fixes: 5f0c2ee1fe ("bus: mhi: pci-generic: Fix hibernation")
Cc: stable@vger.kernel.org
Suggested-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20211216081227.237749-3-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add new device ID 0xe0bf for T99W175.
This device ID is created because it is using Qualcomm SDX55 new base line.
Test evidence as below:
root@jbd-ThinkPad-P1-Gen-4:/dev# lspci -nn | grep Foxconn
0000:08:00.0 Wireless controller [0d40]: Foxconn International, Inc. Device [105b:e0bf]
root@jbd-ThinkPad-P1-Gen-4:/dev# cat wwan0at0 & echo -ne "ati\r" > wwan0at0
[2] 2977
root@jbd-ThinkPad-P1-Gen-4:/dev# ati
Manufacturer: Qualcomm
Model: T99W175
Revision: T99W175.F0.6.0.0.6.CC.005 1 [Oct 21 2021 10:00:00]
IMEI:
+GCAP: +CGSM
OK
Link: https://lore.kernel.org/r/20211029104918.3976-1-slark_xiao@163.com
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Slark Xiao <slark_xiao@163.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20211216081227.237749-2-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tag for dmaengine slave_id removal topic branch which should be merged
into v5.17
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAmG8J+UACgkQfBQHDyUj
g0cmEQ/9H5sOft40t02H4tKkdIm8ZvEL4p58+Dzkv09YR7PjGH9pOWoPikzMozNe
aQVIoMs+0QAe9HmaHNOqEgXX3yCswm+PTl9KoULOzMZGMIbw9KxeippVvpqybgtH
flxVPBN/u++WEyPUHRWkr8TCHRzDZjzOQDlHVfOFTl09oNM302Mmz7XasArDwQkI
X3FIpI4mDsWxXOE2hX+A6zqUTqhakV+KBg7a7/JpPnJ558REsvdOxTTRVyW8dQiW
O5EXvrCqus6Ahtu+NIJ3wHjEHcn2pUBeuDRGJgo729f9tBa4ERcZIWSoMXPNLqZm
jbmyoUZIBt6DCTwwd+k35BtreN47dfxY7KIjX3D3qdWDPOBrWsVUIhbEjkzIUqOa
mnEJf6mdDs9z6qCDTYm+Fly7n0bFaOSs94wLWbccxf5PK1ZnS8yI7XcWrA37WRl/
5196CvFoMx4n68QJeyv1PdMEzSMb2aubniOohgfMrPE1HxBdRYcikzoNExiwZeGs
m5oIAQ0bCAu/Jp1c1m/wMN5hE2KSzGQY6L/8h0Jl4ML1jn2x6QGQa6NkHhpVH2AX
5aNF2tOUFNUN8MxunU7eNTE3icpIwhWnW5emfRwrW7sbhPvssbN+O6Pv30TgjA5e
gvtytGO8sXFhRFKoVpMEPI/CYyYz8hxGJKLnLFSvcLYkZN9yvig=
=Mpf8
-----END PGP SIGNATURE-----
Merge tag 'dmaengine_topic_slave_id_removal_5.17' into next
Merge the tag dmaengine_topic_slave_id_removal_5.17 into next. This
brings in the slave_id removal topic changes
'shdma_slave_used' is a bitmap. So use 'bitmap_zalloc()' to simplify code,
improve the semantic and avoid some open-coded arithmetic in allocator
arguments.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/3efaf2784424ae3d7411dc47f8b6b03e7bb8c059.1637702701.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The pointer hwdesc is being initialized with a value that is never
read, it is being updated later in a for-loop. The assignment is
redundant and can be removed.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://lore.kernel.org/r/20211204140032.548066-1-colin.i.king@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add a sysfs knob to allow tuning of retries for the kernel ENQCMDS
descriptor submission. While on host, it is not as likely that ENQCMDS
return busy during normal operations due to the driver controlling the
number of descriptors allocated for submission. However, when the driver is
operating as a guest driver, the chance of retry goes up significantly due
to sharing a wq with multiple VMs. A default value is provided with the
system admin being able to tune the value on a per WQ basis.
Suggested-by: Sanjay Kumar <sanjay.k.kumar@intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/163820629464.2702134.7577370098568297574.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
"make dtbs_check":
Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml: dma-controller@50000000: 'resets' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
The Synopsys DesignWare AXI DMA Controller on the Canaan K210 SoC
exposes its reset signal.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Link: https://lore.kernel.org/r/20211125152008.162571-1-geert@linux-m68k.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
For some devices with only half-duplex capabilities, it doesn't make
much sense to use one DMA channel per direction, as both channels will
never be active at the same time.
Add support for bidirectional I/O on DMA channels. The client drivers
can then request a "tx-rx" DMA channel which will be used for both
directions.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20211206174259.68133-7-paul@crapouillou.net
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The JZ4760 and JZ4760B SoCs have two regular DMA controllers with 6
channels each. They also have an extra DMA controller named MDMA
with only 2 channels, that only supports memcpy operations, and one
named BDMA with only 3 channels, that is mostly used for transfers
between memories and the BCH controller.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20211206174259.68133-5-paul@crapouillou.net
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The JZ4760 SoC has a hardware problem with chan0 not enabling properly
if it's enabled before chan1, after a reset (works fine afterwards).
This is worked around in the probe function by just enabling then
disabling chan1.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20211206174259.68133-4-paul@crapouillou.net
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The JZ4760 and JZ4760B SoCs have two additional DMA controllers: the
MDMA, which only supports memcpy operations, and the BDMA which is
mostly used for transfer between memories and the BCH controller.
The JZ4770 also features the same BDMA as in the JZ4760B, but does not
seem to have a MDMA.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211206174259.68133-2-paul@crapouillou.net
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The TI k3-bcdma and k3-pktdma both use 'ti,sci' and 'ti,sci-dev-id'
properties defined in ti,k3-sci-common.yaml. When 'unevaluatedProperties'
support is enabled, the follow warning is generated:
Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml: dma-controller@485c0100: Unevaluated properties are not allowed ('ti,sci', 'ti,sci-dev-id' were unexpected)
Documentation/devicetree/bindings/dma/ti/k3-pktdma.example.dt.yaml: dma-controller@485c0000: Unevaluated properties are not allowed ('ti,sci', 'ti,sci-dev-id' were unexpected)
Add a reference to ti,k3-sci-common.yaml to fix this.
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20211206174226.2298135-1-robh@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
With 'unevaluatedProperties' support implemented, the example has
warnings on primecell properties and 'resets':
Documentation/devicetree/bindings/dma/arm-pl08x.example.dt.yaml: dma-controller@67000000: Unevaluated properties are not allowed ('arm,primecell-periphid', 'resets' were unexpected)
Add the missing reference to primecell.yaml and definition for 'resets'.
Cc: Vinod Koul <vkoul@kernel.org>
Cc: dmaengine@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20211206174231.2298349-1-robh@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add SYSFW defined rchan_oes_offset number for J721S2 SoC in soc data.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20211119132315.15901-2-a-govindraju@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Make use of the struct_size() helper instead of an open-coded version, in
order to avoid any potential type mistakes or integer overflows that, in
the worst scenario, could lead to heap overflows.
Link: https://github.com/KSPP/linux/issues/160
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20211208001013.GA62330@embeddedor
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Handle errors when trying to map the IRQ for the DMA channels.
The main motivation here is to be able to handle probe deferral. E.g. when
using DT overlays it is possible that the DMA controller is probed before
interrupt controller, depending on the order in the DT.
In order to support this switch from irq_of_parse_and_map() to
of_irq_get(), which internally does the same, but it will return
EPROBE_DEFER when the interrupt controller is not yet available.
As a result other errors, such as an invalid IRQ specification, or missing
IRQ are also properly handled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/20211208114212.234130-1-lars@metafoo.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going
under test needs to be put in suspend state before sending the test
command. Many hubs, don't enforce this precondition and they work fine
without this step. We should follow the specification and put the USB
port in suspend before sending the test command.
Also there are some "special" hubs, which requires to disable the USB
port power instead of putting it in suspend. I found out only three hubs
which requires this step, but if more are found, they can be added to
the list.
Since this changes the default implementation, it raises the posibility
of finding other broken hubs which are not compliant with the spec and
the test command might not work is the port is suspended. If such hubs
are found, a similar workaround like the disable part can be implemented
to skip putting the port in suspend.
Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com>
Link: https://lore.kernel.org/r/20211213183617.14156-2-heghedus.razvan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Export usb_device_match_id so that it can be used for easily matching an
usb_device with a table of IDs.
Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com>
Link: https://lore.kernel.org/r/20211213183617.14156-1-heghedus.razvan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The musb glue drivers just copy the glue resources to the musb child device.
Instead, set the musb child device's DT node pointer to the parent device's
node so that platform_get_irq_byname() can find the resources in the DT.
This removes the need for statically populating the IRQ resources from the
DT which has been deprecated for some time.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211215230756.2009115-3-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The platform device resources are copied by the driver core, so there is
no need for the caller to do it when creating a platform device. Just pass
the parent resources to the child device directly.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211215230756.2009115-2-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver overrides the error codes returned by platform_get_irq() to
-ENXIO for some strange reason. Switch to propagating the error codes
upstream.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/20211214204247.7172-5-s.shtylyov@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver overrides the error codes and IRQ0 returned by platform_get_irq()
to -ENODEV. Switch to propagating the error codes upstream. IRQ0 is no
longer returned by platform_get_irq(), so we now can safely ignore it...
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/20211214204247.7172-4-s.shtylyov@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver overrides the error codes returned by platform_get_irq() to
-ENODEV for some strange reason. Switch to propagating the error codes
upstream.
Acked-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/20211214204247.7172-3-s.shtylyov@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
