Remove unnecessary register OTP_Ver and change the device ID address to
0x1. Previous version chip is never mass production. So not broken
compatibility.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Link: https://patch.msgid.link/20251103-b4-next-pf9453-v1-1-a025d536eee1@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It's a little bit cleaner to just pass "aw88261" instead of the address
of it "&aw88261".
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aQYKxl2f-zGVdYFC@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Just pass "aw87390" instead of the address of it. It's a bit simpler.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aQYKuQuKekmoUrHP@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
The two virtual multiplexers are now part of the alsa routing.
The "DMIC M1 Mux" now sits between the primary digital mics
"DMICL"/"DMICR" and the virtual multiplexer "DMIC Mux". And
"DMIC M2 Mux" sits between the secondary digital mics
"DMIC2L"/"DMIC2R" and the audio out interfaces
"AIFOUT2L"/"AIFOUT2R". This patch makes sure that the M1 and
M2 mics can be switched On/Off independently, by default both
will be enabled.
Signed-off-by: Sharique Mohammad <sharq0406@gmail.com>
Link: https://patch.msgid.link/20251103091648.771947-1-sharq0406@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
'struct fsl_spdif_soc_data' and 'struct snd_kcontrol_new' are not modified
in this driver.
Constifying these structures moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
53548 25576 128 79252 13594 sound/soc/fsl/fsl_spdif.o
After:
=====
text data bss dec hex filename
54828 24296 128 79252 13594 sound/soc/fsl/fsl_spdif.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/5fe08f028395a6c6f50d11eee8fdb4a90b1f68ab.1762151503.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
The two digital mics M1(primary digital mic) and M2(secondary digital
mic) work independently of one another. It means they could be switched
On or Off independently of one another. To control their On or Off
state, with this patch creating two virtual multiplexer widgets
"DMIC M1 Mux" and "DMIC M2 Mux", with two options "Enable" and "Disable".
Signed-off-by: Sharique Mohammad <sharq0406@gmail.com>
Link: https://patch.msgid.link/20251103091447.771793-1-sharq0406@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Update the text for firmware file naming to show that the l?u? suffix is
supported on CS35L56 B0 silicon and ampN was only used on early firmware.
The previous version of this text only said that B0 silicon used the ampN
suffix. Since kernel 6.16 the driver supports both the old ampN and
new l?u? suffix for B0 silicon. New firmwares will use the l?u? suffix.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251103115809.33953-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They
both are of the same data and overrides each other. This resulted in the
rmmod of the svc driver to fail and throw a kernel panic for kthread_stop
and fifo free.
Fixes: b5dc75c915 ("firmware: stratix10-svc: extend svc to support new RSU features")
Cc: stable@vger.kernel.org # 6.6+
Signed-off-by: Ang Tien Sung <tiensung.ang@altera.com>
Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
The correct sequence for bridge initialization is:
1. devm_drm_bridge_alloc()
2. drm_bridge_add()
3. drm_bridge_attach()
For bridges missing either 1 or 2 there are warnings in place already,
presenting an explanatory error message.
Bridges missing both 1 and 2 would still face a poorly understandable
message, as reported in a recent regression report [0]:
WARNING: [...] at [...]/lib/refcount.c:25 drm_bridge_attach+0x2c/0x1dc
...
Call trace:
...
drm_bridge_attach
...
Add a new warning to ensure an understandable message is logged in such
cases. Use the same message and warning message already in place in
drm_bridge_add().
[0] https://lore.kernel.org/all/hlf4wdopapxnh4rekl5s3kvoi6egaga3lrjfbx6r223ar3txri@3ik53xw5idyh/
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-5-bb8611acbbfb@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
DRM bridges must be added before they are attached. Add a warning to catch
violations.
The warning is based on the bridge not being part of any list, so it will
trigger if the bridge is being attached without ever having been added.
It won't catch cases of bridges attached after having been added and then
removed, because in that case the bridge will be in
bridge_lingering_list. However such a case is both more demanding to detect
and less likely to happen, so it can be left unchecked, at least for now.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/all/20250709-sophisticated-loon-of-rain-6ccdd8@houat/
Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251028-b4-drm-bridge-alloc-add-before-attach-v3-4-bb8611acbbfb@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Recent AMD node rework removed the "search and count" method of caching AMD
root devices. This depended on the value from a Data Fabric register that was
expected to hold the PCI bus of one of the root devices attached to that
fabric.
However, this expectation is incorrect. The register, when read from PCI
config space, returns the bitwise-OR of the buses of all attached root
devices.
This behavior is benign on AMD reference design boards, since the bus numbers
are aligned. This results in a bitwise-OR value matching one of the buses. For
example, 0x00 | 0x40 | 0xA0 | 0xE0 = 0xE0.
This behavior breaks on boards where the bus numbers are not exactly aligned.
For example, 0x00 | 0x07 | 0xE0 | 0x15 = 0x1F.
The examples above are for AMD node 0. The first root device on other nodes
will not be 0x00. The first root device for other nodes will depend on the
total number of root devices, the system topology, and the specific PCI bus
number assignment.
For example, a system with 2 AMD nodes could have this:
Node 0 : 0x00 0x07 0x0e 0x15
Node 1 : 0x1c 0x23 0x2a 0x31
The bus numbering style in the reference boards is not a requirement. The
numbering found in other boards is not incorrect. Therefore, the root device
caching method needs to be adjusted.
Go back to the "search and count" method used before the recent rework.
Search for root devices using PCI class code rather than fixed PCI IDs.
This keeps the goal of the rework (remove dependency on PCI IDs) while being
able to support various board designs.
Merge helper functions to reduce code duplication.
[ bp: Reflow comment. ]
Fixes: 40a5f6ffdf ("x86/amd_nb: Simplify root device search")
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/all/20251028-fix-amd-root-v2-1-843e38f8be2c@amd.com
The panel_bridge pointer is taken inside the loop and used after the
loop. Being a local variable, use a cleanup action to ensure it is put on
return.
Based on the code structure the panel_bridge pointer might be assigned
during multiple loop iterations. Even though this is probably not possible
in the practice, ensure there is no reference leak by putting the reference
to the old value before overwriting with the new value.
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-3-667abf6d47c0@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
drm_bridge_connector_init() takes eight pointers to various bridges, some
of which can be identical, and stores them in pointers inside struct
drm_bridge_connector. Get a reference to each of the taken bridges and put
it on cleanup.
Achieve this by adding a drmm cleanup callback whic puts all the non-NULL
bridges. Using drmm ensures the cleanup happens on drm_device teardown,
whichever is the return value of this function.
Four of these pointers (edid, hpd, detect and modes) can be written
multiple times (up to once per loop iterations), in order to eventually
store the last matching bridge. So when one of those pointers is
overwritten, we need to put the reference that we got during the previous
assignment. Add a drm_bridge_put() before writing them to handle this.
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-2-667abf6d47c0@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This reverts commit 2be300f9a0.
The commit being reverted moved all the bridge_connector->bridge_*
assignments to just before the final successful return in order to handle
the bridge refcounting in a clean way.
This introduced a bug, because a bit before the successful return
drmm_connector_hdmi_cec_register() is called, which calls funcs->init()
which is drm_bridge_connector_hdmi_cec_init() which needs
bridge_connector->bridge_hdmi_cec to be set.
The reported bug may be fixed in a relatively simple way, but other similar
patterns are potentially present, so just revert the offending commit. A
different approach will be implemented.
Fixes: 2be300f9a0 ("drm/display: bridge_connector: get/put the stored bridges")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Closes: https://lore.kernel.org/all/336fbfdd-c424-490e-b5d1-8ee84043dc80@samsung.com/
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Closes: https://lore.kernel.org/r/CA+G9fYuKHp3QgPKjgFY3TfkDdh5Vf=Ae5pCW+eU41Bu=D7th2g@mail.gmail.com
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> # db410c
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20251017-drm-bridge-alloc-getput-bridge-connector-fix-hdmi_cec-v2-1-667abf6d47c0@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Update leftover reference to Thunderbolt firmware upgrade site
(thunderbolttechnology.net) with the preferred method described in
Documentation/admin-guide/thunderbolt.rst.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Update guide about firmware upgrade of Thunderbolt devices, replacing
outdated recommendations with the use of modern "fwupd" tool.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The $id for a binding should match its file path. The ti,twl4030-gpio
binding is located in the gpio/ subdirectory but was missing this from
its $id.
Correct the path to follow the standard convention.
Fixes: 842dcff8e2 ("dt-bindings: gpio: Convert ti,twl4030-gpio to DT schema")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
Fixes: 842dcff8e2 ("dt-bindings: gpio: Convert ti,twl4030-gpio to DT schema")
Link: https://lore.kernel.org/r/20250821194710.16043-1-jihed.chaibi.dev@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Correct most kernel-doc warnings in include/linux/mtd/spear_smi.h
by adding a leading '@' to the description of struct members.
Add a new description for the missing @np member.
Warning: spear_smi.h:48 struct member 'name' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'mem_base' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'size' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'partitions' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'nr_partitions' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:48 struct member 'fast_mode' not described
in 'spear_smi_flash_info'
Warning: spear_smi.h:62 struct member 'clk_rate' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'num_flashes' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'board_flash_info' not described
in 'spear_smi_plat_data'
Warning: spear_smi.h:62 struct member 'np' not described
in 'spear_smi_plat_data'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
The driver has never supported anything but OF probing so drop the
unused platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Martin Kepplinger-Novakovic <martink@posteo.de>
Link: https://patch.msgid.link/20251017060051.8204-3-johan@kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The driver has never supported anything but OF probing so drop the
unused platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20251017060051.8204-2-johan@kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The driver does not support anything but OF probe since commit
f0e7cfbb43 ("media: imx: imx7_mipi_csis: Add i.MX8MM support") so
drop the unused platform module alias.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20251017060051.8204-1-johan@kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The ISI module on i.MX91 implements only one channel and one parallel
camera input. As no input source selection is required, gasket ops are
unnecessary.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20250905-isi_imx93-v2-5-37db5f768c57@nxp.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Sort platform data in the order of compatible strings in of_match table
to make it more convenient to read.
No functions changed.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20250905-isi_imx93-v2-4-37db5f768c57@nxp.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The ISI module on i.MX93 implements one camera input which can be
connected to either of MIPI CSI-2 or parallel camera. The source
type can be selected by setting camera mux control register.
Signed-off-by: Alice Yuan <alice.yuan@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20250905-isi_imx93-v2-3-37db5f768c57@nxp.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Make code more readable and easier to maintain by using the FIELD_PREP
and GENMASK() macros.
While at it, replace spaces with tabs for macro indentation.
No functional changes.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
Link: https://patch.msgid.link/20250905-isi_imx93-v2-2-37db5f768c57@nxp.com
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The ISI module on i.MX91 is reused from i.MX93 and implements one channel
and one camera input which only can be connected to parallel camera input.
So needn't to select camera source like i.MX93 in gasket ops.
Signed-off-by: Alice Yuan <alice.yuan@nxp.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20250905-isi_imx93-v2-1-37db5f768c57@nxp.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
On the rkisp1 (in my case on a NXP i.MX8 M Plus) the ISP interrupt
handler is sometimes called with RKISP1_CIF_ISP_V_START (start of frame)
and RKISP1_CIF_ISP_FRAME (end of frame) being set at the same time. In
commit 8524fa22fd ("media: staging: rkisp1: isp: add a warning and
debugfs var for irq delay") a warning was added for that. There are two
cases where this condition can occur:
1. The v-sync and the frame-end belong to the same frame. This means,
the irq was heavily delayed and the warning is likely appropriate.
2. The v-sync belongs to the next frame. This can happen if the vertical
blanking between two frames is very short.
The current code always handles case 1 although case 2 is in my
experience the more common case and happens in regular usage. This leads
to incorrect sequence numbers on stats and params buffers which in turn
breaks the regulation in user space. Fix that by adding a frame_active
flag to distinguish between these cases and handle the start of frame
either at the beginning or at the end of the rkisp1_isp_isr().
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Link: https://patch.msgid.link/20250922182003.3712101-2-stefan.klug@ideasonboard.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Frank has been reviewing NXP media drivers for a while, and is
volunteering to continue. Add him as a reviewer for the IMX media
drivers.
Also add the NXP i.MX platform mailing list (imx@lists.linux.dev).
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20250904161720.514889-1-Frank.Li@nxp.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
- Unsupported APIs cleanup
- New sniffer API
- small bugfixes and features
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQM3A3Pv7vbm9vtjWbacY7uyt+OfQUCaQDS5gAKCRDacY7uyt+O
fapgAQD0w9ktKj7jsmvIQui5i2lE0FctQss8JydTXfJIw7qt4gD9EXpE+SgVLfDV
qzZPYWs1YEqOGHITTuzYFKfm3FFxMgg=
=SR81
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-2025-10-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Miri Korenblit says:
====================
iwlwifi features. Notably:
- Unsupported APIs cleanup
- New sniffer API
- small bugfixes and features
====================
Link: https://patch.msgid.link/DM3PPF63A6024A9B77EE7385B4C865E3E54A3FDA@DM3PPF63A6024A9.namprd11.prod.outlook.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This was supposed to pass "onenand" instead of "&onenand" with the
ampersand. Passing a random stack address which will be gone when the
function ends makes no sense. However the good thing is that the pointer
is never used, so this doesn't cause a problem at run time.
Fixes: e23abf4b77 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
According to datasheet (http://eng.fmsh.com/nvm/FM25S01A_ds_eng.pdf)
there is no QE (Quad Enable) bit for FM25S01A flash, so remove it.
Fixes: 5f284dc15c ("mtd: spinand: add support for FudanMicro FM25S01A")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Tested-by: Tianling Shen <cnsztl@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
cpu-clock usage by the async-profiler tool can trigger a system hang,
which got bisected back to the following commit by Octavia Togami:
18dbcbfabf ("perf: Fix the POLL_HUP delivery breakage") causes this issue
The root cause of the hang is that cpu-clock is a special type of SW
event which relies on hrtimers. The __perf_event_overflow() callback
is invoked from the hrtimer handler for cpu-clock events, and
__perf_event_overflow() tries to call cpu_clock_event_stop()
to stop the event, which calls htimer_cancel() to cancel the hrtimer.
But that's a recursion into the hrtimer code from a hrtimer handler,
which (unsurprisingly) deadlocks.
To fix this bug, use hrtimer_try_to_cancel() instead, and set
the PERF_HES_STOPPED flag, which causes perf_swevent_hrtimer()
to stop the event once it sees the PERF_HES_STOPPED flag.
[ mingo: Fixed the comments and improved the changelog. ]
Closes: https://lore.kernel.org/all/CAHPNGSQpXEopYreir+uDDEbtXTBvBvi8c6fYXJvceqtgTPao3Q@mail.gmail.com/
Fixes: 18dbcbfabf ("perf: Fix the POLL_HUP delivery breakage")
Reported-by: Octavia Togami <octavia.togami@gmail.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Octavia Togami <octavia.togami@gmail.com>
Cc: stable@vger.kernel.org
Link: https://github.com/lucko/spark/issues/530
Link: https://patch.msgid.link/20251015051828.12809-1-dapeng1.mi@linux.intel.com
Start using display parent interface for i915 runtime pm. Doing the same
for xe is done in coming changes.
v3:
- remove useless include
v2:
- use <> when including drm/intel/display_parent_interface.h
- drop checks for validity of rpm function pointers
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-6-jouni.hogander@intel.com
Implement runtime pm wrappers for xe driver and add them into display
parent interface.
v3:
- drop useless include
- drop xe_display_rpm_{get, put}_raw
v2:
- move xe_display_rpm_interface code into xe_display_rpm.c
- rename xe_rpm as xe_display_rpm
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-5-jouni.hogander@intel.com
We have differing implementations for display runtime pm in i915 and xe
drivers. Add struct of function pointers into display_parent_interface
which will contain used implementation of runtime pm.
v2:
- add _interface suffix to rpm function pointer struct
- add struct ref_tracker forward declaration
- use kernel-doc comments
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-3-jouni.hogander@intel.com
Let's gradually start calling i915 and xe parent, or core, drivers from
display via function pointers passed at display probe.
Going forward, the struct intel_display_parent_interface is expected to
include const pointers to sub-structs by functionality, for example:
struct intel_display_rpm {
struct ref_tracker *(*get)(struct drm_device *drm);
/* ... */
};
struct intel_display_parent_interface {
/* ... */
const struct intel_display_rpm *rpm;
};
This is a baby step towards not building display as part of both i915
and xe drivers, but rather making it an independent driver interfacing
with the two.
v3: useless include additions dropped
v2: unrelated include removal dropped
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-2-jouni.hogander@intel.com
J784S4 SoC has two instances of PCIe which are PCIe0 and PCIe1. J784S4
SoC uses PCIe1 instance for PCIe boot process. To configure PCIe1 at
all boot stages "pcie1_ctrl" also needs to be present at all boot
stages. Thus add the "bootph-all" boot phase tag to "pcie1_ctrl" device
tree node.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Link: https://patch.msgid.link/20251017084654.2929945-4-h-salunke@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 SoC has two instances of PCIe which are PCIe0 and PCIe1. PCIe1
instance is used for PCIe boot process. J784S4 SoC has four instances
of 4-lane SERDES. Out of which SERDES0 is used as PHY for PCIe1. So it
needs to be functional at all stages of PCIe boot process. Thus add the
"bootph-all" boot phase tag to nodes required to enable SERDES0 at all
boot stages.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Link: https://patch.msgid.link/20251017084654.2929945-3-h-salunke@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 SoC has two instances of PCIe which are PCIe0 and PCIe1. J784S4
SoC uses PCIe1 instance for PCIe boot process. So it needs to be in
endpoint mode and it needs to be functional at all stages of PCIe boot
process. Thus add the "bootph-all" boot phase tag to "pcie1_ep" device
tree node.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Link: https://patch.msgid.link/20251017084654.2929945-2-h-salunke@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Convert 9p to the new mount API. This patch consolidates all parsing
into fs/9p/v9fs.c, which stores all results into a filesystem context
which can be passed to the various transports as needed.
Some of the parsing helper functions such as get_cache_mode() have been
eliminated in favor of using the new mount API's enum param type,
for simplicity.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Message-ID: <20251010214222.1347785-5-sandeen@redhat.com>
[ Dominique: handled source explicitly as per follow-up discussion ]
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
This patch creates a new v9fs_context structure which includes
new p9_session_opts and p9_client_opts structures, as well as
re-using the existing p9_fd_opts and p9_rdma_opts to store options
during parsing. The new structure will be used in the next
commit to pass all parsed options to the appropriate transports.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Message-ID: <20251010214222.1347785-4-sandeen@redhat.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
