| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
For RISC-V platforms we permit assigning addresses from 0 to PCI devices,
both in the memory and the I/O bus space, and we happily do so if there
is no conflict, e.g.:
pci 0000:07:00.0: BAR 0: assigned [io 0x0000-0x0007]
pci 0000:07:00.1: BAR 0: assigned [io 0x0008-0x000f]
pci 0000:06:01.0: PCI bridge to [bus 07]
pci 0000:06:01.0: bridge window [io 0x0000-0x0fff]
(with the SiFive HiFive Unmatched RISC-V board and a dual serial port
option card based on the OxSemi OXPCIe952 device wired for the legacy
UART mode).
Address 0 is treated specially however in many places, for example in
`pci_iomap_range' and `pci_iomap_wc_range' we require that the start
address is non-zero, and even if we let such an address through, then
individual device drivers could reject a request to handle a device at
such an address, such as in `uart_configure_port'. Consequently given
devices configured as shown above only one is actually usable:
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial 0000:07:00.0: enabling device (0000 -> 0001)
serial: probe of 0000:07:00.0 failed with error -12
serial 0000:07:00.1: enabling device (0000 -> 0001)
serial 0000:07:00.1: detected caps 00000700 should be 00000500
0000:07:00.1: ttyS0 at I/O 0x8 (irq = 39, base_baud = 15625000) is a 16C950/954
Therefore avoid handing out address 0, by bumping the lowest address
available to PCI via PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM up by 4 and 16
respectively, which is the minimum allocation size for I/O and memory
BARs.
With this in place the system in question we have:
pci 0000:07:00.0: BAR 0: assigned [io 0x1000-0x1007]
pci 0000:07:00.1: BAR 0: assigned [io 0x1008-0x100f]
pci 0000:06:01.0: PCI bridge to [bus 07]
pci 0000:06:01.0: bridge window [io 0x1000-0x1fff]
and then devices work correctly:
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial 0000:07:00.0: enabling device (0000 -> 0001)
serial 0000:07:00.0: detected caps 00000700 should be 00000500
0000:07:00.0: ttyS0 at I/O 0x1000 (irq = 38, base_baud = 15625000) is a 16C950/954
serial 0000:07:00.1: enabling device (0000 -> 0001)
serial 0000:07:00.1: detected caps 00000700 should be 00000500
0000:07:00.1: ttyS1 at I/O 0x1008 (irq = 39, base_baud = 15625000) is a 16C950/954
Especially I/O space ranges are particularly valuable, because bridges
only decode bits from 12 up and consequently where 16-bit addressing is
in effect, as few as 16 separate ranges can be assigned to individual
buses only, however a generic change to avoid handing out address 0 only
has turned out controversial as per the discussion referred via the link
below.
Conversely sorting this out in platform code has been standard practice
since forever to avoid a clash with legacy devices subtractively decoded
by the southbridge where present. This can be revised should a generic
solution be adopted sometime.
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2202260044180.25061@angie.orcam.me.uk
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
|
Merge series from Judy Hsiao <judyhsiao@chromium.org>:
The patches series is to fix the unexpected large DC output
voltage of Max98357a that burns the speakers on the rockchip
platform when BCLK and SD_MODE are ON but LRCLK is OFF.
|
|
Merge series from Tinghan Shen <tinghan.shen@mediatek.com>:
Some updates to the DT bindings to make things less surprising for
users.
|
|
Cinterion MV31-W modem with a new baseline (firmware) is sold as a separate
product with different device ID. So add support for the same reusing the
config.
Signed-off-by: Slark Xiao <slark_xiao@163.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/20220622032544.17713-1-slark_xiao@163.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
|
coresight devices track their connections (output connections) and
hold a reference to the fwnode. When a device goes away, we walk through
the devices on the coresight bus and make sure that the references
are dropped. This happens both ways:
a) For all output connections from the device, drop the reference to
the target device via coresight_release_platform_data()
b) Iterate over all the devices on the coresight bus and drop the
reference to fwnode if *this* device is the target of the output
connection, via coresight_remove_conns()->coresight_remove_match().
However, the coresight_remove_match() doesn't clear the fwnode field,
after dropping the reference, this causes use-after-free and
additional refcount drops on the fwnode.
e.g., if we have two devices, A and B, with a connection, A -> B.
If we remove B first, B would clear the reference on B, from A
via coresight_remove_match(). But when A is removed, it still has
a connection with fwnode still pointing to B. Thus it tries to drops
the reference in coresight_release_platform_data(), raising the bells
like :
[ 91.990153] ------------[ cut here ]------------
[ 91.990163] refcount_t: addition on 0; use-after-free.
[ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144
[ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-)
crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug]
[ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53
[ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019
[ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 91.990454] pc : refcount_warn_saturate+0xa0/0x144
[ 91.990476] lr : refcount_warn_saturate+0xa0/0x144
[ 91.990496] sp : ffff80000c843640
[ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8
[ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8
[ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2
[ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40
[ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0
[ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375
[ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28
[ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572
[ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027
[ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00
[ 91.991000] Call trace:
[ 91.991012] refcount_warn_saturate+0xa0/0x144
[ 91.991034] kobject_get+0xac/0xb0
[ 91.991055] of_node_get+0x2c/0x40
[ 91.991076] of_fwnode_get+0x40/0x60
[ 91.991094] fwnode_handle_get+0x3c/0x60
[ 91.991116] fwnode_get_nth_parent+0xf4/0x110
[ 91.991137] fwnode_full_name_string+0x48/0xc0
[ 91.991158] device_node_string+0x41c/0x530
[ 91.991178] pointer+0x320/0x3ec
[ 91.991198] vsnprintf+0x23c/0x750
[ 91.991217] vprintk_store+0x104/0x4b0
[ 91.991238] vprintk_emit+0x8c/0x360
[ 91.991257] vprintk_default+0x44/0x50
[ 91.991276] vprintk+0xcc/0xf0
[ 91.991295] _printk+0x68/0x90
[ 91.991315] of_node_release+0x13c/0x14c
[ 91.991334] kobject_put+0x98/0x114
[ 91.991354] of_node_put+0x24/0x34
[ 91.991372] of_fwnode_put+0x40/0x5c
[ 91.991390] fwnode_handle_put+0x38/0x50
[ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight]
[ 91.991472] coresight_unregister+0x64/0xcc [coresight]
[ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x]
[ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x]
[ 91.991598] amba_remove+0x3c/0x19c
Reproducible by: (Build all coresight components as modules):
#!/bin/sh
while true
do
for m in tmc stm cpu_debug etm4x replicator funnel
do
modprobe coresight_${m}
done
for m in tmc stm cpu_debug etm4x replicator funnel
do
rmmode coresight_${m}
done
done
Cc: stable@vger.kernel.org
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Fixes: 37ea1ffddffa ("coresight: Use fwnode handle instead of device names")
Link: https://lore.kernel.org/r/20220614214024.3005275-1-suzuki.poulose@arm.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
This commit adds dt-binding documentation for the MediaTek MT8186
reference board.
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220520122217.30716-3-allen-kh.cheng@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add mt8186 pericfg compatible to binding document.
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220520122217.30716-2-allen-kh.cheng@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add the maintenance interrupt for GIC-400.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-11-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add a node for the pinctrl controller found on MT6795 but without
configuration for any pin, as that's expected to be done in the
machine-specific devicetrees.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-10-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
This SoC features an ARM CCI-400 IP: add the required node and
assign the cci control ports to the CPU cores.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-9-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add the timer node, enabling two GPTs, of which one will be used as
sched_clock.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-8-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Remove the RTC and UART fixed clocks, as these were introduced to
temporarily provide a dummy clock to devices: since the two 26M/32K
fixed oscillators clocks (which do really exist in the SoC) have
been added, there's no reason to keep the aforementioned (and now
redundant) dummies in this devicetree.
In order to remove the uart dummy clock, it was necessary to also
reassign the clock of all UART nodes to clk26m.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-7-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add the 32kHz and 26MHz oscillators as fixed clocks in devicetree to
provide a good initial clock spec, since this SoC features two always
on oscillators running at the aforementioned frequencies.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-6-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
At least on commercial devices like some smartphones, the bootloader
will initialize the SoC watchdog and set it to reboot the board when
it times out. The last pet that this watchdog is getting is right
before booting the kernel and left it enabled as a protection against
boot failure: this means that Linux is expected to initialize this
device and pet as soon as possible, or it will bark and reset the AP.
In order to prevent that, add the required watchdog node as default
enabled: this will have no side effects on boards that are not
performing the aforementioned watchdog setup before booting Linux.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add the required nodes to enable the PMU on this SoC.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
This SoC is HMP and has two clusters with four Cortex-A53 cores each:
declare a cpu map and, while at it, also add the next-level-cache
properties.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
MMIO devices should be inside of a soc bus node, as it's done for the
vast majority of ARM64 devicetrees, and for almost all MTK devicetrees.
Create a simple-bus soc node and move all devices with a MMIO address
space in there.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220609112303.117928-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Fixes headset detection on Clevo NS50PU.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220622150017.9897-1-tcrawford@system76.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Consider '*' alignment in comments
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Added return statement in sun4i_layer_format_mod_supported()
in case frontend is not present.
Signed-off-by: Saud Farooqui <farooqui_saud@hotmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/PA4P189MB1421E93EF5F8E8E00E71B7878BB29@PA4P189MB1421.EURP189.PROD.OUTLOOK.COM
|
|
The vc4_check_tex_size() function is supposed to return false on error
but this error path accidentally returns -ENODEV (which means true).
Fixes: 30f8c74ca9b7 ("drm/vc4: Warn if some v3d code is run on BCM2711")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/YrMKK89/viQiaiAg@kili
|
|
gpio-keys (regular, not polling) does not use "poll-interval" property.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220617232124.7022-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The IOMMU driver now looks for the "mediatek,infracfg" phandle as a
new way to retrieve a syscon to that:
even though the old way is retained, it has been deprecated and the
driver will write a message in kmsg advertising to use the phandle
way instead.
For this reason, assign the right phandle to mediatek,infracfg in
the iommu node.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220616110830.26037-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The IOMMU driver now looks for the "mediatek,infracfg" phandle as a
new way to retrieve a syscon to that:
even though the old way is retained, it has been deprecated and the
driver will write a message in kmsg advertising to use the phandle
way instead.
For this reason, assign the right phandle to mediatek,infracfg in
the iommu node.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220616110830.26037-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Use the fixed "efuse" name for efuse nodes according to its yaml file
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/20220617093132.22578-4-chunfeng.yun@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Need also provide a specific compatible "mediatek,mt8192-efuse" at
the same time when use the generic compatible "mediatek,efuse".
Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/20220617093132.22578-3-chunfeng.yun@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
The entry-method property of the idle-states node should be "psci" as
described in the idle-states binding, since this is already the value of
enable-method in the CPU nodes. Fix it to get rid of a dtbs_check
warning.
Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220617233150.2466344-3-nfraprado@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Tweak the name of the idle-states subnodes so that they follow the
binding pattern, getting rid of dtbs_check warnings.
Only the usage of "-" in the name was necessary, but "off" was also
exchanged for "sleep" since that seems to be a more common wording in
other dts files.
Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220617233150.2466344-2-nfraprado@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Fix a number of compile errors by including the correct header
files. Examples are shown below.
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_blit_to_vram_rect':
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:25:48: error: invalid use of undefined type 'struct drm_framebuffer'
25 | struct hyperv_drm_device *hv = to_hv(fb->dev);
| ^~
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_connector_get_modes':
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:59:17: error: implicit declaration of function 'drm_add_modes_noedid' [-Werror=implicit-function-declaration]
59 | count = drm_add_modes_noedid(connector,
| ^~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:62:9: error: implicit declaration of function 'drm_set_preferred_mode'; did you mean 'drm_mm_reserve_node'? [-Werror=implicit-function-declaration]
62 | drm_set_preferred_mode(connector, hv->preferred_width,
| ^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device")
Fixes: 720cf96d8fec ("drm: Drop drm_framebuffer.h from drm_crtc.h")
Fixes: 255490f9150d ("drm: Drop drm_edid.h from drm_crtc.h")
Cc: Deepak Rawat <drawat.floss@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: linux-hyperv@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.14+
Acked-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220622083413.12573-1-tzimmermann@suse.de
|
|
In commit
4e8988c634a1 ("soc: mediatek: add DDP_DOMPONENT_DITHER0 enum for mt8195 vdosys0")
the enum mtk_ddp_comp_id was modified to add an index number to the
DITHER component because some new SoCs have multiple dither blocks.
As a result, all of the mutex mod arrays have been changed to use the
new definition instead of the old one (even if that's retained): for
consistency purposes, follow the same trend on the newly introduced
MT8365 mutex mod array.
This commit brings no functional changes.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220620102454.131417-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add support for PWM on MT8365.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
As explained in Documentation/devicetree/bindings/mmc/mmc-controller.yaml,
the 'enable-sdio-wakeup' property is considered deprecated.
Replace it with the 'wakeup-source' property instead.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20220621124435.121740-1-festevam@gmail.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
|
|
Add binding documentation for the MT8365 SoC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Fix compatible string for R-Car Gen4.
Fixes: ae684caf465b ("iommu/ipmmu-vmsa: Add support for R-Car Gen4")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20220617010107.3229784-1-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
This driver will get support for more SoCs and the list of infracfg
compatibles is expected to grow: in order to prevent getting this
situation out of control and see a long list of compatible strings,
add support to retrieve a handle to infracfg's regmap through a
new "mediatek,infracfg" phandle.
In order to keep retrocompatibility with older devicetrees, the old
way is kept in place.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Reviewed-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20220616110830.26037-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Add property "mediatek,infracfg" to let the mtk_iommu driver retrieve
a phandle to the infracfg syscon instead of performing a per-soc
compatible lookup in the entire devicetree and set it as a required
property for MT2712 and MT8173.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20220616110830.26037-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
When many devices share the same iova domain, iommu_dma_init_domain()
may be called at the same time. The checking of iovad->start_pfn will
all get false in iommu_dma_init_domain() and both enter init_iova_domain()
to do iovad initialization.
Fix this by protecting init_iova_domain() with iommu_dma_cookie->mutex.
Exception backtrace:
rb_insert_color(param1=0xFFFFFF80CD2BDB40, param3=1) + 64
init_iova_domain() + 180
iommu_setup_dma_ops() + 260
arch_setup_dma_ops() + 132
of_dma_configure_id() + 468
platform_dma_configure() + 32
really_probe() + 1168
driver_probe_device() + 268
__device_attach_driver() + 524
__device_attach() + 524
bus_probe_device() + 64
deferred_probe_work_func() + 260
process_one_work() + 580
worker_thread() + 1076
kthread() + 332
ret_from_fork() + 16
Signed-off-by: Ning Li <ning.li@mediatek.com>
Signed-off-by: Yunfei Wang <yf.wang@mediatek.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Miles Chen <miles.chen@mediatek.com>
Link: https://lore.kernel.org/r/20220530120748.31733-1-yf.wang@mediatek.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
The declaration was necessary until commit cc2d22477779 ("pwm: Drop
per-chip dbg_show callback").
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
There is no cyclic dependency, so by reordering the forward declaration
can be dropped.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Spelling mistake (triple letters) in comment. Detected with the help of
Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
There are no drivers left providing the legacy callbacks. So drop
support for these.
If this commit breaks your out-of-tree pwm driver, look at e.g. commit
ec00cd5e63f0 ("pwm: renesas-tpu: Implement .apply() callback") for an
example of the needed conversion for your driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Pull 9pfs fixes from Dominique Martinet:
"A couple of fid refcount and fscache fixes:
- fid refcounting was incorrect in some corner cases and would leak
resources, only freed at umount time. The first three commits fix
three such cases
- 'cache=loose' or fscache was broken when trying to write a partial
page to a file with no read permission since the rework a few
releases ago.
The fix taken here is just to restore old behavior of using the
special 'writeback_fid' for such reads, which is open as root/RDWR
and such not get complains that we try to read on a WRONLY fid.
Long-term it'd be nice to get rid of this and not issue the read at
all (skip cache?) in such cases, but that direction hasn't
progressed"
* tag '9p-for-5.19-rc4' of https://github.com/martinetd/linux:
9p: fix EBADF errors in cached mode
9p: Fix refcounting during full path walks for fid lookups
9p: fix fid refcount leak in v9fs_vfs_get_link
9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl
|
|
For devices stuck behind a conventional PCI bus, saving extra cycles at
33MHz is probably fairly significant. However since native PCI Express
is now the norm for high-performance devices, the optimisation to always
prefer 32-bit addresses for the sake of avoiding DAC is starting to look
rather anachronistic. Technically 32-bit addresses do have shorter TLPs
on PCIe, but unless the device is saturating its link bandwidth with
small transfers it seems unlikely that the difference is appreciable.
What definitely is appreciable, however, is that the IOVA allocator
doesn't behave all that well once the 32-bit space starts getting full.
As DMA working sets get bigger, this optimisation increasingly backfires
and adds considerable overhead to the dma_map path for use-cases like
high-bandwidth networking. We've increasingly bandaged the allocator
in attempts to mitigate this, but it remains fundamentally at odds with
other valid requirements to try as hard as possible to satisfy a request
within the given limit; what we really need is to just avoid this odd
notion of a speculative allocation when it isn't beneficial anyway.
Unfortunately that's where things get awkward... Having been present on
x86 for 15 years or so now, it turns out there are systems which fail to
properly define the upper limit of usable IOVA space for certain devices
and this trick was the only thing letting them work OK. I had a similar
ulterior motive for a couple of early arm64 systems when originally
adding it to iommu-dma, but those really should be fixed with proper
firmware bindings by now. Let's be brave and default it to off in the
hope that CI systems and developers will find and fix those bugs, but
expect that desktop-focused distro configs are likely to want to turn
it back on for maximum compatibility.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/3f06994f9f370f9d35b2630ab75171ecd2065621.1654782107.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Use ida_alloc()/ida_free() instead of deprecated
ida_simple_get()/ida_simple_remove().
Signed-off-by: Ke Liu <liuke94@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://lore.kernel.org/r/20220608021655.1538087-1-liuke94@huawei.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Commit 44f362c2cc6d ("ASoC: rockchip: i2s: switch BCLK to GPIO") added
pinctrl lookups, but did not skip the lookup if there was no pinctrl
device tied to the I2S controller. As a result, the lookup was done
on an invalid pointer in such cases, causing a kernel panic.
Only do the subsequent pinctrl state lookups and switch if a pinctrl
device was found.
i2s_pinctrl_select_bclk_{on,off} already guard against missing pinctrl
device or pinctrl state, so those two functions aren't touched.
Fixes: 44f362c2cc6d ("ASoC: rockchip: i2s: switch BCLK to GPIO")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20220621185747.2782-1-wens@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Even in the presence of problems (here: rn_acp_deinit() might fail), it's
important to unregister all resources acquired during .probe() because
even if .remove() returns an error code, the device is removed.
As .remove() is only called after .probe() returned success, platdata
must be valid, so the first check in .remove() can just be dropped.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220622061739.225966-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The function snd_soc_unregister_card() returned 0 unconditionally and most
callers don't care to check the return value. Make it return void and
adapt the callers that didn't ignore the return value before.
This is a preparation for making platform remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220621145834.198519-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Align clock names in mt8186 dsp driver with dt-bindings.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Link: https://lore.kernel.org/r/20220622062245.21021-5-tinghan.shen@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch adds mt8186 dsp document. The dsp is used for Sound Open
Firmware driver node. It includes registers, clocks, memory regions,
and mailbox for dsp.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220622062245.21021-4-tinghan.shen@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
Maciej W. Rozycki
Mark Brown
Slark Xiao
Suzuki K Poulose
Allen-KH Cheng
AngeloGioacchino Del Regno
Tim Crawford
Jiang Jian
Saud Farooqui
Dan Carpenter
Krzysztof Kozlowski
Chunfeng Yun
Nícolas F. R. A. Prado
Thomas Zimmermann
Fabien Parent
Fabio Estevam
Yoshihiro Shimoda
Yunfei Wang
Uwe Kleine-König
Julia Lawall
Linus Torvalds
Robin Murphy
Ke Liu
Chen-Yu Tsai
Tinghan Shen